Skip to main content

Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)
RFC 8750


(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

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

-- 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 (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.



>  In some context, such as IoT, it may be preferable to avoid carrying

Nit: "...some contexts..."



>  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"



>  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 (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:


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