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

Note: This ballot was opened for revision 07 and is now closed.

(Alexey Melnikov) Yes

(Adam Roach) Yes

Comment (2019-10-15 for -07)
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..."

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2019-10-15 for -07)
** 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 …/

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-10-16 for -08)
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

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-10-15 for -07)
No email
send info
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.

(Mirja Kühlewind) No Objection

Barry Leiba No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke (was Discuss) No Objection

Comment (2019-10-16 for -08)
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/

Magnus Westerlund No Objection