IETF Logo Mail Archive

[Last-Call] Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

Christian Huitema <huitema@huitema.net> Wed, 20 May 2026 05:46 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: last-call@mail2.ietf.org
Delivered-To: last-call@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 80FDCF155E05 for <last-call@mail2.ietf.org>; Tue, 19 May 2026 22:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779256008; bh=/MxrzM3w0Y3Uf0AEk5/SeliySK0BCIsm3espsEcP3tc=; h=Date:Subject:To:References:From:In-Reply-To; b=EWUkjfF7vvFEVPQqQOEauZT418B6hAIRsyp4IJoh8tNza6/0FPjCXtLr0AWdIBMHb 0kECRER6wAQ4PzgFOby8rzyC+4P9v/pHho+FuTANl7HPFu78CoV4swf8urpYnnSqrW GMdlFcvGl9l8oXgkuTz2xC7BnJjo1503bdfr4GAY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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=ham autolearn_force=no
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 xqK6nM4xRsGk for <last-call@mail2.ietf.org>; Tue, 19 May 2026 22:46:48 -0700 (PDT)
Received: from se03.mfg.siteprotect.com (se03.mfg.siteprotect.com [64.26.60.166]) (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 AF232F155CFC for <last-call@ietf.org>; Tue, 19 May 2026 22:45:57 -0700 (PDT)
Received: from smtpauth02.mfg.siteprotect.com ([64.26.60.151]) by se03.mfg.siteprotect.com with esmtp (Exim 4.94.2) (envelope-from <huitema@huitema.net>) id 1wPZkc-008xOL-86 for last-call@ietf.org; Wed, 20 May 2026 01:45:51 -0400
Received: from [192.168.1.112] (unknown [172.56.200.77]) (Authenticated sender: huitema@huitema.net) by smtpauth02.mfg.siteprotect.com (Postfix) with ESMTPSA id 4gL0rY1zkNzCSFvKr for <last-call@ietf.org>; Wed, 20 May 2026 01:45:49 -0400 (EDT)
Message-ID: <870eb8b0-4587-4d77-bb1e-a5ab956d19ef@huitema.net>
Date: Tue, 19 May 2026 22:45:46 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: last-call@ietf.org
References: <dc5e3bdf-da72-4a27-91e3-beecf67dd770@gmail.com> <MN2PR17MB40317343B9486A12D84533B0CD012@MN2PR17MB4031.namprd17.prod.outlook.com> <5b9b16b4-0a4f-417f-ac01-cd7373593fbe@gmail.com>
Content-Language: en-US
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
In-Reply-To: <5b9b16b4-0a4f-417f-ac01-cd7373593fbe@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=huitema@huitema.net
X-Originating-IP: 64.26.60.151
X-SpamExperts-Domain: mfg.outbound
X-SpamExperts-Username: 64.26.60.150/31
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=64.26.60.150/31@mfg.outbound
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.05)
X-Recommended-Action: accept
X-Filter-ID: 9kzQTOBWQUFZTohSKvQbgI7ZDo5ubYELi59AwcWUnuU2UtKSwlMQO528zv4DFM/Jqm52sBBMQmbD 5DgO7M1yVCu2SmbhJN1U9FKs8X3+Nt127hcteP1p0NVNV47moiZtUnZMMMyaNBeO+OvFQHUlG4JL M0i5ZAms0EHrvcCaVIM6r9pOJZBUfxKf0dPunzuoGnT3EFAinyrilm9zau/FuzkQt9Nb4Ml7QXdk EetczWCYKeH5wJNE2hk+QjLN5lBEeB7itP8hgjDRserKv4bhb3Du2hHLbfwudMeTkB5rPevEMzer JfQa9UAYKsgEV8p+MUJTS2Jsxpkx+IHIsDarm2U3gyy0nlbakKK22WPBaizjKzb+JrnOTbl8FYp7 CIWjverajYy2yB71RZy29b9HL7yliuqXZvH3i216cQum167vAusksf9rVl9xti2O/u3hHUlvAVNJ FJLPhnEJwuPa+QdvWVe/Q4mXPvgCQTlRFw1UXD7036SCGN+yf9WCXlXIaMKK7DBe4wHKKJ/dmX9c Bj1rkxMfAc2m63t12mcKIns/dzm4z79mv61HDPvSr7htulcxfjgPaxyVnP1Aft/+GaxlS6+B2s5m vDv0wBb3rl9oh9VoIekQHpwUfpYnEThmd75UILHbzc5giKIyGSOaWQNGlYtRsGoNVDkzd1TBAd9h l3z5IJfAT3I6jTJsKbct3lMD1Lduh66rdbkc9TpC1VHlrZaBCxNSvPxmdKwiDofhUWNYzwuoyjET IdC+/J7xRVIsJhTCZMIYFG4YKPwIKdM+m4WpRRDP6YzwkAPgQJZWCeonEhCiQPLRDYALWHXLfCuB ILYLDdiI+quFItBwvn1lF87HXtkB1vLi4H9iqNvD241taXea0OgTqVXK/bCGp6IQ8bAecYo8dERl q1zRBQe2RQxxf/isbD+UUpVGniQ9bUIFyBVDQ4+0k0aaKb9TIIVGLAOfyPfJYYe0zvB1GmWm+we4 phJlklat9JF1KmkYFn1arNUJVzdcIt0CkiW+oSyaA1TzQpMNBxbB7RLiYDw9ciLLWy673sNwm6Oc oZK2RPr6Q4Ue1KEdL6NZl/zn4uQzIjeAeGe8mlgPHS8Z/7QkOzue3Gw4TUf9sgw4nwoxL7hrJSk6 0SF3F6RYOYr2
X-Report-Abuse-To: spam@se02.mfg.siteprotect.com
X-Complaints-To: abuse@se01.mfg.siteprotect.com
Message-ID-Hash: PFQGQK3A37MNHLFJCASE2IWLED6ONNF6
X-Message-ID-Hash: PFQGQK3A37MNHLFJCASE2IWLED6ONNF6
X-MailFrom: huitema@huitema.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Last-Call] Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC
List-Id: IETF Last Calls <last-call.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/7ZCdhC9KXFi3Nz4RkWt1Y85UlUY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Owner: <mailto:last-call-owner@ietf.org>
List-Post: <mailto:last-call@ietf.org>
List-Subscribe: <mailto:last-call-join@ietf.org>
List-Unsubscribe: <mailto:last-call-leave@ietf.org>

On 5/19/2026 9:04 PM, Brian E Carpenter wrote:
> On 20-May-26 12:26, Salz, Rich wrote:
>>   *
>>     I am concerned that the Security Considerations of this draft do 
>> not state clearly that as a non-hybrid PQ algorithm, it is 
>> potentially less secure than a hybrid equivalent.
>>
>>
>> Security is about trade-offs and using something that gives the 
>> appropriate level of security for the amount of effort (CPU, network, 
>> power, etc) expended.  A blanket statement that PQ is less secure 
>> than a PQ/T hybrid is the wrong thing to say and we are meeting our 
>> ethical requirements by not saying so.
>
> Yes, which is why I did not suggest such a statement. I suggested "as 
> a non-hybrid PQ algorithm, it is _potentially_ less secure than a 
> hybrid equivalent."
>
> The IETF can both stay neutral and issue a warning. As long as we have 
> two opposed encampments, I don't see any other way.


While I generally favor the "hybrid" option, the debates in the TLS WG 
surfaced an important difference between key exchange algorithms (e.g., 
MLKEM) and signature algorithms (e.g., ML-DSA).

Breaking a key exchange algorithm allows an adversary to decrypt the 
data, and in particular to decrypt previously captured sessions "when 
the Quantum computers become available". Hybrid key-exchange schemes 
protect against the possibility that the post quantum algorithm is 
broken, and maybe secretly broken by some secretive organization. They 
are thus obviously safer than "pure quantum" algorithm. They also have 
little deployment overhead.

Breaking a signature algorithm enable signature forgery attacks, and in 
particular Man-in-the-middle attacks. That's bad enough, but that's not 
the same category of bad as "capture now, decrypt later". As soon as the 
breakage becomes publicly known, we can expect implementations to switch 
to a different algorithm. So yes, there will be a window of 
vulnerability, but that window is hopefully short. At the same time, 
deploying an hybrid signature algorithm requires certifying two keys for 
each server, which is a substantially heavier burden than just adding 
some extra computations in a key exchange.

-- Christian Huitema

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