Hi Ilari, The meeting minutes only capture some of the discussion. The recording is here: https://www.youtube.com/watch?v=82Yso4ls54k (HPKE starts roughly 19mins into the session)
I think the fear about the combinatorial explosion is unjustified because the number of algorithms being practically used has been pretty small in the past, even in TLS. The beauty about standardizing combinations of algorithms is that standardization experts combine the combinations that make sense rather than allowing all possible variants to be negotiated. In essence, that's what you are suggesting below as well with the KEM and KDF combination. But let's ignore this for a moment and look at the specific proposal. There is nothing to do for the AEAD algorithm since we can use the values in the "COSE Algorithms" registry and put the value into the alg parameter. That's good. Registering the KEM together with the KDF in the COSE Elliptic Curve registry to be used in the crv (curve) parameter could look like as follows. Here is the current registry content: Name Value Key Type Description P-256 1 EC2 NIST P-256 also known as secp256r1 P-384 2 EC2 NIST P-384 also known as secp384r1 P-521 3 EC2 NIST P-521 also known as secp521r1 X25519 4 OKP X25519 for use w/ ECDH only X448 5 OKP X448 for use w/ ECDH only Ed25519 6 OKP Ed25519 for use w/ EdDSA only Ed448 7 OKP Ed448 for use w/ EdDSA only secp256k1 8 EC2 SECG secp256k1 curve We would be adding something like DHKEM(P-256, HKDF-SHA256) with HKDF-SHA256 DHKEM(P-256, HKDF-SHA256) with HKDF-SHA512 DHKEM(P-384, HKDF-SHA384) with HKDF- SHA384 DHKEM(P-384, HKDF-SHA384) with HKDF-SHA512 DHKEM(P-521, HKDF-SHA512) with HKDF-SHA512 DHKEM(X25519, HKDF-SHA256) with HKDF-SHA256 DHKEM(X448, HKDF-SHA512) with HKDF-SHA512 etc. Then, we have to figure out what key type to use. This is, however, a topic of another email. We might have to introduce another column into the registry indicating that these elliptic curve algorithms are not for generic use. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Tuesday, April 26, 2022 9:45 AM To: [email protected] Subject: Re: [COSE] HPKE Algorithms 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
