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

[RFC Errata System <[e-mail]>]

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

--------------------------------------
Type: Technical
Reported by: David Benjamin <[e-mail]>

Section: 8

Original Text
-------------
   With a 128-bit key as in AES-128, rekeying 2^64 times has a high
   probability of key reuse within a given connection.  Note that even
   if the key repeats, the IV is also independently generated.  In order
   to provide an extra margin of security, sending implementations MUST
   NOT allow the epoch to exceed 2^48-1.  In order to allow this value
   to be changed later, receiving implementations MUST NOT enforce this
   rule.  If a sending implementation receives a KeyUpdate with
   request_update set to "update_requested", it MUST NOT send its own
   KeyUpdate if that would cause it to exceed these limits and SHOULD
   instead ignore the "update_requested" flag.  Note: this overrides the
   requirement in TLS 1.3 to always send a KeyUpdate in response to
   "update_requested".

Corrected Text
--------------
   With a 128-bit key as in AES-128, rekeying 2^64 times has a high
   probability of key reuse within a given connection.  Note that even
   if the key repeats, the IV is also independently generated.  In order
   to provide an extra margin of security, sending implementations MUST
   NOT allow the epoch to exceed 2^48-1.  If a sending implementation
   receives a KeyUpdate with request_update set to "update_requested",
   it MUST NOT send its own KeyUpdate if that would cause it to exceed
   these limits and SHOULD instead ignore the "update_requested" flag.
   Note: this overrides the requirement in TLS 1.3 to always send a
   KeyUpdate in response to "update_requested".

   Exceeding the above limit is not possible with the key update
   mechanisms defined in this document.  After the handshake, each epoch
   change consumes a message_seq value, which is limited to 2^16-1. Both
   sending and receiving implementations MAY instead enforce an epoch
   limit of 2^16-1.  In this case, the implementation MUST check for
   this limit, if reached, terminate the association. In some cases, it
   is otherwise possible for the epoch number to reach 2^16+1.

Notes
-----
See https://mailarchive.ietf.org/arch/msg/tls/6y8wTv8Q_IPM-PCcbCAmDOYg6bM/ for details. Strictly speaking, as noted in the corrected text, the maximum epoch value does not *quite* fit in 2^16. However, bumping the implementation's size just to accommodate two more epochs seems pointless.

The 2^16-1 value comes from the minimum number of messages in the sending side of a handshake, 2 (ClientHello + Finished as a client). Post-handshake, epochs begin at 3. From there, we can send at most 2^16-2 KeyUpdates, ending at epoch 2^16-2+3 = 2^16+1.

In particular, I believe NSS stores the epoch as 16-bit in DTLS 1.3. We plan to do so in BoringSSL as well. It is a natural choice because epochs are 16-bit in DTLS 1.2. Without this erratum, I believe NSS, and any other implementation making this choice, is non-compliant because the spec says the receiver "MUST NOT enforce this rule".

To that end, I've deleted that sentence because we cannot *actually* change this value. DTLS 1.3 tried, but failed, to enable a larger epoch space. Maybe we can try again in DTLS 1.4, or decide we don't care and properly revert to 16-bit.

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