RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Source of RFC: tls (sec)

Errata ID: 5874
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Mr Laurie Perrin
Date Reported: 2019-10-12

Section 5.1 says:

...

   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.

It should say:

...

   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.

Report New Errata