Thanks for letting us know, Andrei. That's rather depressing, but is fairly indicative that the errata report should be verified. (I think I will edit the "Notes" slightly when doing so, but am too tired to do a proper job tonight, so I'm holding off on actually marking the report as verified in the database for now.)
-Ben On Fri, Oct 25, 2019 at 06:13:18PM +0000, Andrei Popov wrote: > 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
