Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
Brian Dickson <brian.peter.dickson@gmail.com> Thu, 17 November 2011 17:50 UTC
Return-Path: <brian.peter.dickson@gmail.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 8271B1F0C80 for <sidr@ietfa.amsl.com>; Thu, 17 Nov 2011 09:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.493
X-Spam-Level:
X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 a-wlKURZ4EX7 for <sidr@ietfa.amsl.com>; Thu, 17 Nov 2011 09:50:22 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42F0E1F0C78 for <sidr@ietf.org>; Thu, 17 Nov 2011 09:50:22 -0800 (PST)
Received: by faap16 with SMTP id p16so4814242faa.31 for <sidr@ietf.org>; Thu, 17 Nov 2011 09:50:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7RFYBVohO2uLNY0gAzK2eIEBx0+FfIPWfx7JhIfnvq0=; b=dk8iyhGtKLiGi7IbiwFCJcX5nL/De1rrCFIsSVFILHZVL9kSw5ghasacp5PqW+UH2O eXxxYb81r8YrYZEAQFaPRnocqrBi8UMCJVQD16D5t0HLUsFYOOh6+MuusMLdiIffJRF9 eDHuWjjmPtr2tSaIpoLJoPw7s9pz0IOy+1USs=
MIME-Version: 1.0
Received: by 10.205.120.2 with SMTP id fw2mr26234720bkc.10.1321552221284; Thu, 17 Nov 2011 09:50:21 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Thu, 17 Nov 2011 09:50:20 -0800 (PST)
In-Reply-To: <p06240801cae63c0d5322@172.20.1.65>
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> <BDA75A7E-2B2D-44A5-A18F-2D7DA01DF3A2@verisign.com> <p06240808cadf618efaa8@128.89.89.6> <E9BAE21C-A8EF-4D07-90C1-E8A5FD7F00E7@verisign.com> <p06240803cae62a2b13af@128.89.89.129> <CAH1iCiotmm47yZ_S_JyY8a0cODPFcnLe-CUSbzjYm7fdPcZDkA@mail.gmail.com> <p06240801cae63c0d5322@172.20.1.65>
Date: Thu, 17 Nov 2011 12:50:20 -0500
Message-ID: <CAH1iCioh1em9KjhFq2vTijpAOogL4nnc5=k0Eg3NFejVVdACRQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Thu, 17 Nov 2011 17:50:23 -0000
On Thu, Nov 17, 2011 at 12:13 AM, Stephen Kent <kent@bbn.com> wrote: > At 10:25 PM -0500 11/13/11, Brian Dickson wrote: > (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. > > 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. > 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: > - RPs speak "B". > > - CAs can process "B". > > 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) > 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. 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
- [sidr] WGLC for draft-ietf-sidr-algorithm-agility… Sandra Murphy
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Arturo Servin
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Paul Hoffman
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Samuel Weiler
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Randy Bush
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Sean Turner
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil