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

[Benjamin Kaduk <[e-mail]>]

On Fri, Oct 11, 2019 at 09:21:49PM -0700, RFC Errata System wrote:
> 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 <[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.

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)".

> 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.

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

-Ben

> 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