Re: [TLS] Adoption call for TLS Flag - Request mTLS
Mohit Sethi <mohit@iki.fi> Sun, 14 April 2024 19:29 UTC
Return-Path: <mohit@iki.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4467DC14F60E for <tls@ietfa.amsl.com>; Sun, 14 Apr 2024 12:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EALJRPd0uGH for <tls@ietfa.amsl.com>; Sun, 14 Apr 2024 12:28:56 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EAEC14F5FB for <tls@ietf.org>; Sun, 14 Apr 2024 12:28:55 -0700 (PDT)
Received: from [10.48.2.193] (85-76-33-161-nat.elisa-mobile.fi [85.76.33.161]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: mohit) by meesny.iki.fi (Postfix) with ESMTPSA id 4VHgMm1d1DzyQf; Sun, 14 Apr 2024 22:28:52 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1713122932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zKNNK0opMHNYbOs570C3SbeB6THDtXHyjJ3qx414I1s=; b=shgY6iRuaQVdNe3zL3y/XuQOdaVzBYNVxWlVw3FRPGfhdIQlRbqd9td1N53QQ/fB/PtnTw cosZav+GvPO5D1DjLcHdVLv0rFulZqsB2pKgsMdGOsQRAPvErd7UFT0kllDDba5UD38/dJ jqvYv2HeKE864aLOtSbtZ8M1/Ajsl/4=
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1713122932; a=rsa-sha256; cv=none; b=B8Er41YPmO63xKqajww5h0NkBCxkz1ScocFe+jqcJJ05mbdBw1uv+RYKGeQ8hw4ohGlkn7 OeaYrOB1DS6Wc6iqc7n3cvu790FBMlmXo8YpqI3qfnKW6zKAbBsiRQgeZW2pwXdI4XwrWp KWWG96I1njzuhUMWHnZ+U+0x07lrwRw=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=mohit smtp.mailfrom=mohit@iki.fi
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1713122932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zKNNK0opMHNYbOs570C3SbeB6THDtXHyjJ3qx414I1s=; b=Lp9fymKi3uJL9fPDdxlUAq2LOuUVYsdgowXblaSvc9nbXf+44ztbN1F3hqnU0kYMlCeccI qHogm+ynNbrZ4LN8Cq9siIcquNrRbJR0WOqdfGiElWbTMVQdd7DRbHtVyTNlNTkMlriPkv zPIlgTkjbSsPoMFkFZ5A0BFeOuNZplM=
Content-Type: multipart/alternative; boundary="------------pn9sShNgg2Fw8fn4WRkT0aGo"
Message-ID: <9b58791d-dcb1-4ef5-bc94-95da078f23aa@iki.fi>
Date: Sun, 14 Apr 2024 22:28:51 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Jonathan Hoyland <jonathan.hoyland@gmail.com>, Dennis Jackson <ietf=40dennis-jackson.uk@dmarc.ietf.org>
Cc: tls@ietf.org
References: <8957179A-14D2-4947-B196-B68988B0E3CA@sn3rd.com> <1c42a223-8abc-472a-bb8d-a7827f5b0f06@iki.fi> <CAG2Zi20=Azki7Qp2rgi+ixdCojTr8kbrP6wBiYX2J7Xy94b4Jg@mail.gmail.com> <CACykbs3V7huBGqUnh5=qcoqHftvdNTsk+Yyc0uJkcOPqZk5bMQ@mail.gmail.com> <3a32b9f5-ebe9-4e8e-9672-860324aaa8ac@dennis-jackson.uk> <CACykbs3esuif1jqfJkTYaQ_ahH_PRS6zg9UgMXTXX0uBj1M9Kw@mail.gmail.com>
Content-Language: en-US
From: Mohit Sethi <mohit@iki.fi>
In-Reply-To: <CACykbs3esuif1jqfJkTYaQ_ahH_PRS6zg9UgMXTXX0uBj1M9Kw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/I3vof94ScyVhZbYT8cQ29Yag3Wc>
Subject: Re: [TLS] Adoption call for TLS Flag - Request mTLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Apr 2024 19:29:01 -0000
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.uk@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.com@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 <mohit@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] Adoption call for TLS Flag - Request mTLS Sean Turner
- Re: [TLS] Adoption call for TLS Flag - Request mT… Salz, Rich
- Re: [TLS] Adoption call for TLS Flag - Request mT… Christopher Patton
- Re: [TLS] Adoption call for TLS Flag - Request mT… Eric Rescorla
- Re: [TLS] Adoption call for TLS Flag - Request mT… Watson Ladd
- Re: [TLS] Adoption call for TLS Flag - Request mT… Mohit Sethi
- Re: [TLS] [EXTERNAL] Re: Adoption call for TLS Fl… Andrei Popov
- Re: [TLS] Adoption call for TLS Flag - Request mT… Eric Rescorla
- Re: [TLS] Adoption call for TLS Flag - Request mT… Salz, Rich
- Re: [TLS] Adoption call for TLS Flag - Request mT… Christopher Patton
- Re: [TLS] Adoption call for TLS Flag - Request mT… Jonathan Hoyland
- Re: [TLS] Adoption call for TLS Flag - Request mT… Dennis Jackson
- Re: [TLS] Adoption call for TLS Flag - Request mT… Mike Bishop
- Re: [TLS] Adoption call for TLS Flag - Request mT… Eric Rescorla
- Re: [TLS] Adoption call for TLS Flag - Request mT… David Schinazi
- Re: [TLS] Adoption call for TLS Flag - Request mT… Dennis Jackson
- Re: [TLS] Adoption call for TLS Flag - Request mT… Jonathan Hoyland
- Re: [TLS] Adoption call for TLS Flag - Request mT… Mohit Sethi