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

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 26 July 2024 04:31 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: <20240726043141.C8D793B874@rfcpa.rfc-editor.org>
Date: Thu, 25 Jul 2024 21:31:41 -0700
Message-ID-Hash: G3FDTMR27KX4DVXOX7O3D6BBM5MW7TUX
CC: tls@ietf.org, rfc-editor@rfc-editor.org
Precedence: list
Subject: [TLS][Technical Errata Reported] RFC9147 (8047)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/evllA_mM1Dz_4JpP4Ouf47_MwB4>

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

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

Section: 8

Original Text
-------------
As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
indicate that they are updating their sending keys. As with other
handshake messages with no built-in response, KeyUpdates MUST be
acknowledged. In order to facilitate epoch reconstruction
(Section 4.2.2), implementations MUST NOT send records with the new
keys or send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use).

Corrected Text
--------------
As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
indicate that they are updating their sending keys. As with other
handshake messages with no built-in response, KeyUpdates MUST be
acknowledged. Acknowledgements are used to both control
retransmission and transition to the next epoch. Implementations MUST
NOT send records with the new keys until the KeyUpdate and all
preceding messages have been acknowledged. This facilitates epoch
reconstruction (Section 4.2.2) and avoids too many epochs in active
use, by ensuring the peer has processed the KeyUpdate and started
receiving at the new epoch.

A KeyUpdate message terminates the post-handshake stream in an epoch.
After sending KeyUpdate in an epoch, implementations MUST NOT send
any new post-handshake messages in that epoch. Note that, if the
implementation has sent KeyUpdate but is waiting for an ACK, the next
epoch is not yet active. In this case, subsequent post-handshake
messages may not be sent until receiving the ACK.

Notes
-----
See https://mailarchive.ietf.org/arch/msg/tls/_ku3-YDcroNmG_QKZsYTtqYzC0M/ for discussion. This is option 7 from that discussion, as well as the fix for the other issue described at the top of https://mailarchive.ietf.org/arch/msg/tls/GYX_teYy5CTFiGCBgbQJQwv_Fj4/

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 (8047) RFC Errata System