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

[Erwin Hoffmann <[e-mail]>]

Hi Dennis,

thanks for sharing. But this only reflects parts of the discussion.

Since I too provide public mail listings for my users, I know, this is
a difficult issue.

From my point of view, this IETF Web-based ML is dysfunctional because
it is difficult to digest the important topics.

Subscribers often express their oppinion not matching the topic
(Subject). This is bad for readers and digesting.

Regards.
--eh.


Am Montag, dem 20.07.2026 um 22:55 +0200 schrieb Dennis Jackson:
>  
> The TLS Mailing List Archive is public & available at the following
> url: 
>  
> https://mailarchive.ietf.org/arch/browse/tls/
>  
> Bulk extracts can also be downloaded with rsync as described here: 
>  
> https://www.ietf.org/about/open-records/
>  
> Best,
>  Dennis
>  
> On 20/07/2026 22:08, Ken Kubota wrote:
>  
>  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> > I am writing to clarify the statement in your email regarding the
> > statistic "7/10 WG participants favor advancing the document."
> >  
> > 
> >  
> >  
> > Transparency is a core principle of the IETF.
> >  
> > 
> >  
> >  
> > Please provide the breakdown or data that supports this figure.
> >  
> > 
> >  
> >  
> > Thank you for your assistance.
> >  
> > 
> >  
> >  
> > Kind regards,
> >  
> > 
> >  
> >  
> > Ken Kubota
> >  
> >  ____________________________________________________
> >  
> >  Ken Kubota
> >  https://doi.org/10.4444/100
> >  
> >  
> >  
> >  
> >  
> >  
> > 
> >  
> > >  
> > > Am 20.07.2026 um 21:51 schrieb Joseph Salowey <[e-mail]>:
> > >  
> > >  
> > >  
> > > As others have mentioned on this thread, a consensus call is not
> > > a
> > >  vote. We used public responses to get a sense of where the
> > > mailing
> > >  list participants are leaning. In this case, we saw many
> > > participants
> > >  who had not participated in the previous calls or on the TLS
> > > list in
> > >  general.  The chairs have the remit to judge consensus based on
> > > input
> > >  such as taking into account the level of previous participation
> > > of the
> > >  sender.  There is no specific threshold which represents rough
> > >  consensus. In this case, we judged that the responses show rough
> > >  consensus to move forward with publishing the document and to
> > > address
> > >  the issues raised during the consensus call.
> > >  
> > >  All of the mail used as part of this process is publicly
> > > available. We
> > >  do not intend to release any further detailed analysis including
> > >  "numbers" or "weights/methods".
> > >  
> > >  Thanks,
> > >  
> > >  Joe
> > >  
> > >  
> > >  On Sun, Jul 19, 2026 at 6:55 AM DA PIEVE Fabiana
> > >  <[e-mail]> wrote:
> > >  
> > > > 
> > > >  Can I kindly ask if there is evidence that can be provided for
> > > > your statements about the numbers, and more info on the weights
> > > > / method you apply to weigh answers, from both sides ?
> > > >  
> > > >  I imagine you have a table/a scheme/something, with
> > > > participants, an established method for the weights, weights
> > > > associated to each person on both sides, other elements you may
> > > > have considered relevant ....
> > > >  
> > > >  Thank you for your kind attention
> > > >  
> > > >  Fabiana Da Pieve
> > > >  Team Leader Post-Quantum Cryptography
> > > >  
> > > >  European Commission
> > > >  DG Communications Networks, Content and Technology
> > > >  Unit C4 – Emerging & Disruptive Technologies
> > > >  
> > > >  
> > > >  
> > > >  
> > > >  -----Original Message-----
> > > >  From: Joseph Salowey <[e-mail]>
> > > >  Sent: Sunday, July 19, 2026 1:31 PM
> > > >  To: <[e-mail]> <[e-mail]>
> > > >  Cc: [e-mail]; tls-chairs
> > > > <[e-mail]>
> > > >  Subject: [TLS] MLKEM Consensus Call (was WG Last Call: draft-
> > > > ietf-tls-mlkem-08 (Ends 2026-07-08))
> > > >  
> > > >  During this last call we received responses from a large
> > > > number of people on both sides of the issue, many were from
> > > > first time participants, which was probably due to the
> > > > extensive social media coverage. The primary objection
> > > > discussed extensively during the call concerned the relative
> > > > strength of pure versus hybrid approaches.
> > > >  Fundamentally, this is a judgement call people have to make
> > > > for themselves, and the chair’s role is not to just decide for
> > > > the WG b=t rather to take the sense of the WG. The chairs
> > > > ultimately bear the burden of how to weigh those responses
> > > > against those of long-time WG participants with demonstrated
> > > > expertise. By pure numbers, more people want to progress the
> > > > document than not, but this alone does not constitute rough
> > > > consensus. However, if we look at pre-existing WG participants
> > > > or people with demonstrated expertise, roughly 7/10 WG
> > > > participants favor advancing the document, which shows rough
> > > > consensus to move the document forward.
> > > >  
> > > >  Even though there is rough consensus to move forward we feel
> > > > several issues raised during the last call need to be
> > > > addressed. Some of the issues below have text proposals that we
> > > > think are appropriate given the list discussions, we will
> > > > accept feedback on them, but we do not intend to make
> > > > significant changes since these issues have already had a fair
> > > > amount of discussion
> > > >  
> > > >  1. Emphasize the status of the document
> > > >  
> > > >  Currently the pure ML-KEM algorithm is recommended “N” in t=e
> > > > IANA registry and is a non-standards-track informational
> > > > document while
> > > >  X25519MLKEM768 is marked as recommended “Y” and is defined =n
> > > > a standards-track document.  While this indicates the
> > > > preference for the hybrid approach, it was pointed out that the
> > > > meaning of the “N =80  value may not be obvious to readers
> > > > unfamiliar with the IETF process.
> > > >  
> > > >  Based on the discussion the following will be added to the
> > > > IANA considerations section, which the IESG approved for pure
> > > > ML-DSA, to save readers following existing links in the
> > > > document to understand the meaning on N and to further
> > > > addresses some hybrid/pure approach
> > > >  concerns:
> > > >  
> > > >  As defined in Section 3 of [RFC9847], the value N indicates
> > > >  
> > > >       That the item has not been evaluated by the IETF and that
> > > > the IETF
> > > >       has made no statement about the suitability of the
> > > > associated
> > > >       mechanism.  This does not necessarily mean that the
> > > > mechanism is
> > > >       flawed, only that no consensus exists.  The IETF might
> > > > have
> > > >       consensus to leave an item marked as "N" on the basis of
> > > > the item
> > > >       having limited applicability or usage constraints
> > > >  
> > > >  2. Randomness requirements
> > > >  
> > > >  Jacob Appelbaum raised the issue that m random input value is
> > > > provided directly to the ML-KEM.Encaps() and encrypted and sent
> > > > to the TLS Client. This means that an attacker who can use raw
> > > > random output to determine the PRNG state can use a connection
> > > > with the server to attempt to derive the server's PRNG state
> > > > and attack other connections.
> > > >  
> > > >  This issue pertains to the ML-KEM algorithm itself and is not
> > > > unique to TLS. The NIST document currently does require a
> > > > secure PRNG defined in NIST SP 800-90A-C and RFC 9846 discusses
> > > > PRNGs in Appendix C. Any text added to address this point would
> > > > need to be included both in this document and the ECDHE-MLKEM
> > > > document.
> > > >  
> > > >  Text to go into Section 4.2, after the existing "MUST NOT
> > > > reuse randomness" line:
> > > >  
> > > >  “During encapsulation, ML-KEM encrypts m, drawn from a random
> > > > bit generator, so the peer holding the decapsulation key
> > > > recovers m exactly. Any information that m provides about other
> > > > outputs of the generator is therefore available to that peer.”
> > > >  
> > > >  And the following text for Section 5 (security
> > > > considerations):
> > > >  
> > > >  “The disclosure of raw random number generator (PRNG) output
> > > > in TLS and other protocols can be used in an attack to
> > > > compromise the state of an insecure RNG as described in
> > > > [DUALEC-TLS]. The m value in ML-KEM is an additional place
> > > > where raw RNG output is disclosed to an active attacker.
> > > >  Because the m value in ML-KEM is randomly generated and
> > > > transmitted to the client, it is important to follow the PRNG
> > > > guidance in [FIPS203] and [RFC9846]. Implementers MAY choose to
> > > > implement mechanisms from [RFC8937] for additional protection
> > > > across sessions."
> > > >  
> > > >  [DUALECTLS] -
> > > > https://www.usenix.org/system/files/conference/usenixsecurity=4
> > > > /sec14-paper-checkoway.pdf
> > > >  
> > > >  Similar text will also go into the ECDHE-MLKEM document.
> > > >  
> > > >  3. Document Track & Stream
> > > >  
> > > >  The document is currently in the RFC stream on the non-
> > > > standards Informational track. Some have argued for the ISE
> > > > stream so that the document does not reflect IETF consensus or
> > > > the document be included on the experimental track.  Both of
> > > > these approaches will result in the publication of an RFC which
> > > > is the same result as the current path to the average RFC
> > > > consumer. We believe we have consensus to publish this as an
> > > > informational working group document
> > > >  
> > > >  Joe
> > > >  
> > > >  
> > > >  On Wed, Jun 24, 2026 at 8:00 AM Joseph Salowey via Datatracker
> > > > <[e-mail]> wrote:
> > > >  
> > > > > 
> > > > >  This message initiates a new Working Group Last Call for
> > > > > draft-ietf-tls-m=kem[1], which defines standalone ML-KEM key
> > > > > establishment for TLS 1.3. The=main question before the
> > > > > working group is: "Should the working group publi=h a
> > > > > document specifying stand alone ML-KEM?". If there is rough
> > > > > consensus =hen we will push to refine and publish the
> > > > > document; otherwise, we will st=p discussing the draft and
> > > > > not progress it. Please respond to this call in=icating
> > > > > whether you support publishing a document specifying a stand
> > > > > alone=ML-KEM. Please refrain from further discussion on this
> > > > > topic as most argum=nts have been discussed multiple times.
> > > > >  
> > > > >  Why are we holding this consensus call now?
> > > > >  
> > > > >  Significant developments have occurred both within this
> > > > > document and in t=e broader TLS ecosystem to address the
> > > > > concerns raised in the last WGLC. T=erefore, the third
> > > > > consensus call is warranted. We ask the working group t=
> > > > > consider document publication in light of these recent
> > > > > changes:
> > > > >  
> > > > >  - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem:
> > > > > Following a separat= consensus call, the WG agreed to promote
> > > > > the X25519MLKEM768 hybrid group =o Recommended: Y in the IANA
> > > > > registry. Consequently, the IANA registry wil= reflect a
> > > > > clear community preference for a hybrid because Recommended:
> > > > > Y =learly indicates this while the standalone ML-KEM groups
> > > > > defined in this d=aft remain Recommended: N. The updated
> > > > > security considerations in [1] refe=ence the IANA registry to
> > > > > emphasize this preference.
> > > > >  
> > > > >  - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis:
> > > > > The WG recentl= reached consensus to explicitly prohibit key
> > > > > share reuse across connectio=s in TLS 1.3. The new text
> > > > > changes the guidance from SHOULD NOT to a stric= MUST NOT.
> > > > > This resolves the concerns regarding static key reuse and its
> > > > > a=sociated privacy and forward-secrecy risks for ML-KEM.
> > > > >  
> > > > >  - Nadim updated the ProVerif model of TLS 1.3 to evaluate
> > > > > KEM and hybrid =EM 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 =f the
> > > > > components is compromised.
> > > > >  
> > > > >  - Liaisons: We received liaison statements from multiple
> > > > > SDOs including  =-RAN[2], IEEE 802.11[4] and from 3GPP[3]
> > > > >  expressing support for the publi=ation of draft-ietf-tls-
> > > > > mlkem as an RFC as they rely on the IETF to provid= a stable
> > > > > normative reference.
> > > > >  
> > > > >  Please note that a third-party IPR disclosure exists [5]
> > > > > against this doc=ment regarding patents related to the
> > > > > underlying ML-KEM algorithm. This IP= declaration has not
> > > > > changed since the last WGLC. As a reminder, per BCP 7=, the
> > > > > IETF takes no stance on the validity of patent claims, and
> > > > > the worki=g 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 Co=duct (BCP 54) and the TLS
> > > > > WG's Mail List Procedures. Keep feedback profess=onal,
> > > > > 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-ie=f-tl
> > > > >  s-mlkem
> > > > >  
> > > >  
> > > >  
> > >  
> > >  _______________________________________________
> > >  TLS mailing list -- [e-mail]
> > >  To unsubscribe send an email to [e-mail]
> > >  
> > >  
> > >  
> >  
> >  
> >  
> >  
> >  
> >  
> >   
> > _______________________________________________
> > TLS mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >  
>  
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 36553F7F9C58D1CC
PGP key-fingerprint:  950B 5555 0B08 5A2A 1C00 9594 3655 3F7F 9C58 D1CC