[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Andrey Jivsov <[e-mail]>]

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 <
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>