Original text:
exceed this length if, e.g., the server uses wildcard names or added new names to the anonymity set. <del> The non-empty name of the client-facing server, i.e., the entity trusted to update the ECH configuration.  This is used to correct </del>  misconfigured clients, as described in handle-server-response. <del> This value MUST NOT begin or end with an ASCII dot and MUST be parsable as a dot-separated sequence of LDH labels, as defined in RFC5890, Section 2.3.1.  Clients MUST ignore any "ECHConfig" structure whose "public_name" does not meet these criteria.  Note that these criteria are incomplete; they incidentally rule out textual representations of IPv6 addresses (see RFC3986, Section 3.2.2), but do not exclude IPv4 addresses in standard dotted-decimal or other non-standard notations such as octal and hexadecimal (see RFC3986, Section 7.4).  If "public_name" contains a literal IPv4 or IPv6 address, the client SHOULD ignore the "ECHConfig" to avoid sending a non-compliant "server_name" extension on the ClientHelloOuter (see RFC6066, Section 3). </del>  A list of extensions that the client must take into consideration when generating a ClientHello message.  These are described below (config-extensions).  The "HpkeKeyConfig" structure contains the following fields: A one-byte identifier for the given HPKE key configuration.  This It MUST include an "encrypted_client_hello" extension with a payload constructed as described in encrypting-clienthello.  [[OPEN ISSUE: We currently require HRR-sensitive parameters to match in ClientHelloInner and ClientHelloOuter in order to simplify client- side logic in the event of HRR.  See https://github.com/tlswg/draft- respond with an empty Certificate message, denoting no client certificate.  Note that authenticating a connection for the public name does not authenticate it for the origin.  The TLS implementation MUST NOT report such connections as successful to the application.  It

Reviewer comments:
This combines and , requiring that validation of publicname happen somewhere_, providing a reference parser (if one does not exist), and allowing it to happen when parsing ECHConfig. , cc NAME NAME NAME NAME
The max for a label in a DNS name is 63 octets though isn't it?
Yeah, but RFC6066 has no similar requirements (that I can tell), so I don't see we need to impose anything new here. Maybe I'm missing something? And if so, can you please propose text?
Fair ask:-) I guess the public_name mostly has to go in a cert SAN so would it help to use or refer to rfc5280 text? The most relevant bit there seems to be: When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax", as specified by Section 3.5 of [RFC1034] and as modified by Section 2.1 of [RFC1123]. Note that while uppercase and lowercase letters are allowed in domain names, no significance is attached to the case. In addition, while the string " " is a legal domain name, subjectAltName extensions with a dNSName of " " MUST NOT be used. (That text is near [1]). That said, that " " is a legal domain name surprises me (and I'm a co-author of 5280!) BTW, I'm fine that that all gets fixed later if that's better. S. [1] URL
Sounds good -- I dropped an OPEN ISSUE to note this for later. NAME would you have cycles to take that issue and propose a PR to address it?
Sneaky eh:-) Sure, I can look at it this week but don't wait on me. S
Yeah, there's no rush here, I think. This seems like a smaller issue to resolve at some point.
For at least command line clients (e.g. curl) and perhaps for censorship circumvention tools it makes sense to allow the outer SNI to contain nothing or something that is not the publicname from the SVCB RR. It's possible that any tool that acquires an ECHConfig from a non-DNS source would benefit from that option too. The offending (for me:-) text is in section 6.1, 2nd list, bullet 7 where it says: 'The value of ECHConfig.contents.publicname MUST be placed in the "server_name" extension.' There may be clients that do need the above. I'm not sure how to chacterise those in a short phrase, but that's likely possible. At the IETF-110 TLS session mention was made of clients that need to fallback but I'm not sure what reference would be correct for that if e.g. we appended something like "URL clients that need to be able to fallback. [ref]"
Censorship circumvention isn't one of the stated goals of ECH. Even if an ECHConfig is acquired from a non-DNS source, it still has the ECHConfig.contents.publicname field, which, as specified in 6.1.3.3, is necessary because: "The client MUST verify that the certificate is valid for ECHConfig.contents.publicname. If invalid, it MUST abort the connection with the appropriate alert."
I believe we should keep this as-is. Fallback is for the server's benefit and the client has no way of knowing whether it will be needed.
+1 -- for robustness reasons, I believe we should keep this as-is.
I also found this requirement odd. Is it really necessary with the changes to config_id in draft -10? If someone could explain why this should be mandatory, that would be fine. I just don't understand the requirement.
When there is a mismatch between DNS and the server configuration, the server will handshake with the outer ClientHello. The expectation when that happens is that the connection is authenticated for the public name, which gives an authenticated recovery signal. That means the server needs to, e.g., select a certificate that covers the public name. Thus, the outer SNI selection.
OK, and a server that didn't need the outer SNI name would be identifiable by IP address anyway. Makes sense.
Sure - the right URL MUST be valid for the client to act upon failed ECH. I don't see that that implies that the ech.public_name MUST be sent though. S.
Hiya, I understand the sensitivities there but nor are we forced to make life harder for those who develop such applications. (Separately, I don't recall there being any consensus call related to whether or not that is or is not a goal.) A requirement for the client to verify the URL vs. the presented cert does not need to involve the publicname. I'm fine that the client MUST (as always) verify the presented cert vs. the URL if ECH didn't work. I'd also be fine with a SHOULD send here, or with a "MUST default to send publicname in URL" but an absolute MUST is not necessary afaics. The issue for me is for a generic library - in that case being able to override the public_name seems like it may sometimes be useful and since there's no need to require library developers to enforce the MUST, it's a bad plan I think. Cheers, S.
Hiya, Not convinced. For a web browser talking to a web server given a sensible set of DNS RRs, I do agree with you. For any random TLS client/server pair, I'm not yet convinced. Hence I still consider an absolute MUST OTT/wrong. S.
One oddity of this requirement is that it presents a GREASE distinguisher when the client is connecting to an IP address with no server name. In the GREASE case, the ClientHelloOuter.servername is absent because . In the real-ECH case, ClientHelloOuter.servername is present and contains ECHConfig.public_name. However, why use ECH at all if the IP address uniquely identifies the desired service? I think I support keeping the requirement for the sake of the fallback/retry mechanism. Was there some other scenario you're thinking of?
(The outer name pretty fundamentally interacts with GREASE because the distribution of true SNIs is different from the distribution of cleartext ones, but the fact that IP addresses don't get SNIs is an insignificant component of that, given how rare they are. Any reasonable model of GREASE distinguishability would need to be a bit more subtle.)
If possible, I'd like to see if we can drill down on where folks disagree. Fact 1: The public name specifies the name that the client expects the client-facing server to verify in case of ECH rejection. Fact 2: The outer SNI specifies the name the client expects the client-facing server to verify, regardless of whether ECH was offered. It seems like the point of disagreement is how these two extensions --- ECH and SNI --- are meant to be composed. It seems to me that NAME believes that SNI takes precedence: if we allowed public name != outer SNI, then this would violate the rules of the SNI extension, It seems like NAME believes that ECH can take precedence: allowing public name != outer SNI is OK because the client already knows what name the client-facing server will verify. Am I understanding this all correctly?
I'm very confused what facts 1 and 2 are trying to say. The servername extension, in any ClientHello, is the name of the server you're trying to contact with that ClientHello. This figures into certificate selection, and you could even imagine a protocol which uses it in lieu of an in-band Host header for virtual hosting. (Although HTTP does it in-band and doesn't care much about the servername.) In the ClientHelloInner, you are trying to contact the true name, so you put the true name in servername. In the ClientHelloOuter, you are trying to contact the public name, so you put the public name in servername. Independent of ECH, if you have external knowledge that such-and-such field will be interpreted in a different way and the server doesn't need the server_name, then you can go against the spec. If that external knowledge applies to the ClientHelloOuter, then you can apply that to the ClientHelloOuter. But that's not how the field is meant to work, so the spec should describe the intended semantics.
This seems to advocate that a SHOULD, rather than a MUST, is appropriate in choosing what name goes in ClientHelloOuter, right? In particular, the spec does not accommodate external knowledge about what goes in the field. It requires it be set to ECHConfig.public_name.
I think a SHOULD is correct. Cheers, S.
Fact 1 says that publicname is the name of the server when ECH is rejected (i.e., the client-facing server). Fact 2 says that servername is the name of the server. My point was merely that these facts appear to contradict one another if publicname != CHOuter.servername. Hence, we need to decide how to compose ECH with SNI in a way that resolves the contradiction. The answer might simply be that publicname MUST equal CHOuter.servername. Or, we might do say something else.
(I don't particular care about MUST vs. SHOULD. Whatever we say elsewhere for servername I guess.) NAME I'm not following. I think talking about publicname != CHOuter.servername is getting causality the wrong way around. CHOuter is a construct we are inventing in ECH. That means we get to define the semantics. The semantics we've defined are that CHOuter, along with the result of handshaking with CHOuter, is intended for the ECH rejection case. How does the client know how the ECH rejection case works? Well, we also need to define that in ECH. Our definition is that you handshake against ECHConfig.publicname. Finally, servername is a construct that has already been defined. What goes in there? RFC6066 and RFC8446 tell you. It's the name of the server you are trying to contact. With all that, what do you put in CHOuter.servername? Well, you put the rules together. It's the name of the server you are trying to contact in the ECH rejection case, which is ECHConfig.public_name.
I do:-) SHOULD seems correct to me. A MUST over-constrains generic libraries. I agree with the above but will quibble with some text below... Not really - CHOuter has to be a "working" CH with semantics defined by 8446, so we're a lot more constrained in reality. Yep. That's too absolute IMO. ECHConfig.publicname tells you a name that should work for the CHOuter fallback. There will be many situations where another name can work as well, though using ECHConfig.publicname is a fine default/SHOULD. Cheers, S.
Oh sure. I wasn't suggesting CHOuter and the resulting handshake get to ignore 8446. But the parameters to that handshake are not set and that's what ECH get to define. Hrm, in which link of the chain were you looking to add flexibility? There's: The implementation wants to set servername to some value other than the name they are contacting The implementation wants to set the name they are contacting to some value other than ECHConfig.publicname Weakening the first to SHOULD is perhaps plausible, especially if 6066 and 8446 already are less prescriptive. Weakening the second to SHOULD is much more dangerous because you lose the chain of authenticity up from the TLS handshake through X.509 to the name specified by the ECHConfig.
Let me try another way to justify a SHOULD. Consider SMTP/TLS. There can be >1 MX RR value for a domain. When forwarding a mail to NAME it may (or may not) be that the correct way to handle ECH for SMTP/TLS is to look for an SVCB at URL or at one of the MX names that we find at URL It may (or may not) be the case that some or all of the server-side TLS endpoints for those MX names share the same ECHConfig private values at a given moment. It may (or may not) be the case that the DNS answers for type65 at all those MX names and URL are well managed and always in sync. It may (and it will:-) be the case that multiple MX name type65 RRs and multiple SVCB RR values including future new SVCB or ECHConfig extensions interact in ways the TLS WG can't now forsee. I think there could in future be a real use-case for ECH in SMTP/TLS, and that it'd be wrong for the TLS WG to decide now with a MUST how ECHConfig.publicname ought be handled in all cases. I reckon many other protocols using TLS might also each have a pile of wrinkles we can't analyse. So I argue that at least generic libraries for TLS ought not be prohibited from having some kind of override that results in URL != ECHConfig.publicname. (And for at least some generic libraries, contravening such a MUST would I think be a reason why upstream might reject an offered PR.) All that said, using ECHConfig.public_name SHOULD work in almost all cases so is a good default and one to probably encourage. Hope that helps, S. PS: As an aside: some MX names expose what we'd like to put in URL, whereas some will not, and a simple sub- string match won't always catch that. But that's an issue for some mail folks to consider later, if it's a real issue. (It probably isn't for TLS, but maybe is for how MTAs might use multiple DoX queries.)

Revised text:
exceed this length if, e.g., the server uses wildcard names or added new names to the anonymity set.  <ins> The DNS name of the client-facing server, i.e., the entity trusted to update the ECH configuration.  This is used to correct </ins> misconfigured clients, as described in handle-server-response.  <ins> 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 SHOULD ignore the "ECHConfig" if it contains an encoded IPv4 address.  To determine if a public_name value is an IPv4 address, clients can invoke the IPv4 parser algorithm in WHATWG- IPV4.  It returns a value when the input is an IPv4 address. See auth-public-name for how the client interprets and validates the public_name. </ins> A list of extensions that the client must take into consideration when generating a ClientHello message.  These are described below (config-extensions). <ins> [[OPEN ISSUE: determine if clients should enforce a 63-octet label limit for public_name]] [[OPEN ISSUE: fix reference to WHATWG-IPV4]] </ins> The "HpkeKeyConfig" structure contains the following fields: A one-byte identifier for the given HPKE key configuration.  This It MUST include an "encrypted_client_hello" extension with a payload constructed as described in encrypting-clienthello. <ins> Note that these rules may change in the presence of an application profile specifying otherwise. </ins> [[OPEN ISSUE: We currently require HRR-sensitive parameters to match in ClientHelloInner and ClientHelloOuter in order to simplify client- side logic in the event of HRR.  See https://github.com/tlswg/draft- respond with an empty Certificate message, denoting no client certificate. <ins> In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity.  Clients that incorporate DNS names and IP addresses into the same syntax (e.g.  RFC3986, Section 7.4 and WHATWG-IPV4) MUST reject names that would be interpreted as IPv4 addresses.  Clients that enforce this by checking and rejecting encoded IPv4 addresses in ECHConfig.contents.public_name do not need to repeat the check at this layer. </ins> Note that authenticating a connection for the public name does not authenticate it for the origin.  The TLS implementation MUST NOT report such connections as successful to the application.  It