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

[Tom Yu <[e-mail]>]

"Black, David" <[e-mail]> 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.