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