[secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03

Tom Yu <tlyu@MIT.EDU> Wed, 21 August 2013 18:56 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 B430B21F9E48; Wed, 21 Aug 2013 11:56:57 -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 POFlHk8EY7la; Wed, 21 Aug 2013 11:56:51 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu []) by ietfa.amsl.com (Postfix) with ESMTP id F33DB21F9CD9; Wed, 21 Aug 2013 11:56:50 -0700 (PDT)
X-AuditID: 1209190f-b7fa58e000000953-cd-52150d72bf6c
Received: from mailhub-auth-1.mit.edu ( []) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 66.D2.02387.27D05125; Wed, 21 Aug 2013 14:56:50 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r7LIunkR009694; Wed, 21 Aug 2013 14:56:49 -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.8/8.12.4) with ESMTP id r7LIuk51011261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 14:56:48 -0400
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu ( id r7LIukaK029452; Wed, 21 Aug 2013 14:56:46 -0400 (EDT)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-storm-ipsec-ips-update.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 21 Aug 2013 14:56:46 -0400
Message-ID: <ldvmwoa7tzl.fsf@cathode-dark-space.mit.edu>
Lines: 44
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrFvEKxpk0DFV0OLRu9NMFjP+TGS2 +LDwIYsDs8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfHodAdzwTTBirmXnzE1MP7j7WLk 5JAQMJE4eeI/C4QtJnHh3nq2LkYuDiGBfYwS/RcWgiWEBDYySvy4zg9hn2OSuPrJB6Koi1Fi 1okGZpCEiECixPquG0wgtrCAncT3rZMYuxg5ONgEpCWOLi4DCbMIqEo0HWsEK+EVsJDY/Xgv I4jNI8ApMffObWaIuKDEyZlPwPYyC2hJ3Pj3kmkCI98sJKlZSFILGJlWMcqm5Fbp5iZm5hSn JusWJyfm5aUW6Zro5WaW6KWmlG5iBAeaJP8Oxm8HlQ4xCnAwKvHwXtgpEiTEmlhWXJl7iFGS g0lJlHcRt2iQEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHexWxAOd6UxMqq1KJ8mJQ0B4uSOO+z p2cDhQTSE0tSs1NTC1KLYLIyHBxKErxZPECNgkWp6akVaZk5JQhpJg5OkOE8QMM7QGp4iwsS c4sz0yHypxgVpcR5E0ASAiCJjNI8uF5YInjFKA70ijBvN0gVDzCJwHW/AhrMBDR4toYQyOCS RISUVAOjePb35Lfp/Z3xrQwLq3490Wjc9ffLQ871F9SXb5//uPGhvrjFtc+tcwo/PGuL/rNn 7vfmp/XH5n95dr37+6GrKXf33UxMOOqd53ns838Bubnu8y521Jrz7p/+6tK5tZYaxj52Ahb6 ATViu0RkmbpZd9ivvZuVOqGb7eMdAWaHX2wTFqyzvHp3jxJLcUaioRZzUXEiAPTz9IPfAgAA
Subject: [secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03
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: Wed, 21 Aug 2013 18:56:57 -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 believe this document is ready with minor issues.

The Security Considerations section in its entirety is

    "This entire document is about security."

Although the above statement is true, I think it would also be
beneficial to provide additional information in the Security
Considerations to help implementers and administrators make informed
risk assessments.  This could include describing the consequences of
failing to adopt the recommendations of this document.  I have
outlined below some possible risk tradeoffs to consider describing in
the document.

AES in GCM mode is vulnerable to catastrophic forgery attacks if a
nonce is ever repeated with a given key.  Hopefully this won't be a
practical issue, but implementation bugs involving random number
generators are not uncommon.  Forgery in a content protection context
is probably also less of a concern than forgery in an authentication

What concerns with AES-CTR motivate its demotion?  I do seem to recall
that (contrary to best practice) confidentiality can be done
separately from integrity in IPsec.  Is this composition done in a way
that has vulnerabilities?  I'm not very familiar with IPsec and am not
remembering the details at the moment.

If there is sufficiently low traffic, is it likely that a site
constrained by legacy or resource issues could use 3DES (with its
64-bit block size) at an acceptable risk level?  (possibly with
frequent rekeying)  Ciphertext collision isn't as catastrophic with
CBC mode ciphers as nonce collision is for AES-GCM.  McGrew's paper
about collision attacks includes equations that estimate data leakage.

It could be useful to include advice about matching symmetric key
lengths with public key strengths.  See NIST SP 800-57 Part 1.

What are the consequences of sequence number cycling in ESP?