Hi Orie, Let me try a refinement of the previous proposals: > HPKE_AAD = CBOR([ > "HPKE-Key-Encryption", content_encryption_algorithm, > recipient_protected_header, > external_aad > ])
In COSE-HPKE key encryption, I believe that adding content_encryption_algorithm (a.k.a. next_alg) into aad for HPKE at layer1 cannot affect the key separation at layer0. It can affect only the separation of CEK encryption keys derived at layer1. In other words, even if you use the proposed HPKE_AAD, it would not prevent the sender from using the same key for both alg A128CBC and A128GCM at layer0. It seems that the best solution is to limit the content encryption algorithms available at layer0 in two layer COSE-HPKE to only AEADs. Alternatively, it might be necessary to carefully explain why the lamps attack is not a concern in COSE-HPKE key encryption. Am I misunderstanding something? Daisuke 2024年3月21日(木) 5:54 Orie Steele <[email protected]>: > This is the main thing we need to address in COSE HPKE: > > > What matters is that the algorithm ID at layer 0 is protected. It must > always be protected no matter what type of COSE or HPKE or CMS or JOSE we > are considering. > > In HPKE, the AAD enc structure is the best place to do it ( we discussed > alternatives and dismissed them already ). > > We need to protect the algorithm directly because in COSE protected > headers are not required to carry algorithms. > > From a terminology perspective, I think "next alg" is not a great name, > and while I liked the generic depth construction from illari, it seems > overkill for HPKE, which only supply 2 layers. > > Let me try a refinement of the previous proposals: > > HPKE_AAD = CBOR([ > "HPKE-Key-Encryption", content_encryption_algorithm, > recipient_protected_header, > external_aad > ]) > > Yes, external AAD at this layer is strange, but it enables private > information, which we lost when rejecting COSE KDF Context. > > The depth is part of the context string, and in the case that recipient > protected header has no algorithms, HPKE internally commits to the hole > suite anyway. > > OS > > On Thu, Mar 21, 2024, 3:28 AM lgl island-resort.com <[email protected]> > wrote: > >> >> >> On Mar 19, 2024, at 5:43 PM, AJITOMI Daisuke <[email protected]> wrote: >> >> Hi Laurence, >> >> Two-layer COSE-HPKE is structurally the same as -25. If we take out >>> COSE_KDF_Context and don’t provide an equivalent we are going backwards. >> >> >> It's not correct. Two-layer COSE-HPKE is not similar to -25, but -29. >> >> To illustrate using HPKE, in direct key agreement (-25, etc.), KEM and >> KDF are done at layer1, and AEAD is done at layer0. On the other hand, in >> COSE-HPKE key encryption, KEM, KDF, and AEAD all are done at layer1 for CEK >> encryption. >> This is the same as Key Agreement with Key Wrap (-29, etc.). >> >> >> Well, yes, kinda-sorta, but in a way that doesn’t matter for the >> discussion at hand. >> >> The important part is that next_alg provides the necessary protection for >> both -25 and COSE-HPKE Key Encryption (aka 2-layer COSE). They are the same >> in that regard. >> >> As you mentioned, next_alg is not a solution for -29. From my >> understanding, next_alg makes sense primarily for direct key agreement and >> is not related to COSE-HPKE. >> >> >> I don’t think that logic makes sense. Two-layer COSE-HPKE is vulnerable >> to the lamps attack. >> >> (and we can probably have a next_next_alg or such to fix -29). >> >> >> Anyway, in COSE-HPKE key encryption, the key encryption at layer1 is >> protected by HPKE and is not affected by the lamps attack. >> >> >> Yes, that’s true. In particular you can’t change the algorithm ID for the >> AEAD inside HPKE to a non-AEAD. Such a change will be detected and blocked. >> >> The discussion about the keys used at layer0 is independent of layer1, >> and in my opinion, does not need to be considered in COSE-HPKE draft, >> regardless of whether non-AEAD algs can be used at layer0. >> >> >> Not sure why you mention “keys used at layer 0”. What matters is that the >> algorithm ID at layer 0 is protected. It must always be protected no matter >> what type of COSE or HPKE or CMS or JOSE we are considering. >> >> LL >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
