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

Stephen Kent <> Tue, 08 November 2011 23:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF84C1F0C70 for <>; Tue, 8 Nov 2011 15:44:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.43
X-Spam-Status: No, score=-106.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gc1qZT9fu4oC for <>; Tue, 8 Nov 2011 15:44:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 300A921F8540 for <>; Tue, 8 Nov 2011 15:44:18 -0800 (PST)
Received: from ([]:49186) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1RNvKz-000Dqe-2c; Tue, 08 Nov 2011 18:44:17 -0500
Mime-Version: 1.0
Message-Id: <p06240808cadf618efaa8@[]>
In-Reply-To: <>
References: <> <p06240803cad6af1b0ce7@[]> <> <p06240803cad951813fd9@[]> <> <p06240802cadde494171b@[]> <> <p06240811cade1873e723@[]> <>
Date: Tue, 08 Nov 2011 18:37:38 -0500
To: Eric Osterweil <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: " list" <>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Nov 2011 23:44:19 -0000


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 
>and ensures agreement of the various dates?

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

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
>CA is simply orphaned and cannot participate in routing anymore 
>(until they catch back up)?

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

>  >From these three questions, I came to the following clarification 
>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,
>there may need to be a rollback procedure specified.

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 
>the current design's complexity.  It's possible that we will just 
>simply come to loggerheads here, but (design issues aside) do people 
>CA operators should have the ability to protect themselves as soon 
>as they can move to a new algo?

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
>having that requirement.  So, perhaps it would make sense to soften it here?

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