Not just the lamps attack but best known security practice. Internally, HPKE locks down all the algorithm IDs — best known security practice — even though it only allows AEAD algorithms.
I dunno if I’d call COSE_KDF_Context best practice, but it covers the next algorithm ID too. Knowing what we know now, I think we would be kind of negligent to not protect the bulk encryption alg in any new encryption standard. LL On Mar 17, 2024, at 3:29 PM, AJITOMI Daisuke <[email protected]> wrote: Hi Ilari, I think your and Laurence's proposal is reasonable as a countermeasure against the lamps attack, but should this be defined in the COSE-HPKE draft? In my opinion, we should prohibit the use of non-AEAD algorithms in the COSE-HPKE draft, and your proposal should be defined in a separate draft. Assuming HPKE(AES-*-GCM) is available, I can't imagine use cases where A128CBC must be used for content encryption, and I can't understand why CBC mode can't be prohibited for COSE-HPKE. From that perspective, your proposal seems to me to be a countermeasure against the lamps attack mainly for legacy key derivation algs (such as -25), and it doesn't seem to me something that should be defined in the COSE-HPKE draft. What do you think? (I apologize if what I say is off the mark since I don't follow all the discussions here.) Daisuke 2024年3月17日(日) 18:15 Ilari Liusvaara <[email protected]<mailto:[email protected]>>: On Fri, Mar 01, 2024 at 02:00:58PM +0200, Ilari Liusvaara wrote: > On Fri, Mar 01, 2024 at 03:39:11AM +0000, lgl > island-resort.com<http://island-resort.com/> wrote: > > So here’s a possible new Enc_structure Orie suggested. I’m calling > > it Rec_structure. It is just for COSE_Recipients. > > > > > > Rec_structure = [ > > context : “Enc_Recipient” / “Rec_Recipient", > > protected : empty_or_serialized_map, > > next_alg : int/tstr > > ] > > > > - protected is for the protected headers from the COSE_Recpient > > - No external_aad since COSE_Recipient doesn’t have that > > - Pass this as the aad parameter to Seal() as Ilari suggests > > - next_alg is the COSE algorithm ID from the COSE layer below and is > > mandatory > > I would use a single context and add explicit uint depth. Even if I > expect this to always have depth=1 in practice. As concrete example for COSE: Enc_structure2 = [ context: "enc_structure2", depth: uint/null, next_alg: int/tstr/null, protected: empty_or_serialized_map, external_aad : bstr ] - Uses core deterministic encoding. - depth is the layer number (how many layers are above this), or null for COSE_Encrypt0. - next_alg is the algorithm of next layer up, or null if this is the content encryption layer (depth 0 or null). - protected is the protected headers from this layer. - external_aad is the application-specified external aad for this layer. If not specified, defaults to empty bstr. Including depth prevents any layer-shifting attacks. The reason depth is set to null for COSE_Encrypt0 is that COSE does make a difference between COSE_Encrypt and COSE_Encrypt0, and it is a bad idea to weaken stuff like that without really understanding why it exists. Only alg is chained because there is serious issues with including full upper layer protected headers: 1) Greatly increases resource usage (as noted by lgl). 2) Operation sequencing in existing implementations. 3) There is no guarantee that alg is in protected headers (authenticated encryption!). -Ilari _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
