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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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. 

That’s been the consensus for quite some time, as far as I recall. (Except for a few dissenters who absolutely can’t accept that somebody else may use pure mlkem1024.) 


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. 

I think this is the status quo, and the majority (at least, the way I read this WG) is not planning to change it. 



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/ <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/ <https://datatracker.ietf.org/doc/bcp78/>
> > [2] https://datatracker.ietf.org/doc/bcp79/ <https://datatracker.ietf.org/doc/bcp79/>
> > [3] https://datatracker.ietf.org/doc/rfc6701/ <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]

_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]