Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)
draft-ietf-ipsecme-implicit-iv-11
Yes
(Alexey Melnikov)
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)
Note: This ballot was opened for revision 07 and is now closed.
Roman Danyliw
No Objection
Comment
(2019-10-15 for -07)
Sent
** I support the DISCUSS position held by Ben Kaduk. (Derived from Magnus Nystrom’s SECDIR review) The abstract, Section 2, Section 4 and Section 7 make references to AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 (four algorithms). However, Section 4 also states “This document solely defines the IV generation of the algorithms defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for ChaCha20-Poly1305” (i.e., AES-CTR is missing). Likewise, no new code point is assigned for AES-CTR in Section 8. If AES-CTR is not in scope, then please don’t mention it in the draft. If it was missed from Section 4 and 8, please add it. ** Section 7. I’m having difficulty reconciling these two sentences: (1) Nonce generation for these algorithms has not been explicitly defined.” (2) This document provides an explicit and normative way to generate IVs. Isn’t this text saying the Nonce = Sequence number = IV? ** Section 7. Editorial. s/the IV is not allowed being repeated for one particular key./the IV is not allowed to be repeated for a particular key./ ** Section 7. Editorial. s/The Message-ID field in IKEv2 header is somewhat counterpart of SN field in ESP header, but recent …/The Message-ID field in IKEv2 header is similar to the SN field in ESP header. However recent …/
Warren Kumari
No Objection
Comment
(2019-10-15 for -07)
Not sent
I'll trust the Security ADs to determine the security properties of non-random IV's. I also have a small nit: 4. Implicit IV With the algorithms listed in Section 2, the 8 byte nonce MUST NOT repeat. I don't see what "8 byte" adds to this sentence -- sure, bits are cheap, but I spent a while trying to figure out if there is another, non-8 byte IV that can repeat, or that some other nonces are allowed to, etc.
Éric Vyncke
(was Discuss)
No Objection
Comment
(2019-10-16 for -08)
Sent
Thank you for addressing the DISCUSS and my COMMENTS. I leave my previous comments here for log purpose == COMMENTS == -- Section 5 -- C.1) "inside the SA Payload" probably worth being a little more descriptive here (for instance, "SA payload in the IKE exchange" ?). Also suggest to use "IKE Initiator Behavior" for the section title. -- Section 8 -- C.2) please use the usual text for IANA considerations (notably asking IANA to register as this is not this document that registers the codes). == NITS == In several places, s/8 byte nonce/8-byte nonce/
Adam Roach Former IESG member
Yes
Yes
(2019-10-15 for -07)
Sent
Thanks for the work on this mechanism. I have no substantive comments beyond those that have already been shared, although I do have some minor editorial comments. --------------------------------------------------------------------------- §2: > In some context, such as IoT, it may be preferable to avoid carrying Nit: "...some contexts..." --------------------------------------------------------------------------- §5: > An initiator supporting this feature SHOULD propose implicit IV > algorithms in the Transform Type 1 (Encryption Algorithm) > Substructure of the Proposal Substructure inside the SA Payload. Please expand "SA" on first use. --------------------------------------------------------------------------- > 7. Security Consideration Nit: "Considerations" --------------------------------------------------------------------------- §7: > extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is > no an easy way to derive unique IV from IKEv2 header fields. Nit: "...not an easy way..."
Alexey Melnikov Former IESG member
Yes
Yes
(for -07)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -07)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -07)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(for -07)
Not sent
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2019-10-16 for -08)
Sent
Thanks for addressing my Discuss! A few new comments on the -08: Abstract If we're going to differentiate between nonce and IV, I think that the algorithms require a unique but not necessarily unpredictable *nonce*, rather than *IV*. Section 2 nit: s/Initialize/Initialization/ nit: s/similar mechanism/similar mechanisms/ plural Section 7 My previous ballot was trying to note that the sender/receiver counters MUST be reset (as noted here) even without this document, as part of the core ESP requirements. So we don't need to use the "MUST" here as if it's a new requirement; we can just say that this behavior is already present due to the preexisting requirements
Deborah Brungard Former IESG member
No Objection
No Objection
(for -07)
Not sent
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -07)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -07)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -08)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -07)
Not sent
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -07)
Not sent