Re: [TLS] Updated AuthKEM drafts

[Peter C <[e-mail]>]

Sorry, the hybrid TLS draft I referenced should have been draft-tls-westerbaan-xyber768d00.  I do realise they are different drafts with slightly different KEMs, I just can't copy and paste properly!

Peter

From: TLS <[e-mail]> On Behalf Of Peter C
Sent: Monday, November 6, 2023 4:08 PM
To: [e-mail]
Subject: Re: [TLS] Updated AuthKEM drafts

Thom,

If I'm understanding things correctly, the proof of multi-stage security for AuthKEM requires that the KEM used for authentication is IND-CCA2 secure.

Unfortunately, kem_x25519kyber768 from draft-westerbaan-cfrg-hpke-xyber768d00 is not IND-CCA2 secure.  It simply concatenates the shared secrets so is straightforward to distinguish given a decapsulation oracle - modify the first component ciphertext and check whether the second half of the concatenated shared secret stays the same.  It's possible that the TLS key schedule means it might still be fine to use, maybe - this is the argument in draft-westerbaan-cfrg-hpke-xyber768d00 for the ephemeral KEM - but I don't think this is covered by the existing KEMTLS security analysis and it's not clear to me what happens if one of the component algorithms is broken.

An alternative would be to use a hybrid KEM construction along the lines of draft-ounsworth-cfrg-kem-combiners where you are guaranteed to get IND-CCA2 security.  I realise this moves away from directly reusing the ephemeral KEM for authentication, but they have slightly different security requirements and it's somewhat analogous to using dhkem_x25519_sha256 for authentication instead of x25519 by itself.

Best,

Peter

From: TLS <[e-mail]> On Behalf Of Thom Wiggers
Sent: Friday, August 18, 2023 10:41 AM
To: <[e-mail]> <[e-mail]>
Subject: [TLS] Updated AuthKEM drafts

Hi all,

I have just updated the AuthKEM draft and published a new one. TL;DR:

AuthKEM is a proposal that replaces signature-based handshake authentication in TLS by an additional KEM key exchange (putting KEM public keys in endpoint certificates).

In this update we:
* Split off the AuthKEM cached/pre-shared KEM public key PSK-style mechanism into a separate draft
* Added a new section that explains the sizes of different TLS and AuthKEM handshakes
* Also explain how AuthKEM makes it cheaper to use Falcon for offline signatures
* Expanded on related work and how this mechanism relates to compression proposals

In our view, AuthKEM can be especially helpful for embedded and IoT devices, as using KEMs instead of signatures can be much cheaper in terms of bandwidth, computation, and (when mutually authenticating) code size. For example, in [Samandari23], a KEM-authentication approach was investigated for MQTT and resulted in much faster messaging. But also for the WebPKI, AuthKEM can reduce handshake sizes further when combined with e.g. Merkle Tree Certs or Abridged Certificate Compression.

The KEM-based PSK-style mechanism can in my mind be a robust contribution to the discussion on the update for RFC7924 versus session tickets: storing KEM public keys can be much easier than symmetric session tickets or other symmetric secrets in terms of key management, but also in terms of not having to protect the secrets.

The source repository for both drafts lives at https://github.com/kemtls/draft-celi-wiggers-tls-authkem. I am already aware that I forgot to update the abstract for authkem-psk, so that is one of the new issues tracked there.

There are lots of things still open for discussion, and these are marked in the draft. I am also sure the presentation or any details can be much improved, and welcome any and all contributions to either.

Cheers,

Also on behalf of my co-authors,

Thom
PQShield

[Samandari23] https://www.mdpi.com/2624-800X/3/3/21/html