> > > But that is all poor design, harmful complexity, and needlessly throwing > > away convention, all of which degrade security and interoperability.
> What cose-hpke-05 does today is to have the raw values to stuff into > HPKE in the message. What could be simpler? That's absolutely correct. As an COSE implementer, I (and Ilari) proposed a design as simple as possible, while adhering to existing COSE spec and conventions, but I'm really disappointed to hear it being referred to "all poor design, harmful complexity, and needlessly throwing away convention, all of which degrade security and interoperability." ... I feel like Orie may have confused the hpke_sender_info of cose-hpke-05 and the hkc included in my key expression draft, so I'd like to think he is criticizing due to a misunderstanding of the current draft. Anyway, I considered Orie's proposal to fully expand the HPKE ciphersuite information into the 'alg' field in my own way. Still, compared to the current drafts (cose-hpke-05 and ajitomi-cose-cose-key-jwk-hpke-kem), I can't find any advantages at all. I apologize for the length, but I've summarized my thoughts on Orie's proposal below. I look forward to hearing Orie's counterarguments. *1. Compliance with existing COSE/JOSE standards and conventions* Orie criticizes the cose-hpke-05 and my key representation proposal as deviating from the existing COSE specs, but his proposal is the one that clearly deviates from the existing standards and conventions. As I have already pointed out, the 'alg' value is defined within the range of the operation categories (sign/verify, encrypt/decrypt, sign/verify_mac, derive_key/bits) defined by 'key_ops'. There are no examples of 'alg' values that span multiple categories. From the perspective of end-to-end encryption, "key agreement" and "encryption" are separated, and the decision of the latter algorithm has been left to each application. Both cose-hpke-05 and my key expression proposal comply with this convention. "HPKE-v1-Base" is clearly for KEM use, and the operation used is 'derive_bits'. As John has already pointed out, COSE and JOSE are clearly NOT ciphersuite-oriented. It's clearly designed with cryptographic-agility-oriented, per key operation (key usage). It would be a stretch to argue that they are ciphersuites-oriented. I would like to emphasize first, putting aside the merits and demerits, that while Orie argues that we should adhere to the conventions of COSE/JOSE so far, his proposal deviates more from these conventions. *2. Compatibility with the design policy of other HPKE application standards* There are three (OHTTP, ODoH, ECH) that use HPKE's algorithm ID as is, just like cose-hpke-05. There is one (MLS) that assigns IDs to specific HPKE ciphersuites and uses them, just like Orie's proposal. At least, the design policy of cose-hpke-05 is more common. *3. Complexity and maintainability of implementation* I apologize for repeating the same point. Orie's proposal needs to implement an ID conversion process in the COSE library that is not originally necessary (the conversion process from COSE's 'alg' ID to HPKE's three values), and this conversion process may need to be extended in the future, which means continued maintenance. Also, the 'alg' value in the header serves as a switch for the extension process (COSE-HPKE). While cose-hpke-05 can switch with a single value, it's cumbersome to have to use a dynamic ID set that may potentially be extended in the future as a switch. The complexity of implementation can also degrade security and interoperability. *4. Complexity and maintainability of the specification* This is a point I always mention, but with Orie's proposal, in order to use a new KEM (post quantum KEM, etc.) added to the HPKE registry, a new COSE-HPKE draft must be standardized, a new value must be registered in the IANA COSE registry, and all COSE implementations must be updated With the current spec (cose-hpke-05), there is no need to expend such effort. Wouldn't you rather spend the saved time on developing comprehensive test vectors for COSE, instead of such meaningless effort? (I think this would be much more helpful for improving COSE's security and branding.) *5. Variety of supportable use cases* cose-hpke-05 is also clearly superior in this respect. It's not just that it can support all HPKE cipher suites. Even post-quantum KEMs to be added in the future are acceptable for the current draft. Including the entire HPKE ciphersuite in the 'alg' value means fixing the usable KDF and AEAD for one KEM key. Use cases where one KEM key provides service to various IoT devices that each support different AEADs would no longer be feasible. *6. Ease of cipher suite selection by application* This is probably the point where Orie wants to claim the most advantage. I think he prefers ciphersuites over cryptographic agility, but then how many cipher suites should we define in the COSE-HPKE spec? As a precedent, let's bring up the cipher suites carefully selected by experts for MLS. https://www.ietf.org/archive/id/draft-ietf-mls-protocol-20.html#section-17.1 I tried to express them in JWK/JOSE 'alg' values, but just enumerating them is exhausting due to the length of these names. It's likely to lead to typing mistakes or incorrect autocomplete, resulting in poor usability. - "HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM" - "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" - "HPKEv1-Base-DHKEM(P25519,HKDFSHA256)-HKDFSHA256-ChaCha20Poly1305" - "HPKEv1-Base-DHKEM(X448,HKDFSHA512)-HKDFSHA512-AES256GCM" - "HPKEv1-Base-DHKEM(P521,HKDFSHA512)-HKDFSHA512-AES256GCM" - "HPKEv1-Base-DHKEM(X448,HKDFSHA512)-HKDFSHA512-ChaCha20Poly1305" - "HPKEv1-Base-DHKEM(P384,HKDFSHA384)-HKDFSHA384-AES256GCM" Let me point out in advance that adding post-quantum KEMs or KEMs for compressed or compact points for NIST curves will further increase the variation, and there's no rational reason why COSE should limit this list to fewer numbers. Now, how much difference is there in the knowledge required for an application designer to choose one out of these seven options, compared to choosing one each from 5 KEMs, 3 KDFs, and 3 AEADs? As you can see from the list of values defined as JOSE 'alg' values above, the names are long and the similarities between each choice are high. To choose the desired one from this list, you need to understand HPKE to some extent. Ultimately, isn't this task almost the same as choosing one each from 5 KEMs, 3 KDFs, and 3 AEADs? Should we choose this policy, ignoring the demerits of No.1-5 above? Moreover, the visibility of the JWK 'alg' value is low, and it is not developer-friendly. Next, let's imagine a situation where an application developer has to specify a cipher suite. Is there a difference between the two examples below? AwesomeHPKEApp.new(suite="HPKEv1-Base-DHKEM(X25519,HKDFSHA256)-HKDFSHA256-AES128GCM") > AwesomeHPKEApp.new(suite={kem: DHKEM_X25519_HKDFSHA256(0x20), kdf: > HKDF_SHA256(0x01), aead: AES128GCM(0x01)}) The former still has to internally decompose the suite_id into kem_id, kdf_id, and aead_id. I preffer the latter. *Conclusion* As you can see from reading 1-6 above, I can't find any elements in Orie's proposal that I can support. I also have strong concerns about his proposal in terms of compatibility with existing implementations. I'm not denying the ciphersuite approach at all. As I've mentioned in another thread before, I am also a supporter and implementer of PASETO, which was born from the antithesis of cryptographic agility. I have also made a modest contribution to the spec by correcting errors in test vectors and specs. >From the perspective of someone who has seen both sides, COSE/JOSE is definitely a cryptographic-agility-oriented standard. I insist once again that it is quite dangerous to twist this into a ciphersuite, and build up a spec that deviates from convention. If you're going to adopt a ciphersuite approach, ideally you should limit it to one or two. Are you going to do this at the generic COSE-HPKE layer? I will say this over and over again, but this is something that should be done at the application layer. Not in COSE-HPKE, but for example, in the higher layer of "Firmware Encryption with SUIT Manifests". In the utility library of "Firmware Encryption with SUIT Manifests", you can limit it to a specific HPKE ciphersuite, so that users don't have to be aware of HPKE. This can be built on top of the current COSE-HPKE spec. Finally, about the article that Orie seems to be influenced by: https://www.blockchaincommons.com/musings/musings-agility/ This article cites TLS1.3 as a good example of a modern approach that limits cipher suites. This characteristic of TLS1.3 applies to HPKE as well. The KEM/KDF/AEAD algorithms of HPKE are already carefully selected. (The variety of cipher algorithm options in TLS1.3 is even greater than that in HPKE) There should be no problem with showing the raw choices of each step in HPKE to the higher levels. The Gordian Envelope discussed in this article and the original argument both suggest that there should be only one cipher suite. Do you want to reduce the cipher suites of COSE-HPKE to just one? (That would be impossible). Or would you define an incomplete cipher suite set, like MLS? I see no essential merit in doing so. Best, Daisuke 2023年6月2日(金) 15:41 Ilari Liusvaara <[email protected]>: > On Thu, Jun 01, 2023 at 10:22:55AM -0500, Orie Steele wrote: > > I've said this several times before, apologies to the list. > > > > "alg" has always represented "suites". > > > > ES256 is sha256 with ecdsa on secp256r1. > > In JOSE, not in COSE. > > > > ES256K is sha256 with ecdsa on secp256k1. > > Yeah, that one is odd in COSE. > > > > ECDH-ES+A128KW on either of those keys indicates ECDH with a specific > > KDF that uses sha256 and key wrapping. > > However, that is always used with bulk encryption algorithm, with no > way to restrict that choice. > > > > AFAIK, the first occurrence of "alg" comes from > > https://www.rfc-editor.org/rfc/rfc7517#section-4.4 > > > > >From the beginning, these "alg" values encapsulated complexity for > > developers, most commonly by setting the hash function used before ECDSA, > > or the kdf used after ECDH. > > The way ECDH-ES works is that key determines the group used, an the > ECDH-ES "alg" specifies the kdf. Then there may be integrated key wrap > step. > > In JWE, this key wrap step is sometimes required and sometimes > forbidden. In COSE, integrated key wrap is size optimization, since > nested recipients allow using separate key wrap. > > > > Note that COSE-HPKE use "enc" differently, and instead of *identifying an > > aead algorithm*, it represents the output of the kem, in the case of dh > > kems, that is a *public key as opaque bytes.* > > COSE uses "enc" differently from JWE. Roughly speaking, "enc" maps to > "alg" in layer zero, and if there is "alg", it maps to "alg" in layer > one. > > > > Let's look at a simple example: > > > > Your closest friend only supports > > "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM". > > > > You start with the recipient public key, if it contains alg, you use it, > if > > it does not, you somehow learn that the recipient supports the above > suite, > > maybe ask them if they have an iPhone. > > This is what I think "hkc" and "cbc" are for. > > "hkc":[[32],[1],[1]], > "cbc":[1] > > Advertises support for > "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" > plus AES128GCM for bulk encryption. > > > > You prepare their message, as you normally would with HPKE. > > > > You put the message in an envelope that makes it easy for the recipient > to > > safely handle it. > > > > The minimum information needed for the envelope is: > > > > [ kem_id, kdf_id, aead_id ] ... all of these can be omitted from an > > envelope IF they are discoverable from a key representation (such as JWK > or > > COSE Key) > > I think that is unlikely to be the case. > > > > If you wanted to align with JOSE, you would just do [ kem_id, kdf_id ] > > and send the aead, in the envelope. > > > > https://www.rfc-editor.org/rfc/rfc7516.html#appendix-A.1.1 > > This is not JOSE. > > For JOSE, it would be JOSE-HPKE, which must be more complicated than > COSE-HPKE, because COSE is just more flexible than JOSE. > > For example, while COSE-HPKE can do with only one "alg", JOSE-HPKE can > not: There must be at least two "alg"s (this is actually related to the > required/forbidden key wrap mentioned earlier). > > And BTW, the latter impiles that using "alg" to restrict keys to HPKE > does not work all too well. Fortunately one could define "use":"HPKE". > Which is also useful for COSE-HPKE, because no JOSE "alg" value even > exists. > > > > Excluding aead from the key agreement algorithm does make some sense, but > > then you end up with what JOSE has, where you need to learn the aead that > > is supported some other way... worth noting the current -05 draft > combines > > "aead with key agreement", by telling you certain "alg" values are > > dependent on certain "hkc" values. > > This is also how COSE works right now, except "enc" is called "alg" on > layer zero. > > And the current -05 draft does not mention "hkc" at all. > > And this is the reason for "cbc" ("jbc" for JOSE): To advertise the bulk > encryption. > > > > To date, JOSE & COSE keys have supported "alg" values that ONLY cover > > "key agreement" or "encryption". > > Well, for asymmetric JWE/Cose_Encrypt. There are signature, MAC and > symmetric encryption keys as well. > > > > But you can imagine wanting to build an API that took a JOSE or > > COSE Key for "Key Agreement", and produced a Key for "Encryption". > > > > If the first key contained an aead in its "algorithm" the second key's > > algorithm would use that same aead. > > > > "alg" is always optional, but it can be used to create easier to > > understand, and safer to use APIs. > > > > JOSE / COSE today: > > > > { > > "kty": "EC", > > "crv": "P-256", > > "x": "z0JJ6bYOwvIXL0RlE-0iOUUAQ1KWz2YpPvVLXY2ah-4", > > "y": "eXLXYE-rH71FtvWihfOclbcSFNMRMGGDej7X8tc5_s8", > > "alg": "ECDH-ES+A128KW" > > } > > > > ==> { > > "kty":"oct", > > "k":"GawgguFyGrWKav7AX4VKUg", > > "alg": "A128GCM", // how do you know if the recipient above supports > > this?... you learned without looking at their key. > > } > > This is exactly what "jbc"/"cbc" are meant for: > > "jbc":"A128GCM" (JOSE) > "cbc":1 (COSE) > > > > JOSE / COSE tomorrow: > > > > { > > "kty": "EC", > > "crv": "P-256", > > "x": "z0JJ6bYOwvIXL0RlE-0iOUUAQ1KWz2YpPvVLXY2ah-4", > > "y": "eXLXYE-rH71FtvWihfOclbcSFNMRMGGDej7X8tc5_s8", > > "alg": "ECDH-ES+A128KW (*+A128GCM) *" ~~~= > > "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" > > } > > > > ==> { > > "kty":"oct", > > "k":"GawgguFyGrWKav7AX4VKUg", > > "alg": "A128GCM", // now you know where this came from... you learned > it > > when you learned their key agreement key. > > } > > If key has "alg": "ECDH-ES+A128KW", then JOSE/COSE specs are very clear > that it MUST NOT be used with HPKE. > > > > > How do you learn the aead the recipient supports?... It doesn't really > > matter. > > Currently, JOSE/COSE just punt that to the application. > > The HPKE key format draft contains first attempts at advertising what > the recipient supports. However, the mechanisms presented are not > sufficient for the purpose. > > > > cbor can easily handle structuring of aead, "enc" or "ciphertext", see > > > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-05#section-5.1 > > > > The point is the "alg" value either helps you learn or it doesn't, and > > since "alg" is always optional, you can't rely on it 100% of the time. > > That is not sufficient to discover the bulk AEAD. One can not assume > that every HPKE AEAD is supported as COSE AEAD, or vice versa. > > The prototype code I wrote works this way: It supports COSE AEAD 2, > which can not be used in HPKE. And it allows new HPKE AEAD to appear at > any time, but not COSE AEAD. > > > > But you should be able to rely on "alg" behaving how it has in the > > past, and providing the same safety features it has in the past. > > > > At a minimum this means communicating the kem_id and kdf_id. > > Historically, the equivalent of kem_id is pulled from the key. > > > > We can of course invent a "new way" of doing this.... where "alg" and > > "hkc" work together to accomplish what a single "integer" or a > > "string" could have, or what 2 strings in JOSE do today, or what an > > array does in cose-hpke-05 today. > > "hkc" is clearly not intended to be used that way. > > > > But that is all poor design, harmful complexity, and needlessly throwing > > away convention, all of which degrade security and interoperability. > > What cose-hpke-05 does today is to have the raw values to stuff into > HPKE in the message. What could be simpler? > > And that is in fact exactly what the protoype code I wrote does. > > $ cose-hpke-keygen --supported > KEM supported: 0010[p256] 0011[p384] 0012[p521] 0020[x25519] 0021[x448] > 0030 > KDF supported: 0001 0002 0003 > AEAD supported: 0001[aes128gcm] 0002[aes256gcm] 0003[chacha20poly1305] > Bulk ciphers supported: 1[aes128gcm] 2[aes192gcm] 3[aes256gcm] > 24[chacha20poly1305] > > The names displayed are purely UI concern. Note how KDFs have no name, > and how KEM 0030 (post-quantum!) is listed as supported despite having no > name (yes, it actually works). > > > > I'm not saying I know for sure what the "value" side of "alg" should > > be for HPKE COSE Keys or Envelopes, but I know we don't need new > > parameters for either case, we just need to pick "alg" values that > > people want to use and register them. > > Having implementation look up values to stuff into HPKE from table is > certainly not simpler. Especially so if someone gets some "smart" idea > and makes something be its own special snowflake. > > > > Arguing that we must register everything that is in the HPKE registry, is > > similar to arguing that we must register every curve ever invented by > > cryptographers in the JOSE / COSE registry, it would be bad for > developers > > to suggest they should support every option cryptographers have > registered > > (HPKE is a CFRG established registry). > > There is no nice way to refer to arbitrary curve ever invented by > cryptographers, while there is a nice way to refer to HPKE algorithms. > > > > Similarly, arguing we should use a CFRG registry and support 100% of it > for > > COSE, without any expert review *applied to the cose use case*, is also a > > bad idea. > > What is "the cose use case"? COSE is used across variety of applications on > systems ranging from quite constrained to very high-powered. > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
