[TLS] Re: What about AuthKEM? / Online-Offline signature split

[Loganaden Velvindron <[e-mail]>]

On Mon, 06 Apr 2026, 03:34 Daniel Apon, <[e-mail]> 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=
> [e-mail]> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>