[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

[Loganaden Velvindron <[e-mail]>]

Hi All,

I am also concerned regarding those issues raised. While I understand
that compliance
mandates pure MLKEM1024 for some government, I still prefer
x25519mlkem768 or even x25519mlkem1024 as
a safer bet for general adoption.

Like we saw with "Kyberslash",There are implementation issues that can
happen. I would prefer to see
some discussion in the draft so that developers are at least aware of
those issues.


If web browsers can provide both x25519mlkem768 (and maybe
x25519mlkem1024 at a later time ?)
and mlkem1024 for satisfy both demands, I think it's
a good way for us to move forward.

If we can agree to support both hybrid and pure, then I'm OK with
supporting the I-D to satisfy those compliance
requirements for the US government.

On Wed, 5 Nov 2025 at 23:04, Stephen Farrell <[e-mail]> wrote:
>
>
> I re-read the document. It has zero commentary on the issues about
> hybrids vs. pure PQ. It may be hard to reach rough consensus on what
> to say about that, but it is a topic where people have significantly
> different opinions, so I think we ought say something, for example,
> along the lines of, "At the time of writing a significant number of
> knowledgeable people consider it better to deploy hybrid KEMS, while
> some do dispute that. Opinions may change over time." I'd be happy
> but surprised if the WG had consensus to add such text, but we
> should. Absent that, I think producing an RFC based on this draft
> provides a misleading signal to the community.
>
> Also - what happened to the adopt-but-park plan? Did that get lost
> in the fog of appeals?
>
> Cheers,
> S.
>
> On 05/11/2025 18:51, Sean Turner via Datatracker wrote:
> >
> > Subject: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)
> >
> > This message starts a 3-week WG Last Call for this document.
> >
> > Abstract:
> >     This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as
> >     NamedGroups and and registers IANA values in the TLS Supported Groups
> >     registry for use in TLS 1.3 to achieve post-quantum (PQ) key
> >     establishment.
> >
> > File can be retrieved from:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
> >
> > Please review and indicate your support or objection to proceed with the
> > publication of this document by replying to this email keeping [e-mail]
> > in copy. Objections should be motivated and suggestions to resolve them are
> > highly appreciated.
> >
> > Authors, and WG participants in general, are reminded again of the
> > Intellectual Property Rights (IPR) disclosure obligations described in BCP 79
> > [1]. Appropriate IPR disclosures required for full conformance with the
> > provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
> > any. Sanctions available for application to violators of IETF IPR Policy can
> > be found at [3].
> >
> > Thank you.
> >
> > [1] https://datatracker.ietf.org/doc/bcp78/
> > [2] https://datatracker.ietf.org/doc/bcp79/
> > [3] https://datatracker.ietf.org/doc/rfc6701/
> >
> >
> >
> > _______________________________________________
> > 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]