On Mon, Mar 18, 2024 at 07:29:41AM +0900, AJITOMI Daisuke 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.
What I think should be done is to prohibit using non-authenticated content encryption and key wrap algorithms in COSE. The problem with doing anything in COSE-HPKE draft is that it leaves the existing stuff unprotected (the "optional security" mistake). > 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. If one looks at the RFC that adds unauthenticated content encryption, the stated use case is essentially performing neat encryption with external authentication. However, using it safely is at best difficult: - To get neat encryption in COSE, you need to detach the ciphertext. - COSE does not support vector sign/MAC so only the ciphertext can be authenticated, not any other auxiliary structures. I had idea of split tag mode (move tag into unprotected header). It would also offer neat encryption, and by being just post-encryption data shuffle, it would have trivial security implications. Even better, the main COSE bulk encryption algorithms are counter-EtM type, allowing fast validation pass and constant-time random access. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
