IETF Logo Mail Archive

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

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Sat, 21 February 2026 22:30 UTC

Return-Path: <sfluhrer@cisco.com>
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 37574BB6A7C5 for <tls@mail2.ietf.org>; Sat, 21 Feb 2026 14:30:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -9.686
X-Spam-Level:
X-Spam-Status: No, score=-9.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URI_NOVOWEL=0.5, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cisco.com
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 5LSCk5ewbbpS for <tls@mail2.ietf.org>; Sat, 21 Feb 2026 14:30:37 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id BD9E2BB6A7BD for <tls@ietf.org>; Sat, 21 Feb 2026 14:30:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=32542; q=dns/txt; s=iport01; t=1771713036; x=1772922636; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ddqdTkmktVnlGlja6uxoFMwOT51Zm7SYNV63RqDtoQs=; b=CxlVCH0E8IMZCXa6Awg+ZpH92ZWgzBYc+qVEJYPCKUzYCPxT2PPeAzwg HBwKDBkzfZhEOLU23ItkiPHp5nQ+tlPdEntWBjNJIqsCDZ0R5fnODv7g6 N0mKOTzkF/BxZ2rQ3ac/iw+u7Q2C5THLLDXb7Hb/X++XWYs4tM+R5cjw+ BAp3tnSObmlx8MATGEEF7FDHCOGQq7cYNNiOKfJFugDQgceeQkvKt+T7l ELQRrQUoKn+mZrke94xcn0pn4Rrx7zaKbRsuNQ1p80k9O+ND7BXttT7QR HJF8RR+aSt6AnD4Ra/ly2aBtXnLsEg9nk5NvqAH2yXaj8Drr9kc8UR9e8 w==;
X-CSE-ConnectionGUID: vYfAijL5Shqayhm5jqPB4Q==
X-CSE-MsgGUID: Fqvag5TmQCmPonvPmYWmwQ==
X-IPAS-Result: A0AGGQCWMZpp/9FK/pBaDoEggmgxKikHfgKBIUmEV4NMA4UsiHkDi2SMG4E7hHSBaw8BAQEPNB0EAQGCE4E9gTcCFo0JAiY4EwECBAEBAQEDAgMBAQEBAQEBAQEBAQsBAQUBAQECAQcFgQ4Thk8NRoYUAQEBAQIBDgQRKxcJCwULAgEIEQQBAQEnAwICAh4QARQJCAIEAQcGBQgVBAGCYYIdFgcDDycDAQIOm1gBgUACiit6gTKBAd1DDYJYBoFNhTyCeR4BASqBNQMOgXdTgSEZO4IMgQSBLycbgUlEgRVCgmg+gQWBGkIEgSkBCwYCASIGDx+DJTqCLwSCCQRnKAoKEgsPPwUGL0MBARMDgQ8EAxECK4QuXgZ0UiNkJ0VnFCEBAQEFhhxSckszLAFVExcLBwWBI0MDgQYjSwUtHYEjIR0XFB9YGwcFEiEqB4FYAgIEghN7ggEPhmp5Ay5hGg4iAiwSXFIFPgtgBVEDC209NxQbAwSBNQWNUFs/gTgJARABQRkGCCYQIwMEIhARECItCQ4rSRAOBikFBgsLAi2WYa4YTXEKhByMHo8+hjIXhASNE5htZ5kGIo1nhAmXBAIEAgQFAhABAQaBfyVpcHAVO4JnUhkPjX8uFoESAQiCQ4Z0iECqDHgCOgIHAQoBAQMJkWqBfQEB
IronPort-PHdr: A9a23:WjGEkB3tPlKaiHSasmDPmlBlVkEcU/3cJAUZ7N8gk71RN//l9JX5N 0uZ7vJo3xfFXoTevupNkPGe87vhVmoJ/YubvTgcfYZNWR4IhYRenwEpDMOfT0yuBPXrdCc9W s9FUTdY
IronPort-Data: A9a23:D99MeqgEyRQ1sYT86k1IwmjQX1612hIKZh0ujC45NGQN5FlHY01je htvWmmCOvzeNDanfIp2Od+woU5SsMeBxoNmSwVrrn9jRC9jpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+FH1dOOn9SUgvU2xbuKUIPbePSxsThNTRi4kiBZy88Y0mYcAbeKRW2thg vus5ZeGULOZ82QsaDxMsfja8EkHUMna4Vv0gHRvPZing3eG/5UlJMp3Db28KXL+Xr5VEoaSL 87fzKu093/u5BwkDNWoiN7TKiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JAAatjsAhlqvgqo Dl7WTNcfi9yVkHEsLx1vxC1iEiSN4UekFPMCSDXXcB+UyQqflO0q8iCAn3aMqUGy+heAGNqq McYMTkcbhXehfuO6u6CH7wEasQLdKEHPasWt2slyXTSCuwrBMiTBa7L/tRfmjw3g6iiH96HO 5ZfM2czKkucJUcXaz/7C7pm9AusrmLxdyBYsl+PjaE2+GPUigd21dABNfKJKoHTHJoJzy50o Ero5nrwDUwmMeW0zAKC9GyUg97wmDzCDdd6+LqQs6QCbEeo7nAXEzUXWEe15/6jhSaDt8l3I kEOvy5rpq8o+QnzHp/2XgazpziPuRt0t8dsLtDWITqlk8L8yw2YHWMDCDVGbbQbWAUeHFTGC nfhcwvVOAFS
IronPort-HdrOrdr: A9a23:qeBnE6lYr35WBMDc12jeI+eM2j3pDfNsiWdD5ihNYBxZY6Wkfp +V7ZcmPE7P6Ar5BktApTnZAtj/fZq9z/JICYl4B8bFYOCUghrYEGgC1/qs/9SOIVyFygcw79 YFT0E6MqyOMbEYt7e13ODbKadc/DDvysnB7omurQYJcegpUdAd0+4TMHfjLqQCfng8OXNPLu vl2iMonUvGRV0nKu6AKj0uWe/Fq9fXlJTgTyInKnccgjWmvHeD0pK/NwKX8Cs/flp0rIvK91 KrryXJooGY992rwB7V0GHeq75MnsH699dFDMuQzuAINzTFkG+TFcRccozHmApwjPCk6V4snt WJiQwnJd5P53TYeXzwiQfx2jPnzC0l5xbZuBylaDrY0I7ErQABeo58bLFiA1zkAo0bzZdBOZ dwriekXlxsfEr9dWrGloD1vlpR5zqJSDIZ4J0uZjpkIMojgHs7l/1EwKuTe61wRx4T5O0cYZ tTJdCZ6/BMfVyAaXfF+mFp3dy3R3w2WgyLW04Yp6WuonJrdV1CvgMlLfYk7zw93YN4T4MB6/ XPM6xumr0LRsgKbbhlDONERcesEGTCTR/FLWrXeD3cZe06EmOIr4Sy7KQ+5emsdpBNxJwumI 7ZWFcdsWIpYUrhBcCHwZUO+BHQR2e2Wyjr16hlltVEk6y5QKCuPTyISVgoncflq/IDAtfDU/ L2I55SC++LFxqmJW+I5XyJZ3B/EwhobCROgKdPZ7unmLO+FrHX
X-Talos-CUID: 9a23:cl/yUWrYz6vCmPOzTUTE/gbmUd4UfFTczlONGE+hAHdpTeCXUGe6pJoxxg==
X-Talos-MUID: 9a23:/YcIRQ14BgyvfR3VoDFzoeCDnjUjzb2wAU9QrZA/kMy8MipuAzKsszGoe9py
X-IronPort-Anti-Spam-Filtered: true
Received: from aer-l-core-08.cisco.com ([144.254.74.209]) by aer-iport-2.cisco.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 21 Feb 2026 22:30:28 +0000
Received: from rcdn-opgw-3.cisco.com (rcdn-opgw-3.cisco.com [72.163.7.164]) (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 aer-l-core-08.cisco.com (Postfix) with ESMTPS id B0B5618000187 for <tls@ietf.org>; Sat, 21 Feb 2026 22:30:27 +0000 (GMT)
X-CSE-ConnectionGUID: LyiLiOZeTt2t+6htMb3O2g==
X-CSE-MsgGUID: Uwu0BlhvR2WRSUzaPGfZHQ==
Authentication-Results: rcdn-opgw-3.cisco.com; dkim=pass (signature verified) header.i=@cisco.com
X-IronPort-AV: E=Sophos;i="6.21,304,1763424000"; d="scan'208,217";a="56186823"
Received: from mail-dm2pr0701cu00105.outbound.protection.outlook.com (HELO DM2PR0701CU001.outbound.protection.outlook.com) ([40.93.13.69]) by rcdn-opgw-3.cisco.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 21 Feb 2026 22:30:26 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uRatW9kq4tKw0WPvXllnF3iVCR0I0NMSQlm4waBR92oyCx0Tz56Jp+CZQ7Lz6cS3X3rdpf2ATZISmP9b8A12R252jnUOuKqlXfiP1e8Q33hIP6TI2ly4TlpcpvEDB4hpVYTxtGfwebqE96oZ6MnZUgnFaaKFjrhbRw+hd1EOspnjx6m4GINzhrHVRSKYc7nWMCBXvpxyqKrnKI1E5Hs5zaPQHddCNnL6/eKrLPlywAh+VI3DXXcFc5IK0Frlga7h2aPJHT/Ma6Orl6lchmVQgq4Afe+gNYtFJQZ+0V9EXqSQMURU/Dvn2gYqlNXvs7kGEhHGDH7bP/G+WIRkSOERYQ==
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=ddqdTkmktVnlGlja6uxoFMwOT51Zm7SYNV63RqDtoQs=; b=o46tbSro88EeDH+bDJ93F3g5U8JgWZm7IQJGGNbsPHOVQpI0T35BTBm5lnhZ7hyQO/DiEg+dIAlTSFpX2vWICBj+973WXqx1E0DRIRC9ZrOmPRqbr2MNCliX8kGwYuFQnmcZeCE/8MZPtbzt0IThse2lReD3JpSOkU+1XPX1hOL10+gZrOhuCcbTXAGWq6+1yPS6KR2wh2KdSNI9yHSCsQsJHeCUaRlZ79Qx6BrFQhRqstMCuqwWCkl/lmuzl1YJimG0fbGZXSGuUINNiP+U93vnw3j9hyGO/ADRz6LxrA8Rqbt/vGmRUm61KIe/53TH7EaUWSatOSOrW6QioGNaDQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
Received: from PH3PPFA3FE8A23F.namprd11.prod.outlook.com (2603:10b6:518:1::d3f) by DS7PR11MB7781.namprd11.prod.outlook.com (2603:10b6:8:e1::7) 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 22:30:23 +0000
Received: from PH3PPFA3FE8A23F.namprd11.prod.outlook.com ([fe80::819f:d782:bf3d:c1df]) by PH3PPFA3FE8A23F.namprd11.prod.outlook.com ([fe80::819f:d782:bf3d:c1df%5]) with mapi id 15.20.9632.015; Sat, 21 Feb 2026 22:30:23 +0000
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Izzy Grosof <izzy.grosof@northwestern.edu>, Deirdre Connolly <durumcrustulum@gmail.com>
Thread-Topic: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
Thread-Index: AQHcop0Sk+VOzK4tWE27SuiDkwMGt7WMFmEAgAAAk4CAAAFjgIAAS7qAgAFHnQCAAA+00g==
Date: Sat, 21 Feb 2026 22:30:22 +0000
Message-ID: <PH3PPFA3FE8A23F941F869933D16E2BFD1DC169A@PH3PPFA3FE8A23F.namprd11.prod.outlook.com>
References: <MWHPR05MB3647B28767462F896A389FF59D68A@MWHPR05MB3647.namprd05.prod.outlook.com> <CAFR824z0CBKSi8P1o2Nr-h0pueNNN_SNitUVSg+W2VaB36JJHQ@mail.gmail.com> <642EFEE3-E4B2-43E4-ACDD-C662F385769E@symbolic.software> <CAFR824xGzq7DHHU0xAhTeLBSG2mJvCFWSbhKbYk5fMrSwF4tsw@mail.gmail.com> <b650b79c-59d3-47d6-9ef6-09dfc24e8550@email.android.com> <f6c1a48e-fd67-4be6-96f5-96de6f07072a@email.android.com>
In-Reply-To: <f6c1a48e-fd67-4be6-96f5-96de6f07072a@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH3PPFA3FE8A23F:EE_|DS7PR11MB7781:EE_
x-ms-office365-filtering-correlation-id: abd35bfb-ddd1-4117-e76f-08de7198cd88
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|10070799003|1800799024|4022899009|366016|376014|13003099007|38070700021|8096899003|7053199007;
x-microsoft-antispam-message-info: wErq4Th0mNZV2ZwDNu49tFVyoO8YvRFhwMjRkD5X1N4KsPZOXi28vGXCzEzBSpRyjFlHZSUbNC75Anq4WUAAe07+FhuIclC+CwwjqgTjO07JFqr1gSkZ1Z0B1Up4zz7hGI5CVdP+z/mutbmgN9W4UNAWdUAaBj13OCmJuhOMMlXByWtbhnE2CuxZ/qJWPjoXoSez8vEDD7Aj+RH/edmerogAddfD8WNBiefhONIMwIdHm+2v7fh8IlKIUHJULPQ3uPMjvDToHIxtDC7zpGuUMtUoCdJFgCEpnLWpb/KL+1a11LJY/urq59lSDPhrWu4iuEq/Tuxh/i3eh7X4NEwiqv6ZeSHXDRER4f3/6cbdrMGDZbJdzd+nvcKglkUCBHjZKRT+Yt7VpNEhGw/lNxMdhifJ8sdT7hb5aex80rfXRvzLL9x3p5FO2cspHpyWm3HFkPJn59f1YG6Is2AP+QFNbpb7ZH1wo1xKnCVyB+lHdYiQGqL2xog4cExzFZrui1Ouvvbx8su9sVV7CWcuNjAXlyMPemj9p/Gs027mS+B2QW2pd9YfIhQj95qKl3SKEtbQ9269eDMq+2U9Yy1YgSZpMxMZiWIN+VcX+rKBtah6D+qeuOVSCMb6yFTzcucTXxyv++4lU7tTkB0OlbpyKK87Ut/E4Svoq+/b9LZGWQyS5tNlBqUgUAG2CIOVc/jNCcNdx7V/ABUZqsZgbyb1R6+5Yd4O86aLfcGiqjNjvDJ1h/i3nFHc2yc76hFVYxPlH1Rn698SQsvjkFT7xGWnP3j80M1AJ0cTjgCG2YpPqEardwH10lnvCKBQUIZ9wQu95iISHmjZsOXZUqcrSk1XUum7hLXkd8gjwZYrhH3MxEtk85uoA28NqbKrdHGdvCLrROC+F+z69jUmi6TH6WfLyQ95GHGq3Fxh76/3mjQRyu+xpNk7VzuEIw7qL3VvPNux0lRhFVcG793F2sWmNj+dMaV8GTrBGgZ41Npld7oVv20wW+IfxsJ8U4r6PnuiPLPlmwMZOSUUIqjopORXrRZjDVtB7s8a3NWMlYUIrRBge9y+GuoBqcWBpy7VSuOHCOqFOa39cKqu2JbV9gnmGvGtnNUk37dDm3R8/DWgskY+wPt3uf8RfBMWduxqHukqk4zaA1VEVk3bsk6/Wd9A+lIjmzuDguyl6cKj8vP9UMATInaFyepCoZEII+KBMuEikGapY6d0Ah4cmQZE9c95dk5xqGS4loE6dkjQzb+Q+vNUjAXh2rRaJjy66CEMmVOse4/HWC5ScWGAMMT8ySkhspP7f00laPmTRcUp0QbZq82etyDyD5HwCTPuA0yL+B826AOXytqk16j9AV4hqRlCsda2jCVtE8OnI/XtPaXim6euV+9hDraQnrYCs5iyvSO65m2lYnr6PbcsZTHWhmLgnvSXzZ7Zp6B1tWaMqZcsqwsePuFXAmwOBA9tFL99i18ljRU8hWk9ceo9giou8btVAuyzEu4zkbU+jGGXmFGH54lann9eVrtrKALuA8Y/0Z1VuOMne0Iz52pvqpczWPlrxdPhJB6etCLH1vqNwliFRym1G5NYdsc=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH3PPFA3FE8A23F.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(4022899009)(366016)(376014)(13003099007)(38070700021)(8096899003)(7053199007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 5F7iDLJUjxOSvfiKnHeu8SSkTpAA1Bzi1s93JyAzWplnVJ2oaWv0ERXG8VCwjJyJ+7XYsDaJpb8SiAkVD3ggOi2o9HkwL6PgLRtdQyl4Lgb4GhT0kFcvqpg8eS07hOzAtKNSjsLSpIh1OclClOfMey/w0RJ+GcMGqoQrapVq4qAfyQDPBUDHk4PZWggBsr/xjqRbLn1aJQijM2vp4tYZJzo7RkbSBpD2S4ldotQGfNVD+PFFBlB8uq753VV80YrM4/mavoOHv2ez1lu1yzNxyhQzyzK+B9rAVr/BMS+t2p0iRrvB3oIEhzQB1G4oquQ5jz4mgpR5O9fvfjRmUX/1wa9eyy/wHJaxsauS5i/cN79a1EWWbQKaZz+W5GV9hnpPnm9yUbKtioJEACxYSrMyEOHe56udETBMkHs5nG1dGtYOPDoJ7D4Qbn8eaS58gJEeQ5rTz+LeRBoLOXujTg71yx0i1yRkGBQLh/Zcq5aEArSqcQMeaejGMyF5HWJj0bHD3BQ5zaSHM1Mh13kquHBlnIUlQSIK7FNVh9RiyeC4k/L2B3cQrm86ZdKjF+ZAAlzMRwrb+HL+8o0ghprynp4KrJO48PSFgLPUowyyarBeRxLaen15TLyUTDFyFLHq+884ARe9YaXCFBrK4h3gwQdNqFbKnerKQlRpYJ884ZEU7r6POZTQiMsAT/ogD21pItvo4LglUldQUgEZlvhM6/tqzW+A64JrdTAjsVba87qhYSCbyKNIDd/Tyvypga387R87v5g4hnLwLU6//2c2WcFa3lb93TNCKGpSV1+ZI8W3lwFig+9a8h46RU3nLfb706UseqpvY9V1CCjRc7V/kkeW5LyqK5FRjDEXs0F24dQlWYC6adqNEwyRqSJYOFV4SbpML3rVF11AF4Xd8HLMV53WnWx1ctaegnbcpcaypatZRIsX3sk1nSuajhkHDPLzQOcAPEPfzfP7jcNnDrPkEIKt0wYPkVliAcu2SqWyoaoM0DQhtcD7TJF9+V98/w7zFvIpRdOEjSRpGOKPcah5yuwHSu7SAvA+DiZtAKn+j702qK+20Ek6Ur3wayqgf7rCiAchdryMhwK9TB++AU5xTg7AiNsudPS2/0rEM6fOGgwlY8HKtFfu/CGwNY0CVq6nSTErjBgaeKBW4VxRj4eh/DJZw2WtQmVp6djDn+Lg8QfbnFU/YBDJ83XlPfUpTABEP5/Z6e9FpG154LyNGd43fNvwFVZ6MW80LHbVUXNQZb3hDvMVZdonjuhm7Ck0ITvJsugm9EMyr6jNedjUOYH8H2Q/jr4YdqR7o3RVgQIWXRP61Kn+hFXZZ5638ojEBgNnJB8ZQOdIUu35YMxaqEZAkpzPOgpTU+5wD0Y3454LTgV0v+St5GuARByL2/xoCSTKNFZuW2SfJY79EqbP9dZ8imJHfNuFEA7ezEpPSeDOp5SWHS8gZWtwv/clrNbCXA9Qam+NdLLPSZIpeYq0RU4aqpKpY9vL2PJGCVt4Nn50xrJH0dCS3j+pPUZX9oczumeYyQlQKkRyd3Et7s/UGZSLyLgiyUxMRBOLm/VZG7jBIfQhp3IbXtLDtMf+j+SMFhWxKxxRKxwrOyWg12tTdxlRPVDeZkTFFzglu7ZLzmcarivp83iQLZ8+DnJRtbhrg2h2y8e+uK7MMcltH4Qrrg4eH4+sJBDz7yTufuZ2Xa5C0UIQShFio/zW/Z/weJ7iLXIdfORdwFnuaDM2wZk5gGRrum5tv3N93jjaWXGBKZghi1F0Rla1dsHtCtcXcUfCVo2smgV8
Content-Type: multipart/alternative; boundary="_000_PH3PPFA3FE8A23F941F869933D16E2BFD1DC169APH3PPFA3FE8A23F_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH3PPFA3FE8A23F.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: abd35bfb-ddd1-4117-e76f-08de7198cd88
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2026 22:30:22.9907 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2pOiZlxTRUarjPAiP4pKPw4B2zl/afx22teTboGrd6ufPKbrn1hwhcKhmtds9y4nicDBqgRqSmK+PB6xg0mAkw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR11MB7781
X-Outbound-SMTP-Client: 72.163.7.164, rcdn-opgw-3.cisco.com
X-Outbound-Node: aer-l-core-08.cisco.com
Message-ID-Hash: EPJ37QJVSXBPUXX3EE2YQ5NZXGC2DLOC
X-Message-ID-Hash: EPJ37QJVSXBPUXX3EE2YQ5NZXGC2DLOC
X-MailFrom: sfluhrer@cisco.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: Nadim Kobeissi <nadim@symbolic.software>, "TLS@ietf.org" <tls@ietf.org>, Rich Salz <rsalz=40akamai.com@dmarc.ietf.org>, 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/aNmB_j9lKYsjcRV5-RVfT3AP7NQ>
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>

I fully realize that this will not change anyone's opinion, but I feel compelled to ask.

In opposing the ML-KEM draft, are you saying that there is a significant chance that ML-KEM be compromised (either due to a cryptographic breakthrough, an implementation flaw or a side channel), and that chance is high enough that we ought to try to forbid anyone from using it?

If so, then one would have to conclude that the current hybrid being proposed (ML-KEM + ECC) has a significant chance of not meeting its security goal of being PQ secure.

If we believed that to be the case, I would think that we would also need to reject the hybrid draft, and work on something we think is secure.

If you still make the claim that "ML-KEM only is bad, ML-KEM+ECC is good", could you please point out the flaw in my reasoning?


________________________________
From: Izzy Grosof <izzy.grosof@northwestern.edu>
Sent: Saturday, February 21, 2026 4:24 PM
To: Deirdre Connolly <durumcrustulum@gmail.com>
Cc: Nadim Kobeissi <nadim@symbolic.software>; TLS@ietf.org <tls@ietf.org>; Rich Salz <rsalz=40akamai.com@dmarc.ietf.org>; Paul Wouters <paul=40nohats.ca@dmarc.ietf.org>
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

To refine my previous wording, I believe that a recommendation is insufficient, and that a full requirement is needed. To that end, I recommend the language:

"Non-hybrid ML-KEM MUST not be deployed as a TLS cryptosystem prior to the public demonstration of a security break of the classical component of hybrid ML-KEM via a quantum computer. However, this is not a reason to prefer classical pre-quantum cryptosystems over non-hybrid ML-KEM: hybrid ML-KEM should be used instead."

However, I want to clarify: while the above language is necessary for me to support the draft, it is not sufficient. I oppose the current document, and I would continue to oppose it if this was the only change made.

Many other issues have been articulated which I agree are blocking problems, such as the lack of a compelling reason to employ non-hybrid ML-KEM over hybrid ML-KEM, as described by Nadim, as well as the other problems described by Nadim, as well as problems described by others.

The balance of the probabilities of security breaches due to classical-only vs. non-hybrid ML-KEM vs. hybrid ML-KEM overwhelmingly favors hybrid ML-KEM. The document should articulate clear and compelling reasoning security benefits of non-hybrid ML-KEM over hybrid ML-KEM, or it should not be published.

"If all other cryptosystems are banned, this is the best cryptosystem" is not a clear and compelling security benefit. The same can be said of literally any cryptosystem.

On Feb 20, 2026 19:51, Izzy Grosof <izzy.grosof@northwestern.edu> wrote:
To clarify, are you concerned about a scenario in which someone is willing to deploy either classical-only or ML-KEM-only, but is unwilling to deploy the hybrid-ML-KEM system, and so with a recommendation against ML-KEM-only prior to a CRQC demonstration and towards hybrid-ML-KEM, instead chooses classical-only, becoming open to Save Now Decrypt Later?

In this scenario, this provider is already refusing to deploy the best option prior to a CRQC demonstration, namely hybrid-ML-KEM. Should we not attempt to convince this provider to support hybrid-ML-KEM via this clarifying text, rather than omit a clear indication of the best course of action?

As a compromise, the clarifying line that I'm suggesting could say something like:

"Non-hybrid ML-KEM should not be deployed prior to the public demonstration of a security break of the classical component of hybrid ML-KEM via a quantum computer. However, this is not a reason to prefer classical pre-quantum cryptosystems over non-hybrid ML-KEM: hybrid ML-KEM should be used instead."

A line like this addresses the scenario that you're describing, I believe, by removing any perceived advantage to classical-only.

On Feb 20, 2026 15:21, Deirdre Connolly <durumcrustulum@gmail.com> wrote:
To clarify, saying either hybrid or non-hybrid key agreement should not be deployed until a CRQC has been demonstrated fails to address the primary passive attack against TLS key agreement, and applies to both hybrid and non-hybrid— basically saying non-hybrid should not be deployed until it is too late

On Fri, Feb 20, 2026, 4:15 PM Nadim Kobeissi <nadim@symbolic.software> wrote:
Wait, wasn’t the whole point of adding a PQ primitive to mitigate SNDL?

Both hybrid and PQ-only key agreement should mitigate SNDL. ECC-only key agreement is the only scheme that’s vulnerable to SNDL as far as I'm aware. Please correct me if I’m wrong.

Nadim Kobeissi
Symbolic Software • https://symbolic.software<https://urldefense.com/v3/__https://symbolic.software__;!!Dq0X2DkFhyF93HkjWTBQKhk!Uf4nfZhJqaAjKdsbw9YrmYmf_PjTf8RbqF1-wL30JtJS4yPBcMTdGrbkuCGM8wdYpPUun72UFFN8hQdYAGpEyJGB6n5R_VmrhT4$>

On 20 Feb 2026, at 10:13 PM, Deirdre Connolly <durumcrustulum@gmail.com<mailto:durumcrustulum@gmail.com>> wrote:

> non-hybrid ML-KEM should not be deployed in a user-facing manner until a CRQC has been publicly demonstrated.

This fails to mitigate Store Now Decrypt Later attacks which are considered a live threat to present TLS traffic, whether using hybrid or non-hybrid PQ key agreement

On Fri, Feb 20, 2026, 4:04 PM Izzy Grosof <izzy.grosof@northwestern.edu<mailto:izzy.grosof@northwestern.edu>> wrote:
> This seems like a tremendous waste of time. The chairs should exclude from
their consensus determination mail from people who are not limiting their
comments to clarifying text and are instead relitigating the same
previously discussed arguments. There is no reason to believe the same
people going off topic now, will not simply go off topic on yet another
WGLC.

To offer a substantive comment on topic, focused on clarifying the text of the proposal, it seems that the two main use cases for non-hybrid ML-KEM are either to plan ahead for the future development of a CRQC, or to deploy once a CRQC has been developed, and there is agreement that CRQCs do not currently exist.

I therefore propose to add a line to the document which states that non-hybrid ML-KEM should not be deployed in a user-facing manner until a CRQC has been publicly demonstrated. Concretely, non-hybrid ML-KEM should not be deployed in a user-facing manner until the classical component of the relevant hybrid cryptosystem (e.g. an elliptic curve cryptosystem) has been demonstrated to be broken (e.g. a concrete decryption demonstration) via a quantum computer.

I believe this additional line would be amenable both to people who think that this demonstrated break of classical systems will come relatively soon, and so non-hybrid ML-KEM will soon be relevant, and people who think this break will not come for a while, and so hybrid ML-KEM will stay preferable for a long time. To be clear, this additional line clarifying the proposal does not block developers from creating non-hybrid ML-KEM software, but only recommends against deploying that software prematurely.

My research area is the performance modeling of computing systems, so a stochastic model of future security degradation is natural to me, both of classical cryptosystems via quantum computer and of ML-KEM via classical attacks. Hybrid cryptosystems should be used until the times comes when it is sufficiently cheap/quick/easy to break classical cryptosystems via quantum attacks that no substantial security benefit is provided by including the hybrid component. There is a distribution of how long this will take, and different people will have different estimates of this distribution. I think it is relatively uncontroversial that there is a substantial probability that classical cryptography is not broken (or substantially degraded in security) for tens of years. We should provide guidance which clarifies our stance relative to this timeline.

Finally, I want to point out that a wide variety of institutions have some expiry date on the duration for which they want their information to stay secret. For example, the US government has automatic declassification procedures after 25, 50, and 75 years. We should clarify the text of this document in a way that benefits readers interested in this form of limited-duration security in the 10-100 year time scale, by clarifying that non-hybrid ML-KEM should only be deployed to users after a demonstrated full decryption of the relevant classical cryptosystem.
_______________________________________________
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>

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