Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue628 dns names #637

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Issue628 dns names #637

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
70bdd72
Address AD review about DNS names. Fixes #628
ekr Nov 25, 2024
1d36649
Fix lint
ekr Nov 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions draft-ietf-tls-esni.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -291,14 +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 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.
{{!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
Comment on lines +296 to +299
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The concept of a "valid DNS name" is not well-defined. In general, DNS "labels" can contain any sequence of up to 63 octets. There is no uniform standard for representing DNS names as strings.

IPv6 addresses are not valid hostnames, nor are they permissible FQDNs under ICANN rules, but that is not the same thing.

I don't think we need the parenthetical anyway though.

Suggested change
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
IPv4 address {{!RFC791}} in textual or hexadecimal form.
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.
Comment on lines +299 to +301
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How many would properly ignore such an ECH config?


: See {{auth-public-name}} for how the client interprets and validates the
public_name.
Expand Down Expand Up @@ -1371,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
Expand Down
Loading