This seems right. I've opened https://github.com/tlswg/tls13-spec/issues/1409 for the -bis.
On Mon, Mar 2, 2026, at 16:17, 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/eid8794 > > -------------------------------------- > Type: Technical > Reported by: Loïc Ferreira <[email protected]> > > Section: 2.3 > > Original Text > ------------- > > Client Server > > ClientHello > + early_data > + key_share* > + psk_key_exchange_modes > + pre_shared_key > (Application Data*) --------> > ServerHello > + pre_shared_key > + key_share* > {EncryptedExtensions} > + early_data* > {Finished} > <-------- [Application Data*] > (EndOfEarlyData) > {Finished} --------> > [Application Data] <-------> [Application Data] > > Corrected Text > -------------- > > Client Server > > ClientHello > + early_data > + key_share* > + psk_key_exchange_modes > + pre_shared_key > (Application Data*) --------> > ServerHello > + pre_shared_key > + key_share* > {EncryptedExtensions} > + early_data* > {Finished} > <-------- [Application Data*] > (EndOfEarlyData*) > {Finished} --------> > [Application Data] <-------> [Application Data] > > Notes > ----- > Section 4.5 reads: "If the server sent an "early_data" extension in > EncryptedExtensions, the client MUST send an EndOfEarlyData message > after receiving the server Finished. If the server does not send an > "early_data" extension in EncryptedExtensions, then the client MUST NOT > send an EndOfEarlyData message." > Therefore, EndOfEarlyData is sent only if the server sends an > "early_data" extension and should be marked as situation-dependent. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will 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 > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
