Subject: [TLS] [Technical Errata Reported] RFC8446 (5874)

From: RFC Errata System <[email-masked]>
Date: Fri, 11 Oct 2019 21:21:49 -0700 (PDT)

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

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5874

--------------------------------------
Type: Technical
Reported by: Mr Laurie Perrin <[email-masked]>

Section: 5.1

Original Text
-------------
...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data MAY be sent, as they are potentially
   useful as a traffic analysis countermeasure.  Application Data
   fragments MAY be split across multiple records or coalesced into a
   single record.

Corrected Text
--------------
...

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data (i.e. those encapsulating an
   TLSInnerPlaintext record having a content field of length zero)
   MAY be sent, as they are potentially useful as a traffic analysis
   countermeasure. Application Data fragments MAY be split across
   multiple records or coalesced into a single record.

Notes
-----
In the interest of clarity, it may be prudent to specify the type of record for
which a fragment of length zero is being considered - it cannot be that of the
TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of
length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

Note: This comment also applies to previous versions of the TLS specification,
in particular with the introduction of the respective text concerning zero-length
fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content
field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment.

Note: The implications of zero-length records must be considered with respect to
potential vectors for denial of service.

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. 

--------------------------------------
RFC8446 (draft-ietf-tls-tls13-28)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date    : August 2018
Author(s)           : E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Oct 2019 16:55:21 -0700

> "The Transport Layer Security (TLS) Protocol Version 1.3".

I think at most this could be Editorial/Hold For Document Update, though
the added phrasing can probably be wordsmithed a bit more, perhaps "(i.e.,
TLSInnerPlaintext records of type application_data with zero-length
content)".

> length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

As an implementor I think it's hard to be confused, but maybe others feel
otherwise.

-Ben

---

From: Andrei Popov <[email-masked]>
Date: Fri, 25 Oct 2019 18:13:18 +0000

My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data records must still be encrypted and authenticated. Otherwise, MITM can inject arbitrary numbers of these.

However, the current language is vague enough that I've seen major SW vendors send (and accept) 0x17 0x03 0x03 0x00 0x00 and insist that this is RFC-compliant, because " Zero-length fragments of Application Data MAY be sent".

Therefore, I support clarifications in this area.

Cheers,

Andrei

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of RFC Errata System
Sent: Friday, October 11, 2019 9:22 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [TLS] [Technical Errata Reported] RFC8446 (5874)

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

--------------------------------------
You may review the report below and at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5874&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889&amp;sdata=61wnX96xJGd6FSLbxEQAJNvwERSVAMGoxxvjgb7DuRo%3D&amp;reserved=0

Section: 5.1

Original Text
-------------
....

Corrected Text
--------------
....

Notes
-----
In the interest of clarity, it may be prudent to specify the type of record for which a fragment of length zero is being considered - it cannot be that of the TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

Note: This comment also applies to previous versions of the TLS specification, in particular with the introduction of the respective text concerning zero-length fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment.

Note: The implications of zero-length records must be considered with respect to potential vectors for denial of service.

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. 

_______________________________________________
TLS mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889&amp;sdata=khYsCm5Wgkg98VESyOV8pNZCqEhA7EWLQhGE6%2FtOgos%3D&amp;reserved=0

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 25 Oct 2019 22:52:47 -0700

Thanks for letting us know, Andrei.
That's rather depressing, but is fairly indicative that the errata report
should be verified.  (I think I will edit the "Notes" slightly when doing
so, but am too tired to do a proper job tonight, so I'm holding off on
actually marking the report as verified in the database for now.)

-Ben