From 70bdd72951cdfeb1849a9925f2252a59d5b780b3 Mon Sep 17 00:00:00 2001 From: EKR Date: Sun, 24 Nov 2024 17:31:04 -0800 Subject: [PATCH 1/2] Address AD review about DNS names. Fixes #628 --- draft-ietf-tls-esni.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index 0058c984..7b109e9d 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -291,12 +291,11 @@ 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 +{{!RFC5890, Section 2.3.1}} or which begins or end with an ASCII dot. +Clients additionally SHOULD ignore the structure if it represents an IPv4 address {{!RFC791}} +in textual or hexadecimal form (IPv6 addresses are invalid DNS names +due to the presence of the ":" character, and thus are excluded by +the previous requirement). Additionally, clients MUST 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. From 1d36649ee3b9242a0925ad38425800b7efd1379e Mon Sep 17 00:00:00 2001 From: EKR Date: Sun, 24 Nov 2024 17:31:57 -0800 Subject: [PATCH 2/2] Fix lint --- draft-ietf-tls-esni.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index 7b109e9d..c152b665 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -291,13 +291,14 @@ 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 it represents an IPv4 address {{!RFC791}} -in textual or hexadecimal form (IPv6 addresses are invalid DNS names -due to the presence of the ":" character, and thus are excluded by -the previous requirement). Additionally, clients MUST 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. +{{!RFC5890, Section 2.3.1}} or which begins or end with an ASCII dot. +Clients additionally SHOULD ignore the structure if it represents an +IPv4 address {{!RFC791}} in textual or hexadecimal form (IPv6 +addresses are invalid DNS names due to the presence of the ":" +character, and thus are excluded by the previous +requirement). Additionally, clients MUST 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. @@ -1370,7 +1371,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