IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

Peter C <Peter.C@ncsc.gov.uk> Sat, 21 February 2026 18:41 UTC

Return-Path: <Peter.C@ncsc.gov.uk>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8854BBB5653B for <tls@mail2.ietf.org>; Sat, 21 Feb 2026 10:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVSwwTZ4pwH6 for <tls@mail2.ietf.org>; Sat, 21 Feb 2026 10:41:16 -0800 (PST)
Received: from LO3P265CU004.outbound.protection.outlook.com (mail-uksouthazon11010000.outbound.protection.outlook.com [52.101.196.0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 89215BB56528 for <tls@ietf.org>; Sat, 21 Feb 2026 10:41:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iafixwuT7ckD8XFPHYpt4voRqCsUJI0Vo4bFzyBELZVavKEq7SpRtOKv6oOSyIVVajCGVcdAj8wUrMqvecJ+IEAP8sN82NWAY1BSHYFhMT0zRU4bsLuNpE0FipXH14SO6lxNiaSXVC62ninZ46d3xj+TtcRzggrSaFiHHO9wcTzRsoERJj0VcWJ8yYoMpiQCL81jF/xJ7u470I8H/3ohmxVqtksVuGOl0opKrXhYKE4kKNGpwCwlUzWhlMY108wkNmGBG2mA179G5cukt/yd8ALY84kuahrePBOQDI8Ch0n6p/nUyRwyZvLENDHKVdkv4y9fe3PpqJclpS3puw4dOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=x5MRZZ7+imVOGDps1j4+MKDRshL78qIaF8JjzqCxOak=; b=cskEOaD0bDyraMSv6OaEXBOWRqma1ICc3BnMGQI5wWtdy70QSQjAJXXuIteiFDRTdm1WkrUX+jazoQkCDsw8urVlBxG0A5mTP47nYAxiBwvIAd/Oz9f2vBfnXwNkXVRm4yaZUMK7llWw++LDG20nVvDI1/RcxCWwtLkF29Y/CJBQkHcVFpWa9FSUAWrWvt3G4Q8/vQSapkZSvIYl0SrfA7BuGGYSfIMBWf//CvuKAxU3yI6ejfF2mstbcjnsdtk7DMe/OizoSNqDiRS+qeaX0VqovmDfmT13EKelSHX7pVgF07t4jk4NdUQ4xXn4XbzwSL/Qc+Lu9jwj9dLhN6nzqg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x5MRZZ7+imVOGDps1j4+MKDRshL78qIaF8JjzqCxOak=; b=kB24zQMCPieJdE+3r1IoS4a6HMWj4R76MKh9VSJs6Af59iAFYygzJ+h2Ugh/xhuEoMQeRBeQDqS1K2TByaT8OZcNYHwyy+5FPGjIkIe9HDqHUi8b3iyxLL4nVDj4tVxyDa7IxImYR8rwK9A+lH/rDTlm9zTHoSuibyfnE5IHEXA5L4Qxd5/b8PLZdnMv/GFjsZW7cCiaJqCf9JidnPlsYWQ8xWMTxwJQLljIO86m5WHcIiSzqoBKAoXQ6v0aaYe39ICXXNUNXFyN/ysirZQ2XGHkrLmdQcOgU0l6LvPQEmBotdherQ5qX9FNS9iUboqGAjfGrS3Ex3jiu7kT2kTG0w==
Received: from LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:31d::15) by CWLP123MB6145.GBRP123.PROD.OUTLOOK.COM (2603:10a6:400:1b1::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9632.19; Sat, 21 Feb 2026 18:41:06 +0000
Received: from LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM ([fe80::f4fd:1da:be9c:c46d]) by LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM ([fe80::f4fd:1da:be9c:c46d%5]) with mapi id 15.20.9632.017; Sat, 21 Feb 2026 18:41:06 +0000
From: Peter C <Peter.C@ncsc.gov.uk>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
Thread-Index: AQHcoQ6WWvnpm4Ui9Ee5DCJh8YqiUrWKT5GAgAATOYCAACrMAIAABuIAgAA3KgCAACwnAIAAQ3+AgAAJhACAAFqDgIAAEfgAgAFGWYCAAGMWgIAAFmmw
Date: Sat, 21 Feb 2026 18:41:06 +0000
Message-ID: <LO2P123MB7051563680FE0C7724A30724BC69A@LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM>
References: <20260218194044.1135896.qmail@cr.yp.to> <7C9C99AA-42B0-4BC7-8F41-39F35754F1C4@vigilsec.com> <MN2PR17MB40310F0A2891942D76C43E60CD6BA@MN2PR17MB4031.namprd17.prod.outlook.com> <2caab265-00ba-4078-b6d0-3a178dabaa61@tu-dresden.de> <CAEEbLAbkV4YxN7cgggckpEp24MLtRZpzs6M4KemBatpzCCcs0A@mail.gmail.com> <MEAPR01MB3654415F735DE96CEE239C78EE68A@MEAPR01MB3654.ausprd01.prod.outlook.com> <aZfbhrFDBp7a0xHL@chardros.imrryr.org> <EB48AB24-A1A2-47C8-9C2C-47C93B9320E7@thomwiggers.nl> <93af0689-4bd3-4f6b-afaf-41869d27fa4d@app.fastmail.com> <CAMtubr3QcHbiP5guhBoiFbFh8tKSD6WNHBJkxxb_AM4Wy5i0=g@mail.gmail.com> <9b71e709-69a3-f3d9-4cbd-d4d521556c55@nohats.ca> <971672FF-31BE-47C4-A478-8FEB60DE3F7A@symbolic.software> <66970fb7-0645-4fff-8b9e-48f6bad3e007@symbolic.software>
In-Reply-To: <66970fb7-0645-4fff-8b9e-48f6bad3e007@symbolic.software>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_d51697e2-b69a-493f-9635-378990918eab_Enabled=True;MSIP_Label_d51697e2-b69a-493f-9635-378990918eab_SiteId=14aa5744-ece1-474e-a2d7-34f46dda64a1;MSIP_Label_d51697e2-b69a-493f-9635-378990918eab_SetDate=2026-02-21T17:43:42.0000000Z;MSIP_Label_d51697e2-b69a-493f-9635-378990918eab_Name=OFFICIAL (No Handling Instructions);MSIP_Label_d51697e2-b69a-493f-9635-378990918eab_ContentBits=3;MSIP_Label_d51697e2-b69a-493f-9635-378990918eab_Method=Standard
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ncsc.gov.uk;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: LO2P123MB7051:EE_|CWLP123MB6145:EE_
x-ms-office365-filtering-correlation-id: 194e7367-7cee-436d-802c-08de7178c5eb
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|19092799006|376014|1800799024|38070700021;
x-microsoft-antispam-message-info: IvA+2VE6nYkSLFZR7l3S/GoA/nxAm5jR5Go/tq0CioMDyQau4asSteQmZG28+iqdaHfbFC+Msuvz8iO0hhF2yBVI5dfo+/VDKk7yWBX6BlV7gVE6RI7GcZgBITW98ZGL2vnptlPI9s4i77FHxvWMOBkcjZQgimvcgFqTfTZiUav/UgWZ2G4wOSerL0buE0mNuH4+FJRWgLfRDeZYhJumxOU7tL/RYOuFK7HYqNnQh1xKBQVJbjw3/g7VJYG6BcAuLsyn7v3xiLxsNdUiaWl1/miO+fGtBqxnFidHNlBZspugf1R9+oFXh+wvKc6V8XEwhmSBcyzcDtZVaNmG+FdY9pBlv6YjarAe8j2GVZzHsxcHP/wmN426bivVRqdAabFByGz7fvesDmUiYqDoXJbyVJDzkuySQePqmjvnmsqMVZdJm+hIMgdRpDPM6zAogO7A7LpLN2oSMPHutzgGecPBma4DxVYTmm28wQW/3JUGYxfFlBE3XE1JsdfGukRs7r6C+OyqP8WqBeyB+/9nxeLlIuQRAHf4n7v/z7l4+sHW9yEfwSzKkp+ZJKVTddrFXF2gVWuuFYlCNaxTcCfnvsebSOtnYFqVazDb3oV9G3qKO3ImfV6V1kZYFrssuJZl72TJMSNaV5Mzd2ggkqlNHrypDiCMbkncMjyJDmNXTvAIgv8xB094SChUbhCNxJHfMIo8PlTgGYSVr7AdwBz1xEf4fSsOvGVzYmRT3lWKb+2juN26pdozz8BsnvisdQYYE4ffzAEMV2EiTKIu5zi71TPZAFdNBEBO9N9zb66zMopKfx2hBkqWOpnL1CTEBFMkq3+fTAjF26WIpDLEK7IeTLvE+Uj3bGvnYFIAwUcfFbjFezxcnZRAt3HgTraBKnrg7PA9ksPpoOuCcx7NxrVW/TpsHs1fzp1IkEA82z3axQeTyhxH/wc2gT1O1hYqRPryX+H51oEdKepberqVqs63ciB6bOjFAM1tI8C3iJrkdWDKBAlDuXw1BYfr38l+DDWAvyycZRX/GCVsdSSNyCUeVabhOlUa+LF72mLuFyRXjQ00wPxzJt9tm54c2qqmopQnPA7alaQ31wCW/lYvsUtx4k6mlNv1li1L3PTT+yOd33QTHJW+6Ak9fjJe1v+EBD6jsYZTPhwtq7GxemGzovtEW55X2dknEWl01CtDej5rN9boBy5FQNhJNLzCX/RD8GcJB9PrGUtLgqj58gaGxqrIqHzNWGduHutS2zZFwz6eypVHvIX1As1togRN6EH8ejAI1VKQ7y7FOX8fzG9pUXN18cnbL8Q3z63czFKY2VBtZjQNO8hp9zZt4I3yyonzs0UgJDRKOCrkXgbErDUkgfmYWmVwDKNkFxxuAHkHsOcSe9Ak0LSIxgoLEJ51yYPmGS7fG10tZWKgFk0TKurkLyxA/eDLoGSJhIBHOz5g3Gxxn9AHgsCCGWQI0zrKgCJBeGl6L2sow3WfIJwsDuQLHBf8GVkve6h9HDDjdGPDQBgrieloMLK7LForNRflA5MJHlL6KUYmmBGIocA+RxuMYUkOJgSH+dgYN0a93r3MT0n7LOAqhflX713Io/fnpPThw2dJjriWfMkU9oZCqOxzWLA8FqAoRPYgnhnfgCpLjEdGwcNLzaw=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(19092799006)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Z6qFRzn+LRefB8M9pb6Ag564aWWRy4v7gVKoDkeHxyhylwaH8rvktGEaQBX3ygCz/zhvCDD/m0DiyHRHlJeapqDxoon4ZoS8DWbDbFu9TpX6IepqjL/yfz1crBLbJuEc+Wej2xP3D7XCy0sxU+LtViOVy6z7BsvFSblnd4FhqHpfodjCR/iyMZGO+6WoAbtoGrSt7O1USzUwwUvAblH1tOaJaj+Jvpp9rZhj2vZ/+HDwvdA3ZRZK8meM49+ALDpDs1pgFr8BrVVeCtqor1x8xBz8xUw58MowpmBAEAmLtwY5DXLaB0BXm67jst14BztQkIVTqkBYwj2ey/kuqR3i03pBjauQgMG46TzyY+Ac1zieTFVVDcvOBxdlSw2GcOqBwdReSA488e3oQ/GOcA0lT72qOhBfLpanoMQ9M97MaWg+abTX2R6v6iAoLeV74ZQF9pTeN9YDEKqcIUtmXl84C63wXTgZzfSCKP3lzP5NmNo3LuQfTA+aNKa6vRIUNj5QpEGj1y0NGtNkMIkzZ1ix232EaoC4IdWsN7QTtMd9wTfGgNinIV+J4ho3+oBsYGM4+0D051seobcGRcz2N08KFbb82MtOVRxZeHYV6+115CJ/X2tthDRGDVhhxUBPOgXUrFh9FnrW7pGCn0kfIXXLtTEAZtdc6S5tKU4afj4+4lxnfSyxvpWNAGs1ePHMI++B2EQjBYe3DGUA3l7vqoQHlfc0gWEYKJ/VH9wLD6nWuNlerugRyaLHuEBRc862CXEHS7wBe2SSfjdCcGEwRNHe+SaMDXqOBva55vJwfO0Atp1SFq3y8MQKaz1Hj1eLlAjmQkrfs2C2E16KxliAIRXpqW11whBuSLG54R+Hfuxin51ZTIjzcwfHvvCjnHK2c+eoF3vYVnRsepRCn4QZvVYmU9pEpLsNA7N0PTYQG5pyHWaZxoj/JqvEzzrPm6nrAc2Tkp7Jtl8I2P0SI1Ul8rvJTWk6mlsC5EaMdB/gt5D8ktxhOJZMDdMgU/1GR8ZhejOl8ImdRkuNc3Ef0ZDnL6RT+hrgg1VkBhf8W/GojM7i4A3Dxhd+SV46NnlcM2OACXEHddli1RO8Nw36IkJJlikpTI0cHItMlVdYG5DMaWVPpnZLAVBPMNGN12J3HtcFXr410Z+a0f4s6GO5GT4VFup/n2ww4VJDVHms4iWvvfZ930cddz2uqgqz4ZlBIj1YoMiPhMqRRdBxeA6y2N38GmXRYbD+VUqy8Ifz9UCDgaz0jsvJ753fOrsYloDBUPZv7+WLvlr7I8ZM67IPafYW9lkzyG+VDdrSki5M8MzZlR+B56ZGoSwQY5gnpiV9oR3SQHQBe4rgMHDlBMhYoLndP7y6rm/m5wNINq8hQRxKigyxX6OHAkDDECAG8t6GCX59SRftSKsl2+bsX++2xp35Hgsw6YJaqUq9I2l0nDyT4mcrMACI5V2eqne+mzcMfm6ByO7IzB2PE9yf/DoP7OFStPJhTTQSvVfDRHvWfpfnULEinFT5nB1YCN0vFL1fuOx/onnSqf7DJWUNjaS9ueemTRtXLKBQnI6E9BgMrtHyQEveWDBehU4vUGjPq9QIIUMF6qmg4wTdlY0yWxwu+e2jhxWnc/9uWw49KXWyknHqCdzuxJi65GEMbqmnHbtw/uJp4qFLIZUzRf3p/g17UD+K6+XbznaeH7QQtE70jlI4rBtPmJWa84BNXsSRE4/LFI1GTESC
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ncsc.gov.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 194e7367-7cee-436d-802c-08de7178c5eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2026 18:41:06.3390 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kAW4rQRwRhfLFLYmZje4H9nU9UFLX9a6NG92o3cnaDzrBcu9pnZPsz1ExkIujBEWRn20PtRg7ukwEkPMOVPypg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP123MB6145
Message-ID-Hash: TONGAMKSYRKLAKHKRFVXWNKNCBSAV5C7
X-Message-ID-Hash: TONGAMKSYRKLAKHKRFVXWNKNCBSAV5C7
X-MailFrom: Peter.C@ncsc.gov.uk
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: Nadim Kobeissi <nadim@symbolic.software>, Paul Wouters <paul=40nohats.ca@dmarc.ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
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/Ge7x7wsumhwDaMXnhYFk5BaCbUs>
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>

OFFICIAL

Nadim Kobeissi writes:
> This document introduces pure ML-KEM as a NamedGroup, substituting the
> ML-KEM shared_secret into the TLS 1.3 key schedule in place of the
> (EC)DHE shared secret (Section 4.3, Figure 1). That substitution
> directly affects a component of the TLS 1.3 key schedule that has been
> formally modeled and analyzed, including in:
>
>    - Bhargavan, Blanchet, Kobeissi, "Verified Models and Reference
> Implementations for the TLS 1.3 Standard Candidate," IEEE S&P 2017, DOI
> 10.1109/SP.2017.26.
>
>    - Dowling, Fischlin, Gunther, Stebila, "A Cryptographic Analysis of
> the TLS 1.3 Handshake Protocol," Journal of Cryptology, 2021, DOI
> 10.1007/s00145-021-09384-1 (cited in the draft as [DOWLING]).

The same is true of draft-ietf-tls-hybrid-design: it also substitutes a
KEM shared secret into the TLS 1.3 key schedule in place of the
(EC)DHE shared secret.

As already pointed out by Thom, the proof by Dowling et al applies
essentially unchanged with an IND-1CCA KEM since this equivalent
to the snPRF-ODF assumption for ECDH.  If you don't trust Thom's
thesis, then look at section 5 of:

   - L. Huguenin-Dumittan, S. Vaudenay, "On IND-qCCA Security in
     the ROM and Its Applications: CPA Security Is Sufficient for TLS 1.3",
     EUROCRYPT 2022, DOI 10.1007/978-3-031-07082-2_22.

> The prior analyses modeled the (EC)DHE input as a freshly generated
> ephemeral value. My own 2017 work explicitly modeled TLS 1.3 client key
> shares as ephemeral. As Muhammad Usama Sardar noted on this list on
> February 20, and as John Mattsson confirmed, this draft introduces a
> materially different assumption: Section 5.3 of -07 explicitly permits
> ML-KEM key share reuse.

draft-ietf-tls-hybrid-design includes the same assumption.  Section 2 of
that draft states:

   While it is recommended that implementations avoid reuse of
   KEM public keys, implementations that do reuse KEM public keys
   MUST ensure that the number of reuses of a KEM public key
   abides by any bounds in the specification of the KEM or subsequent
   security analyses.

> From direct knowledge of the 2017 proof, I can confirm that its
> security arguments do not straightforwardly extend to a static key share
> case. The proof relies on the ephemerality of client key shares at a
> structural level. Substituting a potentially reused ML-KEM encapsulation
> key for a fresh ephemeral (EC)DHE value changes the adversarial model
> the proof operates under.

Again quoting from the same paragraph of draft-ietf-tls-hybrid-design:

   TLS 1.3 does not require that ephemeral public keys be used only
   in a single key exchange session; some implementations may reuse
   them, at the cost of limited forward secrecy.

If the analysis does not extend to the case where key shares are reused
then this would also seem to be a problem for TLS 1.3 with ECDH.

> Under the FATT charter, the chairs were expected to determine whether
> FATT review was warranted at adoption time. I have been unable to find a
> public record that FATT was engaged for this document: there is no FATT
> point person named in the FATT repository, and no FATT assessment
> appears in the shepherd write-up (which shows no shepherd assigned).
>
> I would appreciate it if the chairs could clarify on the record whether
> FATT triage was initiated and, if so, what the outcome was. This is a
> straightforward process question, and answering it would help the
> working group understand whether this document has received the formal
> analysis review that our own processes call for.

Clarification is always useful, but I don't see how the outcome for this draft
can be any different from the outcome for draft-ietf-tls-hybrid design which
has already passed WGLC.

For the record (and the inevitable blog post), I support publication provided
that the draft has had at least some review by the FATT.

Peter

OFFICIAL

v2.39.1 | Report a Bug | By Email | System Status