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

From: RFC Errata System <[email-masked]>
Date: Thu, 26 Jul 2018 11:29:23 -0700 (PDT)

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-masked]>

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Jul 2018 22:06:30 +0300

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 <[email-masked]> wrote:
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 26 Jul 2018 12:30:50 -0700

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-masked]> wrote:
> 
> This errata proposes to add the following sentence to section 4 of RFC 7634:
> 
> Looking back in RFC 7296, we have in section 3.3.5:
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tobias Brunner <[email-masked]>
Date: Fri, 27 Jul 2018 09:00:58 +0200

Hi Paul,

> Some note would be good because apparently strongswan insists of the
> KEY_LENGTH attribute they shouldn’t be there?

Yes, we did that incorrectly before 5.6.3 [1].  Since then the key
length attribute is omitted, but it's still possible to add a transform
with it to a proposal by using the chacha20poly1305compat keyword (for
compatibility with older releases).

Regards,
Tobias

[1] https://wiki.strongswan.org/versions/69

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 27 Jul 2018 09:16:58 -0500

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

I generally agree with this sentiment.  I would probably be willing to mark
as editorial/hold for document update in this case, though.  How would that
work for people?

-Ben

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 27 Jul 2018 17:59:22 +0300

Hi,

while this clarification wouldn't hurt if it were present in the RFC 7634,
I think that generally speaking it is redundant. RFC 7634 doesn't exist
in vacuum, it is expected that its readers are familiar with RFC 7296,
which has a clear rule that algorithms with fixed key size MUST NOT
include Key Length attribute. I see no reason to repeat this rule in every RFC
specifying new algorithm. It definitely wouldn't hurt if it were repeated,
but if it isn't then that is that. Go and read RFC 7296.

Regards,
Valery.

> > This errata proposes to add the following sentence to section 4 of RFC 7634
> <https://tools.ietf.org/html/rfc7634#section-4>:
> >
> > 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.
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Jul 2018 20:32:51 +0300

> "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec".

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...
-- 
[email-masked]