Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Oct 2011 09:59:22 -0400

At 5:31 AM -0700 10/31/11, Terry Manderson wrote:
>On 31/10/11 8:57 PM, "Stephen Kent" <[email-masked]> wrote:
>
>>  At 7:18 PM -0700 10/30/11, Terry Manderson wrote:
>>
>>  We have included dates for alg start an EOL because they affect all
>>  RPs, and we want to make life predictable for RPs. Also, because the
>>  WG agreed that alg transition will be top-down (to avoid geometric
>>  growth in the repository system), it is necessary to set alg
>>  transition dates, for the benefit of
>>  CAs as well.
>>
>
>I understand why you want to, but don't come to the same conclusion as to
>the mechanism.
>
>Is that really the IETF's job?

SIDR was tasked by the SEc ADs to develop an alg transition architecture.
The authors believe that uniform milestones are necessary as part of 
a credible plan.

>Is there prior art in the IETF where this has been done in such a date
>specific manner?

Not sure.

>  >> [1] I would think that as soon at the document is updated and 
>published they
>>>  are able to be used.
>>
>>  The top tier CAs have to be ready to issue certs under the new alg before
>>  any lower tier CAs can do so, so we need a set date, agreed upon, in
>>  the future,
>>  to start the transition.
>
>Call me a dirty rotten cynic but I just don't see this operational aspect of
>one or more running RPKI hierarchies as part of the IETF. Although you can
>prove me wrong, and I'll concede to an already enacted example where dates
>were set for some artifact.

We have to have two, parallel hierarchies to avoid a flag day. This 
is not a situation where every CA can decide, locally, when to 
transition, because the the alg change affect ALL RPs.

>  > We want to encourage RPs to verify their ability to use the new Suite, but
>  > we also realize that, during transition, there may be problems. So,
>>  we RECOMMEND use of Suite B, but require that if either Suite works,
>>  the RP MUST accept the data as valid. That provides a fall back
>>  position in case a CA doesn't get it right.
>>
>
>In which case some clarification to the text could go a long way. I suspect
>in the effort to simplify a complex process the text became too brief.

OK.

>  >> issuance of suite C products MUST be considered invalid.
>>
>>  we can revisit this text to try to make it clearer, if others agree with
>>  your observation.
>>
>>>   Section 5.
>>>
>>>  I think some discussion of the dates, and for communicating 
>>>twilight and EOL
>>>  dates between the parent and the child should be here. I don't quite hold
>>>  the belief that it's a unidirectional downward assertion from parent to
>>>  child. In may well be in PKI - there there is a raft of operational
>>>  interaction  that surrounds that.
>>
>>  The dates for alg transition are published and accessible to
>>  everyone, so there is no need for pairwise communication of the
>>  dates. Because the alg transition affects ALL RPs, not just the
>>  children of a given CA, it is important to mandate the transitions on
>>  a global basis.
>>
>
>I'm still not with you on this - I understand that it makes life easy to say
>"the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see that
>as a step beyond what the IETF should do.

If not the IETF, then whom? The IETF (via SIDR) is the author of the 
CP. This is an extension of the CP, in many respects.

>  >> Section 6.
>>>
>>>  Can you spell out what you technically mean by "keep any relationship
>>>  between " in para 1?
>>
>>  We will revise this sentence. The text is intended to note that the
>>  data extracted from the repository, signed under each alg, are
>>  treated separately. Thus one gets a compete, valid chain of data via
>>  Suite A or Suite B, but not a mix of data under A and B. The next
>>  paragraph explains this.
>
>right, there is a discontinuous leap there that I didn't get. Clarification
>would be appreciated.

OK.

>  >> Section 7.
>  >>
>>>  Can you expand the recommendation in keeping the parallel certificate
>  >> hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4)
>>
>>  In phase 4, Suite C products MAY be present, which means that they
>>  also may be absent. So, we cannot say that the hierarchies are
>>  parallel any more.
>
>So perhaps suggest to the RP/Child CA that in the situation where a
>revocation is issued for Suite A, _if_ there are products with matching
>information for the Suite A revocation, a Suite C revocation should also be
>issued.

If my coauthors agree, I think this could be added,

Steve

---

From: Terry Manderson <[email-masked]>
Date: Tue, 1 Nov 2011 18:29:06 -0700

> The authors believe that uniform milestones are necessary as part of

Architecture, yes. Structured approach, yes. To both of those I agree.
Having the IETF define the dates when algorithms shift. I am not convinced.

> transition, because the the alg change affect ALL RPs.

We are talking years. The overlap will be significant. And I disagree - in
this case every CA has to consciously decide - there may well be a situation
that a mid term operational impact requires an important CA in the middle of
the chain to delay. That then renders all dates specified in any RFC next to
meaningless.

> CP. This is an extension of the CP, in many respects.

The IETF (via SIDR) doesn't implement the hierarchy, nor operate the CAs.

Perhaps the parent(s) and 'non-leaf' CAs should work on this and issue a
statement of transition in following RFCXXXX (this draft). I'm reasonably
sure the non-leaf CAs are capable of making noise when required ;)

As an example of flag day events, even though RFC5855 ( Nameservers for IPv4
and IPv6 Reverse Zones ) was published as an IETF document. It was left to
the various operators (root-servers, reverse-servers et al) to work on the
transition. Admittedly no change was required on the user's software. The
principle isn't that much different.

What I do like about the document is the pre-canned phases, of what happens
when, and how. This is good.. and I think that satisfies the request from
the SEC ADs, but specifying the "when" in IETF - I just don't buy.

Cheers
Terry

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Nov 2011 04:34:45 -0400

>Having the IETF define the dates when algorithms shift. I am not convinced.

An architecture that ignores the need to have a global, uniform set 
of milestones for transition phases is incomplete.

>the chain to delay. That then renders all dates specified in any RFC next to

Yes, we are talking years. No, it cannot be a local, per-CA decision, because
the transition affects all RPs. I anticipate that the stakeholders, 
CAs and RPs, will have the ability to comment on the proposed dates, 
and that the IETF/IESG will take into account these comments when 
developing the timeline. If a major problem arises that makes it 
infeasible for CAs to adhere t the timeline, a new RFC can be issued.

>The IETF (via SIDR) doesn't implement the hierarchy, nor operate the CAs.

agreed.

>sure the non-leaf CAs are capable of making noise when required ;)

See comments above re setting and revising the timeline.

>principle isn't that much different.

I disagree. Because an alg transition does impact all RPs, there is a 
big difference.

>the SEC ADs, but specifying the "when" in IETF - I just don't buy.

So, who do you propose as alternates? Your comment above about 
parent(s) and "non-leaf" CAs issuing a statement encompasses IANA, 
the RIRs, and thousands of ISPs.  When has that set of players issued 
a statement analogous to this?

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 3 Nov 2011 16:06:07 -0400

On Nov 2, 2011, at 4:34 AM, Stephen Kent wrote:

> An architecture that ignores the need to have a global, uniform set of milestones for transition phases is incomplete.

Having a model that requires independent administrative entities (the CA operators here) in the Internet to obey a traffic cop sounds a little... hard to swallow (operationally).  I also remain quite unconvinced.  I think this indicates that there is a misalignment in the design, not a problem in the above question.

> the transition affects all RPs. I anticipate that the stakeholders, CAs and RPs, will have the ability to comment on the proposed dates, and that the IETF/IESG will take into account these comments when developing the timeline. If a major problem arises that makes it infeasible for CAs to adhere t the timeline, a new RFC can be issued.

So, to make sure I understand: if operational issues arise that cause an independent administrative entity (one of the CA operators) to need to delay an operational action, they need to get an RFC published?  I must have misunderstood?

Eric

---

From: Terry Manderson <[email-masked]>
Date: Thu, 3 Nov 2011 17:49:12 -0700

> of milestones for transition phases is incomplete.

I appreciate your view Steve. And in the traditional sense you are correct,
unfortunately I think that level of completion, as a standards document,
will be the 'enemy of the good' as that flips right over into operational
space.

> infeasible for CAs to adhere t the timeline, a new RFC can be issued.

If you are that desperate to see this in play, then perhaps SIDR should
consider creating an operational BCP that provides the recommendation for
algorithms phase-in/phase-out dates. And in that comes the warning, that
IETF specified dates (except for past events) are in a very grey area WRT
the IETF.

But neither this document (in blessing the idea) nor
draft-ietf-sidr-rpki-algs (as standards track) is the place for it.

> a statement analogous to this?

Surely the ISPs would be represented by or through the RIRs?

I'm not an expert in communications between IANA/ICANN/RIRs but if they
needed to issue a statement based on stakeholder (RP) consultation for 'the
good of the internet', its likely they would.

Cheers
Terry

---

From: Stephen Kent <[email-masked]>
Date: Fri, 4 Nov 2011 04:56:51 -0400

>will be the 'enemy of the good' as that flips right over into operational

One of the initial set of SIDR RFCs is draft-ietf-sidr-rpki-algs. The 
new alg suite will be defined in a new version of that doc. I 
envisioned that this doc would also be the place where the milestones 
will be published.  But, a BCP specifying the milestones seems 
reasonable as well.

>IETF specified dates (except for past events) are in a very grey area WRT

I think the BCP idea is appropriate.  I don't agree with your gray 
area argument. Let's avoid terms like "desperate."

>draft-ietf-sidr-rpki-algs (as standards track) is the place for it.

let's just say we disagree, modulo the idea of putting the milestones in
a BCP.

>good of the internet', its likely they would.

In principle the RIRs & IANA, perhaps the NRO & IANA, would be an 
appropriate group to issue such a statement. So far, this process has 
been rocky, which is probably why there is an IAB-issused statement 
re IANA as a global TA for the RPKI. Nonetheless, this might be a 
reasonable split of responsibility, i.e., alg spec through the IETF 
process, and milestone publication via an RFC authored by the NRO and 
IANA.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 4 Nov 2011 04:45:59 -0400

Eric,

1- Yes, there is a need for global coordination for alg transition, 
under the design  presented. If you have an alternative proposal, 
please share it. This design was originally documented in June, 2010, 
in an individual I-D authored by me.  It has been briefed at several 
SIDR WG meetings, starting at IETF 78 in July, 2010. This is not new.

2- Not exactly. The milestones, as well as the alg suite spec, will 
appear in a revised version of draft-ietf-sidr-rpki-algs. Any 
operational problem that requires a delay in any transition phase 
would be brought to the attention of the IESG (if the SIDR WG is no 
longer active) requesting that a this RFC be re-issued, with new 
milestone values for the affected phase(s).

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Fri, 4 Nov 2011 10:24:14 -0400

Hey Steve,

On Nov 4, 2011, at 4:45 AM, Stephen Kent wrote:

> Eric,
> 
> 1- Yes, there is a need for global coordination for alg transition, under the design  presented. If you have an alternative proposal, please share it. This design was originally documented in June, 2010, in an individual I-D authored by me.  It has been briefed at several SIDR WG meetings, starting at IETF 78 in July, 2010. This is not new.

I can appreciate that this document represents some long standing thought and effort.  However, the fact that I believe there is a flaw does not seem to need the support of an alternate design, right?  I'm pointing out an operational misalignment in _this_ design.  I think to offer an alternative at the same time as we are discussing a shortcoming here would be an inappropriate conflation (i.e. I think that would confuse this issue with another).

So, more specifically: I think that trying to mandate global coordination at this scale is an operational non-starter.  Why can't the design be made to accommodate different choices of algorithms and different operational schedules?  I think this is actually a requirement: that operational entities be able to choose their own schedules and make their own configuration choices.

> 
> 2- Not exactly. The milestones, as well as the alg suite spec, will appear in a revised version of draft-ietf-sidr-rpki-algs. Any operational problem that requires a delay in any transition phase would be brought to the attention of the IESG (if the SIDR WG is no longer active) requesting that a this RFC be re-issued, with new milestone values for the affected phase(s).

I'm sorry, but I really think this is likely to have trouble in a real operational setting.  I don't think anyone would claim that the IETF's processes operate at the same pace as operations.  For instance, if there is an emergency at the last minute of this roll, can the working group be expected to mint a new RFC and disseminate in short order (say, days)?  There is a vey fundamental misalignment here: creating standards and managing operations are very loosely coupled.  I think this is a very inappropriate place to try to enforce operational schedules.

Eric

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Nov 2011 14:46:37 -0500

>...
>
>I can appreciate that this document represents some long standing 
>thought and effort.  However, the fact that I believe there is a 
>flaw does not seem to need the support of an alternate design, 
>right?  I'm pointing out an operational misalignment in _this_ 
>design.  I think to offer an alternative at the same time as we are 
>discussing a shortcoming here would be an inappropriate conflation 
>(i.e. I think that would confuse this issue with another).

The authors do not agree that the global coordination requirement is a flaw.

>So, more specifically: I think that trying to mandate global 
>coordination at this scale is an operational non-starter.  Why can't 
>the design be made to accommodate different choices of algorithms 
>and different operational schedules?  I think this is actually a 
>requirement: that operational entities be able to choose their own 
>schedules and make their own configuration choices.

If there is not a schedule when old algs die and new ones MUST be 
supported, then one at least doubles the size of the repository 
system, and imposes a burden on all CAs and RPs to support old algs 
forever.

>  > 2- Not exactly. The milestones, as well as the alg suite spec, 
>will appear in a revised version of draft-ietf-sidr-rpki-algs. Any 
>I'm sorry, but I really think this is likely to have trouble in a 
>real operational setting.  I don't think anyone would claim that the 
>IETF's processes operate at the same pace as operations.  For 
>instance, if there is an emergency at the last minute of this roll, 
>can the working group be expected to mint a new RFC and disseminate 
>in short order (say, days)?  There is a vey fundamental misalignment 
>here: creating standards and managing operations are very loosely 
>coupled.  I think this is a very inappropriate place to try to 
>enforce operational schedules.

I think you overstate the problem. The intervals for each phase are 
not expected to be short, and there are phases that accommodate both 
old and new als in a fashion that allows considerable CA and RP 
flexibility.

Nonetheless, I think Terry's suggestion has merit. I can imagine 
having the milestone RFC be coordinated through the NRO and IANA, and 
published by the IETF, to help ensure that there is appropriate ISP 
input to the milestone
development.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Mon, 7 Nov 2011 17:44:30 -0500

On Nov 7, 2011, at 2:46 PM, Stephen Kent wrote:

> If there is not a schedule when old algs die and new ones MUST be supported, then one at least doubles the size of the repository system, and imposes a burden on all CAs and RPs to support old algs forever.

Sorry, but I think freedom from global coordination is more than an inconvenient, or unpalatable, concept.  It is something that (afaict) has been an inherent requirement in those Internet-scale systems that have survived to date.  I don't think there is any precedent of an operational system of this scale that requires this level of global coordination of its configuration, is there?  What Internet-scale system of a scale remotely as large as BGP has this kind of global coordination model?  What is the evidence that such an approach will work here?

I think this may be suggesting that more requirements analysis is needed before we can have total faith in the design work.  If this particular design implicitly requires something that seems to be a non-starter, then I would say that seriously undermines the design and more design work is likely required.  I have a specific example below...

> I think you overstate the problem. The intervals for each phase are not expected to be short, and there are phases that accommodate both old and new als in a fashion that allows considerable CA and RP flexibility.
> 
> Nonetheless, I think Terry's suggestion has merit. I can imagine having the milestone RFC be coordinated through the NRO and IANA, and published by the IETF, to help ensure that there is appropriate ISP input to the milestone
> development.

Sorry, but this really misses the issue I was trying to describe.  Suppose you have a very well-planned / longterm schedule in place.  As you march towards one of these cutover dates, suppose there is any operational problem (hardware failure, software failure, network partitioning of part of the system, newly discovered problems with the plan, etc).  At the "last minute" at least one operational body cannot meet the deadline.  How do you even securely verify that an operator needs to stop (as opposed to an impostor trying to halt things)? Then what? A new RFC in the 11th hour?  How is this overstating the problem?  There are two very different processes at play here: standards and policies get hammered out in their own time, operations happen whenever a problem feels like rearing its head.  I really think that conflating the two is a non-starter because they are governed by fundamentally different things, and so are their schedules.  Honestly, if someone needs to call a screeching halt to a rollover, how should that happen just days or hours before an RFC's deadline?  I think this is complicated by the fact that even if the NRO or IANA or anyone else actually can mint an RFC in a matter of hours (is that possible?), how would you guarantee that anyone else trying to respect the original RFC date even knows of the change?  Since global coordination is a requirement, they all have to be in sync either way, right?  I suppose if some portion of the operators don't get the message and start the rollover anyway, then we have another problem, yes?

Eric

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Nov 2011 18:38:25 -0500

Eric,

I didn't miss your point; I just do not agree with it.  I was noting that
Terry suggested that a milestone doc ought to reflect input from the CAs and
RPs, and that the NRO and IANA are reasonable candidates for such 
input coordination.

You have said, repeatedly, that you feel that a global schedule for 
alg transition is a terrible idea.  You have explained why you 
believe so. I have grave doubts about the high level scenario that 
you have described. Your comments seem to ignore the fact that the 
transition plan incorporates phases precisely to enable CAs and RPs 
to verify that they have working code to deal with the new alg suite 
before the old one is turned off.  You postulate a major problem that 
precludes a transition to a new alg Suite (presumably for Phase 4), 
but that phase occurs only after CAs have been generating products 
and RPs have been consuming them for some time.

This is not a productive discussion.

Steve

---

From: Terry Manderson <[email-masked]>
Date: Mon, 7 Nov 2011 18:16:01 -0800

> let's just say we disagree, modulo the idea of putting the milestones in

O.k Sure.

Remove the date specification going into the sidr-rpki-algs document and
construct whatever words are needed to say that the WG will adopt a BCP work
item helped along by the NRO, IANA (and it's operator), IAB etc.

Modulo the WG approval and WG Chair's happiness with this direction. :-)

> process, and milestone publication via an RFC authored by the NRO and

I think that is a step forward.

I'll look for the revised draft and will read as soon as I can.

Terry

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 8 Nov 2011 14:38:30 -0500

On Nov 7, 2011, at 6:38 PM, Stephen Kent wrote:

> RPs, and that the NRO and IANA are reasonable candidates for such input coordination.
> 
> You have said, repeatedly, that you feel that a global schedule for alg transition is a terrible idea.  You have explained why you believe so. I have grave doubts about the high level scenario that you have described. Your comments seem to ignore the fact that the transition plan incorporates phases precisely to enable CAs and RPs to verify that they have working code to deal with the new alg suite before the old one is turned off.  You postulate a major problem that precludes a transition to a new alg Suite (presumably for Phase 4), but that phase occurs only after CAs have been generating products and RPs have been consuming them for some time.
> 

Howdy Steve,

Thanks for your response.  Upon re-reading the exchange, I can see how my statements might have come across as categorically against this
approach.  This was not my intention, so I'm sorry if that was the impression I gave you.  If the list (and you) would indulge me, I'd like
to try a (hopefully) more constructive tack: I outlined a few questions that arose in my reading of the draft, and then made a handful of suggestions.

Just to be sure my thinking was clear (well, everything is relative: as clear as I ever get), I re-read the draft.  In doing so, I tried to
refactor my concerns in some more clarifying questions that jumped out at me:
1 - In the draft, there is discussion of the global agreement to move to algorithm B.  Who ensures the global agreement of B, and who chooses
and ensures agreement of the various dates?
2 - (Double checking that I have read this right), if the motivation for an algorithm roll is discovery of a weakness in the current algo,
no CA can roll until this top-down process reaches them, right (months or years)?  I see this is broached in Section 11, but it doesn't seem
to be answered there?  It sounds like the authors don't intend to address this any further than acknowledging the suboptimality of this
approach?
3 - Section 11 also prompted another question I had throughout: what happens if a CA doesn't meet these deadlines?  It seems like that
CA is simply orphaned and cannot participate in routing anymore (until they catch back up)?

From these three questions, I came to the following clarification suggestions:
1 - I see the phases in this draft as defining a formal process.  However, I don't see any error-legs (i.e. what happens if there needs to
be an abort, rollback, whatever you want to call it).  I think it is important to outline how this process can react if there are any
unforeseen failures at each phase.  I'm not sure that we need to be terribly specific, but perhaps we can agree that _something_ could go
wrong and cause the need for an abort?  I think this is quite common in process-specifications, unless we think nothing will ever go wrong
in this process? :)
2 - Related to the above, I would imagine (but maybe this is just me?) that in the event of a failure at one phase or another,
there may need to be a rollback procedure specified.
3 - I think a lot of complexity in the overall draft (and my above comments) could be addressed by allowing CAs to choose their own
algorithms and their own schedules.  Could this be considered?  I recall we discussed how this might negatively affect the performance of
the current design's complexity.  It's possible that we will just simply come to loggerheads here, but (design issues aside) do people think
CA operators should have the ability to protect themselves as soon as they can move to a new algo?
4 - Finally, there is a note that all algorithms must be specified in I-D.ietf-sidr-rpki-algs.  While I am not challenging that, I would
like to point out that having an analogous requirement in DNSSEC made life a little challenging to add new algos (specifically GOST) without a
lot of people trying to assess the algo's worthiness w/i the IETF.  I thought, though I could be mistaken, that several people lamented
having that requirement.  So, perhaps it would make sense to soften it here?

Thanks,

Eric

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Nov 2011 18:37:38 -0500

Eric,

Thanks for your comments.  responses are inline.
>...
>1 - In the draft, there is discussion of the global agreement to 
>move to algorithm B.  Who ensures the global agreement of B, and who 
>chooses

the IETF is responsible for the alg selection, just as it has been 
for other algs used with all other IETF standard protocols. Based on 
Terry's comments, I think we will state that the RFC defining the 
transition  dates will be coordinated with the NRO and IANA.

>2 - (Double checking that I have read this right), if the motivation 
>for an algorithm roll is discovery of a weakness in the current algo,
>no CA can roll until this top-down process reaches them, right 
>(months or years)?  I see this is broached in Section 11, but it 
>doesn't seem
>to be answered there?  It sounds like the authors don't intend to 
>address this any further than acknowledging the suboptimality of this
>approach?

The motivation for alg transition is anticipated weakness in the 
current alg suite, more so than a sudden discovery of a 
vulnerability. Althoygh there have been major headlines about alg 
breaks, these are usually FUD, and do not motivate an immediate 
transition to a new alg suite.  So, no we are not proposing a process 
that deals with a sudden alg break.

>3 - Section 11 also prompted another question I had throughout: what 
>happens if a CA doesn't meet these deadlines?  It seems like that

It's easier to discuss this if you pick a specific phase. Which one 
did you have in mind?

>1 - I see the phases in this draft as defining a formal process. 
>However, I don't see any error-legs (i.e. what happens if there 
>needs to
>be an abort, rollback, whatever you want to call it).  I think it is 
>important to outline how this process can react if there are any
>unforeseen failures at each phase.  I'm not sure that we need to be 
>terribly specific, but perhaps we can agree that _something_ could go
>wrong and cause the need for an abort?  I think this is quite common 
>in process-specifications, unless we think nothing will ever go wrong
>in this process? :)

What one might would do is phase specific. But, in general, the 
timeline could be pushed back if there is a good reason to do so. I 
thin terry';s suggestion helps in this regard. If we view the NRO as 
representing the RIRs, and the RIRs as representing ISPs, then there 
is a path for a CA or RP that has a problem to make that problem 
known, and addressed.

>2 - Related to the above, I would imagine (but maybe this is just 
>me?) that in the event of a failure at one phase or another,

I'm not sure that there is a need for a rollback, per se.  Pick a 
phase and a failure mode as an example as we can explore that issue.

>3 - I think a lot of complexity in the overall draft (and my above 
>comments) could be addressed by allowing CAs to choose their own
>algorithms and their own schedules.  Could this be considered?  I 
>recall we discussed how this might negatively affect the performance 
>of
>the current design's complexity.  It's possible that we will just 
>simply come to loggerheads here, but (design issues aside) do people 
>think

One cannot allow each CA to choose it's own set of algs, because that 
local choice has an impact on ALL RPs. That's what economists call 
externalization, and it's a bad thing. Having each CA choose it's own 
schedule is also a non -starter. Geoff Huston observed that unless we 
adopt a top-down transition plan, the repository could grow 
exponentially! That's an unreasonable burden. With a top-down plan 
CAs have limits imposed on them, already, i.e., a lower tier CA 
cannot switch to a new alg until it's parents support the new alg.

>4 - Finally, there is a note that all algorithms must be specified 
>in I-D.ietf-sidr-rpki-algs.  While I am not challenging that, I would
>like to point out that having an analogous requirement in DNSSEC 
>made life a little challenging to add new algos (specifically GOST) 
>without a
>lot of people trying to assess the algo's worthiness w/i the IETF. 
>I thought, though I could be mistaken, that several people lamented

DNSSEC was initially less rigorous in its alg criteria, and the 
result was not great. We are avoiding those problems.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 9 Nov 2011 15:39:14 -0500

Hey Steve,

On Nov 8, 2011, at 6:37 PM, Stephen Kent wrote:

<snip>

> the IETF is responsible for the alg selection, just as it has been for other algs used with all other IETF standard protocols. Based on Terry's comments, I think we will state that the RFC defining the transition  dates will be coordinated with the NRO and IANA.

Kewl, will look at the next version, thanks!

> The motivation for alg transition is anticipated weakness in the current alg suite, more so than a sudden discovery of a vulnerability. Althoygh there have been major headlines about alg breaks, these are usually FUD, and do not motivate an immediate transition to a new alg suite.  So, no we are not proposing a process that deals with a sudden alg break.

k.

> It's easier to discuss this if you pick a specific phase. Which one did you have in mind?

OK.  For this particular question, I think I understood the draft to be saying that at the end of phase 4, there may be fewer verified entities in the global system (this was discussed in the last paragraph of Section 11).  I believe the implication is that if any CA doesn't keep up (so to speak) they are considered invalid and therefore would be un-routable?

> What one might would do is phase specific. But, in general, the timeline could be pushed back if there is a good reason to do so. I thin terry';s suggestion helps in this regard. If we view the NRO as representing the RIRs, and the RIRs as representing ISPs, then there is a path for a CA or RP that has a problem to make that problem known, and addressed.

I think this needs to be codified for each phase in the draft.  This would seem to be a simple necessity that comes from defining a formal process.

> I'm not sure that there is a need for a rollback, per se.  Pick a phase and a failure mode as an example as we can explore that issue.

As per the above, I think each phase should define its starting requirements (which I think are there), and what to do if its success requirements are not met (exceptions, error legs, etc).  I don't think we need to rathole any strawmen to agree that it is possible that this process may need to be aborted (even if only in very extremely rare cases), and this document should detail how this will be done at each phase.  Indeed, I don't think this document should even try to enumerate the specific types of failures.  Rather, it should just tell people what to do if a failure is deemed to have occurred.

> One cannot allow each CA to choose it's own set of algs, because that local choice has an impact on ALL RPs. That's what economists call externalization, and it's a bad thing. Having each CA choose it's own schedule is also a non -starter. Geoff Huston observed that unless we adopt a top-down transition plan, the repository could grow exponentially! That's an unreasonable burden. With a top-down plan CAs have limits imposed on them, already, i.e., a lower tier CA cannot switch to a new alg until it's parents support the new alg.

Hmm, I think there might be a bit of an oversimplification in this perspective.  The "externalization" you're describing sounds a lot like an operational entity's right to govern their own operational choices.  In other words, regardless of whether this is a "bad" thing or not, we've already got it now.  Is trying to legislate a new operational model that supplants an existing one the job of this draft?

Does the exponential growth come from the need for a predecessor to necessarily employ the union of all crypto algos that exist in the hierarchy below them?  I don't think that should be a requirement here (perhaps exactly for the reason you just mentioned).  Why can't a cryptographic delegation chain be composed of heterogeneous algos?  It solves this complexity problem quite elegantly.  One might even call it algorithm agility...

Sorry, I couldn't help adding some levity... :-P

> DNSSEC was initially less rigorous in its alg criteria, and the result was not great. We are avoiding those problems.

Could you elaborate please?

Eric

---

From: Stephen Kent <[email-masked]>
Date: Sun, 13 Nov 2011 21:16:48 -0500

Eric,

In response to your message from last week.

Some candidate text dealing with the timeline document in section 2:

An additional document, the algorithm transition 
timeline will be published as a BCP (?) to define 
the timeline for the algorithm suite transition. 
It will defines dates for the phase transitions, 
consistent with the descriptions provided in 
Section 4. It is RECOMMENDED that the timeline 
document be developed by the entities that act as 
CAs, RPs, and repository operators in the RPKI, 
e.g., IANA, Internet Registries, and network 
operators. It is also RECOMMENDED that the 
timeline document describe procedures to track 
the progress of the transition and to amend the 
timeline, e.g., if problems arise in implementing 
later phases of the transition.

You raised a question about the implications for 
CAs that do not transition to the new algorithm 
suite, motivated by the last paragraph of section 
11. You posited that "Š the implication is that 
if any CA doesn't keep up (so to speak) they are 
considered invalid and therefore would be 
un-routable?" That's not quite accurate. At the 
end of Phase 4 the Internet resources of any CAs 
that have not made the transition will be treated 
the same as resources that have not been 
protected via RPKI certificates and ROAs. 
Participation in the RPKI is voluntary, so there 
may always been unprotected resources in the 
public Internet. These are not un-routable, but 
they are subject to hijacking.

You suggested that we codify how the community 
should deal with problems that motivate delaying 
a phase transition. We're not writing the 
timeline document now, but the text at the 
beginning of this message is an effort to make 
sure such considerations are addressed in that 
document.

You suggested that we add text, for each phase, 
saying "Š what to do if its success requirements 
are not met (exceptions, error legs, etc)." 
Here's my proposed initial text to address your 
question:

Phase 0 is the start of the process, when a new 
algorithm suite has been selected and the 
timeline published. The only problem I envision 
that might arise at this stage, prior to Phase 1, 
is a discovery of a problem that makes Suite B 
unacceptable. If this situation arises, the 
algorithm document will have to be reissued with 
a new Suite B, and the timeline document will be 
reissued.

Phase 1 requires all CAs to be able to issue 
certificates under Suite B. If a problem arises 
that makes this infeasible for a substantial 
number of CAs, the timeline document can be 
reissued, pushing back this date, and dates for 
subsequent milestones. CAs that are capable of 
issuing Suite B certificates may continue to do 
so, if requested by their child CAs. Since this 
phase does not require any RPs to process signed 
objects under Suite B, and since Suite B product 
SHOULD be stored at independent publication 
points, there is no adverse impact on RPs.

Phase 2 requires that CAs MUST publish all signed 
products under Suite B, as well as Suite A, and 
RP MAY be prepared to validate these products 
using Suite B. If a problem arises that makes 
this infeasible for a substantial number of CAs, 
the timeline document can be reissued, pushing 
back this date and dates for subsequent 
milestones. (Since the processing requirement for 
RPs here is  MAY, if RPs have problems with Suite 
B products this does not require pushing back the 
Phase 2 milestone, but it does motivate delaying 
the start of Phase 3.) CAs that are capable of 
publishing products under Suite B may continue to 
do so. Phase  2, like Phase 1, does not require 
any RPs to process signed objects under Suite B, 
and since Suite B product SHOULD be stored at 
independent publication points, there is no 
adverse impact on RPs.

Phase 3 requires that RPs MUST be able to process 
Suite B signed products, and RPs are encouraged 
to validate signed products using Suite B. 
However, each RP is required to be able to fall 
back to using the Suite A product if the Suite B 
product set cannot be validated. As Section 4.6 
notes, there are no CA behavior changes at this 
phase, so there is no requirement for CA 
rollback. If a substantial number of RPs are 
unable to process product sets signed with Suite 
B, this Phase could be delayed, and subsequent 
milestones pushed back. There is no rollback 
required here, as there is no change in CA 
behavior.

Phase 4 begins the phase out of Suite A. At this 
phase products sets signed under the old 
algorithm suite may begin to disappear, i.e., CAs 
MAY choose to not publish them anymore. This 
phase should be delayed if it is determined that 
many RPs are not capable of processing the new 
algorithm suite. There is no rollback required if 
this phase is delayed. However, CAs should be 
reminded to not remove old  algorithm suite A 
product sets if this phase is delayed.

Section 4.8 describes EOL for the old algorithm 
suite, i.e., it kills off all support for the old 
algorithm suite. It is described as a return to 
Phase 0. If we wait until Phase 0, then it may be 
a very, very long time before the old Suite A is 
killed off. We may want to revisit this, i.e., if 
we want to kill off the old algorithm suite 
sooner.

Your last comment deals with the question of 
top-down vs. laissez faire algorithm transition. 
I think your comment is that we cannot mandate 
adherence to the transition process and timeline. 
Use of the RPKI, both the issuance of signed 
products and their consumption, is optional. So, 
no, we cannot mandate adherence to this timeline. 
But, we can establish a transition  process and 
timeline for all CAs and RPs that chose to follow 
it. The goal in establishing the process and 
timeline is to minimize the cost to the 
community, as a whole, for the transition. 
Externalization of cost is the appropriate term 
here (from economics perspective) to describe 
what happens if one were to adopt the laissez 
faire approach. (Chaos might be an alterative 
term :-))

First, not that a CA cannot unilaterally decide 
to transition to a new algorithm. There is a 
requirement that the issuer of its certificate is 
prepared to accept a certificate request under 
the new algorithm suite (because of the PoP 
requirement).

The exponential growth arises if we have Suite A 
and B product sets at each tier. If we allow CAs 
to "do their own thing," there is the potential 
for four combinations:
- a Suite A certificate issued under Suite A
- a Suite A certificate issued under Suite B
- a Suite B certificate issued under Suite A
- a Suite B certificate issued under Suite B

If we allow all of these combinations, which may 
be needed to allow RPs to process signed products 
during the transition, then each tier has this 
potential 4-way branching, to accommodate RPs at 
different stages of algorithm capability. If you 
want more details, I suggest reviewing the slides 
from the SIDR WG meeting that I believe I cited 
previously. When Geoff Huston initially noted 
this problem, I disagreed, and it was not until I 
started to write the spec that I realized what he 
meant.

To avoid more flame wars, I will duck your 
question about my views on DNSSEC and 
accommodation of different algorithm suites :-).

Steve

---

From: Brian Dickson <[email-masked]>
Date: Sun, 13 Nov 2011 22:25:43 -0500

On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent <[email-masked]> wrote:
> You suggested that we codify how the community should deal with problems
> that motivate delaying a phase transition. We're not writing the timeline
> document now, but the text at the beginning of this message is an effort to
> make sure such considerations are addressed in that document.

When you say "timeline document", do you mean "timeline for specific
implementation of the phases in this document"?

I ask because the algorithm-agility sure looks like a timeline document.

The main concerns rise from the content and order of the phases, and their
consequences.

> Phase 0 is the start of the process, when a new algorithm suite has been
> selected and the timeline published.
>
> Phase 1 requires all CAs to be able to issue certificates under Suite B.
>
> Phase 2 requires that CAs MUST publish all signed products under Suite B, as
> well as Suite A, and RP MAY be prepared to validate these products using
> Suite B.
>
> Phase 3 requires that RPs MUST be able to process Suite B signed products,
> and RPs are encouraged to validate signed products using Suite B.
>
> Phase 4 begins the phase out of Suite A.
>
>
> First, not that a CA cannot unilaterally decide to transition to a new
> algorithm. There is a requirement that the issuer of its certificate is
> prepared to accept a certificate request under the new algorithm suite
> (because of the PoP requirement).

This statement is entirely predicated on having Phase 2, as it is currently
defined, after Phase 1 (CAs ready for receiving B) and before Phase 3
(when RPs are able to validate using B). I don't see what this step
in this order, buys us, or even that it is necessary at all.

Let's take a look at what happens after Phase 3:
- RPs speak "B".
- CAs can process "B".

Is this not the (only!) pre-condition required for supporting any of
the four combinations?

> If we allow CAs to "do their own thing," there is the potential for
> four combinations:
> The exponential growth arises if we have Suite A and B product sets at each
> tier.

I don't see the requirement to support more than one certificate
(ie of more than one of the four types.)

After Phase 1 and Phase 3, but ignoring your Phase 2, we know:
- RPs speak "B"
- CAs can accept requests with PoP == "B".

A certificate of any of the four types can be issued by any CA, and
validated by any RP.
Which type depends only on the CA (signature alg) and the subordinate
CA (key/PoP type).

There is no exponential growth _unless_ multiple cert types for each
cert are maintained,
which I disagree with as being a requirement _at_all_. I do not see a
reason to need
more than one certificate, regardless of which of the four types it is.

So, the only possible danger with allowing any CA to switch to "B"
whenever it wants,
is that should that occur before the end of phase 3 (when all RPs speak "B"),
all subordinate certificates will be at risk for not validating with
those RPs who are not
"B"-ready.

However, experimentation during the early deployment stages, almost demands for
this ability, and that there would be the expectation of such failure
by those using
(or more accurately, testing) code prior to widespread adoption.
Earliest work would
be done using leaf "B" certs, and early-deployment code. Gradually
additional levels
of testing (B-B and B-B-B), until enough traction in deployment in CA
code and RP code
has occurred. This eventually culminate with "B" root transition.

Deploying code without this incremental testing, and then expecting it
to "just work",
suggests a lack of experience and familiarity with the deployment of
new operational
code features in a multi-vendor environment on the Internet...

_Especially_ if there is no compelling reason. Can you show me what compels
the maintenance of both types of certificates, and a "fall-back-to-A" logic?

We have another term for "fall-back-to-foo" - it's called a "downgrade attack".

I'll withdraw my objection if anyone can make a truly compelling case using only
the assumptions above - Phase 1 and Phase 3, followed by widespread issuance
of production "B" certs, on a timeline entirely determined by local CA
decisions.

Brian

---

From: Eric Osterweil <[email-masked]>
Date: Mon, 14 Nov 2011 14:05:32 +0800

Hey Steve,

Thanks for the response.  I commented below:

On Nov 14, 2011, at 10:16 AM, Stephen Kent wrote:

> An additional document, the algorithm transition timeline will be published as a BCP (?) to define the timeline for the algorithm suite transition. It will defines dates for the phase transitions, consistent with the descriptions provided in Section 4. It is RECOMMENDED that the timeline document be developed by the entities that act as CAs, RPs, and repository operators in the RPKI, e.g., IANA, Internet Registries, and network operators. It is also RECOMMENDED that the timeline document describe procedures to track the progress of the transition and to amend the timeline, e.g., if problems arise in implementing later phases of the transition.

I really think we should address these issues in a single document.  It seems like splitting this off into a separate/as yet unwritten document is likely to cause some problems.  In particular, since that document does not yet exist, and it may not be written and adopted for some time, this draft will not be complete on its own.  I'm worried that it is hard to judge this document's readiness w/o these timeline issues worked out or even broached (as they may demand changes to this process).  Besides, isn't the corpus of drafts rather extensive already (w/o adding another)? :)

> 
> 
> You raised a question about the implications for CAs that do not transition to the new algorithm suite, motivated by the last paragraph of section 11. You posited that "Š the implication is that if any CA doesn't keep up (so to speak) they are considered invalid and therefore would be un-routable?" That's not quite accurate. At the end of Phase 4 the Internet resources of any CAs that have not made the transition will be treated the same as resources that have not been protected via RPKI certificates and ROAs. Participation in the RPKI is voluntary, so there may always been unprotected resources in the public Internet. These are not un-routable, but they are subject to hijacking.

OK, I see.  But, aren't there second-order effects of this that we have to worry about?  For example, if I am an ISP whose CA performs the rollover properly, but my upstream's CA does not, then their CA's failure to keep up will cause my ISP to no longer be able to participate in BGPsec, right (because I'm no longer part of a contiguous BGPsec island)?  I realize this is a bit different than my original example, but upon thinking about the motivation for my comment, my point was more general.  It was that transitioning a CA to this state can have very undesirable effects.

> 
> You suggested that we codify how the community should deal with problems that motivate delaying a phase transition. We're not writing the timeline document now, but the text at the beginning of this message is an effort to make sure such considerations are addressed in that document.
> 
> You suggested that we add text, for each phase, saying "Š what to do if its success requirements are not met (exceptions, error legs, etc)." Here's my proposed initial text to address your question:
> 
> Phase 0 is the start of the process, when a new algorithm suite has been selected and the timeline published. The only problem I envision that might arise at this stage, prior to Phase 1, is a discovery of a problem that makes Suite B unacceptable. If this situation arises, the algorithm document will have to be reissued with a new Suite B, and the timeline document will be reissued.

s/I envision/we envision/

> 
> Phase 1 requires all CAs to be able to issue certificates under Suite B. If a problem arises that makes this infeasible for a substantial number of CAs, the timeline document can be reissued, pushing back this date, and dates for subsequent milestones. CAs that are capable of issuing Suite B certificates may continue to do so, if requested by their child CAs. Since this phase does not require any RPs to process signed objects under Suite B, and since Suite B product SHOULD be stored at independent publication points, there is no adverse impact on RPs.

kewl, thnx.  One minor nit: can we rephrase one part for clarity.  Instead of "If a problem arises that makes this infeasible for a substantial number of CAs," can we just specify a little bit about how this is determined.  Maybe something like, "If <whoever the operational governing body we elect for timeline statements> deems a problem to have arisen that is significant enough to make this infeasible for a significant enough number of CAs..."

> 
> Phase 2 requires that CAs MUST publish all signed products under Suite B, as well as Suite A, and RP MAY be prepared to validate these products using Suite B. If a problem arises that makes this infeasible for a substantial number of CAs, the timeline document can be reissued, pushing back this date and dates for subsequent milestones. (Since the processing requirement for RPs here is  MAY, if RPs have problems with Suite B products this does not require pushing back the Phase 2 milestone, but it does motivate delaying the start of Phase 3.) CAs that are capable of publishing products under Suite B may continue to do so. Phase  2, like Phase 1, does not require any RPs to process signed objects under Suite B, and since Suite B product SHOULD be stored at independent publication points, there is no adverse impact on RPs.

First, same minor nit as above.
Second, do we want to consider the case were we want to rollback (perhaps an alg B has become unsuitable for some reason and we need to choose a new alg B altogether)?  I'm not saying the above text should be yanked, maybe just augmented?

> 
> Phase 3 requires that RPs MUST be able to process Suite B signed products, and RPs are encouraged to validate signed products using Suite B. However, each RP is required to be able to fall back to using the Suite A product if the Suite B product set cannot be validated. As Section 4.6 notes, there are no CA behavior changes at this phase, so there is no requirement for CA rollback. If a substantial number of RPs are unable to process product sets signed with Suite B, this Phase could be delayed, and subsequent milestones pushed back. There is no rollback required here, as there is no change in CA behavior.

I think this reads well.  I just have the same rollback comment as above (again, as a possible addition, not replacement text).

> 
> Phase 4 begins the phase out of Suite A. At this phase products sets signed under the old algorithm suite may begin to disappear, i.e., CAs MAY choose to not publish them anymore. This phase should be delayed if it is determined that many RPs are not capable of processing the new algorithm suite. There is no rollback required if this phase is delayed. However, CAs should be reminded to not remove old  algorithm suite A product sets if this phase is delayed.

Same rollback comment.

Minor typo:
s/products sets/product sets/

> 
> Section 4.8 describes EOL for the old algorithm suite, i.e., it kills off all support for the old algorithm suite. It is described as a return to Phase 0. If we wait until Phase 0, then it may be a very, very long time before the old Suite A is killed off. We may want to revisit this, i.e., if we want to kill off the old algorithm suite sooner.
> Your last comment deals with the question of top-down vs. laissez faire algorithm transition. I think your comment is that we cannot mandate adherence to the transition process and timeline. Use of the RPKI, both the issuance of signed products and their consumption, is optional. So, no, we cannot mandate adherence to this timeline. But, we can establish a transition  process and timeline for all CAs and RPs that chose to follow it. The goal in establishing the process and timeline is to minimize the cost to the community, as a whole, for the transition. Externalization of cost is the appropriate term here (from economics perspective) to describe what happens if one were to adopt the laissez faire approach. (Chaos might be an alterative term :-))

I think this is a very strange comment (and I note that you said it earlier in this email too).  "Use of the RPKI... is optional."  Is the goal of this system to protect the global routing infrastructure or not?  Unless we are talking about making this an experimental expedition, and are prepared to create a globally applicable system later?  If the goal is to secure the global routing system (note I am not saying universal deployment in the foreseeable future, just global applicability), then this is an operational non-starter.  I do not believe it is appropriate for us to try and re-legislate operational axioms in these drafts.  What we could be doing is grossly misaligning this standards work with operational invariants.

> 
> First, not that a CA cannot unilaterally decide to transition to a new algorithm. There is a requirement that the issuer of its certificate is prepared to accept a certificate request under the new algorithm suite (because of the PoP requirement).

I'm sorry, I don't understand.

> 
> The exponential growth arises if we have Suite A and B product sets at each tier. If we allow CAs to "do their own thing," there is the potential for four combinations:
> If we allow all of these combinations, which may be needed to allow RPs to process signed products during the transition, then each tier has this potential 4-way branching, to accommodate RPs at different stages of algorithm capability. If you want more details, I suggest reviewing the slides from the SIDR WG meeting that I believe I cited previously. When Geoff Huston initially noted this problem, I disagreed, and it was not until I started to write the spec that I realized what he meant.

Indeed, I will take a look before coming back to this (to be sure I have not missed anything), thanks.

> To avoid more flame wars, I will duck your question about my views on DNSSEC and accommodation of different algorithm suites :-).

Shall I take that as a retraction of your comment? ;)

Eric

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Nov 2011 21:53:22 -0500

Eric,

i think we are making  progress. thanks for the feedback.

>...
>
>I really think we should address these issues in a single document. 
>It seems like splitting this off into a separate/as yet unwritten 
>document is likely to cause some problems.  In particular, since 
>that document does not yet exist, and it may not be written and 
>adopted for some time, this draft will not be complete on its own. 
>I'm worried that it is hard to judge this document's readiness w/o 
>these timeline issues worked out or even broached (as they may 
>demand changes to this process).  Besides, isn't the corpus of 
>drafts rather extensive already (w/o adding another)? :)

My motivation for a separate timetable (vs. timeline) doc is that 
there seems to be some agreement that this doc should be a product of 
the operator community. The alg transition doc is an IETF 
architectural statement, the product of this WG. I can't see 
combining the two.  Did I misunderstand your concern here?

>...
>
>OK, I see.  But, aren't there second-order effects of this that we 
>have to worry about?  For example, if I am an ISP whose CA performs 
>the rollover properly, but my upstream's CA does not, then their 
>CA's failure to keep up will cause my ISP to no longer be able to 
>participate in BGPsec, right (because I'm no longer part of a 
>contiguous BGPsec island)?  I realize this is a bit different than 
>my original example, but upon thinking about the motivation for my 
>comment, my point was more general.  It was that transitioning a CA 
>to this state can have very undesirable effects.

What you say that you performed the rollover but the CA above you 
didn't can you be more specific, re the phase number?

>s/I envision/we envision/

fixed

>kewl, thnx.  One minor nit: can we rephrase one part for clarity. 
>Instead of "If a problem arises that makes this infeasible for a 
>substantial number of CAs," can we just specify a little bit about 
>how this is determined.  Maybe something like, "If <whoever the 
>operational governing body we elect for timeline statements> deems a 
>problem to have arisen that is significant enough to make this 
>infeasible for a significant enough number of CAs..."

Good suggestion. I had already changed the text to the following form.

If it is determined that a substantial number of CAs are unable

Since we don't have a good placeholder for the bracketed entity I 
think it's easier to make the statement without say who makes the 
determination.
>Second, do we want to consider the case were we want to rollback 
>(perhaps an alg B has become unsuitable for some reason and we need 
>to choose a new alg B altogether)?  I'm not saying the above text 
>should be yanked, maybe just augmented?

AI had not considered the case of an alg concern at this phase,  Good 
catch. I'll add suitable text to Phases 1-4.

>...
>
>I think this is a very strange comment (and I note that you said it 
>earlier in this email too).  "Use of the RPKI... is optional."  Is 
>the goal of this system to protect the global routing infrastructure 
>or not?

The goal of this work does not imply that we can force all ISPs to 
adopt it.  We hope that the RPKI will be very widely deployed and 
used, but we acknowledge that it may not me universal. So, both 
initially and perhaps forever, the world will consist of resources 
that are protected by certs and ROAs, and ones that are not.

>   Unless we are talking about making this an experimental 
>expedition, and are prepared to create a globally applicable system 
>later?

that's not a sentence :-).

>   If the goal is to secure the global routing system (note I am not 
>saying universal deployment in the foreseeable future, just global 
>applicability), then this is an operational non-starter.

I'm glad that we agree that universal deployment is not a likely near 
term event. We also agree that the RPKI is globally applicable . 
Neitehr of these observations conflict with the fact that its use by 
an network operator is optional.

>   I do not believe it is appropriate for us to try and re-legislate 
>operational axioms in these drafts.  What we could be doing is 
>grossly misaligning this standards work with operational invariants.

I no longer know what you are referring to. I have said that we 
cannot mandate adherence to this process.  We can offer it as a 
preferred approach and hope that it is followed. We have incorporated 
a number of phases so that there is an opportunity to verify the 
status of the transition, and to allow the timeline to be pushed back 
if necessary. if what you are saying is that we ought not specify any 
process that calls for CAs and RPs to try to execute a transition in 
a coordinated fashion, over a long time interval, then we have an 
impasse. The disagreement is based on perceptions, on both of our 
parts, not facts.

>  > First, not that a CA cannot unilaterally decide to transition to 
>a new algorithm. There is a requirement that the issuer of its 
>certificate is prepared to accept a certificate request under the 
>new algorithm suite (because of the PoP requirement).
>

PoP requires the issue of a cert to verify that the cert requester 
posses the private key corresponding to the public key in the cert 
request. So, if CA N requests a cert that contains a key under Alg X, 
CA N-1 (its parent ) cannot issue that cert until CA N-1 has 
implemented Alg X. Does this help?

>...
>
>>  To avoid more flame wars, I will duck your question about my views 
>>on DNSSEC and accommodation of different algorithm suites :-).
>

no.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 15 Nov 2011 12:28:48 +0800

On Nov 15, 2011, at 10:53 AM, Stephen Kent wrote:

> My motivation for a separate timetable (vs. timeline) doc is that there seems to be some agreement that this doc should be a product of the operator community. The alg transition doc is an IETF architectural statement, the product of this WG. I can't see combining the two.  Did I misunderstand your concern here?

Yes, there is a misunderstanding.  This draft is documenting a formal process.  The snipped text included the statement:
"It is also RECOMMENDED that the timeline document describe procedures to track the progress of the transition and to amend the timeline, e.g., if problems arise in implementing later phases of the transition."

I really think that the procedures associated with this process need to be documented here in the same place (i.e. one draft).

> What you say that you performed the rollover but the CA above you didn't can you be more specific, re the phase number?

After Phase 4, when some CAs may  be orphaned.  To quote the draft:
"a[n] RP that does not follow this process will lose the
   ability to validate signed products issued under the new algorithm
   suite."

> Since we don't have a good placeholder for the bracketed entity I think it's easier to make the statement without say who makes the determination.

Kewl, thnx.  As a broad question, do we think there will be a point when we can name an operational body who will manage this process, and if so, will we put this in a draft?

>> ...
>> 
>> I think this is a very strange comment (and I note that you said it earlier in this email too).  "Use of the RPKI... is optional."  Is the goal of this system to protect the global routing infrastructure or not?
> 
> The goal of this work does not imply that we can force all ISPs to adopt it.  We hope that the RPKI will be very widely deployed and used, but we acknowledge that it may not me universal. So, both initially and perhaps forever, the world will consist of resources that are protected by certs and ROAs, and ones that are not.
> 
>>   Unless we are talking about making this an experimental expedition, and are prepared to create a globally applicable system later?
> 

Yeah it is, I can speak to this at the mic... ;)  In the meantime:
Are we talking about making this an experimental expedition?  Follow on question, are we prepared to create a globally applicable system later?

>>   If the goal is to secure the global routing system (note I am not saying universal deployment in the foreseeable future, just global applicability), then this is an operational non-starter.
> 
> I'm glad that we agree that universal deployment is not a likely near term event. We also agree that the RPKI is globally applicable .

No, I was questioning the global applicability.  I am worried that the way BGPsec and RPKI are currently married is not globally applicable, in the current form. 

> Neitehr of these observations conflict with the fact that its use by an network operator is optional.

True, but my point is still that there is a rather striking misalignment between the design and operational invariants.  I'm trying to see your points and how this might not be true, but claiming that we've agreed when it's plain that we have not is... not as productive as it could be... :)

> 
>>   I do not believe it is appropriate for us to try and re-legislate operational axioms in these drafts.  What we could be doing is grossly misaligning this standards work with operational invariants.
> 
> I no longer know what you are referring to. I have said that we cannot mandate adherence to this process.  We can offer it as a preferred approach and hope that it is followed. We have incorporated a number of phases so that there is an opportunity to verify the status of the transition, and to allow the timeline to be pushed back if necessary. if what you are saying is that we ought not specify any process that calls for CAs and RPs to try to execute a transition in a coordinated fashion, over a long time interval, then we have an impasse. The disagreement is based on perceptions, on both of our parts, not facts.

I think the distinct lack of another instance of this kind of operational requirement in modern Internet-scale systems should be cause for pause here.  As I said back at the beginning of this thread:
"Sorry, but I think freedom from global coordination is more than an inconvenient, or unpalatable, concept.  It is something that (afaict) has been an inherent requirement in those Internet-scale systems that have survived to date.  I don't think there is any precedent of an operational system of this scale that requires this level of global coordination of its configuration, is there?  What Internet-scale system of a scale remotely as large as BGP has this kind of global coordination model?  What is the evidence that such an approach will work here?"

>> Shall I take that as a retraction of your comment? ;)

Then I would really like to understand.  As DNSSEC (though not perfect, in any way) is a system that has reached deployment trials and has a growing body of operational practices, what were the "less rigorous" criteria that were "not great?"  Maybe we'll all agree, or maybe we'll all learn...

Eric

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Nov 2011 00:13:56 -0500

>I ask because the algorithm-agility sure looks like a timeline document.

I mean a document that associates dates with the phases described in the
alg agility doc. I've reworded the agility doc to say "timetable" 
instead of "timeline" to try to avoid confusion.

>in this order, buys us, or even that it is necessary at all.

Phase 1 allows early adopter CAs to get certs under the new alg 
suite, but does not require them to do a lot of work, because they 
don't have to issue new certs except for the children who ask for 
them.

Phase 2 requires CAs to do this work, which enables RPs to test their 
RP software with the new alg, if they wish, i.e., another early 
adopter capability.

Phase 3 says RP have to be able to do this.

I think the order makes sense.

>Let's take a look at what happens after Phase 3:

This characterization strikes me as backwards. RPs process Suite B 
products. CAs generate Suite B products. CAs "process" requests for 
certs under Suite B. But, let's not quibble.

The rest of your message argues that Phase 2 is unnecessary. But, you 
acknowledge the need for CAs and RPs to experiment with software that 
supports Suite B, and processes that support transition from A to B. 
Thart is precisely what Phase 2 enables. It gives RPs time to work on 
processing Suite B product sets, but it does not require that they do 
so. Also, if some CAs didn't get the Suite B product set generation 
right there is an opportunity to provide feedback, but Suite A 
products sets are still there, so things don't break.  Trying to move 
from Phase 1 to Phase 3, as you suggest seems very likely to cause 
things to break, especially when coupled with the notion that a CA 
can decide to make use of only Suite B if it wishes.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Thu, 17 Nov 2011 12:50:20 -0500

On Thu, Nov 17, 2011 at 12:13 AM, Stephen Kent <[email-masked]> wrote:
> Phase 1 allows early adopter CAs to get certs under the new alg suite, but
> does not require them to do a lot of work, because they don't have to issue
> new certs except for the children who ask for them.

> Phase 2 requires CAs to do this work, which enables RPs to test their RP
> software with the new alg, if they wish, i.e., another early adopter
> capability.

Here's my point - you're employing a circular argument.
Strictly speaking, there is no actual _need_ for CAs and RPs to _globally_
achieve this state, simply to do testing.

CAs and RPs can (in more local environments) coordinate such testing.
E.g. CAs can issue Suite B products, under a different cert than their
"real" cert.
RPs can configure the CA's "fake" cert as a trust anchor.

More to the point - here is the only reason I can see to _require_ every CA
to issue Suite B products (as a parallel chain of products):
- To make possible the ending of Suite A deployment entirely

Under phase 2, as defined, there are two cert trees. One where every cert is
issued with a cert chain of AAAAAA..., and the other with BBBBB...

What I'm saying, as a point of clarification, is that BBBBBB.... is
not _strictly_
required for support for Suite B.

And that "enabling Suite B" is distinct from "disabling Suite A".

We may disagree on whether having more than one Suite available and
deployed at a given time is wise.

However, what I am trying to present is another deployment track:
- Enable Suite B as early as possible, by enabling a less risky deployment
- Being able to roll back to Suite A means there is less incumbent
risk _to the issuer_
- There are two parties for whom risk is an issue, the RPs and the issuers.
- The risks to be considered are, both the general stability of code
doing RP validation, and the global propagation of prefixes
- Under this alternate deployment scenario, at any point, a
coordinated roll-back is still feasible. The later it happens, the
more work is needed, but it is also more likely that early discovery
of issues that require a roll-back will occur.

> This characterization strikes me as backwards. RPs process Suite B products.
> CAs generate Suite B products. CAs "process" requests for certs under Suite
> B. But, let's not quibble.

Actually, it's not quibbling - this gets to the heart of the issue.

I'm saying, "CAs are _able_ to 'process' requests _of_ Suite B", but
this is orthogonal
to the statement "CAs _must_ _issue_ Suite B products".

What I'm saying is, regardless of the order of what was previously
called "Phase N":

Once the steps of Phase 1 and Phase 3 have been completed the following hold:
- RPs are _able_ to process products which are of all 4 forms,
involving Suite A and Suite B.
  This includes AA, AB, BA, and BB.
- CAs _can_ generate Suite B products
- CAs _can_ process requests under Suite B
- Nobody is _required_ to do anything (in terms of issuing Suite B vs Suite A)
--- Of course, if a child requests a cert with PoP(B), the resulting
cert must be issued accordingly
--- The parent in this case would be equally free to issue either BB
_xor_ AB material (depending on local CA policy)

> supports Suite B, and processes that support transition from A to B.  Thart
> is precisely what Phase 2 enables.

What I'm saying, if you look at the strict requirements for doing testing,
is that the bullet points above meet _every_ requirement for any CA to issue
a Suite B product and every RP have the ability to process the result.
I.e. for post-experiment stages of real operational deployment.

Once every RP is able to process Suite B, it is able to process heterogenous
products that contain any combination of Suite A and Suite B material.

I'm also saying that there is no _strict_ requirement for all-B cert chains,
to enable use of Suite B.

Phase 2 is only necessary to require CAs not issue (and remove) any
Suite A material, in order to end (globally) use of Suite B. NB: If we
change the order, then Phase 2 can be subsumed by Phase 4. Phase 2
becomes moot.

---

I'm also saying, that the overall strategy of supporting only one
Suite under the steady-state, is being presented as an a priori
assumption or requirement.

I'd suggest that, given the coordination required, that the proportion
of the time where only one Suite is permitted, may be less than the
vast majority, and in fact may turn out to be the minority.

It is worth at least considering, that if more of the time is spent
with multiple signatures supported, whether the more flexible approach
better fits the operation mode, and whether this in turn facilitates
faster deployment of new Suites.

The current approach is a "stick"-only approach. It mandates usage and
migration with no benefit for early adoption.
What I am suggesting is both "carrot" and "stick". It encourages
adoption of the new Suite as well as discourages use of the old Suite.

> Also, if some
> CAs didn't get the Suite B product set generation right there is an
> opportunity to provide feedback, but Suite A products sets are still there,
> so things don't break.

Here's the thing - if all-A chains continue to exist until Phase 4,
_and_ fallback to Suite A is required, this is a downgrade-attack
vulnerability.

Hybrid A/B chains do not suffer from that, so the comparative attack
surface is shrinking over time, versus fixed in the current model.

Given that the introduction of B and the elimination of A is an
explicit goal, and the underlying assumption is that B is stronger
than A, or  even that A has some flaw or weakness, then adopting an
approach which reduces that attack surface is tautologically superior.

> Trying to move from Phase 1 to Phase 3, as you
> suggest seems very likely to cause things to break, especially when coupled
> with the notion that a CA can decide to make use of only Suite B if it
> wishes.

Not so - recall, I am saying that Phase 3 is requiring the support for Suite B.
The scope of a given CA using Suite B, is that CA and its descendants _only_.
The "things" in question are the _validation_ of signed announcements
using Suite B.
The whole agility document already presumes successful deployment of Suite A.
Suite A could only be considered successfully deployed if RPs
correctly handle validation failures.

Not requiring all-A or all-B, supports a self-organizing deployment
process where sparse Suite B adoption is possible.
This would be where a CA has comparatively few descendants using Suite
B, and then converts to Suite B.

Sparse adoption is necessary to enable early adopters to achieve all-B
status (and excludes fallback-to-A).
Not permitting sparse adoption means that the earliest that all-B can
occur, is after the very last A user switches.

The harm comes not from causing things to break, but from not allowing
ROA-owners (leaf certificate holders) to protect their assets with the
best available crypto that is widely supported.

Brian

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 18 Nov 2011 01:21:11 -0500

> _and_ fallback to Suite A is required, this is a downgrade-attack

It seems to me that as long as there are consumers of cert material
that can not do the 'new hotness' (B in your example) you will have to
make products in the 'old and busted' form. Once everyone can do 'new
hotness', there is a relatively short period of time required to kill
off 'old and busted'.

I don't think you can get away with not making 'old and busted' until
everyone is able to plan ball, eh?

-Chris

---

From: Sean Turner <[email-masked]>
Date: Fri, 18 Nov 2011 15:34:21 +0800

> everyone is able to plan ball, eh?

Hope of hopes here is that we don't just transition when an alg is 
broke.  Algs weaken over time - that's just a fact.  When we retire an 
alg because it doesn't cut it anymore, then running with the old 
unbroken alg is a downgrade but assuming the alg ain't broke then it's 
probably okay for the transition period.

spt

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 20 Nov 2011 01:56:30 -0500

On Fri, Nov 18, 2011 at 2:34 AM, Sean Turner <[email-masked]> wrote:
> Hope of hopes here is that we don't just transition when an alg is broke.
>  Algs weaken over time - that's just a fact.  When we retire an alg because
> it doesn't cut it anymore, then running with the old unbroken alg is a
> downgrade but assuming the alg ain't broke then it's probably okay for the
> transition period.

do I have to apologize for the MIB refernce?

---

From: Eric Osterweil <[email-masked]>
Date: Mon, 21 Nov 2011 10:13:26 -0500

<snip>

<snip>

> do I have to apologize for the MIB refernce?

Absolutely not!  I was surprised no one gave you props for it! :)

Eric