[TLS][Editorial Errata Reported] RFC9147 (8051)
RFC Errata System <rfc-editor@rfc-editor.org> Fri, 26 July 2024 05:22 UTC
Return-Path: <wwwrun@rfcpa.rfc-editor.org>
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from rfcpa.rfc-editor.org (unknown [167.172.21.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60DADC169405; Thu, 25 Jul 2024 22:22:35 -0700 (PDT)
Received: by rfcpa.rfc-editor.org (Postfix, from userid 461) id BFF613B874; Thu, 25 Jul 2024 22:22:34 -0700 (PDT)
To: rfc-editor@rfc-editor.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240726052234.BFF613B874@rfcpa.rfc-editor.org>
Date: Thu, 25 Jul 2024 22:22:34 -0700
Message-ID-Hash: JQLU4XJGHZEJX3QC5TGXZPC4HNGRWQVR
X-Message-ID-Hash: JQLU4XJGHZEJX3QC5TGXZPC4HNGRWQVR
X-MailFrom: wwwrun@rfcpa.rfc-editor.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Nagendra@cs.stanford.edu, tls@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS][Editorial Errata Reported] RFC9147 (8051)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ha2JorOTnceTQ0ueflotwCdBo_8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>
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 <davidben@chromium.org> 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][Editorial Errata Reported] RFC9147 (8051) RFC Errata System
- [TLS]Re: [Editorial Errata Reported] RFC9147 (805… Rebecca VanRheenen