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: 2 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-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. 8.4 <https://tools.ietf.org/html/rfc4106#section-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
