Subject: [sidr] draft-ietf-sidr-keyroll-05 "staging period" is in the wrong place

From: Rob Austein <[email-masked]>
Date: Mon, 06 Dec 2010 18:41:04 -0500

I attempted to raise this issue at IETF 78 (sic), but it's still in
the draft.  Sorry for not having been more annoying about this. :)

The case for why we need the "staging period" is pretty much
non-existent.  There's an assertion that we need it, and a vague
comment in section 2 suggesting that somebody somewhere has a worked
example of a validator that will break without this, but I see no
strong case made anywhere in the document.  If somebody has such a
validator, and wants to 'fess up to it and explain why this is not
just a case of the validator being broken, go for it, but as following
the proposed process would require some not completely trivial changes
to running code in the case of at least one implementation (mine), I
think we need more justification than what I see in the doc now.

Consider what would happen if, instead of following the process
mandated by this document, a CA simply started issuing new
certificates and reissuing old ones as fast as it reasonably could
under the "NEW CA", until it had managed to overwrite everything
issued by the "OLD CA".  What terrible thing happens as a result of
this?  I have running code that has operated this way for several
years in test environments, and if there have been any failures as a
result of this, they've been subtle enough to escape notice.

So I don't see the need for the staging period here at all, but if
there is a need, the doc needs to be a lot clearer about it, so that
even I can understand it.

The other thing that I find interesting here is that there is *no*
delay mandated in the case where I think there might really need to be
one: how long to wait after reissuing and publishing all of the CA's
products under NEW CA before asking CA's parent to revoke OLD CA.
This interval seems much more likely to matter, because the place
where we're most likely to be screwed by caching somewhere out there
is old subordinate certificates issued by OLD CA, not OLD CA itself.

Given these (linked) issues, I don't think this doc is ready yet.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 07 Dec 2010 11:19:22 +0100

> even I can understand it.

If I remember correctly I think Roque and Steve mentioned that CA 
certificates on any level may be used by RPs as a Trust Anchor -- even 
if you did not plan to make yourself available as a TA (i.e. publishing 
your cert info as per TA draft). The staging period was introduced to 
give RPs down the chain from you at least some opportunity to notice the 
change and start using the new cert in place of the old one..

But as I said, if I remember correctly.. maybe Roque or Steve can 
comment on this?

> is old subordinate certificates issued by OLD CA, not OLD CA itself.

First of all just for reference: our current implementation of the key 
roll does not automatically revoke the old key (yet). We keep the old CA 
cert, manifest and CRL around. It no longer publishes anything else, but 
we are thus able to revoke previously issued stuff that may still be 
alive out-of-band. Revocation is, for us, still a manual step that may 
be done eg when we suspect a problem with the key. We planned to change 
this when the key roll draft is final.

Having said that..

I don't really object to having a staging period here, but it may not 
help. Out of band / cached subordinate validation may still fail because 
the subordinate no longer appears on the new manifest for OLD CA; it's 
published by new CA.

Case 1: top-down validation and caching

The assumption here is that when the new CA certificate is fetched the 
RP will also fetch the CRL, manifest and all issued certificates and 
objects for this new CA cert. This would mean that your cached 
certificates issued by OLD CA would be replaced.

So I guess the big question is: is this a safe assumption to make? Or 
maybe even: should there be a normative statement somewhere that RPs 
SHOULD do this?

Or maybe even.. non-normative, just operational: should RP tools that 
use caching be smart in this case? And before rejecting a cached 
subordinate because its parent is revoked try to re-fetch?

Case 2: bottom-up (use signed objects out of band)

If we need to support the case for out-of-band use of subordinate 
certificates and objects for as long as possible. And RPs do not care 
about manifest validation in this case.. then it might be good to keep 
the OLD CA around until everything issued under it is either expired or 
revoked; unless there is an overriding reason to revoke OLD CA like key 
loss or compromise.

But is there really a use case for this? My impression was that there 
wasn't and everything is top-down oriented. And that's why I didn't 
resist having the revoke step. If there *is* a use case for out-of-band 
support for as long as possible then the model that we have currently 
implemented may be useful.

Regards

Tim

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

---

From: Rob Austein <[email-masked]>
Date: Sun, 12 Dec 2010 13:36:50 -0500

> change and start using the new cert in place of the old one..

I am far from certain that I buy this argument (and yes, I understand
that you're trying to recount it from memory, not necessarily
advocating it).  Every RPKI operator in the world must be *required*
to publish keys using new certs for 24 hours just in case some
stranger somewhere happens to be constructing trust anchors using
their certs?

To be clear: I do not object to *allowing* prepublication of certs
using new keys, there are scenarios where it makes a lot of sense (eg,
having a new key out there all ready to use so one can roll quickly in
the event of a key compromise).  It's putting this in as a hard
*requirement* imposed on every RPKI operator that bothers me.

> But as I said, if I remember correctly.. maybe Roque or Steve can 

And, even if the WG buys this argument, it would need to go in the
draft.

As for why I think there may be a need for some kind of staging (or,
at least, a need for the absence of a hard requirement for immediate
revocation of OLD CA after reissuing all subordinates under NEW CA):
think about network partitions.  In particular, think about network
partitions that leave the publication point holding the CRL covering
OLD CA itself reachable while leaving the publication point for OLD
CA's and NEW CA's subordinates unreachable.  RP wants to continue
using cached copies of subordinates issued by OLD CA, since RP can't
reach the new subordinates issued by NEW CA -- but OLD CA has been
revoked.  Oops.  Thud.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 13 Dec 2010 16:47:33 +1100

> stranger somewhere happens to be constructing trust anchors using

In my opinion is that the answer to your question is yes, and no.

Yes, in this document every RPKI _CA_ operator in the world is *required* to publish keys using new certs for a "staging period" (>= 24 hours) before using this CA to publish this CA's subordinate products.

No, this is not directly related to trust anchors.

> *requirement* imposed on every RPKI operator that bothers me.

On the other hand, as I understand it, the staging period is intended to catch relying parties that fall out of sync with the distributed repository publication process, and manage to gather a new CA cert, but not collect the new subordinate set of products (maybe they are using some form of local repository cache synchronisation that uses some custom synchronization algorithm). This anomalous situation will of course be suboptimal for the RP given that the set of subordinate products is no longer able to the validated using the NEW CA. The staging period specified in the draft for the NEW CA is intended to minimize the deterimental impacts of this lack of synchronisation between producer and consumer.  As I recall, no specific algorithm is specified as mandatory for an RP to use in terms of the manner by which the local repository cache is synchronized against the distributed repository publication system, with a logical inference that no particular RP repository synchronization behaviour can be assumed to be used uniformly by all RPs.

> And, even if the WG buys this argument, it would need to go in the

The draft considers keyroll for CAs. To the extent that a TA is a CA, this document covers TAs only by virtue of that level of indirection. To the extent that the TA may have some additional requirements regarding use of keys, this document does not encompass that. Maybe the TA draft is the appropriate place to consider what particular requirements one may want to place on a TA key rollover, bearing in mind that the TA's key fingerprint may have already been widely circulated using more persistent media.

> reach the new subordinates issued by NEW CA -- but OLD CA has been

One of many oops thud opportunities in a distributed repository scheme where there is rollover and update of individual components of the distributed system. The algorithm described in this document assumes a repository overwrite procedure of NEW over OLD for the subordinate products, hence the desire to avoid a THUD opportunity by requiring that the immediate superior CA publish the NEW CA certificate well in advance of publishing the subordinate products of the CA.

The old CA could be kept around, as distinct from the draft's advice to generate a revocation request "without and intervening delay" between publication of the subordinate products of the NEW CA and this revocation request, but what is the appropriate delay to make as a minimum *requirement*? What about a CA that encounters key compromise? If they have been prudent and already published a NEW CA, then rollover from OLD to NEW CA can be effectively performed immediately. But if this draft then *requires* the compromised old key to continue to exist for a period prior to revocation, then how does this continued existence of a CA with a compromised key add to the overall robustness of the system?

I suspect that there are a number of trade-offs in this environment, and the algorithm described in the draft represents one such set of trade offs. There are others, as you have pointed out in your note, but I am personally not convinced at this point that the alternative approach you describe here offers a net gain to both CAs and RPs.

regards,

  Geoff