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

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 <daniel.migault@ericsson.com>
wrote:

>
>
> -----Original Message-----
> From: secdir <secdir-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> Sent: Monday, October 14, 2019 7:35 PM
> To: Magnus Nyström <magnusn@gmail.com>
> Cc: secdir@ietf.org
> Subject: Re: [secdir] Secdir review of draft-ietf-ipsecme-implicit-iv-07
>
> 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
>
> On Sun, Oct 13, 2019 at 10:46:30PM -0700, Magnus Nyström wrote:
> >  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?
>

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.

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

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.

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

> >
> > (Editorial: English grammar needs some updates/reviews)
> >
> > Thanks,
> > -- Magnus
>
> > _______________________________________________
> > secdir mailing list
> > secdir@ietf.org
> > https://www.ietf.org/mailman/listinfo/secdir
> > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>