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
