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