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

[Russ Housley <[e-mail]>]

> On Nov 8, 2022, at 1:03 PM, Russ Housley <[e-mail]> wrote:
> 
> Sophie:
> 
>> On Sat, Nov 5, 2022 at 9:29 AM Russ Housley <[e-mail] <mailto:[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/ <https://blog.cryptographyengineering.com/2016/03/21/attack-of-week-apple-imessage/>
> 
> I do not believe that a signature stripping attack will work in the SUIT firmware case, as you say with good implementations,  In the SUIT case, if there is no signature, the firmware will be be accepted.


HUGE TYPO:  ... will not be accepted.

Russ