Re: [Simple] <note> in IMDN

[Eric Burger <eburger at sipforum.org>]

Almost all of the fields in IMDN are verbatim copies of the IM, which  
means an automaton can filter spoofed IMDN's.  Just about all of the  
fields have some protocol semantic value.  However, the <note> field  
is a spam delivery vector that has no protocol value.  That is my  
issue with it: no value *and* a method to introduce spam.  That does  
not sound like a winning combination.

On May 23, 2008, at 5:23 PM, Paul Kyzivat wrote:

>
>
> Eric Burger wrote:
>> 1. The content
>
> Then aren't you concerned with all the nearly unconstrained content  
> that is possible in sip itself? (quoted-strings can be used in many  
> places, and comments are allowed in a few.)
>
> In the context you are talking about, the content is constrained by  
> the syntax of xml. Are you concerned with the xml parser screwing  
> up? Or with an application screwing up processing the content after  
> it has been parsed from the xml - perhaps by doing a bad job of  
> trying to display it?
>
>> 2. IMDN is only for page-mode IM, not MSRP
>
> Oops, sorry. I forgot IMDN had been thrown out of MSRP.
>
> 	Paul
>
>> On May 23, 2008, at 5:08 PM, Paul Kyzivat wrote:
>>> Eric,
>>>
>>> I guess I'm missing what kink of problem you are trying to prevent  
>>> by
>>> constraining the content, and what kinds of constraints are needed  
>>> for
>>> this to be helpful.
>>>
>>> Are you concerned with unconstrained *length* or unconstrained
>>> *content*? You can already put fields of unconstrained length and  
>>> nearly
>>> unconstrained content into MSRP headers, in those places where
>>> quoted-string are allowed.
>>>
>>>    Paul
>>>
>>> Eric Burger wrote:
>>>> Actually, IMDNs, even the SIMPLE free-form fields, are fairly
>>>> constrained.  Any mis-match is an opportunity to filter out bad  
>>>> IMDNs.
>>>> The <note> field has three problems:
>>>>
>>>> 1. It cannot be filtered, as any content could be real (which  
>>>> introduces
>>>> the attack vector)
>>>>
>>>> 2. It cannot know what language it should use, and thus is not  
>>>> likely to
>>>> be useful to the recipient
>>>>
>>>> 3. It has no protocol value, and is of no value to the UA
>>>>
>>>>
>>>> So, if something has no useful protocol value and introduces a spam
>>>> opportunity, why would we want to include it?
>>>>
>>>>
>>>>
>>>> On May 21, 2008, at 7:45 PM, Paul Kyzivat wrote:
>>>>
>>>>> Its kind of late to be thinking about this now. THe problem is  
>>>>> pervasive
>>>>> in MSRP.
>>>>>
>>>>> In SIP there are lots of unconstrained fields. But they are all
>>>>> constrained by the overall size of the message, and people  
>>>>> commonly put
>>>>> limits on that.
>>>>>
>>>>> In MSRP, because of chunking, a single MSRP message can be  
>>>>> gigabytes
>>>>> long. So using that to bound the unconstrained parts of the  
>>>>> headers
>>>>> doesn't work very well.
>>>>>
>>>>> A robust implementation might take a similar approach - define  
>>>>> its own
>>>>> limit on the total message size, excluding the body. Then it could
>>>>> constrain all the unconstrained fields to fit within it.
>>>>>
>>>>> But picking on one header isn't a solution to the problem.  
>>>>> Either assume
>>>>> the developers will be able to deal with it, or else do and  
>>>>> MSRPv2 that
>>>>> eliminates all unconstrained fields.
>>>>>
>>>>>   Paul
>>>>>
>>>>> Dean Willis wrote:
>>>>>> On May 13, 2008, at 11:38 PM, Hisham Khartabil wrote:
>>>>>>
>>>>>>> Can you explain how it is an attack vector?
>>>>>>
>>>>>>
>>>>>> Unconstrained rich content is one of the most easily exploited  
>>>>>> attack
>>>>>> vectors.
>>>>>>
>>>>>> Buffer overrun attacks as well as all of the typical MIME  
>>>>>> compound-
>>>>>> component attacks are likely. For example, the common JPEG
>>>>>> vulnerabilities might be exploitable:
>>>>>>
>>>>>> http://www.news.com/Image-virus-spreads-via-chat/2100-7349_3-5390463.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> Or the content-execution weakness that caused the Macintosh  
>>>>>> Safari
>>>>>> browse to be most easily exploited in recent hacking contests:
>>>>>>
>>>>>> http://www.engadget.com/2007/07/23/safari-exploit-gives-hackers-full-control-of-your-iphone/
>>>>>>
>>>>>>
>>>>>>
>>>>>> There have also been exploits against QuickTime, Flash, and  
>>>>>> most other
>>>>>> plugin components from time to time.
>>>>>>
>>>>>> -- 
>>>>>> Dean
>>>>>> _______________________________________________
>>>>>> Simple mailing list
>>>>>> Simple at ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>>>
>>>>> _______________________________________________
>>>>> Simple mailing list
>>>>> Simple at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>
>>>>
>>> _______________________________________________
>>> Simple mailing list
>>> Simple at ietf.org
>>> https://www.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple