Re: [Simple] <note> in IMDN

[Ben Campbell <ben at estacado.net>]

On May 23, 2008, at 2:21 PM, 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?
>

If something has no useful protocol value, even if it _does_no_harm,  
why would we want to include it?

IMHO, there is no need to prove a vector for harm, if we are fairly  
certain there is no vector for _utility_.

(Note that I am agnostic on whether  the field is truly useless--I am  
merely commenting on the form of the argument.)


>
>
> 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