This errata proposes to add the following sentence to section 4 of RFC 7634 <https://tools.ietf.org/html/rfc7634#section-4>:
As with other transforms that use a fixed-length key, the Key Length attribute MUST NOT be specified. This sentence is correct. If this came up as a suggestion during WG processing or during LC, I think we would add it. Looking back in RFC 7296, we have in section 3.3.5 <https://tools.ietf.org/html/rfc7296#section-3.3.5>: o The Key Length attribute MUST NOT be used with transforms that use a fixed-length key. For example, this includes ENCR_DES, ENCR_IDEA, and all the Type 2 (Pseudorandom Function) and Type 3 (Integrity Algorithm) transforms specified in this document. It is recommended that future Type 2 or 3 transforms do not use this attribute. And RFC 7634 says: o The encryption key is 256 bits. Given that, I don’t think there is any chance for a conscientious implementer to make the mistake of including the Key Length attribute. I don’t believe adding clarifying text is a proper use of the errata system. At best it should be marked as editorial and held for document update, if not rejected outright. Yoav > On 26 Jul 2018, at 21:29, RFC Errata System <[email protected]> wrote: > > The following errata report has been submitted for RFC7634, > "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol > (IKE) and IPsec". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5441 > > -------------------------------------- > Type: Technical > Reported by: Andrew Cagney <[email protected]> > > Section: 4 > > Original Text > ------------- > When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or > IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the > transform substructure of the SA payload as the ENCR (type 1) > transform ID. As with other AEAD algorithms, INTEG (type 3) > transform substructures MUST NOT be specified, or just one INTEG > transform MAY be included with value NONE (0). > > Corrected Text > -------------- > When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or > IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the > transform substructure of the SA payload as the ENCR (type 1) > transform ID. > As with other transforms that use a fixed-length key, the Key Length > attribute MUST NOT be specified. > As with other AEAD algorithms, INTEG (type 3) > transform substructures MUST NOT be specified, or just one INTEG > transform MAY be included with value NONE (0). > > Notes > ----- > Reading both RFC7634 and RFC7539 there seems to be a single fixed-length key > of 256-bits. > Hence, I think https://tools.ietf.org/html/rfc7296#section-3.3.5: > o The Key Length attribute MUST NOT be used with transforms that use > a fixed-length key. For example, this includes ENCR_DES, > ENCR_IDEA,... > applies (my intent is to clarify this). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7634 (draft-ietf-ipsecme-chacha20-poly1305-12) > -------------------------------------- > Title : ChaCha20, Poly1305, and Their Use in the Internet Key > Exchange Protocol (IKE) and IPsec > Publication Date : August 2015 > Author(s) : Y. Nir > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
