[TLS] [Errata Held for Document Update] RFC8446 (5874)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 05 April 2024 12:46 UTC

To: lperrin@bellaliant.net, ekr@rtfm.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: paul.wouters@aiven.io, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240405124618.D6B4A192F799@rfcpa.amsl.com>
Date: Fri, 05 Apr 2024 05:46:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-002Yqljz9PmFuys55jpi8QXdtY>
Subject: [TLS] [Errata Held for Document Update] RFC8446 (5874)
Precedence: list

The following errata report has been held for document update 
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

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Mr Laurie Perrin <lperrin@bellaliant.net>
Date Reported: 2019-10-12
Held by: Paul Wouters (IESG)

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.

Paul Wouters(AD): Currently discussed at:

https://github.com/tlswg/tls13-spec/issues/1346
https://github.com/tlswg/tls13-spec/pull/1347

--------------------------------------
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
Stream              : IETF
Verifying Party     : IESG

[TLS] [Errata Held for Document Update] RFC8446 (… RFC Errata System