RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Held for Document Update (1)

RFC 7634, "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec", August 2015

Source of RFC: ipsecme (sec)

Errata ID: 5441
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Andrew Cagney
Date Reported: 2018-07-26
Held for Document Update by: Paul Wouters
Date Held: 2022-04-11

Section 4 says:

   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).

It should say:

   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).

Paul Wouters:

I agree this should be added in future versions of this document to prevent implementation mistakes. However, not mentioning it here is not an error, so resolving this as Held for Document Update.

Report New Errata



Advanced Search