Hi Benjamin, Thank you 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 Mon, Oct 14, 2019 at 7:15 PM Benjamin Kaduk via Datatracker < [email protected]> wrote: > Benjamin Kaduk 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: > ---------------------------------------------------------------------- > > Please address the issue raised by the secdir reviewer where AES-CTR is > covered in the text but no codepoint allocated. > > > The current version does not cover AES-CTR. However, 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. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2 > > nit: s/In some context/In some contexts/ > Done > > This document limits its scope to the algorithms mentioned above. > Other algorithms with similar properties may later be defined to use > this extension. > > I'd suggest rewording this part; the "extension" here is just the > per-algorithm codepoint for the IIV variant of the encryption transform, > so what would be reused is probably better described as a "mechanism" or > similar than an "extension". > The following text has been replaced: This document limits its scope to the algorithms mentioned above. Other algorithms with similar properties may later be defined to use similar mechanism. > > Section 4. > > With the algorithms listed in Section 2, the 8 byte nonce MUST NOT > repeat. The binding between a ESP packet and its nonce is provided > > I suggest s/MUST NOT repeat/MUST NOT repeat for a given key/. > nit: s/a ESP/an ESP/ > This has been changed accordingly. > > Section 4 > > 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. Any other aspect (including using the Key > Length attribute) of applying those ciphers with the new Transform > Types defined in this document MUST be taken from the documents > defining the use of the algorithms in ESP. > > I suggest s/defines/modifies/; the whole paragraph is slightly confusing > to read and could perhaps be reworded to something like "This document > solely modifies the IV generation for the algorithms defined in > [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for > ChaCha20-Poly1305. All other aspects and parameters of those algorithms > are unchanged, and are used as defined in their respective > specifications." > > The proposed wording has been considered. > Section 7 > > nit: the title should be "Security Considerations" plural. > > I suggest to reiterate the RFC 4303 requirement for SAs to be closed or > rekeyed before sequence numbers grow too large to fit in 32 bits (for > "legacy" Sequence Number) or 64 bits for ESN. This prevents sequence > number overlaps for the mundane point-to-point case. > > The following text has been added: The sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet for an SA that uses a non extended Sequence Number (respectively the 2^64nd packet for an SA that uses an Extended Sequence Number). This prevents sequence number overlaps for the mundane point-to-point case. > This document defines three new encryption transforms that use > implicit IV. Unlike most encryption transforms defined to date, > which can be used for both ESP and IKEv2, these transforms are > defined for ESP only and cannot be used in IKEv2. The reason is that > IKEv2 messages don't contain unique per-message value, that can be > used for IV generation. The Message-ID field in IKEv2 header is > > nit: s/unique/a unique/ > nit: s/value,/value/ > > Changed accordingly. > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
