Nit (which doesn't change your main point):
ECDLP does have a 'worse case to average case' reduction within the prime
subgroup.
This should be obvious, but here it is anyways: given a worse case ECDLog
problem G, H, you can select random r_1, r_2, and formulate the discrete log
problem r_1G, r_2H (which is a random, that is, an average discrete log
problem), if you can solve y(r_1G) = r_2H, then x = y r_1 r_2^{-1} is a
solution to xG = H.
>From the 'Pedants R Us' department
________________________________
From: Antony Vennard <[email protected]>
Sent: Monday, June 29, 2026 7:36 AM
To: Joseph Salowey <[email protected]>; [email protected]
<[email protected]>; [email protected] <[email protected]>;
[email protected] <[email protected]>
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
Good morning,
...
That said, I do not believe the risk of ML-KEM (and ML-DSA) to be
severe: there is no known cryptanalysis currently exploiting rank >=2
module structure at these parameters that performs better than generic
lattice reduction. Module-LWE also has a (granted, an asymptotic)
worst-case-to-average-case reduction - something neither RSA nor ECDLP
had.
Kind regards,
Antony
On Wed, 2026-06-24 at 08:00 -0700, Joseph Salowey via Datatracker
wrote:
> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
