Subject: [TLS] [Technical Errata Reported] RFC5246 (4382)

From: RFC Errata System <[email-masked]>
Date: Fri, 29 May 2015 04:39:32 -0700 (PDT)

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4382

--------------------------------------
Type: Technical
Reported by: Laura Corcoran <[email-masked]>

Section: 4.3

Original Text
-------------
In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[9];        /* 3 consecutive 3 byte vectors */

Corrected Text
--------------
In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[3];        /* 3 consecutive 3 byte vectors */

Notes
-----
The 9 in "Datum Data[9]" should be a 3 because Datum is a data type that consumes 3 bytes, so as written the Data vector is 27 bytes long. To make it a 9 byte vector the 9 must change to a 3.

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 (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date    : August 2008
Author(s)           : T. Dierks, E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 May 2015 05:38:51 -0700

I do not believe that this report is correct:

"A vector (single-dimensioned array) is a stream of homogeneous data
elements.
The size of the vector may be specified at documentation time or left
unspecified until runtime. In either case, the length declares the number of
bytes, not the number of elements, in the vector."

On Fri, May 29, 2015 at 4:39 AM, RFC Errata System <
[email-masked]> wrote:

> The 9 in "Datum Data[9]" should be a 3 because Datum is a data type that
> consumes 3 bytes, so as written the Data vector is 27 bytes long. To make
> it a 9 byte vector the 9 must change to a 3.
>
> Instructions:
> -------------

---

From: "Corcoran, Laura S" <[email-masked]>
Date: Fri, 29 May 2015 13:35:52 +0000

It seems that Data is not a vector, but an array of vectors. Wouldn't that make a difference here?

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Friday, May 29, 2015 8:39 AM
To: RFC Errata System
Cc: Tim Dierks; Stephen Farrell; Kathleen Moriarty; Sean Turner; Joseph Salowey; Corcoran, Laura S; [email-masked]
Subject: Re: [Technical Errata Reported] RFC5246 (4382)

"A vector (single-dimensioned array) is a stream of homogeneous data elements.
The size of the vector may be specified at documentation time or left unspecified until runtime. In either case, the length declares the number of bytes, not the number of elements, in the vector."

On Fri, May 29, 2015 at 4:39 AM, RFC Errata System <[email-masked]> wrote:

	
	
	Section: 4.3
	
	Original Text
	-------------

	Corrected Text
	--------------

	Notes
	-----
	
	Instructions:
	-------------

---

From: Benjamin Beurdouche <[email-masked]>
Date: Fri, 29 May 2015 18:10:10 +0200

If the value is the number of bytes it is 9.
But I agree it is unclear at first read, maybe we should fix it ?

B.

> On 29 May 2015, at 15:35, Corcoran, Laura S <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Benjamin Beurdouche <[email-masked]>
Date: Fri, 29 May 2015 18:11:11 +0200

I meant, fix it in the TLS 1.3 spec…

> On 29 May 2015, at 18:10, Benjamin Beurdouche <[email-masked]> wrote:
>

---

From: Dave Garrett <[email-masked]>
Date: Fri, 29 May 2015 12:12:11 -0400

Based on the definition, the current text is correct. I think the definition is confusing and not particularly helpful, but it's correct.

opaque Datum[3];  // 3 bytes
Datum Data[9];      // 9 bytes
Datum Data<3>;   // 9 bytes

The second notation is only used in RFC5246 in the specification of the SSL2 CLIENT-HELLO for "cipher_specs". Relevant lines quoted:

>      uint8 V2CipherSpec[3];
[...]
>          V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
[...]
>
>   cipher_spec_length
>      This field is the total length of the field cipher_specs.  It
>      cannot be zero and MUST be a multiple of the V2CipherSpec length
>      (3).

The length definition does say it's the total length of the array, not number of elements, so it appears to be using the notation correctly.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Fri, 29 May 2015 12:18:27 -0400

Bah. Confusing, yes... Correcting myself:

opaque Datum[3];  // 3 bytes
Datum Data[9];      // 9 bytes
Datum Data<9>;   // 9 bytes

The variable length uses the same notation. Quoting the example from the spec:

>      uint16 longer<0..800>;
>            /* zero to 400 16-bit unsigned integers */

I would not be against throwing around some warnings that the length is always the sizeof and not the array length. It's not wrong, though.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 May 2015 09:53:27 -0700

> I would not be against throwing around some warnings that the length is always the sizeof and not the array length. It's not wrong, though.

ASN.1 doesn't suffer from this problem.  I wonder if it's worth
translating the spec to ASN.1 and (probably) PER?

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 29 May 2015 17:05:46 +0000

> ASN.1 doesn't suffer from this problem.  I wonder if it's worth translating the
> spec to ASN.1 and (probably) PER?

ASN.1 would be interesting, but I don't believe PER is the right thing as we'd end up defining a completely new on-the-wire protocol for TLS 1.3.  Instead you'd have to define something like TER, the TLS Encoding Rules.

FWIW, about a year ago I wrote a parser for the TLS-RFC grammar: https://github.com/richsalz/tlsparser

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 29 May 2015 17:15:36 +0000

ASN.1 would be good - as long as there's a reasonably debugged parser/encoder, and a language subset is agreed upon. I'm for it, based on my prior experience with ASN.1 (including implementing it).

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 May 2015 10:15:57 -0700

> ASN.1 would be interesting, but I don't believe PER is the right thing as we'd end up defining a completely new on-the-wire protocol for TLS 1.3.  Instead you'd have to define something like TER, t…

I'm not certain about that.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 May 2015 10:23:26 -0700

I wouldn't be excited about making this change at this time.

I agree that the spec could be clearer about the syntax.
Also, a cursory look suggests that we never use fixed-size arrays
of fixed-size objects, so maybe we can just remove this example.

-Ekr

On Fri, May 29, 2015 at 10:15 AM, Martin Thomson <[email-masked]>
wrote:

> > ASN.1 would be interesting, but I don't believe PER is the right thing
> as we'd end up defining a completely new on-the-wire protocol for TLS 1.3.
> Instead you'd have to define something like TER, the TLS Encoding Rules.
>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 29 May 2015 17:28:08 +0000

If we change the "presentation language" used by TLS specs, then we'll end up with two different, inconsistent notations. Anyone implementing TLS 1.3 will then need to understand the new "presentation language", and also be well-versed in the old one (e.g. so that they can implement existing extensions described using the old notation). This seems more confusing than what we have now.

But if we do end up selecting a new notation, let's at least make sure correct parsing code can be auto-generated from it.

Cheers,

Andrei

---

From: Dave Garrett <[email-masked]>
Date: Fri, 29 May 2015 13:38:39 -0400

Agreed. Redoing the whole thing in a new syntax could be mistake prone for both the spec and implementations. The simplest route would be to remove unhelpful examples and narrow the syntax on what is actually needed.

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 29 May 2015 17:52:07 +0000

> I'm not certain about that.

For example, enumerations are serialized by sending their "index value", not their true value.