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

Errata ID: 8051
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: David Benjamin
Date Reported: 2024-07-26

Section 6.1 says:

   *  Epoch value (2) is used for messages protected using keys derived
      from [sender]_handshake_traffic_secret.  Messages transmitted
      during the initial handshake, such as EncryptedExtensions,
      CertificateRequest, Certificate, CertificateVerify, and Finished,
      belong to this category.  Note, however, that post-handshake
      messages are protected under the appropriate application traffic
      key and are not included in this category.

It should say:

   *  Epoch value (2) is used for messages protected using keys derived
      from [sender]_handshake_traffic_secret.  Messages transmitted
      during the handshake, such as EncryptedExtensions,
      CertificateRequest, Certificate, CertificateVerify, and Finished,
      belong to this category.  Note, however, that post-handshake
      messages are protected under the appropriate application traffic
      key and are not included in this category.

Notes:

The discussion of "initial handshake" appears to be a remnant of DTLS 1.2, where a single connection may have multiple handshakes via renegotiation. In (D)TLS 1.3, there is only one handshake per connection.

Looking to RFC 8446, the only references to "initial handshake" refer to resumption, talking about the handshake in the initial connection, vs the handshake in resumption connections. This reference is not trying to distinguish initial vs resumption handshakes, so the use of "initial handshake" is a bit confusing. I believe plain "handshake" is the right terminology.

NB: There are two other references to "initial handshake", one in the diagram in Section 8, and another in Section 11. I believe they too should be switched to "handshake".

Report New Errata