Dear Uri, I disagree. I’d argue that picking a hybrid construct (in this case for signatures, and in my preference the composite construction) is a gateway for future transitions (modulo the choice of the composed algorithms depending on the specifics of the transition itself). Once the algorithms are well understood, studied, and trusted (which seems to be the agreement for ML-DSA), hybrids still edge the risk management against implementation defects. To compromise the security of the composite scheme, the adversary has to be able to exploit 2 distinct flaws in both implementations at the same time, and that provides better security. The composite construction from the LAMPS WG does achieve this with minimal overhead in costs and complexity.
More PQC signature algorithms with better trade offs will eventually go through NIST, and we could reuse the same composite construction easily and quickly if a CRQC has not appeared before that. Even if it did appear, costs might still be a relevant factor, so the ECC part of the composite might not become meaningless immediately. Maybe the same composite construction will be used to bridge our matured confidence on MLDSA implementations and TNBT (TheNextBigThing) implementations. So no, I respectfully think there are grounds to object to your initial assumption and the conclusions you derived from it. Best regards, Nicola On Wed, Apr 22, 2026 at 22.53 Blumenthal, Uri - 0553 - MITLL <[email protected]> wrote: > There can be arguments about the life expectancy of hybrids - from zero to > CRQC appearance - but can be no objection to the point that once CRQC is > here, only pure PQ will make sense. > > Thus, arguing against pure PQ makes no sense in my opinion: you may be > able to delay long enough to avoid hybrids, but there’s no way you’d avoid > pure PQ. > — > Regards, > Uri > > Secure Resilient Systems and Technologies > MIT Lincoln Laboratory > > On Apr 22, 2026, at 13:25, Nicola Tuveri <[email protected]> wrote: > > > Hi Rich, thanks for your clarification, indeed my phrasing was not ideal. > I’ll take your comment as a chance to clarify my stance. Code point > assignment and deployment support are distinct considerations. In practice, > non-experimental production > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message came from outside the Laboratory. > > ZjQcmQRYFpfptBannerEnd > > Hi Rich, > > thanks for your clarification, indeed my phrasing was not ideal. I’ll take > your comment as a chance to clarify my stance. > > > Code point assignment and deployment support are distinct considerations. > In practice, non-experimental production deployments generally rely on both > assigned code points and a published standard. > > > Concerns about the proliferation of standards introducing support for > additional code points are not uncommon on this list. I note a similar > concern here in support of delaying this draft. > > > At present, the process risks creating the impression of a > “first-to-standard” outcome, where publication effectively determines the > direction of deployment before the trade-offs have been fully examined, > possibly even stalling the progress of other drafts. In particular, the > argument that introducing additional options increases complexity has been > raised repeatedly on this list, but it does not seem sufficient on its own > to guide decisions in a security area WG. It would be preferable to more > explicitly evaluate the security properties of hybrid and non-hybrid > approaches and reach a position that can inform what should-and should > not-be advanced to standard. > > Best regards, > > Nicola Tuveri > > > > On Wed, Apr 22, 2026 at 19.30 Salz, Rich <[email protected]> wrote: > >> >> - I have read the draft, but I do not support its publication at the >> moment. >> >> >> >> - My rationale is that this draft adds complexity by adding extra >> code points for pure mldsa. >> >> >> Code points are assigned when a stable reference is available, as you >> might recall from the long threads on the pure ML-KEM draft. So I don’t >> think your stated rationale makes sense. >> > _______________________________________________ > 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]
