Subject: [IPsec] Roman Danyliw's No Objection on draft-ietf-ipsecme-implicit-iv-07: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 15 Oct 2019 05:11:42 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-ipsecme-implicit-iv-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** 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 …/

---

From: Daniel Migault <[email-masked]>
Date: Tue, 15 Oct 2019 13:52:36 -0400

HI Roman,

Thanks for the feed back.

Please find my response inline as well as the updated text:
https://github.com/mglt/draft-mglt-ipsecme-implicit-iv/blob/master/draft-ietf-ipsecme-implicit-iv.txt

We will probably publish the new version by tomorrow.

Yours,
Daniel

> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/

The same construction applies to CTR but none pushed for having it. As we
are moving to AEAD encryption we did not feel the need to assign a code
point that was not used for sure.

We remove CTR and the text above includes CTR is there is a need to assign
some code points in the future:
"""
Other algorithms with similar properties may later be defined to use
similar mechanism.
"""

That said, re-reading the document, we provide some explanation on CBC, so
the current version explains why we are excluding CTR. This could be also
removed, if you prefer, I do not have strong preferences.

> Isn’t this text saying the Nonce = Sequence number = IV?

Though I admit we could have been clearer and we will clarify the text. I
have also provided more details in the response to Magnus - which was not
sent at the time I am writing this response. The algorithms take a nonce as
input. This nonce when used with IPsec is generated based on the IV value
found in each ESP packet. Our document details how the IV value can be
derived when the ESP packet does not provide the IV. In this case, the
value associated to the IV is derived from the sequence number read in the
ESP packet.

Note also that GCM as defined by SP800-38D defines what we call nonce as
IV, but RFC 4106 clarifies that GCM.IV = nonce.

> Fixed

>  Fixed as well.

>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>