Re: [Suit] WG: WGLC on draft-ietf-suit-firmware-encryption-14 due on September 11, 2023

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

thanks for reviewing the draft.

Am 11.09.2023 um 00:20 schrieb Michael Richardson:
> Hi, I re-read draft-ietf-suit-firmware-encryption-14.
> My comments below are entirely of an editorial nature.
>
> 1. Figure one has a data flow from right to left.
>     My brain would prefer left-to-right, but if you want to do it this way,
>     then can you add arrows to the lines so that the payload+manifest clearly
>     flows *to* the devices?


Makes sense.


>
> 2. The lack of any standard way to "obtains information about the
>     recipients and their keys from the distribution system."
>
>     should probably be more clearly noted.


There are standardized device management solutions available. So, that's
not a problem.


> 3. "The author treats the distribution system as the initial recipient"
>     this is also not-standardized, and I think might involve some kind of
>     integration with a sales channel.


This is not standardized, as far as I know. However, this is the area of
classical Web APIs.

>
> An upside of this intermediate step is that:
> - distribution system can inspect the contents
> - distribution system does not need to disclose which devices are involved.
>    (or where they are, or how they are named)
Correct.
>
> }   If the author and distributor are separate entities, then the author
> }   must delegate encryption rights to the distributor.  By the principle
>
> they are clearly depicted as different entities.  I wonder if you mean the
> author and sender are different entities?

I re-worded the text since it was indeed not clear.


>
> It seems like model 1 (replaces the COSE_Encrypt, signs again) is just for
> discussion, and has not been really adopted.


In practice, this is how it is done today.


>    I would rather that this was
> part of the security considerations, if it is not really a choice.

It is a real choice.


> This model also implies that the devices are able to trust the distributor,
> so they have had their trust anchors updated, which also means that the
> distributor has actual control over the devices, and is able to survive the
> business failure of the author.

Correct.


>
> }   Since
> }   a device will typically only support one of the content key
> }   distribution algorithms, the distribution system needs to know a
>
> I think this refers to AES-KW vs ES-DH, vs model 1/2 above.

Yes. Correct.


>
> } the distribution system needs to know about
> } the properties of the deployed devices
>
> how does this distribution system know this? Is it derivable from the content
> that the author/sender provides, or does it require configuration?


If the distribution system, which is more than a file server, encrypts
the payload it needs to know what content key distribution method the
device supports based on the keys it maintains for the devices.

>
> }   RFC Editor's Note (TBD1): The value for the suit-parameter-
> }   encryption-info parameter is set to 19, as the proposed value.]
>
> I suggest: TBD19  if IANA has not yet done their thing.

I don't think we need to worry about the IANA registrations here.


>
> }   Another attack concerns battery exhaustion.  An attacker may swap
> }   detached payloads and thereby force the device to process a wrong
>
> wow, this just jumps into the middle of a protocol description.
> This paragraph and the next one seem like Security Considerations to me.
> The availability of the digest is protocol, but the reasons for it can/should
> be SC.

You are correct. I re-arranged the text.


> } Many other methods are specified in the literature, and even
> } supported by COSE.
>
> okay, but I guess, think, that AES-KW and ES-DH provide for 99% of the target
> cases then?
Yes.
>
> AES-KW, combined with distribution doing re-encrypt, implies that the
> distribution system has access to the KEK for every device.
Yes.
>     Is the KEK not
> unique per-device?  6.1.2 implies it might not always be.

Ideally, it is unique per device. Of course, practice is often different.


>
> I suggest that the different ways of using AES-KW, with common KEK across
> devices, vs per-device KEK be clearly named and listed a different options.
> And then third option of different CEKs!

Let me think about given the versions different names.


>
> I think that 6.2.2, "same encrypted payload", the CEK is the same, but the
> CEK is encrypted multiple times with different KEKs, derived from the
> different ES-DH operations, because every device has a different g^y?

Yes.


>
> Is there a case where all devices have the same g^y?

No, not in this document. Should there be?


>
> Ditto comment about PIC becoming more and more common, and anyway, compile to
> two different slots.

Where is PIC becoming more popular? Which RTOS supports PIC?


>    There is also a situation where the secondary image
> space is not directly addresseable ("external flash").

We support this use case.


>    Even cases where the
> image is loaded into RAM before being executable, and the "flash" is more disk-like.

This is supported as well but here we are also talking about corner
cases because most constrained IoT devices don't have so much ram to fit
the firmware image into it.


>
> I think this section 7 could be an appendix.
> sections 7.1/7.2 seems more of a standard statement, and contains BCP14
> language.

What would be the benefit of moving the text to the appendix?


>
> Thanks for including examples with private keys. I think you can mark those
> pieces as code blocks so they are more easily extracted.

What would be the best way of doing it here?


>
> }   To provide high security for AES Key Wrap, it is important that the
> }   KEK is of high entropy, and that implementations protect the KEK from
> }   disclosure.  Compromise of the KEK may result in the disclosure of
> }   all key data protected with that KEK.
>
> I believe that protecting firmware from disclosure is a low-value activity.
> (Others disagree: but I continue to believe they have IPR violations to hide)
>
> HOWEVER, one of the useful things for suit-firmware-encryption is for
> configuration data.   That could even include application identity keys.
> Keeping application credentials across hardware replacements is probably an
> important simplication for IoT ecosystems.
>
> I believe that one could have multiple KEKs: that the firmware-encryption one
> might be different from the configuration encryption one.  This is worth
> mentioning.

Good idea. Added text.


>
> On the whole I found the SC section far far too short, and I've indicated
> some text that I think could move there.   I think that the SC should review
> the 5 (6?) possible ways to use CEKs, KEKs, and ES-DH keys, providing some
> guidance on which might be appropriate to different uses, or at least, laying
> out the different properties in a more easily digested table-like format.

I have restructured the text a bit and made the security consideration
section even shorter.

Let me think about the "table" idea.


>
> I also think that it would be good to collect the set of "no standard exists
> for..." into a single place, maybe bullet pointed, as that will more clearly
> tell people where they need to come up with answers.
Ok.
>
> Again, I believe that my comments are all of an editorial nature, and that in fact
> nothing should stop deployment of this specification.
>

I appreciate your feedback, which makes the document read better.


Ciao
Hannes