Yoav,
Thank you for your quick reply, the explanations and the actions. Obviously, I
will clear my DISCUSS upon a new revision of the document.
About the nonce / IIV, may I suggest to add the explanation below to the
terminology section?
Regards
-éric
PS: thank you for using a É in my first name ;-)
On 11/10/2019, 11:17, "iesg on behalf of Yoav Nir" <iesg-boun...@ietf.org on
behalf of ynir.i...@gmail.com> wrote:
Hi, Éric. Please see inline.
> On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker <nore...@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.
>
> 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.
> ----------------------------------------------------------------------
> 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
> -- 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.
>
> == NITS ==
>
> In several places, s/8 byte nonce/8-byte nonce/
Will fix.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
