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
