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

From: "Christopher Wood" <[email-masked]>
Date: Tue, 20 Apr 2021 17:33:47 -0700

Issue #424 tracks whether or not we want to allow clients to authenticate client-facing servers with an IP-based certificate:

   https://github.com/tlswg/draft-ietf-tls-esni/issues/424

There are a number of different proposals for _how_ we might enable this, varying in how the name and addresses are encoded in ECHConfig structures, how these interact with atypical client connection setups (through a proxy, for example), and so on. Complexity abounds. 

Taking a step back, it would be great if we could reach consensus on whether or not this is a use case we actually want to solve. If it's not, then the design space seems quite smaller and more manageable in comparison. To that end, it would be great if folks could chime in here whether or not they support this particular use case (with rationale as needed).  

Thanks!
Chris (no hat)

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 21 Apr 2021 11:00:31 +1000

On Wed, Apr 21, 2021, at 10:33, Christopher Wood wrote:
> Taking a step back, it would be great if we could reach consensus on 
> whether or not this is a use case we actually want to solve. 

The Web currently recognizes IP certificates.  The specs, thanks RFC 6125, largely missed this, but we're fixing that.  ACME has RFC 8738 and the latest HTTP(S) spec finally defines validation for an IP-based reference identity.

All that said, IP certificates are naturally a feature with narrow applicability.  For something like ECH fallback, which should be rare, we benefit more from reduced options and simplicity than we do by enabling niche features.  Adding a dependency on a rarely used feature, optional or not, only increases the risk profile.  And complexity.

So I don't think we should support different anything other than a domain name for ECH fallback.

If someone could demonstrate that it would be an undue imposition to require a client-facing server to use a domain name, then I would happily concede the point.  As it is, we're talking about a host that fronts for multiple different names, so I'm finding it hard to imagine how finding a name usable for this purpose would be challenging.

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 20 Apr 2021 18:30:47 -0700

> we're talking about a host that fronts for multiple different names, so I'm finding it hard to imagine how finding a name usable for this purpose would be challenging.

This does sound unusual. That said, if this sort of set-up is possible (which presumably it is), it seems unfortunate to make ECH impossible in that scenario.

> On Apr 20, 2021, at 6:00 PM, Martin Thomson <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 21 Apr 2021 11:40:07 +1000

On Wed, Apr 21, 2021, at 11:30, Carrick Bartle wrote:
> This does sound unusual. That said, if this sort of set-up is possible 
> (which presumably it is), it seems unfortunate to make ECH impossible 
> in that scenario.

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?  If that could be shown to be impossible (or even just quite hard) under some reasonable set of conditions, then I might change my position.

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 20 Apr 2021 18:48:53 -0700

> 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.

> On Apr 20, 2021, at 6:40 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Apr 2021 03:03:22 +0100

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.

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 20 Apr 2021 19:05:55 -0700

> 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 <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> <OpenPGP_0x5AB2FAF17B172BEA.asc>_______________________________________________
> TLS mailing list
> [email-masked]

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 21 Apr 2021 12:10:10 +1000

On Wed, Apr 21, 2021, at 11:48, Carrick Bartle wrote:
> possible in cases where the client-facing server doesn't have a name.

That in turn implies that getting an IP-based certificate might be easier than a DV certificate (and the associated name).  I'd need more supporting evidence to believe that.  Under what conditions could that be true?

---

From: Carrick Bartle <[email-masked]>
Date: Tue, 20 Apr 2021 19:13:48 -0700

> That in turn implies that getting an IP-based certificate might be easier than a DV certificate (and the associated name).  I'd need more supporting evidence to believe that.  Under what conditions…

I'm not making any claims at all about the ease with which one can get different types of certificates. I'm only stating that it's possible to get IP-based certificates, and people do, and thus it's possible to have a client-facing server that has an IP-based certificate.

> On Apr 20, 2021, at 7:10 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Apr 2021 14:44:05 +0000

>    All that said, IP certificates are naturally a feature with narrow applicability.  For something like ECH fallback, which should be rare, we benefit more from reduced options and simplicity than…

I strongly agree.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Apr 2021 09:26:20 -0600

On 4/20/21 7:00 PM, Martin Thomson wrote:
> The Web currently recognizes IP certificates.  The specs, thanks RFC 6125, largely missed this,

The scope of RFC 6125 was already huge so we explicitly specified that
IP addresses were out of scope. See §1.7.2. :-)

Peter