[secdir] secdir review of draft-ietf-sipping-sip-offeranswer-14.txt

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 22 April 2011 11:45 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id 27BB8E06B1; Fri, 22 Apr 2011 04:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.191
X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id URn0U6i03P6s; Fri, 22 Apr 2011 04:45:19 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de []) by ietfc.amsl.com (Postfix) with ESMTP id 6BE3EE06C1; Fri, 22 Apr 2011 04:45:19 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de []) by hermes.jacobs-university.de (Postfix) with ESMTP id 95DF820C2C; Fri, 22 Apr 2011 13:45:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([]) by localhost (demetrius2.jacobs-university.de []) (amavisd-new, port 10024) with ESMTP id nqdHgg93cinG; Fri, 22 Apr 2011 13:45:18 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de []) by hermes.jacobs-university.de (Postfix) with ESMTP id C00CC20C19; Fri, 22 Apr 2011 13:45:17 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 890501778218; Fri, 22 Apr 2011 13:45:17 +0200 (CEST)
Date: Fri, 22 Apr 2011 13:45:17 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org
Message-ID: <20110422114517.GA2512@elstar.local>
Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sipping-sip-offeranswer.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [secdir] secdir review of draft-ietf-sipping-sip-offeranswer-14.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 22 Apr 2011 11:45:20 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I reviewed earlier versions of this I-D in Feburary 2009 and in
December 2010. This revision has more explicit text in the security
considerations, which essentially states that the clarifications on
offer/answer exchanges do not add any new security issues. It took me
some time to parse the sentences, perhaps a simpler wording could have
been used (e.g. s/exclude from use/exclude). I appreciate the more
explicit text and the concrete pointers to the relevant RFCs.

However, these references raise a procedural question. It seems all
these relevant specifications are on the standards track while this
clarification, which tries to handle situations that can lead to
"failed or degraded calls", is submitted as an Informational document.
Should this not be standards track, formerly updating the relevant
RFCs? I see in the IESG writeup that this has been discussed before,
the proposed move to publish this as Informational still sounds
surprising to me as an outsider. If there is consensus to resolve the
ambiguities as described in the document, then why not via a
standards-track action?  Or is the idea that this resolution simply
can be ignored or that something very different might be invented?
That latter would more speak for Experimental then.

Getting back to security considerations, if the intention is not to
require implementations to follow the disambiguation described in the
document (that is not moving to standards-track), can malware exploit
the fact that the underlying RFCs allow for ambiguities to cause
"failed or degraded calls"?


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>