RFC 9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", April 2022

Errata ID: 8066
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Benjamin
Date Reported: 2024-08-06

Section 5 says:

   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.

It should say:

   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.

Report New Errata