RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Note: This RFC has been updated by RFC 9853

Source of RFC: tls (sec)

Errata ID: 8107
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: David Benjamin
Date Reported: 2024-09-18

Section 7 says:

   During the handshake, ACK records MUST be sent with an epoch which is
   equal to or higher than the record which is being acknowledged.  Note
   that some care is required when processing flights spanning multiple
   epochs.  For instance, if the client receives only the ServerHello
   and Certificate and wishes to ACK them in a single record, it must do
   so in epoch 2, as it is required to use an epoch greater than or
   equal to 2 and cannot yet send with any greater epoch.
   Implementations SHOULD simply use the highest current sending epoch,
   which will generally be the highest available.  After the handshake,
   implementations MUST use the highest available sending epoch.

It should say:

   During the handshake, ACK records MUST be sent with an epoch which is
   equal to or higher than the record which is being acknowledged.  Note
   that some care is required when processing flights spanning multiple
   epochs.  For instance, if the client receives only the ServerHello
   and Certificate and wishes to ACK them in a single record, it must do
   so in epoch 2, as it is required to use an epoch greater than or
   equal to 2 and cannot yet send with any greater epoch.
   Implementations SHOULD simply use the highest current sending epoch,
   which will generally be the highest available.  The exception is that
   implementations MUST NOT send ACK records in epoch 1 (early data). If
   the highest current sending epoch is epoch 1 (early data),
   implementations MUST use epoch 0 (unencrypted) to send ACK records.
   After the handshake, implementations MUST use the highest available
   sending epoch.

Notes:

With the caveat that unencrypted ACKs are generally goofy (see https://mailarchive.ietf.org/arch/msg/tls/ZEj04LyL3hJXeK1nsiOBoB2vCsg/), the document currently believes they exist. As long as they exist, the rule in the text right now does not work. The server may reject 0-RTT, in which case it will never see epoch 1.

Report New Errata



Advanced Search