Subject: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07

From: Magnus Nyström <[email-masked]>
Date: Sun, 13 Oct 2019 22:46:30 -0700

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines a mechanism to save on bandwidth in ESP connections
when certain ciphers have been negotiated by using implicit IVs. The
savings are limited to 8 bytes for the current version of this document.

   - Section 2 mentions AES-CCM, AES-CTR, AES-GCM and ChaCha. For all of
   these ciphers, an 8-byte nonce is used. The mechanism to make the IV
   implicit is by coupling it to the sequence number. Yet, Section 4 gives two
   examples of sequence numbers, one  of 4 bytes and one of 8 bytes. This is
   confusing, presumably only the extended sequence number is usable?
   - Also, while the Abstract says the memo offers a mechanism to save on
   the explicit IV also for AES-CTR, and Section 2 includes AES-CTR in its
   description, Section 4 explicitly states that only AES-CCM, AES-GCM and
   ChaCha are subject of the optimization in this memo. This is also
   confusing. Why including AES-CTR in the memo at all if it isn't covered? At
   the very least it seems the Abstract should be updated.
   - It would be very helpful and useful to include an example of a
   handshake with an IIV and the resulting IV in an Appendix; this could
   assist implementors to get things right.

(Editorial: English grammar needs some updates/reviews)

Thanks,
-- Magnus

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 14 Oct 2019 16:35:10 -0700

Hi Magnus,

Thanks for this review -- I filed a Discuss point about the inconsistency
between the text and the codepoints for whether AES-CTR is covered.

-Ben

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

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

Hi Magnus,

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

On Tue, Oct 15, 2019 at 8:53 AM Daniel Migault <[email-masked]>
wrote:

>
>
> -----Original Message-----
> From: secdir <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: Monday, October 14, 2019 7:35 PM
> To: Magnus Nyström <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07
>
> Hi Magnus,
>
> > These comments were written primarily for the benefit of the security
> > area directors.  Document editors and WG chairs should treat these
> > comments just like any other last call comments.
> >
> > This document defines a mechanism to save on bandwidth in ESP
> > connections when certain ciphers have been negotiated by using
> > implicit IVs. The savings are limited to 8 bytes for the current version
> of this document.
> >
> >
> >

I think that is correct. AES-GCM, AES-CCM and Chach20-poly1305 defined for
IPsec are taking a nonce as an input value and this nonce takes the ESP.IV
field as input to be computed. In our case ESP.IV is 8 byte long. The
document defines how ESP.IV value can be generated form the sequence
number. As the sequence number can be extended or not we define two ways to
generate the ESP.IV value. In both cases, the result is always a 8 byte
value.

We will update section 2 to make a clear distinction between IV and nonce.

Some more explanations:
IPsec/ESP:
ESP RF4303 defines the IV field whose length is negotiated with the
algorithm.

AES-CCM:
SP800-38c defines AES-CCM and RFC4309 defines the use of AES-CCM in IPsec.
In both specifications, the 'none' is described as an input parameter.
RFC4309 defines this nonce as a function of a salt and the ESP.IV field.
RFC4309 defines ESP.IV field as 8 byte long.
The current document defines how to generates the IV from the sequence
numbers. The document defines two ways to generate the IV depending if
extended sequence number is used or not and teh resulting IV is always 8
byte long.

AES-GCM:
SP800-38D defines AES-GCM and RFC4106 defines the use of AES-GCM in IPSec.
In both specification GCM needs an input designated as IV. To distinguish
that IV (GMC.IV) and the field defined by ESP, the IV used by GCM is
designated in RFC4106 as nonce. That is GCM.IV = 'nonce' and ESP.IV = IV.
This brings us  in the previous case of CCM where the nonce is an input
parameter for GCM. Similarly to CCM the nonce is a function of a salt and
ESP.IV which is 8 byte long.

Chacha20-Poly1305:
RFC7539 defines chacha20poly1305 and RFC7634 defines the use of
Chacha20poly in IPsec/ESP. In both specifications the nonce is described as
an input parameter. The nonce is described as a function of the ESP.IV and
a salt with ESP.IV of 8 byte long. This brings us  in the previous case of
CCM where the nonce is an input parameter for GCM. Similarly to CCM the
nonce is a function of a salt and ESP.IV which is 8 byte long.

> >    the very least it seems the Abstract should be updated.

The reason we did not assigned a code point for AES-CTR was that none was
really asking for that code point. In addition and we did not want to
assign a code point for an algorithm that is not recommended by RFC8221.
(MAY be implemented status). AES-CTR is not AEAD and we would not like to
encourage its use. On the other hand, the same mechanism applies.

We will remove CTR from the document and that the same mechanism can be
applied is caught by the following sentence:
""
 This document limits its scope to the algorithms mentioned above.
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.

> >    assist implementors to get things right.
I am unclear what would be represented in the exchange. The IKEv2 exchange
does not really differ from a the regular negotiation of a specific
encryption algorithm. The impact is mostly affecting how the encryption,
decryption is performed. I believe that the clarification with IV/Nonce
will address this concern. However, if there is anything specific you would
like to see in the appendix, please feel free to let us know.