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

[Michael Richardson <[e-mail]>]

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?

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.

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.

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)

}   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?

It seems like model 1 (replaces the COSE_Encrypt, signs again) is just for
discussion, and has not been really adopted.  I would rather that this was
part of the security considerations, if it is not really a 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.

}   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.

} 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?

}   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.

}   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.

} 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?

AES-KW, combined with distribution doing re-encrypt, implies that the
distribution system has access to the KEK for every device.   Is the KEK not
unique per-device?  6.1.2 implies it might not always be.

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!

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?

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

Ditto comment about PIC becoming more and more common, and anyway, compile to
two different slots.  There is also a situation where the secondary image
space is not directly addresseable ("external flash").  Even cases where the
image is loaded into RAM before being executable, and the "flash" is more disk-like.

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

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

}   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.

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 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.

Again, I believe that my comments are all of an editorial nature, and that in fact
nothing should stop deployment of this specification.









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