Subject: [apps-discuss] Applications Area Review of draft-ietf-sidr-rpki-manifests-10

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Apr 2011 15:47:23 -0700

I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team). Please
resolve these comments along with any other Last Call comments you may
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-sidr-rpki-manifests-10
Title:  Manifests for the Resource Public Key Infrastructure
Reviewer: Ted Hardie
Review Date: April 21, 2011

Summary:  This draft is almost ready for publication as a Proposed Standard,
but I believe it would benefit from restructuring to highlight the
operational requirements for correct use.

Issues:

It's always difficult to review one piece of a document set that clearly
depends on a much broader context, because some of the backstory is
scattered in other documents.  My primary concern with this document is not
that it is incomplete, but that some of the operationally critical pieces
may be too buried for the user community not immersed in the development of
the protocol.

The document introduction describes the baseline need for the protocol with
this text:

   However, digital signatures provide no protection
   against attacks that substitute "stale" versions of signed objects
   (i.e., objects that were valid and have not expired, but have since
   been superseded) or attacks that remove an object that should be
   present in the repository.  To assist in the detection of such
   attacks, the RPKI repository system can make use of a signed object
   called a "manifest".

and the model for the response as:

   Manifests are modeled on CRLs, as the issues involved in detecting
   stale manifests, and detection of potential attacks using manifest
   replays, etc are similar to those for CRLs.  The syntax of the
   manifest payload differs from CRLs, since RPKI repositories contain
   objects not covered by CRLs,e.g., digitally signed objects, such as
   Route Origination Authorizations (ROAs)

The risk here appears to be exactly the same as that of CRL that is
unexpired but superseded--if a manifest has not reached its "nextUpdate"
time but has been superseded, it provides protection only if the relying
partying can detect that the manifest has changed.   An early pointer to the
operational implications in this specific context would be valuable for the
naive reader. It would be especially useful to describe how and when relying
parties should check for updated manifests, when this is not simply a new
retrieval at nextUpdate time.

Some other aspects of the operational considerations that are present appear
to be a bit buried.  For example, this text in the definition of the
nextUpdate field ties the nextUpdate time for the manifest to that of an
encompassed CRL:

     If the authority alters any of the items that it has published in
      the repository publication point, then the authority MUST issue a
      new manifest before the nextUpdate time.  If a manifest
      encompasses a CRL, the nextUpdate field of the manifest MUST match
      that of the CRL's nextUpdate field, as the manifest will be re-
      issued when a new CRL is published.

The implications to me are that whoever controls the issuance of the
manifest must also control the issuance of the CRL, so that the CRL's
nextUpdate field can take into account any *other* changes that it might
need to make that would cause it to issue a new manifest. (Alternatively, it
might be permitted to issue a manifest with a nextUpdate time that was
before the CRL's nextUpdate time.)  It also seems difficult to include more
than one CRL in the repository, since they would all be tied to the same
timing.  Making this impact explicit, rather than implicit would be
valuable.

I was also concerned by the apparent conflicts occasionally caused by the
discussion of key rollover.   In section 5.2, for example, the document
says:

   Since the manifest object URL is included in the SIA of issued
   Certificates, a new manifest MUST NOT invalidate the manifest object
   URL of previously issued certificates.  This implies that the
   manifest's publication name in the repository, in the form of an
   object URL, is unchanged across manifest generation cycles.

   When a CA entity is performing a key rollover, the entity MAY chose
   to have two CAs instances simultaneously publishing into the same
   repository publication point.  In this case there will be one
   manifest associated with each active CA instance that is publishing
   into the common repository publication point (directory).

The impact of the second paragraph seems to be that in the case where two CA
instances are publishing simultaneously, each manifest must have a different
object URL.  Describing how a relying party determines that it should shift
to the new instance (and thus new object URL) would be very useful.

If these operational considerations are in other documents, more explicit
pointers to the those documents would be fine.  If they are not, I believe
it might be useful to both expand and bring forward sections 5.2 and 6. (but
not the subsequent  6.1-6).  If those occurred as operational context after
Manifest Scope, I believe that the document would be easier to follow and
the manifests thus easier to use correctly.

regards,

Ted Hardie

Nits: