Re: [Simple] <note> in IMDN

------=_Part_5772_8618092.1221625451From simple-bounces at ietf.org Tue Sep 16 21:24:02 2008 Return-Path: <simple-bounces at ietf.org> X-Original-To: simple-archive at megatron.ietf.org Delivered-To: ietfarch-simple-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4093E3A6949; Tue, 16 Sep 2008 21:24:02 -0700 (PDT) X-Original-To: simple at core3.amsl.com Delivered-To: simple at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72803A693E for <simple at core3.amsl.com>; Tue, 16 Sep 2008 21:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqBb8vI9MMHM for <simple at core3.amsl.com>; Tue, 16 Sep 2008 21:23:58 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id C3EF43A68CD for <simple at ietf.org>; Tue, 16 Sep 2008 21:23:58 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2762283rvf.49 for <simple at ietf.org>; Tue, 16 Sep 2008 21:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=hkXN7OeA2cUSunDdGkJtt1YUSPdC7Gtryv1sA/mY1Ow=; b=C4z6fQnDjDzfZ9h2IY8yFp82SkcHjCE69YtjDCIe9i9KwNwgN3qDqDo6lokBuJm/Qm qddXS9My5jhoIRM91z1AuG6iFP49trR/CxmqBUN2CUNeIMBZRquQUWT6NJ9KV/93Vq+s x86zu9OomuapbePyjsPD7y7aRH+12WD7pajzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Jnwoei7kFPBuJIOrVDEmfPuoUQgafP9koynIOrxsG5YaEYLXaguq51bA8hLOlOqcmA y5E5TZ1Uiczmhop1Iln0G0byZIuttd8Mi0J+PIUYYtzS8wSrQpr66EKRMigb7MFDGdQk G3S0iW1ZJOzsng8JHuT1mmtTMF8cjPDQU38NE= Received: by 10.141.49.18 with SMTP id b18mr6242087rvk.92.1221625451084; Tue, 16 Sep 2008 21:24:11 -0700 (PDT) Received: by 10.141.116.8 with HTTP; Tue, 16 Sep 2008 21:24:11 -0700 (PDT) Message-ID: <66cd252f0809162124k1a861742t650609595759cd77 at mail.gmail.com> Date: Wed, 17 Sep 2008 14:24:11 +1000 From: "Hisham Khartabil" <hisham.khartabil at gmail.com> To: "Eric Burger" <eburger at standardstrack.com> In-Reply-To: <BD67270B-42E9-4A20-B47E-5A7279AB17FF at standardstrack.com> MIME-Version: 1.0 References: <1660532724-1210725948-cardhu_decombobulator_blackberry.rim.net-784864713- at bxe033.bisx.prod.on.blackberry> <66cd252f0805131939t6569dab7r45d8ced20471a157 at mail.gmail.com> <77384F67-E82C-483C-B555-665BFAF02D4E at standardstrack.com> <66cd252f0805132138m23aa3f42kf01ce0dcb7c42181 at mail.gmail.com> <3092F25A-A072-4952-9C44-8C639B1925E2 at softarmor.com> <4834C22B.1000407 at cisco.com> <AD5C512E-842F-48F3-8824-03EE8A7F7905 at sipforum.org> <437FCCA2-DA86-48D8-9DAA-24A09CDDE677 at estacado.net> <66cd252f0806040219x4f3354d0t91b76f729452c3e1 at mail.gmail.com> <BD67270B-42E9-4A20-B47E-5A7279AB17FF at standardstrack.com> Cc: simple at ietf.org Subject: Re: [Simple] <note> in IMDN X-BeenThere: simple at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request at ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/simple> List-Post: <mailto:simple at ietf.org> List-Help: <mailto:simple-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1247197582==" Sender: simple-bounces at ietf.org Errors-To: simple-bounces at ietf.org

On 04/06/2008, Eric Burger <eburger at standardstrack.com> 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 <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
oppo
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

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