On Thu, Nov 09, 2023 at 11:07:53AM +0000, lgl island-resort.com wrote: > I believe this relates to Context Info Structure in RFC 9053 because > it COSE_KDF_Context.AlgorithmID is a potential fix. > > It is unfortunately not a fix for ESDH-ES with key wrap (-29) because > the key wrap doesn’t take an additional data so there’s no way to put > the algorithm ID for the bulk symmetric algorithm in. It would work > for direct ESDH (-25), but you can’t do multiple recipients with that, > so we don’t use it much.
I did note that modes that run key though KDF are not affected (beause of the COSE_KDF_Context.AlgorithmID). And the no recipients case should not be affected either. This only leaves the "other" case. And the handwave of solution would work with multiple recipients and looking at the slides, it is pretty much similar to what the slides proposed for CMS. The idea is to put the KDF on the same layer with the encryption, not the next layer up. There are also mitigations a COSE implementation could do: - Strictly implementing authenticated encryption. - Requiring special API for any unauthenticated modes (A*CBC and A*CTR), or even better, not supporting those at all. > I think 1 layer COSE-HPKE takes care of this because HPKE > intrinsically takes care of this. Right? Correct. > We could make two-layer COSE-HPKE take care of this, but we’d have > user Context Info Structure with COSE-HPKE, which is currently not > the plan, or find some other way to mix in the identifier for the > bulk encryption algorithm. I think it could be in a protected > parameter. For two-layer COSE-HPKE, next_alg header would work. Unfortunately, it is not a good solution because it will not work with the usual key wrap modes, because those are not AEAD. > > On Nov 8, 2023, at 6:13 PM, Ilari Liusvaara <[email protected]> > > wrote: > > > > On Wed, Nov 08, 2023 at 04:48:57PM +0100, Orie Steele wrote: > >> > >> There was an excellent presentation from Falko and Russ in Lamps, that > >> impacts jose and cose content encryption schemes. > >> > >> https://datatracker.ietf.org/meeting/118/session/lamps > >> > >> See the slides for attack against aead, and kdf for content encryption. > >> > >> In particular we may need to consider adding some binding between the key > >> and the algorithm, even when using the fully specified algorithms, such as > >> the recently suggested hpke suites. > >> > >> The issue is not whether or not the algorithm is fully specified, it is > >> whether or not the algorithm is mixed by some kdf to prevent cross mode > >> attacks on the aead. > > > > COSE/JOSE do have modes where the key is output by KDF. These modes do > > mix in the algorithm identifier. And when using symmetric keys, the key > > should specify alg[1]. > > > > The issue is with modes that wrap keys. Fixing this is complicated by: > > > > 1) There can be multiple parallel key wraps, and all output keys must > > match. > > 2) Key wraps usually do not admit associated data. > > > > > > One possible solution would be to have header parameter that causes key > > to be run through KDF before use at the same layer, only allowed for > > AEAD ciphers with other recipient type. Bonus points for also handling > > IVs. > > > > > > [1] I noticed that pretty quick when trying to work with COSE/JOSE > > implementation, the symmetric keys turn into mess as there is no > > subtyping. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
