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

Eric Osterweil <eosterweil@verisign.com> Tue, 08 November 2011 19:39 UTC

Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2465B11E8086 for <sidr@ietfa.amsl.com>; Tue, 8 Nov 2011 11:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.589
X-Spam-Level:
X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAAsxwLQPMvM for <sidr@ietfa.amsl.com>; Tue, 8 Nov 2011 11:39:28 -0800 (PST)
Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id DCE8411E8085 for <sidr@ietf.org>; Tue, 8 Nov 2011 11:39:27 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP; Tue, 08 Nov 2011 11:39:27 PST
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA8JcZ4Y020809; Tue, 8 Nov 2011 14:38:35 -0500
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.35]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 14:38:35 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <p06240811cade1873e723@[128.89.89.6]>
Date: Tue, 8 Nov 2011 14:38:30 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <BDA75A7E-2B2D-44A5-A18F-2D7DA01DF3A2@verisign.com>
References: <CAD6DA02.1C611%terry.manderson@icann.org> <p06240803cad6af1b0ce7@[193.0.26.186]> <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <p06240803cad951813fd9@[193.0.26.186]> <CB6FE413-BEC2-4910-AEEF-98D6EAFD4E83@verisign.com> <p06240802cadde494171b@[128.89.89.6]> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> <p06240811cade1873e723@[128.89.89.6]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 08 Nov 2011 19:38:35.0403 (UTC) FILETIME=[01572DB0:01CC9E4E]
Cc: "sidr@ietf.org list" <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2011 19:39:29 -0000

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

> 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.


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