From c89b3b43e39e948aaebcaa55419c0d6eb49c2e56 Mon Sep 17 00:00:00 2001 From: BenSmyth Date: Fri, 17 May 2024 15:39:54 +0200 Subject: [PATCH 1/8] Address erratum 6151 --- draft-ietf-tls-rfc8446bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index b5e426c8..d20a245b 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -2932,7 +2932,7 @@ for each scenario: |------|-------------------|----------| | Server | ClientHello ... later of EncryptedExtensions/CertificateRequest | server_handshake_traffic_secret | | Client | ClientHello ... later of server Finished/EndOfEarlyData | client_handshake_traffic_secret | -| Post-Handshake | ClientHello ... client Finished + CertificateRequest | client_application_traffic_secret_N | +| Post-Handshake | ClientHello ... client Finished + CertificateRequest | [sender]_application_traffic_secret_N | {: #hs-ctx-and-keys title="Authentication Inputs"} ### The Transcript Hash From 81b7ebb15bfe1ace62067cfd9e513d8c993c6ce5 Mon Sep 17 00:00:00 2001 From: BenSmyth Date: Fri, 17 May 2024 16:01:40 +0200 Subject: [PATCH 2/8] Address erratum 7003 --- draft-ietf-tls-rfc8446bis.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index d20a245b..7589abbf 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -3377,7 +3377,8 @@ appropriate application traffic key. ### New Session Ticket Message {#NSTMessage} -At any time after the server has received the client Finished message, +At any time after the server has received both a "psk_key_exchange_modes" extension +and the client Finished message, it MAY send a NewSessionTicket message. This message creates a unique association between the ticket value and a secret PSK derived from the resumption secret (see {{cryptographic-computations}}). From ee8afa2bb6dfd8f22f7aa2f0fd248ac74e9413bc Mon Sep 17 00:00:00 2001 From: BenSmyth Date: Fri, 17 May 2024 16:06:57 +0200 Subject: [PATCH 3/8] Address erratum 7073 --- draft-ietf-tls-rfc8446bis.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index 7589abbf..f1b68360 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -2898,7 +2898,8 @@ flight. The Certificate and CertificateVerify messages are only sent under certain circumstances, as defined below. The Finished message is always sent as part of the Authentication Block. These messages are encrypted under keys derived from the -\[sender]_handshake_traffic_secret. +\[sender]_handshake_traffic_secret, +except for post-handshake authentication. The computations for the Authentication messages all uniformly take the following inputs: From f7129157637a1bae6ad0d21070792f40ed36f7eb Mon Sep 17 00:00:00 2001 From: BenSmyth Date: Fri, 17 May 2024 16:28:50 +0200 Subject: [PATCH 4/8] Editorial --- draft-ietf-tls-rfc8446bis.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index f1b68360..a6471c5f 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -444,7 +444,7 @@ properties. TLS consists of two primary components: * A handshake protocol ({{handshake-protocol}}) that authenticates the communicating parties, - negotiates cryptographic modes and parameters, and establishes + negotiates cryptographic algorithms and parameters, and establishes shared keying material. The handshake protocol is designed to resist tampering; an active attacker should not be able to force the peers to negotiate different parameters than they would @@ -705,7 +705,7 @@ in the diagram above): In the Key Exchange phase, the client sends the ClientHello ({{client-hello}}) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of -symmetric cipher/HKDF hash pairs; either a list of Diffie-Hellman key shares (in the +symmetric cipher/Hash pairs; either a list of Diffie-Hellman key shares (in the "key_share" ({{key-share}}) extension), a list of pre-shared key labels (in the "pre_shared_key" ({{pre-shared-key-extension}}) extension), or both; and potentially additional extensions. Additional fields and/or messages @@ -3145,9 +3145,8 @@ cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending a certificate chain of its choice that may include algorithms that are not known to be supported by the client. -This fallback chain SHOULD NOT use the deprecated SHA-1 hash algorithm in general, -but MAY do so if the client's advertisement permits it, -and MUST NOT do so otherwise. +This fallback chain MUST NOT use the deprecated SHA-1 hash, +except if advertised by the client, in which case it MAY. If the sender is the client, the client MAY use a fallback chain as above, or continue the handshake anonymously. From 76cb2b79a68b018cf86d59ff727ce579ab893ed1 Mon Sep 17 00:00:00 2001 From: EKR Date: Sat, 27 Jul 2024 15:28:16 -0700 Subject: [PATCH 5/8] Editorial --- draft-ietf-tls-rfc8446bis.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index a6471c5f..d61adcab 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -3377,8 +3377,8 @@ appropriate application traffic key. ### New Session Ticket Message {#NSTMessage} -At any time after the server has received both a "psk_key_exchange_modes" extension -and the client Finished message, +If the client's hello contained a suitable "psk_key_exchange_modes" extension, +at any time after the server has received the client Finished message, it MAY send a NewSessionTicket message. This message creates a unique association between the ticket value and a secret PSK derived from the resumption secret (see {{cryptographic-computations}}). From 72f2da5b79ebfbaaf20a9637037e3cf516f52c58 Mon Sep 17 00:00:00 2001 From: EKR Date: Sat, 27 Jul 2024 15:29:44 -0700 Subject: [PATCH 6/8] address erratum 7620 --- draft-ietf-tls-rfc8446bis.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index d61adcab..6578a8b6 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -4093,6 +4093,13 @@ requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation. +Application protocols MAY choose to flush their send buffers and immediately +send a close_notify upon receiving a close_notify, but this allows an attacker +to influence the data that the peer receives by delaying the close_notify or +by delaying the transport level delivery of the application's packets. These +issues can be addressed at the application layer, for instance by ignoring +packets received after transmitting the close_notify. + If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed, the TLS implementation MUST receive a "close_notify" alert before indicating From bfac86a2aaa69fef1ea667775e7c1246b09289c3 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 30 Jul 2024 18:27:03 -0700 Subject: [PATCH 7/8] Update to match MT review --- draft-ietf-tls-rfc8446bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index 6578a8b6..3f6bfaed 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -3146,7 +3146,7 @@ indicated supported algorithms, then it SHOULD continue the handshake by sending a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain MUST NOT use the deprecated SHA-1 hash, -except if advertised by the client, in which case it MAY. +unless the client specifically advertises that it is willing to accept SHA-1. If the sender is the client, the client MAY use a fallback chain as above, or continue the handshake anonymously. From f997610e37fabc1931b6572db4232af84fc5ca8f Mon Sep 17 00:00:00 2001 From: Eric Rescorla Date: Tue, 30 Jul 2024 18:28:14 -0700 Subject: [PATCH 8/8] Update draft-ietf-tls-rfc8446bis.md Co-authored-by: Martin Thomson --- draft-ietf-tls-rfc8446bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index 3f6bfaed..4790b193 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -705,7 +705,7 @@ in the diagram above): In the Key Exchange phase, the client sends the ClientHello ({{client-hello}}) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of -symmetric cipher/Hash pairs; either a list of Diffie-Hellman key shares (in the +symmetric cipher/hash pairs; either a list of Diffie-Hellman key shares (in the "key_share" ({{key-share}}) extension), a list of pre-shared key labels (in the "pre_shared_key" ({{pre-shared-key-extension}}) extension), or both; and potentially additional extensions. Additional fields and/or messages