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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2 nit: s/In some context/In some contexts/ 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". 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/ 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." 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. 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/ _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
