Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
draft-housley-cms-fw-wrap-11

[Ballot comment]
Reviewed by Scott Brim, Gen-ART
No objections from the reviewer.

I worried about adequate review by people who know code management - but subsequently, several people have said that they have reviewed it and are happy with it. So I'm sending this forward.

I talked to Jeff Hutzelman and received permission to put this in the
tracker.  We also had a discussion about the dependency issue.  I
pointed out that his suggestion (2) was actually already true in the
current draft: if the dependency information in the current draft is
provided, an implementation MUST check it, but a vendor can choose to
use their own dependency information imbeded in the package.

I agree we need to adopt Jeff's suggestion 1 for dependencies.  I
believe adopting suggestion 3 would be a bad idea: it introduces
significant complexity and parties requiring that complexity almost
certainly have a preferred format for expressing dependencies.


During our discussion of his review Jeff and I decided we would like
to see the draft point out the issue of circular dependencies.  We
should point out that you can build a system on top of this document
that handles circular dependencies but describing a particular
solution is out of scope.  The probable solution is to provide a
facility for atomically apply a set of firmware packages.  However
there is a lot of complexity associated with  the security analysis
and failure handling.  I'd rather not go down that path with this
draft.




From: Jeffrey Hutzelman
Subject: draft-housley-cms-fw-wrap-09.txt

Below is the first rev of my comments on Russ's document, more or less
prepared as I read it through for the first time.  There are some things I
want to go back and examine in more detail and/or think about some more,
especially in light of Harald's comments.  I'll try to do that in the next
week, but I thought I'd send you what I have so far.

I'm CC'ing Russ on this, since most of it won't change between now and when
I'm done, and I see no reason to hold it back.  The main caveat is that my
comments on handling dependencies might change signficantly after I've
thought about the issue some more.  They might also be affected a lot by
things like the intended application and how much work Russ wants to do
(what's in there now suggests relatively simple changes; I could suggest
something a lot more complete, but it'd be more work to specify and maybe
to implement, and I'm not sure it's a good idea).


Overall, the document is well-written, easy to understand, and sucks less
than PKINIT (though the last is faint praise).  Aside from the dependency
issues, nothing I've found so far is something I would consider a
show-stopper.


- The spec seems to assume that all the work will be done inside the
  hardware module whose firmware is to be upgraded.  It seems like the
  applicability of this document could be broadened by allowing for the
  case where all the work is done on a general-purpose computer which
  then programs a "dumb" device, or writes the unpackaged firmware image
  onto a piece of removable media in a bootable form.

- I don't understand the purpose of the authorization model where a
  package contains information about what devices are allowed to have
  it, and the device is trusted to implement the access control.  The
  trust model here seems backwards -- if only some devices are permitted
  to load the package, then the vendor should limit distribution of the
  package or encrypt it in keys known only to the authorized devices.

- Dependency analysis is hard.  This document describes only the simplest
  of dependency models, in which a package can indicate the need for
  at least a specified minimum version of one or more other packages.
  Unfortunately, as the number of packages and versions grows beyond
  just a few, this proves to be insufficient.  A complete dependency
  system will have at least the following features (approximately in
  decreasing order of importance):

  - Minimum and maximum versions for each dependency, which can be used
    separately or together.
  - Anti-dependencies; that is, other packages (or versions) with which
    this package is incompatible.
  - The ability to load multiple packages in one atomic transaction, so
    it is possible to install sets of packages where there is a cycle
    in the dependency graph.
  - The ability for one package to obsolete another.  For example, a new
    package might subsume functionality previously provided by multiple
    packages.
  - The ability for packages to provide and depend on versioned "features"
    other than the package name itself.  This allows representation of
    the situation where package X requires a feature which might be
    provided by any of A, B, or C.

  In addition, when loading a package it is not enough to check that the
  dependencies of the package being loaded are satisfied.  It is also
  critical to check that loading the new package does not violate the
  requirements of any other package already loaded.

  Obviously, the focus of this document is not on providing a complete
  packaging system for products involving hundreds or thousands of
  packages.  So, it would be inappropriate to spend lots of effort on
  a complex dependency system, which is itself a hard problem.  Still,
  it doesn't seem right to abandon the problem entirely, either.  So,
  I have three recommendations for this...

  (1) Loading a package MUST fail if it would cause the dependency
      requirements of an already-loaded package to be violated.
  (2) Packages should be able to include additional information about
      dependencies, in a vendor-defined format.
  (3) This is not critical, but it would be nice to have a richer
      dependency data model, with these properties;
      + Preferred-form dependencies have both min and max versions
      + Dependencies can be on "features" in addition to packages
      + Packages can include a list of features they provide.
      (think of a feature as a "phony" package name)

- I'm concerned about the requirement that "A unique object identifier
  MUST identify the collection of features that characterize the
  firmware package".  This and the subsequent text seem desgined to
  insure that different branches or feature trains will have different
  OID's.  That's probably a good thing, but the text as written seems
  to require that if I introduce a new feature, I have to change the
  OID.

- When an earlier version is replacing a newer one, the bootstrap loader
  should not only generate a warning, but offer an opportunity to abort
  the load.  Obviously this is not possible in all cases...

- In storing preferred stale version numbers, only the most recent stale
  version for any given OID needs to be recorded.  One would hope that
  implementors could figure this out for themselves, but it can't hurt
  to call it out.

2.2.3 Firmware Package Identifier:
  Should PreferredOrLegacyPackageIdentifier be extensible?
  Make stale a SEQUENCE, to allow one package to identify more than one
  stale version?

2.2.8 CommunityIdentifiers
  Should CommunityIdentifier be extensible?

4.1.3 FirmwarePackageLoadError
  I think the integer vendorErrorCode is a step in the right direction,
  but insufficient by itself.  It should be possible to provide an
  OCTET STRING containing detailed information about the cause and
  circumstances of the error in a vendor-specific format.

Date: Thu, 06 Jan 2005 13:33:05 -0500
From: Jeffrey Altman
Organization: Not Affiliated with Columbia University in the City of New York
To: Sam Hartman
Subject: Re: Secdir review:  draft-housley-cms-fw-wrap-09 as a software packaging
format
Sam Hartman wrote:

>
> Hi.  I'm shepherding a document for protecting firmware to be loaded
> into hardware devices.  The security aspects of the document seem
> fine, but Harald has an outstanding discuss asking for more review of
> the software packaging aspects of the document.
>
> I know all three of you have spent significant time evaluating
> software packaging systems and using them in your environments.  I
> understand that you typically deal with environments where the
> software packaging is for computers/os software rather than embed i
> systems, but I believe the software packaging requirements for that
> environment are strictly more involved than for embedded systems.d
>
>
>
> Please evaluate the software packaging aspects of this proposal.
> Please let me know if you will have time for this review ASAP and
> please return evaluations by 2005-01-06.
>
>
> --Sam

Sam:

Overall I think this document is excellent.  The contents of the
firmware packaging support for restricted rollbacks, applicable
uses, and designated communities is well thought out.  It would be
desirable to see this level of support for protecting the software
package distributions for Linux, MacOSX or Windows.

Unfortunately, there is thing which gnaws at me throughout the document:
We cannot assume that the hardware module which is accepting the
firmware package is either directly connected to a network or contains a
clock.  This means that revocation checks cannot be performed by the
module.  This is not described in the Security Considerations although
it is briefly discussed in the Introduction (first paragraph page 5.)

One thought that comes to mind is whether or not this document should
provide optional support for the entity delivering the firmware package
to the hardware module to also provide an OCSP response similar to
what we are doing in  draft-ietf-krb-wg-ocsp-for-pkinit.  This would
allow the hardware module to perform a validation check although it
would still be forced to trust its peer in the delivery process to
provide it a statement of current time.  If a clock was provided
the validation process would be complete.

Some other minor items:

#1  There is something wrong with the formatting of this document.
At random points throughout there are line breaks inserted in the
middle of words.

#2  Last two paragraphs of page 8.  Each paragraph ends with a
discussion of "stale versions".  Once for legacy and once for preferred.
  The text is similar enough that it would be better to extract the
discussion into its own paragraph.

I have not validated the ASN.1 as part of this review.

Jeffrey Altman

[Ballot discuss]
This mechanism specifies one component of a firmware management system.
It does not specify the architecture of the system, and it does not specify the usage models envisioned for the system.
It is apparently specialized for some particular application (naming exported functions with the attribute "Implemented Crypto Algorithms" is a dead giveaway), but this is never mentioned in the introduction.
The model of using only exact matching of complete object identifiers for both hardware module versions and software dependency versions also indicates that this is only useful in an environment where "control is everything".

Google found no sign of a review on a public mailing list.

There is no mention in the document of any company intending to use this.

There is no mention of a review by people who are experts in the software management business.

I would have no problem with this as Experimental - I'd find it valuable.

But I think it's very likely to require substantial change before it's a generally usable mechanism for software module maintenance. Proposed Standard is inappropriate.

[Ballot comment]
I see reference:

  UTF-8      Yergeau, F.  UTF-8, a transformation format of ISO 10646.
              RFC 2279.  January 1998.

Would it be better to reference RFC 3629, which obsoltes 2279 ??