Hi Peter, The KEM used for authentication indeed needs to be IND-CCA secure, but so does the KEM for ephemeral key exchange (IND-1CCA, at least). The TLS key schedule should ensure that this all goes correctly, if I recall the discussion on the concatenation of the secrets and is-HKDF-a-dual-PRF discussion.
But AuthKEM currently tries to build on HPKE, and I think the HPKE draft intends to give IND-CCA security. Cheers, Thom > Op 6 nov 2023, om 20:51 heeft Peter C <Peter.C=40ncsc.gov...@dmarc.ietf.org> > het volgende geschreven: > > 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 <tls-boun...@ietf.org> On Behalf Of Peter C > Sent: Monday, November 6, 2023 4:08 PM > To: tls@ietf.org > 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 <tls-boun...@ietf.org> On Behalf Of Thom Wiggers > Sent: Friday, August 18, 2023 10:41 AM > To: <tls@ietf.org> <tls@ietf.org> > 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 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
