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

[Yoav Nir <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 
> 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