Re: [TLS] Request mTLS Flag

[Jonathan Hoyland <[e-mail]>]

Hi David,

On Mon, 23 Oct 2023, 17:26 David Benjamin, <[e-mail]> wrote:

> > So in my mind this is something that will (almost) never be sent by
> browsers.
>
> What cases would the "(almost)" kick in? This extensions model just
> doesn't match how client certificates work in browsers. I'm not seeing any
> interpretation beyond "always send" or "never send".
>

So I was thinking about a case where you're behind some TLS terminating
proxy. Assuming the proxy requires mTLS for every connection and the
middlebox wants to treat misconfigured boxes differently, maybe you would
use something like this.
I would have said never,  but never say never, right?

>
> > For example identifying a web crawler, and either allowing or
> disallowing it.
>
> I'm not following how this identifies web crawlers, unless perhaps we're
> using the term to mean different things? I would expect web crawlers to
> typically not do much with client certificates, and to typically *want* to
> index the web in the same way that humans with web browsers see it.
>

So typically web crawlers don't use mTLS, they rely on things like
publishing their IP range for auth, which isn't a great signal.

If we could reliably identify e.g. GoogleBot then we could skip some of our
bot detection systems for definitely-allowed traffic, allowing us to be
stricter with unknown traffic, or of course, explicitly-disallowed traffic.

There is an argument that one could show bots different results to humans,
but given that this is explicitly aimed at bots that we approve, I don't
see the incentive. Maybe improved TTFB or something?


> > I don't think this leaks more info than a dedicated endpoint (even
> accounting for ECH), and from a security perspective is just a hint.
>
> The difference is the dedicated endpoint case only kicks in once you are
> actually talking to a site that is deployed that way. A ClientHello flag
> would likely be sent unconditionally, because it's too early to condition
> it on much.
>

So in my mind this is sent by a bot that is crawling the entire web. It's
automated (as opposed to human triggered), and this is an optional hint, so
it doesn't matter if there's a privacy leak in that way. (Although that's
an interesting thought, do bots have a need for privacy?)

Regards,

Jonathan



> On Mon, Oct 23, 2023 at 11:58 AM Jonathan Hoyland <
> [e-mail]> wrote:
>
>> Hi David,
>>
>> So in my mind this is something that will (almost) never be sent by
>> browsers.
>>
>> This is aimed at bots, both internal and external. For example
>> identifying a web crawler, and either allowing or disallowing it.
>>
>> Currently we identify many bots by IP range and user agent (and a bunch
>> of ML), which isn't always reliable.
>>
>> The web crawler case is where the dedicated endpoint falls over, because
>> crawlers are indexing the human visible web.
>>
>> I don't think this leaks more info than a dedicated endpoint (even
>> accounting for ECH), and from a security perspective is just a hint.
>>
>>
>> Regards,
>>
>> Jonathan
>>
>>
>> On Mon, 23 Oct 2023, 16:36 David Benjamin, <[e-mail]> wrote:
>>
>>> Would you expect a browser user to send this flag? On the browser side,
>>> we don't know until the CertificateRequest whether a client certificate is
>>> configured. We have to do a moderately expensive query, dependent on
>>> information on the CertificateRequest of the OS's cert and key stores to
>>> get this information. This query may even call into things like 3p
>>> smartcard drivers, which may do arbitrarily disruptive things like showing
>>> UI.
>>>
>>> And if we could somehow predict this information, this would leak into
>>> the cleartext ClientHello when, starting TLS 1.3, the whole client
>>> certificate flow is in the encrypted portion of the handshake.
>>>
>>> So, practically speaking, I don't think browsers could do anything
>>> meaningful with this extension. We'd either always send it, on grounds that
>>> we have code to rummage for client certs on request, or never send it on
>>> grounds that we're not preconfigured with a client cert at the time of
>>> ClientHello. Either way, it seems likely to interfere with someone's
>>> assumptions here.
>>>
>>> The dedicated endpoint strategy seems more straightforward.
>>>
>>> David
>>>
>>>
>>> On Mon, Oct 23, 2023, 11:22 Jonathan Hoyland <[e-mail]>
>>> wrote:
>>>
>>>> Hey TLSWG,
>>>>
>>>> I've just posted a new draft
>>>> <https://www.ietf.org/archive/id/draft-jhoyla-req-mtls-flag-00.html>
>>>> that defines a TLS Flag
>>>> <https://www.ietf.org/archive/id/draft-ietf-tls-tlsflags-12.html> that
>>>> provides a hint to the server that the client supports mTLS / is configured
>>>> with a client certificate.
>>>>
>>>> Usually the server has no way to know in advance whether a given
>>>> inbound connection is from a client with a certificate. If the server
>>>> unexpectedly requests a certificate from a human user, most users wouldn’t
>>>> know what to do. To avoid this many servers never send the
>>>> CertificateRequest message in the server’s first flight, or set up
>>>> dedicated endpoints used only by bots. If client authentication is
>>>> necessary it can be negotiated later using a higher layer either through
>>>> post-handshake auth or with an Exported Authenticator, but both of those
>>>> options add round trips to the connection.
>>>>
>>>> At Cloudflare we’re exploring ways to quickly identify clients. Having
>>>> an explicit signal from the client that it has an mTLS certificate on offer
>>>> reduces round-trips to find out, avoids unnecessarily probing clients that
>>>> have no certificate, etc. I think this would be an ideal use case for the
>>>> TLS Flags extension.
>>>>
>>>> I have a pair of interoperable implementations (one based on boringssl
>>>> and one based on Go TLS) which I plan to open source before Prague.
>>>> Obviously these include implementations of the TLS Flags extension, which
>>>> hopefully will help drive that work forward too.
>>>>
>>>> Regards,
>>>>
>>>> Jonathan
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>>