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 (https://github.com/tlswg/draft-ietf-tls-esni/commit/2660209e03b2d7f9c6db9cc9a70c65978914da0d). 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.

[ekr]

@paulwouters I think we are waiting on you for some text here.

[paulwouters]

how about:

OLD:

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').

NEW:

Clients additionally SHOULD ignore the structure if it represents an IP address
in textual or hexadecimal form"

With this, and the above confirmed MAY to MUST, I would be good.

[ekr]

We'll probably need a citation here. I expect it's: IPv4: Maybe 1123? IPv6: https://datatracker.ietf.org/doc/html/rfc4291#section-2.2 (though as a practical matter, no valid IPv6 address can be a valid domain name, I believe.

[letoams]

Yes, “:” is not a valid dns character

[enygren]

Is there an RFC we can reference? I thought ":" technically is allowed within a DNS label, so arguably an IPv6 address could be a valid TLD (or a form like 2001:db8::1.2.3.44 could be a name under .44)? It's not a valid hostname ([a-z0-9.]{0,63} for labels), but there is ambiguity in what is allowed in DNS binary string labels (rfc4343 , rfc1035, rfc2181section 11). Agreed that this is not the right place to try and clarify that ambiguity.

Could we require a valid hostname rather than a valid DNS name? That would preclude underscore-prefixed though (would that be a problem for DANE)?

[paulwouters]

https://www.rfc-editor.org/rfc/rfc8499

Host name:  This term and its equivalent, "hostname", have been
      widely used but are not defined in [[RFC1034](https://www.rfc-editor.org/rfc/rfc1034)], [[RFC1035](https://www.rfc-editor.org/rfc/rfc1035)],
      [[RFC1123](https://www.rfc-editor.org/rfc/rfc1123)], or [[RFC2181](https://www.rfc-editor.org/rfc/rfc2181)].  The DNS was originally deployed into the
      Host Tables environment as outlined in [[RFC952](https://www.rfc-editor.org/rfc/rfc952)], and it is likely
      that the term followed informally from the definition there.  Over
      time, the definition seems to have shifted.  "Host name" is often
      meant to be a domain name that follows the rules in Section 3.5 of
      [RFC1034], which is also called the "preferred name syntax".  (In
      that syntax, every character in each label is a letter, a digit,
      or a hyphen).  Note that any label in a domain name can contain
      any octet value; hostnames are generally considered to be domain
      names where every label follows the rules in the "preferred name
      syntax", with the amendment that labels can start with ASCII
      digits (this amendment comes from [Section 2.1 of [RFC1123]](https://www.rfc-editor.org/rfc/rfc1123#section-2.1)).

      People also sometimes use the term "hostname" to refer to just the
      first label of an FQDN, such as "printer" in
      "printer.admin.example.com".  (Sometimes this is formalized in
      configuration in operating systems.)  In addition, people
      sometimes use this term to describe any name that refers to a
      machine, and those might include labels that do not conform to the
      "preferred name syntax".