IETF Logo Mail Archive

[TLS] Re: [EXTERNAL] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

David Adrian <davadria@umich.edu> Wed, 24 June 2026 19:10 UTC

Return-Path: <davadria@umich.edu>
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 ACCA0106BCE2F for <tls@mail2.ietf.org>; Wed, 24 Jun 2026 12:10:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782328242; bh=5kJFvZPP7RW63s7xQcL5KS7ZeSS0a+2e8YlSxGnGpdk=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=IjOveNyEjD6aPRJflCBzcJqcTqfGO4ZpfYJwf2WzPYM6me3p9mAQvqnFpIHL/vR0U qh4nIyJ/Dhb+jjmnF+tcmIdw0k0MsEkdETfSJBd8ivjs6Mq9FjclpmgxwBKs9RYyr1 jO3YZh0OG6fkO+bXScaIIaFpVPuWlicqSWjjAhAc=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 vuF8YXtpSdxu for <tls@mail2.ietf.org>; Wed, 24 Jun 2026 12:10:41 -0700 (PDT)
Received: from yurei.relay-egress.a.mail.umich.edu (yurei.relay-egress.a.mail.umich.edu [18.216.144.57]) (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 77BC0106BCDE5 for <tls@ietf.org>; Wed, 24 Jun 2026 12:10:25 -0700 (PDT)
Received: from amazing-bakeneko.authn-relay.a.mail.umich.edu (ip-10-0-72-163.us-east-2.compute.internal [10.0.72.163]) by yurei.relay-egress.a.mail.umich.edu with ESMTPS id 6A3C2B9B.27D1193D.7FC4A9C5.1292154; Wed, 24 Jun 2026 15:10:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=relay-2; t=1782328219; bh=RMm+IBAAh9HCTknpVHdDcKPeriikLVbQjrs7KwCFEPs=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=pV51CBRE8wasA2z/G3LAeqisgNsbJLGFNGWVaiXpDEGU3dH+q49uIsawNhTSJcEXD 88E+xJjQf4vGh96e19MY72tUOENkoTffxw6CF+yi9srEibEg9n3dwNXBP6uvNhSalM Z3vsbSz0VkhSQh0M5nGBHeBau1o5riHgURUww+CR4HAE+rH3PhhSPA1RBFgAcTP5Ml 7RepBI8bnLOPOclxwpMcBLLcKEKTDLG1U+y9Ckrt5x2R3xixeKdDnNRO53F7t/2PsM sscb43Y645mBbyXo45U93Vu5CI3oQcL12a2eUJXpf8LfVyKxJWzGZRuHexQzACLlqX bhe0b1Tcj9odg==
Authentication-Results: amazing-bakeneko.authn-relay.a.mail.umich.edu; iprev=pass policy.iprev=209.85.210.43 (mail-ot1-f43.google.com); auth=pass smtp.auth=davadria
Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by amazing-bakeneko.authn-relay.a.mail.umich.edu with ESMTPSA id 6A3C2B9B.111E1BF0.4E7ADA66.2040245; Wed, 24 Jun 2026 15:10:19 -0400
Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-7e6d991991dso1150126a34.3 for <tls@ietf.org>; Wed, 24 Jun 2026 12:10:19 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AFNElJ8GTNbpQch0jiIPr1P2NhIaf51CZXm0o3HfsxzzeLcblRSJ8pQXMKjAEZJ+BonE8uHgR+0=@ietf.org
X-Gm-Message-State: AOJu0YxzudU6w2fL0pptRxVALmEr53CEmV0/VexK/EkT3CWRjoWvLVW3 7i6XsF05EhfaNOU0txxRtfx8lVbVcIv69cuBKX857WjoTV6+2UJHJGstOy+xa/3XBuNXLHvX++M TeDcmG0wXvQPg8rpCMHy4K2weSenZEso=
X-Received: by 2002:a05:6830:4409:b0:7de:5612:d420 with SMTP id 46e09a7af769-7e986c7513bmr4163089a34.18.1782328218214; Wed, 24 Jun 2026 12:10:18 -0700 (PDT)
MIME-Version: 1.0
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg> <LV0PR21MB6623D2F9B3393C59B19817838CED2@LV0PR21MB6623.namprd21.prod.outlook.com>
In-Reply-To: <LV0PR21MB6623D2F9B3393C59B19817838CED2@LV0PR21MB6623.namprd21.prod.outlook.com>
From: David Adrian <davadria@umich.edu>
Date: Wed, 24 Jun 2026 15:10:05 -0400
X-Gmail-Original-Message-ID: <CACf5n79gsVN=UoCPUJVn=0ZOqZsoVda__5mwZohCdLjbqhu-=Q@mail.gmail.com>
X-Gm-Features: AVVi8Cc3fE-dpw7Oml0T5uxEDGVKulmfjp1ZJDCh3Rb17g9RtuE7qF1svF-jfuo
Message-ID: <CACf5n79gsVN=UoCPUJVn=0ZOqZsoVda__5mwZohCdLjbqhu-=Q@mail.gmail.com>
To: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051e571065504a010"
Message-ID-Hash: N5DFQMUTDDZMU6XAF56YGJB4SULIXCY5
X-Message-ID-Hash: N5DFQMUTDDZMU6XAF56YGJB4SULIXCY5
X-MailFrom: davadria@umich.edu
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: "draft-ietf-tls-mlkem@ietf.org" <draft-ietf-tls-mlkem@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "tls@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXTERNAL] WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
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/SnOQ0cEnlE591Ttwfgjyj4sAui0>
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 support publication of this document, and emphasize again, that we have
implemented this in Chrome.

On Wed, Jun 24, 2026 at 1:55 PM Andrei Popov <Andrei.Popov=
40microsoft.com@dmarc.ietf.org> wrote:

> I support publication of this document.
>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: Joseph Salowey via Datatracker <noreply@ietf.org>
> Sent: Wednesday, June 24, 2026 8:00 AM
> To: draft-ietf-tls-mlkem@ietf.org; tls-chairs@ietf.org; tls@ietf.org
> Subject: [EXTERNAL] [TLS] WG Last Call: draft-ietf-tls-mlkem-08 (Ends
> 2026-07-08)
>
> This message initiates a new Working Group Last Call for
> draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key establishment
> for TLS 1.3. The main question before the working group is: "Should the
> working group publish a document specifying stand alone ML-KEM?". If there
> is rough consensus then we will push to refine and publish the document;
> otherwise, we will stop discussing the draft and not progress it. Please
> respond to this call indicating whether you support publishing a document
> specifying a stand alone ML-KEM. Please refrain from further discussion on
> this topic as most arguments have been discussed multiple times.
>
> Why are we holding this consensus call now?
>
> Significant developments have occurred both within this document and in
> the broader TLS ecosystem to address the concerns raised in the last WGLC.
> Therefore, the third consensus call is warranted. We ask the working group
> to consider document publication in light of these recent changes:
>
> - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a separate
> consensus call, the WG agreed to promote the X25519MLKEM768 hybrid group to
> Recommended: Y in the IANA registry. Consequently, the IANA registry will
> reflect a clear community preference for a hybrid because Recommended: Y
> clearly indicates this while the standalone ML-KEM groups defined in this
> draft remain Recommended: N. The updated security considerations in [1]
> reference the IANA registry to emphasize this preference.
>
> - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG recently
> reached consensus to explicitly prohibit key share reuse across connections
> in TLS 1.3. The new text changes the guidance from SHOULD NOT to a strict
> MUST NOT. This resolves the concerns regarding static key reuse and its
> associated privacy and forward-secrecy risks for ML-KEM.
>
> - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and hybrid
> KEM groups in TLS 1.3. This supports other results which show that KEMs are
> secure when used in TLS 1.3 and that hybrid groups are secure even if one
> of the components is compromised.
>
> - Liaisons: We received liaison statements from multiple SDOs including
> O-RAN[2], IEEE 802.11[4] and from 3GPP[3]  expressing support for the
> publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF to
> provide a stable normative reference.
>
> Please note that a third-party IPR disclosure exists [5] against this
> document regarding patents related to the underlying ML-KEM algorithm. This
> IPR declaration has not changed since the last WGLC. As a reminder, per BCP
> 79, the IETF takes no stance on the validity of patent claims, and the
> working group may decide to proceed with a technology despite IPR
> disclosures if it decides that such use is warranted.
>
> Conduct Reminder: Given the heated nature of previous discussions on this
> topic, participants are strongly reminded to adhere to the IETF Code of
> Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep feedback
> professional, technical, and focused on the document's text.
>
> This working group last call will end on 2026-07-08.
>
> Joe and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
> [2] https://datatracker.ietf.org/liaison/2198/
> [3] https://datatracker.ietf.org/liaison/2151/
> [4] https://datatracker.ietf.org/liaison/2148/
> [5]
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem
>
> _______________________________________________
> 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.46.0 | Report a Bug | By Email | System Status