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

[Andrei Popov <[e-mail]>]

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 <[e-mail]> On Behalf Of RFC Errata System
Sent: Friday, October 11, 2019 9:22 PM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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

--------------------------------------
Type: Technical
Reported by: Mr Laurie Perrin <[e-mail]>

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

_______________________________________________
TLS mailing list
[e-mail]
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