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

Tom Yu <tlyu@MIT.EDU> Thu, 22 August 2013 23:45 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AC911E823B; Thu, 22 Aug 2013 16:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjhfGaAMK2EW; Thu, 22 Aug 2013 16:45:40 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 003A211E8239; Thu, 22 Aug 2013 16:45:38 -0700 (PDT)
X-AuditID: 1209190f-b7fa58e000000953-da-5216a2a1b544
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 3F.43.02387.1A2A6125; Thu, 22 Aug 2013 19:45:37 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r7MNjQwr013391; Thu, 22 Aug 2013 19:45:26 -0400
Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r7MNjNWx030597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 19:45:24 -0400
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r7MNjMYC003649; Thu, 22 Aug 2013 19:45:22 -0400 (EDT)
To: "Black, David" <david.black@emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE7129C489A53@MX15A.corp.emc.com>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 22 Aug 2013 19:45:22 -0400
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489A53@MX15A.corp.emc.com> (David Black's message of "Wed, 21 Aug 2013 16:16:39 -0400")
Message-ID: <ldv7gfd5lyl.fsf@cathode-dark-space.mit.edu>
Lines: 100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IRYrdT1124SCzIYP1jQYuth9eyWzx6d5rJ YsaficwWHxY+ZHFg8ThyZDaLx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CVcWT/K8aCL5oV j3b+ZGtgnKzUxcjJISFgIrHv6HFGCFtM4sK99WxdjFwcQgL7GCUO3dkA5WxklHhxZRMjhHOO SWJTVzsThNPFKNG3+wgTSL+IgIbE9o/7wKqYBQ4wSnx9sQ4sISzgJLHz3kp2EFtIwFNixeSD zF2MHBxsAtISRxeXgYRZBFQlbi9rBVvHKdDOKNFyej1YPa+AhcTUnw/ZQep5BLgkXs8sgQgL Spyc+YQFxGYW0JK48e8l0wRGwVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdHL zSzRS00p3cQICmVOSf4djN8OKh1iFOBgVOLhtXAUCxJiTSwrrsw9xCjJwaQkyntsLlCILyk/ pTIjsTgjvqg0J7X4EKMEB7OSCO+uiUA53pTEyqrUonyYlDQHi5I477OnZwOFBNITS1KzU1ML UotgsjIcHEoSvBcWAjUKFqWmp1akZeaUIKSZODhBhvMADd8OUsNbXJCYW5yZDpE/xajL8Wfl 3E+MQix5+XmpUuK8t0CKBECKMkrz4ObAUtArRnGgt4R594BU8QDTF9ykV0BLmICWzHwsCrKk JBEhJdXAmD3lSIqw/c+yayve1O1bH5L0JYy50fQgV0b+u57zjc8ZOeLYhCTLniu61/xfddi+ u9WotFRPeZfY8VPlyjsyHjKk3472sl2/+sVyi6OSAh7qElmXS18ETSyc1rx97d0/WpdfGs/I MH74e3eZ3N2b9+J/SihovS53X5lusjmgottL4+snHRFeJZbijERDLeai4kQAVsWgbxwDAAA=
Cc: "draft-ietf-storm-ipsec-ips-update.all@tools.ietf.org" <draft-ietf-storm-ipsec-ips-update.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Thu, 22 Aug 2013 23:45:50 -0000

"Black, David" <david.black@emc.com> writes:

> I would prefer not to repeat general advice applicable to all uses of
> IPsec in this draft.  That applies to the exposure of AES GCM to nonce reuse
> and means of preventing that reuse (e.g., use of IKE) which are covered in the
> Security Considerations section of RFC 4106; if that advice is inadequate,
> I'd suggest a revision of RFC 4106 rather than adding advice to this draft.

I would tend to agree about not repeating general advice applicable to
all uses of IPsec.  This document does replace AES-CTR with AES-GCM,
and the consequences of nonce reuse with these modes are qualitatively
different and possibly bear mentioning.

I think the text in RFC 4106 about the risks of nonce reuse should be
more specific about the consequences.  (RFC 4106 says "destroys the
security guarantees of AES-GCM mode" instead of "reveals the
authentication subkey".)  Compared to most other cipher modes, nonce
reuse in GCM has surprisingly catastrophic consequences.  Perhaps RFC
4106 could use revision, but that would not benefit readers of this
document until that revision was published.

> * OTOH, it would make sense to add a sentence to point out that all of the
> referenced security RFCs and the security considerations in all of the
> other referenced RFCs are applicable if that seems useful.

That would be useful, as would additional text calling out the
security considerations sections for RFCs related to algorithms whose
requirement levels this document changes, e.g., AES-CTR (RFC 3686),
AES-GCM (RFC 4106), and AES-GMAC (RFC 4543).

Because this document replaces one "SHOULD" requirement level AES
counter mode with another, I think it would also be useful to contrast
the considerably different consequences of nonce reuse in AES-CTR
(confidentiality loss limited to the blocks with colliding counter
values) compared to AES-GCM (additionally reveals the authentication
subkey).

The relative severity of these vulnerabilities might be debatable in
the context of a block storage protocol.  If you believe the security
impacts to block storage protocols caused by these nonce reuse issues
are negligibly different, the document might not need to make that
comparison.  (Although I would be interested in hearing the reasoning
behind such a belief.)

> As explained in Section 2.2, the hardware implementation considerations
> originally used to select AES-CTR as a "SHOULD implement" transform now
> favor AES-GCM.  Based on those considerations, AES-GCM is a significantly
> better choice due to its hardware-friendly hash, so retaining the "SHOULD"
> for AES-CTR doesn't make sense.

Am I correct in concluding from the above that there were no security
issues leading to the changes of requirement levels for AES-CTR
("SHOULD" to "MAY"), and that you base the advice on hardware
implementation considerations?  If so, this text in Section 2.2 seems
potentially misleading:

   "This document changes both [3DES-CBC and AES-CTR] of these
   requirements based on cryptographic developments since the
   publication of RFC 3723."

unless "cryptographic developments" refers to both the block size
vulnerability of 3DES and the standardization of AES-GCM.  In that
case, I would suggest adding text to the "AES Counter mode" paragraph
of Section 2.2 indicating that the new preference of AES-GCM above
AES-CTR is because of hardware implementation considerations and not
cryptographic weakness.

> The comments on 3DES seems off the mark to me.  The IETF approach to
> security, as I've understood it, is to require implementation of
> sufficient security mechanisms so that they will be available if needed.  
> Since the protocols to which this draft's requirements apply will operate
> at high data rates in some environments (e.g., see discussion in Section 2.2),
> 3DES is no longer appropriate as the single "MUST implement" confidentiality
> transform.  Further, the comparison to AES-GCM seems misplaced, as AES-CBC
> is the new "MUST implement" transform, not AES-GCM.

I agree that 3DES is no longer appropriate as the "MUST implement"
confidentiality transform.  I think that because 3DES remains
available as an optional algorithm, it could be valuable to provide
advice about when its use might be an acceptable risk (low data rate
sessions?).

> * I'll add some advice about matching strengths of symmetric and asymmetric
> keys with a pointer to NIST SP 800-57, as there are key length requirements
> in this draft.
>
> * ESP sequence number cycling is prohibited (MUST rekey before that happens)
> by RFC 2404 and RFC 4303, so I don't see any point in discussing its 
> consequences.  OTOH, I think it would be good to call attention to this
> requirement to rekey before the ESP sequence number rolls over and point out
> that extended sequence numbers greatly reduce the frequency at which that may
> be necessary (probably in Section 2 of this draft).
>
> The three paragraphs noted by '*' above indicate the three changes that I'd
> propose to make in response to this review - is that reasonable?
>
> With this draft in IESG Evaluation for next week's telechat (August 29),
> I would plan to defer these changes until after the telechat.

Your proposed changes seem reasonable.