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! 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.) -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
