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 <david...@chromium.org> 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 _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
