Hi TLSWG,
I have read draft-jhoyla-req-mtls-flag-00 and the ensuing mailing list
discussion. I also watched the recording from IETF 118. I fully under
the use-case where trusted client bots need a mechanism to indicate to
the server that mutual certificate based authentication is desired.
Unless I am mistaken, it has probably slipped under the radar of the WG
that this indication is already achievable by using the
client_certificate_type extension defined in RFC 7250:
https://datatracker.ietf.org/doc/html/rfc7250 with certificate type
value = 0:
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3.
The table in section 4.2 of RFC8446 even mentions that the extension can
be included in the ClientHello:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2, thereby
ensuring that the server sends a CertificateRequest message in response
to the ClientHello received.
If it is indeed the case that the client_certificate_type extension is
suitable for the use-case, then perhaps it is preferable to not have a
separate flag. Otherwise, it would make the state machine at the server
more complicated (for example: handling a ClientHello with both the mTLS
flag and the client_certificate_type extension).
--Mohit
On 10/23/23 18:22, Jonathan Hoyland wrote:
Hey TLSWG,
I've just posted a new draft
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-jhoyla-req-mtls-flag-00.html&data=05%7C01%7Cmohit.sethi%40aalto.fi%7Cb1134d8723b640fe8bd608dbd3dc0418%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638336714142818762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XqLqd8JkVfEKN4xcdZqKAUUwnOgCXufkLJV8XERYILo%3D&reserved=0>that
defines a TLS Flag
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-tls-tlsflags-12.html&data=05%7C01%7Cmohit.sethi%40aalto.fi%7Cb1134d8723b640fe8bd608dbd3dc0418%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638336714142818762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6yU2bDzoyiKFhySa3kiVgSvNS5MgZkaYmZlVhBu83KI%3D&reserved=0>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
