[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345

Kyle Nekritz <knekritz@meta.com> Wed, 12 June 2024 19:56 UTC

Return-Path: <prvs=18935df169=knekritz@meta.com>
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 8A351C1E8E19 for <tls@ietfa.amsl.com>; Wed, 12 Jun 2024 12:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (2048-bit key) header.d=meta.com
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 jqJh5ZCxJIkj for <tls@ietfa.amsl.com>; Wed, 12 Jun 2024 12:56:11 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ECCC09E1BD for <tls@ietf.org>; Wed, 12 Jun 2024 12:56:11 -0700 (PDT)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 45CHuuXJ008316; Wed, 12 Jun 2024 12:56:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=cc : content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=s2048-2021-q4; bh=5aXRCdaEzblmaodxnUvIG9wu7AMnJXhkoXcfD+aVv9U=; b=gJDSpj3FJzmm7t0nfuSeYtttuWtJZtDZD/9RqppOj9Zt8KeWo9V+e4i82lGaZ3m1DUR2 IkvRh3vO+9u5zRaIzCfVZfYCjcAS02No0CCYOEM6nyf7EQ71XJ2YcPqdKfDbJt0lV1OE +iuhdiJulFhBcGApu3AzvFcsO54nEVOAxiXr32Rh6HfkY8Eyitus2iSFTlJsTh6DaGuZ BIzY9hX0RB3y2S2QBlOwzBY8NsBVs/rxmMXTnvzsVb8uRY3JjR6lazXMdb/NSEV9OzJM dundhwjD5vU251vba+Fpu1UGVtqnN6b2xjmPnxBxAxm+UY1kr+QXuvAFBDvt5nH6LIF4 Uw==
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2174.outbound.protection.outlook.com [104.47.55.174]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 3yq79wcjh8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jun 2024 12:56:09 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L7b1qrQxrSgjS+x2B1xk9v5+PT7qTMu7g1+wGYhFuI+RHBch0lcie3NeWspG4KW44GasmyF2JwmiZtrClPSl3G3HScjkn+qWsVkSADepdbyYqMoZJ9N/wyb7Gkes8ARHtf2MXGd/HRvBu8lZ9cM3F96mamb/gYvhDAXctnEMywNTa4Ujn+rIXUWq8ayzYs2Q+PXItfAcRSfxrpbNdcf+SUq7NgzhqEn6XsWlm+UfIJ379QrZhFI0hY6FXqrcYZCSFHnOvsn/dbeAVWZXfDly4ZQbr8QYi3c8LBqa69i2jt9FDG2RVFmr+A4WT3H9nRhb62WoyZaOMqxYyx2e5XkxQQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=bRD+gHK1t9MJn8ElbOl/chTDnTiTYHMU4Z7UKO1xdes=; b=f6jxkAY5VAuArYTaqcPaiNo8CD01aby9ameDpfixJDHp3InCyPn878S+uAOwhAZSXK8KUCDdNFI0lkrNL1YgtcPqdDcmokK6auibF2zgQbBMkDJP46Po6taKhsyltMyNLYzkIwM7vk2wkVCs0oGhIOkt2zvHU8NxDkkTK93usL4MjgI9VxbrbLBRex/D3eLmv39gQXOlW7nwKd747Ult7vhv+bAayrry6fZGdWZOy3vOnK9udtIVnttNYkO9bViopSYAztIizW4QCN8Oc9jG3Z76+5wjpYLKwrXz4fD8ub2qNnCaBS4phC0DCZwMyEnWR8gtuj8q8AD1dMmBdLvCCw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=meta.com; dmarc=pass action=none header.from=meta.com; dkim=pass header.d=meta.com; arc=none
Received: from SJ2PR15MB5671.namprd15.prod.outlook.com (2603:10b6:a03:4c1::19) by PH7PR15MB5807.namprd15.prod.outlook.com (2603:10b6:510:2b5::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7611.22; Wed, 12 Jun 2024 19:56:06 +0000
Received: from SJ2PR15MB5671.namprd15.prod.outlook.com ([fe80::a025:a1d3:960b:9029]) by SJ2PR15MB5671.namprd15.prod.outlook.com ([fe80::a025:a1d3:960b:9029%5]) with mapi id 15.20.7633.037; Wed, 12 Jun 2024 19:56:06 +0000
From: Kyle Nekritz <knekritz@meta.com>
To: David Benjamin <davidben@chromium.org>
Thread-Topic: [TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Thread-Index: AQHauFtMWKZtiKzbdEeve1omQKYGgbHEknfw
Date: Wed, 12 Jun 2024 19:56:06 +0000
Message-ID: <SJ2PR15MB5671BB8DC1E5FB02092E7346B6C02@SJ2PR15MB5671.namprd15.prod.outlook.com>
References: <E4F01839-B529-4A07-880F-DED4FE2512B5@sn3rd.com> <SJ2PR15MB5671A04B272DEEB7E620E4C7B6FA2@SJ2PR15MB5671.namprd15.prod.outlook.com> <CAF8qwaADfQA-XVJv=E+09yEVaYNMUojCX07W3B-bO441rCsumg@mail.gmail.com>
In-Reply-To: <CAF8qwaADfQA-XVJv=E+09yEVaYNMUojCX07W3B-bO441rCsumg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SJ2PR15MB5671:EE_|PH7PR15MB5807:EE_
x-ms-office365-filtering-correlation-id: 98acaa4e-4f7c-4fc5-0939-08dc8b19b296
x-fb-source: Internal
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230034|376008|1800799018|366010|38070700012;
x-microsoft-antispam-message-info: luAbfgAz6BmK0QdLRlR2G8UGz+s9ChYhvAMDfsJbSu36w69HYwIW8kiF40DBZ+CY+FNcS5eo8acr+k2ZCcmTT/l11gml0G6YP7b+bJiTAmFNGasBL+SOMFEN5PiOwTPYE7Gmhsn9g80n9ZwpxcWrpH4nL/++KgVCS7ejAzQDX0NHPY6Rn5nd9I94tixzTnVhxZ3Y/I6I1L/HMBoexUF0Jcb/VLcTINBNGp2W0jfMPEKNv+hCqEsoNBg3UtiYql1N5tFM6RbS50zJnppAXr0o54WRJ0w2q+Xu+IOiCHsnAkNy8oVSHDfbPJSKoKhXkdIqubmiEgbAI6S0KxBnbu7J9bBzMyGGfwW/DfPoXcQiFy5J18fA2+QJiTWyUxZN2fHUaT0h+NGiVi3YVQHDGAk0bJyA7YBrps66rpq/PNldYcHXT1grmztl1KQvQDT42zk9M+BjKHdgSUwtYA1qfQYfPzvf8XhbYl14NuGDZMfE8D0MSujfdhKkE3fQpTTclleCsp4ypWUeTznpsSlmRX6jzNG9fquN+wAREeXMz7ySGN2bCJ2RMXad2R77EG77bvaCiW4d40Jl2Q842uPf5/hLSrVPTXHFvn2/Y6bA4FDbY80bxoAjiAIlbC4G4sy4/EQnR8rTvz3zvMEhra8xKv9zrUqpWkfHTeXUTCROfFOqlJHT3UhcXDSJzrF5INzSzq8TlCFX9ZnS0Cc7/TH8k2Q54ne0ALf9fI3HpTF+sl4hO6626GjuyFqRznVgEvG5sbZN5r2HTI/FJmOpZiFZYQCxxDaBQi3PSCCOyNPZ7hjvE8fIb8ujRhc9FbA+4qymG1wZUC4143GExqvRBwnKOsaoMWtej2T6thDyx+xClL58W8pl/BSbxNH7F3V/eQdD3xysJvWg2j0Mz4kcUgwfpnjC0wugwOe1D4UV1JKKTjuZczkY6XBtIPAN9h6kadMd8SR/Pf4XLFtqh9tjQMlkIGm6mxKBYAyxwbNEM5D7febJ4cn/DAnVX3OM0LICH0JeFAs3Ipbmkiz/8NSTRknz2MCeX+MJTVzNoVVysa9W5iJyI/Y8PRoG6PVLssQ8vXgOSMJvMmpX7RpXnlky4L4iThoTvB8FlVee70Jlw0K446IKobRbu1oyQHVyYIo/Cbki3pjRq67zQAVg1eyYb6ocAOsBeGh9l3dlckc3XpBUUM4yKRI/sJ2CxtVnJOwDqpbY+UILby5zM2vlrKTW3TL0vBxwrfH+eQiWWxPdzfZ8VE6/xC6H9WdPVnRELZTi6WCyP/A7jfDkZwc6oxi1coU97xbdda/kOyFJsRxKxpm3+0o2V96bHBTALkuwCxVpw0HJ5L3c
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR15MB5671.namprd15.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230034)(376008)(1800799018)(366010)(38070700012);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Hr5Af3kRIHBTsR+YU6I1opTIjhtwF9n2GyaGhGS3fdZu05tQJIwCoGyjwjOlOMg8hVqZ/Bo/5WgFWyecw+ZK/4tc7xN+ztj1QJ+y5kcDR1excyO2vCHIN2L4pMwjtXfXqE/PE7FJeCG4e9Wd/MpADHA7MrZPzN5RKgjWUdrBwrRd4m+1FLCFsASQ4LBNKBitD3PXOz8Cx3wDhUP2Z/82x2V/xm44BxiXLGVnF+rSlAYT1HrzlLKr3yrlA3oRroEznCh4nrPHruTlK4KL9DIampq7JSS5haWKXCR7PzrMt/hzzVyF4JtqhRtKrAN4HLCkRfPvdXuhebETtTRbyG9xlOOYgkS7gS2RVyCJF+W34sg6uGII6ZtS2jFqgVi1mS+BtfkXS4WcziemTeWtXWHG/Qx3e9B7cH4sOCZdprOwpxBtDeJZctXFQvxFDbB45GwktK7CJOEUuZuqNtnFQpFToPHlY+zuEsnFlKDiJ1p4KFYfaFZNMiZFAf07/5VIinEjBejjS1mmrY9bVvvrDfCboIms84AYvDxzucnp/0qJwNAKtngpNr067VWhxItzb8TJPXeid9oFni3mpf9pyQzYWg5ce2aBXOHhkz1o5JK4dhA6hiP7Q5FeuO7ZBaVX88q7Puy9VAGNrG7RKE6sQEQTYNjtAWE6P1gtPfih3gFzrrFNt3YpE+eNQo0hur+V7jBgSrHRxT1zC9blsSaP5xYvacmyo0y3K0MNFTPd6Uh06PkCYTY4RirPWZnpYR94MKDeHQB493hl7aJi+yR61qDXRBuTykP0Lsreg5wzXo+e7nASludAK5GzAue77caBuynD1c42o4XcaSPDEBWnl6hMROsHiDW9OjqEgXifeumDcHV0kLc0Sy00RG2XdLj4BeYHztWBn+0csjlIPjC0tTBr728R1pG1uRtCGe4UVqSFu377IPndK5+5Jj9wzDJ4dN2VMtOsHu3wz6CuUNRyyCoPPUjrDHFnaPdeFcnUCi/8i9S6Nkua9v90vGQQQVMje+KEElI0z9GtBz/KMmZkOU0plV8d1WR0JXXiBHat/rsHIJrp6Peuejhyu0h6YCpS+rfhAE3+NuuJ8dIJKreoFEmpaCRJq02ibg/0tKCN84yBfEnDFmlJ0xjEQ63SSWnAr28Lf8Tq5BB3sRcZ4zfyTTCcX1BrCtoPSnuIqTFdips1VL+OmBDnkyK3twpIKkrSTVKueNzEfbggTREnGOTXhY+DtI2jEvoofh5tYgQUVuWiOcWJc0Pj2f166LQ44LLQFd9+mI4lA26e3Kcyk6kDz551fA5hXUBaCSs8g0fkebyHNRrk4RnMxBWmDNbBpUAFO2tr6sOF23Hp/cQ2glkMUAFaFMpxzdTPsvXpo+NwUYlOXYZPGOzlDot2j3plP8sI4OFs2j8r0vYxRlnJS/xwkybRxABtPSGm2mI/pXg16bY09eOBDLwRif7AXG6pE0O2d9rAl0n8Nt6BkP5OSWUjhS83FFUJWW1uTHgCt1M71f36llcDrVzvcXpS6VbzE/MK0AJP5aFgrz2KEqec6grCyenirlLPq/3aenLZBXrzIDQUaaue7lVkX27m+bqpAryATvc4t62LOIbMtQTmpOQZEEt9GA==
Content-Type: multipart/alternative; boundary="_000_SJ2PR15MB5671BB8DC1E5FB02092E7346B6C02SJ2PR15MB5671namp_"
X-OriginatorOrg: meta.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR15MB5671.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 98acaa4e-4f7c-4fc5-0939-08dc8b19b296
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2024 19:56:06.6349 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: PWRVofukEOlcAkaEDs8mahut/LPHzOWuqjg4X0QCzXF6JWZsw5dfKk214AjE8z53X+1W2dNOx5n6b29Tfryg7w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR15MB5807
X-Proofpoint-GUID: AZlOs-hDe8C--xhBrDq6fzOjjD-CcLLF
X-Proofpoint-ORIG-GUID: AZlOs-hDe8C--xhBrDq6fzOjjD-CcLLF
X-Proofpoint-UnRewURL: 0 URL was un-rewritten
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-12_10,2024-06-12_02,2024-05-17_01
Message-ID-Hash: YZQGMYMV3CKAZPQY7W3A4BAE7I4IIYPL
X-Message-ID-Hash: YZQGMYMV3CKAZPQY7W3A4BAE7I4IIYPL
X-MailFrom: prvs=18935df169=knekritz@meta.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: TLS List <tls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JKXjXzzV4Pqw2LMIT0r5WLRoFlY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

Yes, my worry is really around enforcement of a property that can’t be strictly adhered to. How about something along the lines of:

    Until receiving a KeyUpdate from the peer, the sender MUST NOT send
    another KeyUpdate with request_update set to "update_requested".

    Note that implementations may receive an arbitrary
    number of messages between sending a KeyUpdate with request_update set
    to "update_requested" and receiving the
    peer's KeyUpdate, including unrelated KeyUpdates, because those messages may already be in flight.

I think this would make the requirement more clear, and avoid enforcement of a requirement that can’t be strictly followed.

From: David Benjamin <davidben@chromium.org>
Sent: Thursday, June 6, 2024 5:48 PM
To: Kyle Nekritz <knekritz@meta.com>
Cc: Sean Turner <sean@sn3rd.com>; TLS List <tls@ietf.org>
Subject: Re: [TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345

Regarding 1343, the PR is a rule on the sender, not the receiver. After all, it says "The sender MUST NOT". It is not a rule on the receiver. We have interop problems *today* when one side sends too many KeyUpdates, triggered by data
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd
Regarding 1343, the PR is a rule on the sender, not the receiver. After all, it says "The sender MUST NOT". It is not a rule on the receiver.

We have interop problems *today* when one side sends too many KeyUpdates, triggered by data received. The PR does not ask receivers to enforce stuff, but (mostly) prevents senders from tripping receiver DoS limits and thus causing an interop problem.

I say mostly because the scenario you mention is a good one. I hadn't thought of that. But that scenario is not an interop problem introduced by 1343. It's a scenario that 1343 doesn't fully solve, but still dramatically improves. Prior to 1343, a server with a buggy update_requested policy would send 3GB / 16K = 196,608 KeyUpdates for every 4 GB of data sent by the client, assuming full records. This will very, very easily trip DoS limits and quickly cause the connection to fail.

1343 clarifies that this update_requested policy is wrong sender behavior. You're right that 1343 doesn't completely solve the problem. The server will misinterpret the client's own KeyUpdates as response and send 1 KeyUpdate for every 4 GB of data. That is, however, an improvement by a factor of 196,608x. It would take a lot more traffic to trip a DoS limit under that scenario. Ideally we'd come up with an even better sender rule, but I suspect we cannot do so without completely redesigning updated_requested. During TLS 1.3's development, my position was that update_requested was a mistake and we should remove it, precisely due to its propensity for DoS and interop problems. I think that position has proven to be the right one, but it's too late to remove the feature now. 1343 is the best option I see to fix it right now.

On Thu, Jun 6, 2024 at 1:46 PM Kyle Nekritz <knekritz=40meta.com@dmarc.ietf.org<mailto:40meta.com@dmarc.ietf.org>> wrote:
I object to 1343 because I don't think it can be implemented without risking interop problems. There is nothing tying a KeyUpdate response to the KeyUpdate that requested it, or distinguishing it from an unrelated KeyUpdate. As an example of how this can cause practical problems, say we have two peers with the following policies:

Client: sends KeyUpdate with update_not_requested every 4GB of data sent (which is a reasonable policy, effectively making sure the client doesn't violate its own data limits, and letting the peer handle theirs)
Server: sends a KeyUpdate with update_requested every 1GB of data sent by either peer (similar to the motivating example in the issue)

If, like in the example in the issue, the client is sending a large amount of data, and not reading anything from the server until it's done, and the server isn't sending any response application data, the server will send an update_requested KeyUpdate after 1GB of data from the client. The server will then be blocked from sending more KeyUpdates due to the proposed requirement. However once the client sends 4GB of data, it will send an update_not_requested KeyUpdate. To the server, this will appear to be a response to it's KeyUpdate request, and it will be free to send another update_requested KeyUpdate. However, to the client, this will appear as a redundant KeyUpdate, since the KeyUpdate it sent wasn't actually in response to the server's first KeyUpdate. If the client enforces the MUST NOT added in the PR, this will cause a failure.

-----Original Message-----
From: Sean Turner <sean@sn3rd.com<mailto:sean@sn3rd.com>>
Sent: Monday, June 3, 2024 11:38 AM
To: TLS List <tls@ietf.org<mailto:tls@ietf.org>>
Subject: [TLS]Consensus Call: -rfc8446bis PRs #1343 & #1345

!-------------------------------------------------------------------|
  This Message Is From an External Sender

|-------------------------------------------------------------------!

Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been submitted (and discussed) that include changes to normative language:

- #1343: Forbid the sender from sending redundant update_requested KeyUpdates
https://github.com/tlswg/tls13-spec/pull/1343

- #1345: Forbid the sender from sending duplicate supported groups entries
https://github.com/tlswg/tls13-spec/pull/1354

The discussion so far seems to support consensus to merge these PRs. If you object, please do so on the issue or in response to this message.  Absent any pushback, we will direct the editors to incorporate them in two weeks' time.

Cheers,
spt
_______________________________________________
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-leave@ietf.org<mailto:tls-leave@ietf.org>
_______________________________________________
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-leave@ietf.org<mailto:tls-leave@ietf.org>