IETF Logo Mail Archive

[TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3

Simon Josefsson <simon@josefsson.org> Mon, 13 April 2026 05:01 UTC

Return-Path: <simon@josefsson.org>
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 96AA5DAFFFA5 for <tls@mail2.ietf.org>; Sun, 12 Apr 2026 22:01:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776056486; bh=STfNY5wb/oJpIyT3gITbYDHK0xTO0aorlxsStfAC3HU=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Uc27tTRoXfuGey3TIU9qqG2/Tb8G9vBog8qYRQccFZ5XlSADWrjwnJFMZQX9JaCjj DX10e+bzw0cZIriGfdPIagD1AlMMoQqRpxF+GJAT/LSH0oJYIcwn1OfPciy1WRotYX c2G+J/8hzOs8XtJpdDQS9igms7CyxIdAvLkQCc3E=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level:
X-Spam-Status: No, score=-4.401 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b="on8DsFx7"; dkim=pass (2736-bit key) header.d=josefsson.org header.b="V56OU7o3"
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 MzZdA2UqfKjs for <tls@mail2.ietf.org>; Sun, 12 Apr 2026 22:01:23 -0700 (PDT)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D4AB6DAFFF9D for <tls@ietf.org>; Sun, 12 Apr 2026 22:01:22 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2303; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zVDkgXMDxrjxTjNEL7t3ihE13gVHlRAJqVEC/q3OSkY=; t=1776056469; x=1777266069; b=on8DsFx7YPvcida68GDeZGxLymw8EhzaWXgimkJgM/ZC+tEk9B2+fXy7isGZZPaRykBg29GEqkv dbZy0UQbSBg==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2303; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zVDkgXMDxrjxTjNEL7t3ihE13gVHlRAJqVEC/q3OSkY=; t=1776056469; x=1777266069; b=V56OU7o3qm1fRhQClFFb7gwzjQ5/ipWvZ5g52NvSgFw1yaJ4HWmiDXiZixEiVlso/WBIE56/76t yaUxrg8/eB6LIwlYoBfJzEGY+OHv2tzs7SqzVQSvxkyvSQ1yxYYSHNsusVIvB+jMRVBWrbMJrUe7L nEohO5XTHS1tiL4lwDQ+1CmxNxOcvCQGwcLlZirtMgLT87Pt3NEWHSpn+OIlFdhcCbvkj9Plub2x8 Rhs2atyPAI3yn+CPgemNOrgjL4vbY6+kN1MYhvp4YBoy1QuGmc5owo3g7gaSRj0FC8i9fUXWnnMxp 8VAeRGNxap0eZAa4WNYFvMVjBYTRPBwp0MQpuai8TfFwena/SWYFkCiQSHtHZPIkaqakXSDJ9KXvT fxrX6eL/RujdrUruGrfM7nehUo1TDHaKW+QzpPr9/vgVVtKA/5rI6mIUK3yuXN6kuojFsi07M;
Received: from h-178-174-130-130.a498.priv.bahnhof.se ([178.174.130.130]:58100 helo=frallan) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <simon@josefsson.org>) id 1wC9Q4-00HZ2v-Ii; Mon, 13 Apr 2026 05:01:08 +0000
From: Simon Josefsson <simon@josefsson.org>
To: Soatok Dreamseeker <soatok.dhole@gmail.com>
In-Reply-To: <CAOvwWh3BviyKLWqZR4u9kFr9bYW1s2bfjf+oRjsRuAozuSgfTg@mail.gmail.com> (Soatok Dreamseeker's message of "Sun, 12 Apr 2026 14:33:15 -0400")
References: <16CF0FDA-7263-461A-9F2B-D37DBEAF5DD9@sn3rd.com> <874ilg4j5f.fsf@josefsson.org> <CAMjbhoW2hGst4bOv0AsJceEeP9n-d-phBk3OSU+TmRz=SnwXLw@mail.gmail.com> <87zf3833tu.fsf@josefsson.org> <CAOvwWh3BviyKLWqZR4u9kFr9bYW1s2bfjf+oRjsRuAozuSgfTg@mail.gmail.com>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:23:260413:simon=40josefsson.org@dmarc.ietf.org::eVIgoZ0jCP5DsGBi:D1iu
X-Hashcash: 1:23:260413:bas=40cloudflare.com@dmarc.ietf.org::WAuhOiR1kqA9s6GC:Jvx0
X-Hashcash: 1:23:260413:tls@ietf.org::wJqwF/qNR02/Ge0o:04p1k
X-Hashcash: 1:23:260413:soatok.dhole@gmail.com::RheLgjq+aJFkezSU:k/He
Date: Mon, 13 Apr 2026 07:01:21 +0200
Message-ID: <87bjfnfo7y.fsf@josefsson.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Message-ID-Hash: DT573S4I45QM2P4IKCKLLNCARZZM2PA2
X-Message-ID-Hash: DT573S4I45QM2P4IKCKLLNCARZZM2PA2
X-MailFrom: simon@josefsson.org
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@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3
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/nIPm_pWDxPZGn3iwl0z6uMevWX0>
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>

Soatok Dreamseeker <soatok.dhole@gmail.com> writes:

> As someone who *prefers* hybrid KEMs, I do not believe the same
> argument holds for hybrid signatures. There is no analogous "harvest
> now, decrypt later" against signature schemes. They can only be
> exploited once a CRQC exists, and not a moment sooner. The pre-QC
> algorithmic risk of pure ML-DSA vs hybrid ML-DSA is significantly
> lower than that of ML-KEM vs hybrid ML-KEM.

They can be exploited when, for example, any pre-quantum implementation
bug is identified.

You can't have end-to-end confidentiality without authentication, and
TLS uses signatures for authentication.

Thus you could make an argument that PQ-hybrid signatures is more
important than PQ KEMs, since signatures are a requirement to have ANY
kind of confidentiality guarantees.

Otherwise we are back to the old 1990's world of no protection against
active man-in-the-middle attacks.  Which is a nice situation to be in
for state-run attackers.  Given the popular use of man-in-the-middle
proxies serving large parts of the WWW these days, such attacks are
feasible.

My argument is that using new PQ crypto in hybrid with traditional
crypto is a reasonable and an appropriate measurement to protect against
throwing out the baby with the bathing water.

The cost of hybrids is motivated by the risks involved.  Diminishing
these risks, and exaggerating the costs, leads everyone in the wrong
direction.

/Simon

>
> On Sun, Apr 12, 2026 at 5:51 AM Simon Josefsson <simon=
> 40josefsson.org@dmarc.ietf.org> wrote:
>
>> Bas Westerbaan <bas=40cloudflare.com@dmarc.ietf.org> writes:
>>
>> > On Sun, Apr 12, 2026 at 11:35 AM Simon Josefsson <simon=
>> > 40josefsson.org@dmarc.ietf.org> wrote:
>> >
>> >> I've re-read the document and continue to believe that this work ought
>> >> not to be published through the TLS WG.  There are other publication
>> >> venues available for crypto algorithm registrations, and I believe using
>> >> our time in the WG on non-hybrid KEM's to be a bad idea because of all
>> >> the concerns expressed throughout the life of this document.
>> >>
>> >
>> > Simon, just to be sure you read the right document: this thread is not
>> > about KEMs.
>>
>> Thanks for the catch - one week of vacation in the sun tends to re-set
>> the terminology brain :)
>>
>> Please read my comment replacing 'non-hybrid KEM' with 'non-hybrid
>> PQ-Signature' above, and replace 'throughout the life of this document'
>> with 'by earlier discussions on the insecurity of non-hybrid PQ usage'.
>>
>> /Simon
>>
>> >
>> >
>> >>
>> >> /Simon
>> >>
>> >> Sean Turner <sean@sn3rd.com> writes:
>> >>
>> >> > This is the working group last call for Use of ML-DSA in TLS
>> >> > 1.3. Please review draft-ietf-tls-mldsa [1] and reply to this thread
>> >> > indicating if you think it is ready for publication or not. If you do
>> >> > not think it is ready please indicate why. This call will end on April
>> >> > 23, 2026.
>> >> >
>> >> > REMINDER: If you have not done so recently, review the TLS WG's Mail
>> >> List Procedures; see [2].
>> >> >
>> >> > The Chairs,
>> >> > Deirdre, Joe, and Sean
>> >> >
>> >> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/
>> >> > [2]
>> >> https://mailarchive.ietf.org/arch/msg/tls/ucdImHExlbOf4Q3BCG81gjzi2xE/
>> >> >
>> >> > _______________________________________________
>> >> > TLS mailing list -- tls@ietf.org
>> >> > To unsubscribe send an email to tls-leave@ietf.org
>> >> _______________________________________________
>> >> TLS mailing list -- tls@ietf.org
>> >> To unsubscribe send an email to tls-leave@ietf.org
>> >>
>> > _______________________________________________
>> > TLS mailing list -- tls@ietf.org
>> > To unsubscribe send an email to tls-leave@ietf.org
>> >
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-leave@ietf.org
>>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

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