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