DNS issues from AD review.

[ekr]

Tagging @bemasc on these.

Section 4

    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.

Wouldn't this prevent the root zone from ever running ECH? It might not matter,
but why not allow it :P

    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 would not allow ECH to work for "00.com", "0x01.com" or "0x07.com", which are
all currently operational domains.

I don't think this document should try to define what a legal DNS name is. Perhaps
refer to "Host name" in RFC 8499 (or BCP219) and only state "leave out any potential
trailing dot" ? Maybe just separately say "SNI's cannot be in the textual form of an
IP address, as connections to IP addresses omit the SNI entirely" ?

It is a bit sad that ECH currently does not work with a URI that points to an IP
address. Especially for the split-mode. But I understand that would be a little
more than just ECH/encrypted-SNI.

    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.

Why is this a MAY? Why not a MUST or SHOULD?

[bemasc]

    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.

Wouldn't this prevent the root zone from ever running ECH?

ECHConfig is versioned, so nothing here is "forever".

The only purpose of public_name is to support the fallback flow on key mismatch. This requires the server to prove ownership of public_name, presumably via an X.509 certificate or TLSA record for the root. As both of those seem extremely unlikely, I don't think we need to worry about it.

It might not matter, but why not allow it :P

ECH is designed to be easy to integrate for existing applications that use common TLS libraries and work with URIs and URLs. In these systems, the final "." is omitted, leaving the root as an empty string. Treating an empty public_name as meaning "the DNS root" would never work, would increase the difficulty of integration with systems that don't accept empty hostnames, and would increase confusion for debugging.

    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 would not allow ECH to work for "00.com", "0x01.com" or "0x07.com", which are all currently operational domains.

"final" here means "rightmost in textual format", i.e. TLD.

I don't think this document should try to define what a legal DNS name is. Perhaps refer to "Host name" in RFC 8499 (or BCP219) and only state "leave out any potential trailing dot" ? Maybe just separately say "SNI's cannot be in the textual form of an IP address, as connections to IP addresses omit the SNI entirely" ?

The challenge here is that textual IPv4 addresses are valid hostnames, but there is no good reference for the textual representation syntax of an IPv4 address (2660209). This creates a high likelihood that some clients will decide that public_name is not an IP address and pass it into a subsystem that interprets it as an IP address, resulting in a recovery request with no SNI and strange failure modes. For the sake of consistency in debugging, the authors felt it was preferable to write a simple rule that could be enforced universally.

It is a bit sad that ECH currently does not work with a URI that points to an IP address. Especially for the split-mode. But I understand that would be a little more than just ECH/encrypted-SNI.

To be clear, that is largely unrelated to the public_name question. If you have a mechanism to associate an ECHConfig with an IP-authenticated TLS connection request, ECH will work fine, although it doesn't seem very useful. What doesn't work is using an IP certificate in the fallback/recovery flow, since public_name cannot be an IP address.

    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.

Why is this a MAY? Why not a MUST or SHOULD?

"Failing open" in this way trades reliability risk for privacy risk, in the event of affected misconfigurations. Given the low risk of confusion in these cases, the authors decided to leave this choice to the client.

[ekr]

@letoams I think this addresses your questions. Any objection to closing these issues?

[paulwouters]

I am still uncomfortable with this document basically having its own version of what is a valid DNS name. I would still prefer that it omits these definitions and instead just mention the issue implementers should avoid. That could be something as simple as "public_names that are textual representation of an IPv4 address MUST be treated as invalid", without talking about what a valid LDH is for DNS.

[bemasc]

cc @davidben

[seanturner]

AT IETF 121, @paulwouters agreed to provide text.

Change this to MUST:

 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.