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, <david...@chromium.org> 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 <jonathan.hoyl...@gmail.com> > 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
