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=40cloudflare....@dmarc.ietf.org> 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 <mo...@iki.fi> 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
> TLS@ietf.org
>
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
