Hi Jonathan, all,
Thank you for explaining why you think client_certificate_type extension
is unsuitable. And apologies if you had also explained this earlier. I
somehow don't remember seeing a response to my previous comment about
the possibility of using the client_certificate_type extension
(https://mailarchive.ietf.org/arch/msg/tls/g3tImSVXO8AEmPH1UlwRB1c1TLs/).
Thank you for referring to the text in RFC 7250. However, if we look at
Section 4.4.2 of RFC8446
(https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2); it has
the following:
If the corresponding certificate type extension
("server_certificate_type" or "client_certificate_type") was not
negotiated in EncryptedExtensions, or the X.509 certificate type was
negotiated, then each CertificateEntry contains a DER-encoded X.509
certificate.
At least to me, the part on "or the x.509 certificate type was
negotiated" implies that the client_certificate_type and
server_certificate_type extensions can indeed be used to negotiate the
usage of x.509 certificate type.
I certainly find the approach of using the client_certificate_type
extension better than an mTLS flag. Maybe initially the extension was
predominantly designed for use with RPKs, but I think the extension is
well-suited to indicate the availability of an x.509 certificate on the
client. Besides, mutual authentication (mTLS) is not exclusive to
certificates. It is perfectly possible to have mutual authentication
with RPKs and with PSKs.
--Mohit
PS: Regardless of how the adoption call ends and which mechanism we
pick, I do think a mechanism for a TLS client to solicit a
CertificateRequest from a TLS server is needed. Based on the discussion
thus far, I still prefer using the client_certificate_type extension.
PPS: Not sure if it is necessary or the right place, but RFC8446bis
could clarify the usage of the client_certificate_type extension for
soliciting mutual authentication. I'd be happy to submit a pull request.
On 4/4/24 19: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=40dennis-jackson...@dmarc.ietf.org> 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=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/
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2Fg3tImSVXO8AEmPH1UlwRB1c1TLs%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189262944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=pZpl3Dn0qP43J4Rm8GsI%2FOp4iR6YHLmrL%2BUQYz0KrNM%3D&reserved=0>
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
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7250&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189274092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2%2Fg8xy1L8rk2Q54bRat%2BiX9QOKdbOvg2G6dX3siwgTk%3D&reserved=0>
with certificate type
value = 0:
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Ftls-extensiontype-values%2Ftls-extensiontype-values.xhtml%23tls-extensiontype-values-3&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189282439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Bz%2BIM9tHjBKrc1cUHmrmCYocL3BOr1gc7KDnRk9vO48%3D&reserved=0>.
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
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8446%23section-4.2&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189292067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OZ752BrkE%2Bwq8Q1G37sgQwPeRoNA9VRYfPjzsEvg6h0%3D&reserved=0>,
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%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189300228%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HekLxwfp30r3ta9io%2BLHlPXT7pep%2FCCJy6PpozTvKFQ%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%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189307901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=7CeTVUko7HlTudWZBh0jGvoaVaPbSmLeGCRt%2F2SIzbM%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%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189314763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DsQv7czQPC9LGyTNX1yi9%2BuSJgFfUk3eGZItbKPD%2BJw%3D&reserved=0>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189321416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rgdx8RAYTYWv%2F6benPttFJ4txy%2FxEtyZQS1VqzdAA7c%3D&reserved=0>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189327967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=I8Y029tFojJTnLdGKvyVL%2F6YifYLGi3nQLmJRXBRX3o%3D&reserved=0>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189334500%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fVUTAcYPdsgp%2FMJ%2BKm8%2FHbZUearXI%2BfoFB952Rr0RDs%3D&reserved=0>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C2a218af7d8c14bd30a8108dc54c22f36%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638478440189340826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LZBOpnnA%2FMpt5VDcBRnt8XXosbcRgy16t6MhfnrWoX4%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
