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> Thu, 21 May 2026 01:53 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 0153AF21471E for <last-call@mail2.ietf.org>; Wed, 20 May 2026 18:53:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779328412; bh=VSxZWdDpBsAXUOyOGo8zu7BmC/coFevpdxmXV4UsNW4=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=VlHBBwUPaDGPIl5aSMZjy4LzUzuT065PRMILmG1uDanii9KgxYKGVkW3KowDtgEKa EskkI+9/LdcW5u3XHJSv8wGgR/oILmtD0iEwLPjgI+J9io5O0Xo8EnZ9ULZ2/vvOF9 kNgokUr2TAmXCXF9OwVlu31sQhZWdqY6L2pAgPrA=
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_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=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 phHTjYaDRHf7 for <last-call@mail2.ietf.org>; Wed, 20 May 2026 18:53:31 -0700 (PDT)
Received: from semf11.mfg.siteprotect.com (semf11.mfg.siteprotect.com [64.26.60.174]) (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 3DB07F214719 for <last-call@ietf.org>; Wed, 20 May 2026 18:53:31 -0700 (PDT)
Received: from smtpauth02.mfg.siteprotect.com ([64.26.60.151]) by se05.mfg.siteprotect.com with esmtp (Exim 4.94.2) (envelope-from <huitema@huitema.net>) id 1wPsPj-0017yh-Nm; Wed, 20 May 2026 21:53:23 -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 4gLWdf5TQKzCSFvKK; Wed, 20 May 2026 21:53:10 -0400 (EDT)
Message-ID: <51553966-3745-47df-a3a9-1836f9c1f080@huitema.net>
Date: Wed, 20 May 2026 18:53:08 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: John C Klensin <john-ietf@jck.com>, Tim Bray <tbray@textuality.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <dc5e3bdf-da72-4a27-91e3-beecf67dd770@gmail.com> <MN2PR17MB40317343B9486A12D84533B0CD012@MN2PR17MB4031.namprd17.prod.outlook.com> <5b9b16b4-0a4f-417f-ac01-cd7373593fbe@gmail.com> <870eb8b0-4587-4d77-bb1e-a5ab956d19ef@huitema.net> <faac80e1-06f1-4903-97b7-4cb04fe26b22@lear.ch> <c6343e64-413a-4e0d-8ab2-d2183c364d2a@gmail.com> <CABcZeBOUquLXBM8K-sN_-tBZrXb0Fy_Cw5pnkPCUoMYrWy3yvw@mail.gmail.com> <3fa15144-dfac-4d28-aead-3380b26929c3@cs.tcd.ie> <CAHBU6isy0+nDWbEfiLGZ_+_vEVUbwcQzYftL9mium3Zu9onPZg@mail.gmail.com> <E762B4CC9215DC579F537D1C@PSB>
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: <E762B4CC9215DC579F537D1C@PSB>
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.21)
X-Recommended-Action: accept
X-Filter-ID: 9kzQTOBWQUFZTohSKvQbgI7ZDo5ubYELi59AwcWUnuUcMLiL8mSMTqJFFp05aaofGr0KXhyBx8Lw Fh3ylN1QXyu2SmbhJN1U9FKs8X3+Nt127hcteP1p0NVNV47moiZtUnZMMMyaNBeO+OvFQHUlG4JL M0i5ZAms0EHrvcCaVIOkMOSkOp5SZTTujgpzf/BMGnT3EFAinyrilm9zau/FuzkQt9Nb4Ml7QXdk EetczWCYKeH5wJNE2hk+QjLN5lBEeB7itP8hgjDRserKv4bhbzi838DBmUKWhOLHfo543wbEMzer JfQa9UAYKsgEV8p+MUJTS2Jsxpkx+IHIsDarm2U3gyy0nlbakKK22WPBaizjKzb+JrnOTbl8FYp7 CIWjverajYy2yB71RZy29b9HL7yliuqXZvH3i216cQum166L4O5yPeOhzvfP/bz2Dm2KU2SI+Dve s8qbaAZWQiv7frzauF+QjKu6oX6LBzjzlWgqfd3yCph9Fk4Q3xWSCSeFPb1iyUlQd+r17D/fFphx c1evpTzuvPpWpSDWWnJUm10fngh4R+TXCPpbAea4jg3yTTRaSfABYUfS7vmcB/jhlIx33I6Vrawi SlMZ97jGX4yuzkZyG+axiRILgXldNWElE2YQOZTzEe+cgopw4uVS65e7Cn3TQsxPN8TQ8dgakCoY 4L7u6QJ/jXXAPItovk04xjKCYeF04B6hleoQPr7AIRYWT4dpnIhFHj+aGmRuDq10pmveITm+EC18 VwUbxBEWlBHd2wJ53rPs265wcrWXIldQmFkSdUPFCTIGWBTY2RXaObuN/Y63UjpMr3ISezU2Mp3S GutIt9FDmIKriVSZwjJYRUhjkoDG+CrHa7j0dVEpvq7yV99KA1cbo0NX/TJ1lzKJsGgv1+QO3ICT rUy0yodPtRVQsUtxoBYu6t30me1PJQcrCIAhqqJ7s6gdsDKnio+4oSAzJ8FbTba/lp0AiVHuAq4k 7PqG9M5idz7joR4jZ7Bi4PBsyNibYLAbU0/fNjigEXZs2cCxi5yxaGoE5RxwEiTVJqDh0qKoKsXx 5lnc3OIdhlrMPJplvH+k7U49U4SHzq6gbzbcgxqibpN2APC7lsKKo0Sf06rIKwX7jl/vZ+cXa4SP MMsvIvQ05tn8UcLJ76KVsbN5HBpfa06JMua64ES/1JPlsdu+J2Iiht7K14atNZaliZXSUa1LiSw3 EDGKkrCXZFrT16KwlUOwsgjV4Yyuc3xBXZw/NdE/HnUgLDVHXYQq70AZoCvKF4Jp
X-Report-Abuse-To: spam@se02.mfg.siteprotect.com
X-Complaints-To: abuse@se01.mfg.siteprotect.com
Message-ID-Hash: KMM2POSP32YMDST3Z2WKG3KW5XS7C6LK
X-Message-ID-Hash: KMM2POSP32YMDST3Z2WKG3KW5XS7C6LK
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
CC: Eliot Lear <lear@lear.ch>, last-call@ietf.org, Eric Rescorla <ekr@rtfm.com>
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/QvR4O4NThECnMYYBjtN-3c8EYK4>
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/20/2026 6:08 PM, John C Klensin wrote:
>
> --On Wednesday, May 20, 2026 17:25 -0700 Tim Bray
> <tbray@textuality.com> wrote:
>
>>   I think there has been value in the discussion but I also would
>> hate to be a WG chair trying to make those consensus calls.
>>
>> What I'd like to see is something that unfortunately I've never
>> seen the IETF do: Publish a document that summarizes the issues
>> that came up in this sequence of repeating discussions, being fair
>> to the proponents of the various theses.
> Tim,
>
> At the risk of disagreeing with Rob, I am not aware of anything that
> would prohibit the IETF from doing that if there was rough consensus
> that it would be a good idea.  I don't have time to sift through them
> and it would be pre-IETF, but my recollection is that there were some
> rather early RFCs that did just that, summarizing the various
> positions and the relevant pros and cons.  More important, not only
> could the ISE publish such a document, but the summary and evaluation
> required, and publication of the results, would clearly be in scope
> for the IAB they were willing to take it on.
>   
>> This would reflect the meta-consensus that any consensus in this
>> space is going to be *very* rough. And I think it would be valuable
>> and instructive.
> Agreed.  And, to a first order approximation, I think my suggestion,
> Brian's, yours above, and probably even EKR's pq-rollout notes are
> headed in the same direction.

The problem is that different participants have a very different version 
of the risks, and also on the timeline.

Take the question on when would a cryptographically relevant quantum 
computer (CRQC) become available. The answers range from never because 
the physics is too hard (https://eprint.iacr.org/2025/1237) to "in 10 
to 15 years" (see the graphs in EKR's pq-rollout paper), to "we have 
better be ready in 2029" 
(https://blog.google/innovation-and-ai/technology/safety-security/cryptography-migration-timeline/)

Then ask whether ML-KEM specifically is reasonably secure. The opinions 
range from ML-KEM is probably fine 
(https://keymaterial.net/2025/11/27/ml-kem-mythbusting/) to "lots of 
new Post Quantum algorithm have been broken in the past, so there is 
some risk", to "The dirty hands of secret services are all over this 
design, so it is probably already backdoored" (https://blog.cr.yp.to/)

With any two answers to these questions, you get different policies. You 
also get different senses of urgency. If you believe that CRQC will be 
available real soon now, you are likely want to deploy Post Quantum 
solutions asap, and consider any attempt to delay that deployment as 
seriously misguided. If you believe that the secret services have 
already broken ML-KEM, you will see any attempt to standardize pure Post 
Quantum algorithms as playing in the hands of these services, either as 
a paid shill or a useful idiot. Put the holders of these two opinions in 
the same room, and the temperature is quickly going to rise.

Could we get some consensus? Probably yes for deploying hybrid key 
exchange algorithms asap, like hybrid ML-KEM and x25519. The partisans 
of doing something quickly might grumble that this is extra overhead, 
but this practical enough. But probably no for signature algorithms, 
because the overhead of deploying hybrids is quite large.

What would I see, personally? I would love to have an alternative to 
ML-KEM and ML-DSA, a different family of post quantum algorithms that 
could be ready for people that are really anxious about the interference 
of secret service, and that could be here and ready should ML-KEM or 
ML-DSA be broken. The IETF should be welcoming efforts like that.

-- Christian Huitema

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