Inline: On Fri, Apr 14, 2023 at 2:44 AM Ilari Liusvaara <[email protected]> wrote:
> 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. > > alg is optional in COSE Key and JWK. AFAIK, it is mandatory in most envelope formats and it is usually not accompanied with "extra parameterization / agility"... but this is what COSE HPKE proposes to change. > > > > 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). > > Apple seems to disagree on this point: https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests?language=objc Their algorithm "APPLE-HPKE-v1", does exactly what I have been suggesting: https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests#4036908 Encode the "HKC stuff, in the algorithm name, and register it". > > > > 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 don't think this is true, I can imagine using Apple's "APPLE-HPKE-v1" in both JWK and COSE Key. > > > 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 > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
