[Suit] suit-firmware-encryption-00

[Michael Richardson <[e-mail]>]

I have read draft-tschofenig-suit-firmware-encryption-00 and I think that the
WG should adopt it.  It fits within the charter as it is within what would
have been done in the manifest document.

Some comments:

1) I found this sentence really awkward:
     In addition to offering protection against modification, which is
     provided by a digital signature or a message authentication code, the
     firmware image may also be confidentiality protected using
     encryption.

Maybe:
     the
     firmware image may also be afforded confidentiality using
     encryption.

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.

3) Are the terms CEK and KEK from RFC3394?  I didn't find it there.
   I wonder how they play out as acronyms in languages without a soft-C
   sound... where both come out as "kay eh kay" (CEK) and "kay eh kay" (KEK)...
   It's bad enough in DNSSEC with Zee Ess Kay vs Zed Ess Kay...

4) "However, the COSE_recipient structure can contain the same CEK
   encrypted with many different KEKs if needed to reach all of the
   authorized recipients."

   This is exactly like how DVDCSS works, and how the dvdcss breach occured
   when a KEK was all zeros.  Something to think about.
   It seems that the HPKE version would not suffer from this mishap?

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.

6) should the pseudo-code in section 4, starting with "CEK = random()", be a
   figure?

7) irtf-cfrg-hpke says it is in state awaiting IRSG reviews.   Does that mean
   it is close to being published?

8) The new HPKE methods defines here might be generally useful outside of
   firmware-encryption.   I don't propose to change the document in a way to
   make it generic, but are there any applicability that we need to import?

9) Given that:
   "Both cases require some upfront communication interaction, which is
   not part of the SUIT manifest."

   do we need to say anything about this communication?
   Can an ECDH be part of an IDevID?
   Would manufacturers be tempted to use the same ECDH in every device?
   In all devices made on a particular day?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [











--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide