[secdir] secdir review of draft-ietf-sipcore-subnot-etags-02

Sam Hartman <hartmans-ietf@mit.edu> Tue, 23 June 2009 16:12 UTC

Return-Path: <hartmans@mit.edu>
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 DF51B28C3C0; Tue, 23 Jun 2009 09:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level:
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 YydsAvNr6Lvn; Tue, 23 Jun 2009 09:12:24 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 2421928C3B2; Tue, 23 Jun 2009 09:12:24 -0700 (PDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 476ED4143; Tue, 23 Jun 2009 12:12:35 -0400 (EDT)
To: secdir@ietf.org, iesg@ietf.org
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Tue, 23 Jun 2009 12:12:35 -0400
Message-ID: <tsltz27apzg.fsf@mit.edu>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: draft-ietf-sipcore-subnot-etags@tools.ietf.org, sipcore-chairs@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-sipcore-subnot-etags-02
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, 23 Jun 2009 16:12:25 -0000

I've reviewed this draft for the security directorate.  My review was
reasonably light although I believe was sufficient. 

This draft defines a mechanism so that subscribers can avoid a
notification message being generated when they already know the
contents of that notification.

The security considerations section claims that this mechanism does
not change the security properties of the protocol: it is just an
optimization.  I'm fine with the document as it stands.  It's not
inherently true that an optimization of this type doesn't change the
security properties.  For example, if an attacker could modify a
subscribe request and suppress a notification, that might change the
security properties.

However, as far as I can tell, this particular mechanism does not make
any significant changes to the security properties.