From 90d732b6288e0a935e86f7fbbb61ae3758b98134 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Wed, 27 Nov 2024 13:33:00 -0500 Subject: [PATCH 1/2] Use the DTLS ClientHello structure in ECH with DTLS This PR implements the option if we decide to use DTLS's ClientHello as the payload and AAD, rather than somehow fit TLS's in there. Fixes #639. --- draft-ietf-tls-esni.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index 0058c984..d44b7d7a 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -481,10 +481,12 @@ into a EncodedClientHelloInner structure, defined below: ~~~ The `client_hello` field is computed by first making a copy of ClientHelloInner -and setting the `legacy_session_id` field to the empty string. Note this field -uses the ClientHello structure, defined in {{Section 4.1.2 of RFC8446}} which -does not include the Handshake structure's four byte header. The `zeros` field -MUST be all zeroes. +and setting the `legacy_session_id` field to the empty string. In TLS, this +field uses the ClientHello structure defined in {{Section 4.1.2 of RFC8446}}. +In DTLS, it uses the ClientHello structured defined in +{{Section 5.3 of RFC9147}}. This does not include Handshake structure's +four-byte header in TLS, nor twelve-byte header in DTLS. The `zeros` field MUST +be all zeroes. Repeating large extensions, such as "key_share" with post-quantum algorithms, between ClientHelloInner and ClientHelloOuter can lead to excessive size. To @@ -556,12 +558,12 @@ while keeping the same encrypted `ClientHelloInner` (see {{flow-clienthello-malleability}}), ECH authenticates ClientHelloOuter by passing ClientHelloOuterAAD as the associated data for HPKE sealing and opening operations. The ClientHelloOuterAAD is a serialized -ClientHello structure, defined in {{Section 4.1.2 of RFC8446}}, which -matches the ClientHelloOuter except that the `payload` field of the -"encrypted_client_hello" is replaced with a byte string of the same -length but whose contents are zeros. This value does not include the -four-byte header from the Handshake structure. - +ClientHello structure, defined in {{Section 4.1.2 of RFC8446}} for TLS and +{{Section 5.3 of RFC9147}} for DTLS, which matches the ClientHelloOuter except +that the `payload` field of the "encrypted_client_hello" is replaced with a byte +string of the same length but whose contents are zeros. This value does not +include Handshake structure's four-byte header in TLS, nor twelve-byte header in +DTLS. # Client Behavior From 1779fe6bb04b0cda0049e5f15fcd35c4051b429e Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Wed, 27 Nov 2024 15:08:52 -0500 Subject: [PATCH 2/2] make fix-lint --- draft-ietf-tls-esni.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index d44b7d7a..23b7793d 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -1373,7 +1373,7 @@ has size k = 1. Client-facing servers SHOULD deploy ECH in such a way so as to maximize the size of the anonymity set where possible. This means client-facing servers should use the same ECHConfig for as many hosts as possible. An attacker can distinguish two hosts that have different ECHConfig values based -on the ECHClientHello.config_id value. +on the ECHClientHello.config_id value. This also means public information in a TLS handshake should be consistent across hosts. For example, if a client-facing server