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

From: Brian Dickson <[email-masked]>
Date: Tue, 8 Nov 2011 01:27:41 -0500

Sorry for the late reply.

I have been following the discussion, and reviewing all the related
items (normative/informative).

I will note that the compartmentalized design of the ROA elements of
SIDR mean it is possible to update pieces easily.
However, on the mere mortal reviewer of component IDs, it puts a
larger burden. It is well worth the cost, IMHO.

I hope my comments aren't too late. Given the number of other items in
the WG that had informally extended periods, I would appreciate
leniency here.

My main comment is as follows:
I do not support adoption of this document in its current form.

The main reasons have to do with fundamental aspects which at a high
level have been addressed by my colleagues, especially with respect to
timelines imposed by the IETF, or even IESG or IAB, whether directly
in BCP or RFC, or indirectly via ICANN or IANA.

More to the point - I am not sure if I understand the relationship
between some of the elements involved, but I believe there is no
strict requirement for all members of a CA hierarchy to maintain
identical algorithms.

Here's why:
- everybody is a CA. Both the "root" of the INR tree (ICANN/IANA),
plus the RIRs, etc., down to the publishers of EE certs.
- each CA publishes its policy via a CPS (it's a SHOULD, but
functionally a MUST for RPs to be able to understand what a CA
publishes.)
- Each CPS specifies the OID of the corresponding CP
- Each CP refers to the corresponding policy for algorithms
- Algorithms themselves have OIDs and are referenced as such in certs
- Every cert also specifies the OID of the CP itself (which embodies
the rules for allowed algorithms)

So while the first revision of the CP insists on only one algorithm
for pub/private keys, and one algorithm for hashes, it explicitly
calls out that these are expected to change.

In changing allowed algorithms, it can reasonably be inferred that CPs
could be issued which increase the _number_ of allowed algoriths of
both types beyond one.

And similarly, the methodology demonstrated by key rollover has local
scope. There is no requirement that children do anything at all when a
parent executes a key roll. _This is by design_.

So the analogous high-level design for agility SHOULD be as follows:
- new CP documents may be published, with new OIDs
- ONLY when a CA with a given CPS decides to change CP does that CA
need to execute a locally-significant key+alg roll
- The CA would issue new certs with the new CP which itself lists
additional algorithms
- The same procedure would be executed in multiple phases - issue new
child certs published under the old main cert; move them to the new
cert, rewriting/overwriting in the same location

This could be handled gracefully by having two CPs - one CP having the
additional algorithm(s), and subsequently another CP with the new but
minus the old.

This mechanism could be used to introduce new algorithms without
requiring retiring specific old algorithms. The two actions - adding
and removing - are in fact independent, beyond the requirement that
there be at least one algorithm (which goes without saying, really).
The only other requirement is that the issued certs have algorithms
consistent with the specified CP (OID) attached to the cert.

I may be completely off the mark, but this would seem to be much more
in line with the whole manner in which algorithms, policies, resource
objects, etc., have been separated out and linked by normative
reference.

Perhaps we could get Geoff Huston to comment on my interpretation of
the CP/CPS/alg interaction and explicit/implicit rules?
Is it intended that CAs have a uniform hierarchy using exactly one
algorithm set, or is it intended that each CA be able to specify (via
CPS + CP)  the set of algorithms it supports, with the initial CP
document being the minimum acceptable algorithm set?

Modulo the interaction between parents/children, and requiring old
algorithms to be retired, and having a set timeline, and  having all
global CAs on the same timetable, the general methodology for handling
the phases seems pretty solid.

IMHO.

Brian

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 8 Nov 2011 11:40:54 +0100

Hi Brian, 

Thanks for your comments.
Please see inline.

Roque

(snif)

> - new CP documents may be published, with new OIDs

The CP document in section 6.1.5 refers the definition of the Algorithm Suite to the draft-ietf-sidr-rpki-algs document. There are not OID defined in the CP document. That is why in our document we refer to an update of this document instead.

> cert, rewriting/overwriting in the same location

In section 4.1 we defined: 
   CA Ready Algorithm B Date  - After this date, all (non-leaf) CAs MUST
               be ready to process a request from a child CA to issue a
               certificate under the Algorithm B suite
If I summarize your comment, you are stating that the definition of "ready" for a CA should also include an update on its CPS to refer to the new suite. This was understood but as what each CA will need to do to be ready to process requests from a child CA is local to that CA, we did not got into the details. 

The process that you have described is indeed the proposed algorithm in the document for the CAs, where we adopted a "top-down" process and we maintain the two suites independent. The document also includes the transition to the new suite on the RPs that are distributed globally. 

Regards,
Roque

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

---

From: Brian Dickson <[email-masked]>
Date: Tue, 8 Nov 2011 07:48:17 -0500

On Tue, Nov 8, 2011 at 5:40 AM, Roque Gagliano <[email-masked]> wrote:
> The CP document in section 6.1.5 refers the definition of the Algorithm
> Suite to the draft-ietf-sidr-rpki-algs document. There are not OID defined
> in the CP document. That is why in our document we refer to an update of
> this document instead.

I was actually referring to the OID _of_ the CP document itself,
draft-ietf-sidr-cp-17,
in section 1.2.

And in draft-ietf-sidr-res-certs-22, section 9, use of that OID is
referenced, including
how the change of OID gets handled.

The change-of-OID process identified there would be necessary, even if
the res-certs
format did not change, so long as there was some other reason for the
OID change.

And in draft-ietf-sidr-cp-17, section 9.12.3 describes when the OID must change.
Clearly, changing the algorithm RFC used by the CP, would require a new CP with
a new OID, since it directly affects acceptability of RPKI certificates.

>                certificate under the Algorithm B suite

What I am saying is, there is no reason to require a change to a child's CPS,
and thus its CP, and thus its algorithm suite, simply because the parent CA
is making this change. The whole 'all (non-leaf)' stuff is un-necessary.

Each CA may operate its CPS independently. Algorithms are explicitly included
via OIDs in every cert. A child CA may need to sign with algorithms accepted by
the parent CA, but they can issue certs with a different CP, signed according
to the algorithms _of_that_CP_ (their own CP, independent of the choice of
CP used by the parent CA).

The choice of algorithm acceptability for a given cert, comes from the CP.
It needs internal consistency. There is no further requirement on
algorithm choice.

> If I summarize your comment, you are stating that the definition of "ready"
> for a CA should also include an update on its CPS to refer to the new suite.
> This was understood but as what each CA will need to do to be ready to
> process requests from a child CA is local to that CA, we did not got into
> the details.

Okay, yes, that was the bit I said was technically correct...

> The process that you have described is indeed the proposed algorithm in the
> document for the CAs, where we adopted a "top-down" process and we maintain
> the two suites independent. The document also includes the transition to the
> new suite on the RPs that are distributed globally.

That's the part I disagree with entirely - there is no "top-down"
required at all.
There is no "globally". There is only the requirement operationally
that any newly
published CP with new OID be supported by RPs.

The publishing the new CP with new OIDs with sufficient time for RPs
to implement
those changes is the only timeline issue. It is a "sunrise" issue - a
minimum time
after publication before ANY CA begins to issue certs using the new OID.

After that date, any CA may choose to use the new CP, without
requiring any change
to either the CA's parent, or the CA's children, except as relates to
the algorithms
used on new certs, which the child needs to discover. This has no bearing on the
CP _used_ by the child CA in issuing certs to grand-child CAs - that
is under the
local policy of the child CA.

Every CA is free to choose the CP it uses from among the published CPs, modulo
the issue date plus delay required (6 months in the initial CP document).

Issuing a second (or third, or fourth) CP does _not_require_ANY_ CA to change
algorithm suite.

Perhaps a separate BCP can recommend, or even require, use of some subset
of CP documents, or at some point an old CP could be moved to historic or
depracated status.

However, that should _not_ be part of the alg-agility document.
Agility should limit
itself to the mechanism by which a _single_ CA changes algorithm
suite, including
the possibility that the new suite still include all the algorithm(s)
from the previous
suite, the possibility that multiple algorithms are part of the new
suite, as well as
case of (but not a requirement that) _an_ older algorithm is dropped
from the suite.

> Roque

Sincerely,
Brian

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 8 Nov 2011 15:16:55 +0100

Hi Brian,

> after publication before ANY CA begins to issue certs using the new OID.

This is fine in a model where every CA lives in its own island (think on the identity case) but not in our case. A CA needs to issue a certificate-signing-request to its parent CA.

The WG decided to not allow "mixed" CA certificates. Consequently, you need your parent to be "ready" before been able to issue the CSR. This is the reason for the "top-down" requirement. So for "any" CA to issue certs using the new OID it needs that it parent has migrated first.

The rest of your reasoning seams to go around the same concept.

Roque.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 8 Nov 2011 14:49:55 -0500 (EST)

This document is basically ready for publication.  While it is
painfully long, it is arguably one of the better written documents
this WG has produced.  My thanks to the editors for their efforts.

I am uneasy with the limitations imposed by this mechanism, but I have
nothing better to suggest.  Let's go forward with this general
approach.

On to specifics:

I am persuaded by Terry's argument that it may not be appropriate to
publish hard dates for later steps.  Please change the doc 
accordingly.

And two very minor things:

Near the end of section 2, there appears to be a duplication:
    This document does not specify any algorithm suite.
    This document does not specify any algorithm suite per se.

And I'm unconvinced of the need for this particular limitation:
    All Dates MUST be represented using the local UTC date-time format
    specified in [RFC3339].
While the steps in this process are ordered, the timeliness of them
need not be so precise that we need to restrict how we write the date.

-- Sam

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Nov 2011 13:42:30 -0500

At 1:27 AM -0500 11/8/11, Brian Dickson wrote:
>...

>level have been addressed by my colleagues,

so, this is a Verisign critique, provided by you, Eric, and Danny?

>plus the RIRs, etc., down to the publishers of EE certs.

yes, essentially every actor in the RPKI is both a CA and an RP.

>functionally a MUST for RPs to be able to understand what a CA

small ISPs and orgs that have address space probably will not bother 
with a CPS, which is why it is a SHOULD, not a MUST. In a typical PKI 
context, a CPS primarily benefits the subjects to whom certs are 
issued; RPs also are potential CPS consumers.  In the RPKI, a "keaf" 
CA issues certs to itself, so a CPS is not of much interest for the 
first class of consumers. In the RPLI one does not get to shop around 
to choose a CA, so RPs don't need much from a CPS.

>- Each CPS specifies the OID of the corresponding CP

there is just one CP. not clear form your statement if thatr ws clear.

>- Each CP refers to the corresponding policy for algorithms

there is only one policy (CP) for the RPKI, and it specifies algs via 
a reference to an alg spec. so, I am not sure what you have in mind 
here.

>- Algorithms themselves have OIDs and are referenced as such in certs

yes.

>the rules for allowed algorithms)

yes.

>calls out that these are expected to change.

yes.

>could be issued which increase the _number_ of allowed algoriths of

there is only one CP.

>parent executes a key roll. _This is by design_.

yes, this is by design, but is irrelevant to the the alg transition 
design, which has global impact (on all RPs).

>- new CP documents may be published, with new OIDs

as I mentioned above, there is one CP for the RPKI. When you suggest multile
CPs, are you thinking of them on a per CA basis, or RPKI-wide?

>need to execute a locally-significant key+alg roll

see question above. also, unlike key roll, an alg roll affects ALL RPs,
which is why the analogy between the two procedures is bad. Also, note my
'reply to Brian re the top-dowen deployment model that the Wg adopted, to avoid
exponential growth in the repository system.

>- The CA would issue new certs with the new CP which itself lists

ibid.

>cert, rewriting/overwriting in the same location

ibid.

>additional algorithm(s), and subsequently another CP with the new but

not graceful re repository growth, and impact on RPs.

>consistent with the specified CP (OID) attached to the cert.

there needs to be one alg that ALL RPs can deal with at all times.  Also,
unlike key roll, when a CA wants to have a new cert with a public key
using a new alg, its parent MUST be able to support that alg, because of
the PoP requirement.

>objects, etc., have been separated out and linked by normative

I do not agree.

>document being the minimum acceptable algorithm set?

This text suggests that you believe there is on CP per CA, vs. a
system-wide CP. The architecture is the latter.  Also, while I respect
Goeff, why is your question directed to him? I am a co-author of the CP,
the arch, and the key roll and the alg roll docs :-).

Steve

---

From: Brian Dickson <[email-masked]>
Date: Wed, 9 Nov 2011 15:07:25 -0500

> so, this is a Verisign critique, provided by you, Eric, and Danny?

Respectfully, Stephen, I would ask that you not infer anything along
these lines.
The IETF is very clear on participation being an individual activity,
regardless of
$day_job.

In addition to this _not_ being the case, I _personally_ consider this both
highly inappropriate at a professional level, and bordering on _ad_hominem_,
something that really has no place in WG mailing-list discussions.

I would ask that you seriously consider whether an apology for your comment
is appropriate.

As for "colleague", I meant within the WG, as in "collegial". If I had meant to
say "co-worker", I would have said "co-worker".

Any similarity between our concerns is entirely due to similarity in operational
experiences in a variety of venues, at a variety of $day_jobs.

I'll address the content-oriented portion of your email in a separate message.

Brian
- not using any email-address that would suggest affiliation -

---

From: Brian Dickson <[email-masked]>
Date: Wed, 9 Nov 2011 16:44:05 -0500

Rather than respond, point-by-point, I will top-reply, and try to
clear this up in a structured manner.

First, from the perspective of normative references:
- most of the main SIDR documents reference each other, both
generally, and in specific places.
-- e.g. -rpki-algs-05 refers to -arch, -cp, -res-certs and -signed-object
-- e.g. -cp explicitly delegates algorithm specification to -rpki-algs
-- e.g. -res-certs section 9, in addition to referring to -cp, clearly
indicates that versions of itself and -cp need to be re-issued in
lock-step
-- e.g. Changing (by updating/replacing) the RFC for -rpki-algs, would
actually require issuing new versions of -cp, -res-certs, and
-rpki-algs, as a "document set".

I believe I would be accurate in saying, one of the primary purposes
of having an algorithm-agility doc, is to document what would need to
happen if a new set of algorithms to be published. And the scope of
the agility needs to include interaction between the RPKI system and
the consumers of that data, the RPs.

Let us stay with one "current" CP.

Again, the presumption is: one -cp doc, one -res-certs doc, one
-rpki-algs doc; and the agility doc describing the necessary state
changes to go from one controlling, unified set of docs, to another
controlling, unified set of docs.

It's is all about the content of the "rpki-algs" document; everything
(the top-down and exponential growth issues in particular) hinge on
that.

[terminology]
Alg.suite = { algorithms }
Let A denote Alg.Suite "A" (upper case means suite)
let a denote algorithm (or alg-pair) "a" (lower case means algorithm)
A example of the above would be:
X = { n p q }
[end terminology]

[example cases]
A = { a }
B = { b }
C = { a b }    (Algorithm suite C, includes algorithms "a" and "b")
[end example cases]

Note the following (Venn diagram) results:
A ^ B = { }
A ^ C = { a } = A
C ^ B = { b } = B
A v B = { a b } = C
A v C = { a b } = C
C v B = { a b } = C

The current algorithm-agility document presumes that an algorithm
update will always be of the form "A -> B".
It is because of the fact that A ^ B = {}, that the duplicate certs
problem arises, which gives rise to the exponential problem, which
leads to top-down.
With more than one suite, it becomes necessary to have multiple certs.
A cert is only valid within one suite.

If you consider suites A and C, note that a cert valid under A, is
_also_ valid under C - it does not require new key date; it may need
to re-issue.

If, instead, the updates were done by two successive, albeit
technically independent, updates, "A -> C", followed by "C -> B", the
problem goes away.

The timelines involved for "A -> C" would look like:
  Process for RPKI CAs:

    Phase 0   Phase 1   Phase 2   Phase 3
  -----------x--------x--------x----------
    ^        ^        ^        ^
    |        |        |        |
   (1)      (2a)     (3)      (4)

  Process for RPKI RPs:

    Phase 0      Phase 1
  --------------x-----x-------------------
    ^           ^     ^
    |           |     |
   (1)         (2b)  (3)

  (1) RPKI's algorithm document updated.
  (2a) CA Ready Algorithm C Date (all CAs can accept algorithms in set
C, "a" or "b" specifically)
  (2b) RP Ready Algorithm C Date (all RPs can validate algorithms in
set C, "a" or "b" specifically)
  (3) CA/RP Set Algorithm C Date (all RPs and CAs now are ready - on
or after later of 2a/2b)
  (4) CA Go Algorithm C Date (any given CA can now _choose_ to switch
from using "a" to using "b")

The mechanics on re-issuing certificates are clear. In the last
paragraph of "sidr-arch", section 4.2:

   If a CA certificate is reissued with the same public key, it should
   not be necessary to reissue (with an updated AIA URI) all
   certificates signed by the certificate being reissued. Therefore, a
   certification authority SHOULD use a persistent URI naming scheme for
   issued certificates. That is, reissued certificates should use the
   same publication point as previously issued certificates having the
   same subject and public key, and should overwrite such certificates.

So, if we presume that Algorithm suite C allows the choice of two
algorithms, then a CA can switch from
one algorithm to the other by (a) re-requesting its own CA cert using
the PoP of its new public key,
which is the public key for algorithm "b"; and (b) reissuing all of
its certificates using the new key.

Every certificate is signed by exactly one algorithm, and there is no
problem with the algorithm being
either "a" or "b". RPs understand both "a" and "b" before this
happens. There is no requirement for
keeping more than one certificate, so there is no exponential problem.
(Each cert identifies algs by OID.)

And furthermore, the re-issuing is done unilaterally by each CA,
meaning each CA can choose to do so
(or not!) any time after the "go" date. This can happen at any time,
in any order, independently.

Note very well: The most important aspect of this is, that _each_ CA,
in this model, has the ability to roll back
unilaterally, since both algorithms are valid. There are no timing or
hierarchy dependencies to this.

In fact, the only time there is a need for ensuring all CAs have done
so, is when there is a "C -> B" update.

All that needs to happen for "C -> B" is for every CA to have
re-issued their certs using suite B (alg "b" only),
by that date, and to stop accepting requests with public keys of alg
"a" at that time.

Again, at no time in this transition are duplicate certs needed
(neither 2 nor 3, no exponentiation).
And the re-issuing is done unilaterally by each CA, with no top-down
requirement.

You are right on this issue:
- The RPs and PoP rules definitely mean that only one rpki-algs
document and one CP can be "current" (phase 0) at any time, globally.

However, I disagree that that single algorithm suite, needs to contain
only _one_ pair of algorithms. The wisdom of the WG,
and of expert advice from the PKIX folks, should inform the contents
of the rpki-algs, and conceivably this could contain
more than one hash/keying algorithm pair. E.g. RSA/SHA 384 and 512,
and also an EC algorithm, for a choice of 3 algs.
As long as the alg choices are justified and mainstream, I don't see
any problem with more than one.

One other point about "C -> B" transitions: the transition avoids the
top-down (or exponential) issue, if C ^ B = B,
i.e. if C is strictly a superset of B. However, nothing in this rule
places restrictions on the sizes of C or B.
It is conceivable that more than one algorithm be retired during such
a transition.
It is also entirely possible that the post-retirement set of
algorithms be larger than one.
E.g C = { a b c d e }, B = { b c e }.
This creates more flexibility in terms of WG work, and more perceived
stability operationally.
CAs are then free to choose from multiple algorithms.
Thus, zero day risks on one active algorithm don't require IETF
response, as CAs can trivially switch to another active algorithm.

I'd even go so far as suggesting pre-publishing "document sets" (-cp,
-rpki-algs, -res-certs) for multiple future alg sets,
in advance, well in advance, to give implementers and operators the
longest possible lead time.

Respectfully,

Brian

P.S. The multiple CP and  CPS goes away in the above - so long as the
rpki-algs supports multiple algs.

On Wed, Nov 9, 2011 at 1:42 PM, Stephen Kent <[email-masked]> wrote:
> small ISPs and orgs that have address space probably will not bother with a
> CPS, which is why it is a SHOULD, not a MUST. In a typical PKI context, a
> CPS primarily benefits the subjects to whom certs are issued; RPs also are
> potential CPS consumers.  In the RPKI, a "keaf" CA issues certs to itself,
> so a CPS is not of much interest for the first class of consumers. In the
> RPLI one does not get to shop around to choose a CA, so RPs don't need much
> from a CPS.
>
>
> there is only one policy (CP) for the RPKI, and it specifies algs via a
> reference to an alg spec. so, I am not sure what you have in mind here.
>
> yes, this is by design, but is irrelevant to the the alg transition design,
> which has global impact (on all RPs).
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Nov 2011 16:50:24 -0500

>is making this change. The whole 'all (non-leaf)' stuff is un-necessary.

this text makes it sound as though there is a per CA CP. The CP for 
the RPKI is global. One possibility is that the CP is updated to 
refer to two alg suites, and two policy OIDs, supplanting the old CP. 
Since the changes would be limited to a vert small part of the CP, it 
is not clear that one would want to have multiple CPs in place for 
the RPKI at the same time. Also, removing the alg description from 
the CP was intended to make the change to a new alg suite more 
modular. Still, the difference between two CPs or one is not so 
critical to this discussion.

>CP used by the parent CA).

Every CA nominally has a CPS, so part of the statement above is 
confusing. There are limitations to what a CA can do vs. what algs 
its parent supports, e.g., because of PoP.

>It needs internal consistency. There is no further requirement on

not entirely true.  each CA MUST perform PoP (3.2.1 of the CP) when 
issuing a cert to a subordinate CA. To perform PoP, the issuer must 
be prepared to deal with the alg in the subordinate CA's public key 
info.

>published CP with new OID be supported by RPs.

Top down is strongly motivated because of the PoP issue, and because of the
repository growth issue. the WG agreed to mandate top down alg 
transition last year (July, 2010), after a briefing at IETF 78. See 
the proceedings for details.

>of CP documents, or at some point an old CP could be moved to historic or

The very brief description provided above does not contain sufficient 
detail to enable it to be compared to the current proposal. it also 
fails to address issues such as PoP, repository growth, and the 
burden imposed on CAs and RPs to support algs forever, if some small 
set of CAs or RPs choose to not transition.

>case of (but not a requirement that) _an_ older algorithm is dropped

We do not believe that alg suite changes are unilateral decisions by 
CAs, for the various reasons cited above.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Nov 2011 16:28:04 -0500

Brian,

...

When three individuals from the same organization begin to comment on 
a WG document during last call, and two of the individuals have no 
history of substantial participation in the WG, one begins to 
question whether this is mere coincidence. Your reference to 
"colleagues" struck me as odd (based on 25 years of reading and 
posting messages on IET WG lists), if you didn't mean to refer to 
Eric and Denny.

...

>- not using any email-address that would suggest affiliation -

Using an address that obscures ones organizational affiliation has 
the potential to raise questions rather than  deflect them.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Wed, 9 Nov 2011 21:43:00 -0500

> so, this is a Verisign critique, provided by you, Eric, and Danny?

Steve, 
Not that I need to justify or explain this to you or anyone else here...  I
agree it is quite interesting that we all arrived at similar conclusions with 
NO express coordination on this end - perhaps it's indicative of finally
giving due consideration to what operationalizing and being held captive 
to such things entails - not simply 'running code, [standards], and run 
away', having to operationalize certainly impacts perspective.

The purpose of last call is to encourage folks to review the documents, 
I'd have thought you would welcome such reviews, unless the goal is 
for "the authors" to simply prescribe to the working group and use SIDR 
as a publication medium for work done outside the IETF.  Furthermore, 
given the barrage of documents that will eventually lead to operational 
requirements for some folks involved in these efforts, I'm very concerned 
they'll not get proper review.

BTW: if you'd really like to evaluate contributions and funding sources
in full let me know, I'm sure I can plot some dependency graphs for you ;-)

I'll say no more on this topic here and stand by the technical merit of 
comments made -- if ANYONE would like more details on any of this 
find me in TPE.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 9 Nov 2011 22:01:21 -0500

> this WG has produced.  My thanks to the editors for their efforts.

Sam, 
So am I crazy for thinking that putting all this effort in place and then simply
saying "just use expired certificates, even after rollovers, and even from the 
algorithm that you just rolled over from, and even though they may have 
previously been in CRLs but aren't now because they're expired" is even 
remotely acceptable?

I don't see how we can publish this until that issue is resolved.

-danny

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 10 Nov 2011 11:09:49 +0100

Danny,

Thank you for your comments and please see the response to your comments. Sorry for the delay.

Roque.

> 
> On Oct 20, 2011, at 10:50 AM, Sandra Murphy wrote:
> 
>> The authors have requested a WG LC for draft "Algorithm Agility Procedure for RPKI."
>> 
>> The document and the draft version history are available at
>> http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03
>> 
>> The last call will end Thu, 3 Nov 2011 (AOE).
> 
> 
> ---------------------------------------
> Substantial;
> 
> ---
> In S 4.6  (Phase 3) you state that all signed product sets are available
> using both algorithms and all RPs MUST be able to validate using either 
> suite.  Further, you state that an object that validates using either 
> Algorithm Suite A or Algorithm Suite B MUST be considered valid, 
> but in the subsequent sentence it is "RECOMMENDED" that RPs utilize
> only Suite B for validation [throughout Phase 3].  
> 
> Is the recommendation you're making that if product sets are available 
> via both Algorithm Suite A and Algorithm Suite B then the Suite A product
> sets SHOULD NOT be validated by RPs in order to minimize processing 
> overhead and the probability of cryptographic vulnerabilities resulting
> in downgrade attacks? 
> 
> Or SHOULD NOT be validated by RPs unless Algorithm Suite B validation 
> failure occurs, then fallback to the Algorithm Suite A product set  
> should be considered?  Or something else?  S.6 guidelines provide "As 
> a general rule, the validation of signed objects using different 
> algorithm suites are independent and the RP MUST NOT keep any 
> relationship between the different hierarchies", which seems to be 
> in conflict with the recommendation above unless some implementation 
> optimization or minimization of vulnerability to downgrade attacks 
> is being contemplated?

The intention was to let the RP to try to use Alg B first to facilitate the transition. I agree with your that the text was not clear.

What about this new text for section 4.6?

"Phase 3 starts at the RP Ready Algorithm B Date.  During this phase,  all signed product sets are available using both algorithm suites and   all RPs MUST be able to validate them using either suite.  An object that validates using either Algorithm Suite A or Algorithm Suite B  MUST be considered valid. It is RECOMMENDED that, in preparation for Phase 4, RPs utilize Suite B as the first and preferred option for validation throughout this phase. Thus, for example, an RP SHOULD try to validate the sets of signed products retrieved from the Algorithm Suite B repository first. 
If this effort fails (relative to the local validation policy), the RP SHOULD revert to using the Algorithm Suite A repository."

For your second comment, it is clear that the RPKI system will be vulnerable to downgrade attacks until the process is completed (EOL date). I believe this is captured somehow in the Security Considerations section when it says: "The procedure described in this document will take months or years to complete an algorithm transition. During that time, the RPKI system will be vulnerable to any cryptographic weakness that may have triggered this procedure.".

We can add some specific text:
"During that time, the RPKI system will be vulnerable to any cryptographic weakness that may have triggered this procedure (i.e. downgrade attack)."

> 
> ---
> Whatever the recommended behavior, how would it also change in Phase 4
> (Twilight), where a RP MAY continue to validate signed product sets
> using Suite C (old)?  If there's a failure in validation of the 
> current algorithm then should it use the "old" objects?  You seem to 
> suggest in S.6 that this is fine, but not in S.4.7?
> 

(Roque) Would a simple reference to section 6 make the trick?

> I think some more explicit guidelines about what to do and what not 
> to do would be useful in both Phase 3 and Phase 4 behavior that aligns
> with S.6 and clarifies the above issues would be of benefit.

(Roque) Again, I can add a reference to S.6.

> ---
> Also, in S.6 it's not clear to me what you mean by "instance of a 
> product" and "instances of such products", did you mean "signed 
> product sets" or something else?  If the former, which I think you 
> did, then it would be really useful if this "MUST contain the same
> resources" was provided much earlier in the document. 
> 
> "A failure to validate one instance of a product, under either 
> algorithm Suite MUST NOT cause the RP to reject the other instance 
> of the product. Because both instances of such products MUST contain 
> the same resources, relying on either instance will yield the same
> outcome."

(Roque) I am fine on adding this text.

> 
> Whereas in Phase 4 both may not even exist, correct?  

(Roque) Correct but also in Phase 1 and of course Phase 0.

> ---
> And given the above, if they "MUST contain the same resource", yet 
> S.7 says revocations are handled independently (even though during 
> phase 2 and phase 3 the "two certificate hierarchies are designed to 
> carry identical information" -- what does this mean?), how do you \
> accomplish all of this in practice?

(Roque) As there are independent hierarchies, you handle independent CRLs for each CA. Unfortunately, CA software will have to handle this "pain".

> ---
> Perhaps it should be that if two hierarchies exist they should be 
> identical - however, this diverges from the guidance that algorithm
> suites must be independent and the RPs MUST NOT keep any relationship
> between the different hierarchies.  This applies to "fallback" 
> implementation behaviors as well, I guess...

(Roque) No "fallback" is specified. 

> 
> Also, general guidance that as long as "old" or Algorithm Suite C 
> data is considered in parallel to or IF "current" algorithm fails, 
> the cryptographic vulnerabilities that triggered the rollover in the 
> first place may well result in downgrade attacks.
> 

(Roque) Again, you are vulnerable until EOL and we can be more precise in the text in the Security Section as referred before.

> ---------------------------------------
> Minor nits:

(Roque) Thanks, all corrected for next version

Thanks again for your review.

Roque

> 
> ---
> S 3 Terminology 
> 
> -
> s/conventions use din examples/conventions used in examples/
> 
> -
> Two occurrences of this ("CA Y" & "CA Z"):
> 
> s/used in examples this document/used in examples in this document/
> 
> 
> ---
> S 4.2 Process Overview
> 
> -
> s/prohibit a CA issuing/prohibit a CA from issuing/
> 
> 
> ---
> S 4.7 Phase 4
> 
> s/figure describe a possible/figure describes a possible/
> 
> ---
> S 5
> 
> s/implementing a different resource classes/implementing different resource classes/
> 
> 
> ---
> S 11
> 
> s/set will not longer be valid/set will no longer be valid/
> 
>

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 10 Nov 2011 11:17:43 -0500

Steve,

This is a ridiculous question, and the implication is a completely false characterization of my involvement.  For the record: I am participating as an individual only.

Eric

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Nov 2011 16:48:11 -0500

At 11:17 AM -0500 11/10/11, Eric Osterweil wrote:
>This is a ridiculous question, and the implication is a completely 
>false characterization of my involvement.  For the record: I am 
>participating as an individual only.
>
>Eric

Eric,

The question was not ridiculous, given the context and the terms that 
Brian used. Nonetheless, I accept your assertion that you are not 
colluding with our "colleagues."

Steve

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 11 Nov 2011 20:47:23 +0000

Guys, guys, guys.

Steve: making reference to a person's company concentrates too much on the personal.  Please be more careful.

Brian, Eric:   If you meant "some individual contributors who I happen to know and discuss this with", saying "my colleagues" was subject to misinterpretation, especially in light of this recent energetic exchange.  

--Sandy, speaking out for civility as wg chair

________________________________________
From: [email-masked] [[email-masked]] on behalf of Eric Osterweil [[email-masked]]
Sent: Thursday, November 10, 2011 11:17 AM
To: Stephen Kent
Cc: [email-masked] list
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

Steve,

Eric

________________________________________
From: [email-masked] [[email-masked]] on behalf of Brian Dickson [[email-masked]]
Sent: Wednesday, November 09, 2011 3:07 PM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

Brian

---

From: Stephen Kent <[email-masked]>
Date: Sat, 12 Nov 2011 03:13:31 -0500

At 8:47 PM +0000 11/11/11, Murphy, Sandra wrote:
>Guys, guys, guys. Steve: making reference to a person's company 
>concentrates too much on the personal.  Please be more careful. 
>Brian, Eric:   If you meant "some individual contributors who I 
>happen to know and discuss this with", saying "my colleagues" was 
>subject to misinterpretation, especially in light of this recent 
>energetic exchange.  --Sandy, speaking out for civility as wg chair

I concur with your dual observations above.

Hope we can now move ahead with the discussions.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Sun, 13 Nov 2011 17:14:20 -0500

Dear SIDR-WG,

Since my original message was pretty long and detailed, and it does
not appear anyone has made it through it yet, let me try to summarize
the main issues with which it is concerned.

The current proposal focuses on ending support for Algorithm A.

IMHO, it does so at the expense of the process by which support for
Algorithm B is introduced.

What I'm suggesting is, that instead of tying the two together, each
be handled separately.

And I'm suggesting that providing a path for early and widespread (but
not necessarily universal) adoption of "B", without regard to ending
support for "A", is more important than ending "A".

(Obviously, starting "B" and ending "A" can't be entirely independent,
since removing A before B is supported, would be illogical in the
extreme.)

It may be premature, as well, to suggest the overall strategy before
getting significant input from ICANN/IANA folks who will be prime on
the trust anchor and root certificates of the system, and operational
processes and strategies for making changes to them.

ICANN/IANA's experience doing similar things in signing the DNSSEC
root, and the processes they used, may better inform the "agility"
document.

NB: The most difficult thing about ending "Algorithm A" is stopping it
being used. This can be done independently, by having CAs delete certs
using "A", or by having RPs have a "knob" to say, "don't use Algorithm
'A'". I suggest both should be done. It's dead easy, IMHO.

The difficulty in introducing "Algorithm B" is much more substantial.
It involves new code for CAs, new code for RPs (multiple vendors,
multiple hardware platforms, many code streams, etc.). There are
interoperability requirements in three directions at least (CA-CA,
rtr-rtr, and rtr-CA). It also pretty much requires non-lab
experimentation, which means having certs issued which involve at
least one signature using "B". It also means that experimentation may
involve announcing BGPsec prefixes using such certs, before all RPs
understand "B".

There might be a place for describing use of an "alternative trust
anchor" to enable testing using production systems, without directly
impacting production certificates. New CA code supporting "B" (and
"A") could be deployed, and a chain of trust using a different trust
anchor and a mix of "A" and "B" certs (either/or at each delegation
point), would allow for exercising the code while maintaining the
"real" cert chain, e.g. as a final test before actually replacing
"A"-signed certs with "B"-signed certs. Trust anchors can be
established at any CA, and while the root "CA" is one place one would
expect this to be done, it isn't the only place it is possible (and
advisable) to do so.

Putting this into the phases is important, specifically so everyone
knows this activity is expected, and that all implementers are
prepared (in their implementations) to be sensible in their code.
Having those phases have flexibility in them, and having them
coordinated with feedback loops built in, is a much smarter way to go
than having deadlines. I would rather see full top-to-bottom support
for all-B certs, than worry about some certs that still have one or
more "A" signatures in them. Earlier transition to "B" at the root is
possible if flexible strategies are employed. Providing RPs with "no
A" knobs makes the CA-signing side of ending "A" cert signatures much
less of a security-critical issue.

The scalability issue (avoiding exponential growth in number of
published certs) means every cert should be signed with only one
algorithm.

This results in a single major requirement - RPs who want BGPsec to
work, must be able to handle Algorithm "B" certs, before the root is
signed with "B". This is _very_ different from requiring top-down
deployment.

Coordinating this is very important, but IMHO, does not require two
"parallel" chains of certs (all "A", and all "B" respectively). This
would be a "flag day", or close enough to it to be ill advised.

Having RPs having code that supports "B", with knobs for "allow-B" and
"allow-A", means RPs will have sufficient control to limit exposure to
security issues or operational issues, specific to "A" or "B". It also
allows deployment of new code without exposure to premature use of
prefixes used for testing. It also means a final wave of "B"
enablement, followed by a "B" root-signing, can be coordinated without
the kind of risk that a no-fall-back scenario (which the current
document requires) at all. A problem with a B-signed root can be fixed
by having the A-signed root re-deployed, either by a new A signature
or by rolling back the old signatures.

The original email below, goes into some of the "how" and "why" to
demonstrate the feasibility of this approach, and suggestions for how
this can be incorporated into a newer version of the "agility"
document.

(If this were easy, my emails would be much shorter.)

Brian

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 15 Nov 2011 02:56:22 +0000

One clarification.  I included Eric below as he was one of those who took offense at the conclusion Steve drew from Brian's remark about colleagues.  Unfortunately, "you" is both singular and plural, so the text as written implies that Eric colluded in the remark about "colleagues".  I should definitely have said "If Brian meant".

--Sandy, to clarify my previous speaking as wg chair

________________________________________
From: Murphy, Sandra
Sent: Friday, November 11, 2011 3:47 PM
To: Brian Dickson; Stephen Kent
Cc: [email-masked]
Subject: RE: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

Guys, guys, guys.

Steve,

Eric

Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Nov 2011 11:08:19 +0800

> One clarification.  I included Eric below as he was one of those who
> took offense at the conclusion Steve drew from Brian's remark about
> colleagues.  Unfortunately, "you" is both singular and plural, so the
> text as written implies that Eric colluded in the remark about
> "colleagues".  I should definitely have said "If Brian meant".

uh, when is recess and can we play skitter ball?