Re: [Suit] suit-firmware-encryption-00

[Russ Housley <[e-mail]>]

Michael:

Building on Hannes' response to three of your questions.

> 2) "This might be done to protect
>   confidential information or prevent discovery of vulnerabilities
>   through reverse engineering."
> 
>   this screams security through obscurity.   I know that some people still
>   think that this is important, so I guess I would just drop the claim.
>   There are also some significant public policy issues around declining
>   access to review and audit code, including defending against insertion
>   of malware at the source, or by National Security Letter.
>   (consider SolarWind situation)
>   I would like some text in the Security Considerations about this.
> 
> [Hannes] There may be many reasons why encryption is useful but in the referenced sentence we have been thinking about ROP. I changed the text.
> 
> The issues you mention are also important but are probably unrelated to encryption itself. If you manage to compromise a company that is responsible for distributing software/firmware updates then there will be a problem.
> 
> I agree that there are also challenges with certification schemes that prevent developers from seeing the source code (or from publishing the source code). That's yet another issue.

SUIT is using signature for the authentication and integrity of the firmware.  If the signature remains in place, a party in the middle of the distribution cannot insert any malware.

> 5) We had a discussion about how to have a complete CDDL during the meeting
>   yesterday.   I think that this version has the complete CDDL shown?
>   There isn't that much copy and pasted from 8152(bis), and I think it's
>   clearer like it is.  It just needs to be noted what is coming from 8152.
>   If 8152bis-bis *CHANGED* COSE_Encrypt in an incompatible way, then we'd
>   still be pointing at 8152bis until we updated this document.
> 
> [Hannes] I have followed the suggestion Henk provided at the last IETF meeting and copied the CDDL from COSE and then removed the parts that are not needed by this specification. When Russ reviewed the CDDL he made further suggestions on how to improve the structure because the nested structure (whereby the same names are used for the structures) made it difficult to refer to the relevant elements.

Please let us know if you see ways to add further clarity.

> 9) [snip]
> 
>   Can an ECDH be part of an IDevID?
> 
> [Hannes] You should be able to answer that question...

Are you aware of anyone that is putting key agreement public keys in the IDevID?  I thought everyone was using signature keys.

Russ