[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.