In any case I’d like to see an explicit text in the draft saying that this document only redefines how IV is generated and (non) transmitted,
all the other aspects of applying these transforms are defined in the relevant RFCs: ENCR_AES_CCM_8_IIV – from RFC 4309 (for ENCR_AES_GCM_8) ENCR_AES_GCM_16_IIV – from RFC 4106 (for ENCR_AES_GCM_16) ENCR_CHACHA20_POLY1305_IIV – from RFC 7634 This is probably obvious, but I prefer to explicitly state this, since it’s a technical document and it should not leave a space for ambiguity. Regards, Valery. From: Valery Smyslov [mailto:[email protected]] Sent: Wednesday, April 03, 2019 9:05 AM To: 'Daniel Migault'; 'Paul Wouters' Cc: 'IPsecME WG' Subject: RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing Hi Daniel, I understand that the draft is only focused on the IV, but since it defines new transforms, it formally must address key length issue for AES. You can either copy-paste text from RFC 4106 (or 4309), or add text referencing Section 8.4 of RFC 4106 for GCM and Section 7.4 of RFC 4309 for CCM. Or alternatively, as I already suggested, you can define default key length and make Key Length attribute optional – it will allow to save a couple of bytes for most common cases. In any cases, I prefer not to put this into Introduction, but instead add a new section, as it is done in all other transform-defining RFCs. Regards, Valery. From: Daniel Migault [mailto:[email protected]] Sent: Tuesday, April 02, 2019 9:41 PM To: Paul Wouters Cc: Valery Smyslov; IPsecME WG Subject: Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing Hi, Thanks Valery for your comment. My reading of the draft is that it only focuses on the generation of the nonce and leave the remaining to 4306 [1]. The use of a code points different from 4306 is to indicate the implicit IV - as opposed to a new transform. In this case, the negotiation of the key length is left to 4306. I am inclined to think this is not necessary to discuss the key length attribute in this draft, but I would like to see what the other think. That said, if people strongly think that should be added, I would add the text from 4306 mentioned below[2]. Yours, Daniel [1] The text of the implicit draft: <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2> 2. Introduction Counter-based AES modes of operation such as AES-CTR ([RFC3686 <https://tools.ietf.org/html/rfc3686> ]), AES-CCM ([RFC4309 <https://tools.ietf.org/html/rfc4309> ]), and AES-GCM ([RFC4106 <https://tools.ietf.org/html/rfc4106> ]) require the specification of an nonce for each ESP packet. The same applies for ChaCha20-Poly1305 ([RFC7634 <https://tools.ietf.org/html/rfc7634> ]). Currently this nonce is sent in each ESP packet ([RFC4303 <https://tools.ietf.org/html/rfc4303> ]). This practice is designated in this document as "explicit nonce". [...] This document defines how to compute the nonce locally when it is implicit. It also specifies how peers agree with the Internet Key Exchange version 2 (IKEv2 - [RFC7296 <https://tools.ietf.org/html/rfc7296> ]) on using an implicit IV versus an explicit IV. [2] the text on key length of RFC 4306. <https://tools.ietf.org/html/rfc4106#section-8.4> 8.4. Key Length Attribute Because the AES supports three key lengths, the Key Length attribute MUST be specified in the IKE Phase 2 exchange [RFC2407 <https://tools.ietf.org/html/rfc2407> ]. The Key Length attribute MUST have a value of 128, 192, or 256. On Tue, Apr 2, 2019 at 12:52 PM Paul Wouters <[email protected]> wrote: On Tue, 2 Apr 2019, Valery Smyslov wrote: > and define a default key length for the case when it is absent (e.g. 256 > bits). Do not do this. There are broken implementations and interop issues on this already by broken clients who don't send or omit to send KEY_LENGTH (old versions of us included). > It'll allow us to save few bytes by omitting attribute for most common cases. Not worth it. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
