Re: [Simple] <note> in IMDN

[Eric Burger <eburger at sipforum.org>]

1. The content

2. IMDN is only for page-mode IM, not MSRP


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