Re: [TLS] Authenticating the client-facing server with an IP-based certificate

[Stephen Farrell <[e-mail]>]

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.


> 
>