[secdir] secdir review of draft-ietf-sipcore-info-events

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 20 April 2010 09:18 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E1D28C0FD for <secdir@core3.amsl.com>; Tue, 20 Apr 2010 02:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level:
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
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 RU5ZKNMjwQ+t for <secdir@core3.amsl.com>; Tue, 20 Apr 2010 02:18:56 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 3C2883A6900 for <secdir@ietf.org>; Tue, 20 Apr 2010 02:18:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 681773E4083; Tue, 20 Apr 2010 10:18:39 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1271755118; bh=YNow6914nNIh13NJQMkM8SWC 44WplpGbVYlr0Pk0N1M=; b=CFFqsf/rWNyI/re8Xd4sUAgHjYGX0dDd16vKThxK yqjtcbCaCTGF+2G7uvGjr7hhRs67hd3Q+XsylOmOxubHPxNvtPh0Iy/gxemykX55 +iYFPrDWqRf/QpRR75uP/b3Fi7+vMSNcmO+Op6uEit6D1ihSSfsz3d85bGPSPs38 PR/qPDlLlh1uWDuqnBO7ethcUvrUS+4KE1fDa2KzcowVI0U+eeeGQVszaByNqZc6 neVMilgRZ/NHuU6qSrzGM/wIkiRIGQXYUvFAXu5UQMXr5jOVwjnrq8xiuv/Xvfol lqNGBpnal8hX12Qvk5CrcMLe/aTO0XipygJeCFq3t+Sxbg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id aBgUrh-G7337; Tue, 20 Apr 2010 10:18:38 +0100 (IST)
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 964143E407F; Tue, 20 Apr 2010 10:18:36 +0100 (IST)
Message-ID: <4BCD7169.9020701@cs.tcd.ie>
Date: Tue, 20 Apr 2010 10:18:33 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: secdir@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org, sipcore-chairs@tools.ietf.org
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [secdir] secdir review of draft-ietf-sipcore-info-events
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Apr 2010 09:18:58 -0000

Hi,

(Sorry for the tardy review;-)

This specification sort-of provides a SIP-based tunnel
for application protocols.

1: What prevents (or allows detection of) insertion of
bogus Info Package specifications? (e.g. by a proxy). If
nothing, then why is this ok?

2: I don't know how prevalent implementations of this are,
or will be, but since this calls for the user agents to
include a MIME parser plus parsers for whatever MIME types
the user agent claims to support, I'd say some guideance
about defensive programming (e.g. avoiding buffer overruns
etc.) should be given somewhere (maybe that's a more generic
SIP thing though).

3. 4.2.2. says that a UA MUST indicate which Info packages it
supports.  That seems a bit open-kimono - why MUST all UAs tell
everyone everything they support all the time? Won't that
expose more attack surface than is wise? Wouldn't it be better
to first know who the other UA is, before telling them everything
every time? For example, imagine a UA supported the "US Govt
SECRET foobar application Info Package," I'm guessing that it
wouldn't be ok to just say that to every UA one meets on
the Internet.

4. 10.10 says that if TLS is not good enough, then use S/MIME.
My understanding is that no UAs implement S/MIME (or CMS really)
and no networks support its use. So shouldn't that really say
"if TLS is not good enough, then just don't do it or require
the application to do its own security"? Same point applies to
section 13. I would think that securing specific applications
would be easier and more likely than getting S/MIME used in UAs,
so why not recommend that?

5. 1st para of section 13 says that this will be an improvement
over RFC2976. I would think a reference to the problems with
that RFC or to something detailing the expected improvement is
warranted.

6. How and why would one "filter for approved Info Packages" as
stated in section 13? It seems like that single sentence is either
too much or too little, so maybe delete it or expand upon it, so
that an implementer might know what's reasonable filtering.

Non security notes:

s1, 2nd para: how can you prevent INFO being used to update the
state of a "SIP dialog or session"? Seems like it'd be more
accurate to say that that's the intent but that there really are
no guarantees. The example given in the abstract of RFC2976 seems
in fact to be directly related to signalling so that's confusing.

Nits/Typos:

10.10: s/certain level/a certain level/


Stephen.