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/eid8107 -------------------------------------- Type: Technical Reported by: David Benjamin <david...@chromium.org> Section: 7 Original Text ------------- During the handshake, ACK records MUST be sent with an epoch which is equal to or higher than the record which is being acknowledged. Note that some care is required when processing flights spanning multiple epochs. For instance, if the client receives only the ServerHello and Certificate and wishes to ACK them in a single record, it must do so in epoch 2, as it is required to use an epoch greater than or equal to 2 and cannot yet send with any greater epoch. Implementations SHOULD simply use the highest current sending epoch, which will generally be the highest available. After the handshake, implementations MUST use the highest available sending epoch. Corrected Text -------------- During the handshake, ACK records MUST be sent with an epoch which is equal to or higher than the record which is being acknowledged. Note that some care is required when processing flights spanning multiple epochs. For instance, if the client receives only the ServerHello and Certificate and wishes to ACK them in a single record, it must do so in epoch 2, as it is required to use an epoch greater than or equal to 2 and cannot yet send with any greater epoch. Implementations SHOULD simply use the highest current sending epoch, which will generally be the highest available. The exception is that implementations MUST NOT send ACK records in epoch 1 (early data). If the highest current sending epoch is epoch 1 (early data), implementations MUST use epoch 0 (unencrypted) to send ACK records. After the handshake, implementations MUST use the highest available sending epoch. Notes ----- With the caveat that unencrypted ACKs are generally goofy (see https://mailarchive.ietf.org/arch/msg/tls/ZEj04LyL3hJXeK1nsiOBoB2vCsg/), the document currently believes they exist. As long as they exist, the rule in the text right now does not work. The server may reject 0-RTT, in which case it will never see epoch 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 mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
