On Mon, 06 Apr 2026, 03:34 Daniel Apon, <[email protected]> wrote:
> " 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. > Why shouldn't protocol standards get experienced with pre standardized primitive standards? Doesn't that help to get primitive standards moving forward? > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
