My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data records must still be encrypted and authenticated. Otherwise, MITM can inject arbitrary numbers of these.
However, the current language is vague enough that I've seen major SW vendors send (and accept) 0x17 0x03 0x03 0x00 0x00 and insist that this is RFC-compliant, because " Zero-length fragments of Application Data MAY be sent". Therefore, I support clarifications in this area. Cheers, Andrei -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of RFC Errata System Sent: Friday, October 11, 2019 9:22 PM To: e...@rtfm.com; r...@cert.org; ka...@mit.edu; c...@heapingbits.net; j...@salowey.net; sean+i...@sn3rd.com Cc: lper...@bellaliant.net; tls@ietf.org; rfc-edi...@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC8446 (5874) 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5874&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889&sdata=61wnX96xJGd6FSLbxEQAJNvwERSVAMGoxxvjgb7DuRo%3D&reserved=0 -------------------------------------- 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. 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. 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889&sdata=khYsCm5Wgkg98VESyOV8pNZCqEhA7EWLQhGE6%2FtOgos%3D&reserved=0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
