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

[Dennis Jackson <[e-mail]>]

Ah, I wonder what the motivation was for it being a MUST rather than a 
SHOULD.

That still leaves open sending a private use value - which would allow 
you to de-conflict with others uses.


On 04/04/2024 17:11, Jonathan Hoyland wrote:
> Hi Dennis,
>
> RFC 7250 Section 4.1 says:
> If the client has no remaining certificate types to send in
>     the client hello, other than the default X.509 type, it MUST omit the
>     client_certificate_type extension in the client hello.
> That seems to explicitly exclude sending the single entry 0 to me.
> Regards,
> Jonathan
>
>
> On Thu, 4 Apr 2024, 16:43 Dennis Jackson, 
> <ietf=[e-mail]> wrote:
>
>     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
>     _______________________________________________
>     TLS mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls