" 1. Should we .. forbid "real" signature algorithms ..? "
In my opinion, no. KEMTLS is fantastic, but KEMTLS doesn't seem like a reason on its own to *forbid* digital signatures (beyond certificates on long-term KEM PKs, of course, where they're required for KEMTLS). " 2. .. FN-DSA .." Right... -- show me your copy of the FIPS 206 draft first :) I've had dating relationships I'd consider "long term" and "serious" that have lasted less time than the 4+ year window from 2022 (Falcon selected) to now (still no FN-DSA draft available). !remindme 1 year " 3. Are experimental post-quantum handshakes ready to go into TLS without the seatbelt? " In my opinion, no. Protocol standards should not get ahead of primitive standards. Kind regards, --Daniel On Thu, Apr 2, 2026 at 6:29 PM Joshua <joshua= [email protected]> wrote: > While the horticulturalists over at PLANTS has been working on some really > cool stuff regarding tree signatures, > I wanted to revive an idea that’s been toyed with in the past: what if we > move away from signature suites for > handshaking, and move to exclusively AuthKEM-based handshakes? > > AuthKEM has some advantages over “normal” Signatures. Chiefly, we are > using signature algorithms designed to be > provable to anyone, anywhere, and using them in cases where only one > person will ever need to verify them. This > has real impacts on the attack surface; non-constant-time signature > generation can lead to key recovery attacks, > implementation errors can lead to key recovery attacks, implementations > can potentially be tricked into signing > maliciously crafted plaintexts, etc. On the contrary, AuthKEM "proofs" are > very localized; an AuthKEM "signature" > can't easily be passed on and verified by third parties. > > Overall, 3DH-esque authentication schemes are simpler, faster, and smaller > than their comparative signature-based > authentication schemes. (Kyber512 is used to illustrate, but I do not > recommend it's adoption) > - Dilithium2 requires 3,700 bytes to communicate a pk/sig pair, whereas > AuthKEM-Kyber512 requires less than half > at 1,500 bytes; > - Dilithium2 requires about 300kilocycles to generate a proof, whereas > decapsulating a AuthKEM-Kyber512 secret > can go as low as ~30kilocycles; > - Dilithium2 requires both a correct constant-time PQ KEM and a correct > constant-time PQ signature algorithm, > whereas AuthKEM-Kyber requires only a correct constant-time PQ KEM. > > For example, consider the issues with Ed25519, generally considered one of > the more bulletproof signature schemes > available/widely deployed today: > - Despite having constant-time point addition, a constant-time scalarmult > ladder is required to avoid side-channels; > - A single bit-flip during signing exposes the private key immediately, > and implementation errors compound this problem; > - This also occurs when signing with a mismatched private/public keypair > (which some implementations used to allow) > > These benefits* have, of course, already been enumerated in the AuthKEM > I-D, available here: > https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ > > * Debatably “benefits” based on your use case, hence why I’m writing > this email. > > That's not to say that lattice-based signature schemes are a bad idea; on > the contrary, I think saying "we should > only use AuthKEM for authentication" frees us to consider more optimal > signature schemes for each step in the chain. > For example, FN-DSA is a perfect fit for chain signatures (especially > since we don't need to worry about side-channel > resistance), and more exotic algorithms like SQIsign might even enter the > fray. And of course, we have the eternally-cool > merkle trees for root certificates. We won't need to worry about, eg, > SQIsign being (mis)used for handshakes, and a side- > channel key recovery attack breaking a significant portion of the > encrypted internet. > > So, I want to pose a few questions to the mailing list: > > 1. Should we only consider the AuthKEM family of handshake algorithms for > use within PQ CertificateVerify messages? > (In other words, forbid "real" signature algorithms for use within the > handshake process) > > 2. Should we segment handshake schemes into different use cases based on > their side channel resistance? > (eg, allowing FN-DSA for offline signatures, but forbidding them for > online/handshake signatures) > > 3. Are experimental post-quantum handshakes ready to go into TLS without > the seatbelt? > Personally, I’d say yes: if an attack is found, > loss-of-confidentiality is limited to active attacks, and > clients can be updated to reject the insecure algorithm, which allows > us to contain the blast radius. > (This is in contrast to eg. Standalone ML-KEM, where compromise means > years of retroactive confidentiality loss) > > > Best, > Joshua Nabors > > > P.S. This has nothing to do with the dilithium2 draft published recently; > if it means anything, I support its publication. > > P.P.S. I would like to add “Futureproofing (the) Internet’s Secure > Handshaking” (FISH) to the backronyms bucket. > “Marine Biologists” has a nice ring to it > :^)_______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
