[TLS][Technical Errata Reported] RFC9147 (8066)

[RFC Errata System <[e-mail]>]

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 <[e-mail]>

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