Hi Ilari, Op di 7 nov 2023 om 08:34 schreef Ilari Liusvaara <ilariliusva...@welho.com >:
> On Tue, Nov 07, 2023 at 08:00:57AM +0100, Thom Wiggers wrote: > > 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. > > I thought key exchange only needs absolute minimum to avoid trivial > breakage (one-wayness)? > Surprisingly, it turns out that IND-CPA is not exactly sufficient. The TLS 1.3 proof by Dowling et al. [1] established that you need PRF-ODH for the ephemeral key exchange. Very similarly, in TLS 1.3 and KEMTLS, in the indistinguishability experiment we need to be able to answer a single decapsulation oracle query to properly answer the adversary's queries: this is due to the fact that the server immediately uses the encapsulated/DH shared secret to encrypt handshake messages. Hüguenin-Dumittan and Vaudenay later improved this analysis [2] and showed that for TLS 1.3, the CDH assumption and some additional construction can be used to avoid the PRF-ODH assumption. However, l think this series of papers shows something else: IND-CPA has a ton of footguns and you're better off just assuming you need IND-CCA security for all your primitives. > > But AuthKEM currently tries to build on HPKE, and I think the HPKE > > draft intends to give IND-CCA security. > > >From reading HPKE RFC, it seems weird. > > I thought that HPKE intends to guarantee IND-CCA2, however, I can > not find a requirement for KEM part to be IND-CCA2 secure (all the > other parts yes). And if the KEM is not IND-CCA2, the whole HPKE > will not be either. > > We should currently be using full HPKE, we're just wrapping it in some KEM operations. But this is something I haven't looked at too deeply either. Cheers, Thom [1]: https://eprint.iacr.org/2015/914 [2]: https://eprint.iacr.org/2021/844 > > > > > -Ilari > > _______________________________________________ > 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
