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.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. > 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 >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
