Re: [IPsec] [Technical Errata Reported] RFC7634 (5441)

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 <ynir.ietf@gmail.com> 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 <rfc-editor@rfc-editor.org> 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 <andrew.cagney@gmail.com>
>> 
>> 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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec