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