The following errata report has been submitted for RFC9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8066 -------------------------------------- Type: Technical Reported by: David Benjamin <david...@chromium.org> Section: 5 Original Text ------------- DTLS implementations do not use the TLS 1.3 "compatibility mode" described in Appendix D.4 of [TLS13]. DTLS servers MUST NOT echo the "legacy_session_id" value from the client and endpoints MUST NOT send ChangeCipherSpec messages. With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.3. Corrected Text -------------- DTLS implementations do not use the TLS 1.3 "compatibility mode" described in Appendix D.4 of [TLS13]. DTLS endpoints MUST NOT send ChangeCipherSpec messages when negotiating DTLS 1.3. Additionally, the "legacy_session_id_echo" field of the ServerHello message, described in Section 4.1.3 of [TLS13], MUST be empty in DTLS 1.3. DTLS 1.3 servers MUST NOT echo the "legacy_session_id" value from the ClientHello. DTLS 1.3 clients MUST abort the handshake with an "illegal_parameter" alert if the field is not empty. This applies even if the "legacy_session_id" field of the ClientHello is non-empty due to a cached session ID set by a pre-DTLS 1.3 server (see Section 5.3). With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.3. Notes ----- DTLS 1.3's continuity with DTLS 1.2 makes this a little subtle. First, a DTLS-1.3-capable endpoint may well need to send ChangeCipherSpec if it negotiates DTLS 1.3, so add a small clarification here. More importantly, the changes described here do more than disable the provisions of Appendix D.4. Compatibility mode is only half-negotiated in TLS 1.3, with the ServerHello provisions being unconditional from Section 4.1.3 of RFC 8446: legacy_session_id_echo: The contents of the client's legacy_session_id field. Note that this field is echoed even if the client's value corresponded to a cached pre-TLS 1.3 session which the server has chosen not to resume. A client which receives a legacy_session_id_echo field that does not match what it sent in the ClientHello MUST abort the handshake with an "illegal_parameter" alert. In particular, even if we disable the provisions of D.4, a DTLS 1.3 client may still send a non-empty legacy_session_id if it is offering a DTLS 1.2 session. That means matching legacy_session_id and always being empty aren't *quite* the same. The old text overrode 4.1.3's server text (though without citing the section) but not the client text. Leaving the client text as-is will lead to an interop problem in the 1.2 resumption case above, so let's make that clearer. Best also to cite the section we're overriding. 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. -------------------------------------- RFC9147 (draft-ietf-tls-dtls13-43) -------------------------------------- Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Publication Date : April 2022 Author(s) : E. Rescorla, H. Tschofenig, N. Modadugu Category : PROPOSED STANDARD Source : Transport Layer Security Stream : IETF Verifying Party : IESG _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
