[secdir] SECdir review of draft-ietf-sidr-rpki-manifests ( and Stephen Farrell's Discuss on draft-ietf-sidr-rpki-manifests-10)

Geoff Huston <gih@apnic.net> Thu, 05 May 2011 04:45 UTC

Return-Path: <gih@apnic.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 18685E06C0; Wed, 4 May 2011 21:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.048
X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mDJRgp+cPasx; Wed, 4 May 2011 21:45:12 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE7AE06AE; Wed, 4 May 2011 21:45:11 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2F010B689A; Thu, 5 May 2011 14:45:04 +1000 (EST)
From: Geoff Huston <gih@apnic.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 05 May 2011 14:43:45 +1000
Message-Id: <7A33AE35-5B39-466E-BF31-28BFD36081C5@apnic.net>
To: Nico Williams <nico@cryptonector.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: sidr-chairs@tools.ietf.org, secdir@ietf.org, draft-ietf-sidr-rpki-manifests.all@tools.ietf.org, The IESG <iesg@ietf.org>
Subject: [secdir] SECdir review of draft-ietf-sidr-rpki-manifests ( and Stephen Farrell's Discuss on draft-ietf-sidr-rpki-manifests-10)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2011 04:45:14 -0000


Thanks for your review. Below are replies to the non-trivial comments
(i.e., comments other than editing and reference versions):

> A summary of my comments is:
> - Text on versioning of the manifest ASN.1 would be useful.
> - Handling of boundary conditions on manifest validation could use some
>  improvement, such as regarding clock skew.  See specific comments
>  below.
> - Some "SHOULDs" could use some additional commentary regarding when
>  an implementation might act otherwise.
>> 2.  Manifest Scope
>>   [...] >
>>   Where an EE certificate is placed in the Cryptographic Message Syntax
>>   (CMS) wrapper of a published RPKI signed object
>>   [ID.sidr-signed-object] there is no requirement to separately publish
>>   the EE certificate in the CA's repository publication point.
>>   [...]
> Any guidance on when to place EE certs in CMS wrappers and when not to?


The answers are "always" and "never" in that order. The general format 
and top-level processing for all such RPKI signed objects is specified in
draft-ietf-sidr-signed-object. The text in the draft is less than clear
in such guidance, and the following text is proposed in its place:

  "Every RPKI signed object includes, in the Cryptographic Message
   Syntax (CMS) [RFC3370] wrapper of the object, the EE
   certificate used to verify it [ID.sidr-signed-object].
   Thus there is no requirement to separately publish that 
   EE certificate at the CA's repository publication point."

>> 4.2.  eContent
>>   The content of a Manifest is defined as follows:
>>     Manifest ::= SEQUENCE {
>>      version     [0] INTEGER DEFAULT 0,
>>      manifestNumber  INTEGER (0..MAX),
>>      thisUpdate      GeneralizedTime,
>>      nextUpdate      GeneralizedTime,
>>      fileHashAlg     OBJECT IDENTIFIER,
>>      fileList        SEQUENCE SIZE (0..MAX) OF FileAndHash
>>      }
>>    FileAndHash ::=     SEQUENCE {
>>      file            IA5String,
>>      hash            BIT STRING
>>      }
> IA5String?  Not UTF8String?  What goes into file naming?


The authors asked the implementors and the likely users, including the
RIRs, and nobody saw a need to support UTF-8 characters for file names.
So the authors went with a simpler character set. If one supported UTF-8
here, one would incur a lot of potential complexity in UIs and there
might be problems with other software.

>> 4.2.1.  Manifest
>>   The data elements of the Manifest structure are defined as follows:
>>   version:
>>      The version number of this version of the manifest specification
>>      MUST be 0.
> Some text on how versioning is intended to be used would be nice.
> Specifically, how might extensions be added?  Or perhaps extensibility
> here is seen as unnecessary?


This question is not clear. When a new version of the manifest
specification is created, the version number of the new manifest
specification will change. A new version of the manifest specification
is the intended way of accommodating future extensions or changes to the
manifest specification. The text referring to version 0 refers to this
particular specification. Presumably the first update to this
specification will have a version number of 1.

> If extensibility is inteded to be done by turning the version field of
> the above SEQUENCE into a CHOICE then say so -- implementors with
> sufficiently capable ASN.1 compilers and runtimes may prefer to modify
> the above to use an extensible CHOICE.


I am advised by a co-author of this draft that the version number syntax
cited here is precisely what is used in most PKI objects, e.g.,
certificates and CRLs, and that CHOICE is not needed here either.

> In general I would much prefer that we make use of ASN.1's explicit
> extensibility features (namely, the extensibility marker in SEQUENCEs,
> SETs, and CHOICEs) and/or typed-holes as appropriate.


The specification is following the CMS syntax model, to first order, as
the Manifest data structure places this data inside a CMS wrapper. The
authors Do not see much incremental benefit to the stylistic approach
you suggest.

>>   manifestNumber:
>>      This field is an integer that is incremented each time a new
>>      manifest is issued for a given publication point.  This field
>>      allows an RP to detect gaps in a sequence of published manifests.
>>      As the manifest is modeled on the CRL specification, the
>>      ManifestNumber is analogous to the CRLNumber, and the guidance in
>>      [RFC5280] for CRLNumber values is appropriate as to the range of
>>      number values that can be used for the manifestNumber.  Manifest
>>      numbers can be expected to contain long integers.  Manifest
>>      verifiers MUST be able to handle number values up to 20 octets.
>>      Conforming Manifest issuers MUST NOT use number values longer than
>>      20 octets
> Why not write that MAX value explicitly in the constraint for this
> field?  (Because it's a fairly long number?)


We could put in a MAX here, consistent with the 20 octet limit in the
comment, but it is a BIG number. This is a style response, and the
authors have obviously Preferred the style of describing the maximum
value by the maximum octet length of the value.

>> 5.1.  Manifest Generation Procedure
>>   6.  In the case of a key pair that is to be used only once, in
>>       conjunction with a "one-time-use" EE certificate, the private key
>>       associated with this key pair SHOULD now be destroyed.
> Any reason not to make this SHOULD a MUST?  Any guidance as to when one
> might not heed this SHOULD?


One-time use certificates are a recommended implementation strategy, but
are not mandated here. There was the view that the issuer's practices
with respect to key management and destruction are appropriately
described in the Certification Practice Statement. However changing a
SHOULD to a MUST is reasonable in any case, and this change will be made
to the document.

>> 5.2.  Considerations for Manifest Generation
>>   A new manifest MUST be issued on or before the nextUpdate time.
> Well, a new manifest must be published on or before the nextUpdate time.
> Since RPs clocks will have some skew, new manifests should really be
> published some time ahead of the nextUpdate time.  A few seconds or
> minutes will do.  See comments on section 6.2.


We'll change this to “issued and published.”

> What happens if an authority fails to publish a new manifest in a timely
> fashion?  This would surely be an important operational consideration...


Failure to publish a new manifest in a timely fashion will cause RPs to
treat the manifest as stale, as discussed in the later sections.

>>   2.  To verify completeness, an RP MAY check that every file at each
>>       publication point appears in one and only one current manifest,
>>       and that every file listed in a current manifest that is
>>       published at the same publication point as the manifest.
> See comment on (4) below.
>>   3.  Check that the current time (translated to UTC) is between
>>       thisUpdate and nextUpdate.
>>       If the current time does not lie within this interval then see
>>       Section 6.4, but still continue with the following tests.
> This appears to be in conflict with (1) above.  The manifest can't be
> valid if the current time does not fall in the manifest's validity
> period, so what's the point in continuing?  I suppose I'll find out when
> I get to section 6.4!
>>   4.  Verify that listed hash value of every file listed in each
>>       manifest matches the value obtained by hashing the file at the
>>       publication point.
>>       If the computed hash value of a file listed on the manifest does
>>       not match the hash value contained in the manifest, then see
>>       Section 6.6.
> Will the RP need to check every file?  Why not just those that are of
> interest?


Except during algorithm transition every file at a pub point is assumed
to be of interest to every RP. During algorithm transition, an RP might
skip pub points that hold objects that are signed under a new algorithm
that the RP doesn’t yet possess. But, that doesn’t change the
per-pub point behavior described here.

>>   For each signed object, if all of the following conditions hold:
>>       [...]
>>   then the RP can conclude that no attack against the repository system
>>   has compromised the given signed object, and the signed object MUST
>>   be treated as valid.
> No scope for local policy exemptions to the above MUST?


Not at this level of validity checking. The signed objects are subjected
to additional checks that are object-specific (encompassed by the text
you elided that includes the constraint "the signed object is valid").
The manifest check adds the additional constraint that "and the issuer
of the signed object has a current intention that this is publically
accessible via its publication". To remove ambiguity here we'll add
"valid (relative to manifest checking)." to that sentence.

>> 6.2.  Missing Manifests
>>   The absence of a current manifest at a publication point could occur
>>   due to an error by the publisher or due to (malicious or accidental)
>>   deletion or corruption of all valid manifests.
>>   When no valid manifest is available, there is no protection against
>>   attacks that delete signed objects or replay old versions of signed
>>   objects.  All signed objects at the publication point, and all
>>   descendant objects that are validated using a certificate at this
>>   publication point SHOULD be viewed as suspect, but MAY be used by the
>>   RP, as per local policy.
> I wonder if we shouldn't have a latestNextUpdate field specifying a time
> past which RPs MUST NOT accept expired manifests.  Alternatively, local
> policy ought to specify how old an expired manifest may be accepted,
> with RECOMMENDED guidance as to what that maximum age should be.


In the case of manifests with single use EE certificates, then the EE
certificates notafter time coincides with the nextUpdate time of the
Manifest (5.1, point 2), ergo there is no possibility of having a stale
Manifest that is still valid if using a single use EE certificate.

In the case of sequential use EE certificates to sign a manifest there
is the potential to have stale manifests that are still valid in terms
of the validity times of the EE cert. Section 6.4 describes the
operational warnings that should be generated if a stale manifest is
used in this fashion.

> Additionally, CA operators should get guidance to publish new manifests
> somewhat sooner than the expiration of current manifests being replaced
> so as to have some time to cope with operations failures during manifest
> generation and publication.


The guidance to operators is in section 5.2:

"A new manifest MUST be issued on or before the nextUpdate time."

See the final comment about operational considerations and the RPKI
distributed repository framework on the more general topic of
operational considerations.

>>   The primary risk in using signed objects at this publication point is
>>   that a superseded (but not stale) CRL would cause an RP to improperly
>>   accept a revoked certificate as valid (and thus rely upon signed
>>   objects that are validated using that certificate).  This risk is
>>   somewhat mitigated if the CRL for this publication point has a short
>>   time between thisUpdate and nextUpdate (and the current time is
>>   within this interval).  The risk in discarding signed objects at this
>>   publication point is that an RP may incorrectly discard a large
>>   number of valid objects.  This gives significant power to an
>>   adversary that is able to delete a manifest at the publication point.
> I.e., there's a trade-off between DoS and more severe attacks.  However,
> we can't protect against DoS attacks here anyways, so might as well give
> guidance in preference of protecting against the other attacks.


There is a distinction to be drawn here between a standard specification
and the minimal set of operational criteria to ensure the secure
operation of the specification and the broader topic of operational best
practices and various potential actions operators may take to mitigate
some forms of attack and the potential trade-off such mitigations may
entail. But such considerations are not comfortably positioned in a
standard specification. The WG draft draft-ietf-sidr-origin-ops
is one that the WG intends to hold operational considerations for the
operation of the RPKI, and it is perhaps more appropriate that such 
more general topics of operational best practices site within that
document rather than be dispersed within various standard specification

> Additionally, guidance to interleave new manifest publication such that
> there's enough time to cope with operations failures and DoS attacks
> should help.


I am confused by what is meant by "interleave new manifest publication".

I am tempted, inter alia, to refer to the previous comment relating to the
distinction between a standard specification and an operational practice

>>   Regardless of whether signed objects from this publication are deemed
>>   fit for use by an RP, this situation SHOULD result in a warning to
>>   the effect that: "No manifest is available for <pub point name>, and
>>   thus there may have been undetected deletions or replay substitutions
>>   from the publication point."
> I imagine this isn't a MUST because of log squelching considerations.
> Right?


And the authors are considerate of minimizing mandatory requirements 
to those that are strictly necessary as distinct from those that 
are strongly desirable.

>>   In the case where an RP has access to a local cache of previously
>>   issued manifests that are valid, the RP MAY use the most recently
>>   previously issued valid manifests for this RPKI repository
>>   publication collection in this case for each entity that publishes at
>>   this publication point.
> Subject to the same considerations, surely.


I believe that this is reasonably inferred from the text and further
elucidation is not necessary.

> Any advice as to when to poll for new manifests ahead the current,
> cached manifest's nextUpdate?


This does not make a lot of sense when referring to manifests in isolation 
from the RPKI distributed repository publication structure and the actions
of relying party actions. Again, the referral to an operational
best practices draft being studid by the SIDR WG is appropriate here.

>> 6.4.  Stale Manifests
> My comments on section 6.2 apply here as well.


As does the response

>>   Note that there is also the potential for the current time to be
>>   before the thisUpdate time for the manifest.  This case could be due
>>   to publisher error, or a local clock error, and in such a case this
>>   situation SHOULD result in a warning to the effect that: "A manifest
>>   found at <pub point name> has an incorrect thisUpdate field.  This
>>   could be due to publisher error, or a local clock error, and
>>   processing for this publication point will continue using this
>>   otherwise valid manifest."
> This can also happen due to having a slow clock on the RP or a fast
> clock at the CA, or both.  Clock skew is hardly an error, since there
> will always be some skew, even if only on the order of nanoseconds in
> the case of good hardware setup with good time distribution mechanisms
> and good hardware time sources.  A bit more text (any!) regarding clock
> skew would be useful.


It is a good point, but I worry that it may be inappropriate to bury
general considerations about validity and clock skew in the RPKI in the
document specifically describing manifests.

I would prefer to see this operational consideration about using the RPKI 
and clock skew be placed in a document that considered operational practices
and the RPKI, as referred to above.

kind regards,