Re: [Simple] <note> in IMDN

[Eric Burger <[e-mail]>]

I cannot argue with that position :-)
+1

On Sep 16, 2008, at 9:24 PM, Hisham Khartabil wrote:

> For the sake of moving this draft to completion, I plan to remove  
> the <note> element from IMDNs. If someone is interested in extending  
> the schema to allow an element that carries extra information about  
> the reasons behind a certain disposition status, please write an I-D.
>
> Any objections?
>
> Regards,
> Hisham
>
>
> On 04/06/2008, Eric Burger <[e-mail]> wrote: Except:
>
> 1. I have no clue what language to use in the message, as a human  
> will read it.
>
> 2. The field is free-form, so is not amenable for automaton  
> processing.
>
> 3. The field is free-form, but could be read by the UAC, so it will  
> invite vendors to put proprietary information into the field.  Then  
> users expect particular behaviors when these values are present.   
> I.e., who needs the IETF to review protocol element use?  Let the  
> random implementor of the day build a protocol on top of IMDN!
>
> 4. The field is free-form and displayed to the user, so it will  
> invite spam.
>
> If it is useful from a protocol perspective, then create an IANA  
> registry of values.
>
>
>
> On Jun 4, 2008, at 5:19 AM, Hisham Khartabil wrote:
>
> The field is not useless. It carries extra information (a reason
> phrase, if you like) as to why the IM delivery resulted in an error or
> still being processed, etc.
>
> Hisham
>
> 2008/6/4 Ben Campbell <[e-mail]>:
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple
>
>
>

_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple