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

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 14 November 2011 03:25 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 7994A1F0C47 for <sidr@ietfa.amsl.com>; Sun, 13 Nov 2011 19:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.543
X-Spam-Level:
X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 jk-IWCV6UCb4 for <sidr@ietfa.amsl.com>; Sun, 13 Nov 2011 19:25:46 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2CB1F0CC1 for <sidr@ietf.org>; Sun, 13 Nov 2011 19:25:46 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so6661565bkb.31 for <sidr@ietf.org>; Sun, 13 Nov 2011 19:25:44 -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; bh=Ebk4px+AM48aCvWWPO1wEaJ+CZtPSoZFsTDg+XUMak4=; b=IPW+vCftD5I+7ypZ6ZrdIGSkcmIj0yzJocq/2WBAOkB5m0M3vkmHLmeG1TQCUJOhFl IMyPyzfdT0Xp2R5UcCN2OCv40/2lCDma2YguFGzLjW1/usujCXMEL+IijsF2Q8Nts+pE wWlVe0ad0kQYWE8/oUP/K1NBALiMQK7rAxuVw=
MIME-Version: 1.0
Received: by 10.204.130.90 with SMTP id r26mr5416257bks.46.1321241143932; Sun, 13 Nov 2011 19:25:43 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Sun, 13 Nov 2011 19:25:43 -0800 (PST)
In-Reply-To: <p06240803cae62a2b13af@128.89.89.129>
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>
Date: Sun, 13 Nov 2011 22:25:43 -0500
Message-ID: <CAH1iCiotmm47yZ_S_JyY8a0cODPFcnLe-CUSbzjYm7fdPcZDkA@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
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: Mon, 14 Nov 2011 03:25:47 -0000

On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent <kent@bbn.com> wrote:
> You suggested that we codify how the community should deal with problems
> that motivate delaying a phase transition. We're not writing the timeline
> document now, but the text at the beginning of this message is an effort to
> make sure such considerations are addressed in that document.

When you say "timeline document", do you mean "timeline for specific
implementation of the phases in this document"?

I ask because the algorithm-agility sure looks like a timeline document.

The main concerns rise from the content and order of the phases, and their
consequences.

> Phase 0 is the start of the process, when a new algorithm suite has been
> selected and the timeline published.
>
> Phase 1 requires all CAs to be able to issue certificates under Suite B.
>
> Phase 2 requires that CAs MUST publish all signed products under Suite B, as
> well as Suite A, and RP MAY be prepared to validate these products using
> Suite B.
>
> Phase 3 requires that RPs MUST be able to process Suite B signed products,
> and RPs are encouraged to validate signed products using Suite B.
>
> Phase 4 begins the phase out of Suite A.
>
>
> First, not that a CA cannot unilaterally decide to transition to a new
> algorithm. There is a requirement that the issuer of its certificate is
> prepared to accept a certificate request under the new algorithm suite
> (because of the PoP requirement).

This statement is entirely predicated on having Phase 2, as it is currently
defined, after Phase 1 (CAs ready for receiving B) and before Phase 3
(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.

Let's take a look at what happens after Phase 3:
- RPs speak "B".
- CAs can process "B".

Is this not the (only!) pre-condition required for supporting any of
the four combinations?

> If we allow CAs to "do their own thing," there is the potential for
> four combinations:
> - a Suite A certificate issued under Suite A
> - a Suite A certificate issued under Suite B
> - a Suite B certificate issued under Suite A
> - a Suite B certificate issued under Suite B
>
> The exponential growth arises if we have Suite A and B product sets at each
> tier.

I don't see the requirement to support more than one certificate
(ie of more than one of the four types.)

After Phase 1 and Phase 3, but ignoring your Phase 2, we know:
- RPs speak "B"
- CAs can accept requests with PoP == "B".

A certificate of any of the four types can be issued by any CA, and
validated by any RP.
Which type depends only on the CA (signature alg) and the subordinate
CA (key/PoP type).

There is no exponential growth _unless_ multiple cert types for each
cert are maintained,
which I disagree with as being a requirement _at_all_. I do not see a
reason to need
more than one certificate, regardless of which of the four types it is.

So, the only possible danger with allowing any CA to switch to "B"
whenever it wants,
is that should that occur before the end of phase 3 (when all RPs speak "B"),
all subordinate certificates will be at risk for not validating with
those RPs who are not
"B"-ready.

However, experimentation during the early deployment stages, almost demands for
this ability, and that there would be the expectation of such failure
by those using
(or more accurately, testing) code prior to widespread adoption.
Earliest work would
be done using leaf "B" certs, and early-deployment code. Gradually
additional levels
of testing (B-B and B-B-B), until enough traction in deployment in CA
code and RP code
has occurred. This eventually culminate with "B" root transition.

Deploying code without this incremental testing, and then expecting it
to "just work",
suggests a lack of experience and familiarity with the deployment of
new operational
code features in a multi-vendor environment on the Internet...

_Especially_ if there is no compelling reason. Can you show me what compels
the maintenance of both types of certificates, and a "fall-back-to-A" logic?

We have another term for "fall-back-to-foo" - it's called a "downgrade attack".

I'll withdraw my objection if anyone can make a truly compelling case using only
the assumptions above - Phase 1 and Phase 3, followed by widespread issuance
of production "B" certs, on a timeline entirely determined by local CA
decisions.

Brian