> On Jun 1, 2023, at 4:52 AM, Ilari Liusvaara <[email protected]> wrote: > > On Wed, May 31, 2023 at 12:15:14PM -0400, Christopher Wood wrote: >> The convention established by RFC8152 and updated in RFC9052 says the >> following about the "alg" header parameter: >> >> alg: This parameter is used to restrict the algorithm that is used >> with the key. If this parameter is present in the key structure, >> the application MUST verify that this algorithm matches the >> algorithm for which the key is being used. If the algorithms do not >> match, then this key object MUST NOT be used to perform the >> cryptographic operation. Note that the same key can be in a >> different key structure with a different or no algorithm specified; >> however, this is considered to be a poor security practice. >> >> My interpretation of this is that "alg" fully specifies the algorithm >> that is to be used for the object. For HPKE, the algorithm consists >> of the mode and ciphersuite parameters (KEM, KDF, and AEAD). On that >> basis, Orie's suggestion to use a single identifier or label that maps >> to an HPKE mode and ciphersuite seems best. It also matches the very >> high level abstraction that alg seems to target, being a very generic >> identifier for a "security thing." > > This is not correct. > > "alg" is not "security thing". It is "security component" that may be > composed (COSE itself allows any number, but currently the highest > number that makes sense is stacking 3). > > The way HPKE-like operation is done in existing COSE is by having a > component that performs bulk encryption be keyed by another component > that performs ECDH key agreement and outputs a key. > > That does not support multiple recipients. How to do that? By inserting > a key-wrapping component in the middle (or if allowed, using combined > ECDH+key-wrap to save space) and putting multiple in parallel!
Thanks for that additional context. I can appreciate that this is how HPKE-like things are done today, but I don’t think it needs to be done that way moving forward. We have HPKE, a construction for public key encryption of arbitrary plaintext. Can’t we just use it as such? > > The role of "alg" specified by the key in above examples is analogous to > KDF in HPKE (the role analogous to KEM is played by "crv" of the key). > > And the role analogous to AEAD is played by another "alg" there is no > way to restrict. > > > As side note, JWE has similar "alg" parameter, of which there can be > only one (so restricting works as expected). However, it also has "enc" > parameter, that can not be restricted. > > >> Beyond matters of consistency and abstraction alignment, I'll note >> that splitting up algorithm "negotiation" across parameters runs >> counter to the trend I've seen in higher-level security protocols >> lately, which is roughly "versions define ciphersuite/algorithm >> parameters." This lets implementations check precisely one thing, >> a version, label, or, in this case, the "alg" parameter, and determine >> how to process the rest. It does not introduce additional processing >> complexity. (I understand that the alternative proposal with the "hkc" >> parameters may not seem overly difficult, but it does effectively >> break from the mold of '"alg" fully defines the algorithm'.) > > Out of the frying pan into the fire. > > >> As a final note, the contents of the registry do matter. I consider >> HPKE to be a fairly low-level primitive, whereas I (perhaps naively) >> view COSE as a higher-level application protocol. We have the >> expertise to be opinionated about what goes into that registry for >> applications to use, and we should exercise that opinion to provide >> folks with a very limited set of options, ideally target precisely >> one. The "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" >> label seems like a perfectly fine candidate for that. > > With the HPKE registry as of 2023-05-18, I count 14 already. 12 of > those have equivalents composed of existing components. > > And that is vulnerable to combinatorial blowup. E.g., adding CP-* > and AEGIS increases that to 33. > > The two present ones with no equivalents are: > > - HPKEv1-Base-X25519Kyber768Draft00-HKDFSHA256-AES256GCM > - HPKEv1-Base-X25519Kyber768Draft00-HKDFSHA256-ChaCha20Poly1305 > > (Both are post-quantum.) If the point here is that the number of entries will grow combinatorially, then yes, I agree, but that assumes we’ll be adding lots of things to the registry. But as I suggested, I don’t think we should be doing that. I think we should just pick some sensible, widely supported defaults. Applications and implementations don’t seem to need the flexibility afforded by the alternate proposals (as I understand them). Best, Chris _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
