> On Sep 12, 2025, at 12:11 PM, Ilari Liusvaara <[email protected]> > wrote: > > On Mon, Sep 08, 2025 at 10:06:34AM -0700, Laurence Lundblade wrote: >> Focusing on ECDH-ES + A128KW, algorithm ID -29, section 6.4.1 of >> RFC 8949. >> >> Any fix to -29 for non-AEAD algorithms will NOT be compatible with >> existing implementations. Adding the layer defined in >> draft-tschofenig-cose-cek-hkdf-sha256 >> will require a large change to any implementation of -29. > > My understanding is that it is not a layer, but a transform on the key > used on a layer.
Right, not a COSE layer like COSE_Encrypt or COSE_Recipient, but a new layer in the sense of some more processing. > And it is only supported on layers with symmetric input > keys, which does not include -29. -29 is vulnerable to the lamps attack so draft-tschofenig-cose-cek-hkdf-sha256 has to be used with it, right? > And yes, using it will not be compatible with existing implementations. > I do not think it is a large change, but I would need to try to modify > my COSE-HPKE prototype implementation (the encryption side does support > any other-type recipient). Perhaps the number of lines changed is small, but it is an unnecessary increase in object code size. I also find draft-tschofenig-cose-cek-hkdf-sha256 a sort of “bolt on” fix that is not really aligned with the COSE architecture. >> So what we should do instead is define ECDH-ES + A128KWbis, with a new >> algorithm ID like -129, that authenticates the algorithm ID properly. >> The solution would look a lot like what we did for COSE-HPKE. > > While it would be possible to hack algorithm ID authentication to > composed KAwKW, To be explicit, the design is such that the key distribution layer, the COSE_Recipient has the next_layer_alg header parameter that authenticates the algorithm ID for the symmetric layer below. It doesn’t matter if layer 0 is an AEAD or not. > it would not work with algorithms that do not have > any capability for authenticated data, like Authenticated Encryption > or Key Transport. The correct answer IMO in those cases is to define a new algorithm that does use a KDF. Direct Key with KDF (alg ID -10…) is an example of that. > CMS faces analogous problem, which is why the CMS fix is done the way it > is. So far I haven’t looked at the CMS design (though I implemented it once) to say if there was a better solution for CMS like I believe there is for COSE. >> I would also like to replace Context Information Structure like we did >> for COSE-HPKE. > > Note that COSE does support ECDH-SS, which needs more complex Context > Information Structure, in order to break the symmetry and to inject > entropy. > > Breaking the symmety could be done with a one-byte key spaceship field > (is the sender key less, equal or greater than reciver key in some total > order), and injecting entropy with a bstr field. Yes, we have to provide an alternative to Context Information Structure. The new design can be simper and cleaner. LL
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
