Subject: [sidr] staging period discussion

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Feb 2011 19:41:41 -0500

I concur with Geoff re the desirability of the staging period.  I 
disagree with Rob's suggestion that the staging period is at the 
wrong place in the document, or in the phased approach to key 
rollover.

 From my perspective, the fundamental rationale for the staring period 
is two-fold:

	-  we want a delimited interval after which a CA can have 
reasonable confidence that all RPs will have retrieved the new CA 
key, before transiting to a new CA key and subordinate, signed 
products.

	- we also want a delimited interval for RPs so that they can 
acquire a new CA key prior to the transition to that key for 
subordinate signed products.
Because of the naming conventions adopted by the repository design, 
most of these new products overwrite old ones, so we want to maximize 
the likelihood that an RP gets a consistent set of data.

I agree with Rob that there is no delimited period that will 
guarantee that both CAs and RPs are in sync re a CA key transition. 
But, that does not mean that we ought not select and publish such a 
period, consistent with the other time intervals that we have 
published, e.g., the frequency at which RPs SHOULD query the 
repository.

As a compromise, we could re-phrase the staging period discussion to 
RECOMMEND a 24-hour minimum (vs. using MUST here), if the WG (not 
just you, Rob, :-)) feels strongly.

I also agree that, as Roque noted, in the case of an emergency rekey, 
the 24-hour staging period may be inappropriate. But an emergency 
rekey is not the same as a planned key rollover.  I suggest that we 
note this difference up front and say that, in case of an emergency, 
the CA re-issuing the cert which is being re-keyed SHOULD consider 
the impact on routing of a quicker transition to a new cert+key, and 
behave as it sees fit, given the circumstances surrounding the rekey.

Geoff, would you be comfortable with this rewording for emergency 
rekey, and with the MUST->RECOMMEND, if Sandy determines that there 
is WG consensus for that change?

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 9 Feb 2011 17:13:34 +1100

On 09/02/2011, at 11:41 AM, Stephen Kent wrote:

> I concur with Geoff re the desirability of the staging period.  I disagree with Rob's suggestion that the staging period is at the wrong place in the document, or in the phased approach to key rollover.
> 
> From my perspective, the fundamental rationale for the staring period is two-fold:
> 
> 	-  we want a delimited interval after which a CA can have reasonable confidence that all RPs will have retrieved the new CA key, before transiting to a new CA key and subordinate, signed products.
> 
> 	- we also want a delimited interval for RPs so that they can acquire a new CA key prior to the transition to that key for subordinate signed products.
> Because of the naming conventions adopted by the repository design, most of these new products overwrite old ones, so we want to maximize the likelihood that an RP gets a consistent set of data.
> 
> I agree with Rob that there is no delimited period that will guarantee that both CAs and RPs are in sync re a CA key transition. But, that does not mean that we ought not select and publish such a period, consistent with the other time intervals that we have published, e.g., the frequency at which RPs SHOULD query the repository.
> 
> As a compromise, we could re-phrase the staging period discussion to RECOMMEND a 24-hour minimum (vs. using MUST here), if the WG (not just you, Rob, :-)) feels strongly.
> 
> I also agree that, as Roque noted, in the case of an emergency rekey, the 24-hour staging period may be inappropriate. But an emergency rekey is not the same as a planned key rollover.  I suggest that we note this difference up front and say that, in case of an emergency, the CA re-issuing the cert which is being re-keyed SHOULD consider the impact on routing of a quicker transition to a new cert+key, and behave as it sees fit, given the circumstances surrounding the rekey.
> 
> Geoff, would you be comfortable with this rewording for emergency rekey, and with the MUST->RECOMMEND, if Sandy determines that there is WG consensus for that change?

sure!

  Geoff

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 17 Feb 2011 16:10:47 +0100

Hi,

> Geoff, would you be comfortable with this rewording for emergency rekey, and with the MUST->RECOMMEND, if Sandy determines that there is WG consensus for that change?

+1.

Roque.

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

---

From: Rob Austein <[email-masked]>
Date: Fri, 18 Feb 2011 09:04:20 +0800

> key, before transiting to a new CA key and subordinate, signed 

I have no problem with -allowing- a CA to wait for a staging interval
here.  I do still object to -requiring- every CA to wait for a staging
interval here.

> subordinate signed products.

Not at all obvious.  So long as the new CA key is published before the
subordinate signed product, either it just works or you're into the
grey area of loose consistency, where there are so many ways to lose
that it's almost not worth trying to enumerate them.  The net could
partition.  One of the rsync servers could be down.  Your clock could
be wrong.  Etc ad nausium.

> the likelihood that an RP gets a consistent set of data.

You appear to be assuming a model in which an RP discards old good
data before fetching new bad data, thus potentially shooting itself in
the foot whenever anything changes.  Perhaps instead one just ought
not to write one's validator that way :)

Part of my issue (raised explicitly in an earlier message, not sure if
you saw it) is that the justification for the staging period in the
draft is very weak, and needs to be rewritten to fix this (if you can)
before publication.  In essence, it starts with the bad assumption
that perfect consistency is possible, even though we know (long
mailing list discussion) that it is not, then justifies the staging
period by saying that we must maintain consistency for the benefit of
hypothetical validators that operate in strange ways that require it.
Given that, as far as I know, none of the existing validators do
require this of consistency (and given that, as noted, such
consistency is not even possible), this does not make much sense.

> published, e.g., the frequency at which RPs SHOULD query the 

If I believed in the need for the staging period, I would agree with
this.

> just you, Rob, :-)) feels strongly.

I would strongly prefer MAY to either MUST or SHOULD here.   That
said, I would strongly prefer SHOULD to MUST. :)

Part of my issue, of course, is that I already have running code which
does not follow the model you're trying to mandate here, and I am
reluctant to change it to suit an ex post facto specification absent
stronger justification than you've provided so far.  As far as I have
been able to determine, what I have now works just fine, and the
changes you're trying to mandate would require not just code changes
but some additional complexity in the internal management operations.
Right now I have two operations related to key rollover:

1) Generate a new key, ask parent to issue new cert, deprecate (but
   continue to maintain) old key and cert, and start issuing new
   product with new key and cert until everything relevant has been
   reissued.

2) Revoke all deprecated keys and certs.

If I accept your changes, I not only need to add a third operation
(start using the new key and cert), I also need to make names for the
pesky things visible in the control protocol, expose those names in
the user interface, etc, because somebody might restart the rollover
operation during the staging period.  Whole collection of new ways for
operator to get confused and shoot self in foot, to no gain that I can
see, because you still haven't convinced me that the staging period is
necessary in the first place.

> behave as it sees fit, given the circumstances surrounding the rekey.

So code has to be capable of carrying on without waiting for the
staging interval.   Good.

---

From: Randy Bush <[email-masked]>
Date: Fri, 18 Feb 2011 09:44:27 +0800

> be wrong.  Etc ad nausium.

this way lies breakage.  is this new way to get things wrongly really
needed?

> the foot whenever anything changes.

the rp code in the routers goes the complete opposite way.  if it has
good data, those data are kept until new good data are completely
fetched and assured.  a router can even peer with multiple sources and
hang on to 42 copies of good data.

> perfect consistency is possible

and cash could fall from the sky.  sure it is possible.  and so is
brownian motion moving all the air molecules in the room into one
corner.

> said, I would strongly prefer SHOULD to MUST. :)

i do not see how the router rps can deal with SHOULD.  maybe MIGHT.  or
modify 2119 to add BLUE MOON.

randy

---

From: Roque Gagliano <[email-masked]>
Date: Fri, 18 Feb 2011 11:38:06 +0100

Hi Rob,

Just to clarify my position. 

I believe that the emergency roll-over is one use case where MUST would not apply. I checked some existing CPS to see what do they say about Emergency rekeying, the only mention that I could find was in the case or RIPE's CPS that mentions that an emergency re-keying of their off-line trust anchor was performed but not mention to the process utilized.

Referring to replace it with SHOULD or MAY, I believe that pre-publishing keys is a good practice. However, you have a point that if the staging period is made completely optional, you are not "breaking" RP softwares and consistency in the database across different RP is impossible to be enforced. One more issue to consider is that, if you look again to what the current CPSes are saying (i.e. LACNIC CPS section 4.7.6), you already have one business day delay since the moment that the re-keyed certificate was generated until the time that the re-keyed certificate shows up in the repository. If you do not have a staging period, you are facing the problem of starting resigning objects without your re-keyed certificate been published yet.

In your email email back in Dec, 7th you proposed: "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".

A compromise could be to make the staging period a MAY and add text that  states what factors should be consider when defining "reasonably could". 

Cheers,
Roque.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 18 Feb 2011 14:18:35 +0100

Hi All,

my 2 cents with the implementation of our 'rpkid' and (ad-hoc, not-yet-caching) validator in mind..

> here.  I do still object to -requiring- every CA to wait for a staging

right and as stated elsewhere in case of an emergency roll the interval may be zero.

> be wrong.  Etc ad nausium.

I am in two minds about this:

1) I think in case of a *planned* roll-over the staging period may help

Though I agree it's not guaranteed to give 100% consistency as mentioned by Rob, I also believe that for the two reasons phrased by Steve it's the best the publication side can do to try and prevent issues that RPs may encounter.

otoh:
2) For anything less than MUST, the RP software SHOULD be able to deal with no staging period in case of emergency rolls

I have some ideas about defensive coding to detect possible scenarios like this and re-fetch, or make sure to look for a new CA cert when the old one is revoked etc, but I still doubt that all possible corner cases can tackled. I am happy to talk about possible approaches with other implementers, but I think this is probably not best discussed here in this thread.

I think the bottom line is that if the draft says no staging period for emergency rolls, as we all agree on I think, this implies that RPs have to be able to deal with this. So one might say if you can deal with this, then this should be okay for planned rolls as well... It's just that I am afraid that there is still more that can go wrong here, so I prefer to keep the staging period for *planned* rolls.

So personally I favor SHOULD...

> necessary in the first place.

To keep things reasonable we decided to restrict this to one roll-over at a time, imposed by the software. I.e. a roll-over has to be completed before a new one may be initiated.

In our case *planned* key roll-overs are managed by automated processes (when key older than 5 years) and use a 24 hour staging period. However in case of an emergency operators can force initiation of a roll-over at any other time and reduce the staging period to zero. In case of a double emergency we can do an emergency roll, and then do another.. though I sincerely hope this will never be needed ;)

> So code has to be capable of carrying on without waiting for the

+1

---

From: Stephen Kent <[email-masked]>
Date: Sun, 20 Feb 2011 12:16:13 -0500

Rob,

Your reply did not contain any info that would cause me to change my mind
about the staging period. I think we agree that the staging period cannot
guarantee that all RPs have the new CA cert before the old data is replaced.
What it can do is increase the likelihood that this will happen. 
Your position seems to be that the staging period may cause more harm 
than good.  I appreciate that notion, but disagree.

I think that changing the MUST to a SHOULD (or to RECOMMEND), and 
noting that an emergency rekey is not bound by this rule is a 
reasonable compromise. I am not willing to go with MAY; it may 
encourage bad behavior.

BBN does not produce CA/repository management code, so we are not 
arguing from a position of not wanting to change our code.  We are 
arguing from a position of trying to minimize the likelihood of RP 
confusion.

Your description of how your CA code works omits a few details.  For 
example, in step 1, when you start issuing new signed products, these 
replace the old products, because of the naming conventions employed 
in the repository. Thus you seem to be creating a mixed 
(inconsistent) set of repository entries during this step.  The 
staging period, as described in the keyroll doc, provides more detail 
about this process, and shows how to minimize the window of 
inconsistency. That strikes me as a fundamentally good thing to do.

I acknowledge that offering an option to restart the rollover during the
staging period add complexity.  But, there is also added complexity 
for RPs who have to deal with repository fetches that yield a mix of 
old and new signed products. Saying that an RP will have to deal with 
this issue in some cases does not mean that we ought not try hard to 
minimize the frequency with which RPs have to do so. This seems 
especially true since we seem to lack a good description of how an RP 
should deal with this problem. I have seen no algorithmic description 
of how an RP is supposed to deal with repository inconsistency. Not 
even heuristics.)

Steve

P.S.  BTW, no, our RP code does not discard old data before getting new data.
Has your validator stopped beating its database :-)?