> On Nov 8, 2022, at 1:03 PM, Russ Housley <[email protected]> wrote: > > Sophie: > >> On Sat, Nov 5, 2022 at 9:29 AM Russ Housley <[email protected] >> <mailto:[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/ >> >> <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
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
