Hi, Eric, > On Mar 14, 2024, at 00:45, Eric Rescorla <e...@rtfm.com> wrote: > > There are two questions here: > > 1. What the specification says > 2. What implementations choose to do within the envelope of that > specification. > > The specification needs to prescribe a set of behaviors that promote > interoperability, which means that whatever it tells the client to do must be > compatible with what it tells servers to do. Presently, the specification > tells clients to put whatever is in ECHConfig.public_name in > ClientHelloOuter.sni (S 6.1) and tells the server that it may check and > reject it otherwise (S 7.1). We extensively debated whether to forbid > checking in PR #575 and concluded that we should do so. The primary arguments > were the same ones being offered here balanced against the ecosystem benefits > of encouraging the client to correctly populate ClientHelloOuter.sni to > enable the recovery mechanism. The WG could of course revisit that decision. > > With that said, even if the specification explicitly allowed clients to > omit/falsify ClientHelloOuter.sni, I don't believe that generic clients > (e.g., the kind of Web browsers that most people use) would choose to do so. > The reason is that, as noted above, it would break the recovery mechanism, > and that's more important than the modest increment in concealing the > public_name of servers on non-shared IPs. One might imagine that some special > purpose clients would choose to do so, but that's not the case I'm talking > about.
The public_name is required, not naturally because it will be used by ECHConfig recovery, but because if the client omit it or fill some none domain value like ensi.test, the observer could identify traffic equipped with ECH or normal TLS traffic. However, the problem we are discussing here is if you want to deploy ECH you have to own a dedicated domain name and get a valid SSL certificate for it so that you can resend the latest ECHConfig to the client that use the outed configuration. The process is only chosen by the draft. But it is not the only way to do it. Here are some immature ideas. One method is to public another public_key for signing along side with ECHConfig, let's call it Recovery Signing Key. This key will only be used to sign the latest ECHConfig during the recovery process. So there is not need to rotate it as frequently as the ECHConfig itself. The client should use DNS to lookup the ECHConfig and the Recovery Signing Key. If the ECHConfig is outdated, the server will respond the latest ECHConfig with signature signed the Recovery Signing Key. By the way, the client could verify whether the recovered ECHConfig is valid. Here is another immature ideas. If the WG insist to use the outer TLS negotiation to recovery ECHConfig, it may works to use the self-signed certificate. In order to let client trust the self-signed certificate only in the process of ECHConfig recovery, we can publish the hash of the self-signed certificate along side the ECHConfig in the HTTPS RR. If the server need to recover the latest ECHConfig, it can finish the outer TLS negotiation with its self-signed certificate. As the client already knows the server's self-signed certificate by the DNS lookup, it can trust it once int this negotiation process and get the latest ECHConfig. By this ways, the public_name in ECHConfig.public_name could not have to be a real domain, and there is no need to own it or buy a SSL certificate for it. It is only an ID of ECHConfig, and just looks like a domain. And we can rotate it and the ECHConfig as soon as need. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
