> On Jun 2, 2023, at 1:52 PM, Ilari Liusvaara <[email protected]> wrote: > > On Fri, Jun 02, 2023 at 05:59:30PM +0000, lgl island-resort.com wrote: >> >> >> Algorithm ID >> Binds the output key material of the HKDF to the algorithm that key >> material will be used with. The purpose is explained fairly well in >> RFC 9053. >> >> HPKE takes care of this internally for COSE-HPKE single recipient >> mode, but not for multiple recipient mode. > > AFAIK, the native ECDH mode in COSE has the same limitation: > > The COSE_KDF_Context binds the next algorithm. If there is only a > single recipient, it is the final bulk encryption, so everything is > bound. However, in case of multi-recipient, it is key wrap, leaving > the final bulk encryption unbound.
- COSE-HPKE single recipient — not applicable because content encryption is internal to HPKE - COSE-HPKE multiple-recipient — applicable because the next stage after HPKE is the content encryption AEAD - RFC 9053 6.1.2. Direct Key with KDF — applicable because the next stage after HPKE is the content encryption AEAD - RFC 9053 6.3.1. Direct ECDH — applicable because the next stage after HPKE is the content encryption AEAD - RFC 9053 6.4.1. ECDH with Key Wrap — not applicable because the next stage is key wrap So this mechanism can work for COSE-HPKE, but rather unfortunately not for ECDH with Key Wrap. Just because it doesn’t work for ECDH with Key Wrap doesn’t mean we shouldn’t do it for COSE-HPKE. It seems possible to design new AES Key Wrap that is an AEAD. It would have an “info” input like SealBase and HKDF. >> Sender/Receiver Info (e.g. Party U) >> Appendix B of NIST SP800-56A gives the rationale referencing some >> papers describing attacks. This is fairly esoteric for me so far so >> I can't give a plain explanation. I’m still kind of looking for good >> guidance on how / when to use this. It seems like this is >> defense-in-depth rather than essential unless your use case is poorly >> constructed in some way. >> >> However, I think the bottom line is that is best practice nowadays, >> so for example COSE libraries should really support it. > > I see two reasons for including the info in the appendix. > > - The first does not look applicable, because HPKE always generates > fresh keys. You are talking about every key except the static key for the recipient (pkR), right? I would expect most non-HPKE COSE implementations to do the same. Can one categorically say that if all keys are fresh (except pkR), PartyU/PartyV is completely unnecessary? > - The second does look applicable. However, adding it in a way that is > neither trivially broken nor highly application-specific seems almost > impossible. From a COSE library view, this seems fairly simple. Just allow the caller to set PartyU and PartyV. If a use case wants to go to a ton of trouble for some application-specific issue they can. If not, they default to “sender” and “receiver”. Seems like there has to be some value as they are not optional. >> SuppPubInfo.protected >> This is the super-important part that protects the protected COSE >> header parameters. >> >> Absolutely not optional. >> >> In COSE-HPKE draft-05, this is taken care of by using an Enc_structure >> with context “Enc_Recipient”, but we could (should) change COSE-HPKE >> to line up better with the rest of COSE. >> >> For some COSE, like AES Key Wrap that has no AEAD or HKDF there is no >> protection here. > > Because HPKE is AEAD-capable, COSE header parameters are already > protected by Enc_structure (by RFC9052). Including those into KDF > context would lead to double protection, which is silly. My proposal is to fully replace the Enc_structure with COSE_KDF_Context in COSE-HPKE. I am not proposing double protection. I believe use of COSE_KDF_Context with COSE-HPKE is in line with COSE in general and is best practice from SP800-56A (and with JOSE). For me it is also going to be less code, because there will no longer be a need for Enc_structure with context “Enc_Recipient” at all. (If COSE were not a published standard, I’d use Enc_structure with context “Enc_Recipient” and put all the stuff in COSE_KDF_Context into COSE_Recipient header parameters to get a cleaner simpler design). > And I think taking authentication failure with correct keys is > slightly more sound than trying to use wrong keys. > > >> Other — Hash of ciphertext >> Hannes has proposed that a hash of the SUIT_Digest be included here. >> In practice I think this is a hash of ciphertext in the COSE_Encrypt. > > That seems like it would be impossible to implement because of hard > cyclic dependency? It is possible. We have a prototype, but I don’t think it is a good idea. LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
