> In general, I'd prefer we get ECH deployed for some major use > cases and not try fill in every possible niche at this point.
That's fine with me. > On Apr 20, 2021, at 7:03 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > > > Hiya, > > To answer Chris' initial question: I can't currently think of > a real use-case where the client would need to authenticate > an IP address for a client-facing server in the event that > ECH decryption has been tried and failed. > > And, I very much sympathise with Martin's goal of simplifying > if we can. (E.g. leave the public_name as-is and as we've got > implemented, but drop the extensions field entirely - I don't > think there's a shortage of code points for new extensions if > the first ECH one doesn't quite do what's needed.) > > But I'm likely not the right person to ask - I'd guess that > the people who might have a use-case for this are smaller > hosters where the default listener on 443 is very minimal. I > don't know how common those are, but I'd suspect they are > fairly rare. And likely those with certs that have the > exactly right IP address are even rarer. > > On 21/04/2021 02:48, Carrick Bartle wrote: >>> I'm not sure what you are implying might be impossible. Are you >>> suggesting that it might be impossible to get a name for which you >>> could get a certificate? >> No. I'm implying that if we don't allow clients to authenticate >> client-facing servers with an IP-based certificate, ECH won't be >> possible in cases where the client-facing server doesn't have a >> name. > > In general, I'd prefer we get ECH deployed for some major use > cases and not try fill in every possible niche at this point. > ISTM the overall win here is that we end up with ECH working > in many cases, but don't need all cases. And there's a danger > that we get zero cases if we make it too complex. > > Cheers, > S. > > > <OpenPGP_0x5AB2FAF17B172BEA.asc>_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
