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 wrote: > Hi, Éric. Please see inline. > > > On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker > 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
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)
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" wrote: Hi, Éric. Please see inline. > On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker 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
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)
Hi, Éric. Please see inline. > On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker > 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
[IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)
É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 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. Regards, -éric == DISCUSS == -- Section 1 -- D.1) Please use the RFC 8174 template ;) -- 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. -- 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). == NITS == In several places, s/8 byte nonce/8-byte nonce/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
