Hi Paul, We consider the proposed change from "initial handshake” to “handshake” in this erratum report to be above editorial, so we changed the Type to “Technical”. As Stream Approver, please review and set the Status and Type accordingly (see the definitions at https://www.rfc-editor.org/errata-definitions/).
Also, as the submitter notes, "initial handshake” appears three times in the document (Sections 6.1, 8, and 11). Perhaps this erratum report should be updated to GLOBAL and only include the original and corrected term in the OLD/NEW text rather than sentences from just one of the sections affected. We are happy to make this change if that would be helpful. Just let us know. You may review the report at: https://www.rfc-editor.org/errata/eid8051 Information on how to verify errata reports can be found at: https://www.rfc-editor.org/how-to-verify/ Further information on errata can be found at: https://www.rfc-editor.org/errata.php Thank you, RFC Editor/rv > On Jul 25, 2024, at 10:22 PM, RFC Errata System <[email protected]> > wrote: > > 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/eid8051 > > -------------------------------------- > Type: Editorial > Reported by: David Benjamin <[email protected]> > > Section: 6.1 > > Original Text > ------------- > * Epoch value (2) is used for messages protected using keys derived > from [sender]_handshake_traffic_secret. Messages transmitted > during the initial handshake, such as EncryptedExtensions, > CertificateRequest, Certificate, CertificateVerify, and Finished, > belong to this category. Note, however, that post-handshake > messages are protected under the appropriate application traffic > key and are not included in this category. > > Corrected Text > -------------- > * Epoch value (2) is used for messages protected using keys derived > from [sender]_handshake_traffic_secret. Messages transmitted > during the handshake, such as EncryptedExtensions, > CertificateRequest, Certificate, CertificateVerify, and Finished, > belong to this category. Note, however, that post-handshake > messages are protected under the appropriate application traffic > key and are not included in this category. > > Notes > ----- > The discussion of "initial handshake" appears to be a remnant of DTLS 1.2, > where a single connection may have multiple handshakes via renegotiation. In > (D)TLS 1.3, there is only one handshake per connection. > > Looking to RFC 8446, the only references to "initial handshake" refer to > resumption, talking about the handshake in the initial connection, vs the > handshake in resumption connections. This reference is not trying to > distinguish initial vs resumption handshakes, so the use of "initial > handshake" is a bit confusing. I believe plain "handshake" is the right > terminology. > > NB: There are two other references to "initial handshake", one in the diagram > in Section 8, and another in Section 11. I believe they too should be > switched to "handshake". > > 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 -- [email protected] To unsubscribe send an email to [email protected]
