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
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
