HI Roman, Thanks for the feed back.
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 Tue, Oct 15, 2019 at 8:11 AM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-ipsecme-implicit-iv-07: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** I support the DISCUSS position held by Ben Kaduk. (Derived from Magnus > Nystrom’s SECDIR review) The abstract, Section 2, Section 4 and Section 7 > make > references to AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 (four > algorithms). However, Section 4 also states “This document solely defines > the > IV generation of the algorithms defined in [RFC4106] for AES-GCM, > [RFC4309] for > AES-CCM and [RFC7634] for ChaCha20-Poly1305” (i.e., AES-CTR is missing). > Likewise, no new code point is assigned for AES-CTR in Section 8. If > AES-CTR > is not in scope, then please don’t mention it in the draft. If it was > missed > from Section 4 and 8, please add it. > The same construction applies to CTR but none pushed for having it. As we are moving to AEAD encryption we did not feel the need to assign a code point that was not used for sure. We remove CTR and the text above includes CTR is there is a need to assign some code points in the future: """ Other algorithms with similar properties may later be defined to use similar mechanism. """ That said, re-reading the document, we provide some explanation on CBC, so the current version explains why we are excluding CTR. This could be also removed, if you prefer, I do not have strong preferences. > ** Section 7. I’m having difficulty reconciling these two sentences: > > (1) Nonce generation for these algorithms has not been explicitly > defined.” > > (2) This document provides an explicit and normative way to generate IVs. > > Isn’t this text saying the Nonce = Sequence number = IV? > Though I admit we could have been clearer and we will clarify the text. I have also provided more details in the response to Magnus - which was not sent at the time I am writing this response. The algorithms take a nonce as input. This nonce when used with IPsec is generated based on the IV value found in each ESP packet. Our document details how the IV value can be derived when the ESP packet does not provide the IV. In this case, the value associated to the IV is derived from the sequence number read in the ESP packet. Note also that GCM as defined by SP800-38D defines what we call nonce as IV, but RFC 4106 clarifies that GCM.IV = nonce. ** Section 7. Editorial. s/the IV is not allowed being repeated for one > particular key./the IV is not allowed to be repeated for a particular key../ > > Fixed > ** Section 7. Editorial. s/The Message-ID field in IKEv2 header is > somewhat > counterpart of SN field in ESP header, but recent …/The Message-ID field in > IKEv2 header is similar to the SN field in ESP header. However recent …/ > > Fixed as well. > > _______________________________________________ > 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
