I agree with comments from illari and Lawrence on scenarios where headers have no algorithm... I think a few spanning use cases will make the enc structure proposals easier to consider.
A case that uses the apu/apv... A case that has no algorithms in headers. I don't find the size arguments compelling since any context that includes a protected header will have to handle variable length. I do find the generalized depth and next algorithm proposal interesting, but possibly overkill for COSE HPKE... But maybe a good general purpose solution for COSE. OS On Mon, Mar 18, 2024, 9:46 AM lgl island-resort.com <[email protected]> wrote: > 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]>: > >> 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 > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
