Re: Security for various IETF services

Tim Bray <> Wed, 09 April 2014 20:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 562A21A0321 for <>; Wed, 9 Apr 2014 13:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P_3nDlj2n8NQ for <>; Wed, 9 Apr 2014 13:15:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 261701A0397 for <>; Wed, 9 Apr 2014 13:15:02 -0700 (PDT)
Received: by with SMTP id ld13so2506683vcb.5 for <>; Wed, 09 Apr 2014 13:15:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2nC2ho/ttrs2D/Z8cR3kKfAjhtp3OLW/fQQwMVDHBTY=; b=kIPJ3VJBaTKMwkCkgZzkL5Y3l1CgSm6tqBmokihHOox95DEBiPwYMNxokcx8rlUe8T iZ+2nOCaFEMdxFosiKtGRcOLq91mlxwDjH8DL30mqfVTFdSgGVsI8FN/WTrQxuKTOVHm U9WEF0VihSDgrFERkHBgaiBclXPeS1LhOrwUWDCaWFc+vNOjgnTtMZz8cfcvHPNs9Dp9 EejLI7DzXFNO0FNYrWRfZOWBnQbLwIR6A12MbRoEzTdkTVRq6hni4GE1g5zogI8fRzHq yqiEt+WvwUTymzR5CliNvOP1HkYKcbQu9ynsnNL9xIjWtitaXCjBjyAOl656BgbdXhsd 4YSw==
X-Gm-Message-State: ALoCoQll6jcxH1ng73FSmjxrWN6oMYuz/kczDs6CDTEWgYb6bT192vO0QZ73AD4FDpfa2gYOF5ii
MIME-Version: 1.0
X-Received: by with SMTP id ob2mr2251207vcb.28.1397074501388; Wed, 09 Apr 2014 13:15:01 -0700 (PDT)
Received: by with HTTP; Wed, 9 Apr 2014 13:15:00 -0700 (PDT)
X-Originating-IP: []
Received: by with HTTP; Wed, 9 Apr 2014 13:15:00 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 9 Apr 2014 13:15:00 -0700
Message-ID: <>
Subject: Re: Security for various IETF services
From: Tim Bray <>
To: "Theodore Ts'o" <>
Content-Type: multipart/alternative; boundary=089e0122a9246160c704f6a1c1dc
Cc:, IETF Discussion <>, Noel Chiappa <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Apr 2014 20:15:07 -0000

While not a solution, I'm thinking the work is a step in a
useful direction.  Just a directory of accounts where you can associate a
keypair with verifiable assertions that its holder controls a particular
Twitter/github account and Web server and DNS.
On Apr 9, 2014 1:08 PM, "Theodore Ts'o" <> wrote:

> On Wed, Apr 09, 2014 at 12:17:35PM -0500, Dave Crocker wrote:
> >
> > The interesting premise in the suggestion is that a web of trust key
> > management model is useful at Internet scale.
> >
> > I don't understand why anyone believes that.
> The problem is that nearly all solutions to the PKI problem I've seen
> to date fall into three classes, all of which have problems (which is
> why there is the oft-retold joke about how any protocol which requires
> a PKI is doomed).
> 1) The current "race to the bottom" multiple competing CA model, which
> while scalable, has had some rather spectacular failures, of which
> Diginotar is only one example.
> 2) Trust the government to run the CA ("I'm from the government, and
> I'm here to help!") --- which raises questions of "which government"
> and "how do you trust that someone won't invoke 'national security' as
> the root password to the Constitution / Fundamental Rights" to abuse
> the trust that the government would have it served as the CA?
> 3) The PGP web of trust model, which doesn't scale to the Internet,
> but which is good enough for small communities for which high trust is
> extremely important (for example, such as Debian Developers and the
> Linux keyrings).
> I suspect #1 could have gotten traction as far as usage is concerned,
> if the pricing model for a given level of security had been attractive
> enough and if it had been sufficiently easy for mere mortals to get
> x509 user certificates.  But as it is, #3 has been winning out as far
> as usage because the people who care enough about security to go do
> the extra work are also the folks who (a) don't trust the CA's, and/or
> (b) are too cheap to be willing to pay what the CA's want to charge,
> and so the PGP web of trust model is quite suited for their needs.
> At the end, because the use cases and the requirements for different
> communities are quite different, I think the only thing that has a
> chance is some kind of hybrid solution.  Because questions of format
> aside, the main difference between all of these schemes is who do you
> put in your trusted root, and how much cerifying delegation do you
> allow?
> If you're the US military and you let the NSA handle all of your key
> management needs, that's one answer.  If you're a web browser, you
> mark several dozen or several hundred CA's (depending on how you
> count), and that's another answer.  If you're a Linux kernel developer
> and you want to get an account on and be able to sign git
> tags, you need to either be directly signed by one of four or five
> trusted root individuals, or have 3 signatures by keys that are signed
> by the root individuals, and that's yet another answer.
> What we really need is widely deployed software which can support all
> of these different use cases, and deal with the fact that there is
> significant base deployed that will add resistance to switching to a
> whole new certificate format.  (For example, x509 certs have a large
> amount of infrastructure, but so do PGP --- there are smart card and
> Yubikey NEO's that support storage of private keys for PGP and ssh on
> hardware tokens.)  And so I might want to use one of PKI policy when
> validating e-mail sent by a fellow kernel developer, and use a
> different PKI policy if I'm talking to a stranger someone for whom the
> only authentication path is via some "race to the bottom" cerifying
> authority, and where my trust requirements might be different.
> I'll note that I can mostly do that today, because my mail user agent
> (mutt) supports both S/MIME and PGP.  So any proposed solution should
> ideally be better than what we can do today with that kind of support
> (namely, adding both S/MIME and PGP into the mail client).
> Cheers,
>                                                 - Ted