Subject: Re: [sidr] RPKI validator testing summary

From: Danny McPherson <[email-masked]>
Date: Thu, 1 Dec 2011 20:51:22 -0500

On Nov 30, 2011, at 10:38 AM, Andrew Chi wrote:

> The specs leave room for the relying party to decide what to do with imperfect but not completely invalid objects. 

Thanks for sharing Andrew.  One question and one comment...

Is an expired object "completely invalid" or just "imperfect"?  Can you 
explain the difference?

In general, I agree with you that this needs to be codified before we proceed
and I agree with Randy that "I see no reason to tolerate useless incorrectness" 
in a brand new security system expressly aimed at bringing integrity to the mix, 
integrity that is especially important in times of instability and uncertainty.

-danny

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 2 Dec 2011 11:23:21 +0100

> Is an expired object "completely invalid" or just "imperfect"?  Can you 

I think that here, the term 'stale' is preferred over 'expired'. This is not about any object type, but manifests and crls in particular..

A manifest is stale "if the current time is after the nextUpdate time":
http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-6.4

When a one-time-use EE cert is used in the manifest CMS the validity time MUST match the 'thisUpdate' and 'nextUpdate' of the manifest contents:
http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-5.1

So note that in this case the 'expired' EE cert should be considered 'stale' instead as well..

CRLs also have a 'nextUpdate' field, that's typically the same as the manifest's. Again, these are considered 'stale' not 'expired' after this time.

The reasoning is that an RP may only have old data for some reason: eg. no updates occurred due to some technical issue, or there is some problem retrieving new info. In this case it would be a bit rash to *reject* the manifests and CRLs and all objects that depend on them. This is the text in http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-6.4:

  "All signed objects at the publication point issued by the entity that
   has published the stale manifest, and all descendant signed objects
   that are validated using a certificate issued by the entity that has
   published the stale manifest at this publication point SHOULD be
   viewed as somewhat suspect, but MAY be used by the RP as per local
   policy."

Current validator implementations differ in how they treat this case:

rsynic			accepts for indefinite(?) time (warns?)*
BBN validator	accepts for indefinite(?) time (warns?)*
RIPE NCC val.	rejects

*: Andrew, Rob please comment..

We are now changing our validator to do the same as the other implementations and accept stale manifests and crls for an indefinite time, but warn about it. 

There still is something to say for not accepting 'stale' for too long. It makes an RP vulnerable to replays and defeats the idea of why the manifests and crls are there in the first place, in my opinion. So, we are thinking of adding a configuration setting at some point that allows the user to indicate something like: "accept stale for a maximum of X times the intended validity period" -- with a default of 3(?).. so: if a manifest/crl was issued with an intended 24 hour life time, accept it for another 72 hours. As a compromise between security and resilience.. I am open to better suggestions..

Note that if other objects such as CA certificates, or ROAs (by their EEs) are expired they must be rejected. The validator implementations agree on this.

> integrity that is especially important in times of instability and uncertainty.

I think corner cases exist where a publisher doesn't follow the standards strictly, but the offense is not so serious that a publication point and its descendants should be rejected altogether. For example the AIA pointer is not really needed to validate the child certificate. Incorrect key usage bits in an EE cert is another (our old code had this bug). Other current example: illegal characters in subject names. It's all incorrect, but none of these case actually make it impossible to validate a child cert. The AIA pointer is not needed when you're walking top-down, the key usage bits are an indication of allowed use, but not used to determine validity (esp. in EEs an entity issued themselves, it's not their parent allowing/disallowing some use), the subject still parses in the BBN, openssl (rsynic) and bouncy castle (our validator uses this) libraries.

So.. I would actually prefer to warn instead in cases like this.

As an implementer of publishing software I want to fix my code to not raise any of these warnings. But resource competition means that this may take time.. Therefore I think that at the very least validators should *warn* for new corner cases for some time before they start to reject. There are a number of different implementations out there and not all corner cases are covered. If validators start checking for more and more corner cases now, and reject, that would result in very flaky availability (in terms of acceptance) of the current repositories.

Having a list of all these corner cases and their agreed severity can help prevent nasty surprises.

Tim

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Dec 2011 22:53:10 +0900

> Is an expired object "completely invalid" or just "imperfect"?  Can
> you explain the difference?

the objects of concern here, namely mainifests and crls, do not expire,
they just go past their expected refresh date.

> In general, I agree with you that this needs to be codified before we
> proceed and I agree with Randy that "I see no reason to tolerate
> useless incorrectness"

are they uselessly incorrect.  if the manifest is past it's refresh
date, and names a cert C as expected at the pub point, and C is not
there, a conservative might suspect an attack which deleted C yet did
not have the private key needed to issue a new manifest.

> in a brand new security system expressly aimed at bringing integrity
> to the mix, integrity that is especially important in times of
> instability and uncertainty.

integrity is always good.  and times are always uncertain.

randy

---

From: Geoff Huston <[email-masked]>
Date: Sat, 3 Dec 2011 08:46:46 +1100

On 01/12/2011, at 2:38 AM, Andrew Chi wrote:

> 
> 2. AIA correctness.  Does res-certs require validators to reject a certificate with a messed up AIA URI, even if top-down traversal is ok?  Having clean AIAs obviously helps bottom-up validators.  But validators capable of bottom-up traversal must already defend against AIA-wild-goose-chase DoS, e.g. by limiting chase depth.  Should we encourage validators to enforce AIA correctness?

res-certs says that there  MUST be an AIA and the text says that it points to the "publication point of the immediate superior certificate". In the case where a local TA is being used (and in other conceivable cases) it is possible for multiple CAs to certify a subject. What the spec does NOT say is that the AIA must point to the publication point of all such CAs. So it appears to be within the bounds of the res-cert profile for a certificate hierarchy of the form

CA A      CA B
  |         |
  V         V
      CA C

Now if the AIA of certificates issued by CA C points to the publication point of CA A, then if you are performing a validation along the path A to C then this is NOT "messed up", and things look fine. If you are performing a validation along the path from B to C then it IS "messed up", and things look good.

So "messed up" in AIA appears to be a little bit in the eyes of the beholder rather than an objective condition.

On what grounds would a validator reject certificates issued by CA C in this example?

regards,

  Geoff

---

From: Geoff Huston <[email-masked]>
Date: Sat, 3 Dec 2011 12:44:38 +1100

> Now if the AIA of certificates issued by CA C points to the publication point of CA A, then if you are performing a validation along the path A to C then this is NOT "messed up", and things look fi…

things _do not_ look good

:-)

sorry!

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sat, 03 Dec 2011 12:44:45 +0900

so are you saying bottom up is just a no-go?

randy

---

From: Geoff Huston <[email-masked]>
Date: Sat, 3 Dec 2011 16:29:46 +1100

> so are you saying bottom up is just a no-go?

I believe I am, in that by following the AIA pointers you may be lead to places that may not match your chosen trust anchors.

This is particularly the case for those who want to set up local TAs as per some draft or another.

 Geoff

---

From: Randy Bush <[email-masked]>
Date: Sat, 03 Dec 2011 14:47:07 +0900

> I believe I am, in that by following the AIA pointers you may be lead
> to places that may not match your chosen trust anchors.

as at least one validation implementation, bbn, is bottom up, and was
done by clueful folk next to some draft or another, i suspect we need to
document this in a warning some place.

randy

---

From: Geoff Huston <[email-masked]>
Date: Sat, 3 Dec 2011 16:51:25 +1100

> document this in a warning some place.

That would be a Good Idea - I've met my personal quota of drafts and writing
assignments for this Working Group some time back, but hopefully someone will
pick this up and put the necessary caveat into the appropriate documentation
spot.

  Geoff

---

From: Andrew Chi <[email-masked]>
Date: Tue, 06 Dec 2011 11:20:00 -0500

> document this in a warning some place.

BBN's validator does have both top-down and bottom-up capability 
(currently, both run by default).  This was intended to handle any 
future use cases where a child is somehow obtained before its parent. 
As it turns out, all use cases that we've tested so far only require 
top-down.  And the bottom-up capability only leads us to old, abandoned 
data.

Note that Local TA is unaffected; that "tree" is shallow, locally 
managed, and processed in a manner that doesn't require AIAs.

As others have mentioned, bottom-up introduces complexity with (1) stray 
AIA pointers, and (2) multiple issuers if AIAs must be strict.  We have 
a countermeasure for 1, and currently we aren't strict about 2.  But if 
no bottom-up use cases ever come up, we will default the BBN validator 
to run top-down only.

-Andrew

---

From: Andrew Chi <[email-masked]>
Date: Tue, 06 Dec 2011 11:48:24 -0500

> managed, and processed in a manner that doesn't require AIAs.

I wrote that quickly and might have been unclear.  The AIA for every 
paracert points to the Local TA publication point.  Thus, that tree has 
height 1.  If you trust the local trust anchor, then you have already 
have it, and there's no need to "chase upward" to go looking for it.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 6 Dec 2011 17:55:05 +0100

On Dec 6, 2011, at 5:20 PM, Andrew Chi wrote:

> BBN's validator does have both top-down and bottom-up capability (currently, both run by default).  This was intended to handle any future use cases where a child is somehow obtained before its parent. As it turns out, all use cases that we've tested so far only require top-down.  And the bottom-up capability only leads us to old, abandoned data.
> 
> Note that Local TA is unaffected; that "tree" is shallow, locally managed, and processed in a manner that doesn't require AIAs.
> 
> As others have mentioned, bottom-up introduces complexity with (1) stray AIA pointers, and (2) multiple issuers if AIAs must be strict.  We have a countermeasure for 1, and currently we aren't strict about 2.  But if no bottom-up use cases ever come up, we will default the BBN validator to run top-down only.

Our command line validator supports ad-hoc bottom-up validation at this time, meaning:
- it will follow the AIA pointers up to a self-signed cert, the FIRST rsync pointer is used.
- insist that the self-signed cert matches (one of) your chosen trust anchor(s)
- perform a top-down validation for this chain only

But it needs some work. We are thinking of this:
- from the next release of our validator we will start supporting doing top-down validation, and most importantly re-validation, as a background service
- when asked to do bottom-up validation (in a future release):
	- we check if we have seen an exact binary match for the object content from a previous top-down run
	- if not we follow pointers up and fetch missing certificates until we find a pointer to something in our cache
	- I would define a match as a CA certificate with the correct subject (matching issuer) and public key, publication point may differ
	- The big assumption here is that people use unique key pairs, but I should hope that's a safe bet

I think bottom-up validation has a use for manual validation of objects that disappeared from the rpki (but may still be valid). And possibly in future for other (non-sidr even) object types that an address holder may not necessarily want to publish in the global rpki, but send directly to any RP for validation instead. In that case, assuming a CMS is used with an embedded EE with an AIA pointer to the normal CA cert for this holder, it's just one hop up into the 'known territory'.

Tim

---

From: Andrew Chi <[email-masked]>
Date: Fri, 09 Dec 2011 10:25:23 -0500

On 12/6/2011 11:55 AM, Tim Bruijnzeels wrote:
> And possibly in future for other (non-sidr even) object types that an address holder may not necessarily want to publish in the global rpki, but send directly to any RP for validation instead.

Let's clarify the terminology.

1. Certification path validation is always top down (rfc5280)
2. Path *discovery* is not covered by rfc5280.

AIA is for #2, discovery.  Based on the preceding discussion, the global 
rpki appears to need only top-down discovery(?).  Tim has given an 
example where bottom-up discovery could be useful -- data sent directly 
to an RP rather than published in the global rpki.

-Andrew