Subject: [IPsec] Benjamin Kaduk's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 14 Oct 2019 16:15:07 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ipsecme-implicit-iv-07: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please address the issue raised by the secdir reviewer where AES-CTR is
covered in the text but no codepoint allocated.

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

Section 2

nit: s/In some context/In some contexts/

   This document limits its scope to the algorithms mentioned above.
   Other algorithms with similar properties may later be defined to use
   this extension.

I'd suggest rewording this part; the "extension" here is just the
per-algorithm codepoint for the IIV variant of the encryption transform,
so what would be reused is probably better described as a "mechanism" or
similar than an "extension".

Section 4.

   With the algorithms listed in Section 2, the 8 byte nonce MUST NOT
   repeat.  The binding between a ESP packet and its nonce is provided

I suggest s/MUST NOT repeat/MUST NOT repeat for a given key/.
nit: s/a ESP/an ESP/

Section 4

   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.  Any other aspect (including using the Key
   Length attribute) of applying those ciphers with the new Transform
   Types defined in this document MUST be taken from the documents
   defining the use of the algorithms in ESP.

I suggest s/defines/modifies/; the whole paragraph is slightly confusing
to read and could perhaps be reworded to something like "This document
solely modifies the IV generation for the algorithms defined in
[RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for
ChaCha20-Poly1305.  All other aspects and parameters of those algorithms
are unchanged, and are used as defined in their respective
specifications."

Section 7

nit: the title should be "Security Considerations" plural.

I suggest to reiterate the RFC 4303 requirement for SAs to be closed or
rekeyed before sequence numbers grow too large to fit in 32 bits (for
"legacy" Sequence Number) or 64 bits for ESN.  This prevents sequence
number overlaps for the mundane point-to-point case.

   This document defines three new encryption transforms that use
   implicit IV.  Unlike most encryption transforms defined to date,
   which can be used for both ESP and IKEv2, these transforms are
   defined for ESP only and cannot be used in IKEv2.  The reason is that
   IKEv2 messages don't contain unique per-message value, that can be
   used for IV generation.  The Message-ID field in IKEv2 header is

nit: s/unique/a unique/
nit: s/value,/value/

---

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

Hi Benjamin,

Thank you for the review. 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 current version does not cover AES-CTR. However, 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.

Done

> similar than an "extension".

The following text has been replaced:
This document limits its scope to the algorithms mentioned above.
Other algorithms with similar properties may later be defined to use
similar mechanism.

> I suggest s/MUST NOT repeat/MUST NOT repeat for a given key/.

This has been changed accordingly.

> The proposed wording has been considered.

> The following text has been added:

The sender's counter and the receiver's counter MUST be reset (by
establishing a new SA and thus a new key) prior to the transmission of
the 2^32nd packet for an SA that uses a non extended Sequence Number
(respectively the 2^64nd packet for an SA that uses an Extended Sequence
Number). This prevents sequence number overlaps for the mundane
point-to-point case.

> Changed accordingly.

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