Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)

Hi  Éric,

Thanks 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 Fri, Oct 11, 2019 at 5:16 AM Yoav Nir <ynir.ietf@gmail.com> wrote:

> Hi, Éric.  Please see inline.
>
> > On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker <noreply@ietf.org>
> wrote:
> >
> > Éric Vyncke 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:
> > ----------------------------------------------------------------------
> >
> > Thank you for the work put into this document. I am trusting the
> security AD to
> > check whether it is safe not to have a 'random' IV.
>
> I’m sure they will, but as an explanation, some algorithms require a
> random IV. Examples are AES in CBC mode. Other algorithms do not require a
> random IV, but do require a unique IV. The documents describing such
> algorithms recommend using either a simple counter or an LFSR to generate
> the IV. Examples are AES in counter mode and ChaCha20.  Our draft specifies
> IIV only for the latter kind of algorithms.
>
> > I have one trivial-to-fix
> > DISCUSS and a couple of COMMENTs.
> >
> > It is also unclear at first sight whether the 'nonce' built from the
> sequence
> > number is actually the IIV.
>
> Although they use the same fields, the literature tends to call the random
> kind an "Initialization Vector" and the must-not-repeat kind a “Nonce”.  In
> IPsec the field is called IV, so there is some confusion in the terms.
>

The current version tries to clarify that by being more consistent with the
IPsec terminology - at least I hope so. This is correct that what IPsec
calls nonce is also called IV in the literature.

>
> >
> > Regards,
> >
> > -éric
> >
> > == DISCUSS ==
> >
> > -- Section 1 --
> > D.1) Please use the RFC 8174 template ;)
>
> Right, our bad.  This is probably because this document has been making
> the rounds for over 3 years. Will fix.
>
> Fixed

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > == 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.
>
> OK
>
Fixed

>
> > -- 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).
>
> Yes, since we received early assignment I think we should go with the
> “IANA has assigned the following values…” text, and leave a reminder that
> the reference should be updated.
>
> Fixed

> >
> > == NITS ==
> >
> > In several places, s/8 byte nonce/8-byte nonce/
>
> Will fix.
>
> Fixed

> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>