From 39723d575a7ec8dcd0530b88ded5aba62ce6bd5b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 26 Nov 2024 15:30:51 +1100 Subject: [PATCH 1/3] Move name validation to the authentication section This is partly motivated by my interests in doing something evil, but mostly this is because coupling name validity to ECH config validity is a layering violation. It's fine to invoke some name validation, but that should be dictated by the needs of the thing that ends up relying on that name. This corrects both problems. In doing this, I realized that RFC 791 says nothing about the IP address textual format. That's problematic, but I couldn't come up with anything better in short notice. Closes #628. Closes #637. --- draft-ietf-tls-esni.md | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index 0058c984..f1150ee3 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -289,17 +289,6 @@ public_name to update the ECH configuration. This is used to correct misconfigured clients, as described in {{rejected-ech}}. -: Clients MUST ignore any `ECHConfig` structure whose public_name is not -parsable as a dot-separated sequence of LDH labels, as defined in -{{!RFC5890, Section 2.3.1}} or which begins or end with an ASCII dot. Clients -additionally SHOULD ignore the structure if the final LDH label either consists -of all ASCII digits (i.e. '0' through '9') or is "0x" or "0X" followed by some, -possibly empty, sequence of ASCII hexadecimal digits (i.e. '0' through '9', 'a' -through 'f', and 'A' through 'F'). This avoids public_name values that may be -interpreted as IPv4 literals. Additionally, clients MAY ignore the -`ECHConfig` if the length of any label in the DNS name is longer than 63 -octets, as this is the maximum length of a DNS label. - : See {{auth-public-name}} for how the client interprets and validates the public_name. @@ -917,6 +906,18 @@ and session IDs presented by the server. These connections are only used to trigger retries, as described in {{rejected-ech}}. This may be implemented, for instance, by reporting a failed connection with a dedicated error code. +Prior to attempting a connection, a client SHOULD validate the `ECHConfig` to +ensure that the public_name can be authenticated. Clients SHOULD ignore any +`ECHConfig` structure with a public_name that is not a vaild host name in +preferred name syntax (see {{Section 2 of ?DNS-TERMS=RFC8499}}). That is, to be +valid, the public_name needs to be a dot-separated sequence of LDH labels, as +defined in {{!RFC5890, Section 2.3.1}}, where: + +* the sequence does not begin or end with an ASCII dot; +* all labels are no more than 63 octets; and +* the sequence does not parse as an IPv4 address {{!RFC0790}} in textual form, + including a hexadecimal form that starts with "0x". + ### Impact of Retry on Future Connections @@ -1371,7 +1372,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 From aacf20ea2b6e53ad89bb9b7c2f79db6acf70d8cb Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 26 Nov 2024 15:34:38 +1100 Subject: [PATCH 2/3] Obvious improvements --- draft-ietf-tls-esni.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index f1150ee3..80cb5563 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -911,10 +911,10 @@ ensure that the public_name can be authenticated. Clients SHOULD ignore any `ECHConfig` structure with a public_name that is not a vaild host name in preferred name syntax (see {{Section 2 of ?DNS-TERMS=RFC8499}}). That is, to be valid, the public_name needs to be a dot-separated sequence of LDH labels, as -defined in {{!RFC5890, Section 2.3.1}}, where: +defined in {{Section 2.3.1 of !RFC5890}}, where: * the sequence does not begin or end with an ASCII dot; -* all labels are no more than 63 octets; and +* all labels are at most 63 octets; and * the sequence does not parse as an IPv4 address {{!RFC0790}} in textual form, including a hexadecimal form that starts with "0x". From f6b6111769c7342ebc3e0ff7d83e5f89856c0bda Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 27 Nov 2024 09:30:41 +1100 Subject: [PATCH 3/3] veiled Co-authored-by: David Benjamin --- 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 80cb5563..151dbe0a 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -908,7 +908,7 @@ instance, by reporting a failed connection with a dedicated error code. Prior to attempting a connection, a client SHOULD validate the `ECHConfig` to ensure that the public_name can be authenticated. Clients SHOULD ignore any -`ECHConfig` structure with a public_name that is not a vaild host name in +`ECHConfig` structure with a public_name that is not a valid host name in preferred name syntax (see {{Section 2 of ?DNS-TERMS=RFC8499}}). That is, to be valid, the public_name needs to be a dot-separated sequence of LDH labels, as defined in {{Section 2.3.1 of !RFC5890}}, where: