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

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

Section 5.2 says:

   The first message each side transmits in each association always has
   message_seq = 0.  Whenever a new message is generated, the
   message_seq value is incremented by one.  When a message is
   retransmitted, the old message_seq value is reused, i.e., not
   incremented.  From the perspective of the DTLS record layer, the
   retransmission is a new record.  This record will have a new
   DTLSPlaintext.sequence_number value.

It should say:

   The first message each side transmits in each association always has
   message_seq = 0.  Whenever a new message is generated, the
   message_seq value is incremented by one.  Implementations MUST NOT
   allow message_seq to wrap, but instead MUST establish a new
   association, terminating the old association.  When a message is
   retransmitted, the old message_seq value is reused, i.e., not
   incremented.  From the perspective of the DTLS record layer, the
   retransmission is a new record.  This record will have a new
   DTLSPlaintext.sequence_number value.

Notes:

While pondering what to do about https://mailarchive.ietf.org/arch/msg/tls/6y8wTv8Q_IPM-PCcbCAmDOYg6bM/, I noticed that we don't say anything about message_seq wrapping. Since we don't reset that counter, it's not only possible for it to wrap, but for the peer to induce you to wrap it. This seems warrant some text. I borrowed the "MUST NOT allow ... to wrap, but instead ..." phrasing from Section 4.2.1.

Report New Errata