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

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 26 July 2024 04:46 UTC

To: ekr@rtfm.com, hannes.tschofenig@arm.com, Nagendra@cs.stanford.edu, debcooley1@gmail.com, paul.wouters@aiven.io, joe@salowey.net, sean+ietf@sn3rd.com, durumcrustulum@gmail.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240726044643.2E1433B873@rfcpa.rfc-editor.org>
Date: Thu, 25 Jul 2024 21:46:43 -0700
Message-ID-Hash: HKKBNIFTPKYQEHEWPYPYDTFTV7BHB5GZ
CC: tls@ietf.org, rfc-editor@rfc-editor.org
Precedence: list
Subject: [TLS][Technical Errata Reported] RFC9147 (8048)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/U1D_IG1fBb0U6PDexV7x8Y6LHQg>

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/eid8048

--------------------------------------
Type: Technical
Reported by: David Benjamin <davidben@chromium.org>

Section: 5.2

Original Text
-------------
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.

Corrected Text
--------------
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.

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

[TLS][Technical Errata Reported] RFC9147 (8048) RFC Errata System