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 <lper...@bellaliant.net> > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
