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

[Tero Kivinen <[e-mail]>]

RFC Errata System writes:
> 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).

I think RFC7634 is clear that there is fixed-length key and RFC7296 is
clear how those fixed-length keys are negotiated (i.e., no Key Length
attribute), I think the current text is clear.

Your change would be techinically correct, but not needed, as the same
thing is already explained in general processing rules for the Key
Length attribute.

We could mark this as hold for document update, but I do not really
expect that there would be update of this document...
-- 
[e-mail]