On Mon, Mar 02, 2026 at 01:46:20PM -0800, Benjamin Kaduk wrote:
> On Fri, Feb 27, 2026 at 08:35:26PM -0500, Deirdre Connolly wrote:
> > This Message Is From an External Sender
> > This message came from outside your organization.
> >
> > Trying to pull this up to its own subject
> >
> > Here's a stab at more text around hybrid vs not-hybrid in Security
> > Considerations:
> > # Security Considerations {#security-considerations}
> >
> > This document defines standalone ML-KEM key establishment for TLS 1.3.
> > Hybrid key establishment mechanisms, which support combining a
> > post-quantum
> > algorithm with a traditional algorithm such as ECDH, are supported
> > generically via {{HYBRID}} with some concrete definitions in
> > {{ECDHE-MLKEM}}. Hybrid mechanisms provide security as long as at least
> > one
> > of the component algorithms remains unbroken, such as combining
> > quantum-resistant and traditional cryptographic assumptions. Standalone
> > ML-KEM relies on lattice-based and hash function cryptographic
> > assumptions
> > -for its security.
> > +for its security. Proponents of hybrid PQ/T key establishment generally
> > +consider it a conservative approach to deployment of newer post-quantum
> > +schemes alongside older traditional schemes, retaining at least the
> > security
> > +currently offered by traditional algorithms.
>
> I think this is perhaps missing the point of my concern ... while I do think
> that we should have more text in the security considerations about the
> perception of relative risk between hybrid and non-hybrid PQ usage my
> overarching concern is that the TLS WG needs to have a consistent overall
> position for documents being published ~contemporaneously. Which is to say, I
> think we need to acknowledge that in {{HYBRID}} we are giving guidance that,
> generally speaking, hybrids are preferred at present, and indicate why the
> mechanisms in this document diverge from the general guidance, so as to place
> the two documents in a consistent posture overall (presumably, by carving out
> a
> specific subset of cases in which this document applies more specifically than
> {{HYBRID}} does).
Maybe something along lines of:
Since confidence in pre-quantum security of ML-KEM is much lower than
that of ECC, one SHOULD use {{HYBRID}} cipher suites instead of these
ones, unless:
- Following security profile standard, which can be blamed if things go
pear-shaped.
- CRQC has rendered traditional cryptography moot.
- One is in constrained environment, nevertheless needing post-quantum
protection, where hybrids would have not acceptable cost.
The first one is to cover things like CNSA2, the second one is to cover
things like ANSSI phase 3, and the third all manner of obscure IoT
garbage (where someone breaking ML-KEM-512 is far from the worst
security risk). And "much lower confidence" does not mean "low
confidence".
-Ilari
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
