Alicja Kario writes: > Unfortunately, I don't think we have a rough consensus in > LAMPS on how hybrid signatures should be done just yet, and without that, > we can't standardise it for TLS.
It's trivial to build a signature system where each signature has, internally, an Ed25519 signature followed by whichever PQ signature, of course with the verifier requiring both signatures to pass. Nothing is stopping TLS from going ahead with this straightforward form of ECC+PQ for signatures, analogously to draft-ietf-tls-hybrid-design for KEMs. This eliminates the delay issue. Compared to just PQ in TLS, focusing on ECC+PQ in TLS will do a better job of encouraging upgrades. There are other combiner options that hash more inputs in the hope of protecting more protocols. A unified combiner that hashes all available inputs, as in Chempat for KEMs or https://mailarchive.ietf.org/arch/msg/cfrg/LdvasJBpseekZtQkQF1nuPPDH_s/ for signatures, turns out to have very little cost in context (as an analogy, remember how the world didn't come to an end when TLS moved to hashing the transcript?), but there are still other combiner proposals that skimp on hash calls. So, sure, waiting for those discussions to settle would produce a delay---but I don't see how that's an argument for doing PQ instead of ECC+PQ. ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
