On Tue, Mar 03, 2026 at 10:51:27AM +0200, Ilari Liusvaara wrote:
> !-------------------------------------------------------------------|
> This Message Is From an External Sender
> This message came from outside your organization.
> |-------------------------------------------------------------------!
>
> 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".
Yeah, something along those lines looks promising (John had a good point in the
follow-up).
I am willing to put some time into drafting more polished text if we get some
more buy-in.
Thanks for helping distill out the key facets here.
-Ben
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
