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: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDD2C11E80FC; Thu, 22 Aug 2013 20:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hyx2P94K9DJu; Thu, 22 Aug 2013 20:39:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D0EB911E813B; Thu, 22 Aug 2013 20:39:19 -0700 (PDT)
X-AuditID: 12074425-b7f0c8e000000953-64-5216d9668aa0
Received: from ( []) by (Symantec Messaging Gateway) with SMTP id 41.09.02387.669D6125; Thu, 22 Aug 2013 23:39:18 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id r7N3dGkg030256; Thu, 22 Aug 2013 23:39:17 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by (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 ( id r7N3dDjo004274; Thu, 22 Aug 2013 23:39:13 -0400 (EDT)
To: "Black, David" <>
References: <> <> <>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 22 Aug 2013 23:39:13 -0400
In-Reply-To: <> (David Black's message of "Thu, 22 Aug 2013 20:46:07 -0400")
Message-ID: <>
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: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-storm-ipsec-ips-update-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Aug 2013 03:39:27 -0000

"Black, David" <>; 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.