Essentially, every case where we use COSE KDF context to derive a key that does not commit to the content encryption algorithm, we would need to use a new context that did commit to the content encryption algorithm, and we would want to deprecate all the algorithms that were vulnerable to the cross mode attack at the same time.
We might as well fully specify the new entries at that rate as well. ECDH-ES+A128KW+A128GCM ECDH-ES+HKDF-256+A128GCM Or fully specified: ECDH-ES-P384+A128KW+A128GCM ECDH-ES-P384+HKDF-256+A128GCM That's a lot of work, and certainly belongs in a separate draft, which I would be happy to review, but probably don't have time to author at this point. OS On Sun, Mar 24, 2024, 4:10 PM lgl island-resort.com <[email protected]> wrote: > > > On Mar 24, 2024, at 2:51 AM, Ilari Liusvaara <[email protected]> > wrote: > > > > On Sat, Mar 23, 2024 at 08:37:58PM +0000, lgl island-resort.com wrote: > >> > >> On Mar 23, 2024, at 10:13 AM, Ilari Liusvaara <[email protected]> > wrote: > >> > >> _If_ key management algorithm is aad-capable, adding next_alg to aad is > >> an easy way to make decryption fail if attacker alters algorithms. > >> > >> COSE -25 and for COSE-HPKE key management is aad-capable. With a > >> little extra work I think content_encryption_algorithm (formerly > >> next_alg) can work for COSE -29. > > > > Sure -29 can be hacked to work. And fully-specified-encryption would > > redo it anyway. The main problem is Key Wrap and Key Transport. > > > > And next_alg and content_encryption_algorithm are not the same thing. > > next_alg is the algorithm with what the unwrapped key will be used with, > > while content_encryption_algorithm can be something else if there is > > intermediate step (even if I do not know why anyone would do that). > > My thought is that content_encryption_algorithm is the COSE algorithm ID > for the next *COSE* layer. > > > >> I’m starting to think about a new draft to define the -29 replacement. > >> Probably not a large document. It would not use COSE_KDF_Context. It > >> would use a new Enc_structure with content_encryption_algorithm. > > > > There should still be something close to COSE_KDF_Context, because it > > is driven by ECDH (or KEM), and thus there should be KDF step. > > > > > >> It could define a -25 replacement too, one without COSE_KDF_Context. > > > > Uh, the whole purpose of -25 is to have ECDH driving a KDF. > > Yes, still must have a KDF and section 5.1 applies, but the “info” or > "context information” input to the KDF would be a Recipient_structure like > that proposed by Ori, not the COSE_KDF_Context from section 5.2. > > 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
