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]>: > 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 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] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
