Re: [TLS] Request mTLS Flag

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