On Sat, Nov 5, 2022 at 9:29 AM Russ Housley <[email protected]> wrote:
> The Security Considerations is already longer than the rest of the > document. And, the specification already says that AES-CTR MUST be used > with some other integrity mechanism. In the SUIT environment, the > integrity mechanism a digital signature. > But using AES-CTR with another integrity mechanism alone does not help, since signature stripping would still work. For an example of a signature stripping attack with AES-CTR, see [1]. All of these issues are in the end avoidable by a good implementation (i.e. one that annotates keys with their algorithm, and does not use the alg field in order to make algorithm decisions), but experience shows that implementers are not always careful reading advisory sections of a spec. A clear distinction on the standard level, making sure that these two things are different and should use different methods does help a lot with this issue, as it acts as a somewhat self-enforcing advisory, and seems to get you exactly what you want in terms of functionality. I'm slightly confused why you would use COSE at all if you are worried about overhead, instead of using the output format of the cryptographic standard directly, that seems to be a preferable choice for this use case? [1] https://blog.cryptographyengineering.com/2016/03/21/attack-of-week-apple-imessage/ -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
