Some note would be good because apparently strongswan insists of the KEY_LENGTH attribute they shouldn’t be there?
Sent from my phone > On Jul 26, 2018, at 12:06, Yoav Nir <[email protected]> wrote: > > This errata proposes to add the following sentence to section 4 of RFC 7634: > > 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: > > 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 > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
