On Thu, Apr 13, 2023 at 12:12:17PM -0700, Laurence Lundblade wrote: > > > On Apr 12, 2023, at 4:06 PM, Orie Steele <[email protected]> wrote: > > > > > > Is there really a burning desire to use the same key with multiple > > kdf and aeads? > > > > Which application use cases really need this feature? > > We write security considerations to say that is bad, but I don’t > think we get to categorically exclude this from all COSE use.
There is also consideration on what excluding this would do to specification complexity. I think the impact would be quite negative. > > Applications need to define the set of information that is to be > > considered to be part of a context when omitting algorithm > > identifiers. At a minimum, this would be the key identifier > > (if needed), the key, the algorithm, and the COSE structure it is > > used with. Applications should restrict the use of a single key to > > a single algorithm. As noted for some of the algorithms in > > [RFC9053], the use of the same key in different, related algorithms > > can lead to leakage of information about the key, leakage about the > > data, or the ability to perform forgeries. > > It is a should, not a must. HPKE is designed not to interact badly with itself even when mixing and matching algorithms. And the internal structure looks like it would not be likely to interact badly with other algorithms (even if this is in general unsound). > > Is it still considered a single algorithm if it supports a family of > > parameters like "hkc", or is each unique combination actually a > > "single algorithm" ? I can imagine needing to check both alg and > > hkc, in order to build safe APIs for "alg" aware COSE Key. > > I can imagine different interpretations of this, impacting security > > considerations. I think the threshold is unified algorithm that considers self- interactions. So HPKE is a single algorithm, and there is no need to check hkc (or even have it). And the COSE-HPKE test code I wrote is intentionally written to stuff absolutely everything to HPKE with minimum checks (IIRC, currently the only one is checking that KEMs match, but this check will be loosened if adding support for non-native keys). > Right. The alg parameter in a COSE_Key is defined in COSE only for key > use restriction for that particular key. I suppose it could be part of > a negotiation scheme, but that’s not what it’s defined for. The "hpkeadv" from my earlier e-mail is a negotiation scheme, not a use restriction. The model being "I support these, use at will". > So the new “hkc” parameter in AJITOMI’s draft is then an extension to > the alg parameter and its purpose is key use restriction. It is > definitely a step beyond anything in COSE so far which has used only > single integer ciphersuites here. Looking at the draft, it is not actually clear if "hkc" is restiction or negotiation. In contrast, JOSE and COSE are very clear "alg" is restriction. > > > The second case is having multiple implicit algorithm identifiers > > > specified for a multiple-layer COSE object. An example of how this > > > would work is the encryption context that an application > > > specifies, which contains a content encryption algorithm, a key > > > wrap algorithm, a key identifier, and a shared secret. The sender > > > omits sending the algorithm identifier for both the content layer > > > and the recipient layer, leaving only the key identifier. The > > > receiver then uses the key identifier to get the implicit > > > algorithm identifiers. > > > > This implies "sender info" could be discoverable from "kid"? But > > this would only work if the recipient key had only 1 supported kem, > > kdf and aead? > > All sorts of designs are possible and allowed. Use of the kid is > optional and when it is used, it’s meaning is application-specific. I don't think this is allowed in COSE. Alg is mandatory at every layer, and the key restricting alg only works at the lowest layer, not constraining the higher layers at all. > > Does this signal any design decisions around "hkc" ? > > > > Imagine sending a single integer for "kid" and storing only a > > single integer in the COSE Key for the 3 integers (recipient > > info) needed by HPKE. > > > > No negotiation mechanism is specified in COSE because it is highly > > variable by application domain (IMO). Some use cases may succeed > > with specification of one single algorithm (perhaps relying > > excellent SW update that happens to be available in the particular > > ecosystem). Others, like S/MIME (certificate-based encrypted email) > > may rely on directory services with X.509 certificates to advertise > > the algorithm. Another might have a round-trip negotiation protocol. > > > > What’s new here is that COSE-HPKE requires the “hkc” structure in > > addition to the integer cipher suite. The rest of COSE requires > > only the integer. That means the “hkc” structure needs to be > > incorporated into minimum-to-implement definitions, as protocol > > items in advertisement in a certificate and so on for each > > negotiation scheme used with COSE. Such design would require "hkc", while the current COSE-HPKE design does not. > (Part of the beauty of COSE’s design for highly constrained devices > is the simplicity of the single integer algorithm identification. > It has made t_cose internals much cleaner than previous work I’d done > with OIDs. If I’d realized all this a few months ago, I’d have argued > for ciphersuites a lot harder). Not having ciphersuites makes COSE-HPKE much simpler, since the values are direct inputs to HPKE. I think ciphersuites would have been mess at best, very flawed at worst. For how-not-to on ciphersuites, check what MLS (-20) seems to do (by far the worst I have ever seen). > > I think it was briefly mentioned at IETF 116, can we perhaps make > > "sender info" useful for COSE Key / JWK... or can we replace "sender > > info" with some version of "hkc". > > > > I don't think we need 2 different solutions here, even if the > > problems are different. Neither of the two is possible because the fields are different. And even if it were possible, it would not make sense, because header parameters and key parameters are separate things in COSE and JOSE. > I think key use restriction by algorithm in COSE_Key is a solvable > problem. I don't think that needs to be solved with HPKE. I am much more worried about "can recipient decrypt this?" than "is this safe?". > I do not think COSE algorithm negotiation is solvable in a general > way. The problem space is too vast and varied. That’s why COSE didn’t > solve it. Right, it gets especially difficult with multi-layer structures. > To give one example — we redesign S/MIME to use COSE, but we want > it to work with X.509 certificates because there are millions of > them out there and there is huge expensive HW infrastructure and > process to support them (HSMs). There’s no COSE_Key in that, so it > wouldn’t be part of the solution. Funnily enough, one application I have considered for COSE-HPKE is e-mail encryption. Especially in "few-off" cases. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
