Re: [COSE] COSE Support for AES-CTR and AES-CBC

[Sophie Schmieg <[e-mail]>]

On Sat, Nov 5, 2022 at 9:29 AM Russ Housley <[e-mail]> 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 |
[e-mail]