On Mon, Apr 25, 2022 at 04:23:37PM +0000, Hannes Tschofenig wrote: > > There are two basic approaches for algorithm indication, namely > crypto suites vs. ala carte. Currently, the draft contains the ala > carte approach. It was my understanding that the group asked me to > do this at the interim meeting in January. I might have > misunderstood.
I took a look at the minutes of the January interim. What I see it requesting is minimum-effort way of adding new HPKE algorithms to COSE. I think ala carte approach is not good for that: There is combinatorial explosion in registrations. And trying to be "smart" here probably will wind up with missing combinations causing trouble in implementations. For a nasty example about where this can lead to, see TLS 1.0-1.2 ciphersuites. And there are TLS server implementations that can fail to negotiate ciphersuite if client sends some strange combination, even if that combination contains an acceptable ciphersuite. > So, we first have to decide what approach we want to use. There is no > wrong approach here - it is just a preference. > > Let's assume we don't want the ala carte approach currently in draft > and want to individually indicate > > * KEM > * KDF > * AEAD > (Values are registered at https://www.iana.org/assignments/hpke/hpke.xhtml) > > The question then arises where to put those values. > > You are suggesting to go the "middle"-way by combining the KEM and the > KDF and to put them into the crv (curve) parameter and to register the > values into the COSE Elliptic Curve registry. The first reason I combined KEM and KDF is that usually there is only one KDF for each KEM that does not wind up causing unpleasant things in implemenation. E.g. if you combine KEM 16 and KDF 3, you need both SHA-256 and SHA-512, because KEM 16 internally uses SHA-256, and KDF 3 is based on SHA-512. However, this breaks down an bit if, e.g., HPKE adds Kyber KEMs. The issue is that Kyber internally uses SHA-3, but HPKE has no KDFs that use SHA-3. So one would wind up needing both SHA-3 and SHA-2. Perhaps HPKE should add KDF based on SHA-3, so when it adds a post- quantum KEM (all the leading 3 are using SHA-3 internally), one can avoid having to support multiple hashes. And second reason I did combine them is that using multiple KDFs with the same key is not cryptographically kosher: The keys raw KEM outputs are independent of KDF, so the same key can end up being uded with multiple different KDFs. Whereas neither reason appiles to coupling KEM and AEAD: There might be multiple valid candidates (e.g., one might want to use all three AEADs with x25519), and there are no cryptographical issues with using many AEADs with one key: The key output from KDF is dependent of AEAD used, so the same key can not be used with multiple AEADs. And putting the KEM used into message would require implementation to perform an extra check that the KEM specified in message matches with the key used. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
