Re: [TLS] Adoption call for TLS Flag - Request mTLS

[Dennis Jackson <[e-mail]>]

Hi Jonathan,

My reading of RFC 7250 is the same as Mohits. Although the RFC talks 
about raw public keys and a new codepoint for them, it is building on 
RFC 6091 which defined a similar extension and the X509 codepoint.

It seems fine for you to send the client_certificate_type extension with 
the single entry 0 (X509). You also have the option of using a value 
assigned for private use (224 and up) for your specific use case of 
indicating a search engine crawler willing to provide a client cert.

Best,
Dennis

On 04/04/2024 11:17, Jonathan Hoyland wrote:
> Hi all,
>
> Thanks for the feedback here.
>
> With respect to RFC 7250, as I mentioned earlier on list, there seen 
> to be two issues. First it changes the semantics of the extension 
> slightly, and second the RFC explicitly excludes x.509 certs.
>
> IIUC the semantics of the extension are "I have a weird client cert", 
> not "I have a client cert".
>
> With respect to whether this needs to be a working group item, I'm not 
> particularly averse to this being an independent document if that's 
> where the WG thinks it should go.
> In my opinion, however, there are two things that it would be good to 
> get input from the TLS WG on.
>
> One, this is a change from all previous versions of TLS in which the 
> client cannot induce auth, does enabling this break anyone's assumptions?
>
> Two, I'd like a low flag number because it saves bytes on the wire, 
> but there is a discussion to be had as to how common this flag will be 
> versus other flags.
> (Non-attack) Bot traffic is very common, but it's not the majority of 
> traffic by any means.
>
> Regards,
>
> Jonathan
>
>
>
> On Thu, 4 Apr 2024, 01:17 Christopher Patton, 
> <cpatton=[e-mail]> wrote:
>
>     It would be great to here from Jonathan (the author) if RFC 7250
>     is already sufficient for this use case.
>
>     On Tue, Apr 2, 2024 at 10:23 PM Mohit Sethi <[e-mail]> wrote:
>
>         Please see my earlier comment regarding this draft:
>         https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/
>
>         In summary: the functionality of this draft 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.
>
>         OpenSSL already implements this extension since it was needed for
>         support raw public keys (RPKs).
>
>         As stated earlier: 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.
>
>         Therefore, like Ekr, I am mildly negative on adopting this
>         document but
>         for different reasons.
>
>         --Mohit
>
>         On 4/3/24 00:52, Sean Turner wrote:
>         > At the IETF 119 TLS session there was some interest in the
>         mTLS Flag I-D
>         (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D&reserved=0
>         <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jhoyla-req-mtls-flag%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681199391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ERzWFcuBlAfobNyGCcgKDhCl9wex9LOQ%2F3yPYC7idfU%3D&reserved=0>);
>         also, see previous list discussions at [0]. This message is to
>         judge consensus on whether there is sufficient support to
>         adopt this I-D.  If you support adoption and are willing to
>         review and contribute text, please send a message to the
>         list.  If you do not support adoption of this I-D, please send
>         a message to the list and indicate why.  This call will close
>         on 16 April 2024.
>         >
>         > Thanks,
>         > Deirdre, Joe, and Sean
>         >
>         > [0]
>         https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D&reserved=0
>         <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2F9e2S95H9YgtHp5HhqdlNqmQP0_w%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681208049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=eEU6ZPJ5cmfqLHQuM3UYXrFKCJuKaaJVc8Ssk5erRjk%3D&reserved=0>
>         > _______________________________________________
>         > TLS mailing list
>         > [e-mail]
>         >
>         https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D&reserved=0
>         <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C42877de6d3d64135e49e08dc534a463b%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638476825681214744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2B9CGIKB31GI9RMQG62I1rTnbHaDPfSynvlmwrkPn%2FpQ%3D&reserved=0>
>
>         _______________________________________________
>         TLS mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/tls
>
>     _______________________________________________
>     TLS mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls