On Tue, Oct 7, 2025 at 9:18 AM Paul Wouters <[email protected]> wrote:
> On Tue, 7 Oct 2025, Eric Rescorla wrote: > > > Date: Tue, 7 Oct 2025 10:51:50 > > From: Eric Rescorla <[email protected]> > > Cc: "<[email protected]>" <[email protected]> > > To: Joseph Salowey <[email protected]> > > Subject: [TLS] Re: Working Group Last Call for Post-quantum Hybrid > ECDHE-MLKEM > > Key Agreement for TLSv1.3 > > > > I have reviewed this document and I think it is ready to go with > > one exception, namely the Recommended column. > > > > The RFC 8447 standard for "Recommended=Y" is: > > > > Per this document, a "Recommended" column has been added to many of > > the TLS registries to indicate parameters that are generally > > recommended for implementations to support. > > > > I think there's a general expectation that we want people to > > implement and deploy these algorithms, and I would expect > > that the X25519 and P-256 versions to be widely deployed, > > at least on the Web. Therefore, I think we should mark all of > > these as Recommended=Y. I note that this would require > > advancing this document as Proposed Standard. We should do > > that as well. > > Eric, > > As has been previously found, the problem of discussing the RECOMMENDED > Y for each draft separately, instead of periodically as a group, leads to > relitigating these things over and over again. That was true in the context of SSH, but it's not clear to me that it's true in the context of TLS, where the semantics of "RECOMMENDED=Y" are entirely different. For context, there are currently four such supported groups for TLS: X25519, X448, P-256, and P-384. Is there a substantive reason why the hybrids of these same groups with MLKEM ought not to be RECOMMENDED=Y? One new algorithm appears > and people want to rediscuss the other algorithms in the updated context > again. Would you really be opposed to letting the current drafts get > published with N while starting a dedicated document setup similarly to > how other WGs have do this, eg RFC 8247/8221/8624. > Yes, I'm opposed to it. I think it's wholly unnecessary, and would have the odd state where the algorithm in wide use is not at PS. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
