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

Tom Yu <tlyu@MIT.EDU> Fri, 23 August 2013 03:39 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 BDD2C11E80FC; Thu, 22 Aug 2013 20:39:26 -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 Hyx2P94K9DJu; Thu, 22 Aug 2013 20:39:20 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id D0EB911E813B; Thu, 22 Aug 2013 20:39:19 -0700 (PDT)
X-AuditID: 12074425-b7f0c8e000000953-64-5216d9668aa0
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 41.09.02387.669D6125; Thu, 22 Aug 2013 23:39:18 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r7N3dGkg030256; Thu, 22 Aug 2013 23:39:17 -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 r7N3dDbu001801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 23:39:15 -0400
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r7N3dDjo004274; Thu, 22 Aug 2013 23:39:13 -0400 (EDT)
To: "Black, David" <david.black@emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE7129C489A53@MX15A.corp.emc.com> <ldv7gfd5lyl.fsf@cathode-dark-space.mit.edu> <8D3D17ACE214DC429325B2B98F3AE7129C489CB1@MX15A.corp.emc.com>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 22 Aug 2013 23:39:13 -0400
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489CB1@MX15A.corp.emc.com> (David Black's message of "Thu, 22 Aug 2013 20:46:07 -0400")
Message-ID: <ldvvc2x3wke.fsf@cathode-dark-space.mit.edu>
Lines: 111
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hRV1k27KRZkcKXbxGLr4bXsFo/enWay mPFnIrPFh4UPWRxYPI4cmc3isWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBlLHx6iLVguWrF 93Nn2BsYb8h2MXJySAiYSOzrXcMMYYtJXLi3nq2LkYtDSGAfo8SWY2dZIJyNjBIvL21khXDO MUnc3ruJGcLpYpRY8q+DFaRfREBDYvvHfYwgCWaBA4wSX1+sYwJJCAs4Sey8t5IdomMHo0TX 2yNAHRwcbALSEkcXl4HUsAioSuy7sZcJpIZToJ1R4s+EDmaQGl4BC4nFV5JAangEuCTmXrzC BmLzCghKnJz5hAXEZhbQkrjx7yXTBEbBWUhSs5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtL LdK10MvNLNFLTSndxAgKZnYX1R2MEw4pHWIU4GBU4uGd4CwWJMSaWFZcmXuIUZKDSUmUV+YC UIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr80qoBxvSmJlVWpRPkxKmoNFSZz3+dOzgUIC6Ykl qdmpqQWpRTBZGQ4OJQne5BtAjYJFqempFWmZOSUIaSYOTpDhPEDDC0FqeIsLEnOLM9Mh8qcY dTn+rJz7iVGIJS8/L1VKnDcLpEgApCijNA9uDiwJvWIUB3pLmNcNpIoHmMDgJr0CWsIEtGTm Y1GQJSWJCCmpBsbAn2/lL75bu2czp+TPmlt18dZ3JU53y8y9zWai53/yve6dludzX3fuYju9 +SHruRb2rcH1k85WffzBtjpS376v5n5c5KtmpoVMJ0V5Vk1Yn5W+/NS8XIdWrdvcvvN9l6xK /NvqeII9+0V4SOrqSy/WPS+5fnvixZdLA+Zl9mSsfJLnZnI1YVOZEktxRqKhFnNRcSIAKYWz bB0DAAA=
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: Fri, 23 Aug 2013 03:39:27 -0000

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

> Tom,
>
> I think we should agree to disagree on one point, and I'm prepared to make
> text changes to address the others (in particular, you are clearly right
> that the hardware implementation rationale for AES GCM instead of AES CTR
> should be made clearer).  As previously noted, I plan to hold off on
> submitting a revised draft until after the IESG telechat on August 29.
>
> Again, thank you for the review and your comments.
>
> -- Point of disagreement
>
> I firmly believe that filing technical errata against RFC 4106 (AES GCM)
> is the appropriate vehicle for the concerns about AES GCM nonce reuse,
> including the comparison of security properties to AES CTR.  Such errata will
> get the requisite level of review from security experts and cryptographers
> who may not look at this draft, and will result in them being seen by
> anyone who implements GCM, in contrast to this draft which may not even
> be consulted by all IPsec implementers.
>
> I propose leaving this to the Security ADs to determine at this juncture, as
> I believe I understand your security concerns, (with which I do not disagree).
>
> Rather, I am asserting that this draft is the wrong vehicle for them, because
> (IMHO) they should be directly associated with the AES GCM RFC, and filing
> technical errata against that RFC is the appropriate means to accomplish that.

Hi David,

I think that is a reasonable approach (although I do have some slight
disagreement with it), and I'm willing to defer to the Security ADs
about which approach is the most appropriate in this situation.

> -- Points of agreement
>
> (1) Applicability of security considerations text in other RFCs
>
>> > * 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).
>
> Ok, I can do that.
>
> (2) Rationale for replacement of AES CTR with AES GCM
>
>> 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.
>
> That is the situation.
>
>> 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.
>
> Good suggestion - I'll plan on doing that.
>
> (3) Use of 3DES
>
>> 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?).
>
> Ok, I can write a sentence to the effect that when the data rate is low
> enough that 3DES's rekeying frequency is not a concern, 3DES is a
> reasonable algorithm to use.
>
> (4) Key strength matching
>
> As previously noted, I'll do the following:
>
>> > * 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.
>
> (5) ESP sequence numbers and rekeying
>
> As previously noted, I'll do the following:
>
>> > * 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).
>
> Thanks,
> --David

Yes, I believe we are in agreement on the other points you describe
above.  Thank you for your prompt and thoughtful reply.