With due respect to other opinions, I don't find these concerns below as significant.
- The classical crypto, e.g. ECDH, will need to stay around for some time, and that means that classical crypto code must remain correct. - Test vectors should catch regressions during maintenance - When QC becomes practical, there is no security need to disable ECDH. If the code can be updated, code can be optimized to use fixed private keys (e.g. equivalent to 1 or 2) -- it's just "encoding" at that point. - The private key should be viewed as one key that includes the ECDH and ML-KEM keys. - Not sure why PKI is mentioned, but I think that signing certificates should take the approach of a single algorithm corresponding to ML-DSA+ECDSA (or ML-DSA+EdDSA). Functionally, this will be similar to a pure ML-DSA certificate chain. If you meant by "parallel" that a post-quantum certificate chain needs to be set up in addition to the classical certificate chain, that's eventually inevitable. If we consider the world where composite certificate chains must be supported, then a pure ML-DSA chain, likewise, adds complexity and confusion in that it needs to be supported as a yet another parallel chain. The major problem here is that in some cases one must pick up a single algorithm, which cannot be negotiated or even configured. On Thu, Apr 17, 2025 at 2:17 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > I consider risks associated with hybrids, so my deployment will not use > them. > > > > Care to share? Perhaps you know something that many others don’t. > > > > I know that (purely) cryptographically “as strong or stronger” is not the > end. Which many others don’t seem to take into account, or even care about. > > > > There’s maintenance of the code for both parts of the KEM and ensuring > they’re properly integrated, maintenance of parallel PKI structures, need > to allocate the costs for two moves [1] instead of one which already makes > some users argue (which can be a royal pain in a large deployment), likely > many other things I’m too lazy to concentrate on now (besides, there’s that > feeling that I don’t need to convince “my” clientele at all, and there’s > little chance to convince this audience anyway, which dampens the eagerness > to strive). > > > > In short, all those factors of actually running a *large* conglomerate of > organizations… > > > > > > [1] One move – to the PQ (in whatever form), then – once people (even > those now-dissenting here) decide that enough decades have passed, and we > can consider Lattice-based as reliable as ECC (apparently, two decades of > study is not enough – would three suffice? Four? Five? Would we still want > hybrids even after CRQC appear?) – another move to dump the Classic part. > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
