IETF Logo Mail Archive

[TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 05 April 2026 03:07 UTC

Return-Path: <ietf-dane@dukhovni.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 83637D68F4C6 for <tls@mail2.ietf.org>; Sat, 4 Apr 2026 20:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775358431; bh=FXw2ZJBPKFadlIFTfmRQoNqN4iJpzpemNrbibuv1tl0=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To; b=Sbu88XqaXaYlbzWlNgo/UGrSmdh0ry8cJ8304TKrU6F8odw6HByCwOITo0qNVVnlD drQNE0UXjvioknfiYFbYatGLfFNu2wdsCnuf85p1XzEYn+790phuWF+v3+VFkYoiOu HLRnlI+zyDVjgwF93cRPD21cC6ecB9MMSM7ESqpE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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, 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
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
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 VFmDlpUcSvOm for <tls@mail2.ietf.org>; Sat, 4 Apr 2026 20:07:11 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (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 D4B5BD68F4C1 for <tls@ietf.org>; Sat, 4 Apr 2026 20:07:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1775358421; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=FXw2ZJBPKFadlIFTfmRQoNqN4iJpzpemNrbibuv1tl0=; b=xgqcWlvIKaTGnGUlTTA4IKV+vGEYo9wedMKCeM1YnAROKAZQV67jLb/XZTI1F5gy+iAdp U286rLwRy3u51qzlke/Z0qgO6c/PHFr51m7J0fd32mdwLM0v4lANgu5mQ6CmHLCLWMslF3Z VLFkF9ImeQyjScUHNeuL9g8/t0D8O5I=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id EB5C6937701; Sun, 05 Apr 2026 13:07:01 +1000 (AEST)
Date: Sun, 05 Apr 2026 13:07:01 +1000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <adHR1YEW-mPEb_BT@chardros.imrryr.org>
References: <CAF8qwaBcotZqOnY2qJ6d0fRoa=5v0sZTOSWqeqkou+bLJcy9LA@mail.gmail.com> <CABcZeBPr+WeivTWpSCVC4f95fRuSiOytvvBPB_6r+af9Didhgw@mail.gmail.com> <CEB84168-5998-432A-9D62-36E28B9CDFA5@vigilsec.com> <CABcZeBM-eoqh+kJ7H6SiwC9p4tKAt+YiQhzetJZJmPNpXc+5OA@mail.gmail.com> <CAF8qwaALDXR6d=jLD46wXmKHDjyj=OdJ1X3a1AgxF+ByQceeMg@mail.gmail.com> <697d6134-0083-4933-8531-9be49118be7d@cs.tcd.ie> <adCCIZsvHqgci5LT@chardros.imrryr.org> <597455e4-29e1-46a0-a9a7-b87c5adbaec7@cs.tcd.ie> <adFBMGhVMOl2eptE@chardros.imrryr.org> <34c6c882-4cef-4350-9afa-0edb0b460eb6@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <34c6c882-4cef-4350-9afa-0edb0b460eb6@cs.tcd.ie>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: BAGTM6VWOETBM5HNKSKPCIIXV6VF2AYV
X-Message-ID-Hash: BAGTM6VWOETBM5HNKSKPCIIXV6VF2AYV
X-MailFrom: ietf-dane@dukhovni.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: tls@ietf.org
Subject: [TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"
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/0z0GeZrDYLOpoqMBtUY71CfAGpE>
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>

On Sat, Apr 04, 2026 at 09:30:16PM +0100, Stephen Farrell wrote:

> I do agree it might help move matters along though if the
> TLS WG reached consensus that deploying hybrids is the BCP
> for the present. I don't think we've established that, have
> we? Have we even been asked the question?

I keep trying to ask the question, and as it seems that use of hybrids
remains the prudent best/current practice, I don't see a barrier to
reaching "rough" consensus on that question.

Recent theoretical progress on reducing the resource requirements
(logical qbits, and circuit sizes, i.e. gate counts and time) for
breaking 256-bit ECC with Shor's algorithm, may have reduced the
perceived value of the ECC components of hybrids for some QC "optimists"
who were betting on CRQC's to show up in O(decade), but now think it may
much sooner than previously expected.

So support for hybrid may be slightly more tepid this month than last,
but I still expect it to be possible to find a rough consensus along
those lines.

-- 
    Viktor.  🇺🇦 Слава Україні!

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