[secdir] secdir review of draft-snell-http-prefer-15

Tom Yu <tlyu@MIT.EDU> Fri, 12 October 2012 21:36 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1F65321F8748; Fri, 12 Oct 2012 14:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aoSHhSvxy-nP; Fri, 12 Oct 2012 14:36:43 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU []) by ietfa.amsl.com (Postfix) with ESMTP id A8F2F21F8746; Fri, 12 Oct 2012 14:36:41 -0700 (PDT)
X-AuditID: 1209190e-b7f756d000000904-26-50788d68224f
Received: from mailhub-auth-2.mit.edu ( []) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id EB.CA.02308.86D88705; Fri, 12 Oct 2012 17:36:40 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU []) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q9CLadpd000562; Fri, 12 Oct 2012 17:36:39 -0400
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU []) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q9CLaZE3010131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Oct 2012 17:36:37 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu ( id q9CLaZ0H010087; Fri, 12 Oct 2012 17:36:35 -0400 (EDT)
To: iesg@ietf.org, secdir@ietf.org, draft-snell-http-prefer.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Fri, 12 Oct 2012 17:36:35 -0400
Message-ID: <ldvd30nz82k.fsf@cathode-dark-space.mit.edu>
Lines: 54
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nopvRWxFgcHEim8X0adNYLWb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK+PcYv+CLyIV6+/dZG1gnCHYxcjB ISFgInFyQVEXIyeQKSZx4d56ti5GLg4hgX2MEis/32SGcDYwSmx8+Qcqc4VJ4uv9GSwQThej xPX+jcwg/SICfhKr1xxjBLGFgcZ+6Z7LBLKCTUBa4ujiMpAwi4CqxLStXawgNq+AhcTFnvks IDaPAKfE10sTmSHighInZz4BizMLaEnc+PeSaQIj3ywkqVlIUgsYmVYxyqbkVunmJmbmFKcm 6xYnJ+blpRbpGuvlZpbopaaUbmIEBRqnJN8Oxq8HlQ4xCnAwKvHw3uiuCBBiTSwrrsw9xCjJ waQkymvcDBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwsuXDpTjTUmsrEotyodJSXOwKInzXkm5 6S8kkJ5YkpqdmlqQWgSTleHgUJLgzegBahQsSk1PrUjLzClBSDNxcIIM5wEangtSw1tckJhb nJkOkT/FqCglzlsKkhAASWSU5sH1whLBK0ZxoFeEeWtBqniASQSu+xXQYCagwQ0Xy0EGlyQi pKQaGB1YzMJebfrwwZqx1qVH+ufZw3Z2PPyPfzP7TNN8p7TAPqFl67ZZ2Sqm1o6TOxYvk9JV jVy3flu1QO6LJ6U/BUvXirIxOD9li1PgndWzMnBd7war2O2xkk1yUSXqN2VbvzTYSqwWcDbz FvpjOjHt5ZNH79Vsu2bU7+83XbVo34SlzL8DjV7UKrEUZyQaajEXFScCAJxHacbfAgAA
Subject: [secdir] secdir review of draft-snell-http-prefer-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 12 Oct 2012 21:36:44 -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.

The -15 version has substantial changes from the -14 version that I
began reviewing, but the changes appear to not affect my evaluation.
This document appears mostly ready for publication, but it could use a
few minor clarifications.

The Security Considerations (Section 6) states that implementers need
to refer to the specification of each preference to determine the
security considerations relevant to each, but the specifications of
the preferences defined in this document do not state any security
considerations.  The second paragraph of Section 6 describes server
resource consumption risks associated with honoring a client's
requested preferences.  These risks seem primarily applicable to the
preferences "return-asynch", "return-representation", and possibly

Do the other preferences specified in this document lack such risks of
excessive server resource consumption?  It would be useful to
explicitly state whether they do.

Not security related:

In Section 2, the right hand side of the first line of the ABNF rule
for "preference" seems identical to that for "parameter".  Why does
"parameter" not appear in first line of the definition of
"preference"?  Is it solely to distinguish the semantics of the first
token (or key-value pair) in the semicolon-separated list?

Consider rewording "A preference token can contain a value." to "A
preference token can have an associated value.", because the value
("word") is not syntactically a part of the token.

"An optional set of parameters" should probably be reworded "An
optional set of named parameters".  This change would help clarify
that the optional word that follows the preference token is not a
parameter, but is an unnamed value associated with the parameter

Is the prevailing practice to omit any spaces preceding the semicolon,
and to have a single space after the semicolon?  If so, it might be
useful to mention.  (I think there might be a similar issue with the
"#rule" in draft-ietf-httpbis-p1-messaging-21, but I haven't checked
that document extensively.)  Such practices appear consistent with the
examples in this document and with conventional English punctuation.


In the first paragraph of Section 6, "it's additional associated"
should be "its additional associated".