Re: Security for various IETF services
Tim Bray <tbray@textuality.com> Wed, 09 April 2014 20:15 UTC
Return-Path: <tbray@textuality.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562A21A0321 for <ietf@ietfa.amsl.com>; Wed, 9 Apr 2014 13:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_3nDlj2n8NQ for <ietf@ietfa.amsl.com>; Wed, 9 Apr 2014 13:15:02 -0700 (PDT)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 261701A0397 for <ietf@ietf.org>; Wed, 9 Apr 2014 13:15:02 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id ld13so2506683vcb.5 for <ietf@ietf.org>; Wed, 09 Apr 2014 13:15:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.221.4.66 with SMTP id ob2mr2251207vcb.28.1397074501388; Wed, 09 Apr 2014 13:15:01 -0700 (PDT)
Received: by 10.220.98.73 with HTTP; Wed, 9 Apr 2014 13:15:00 -0700 (PDT)
X-Originating-IP: [208.54.5.149]
Received: by 10.220.98.73 with HTTP; Wed, 9 Apr 2014 13:15:00 -0700 (PDT)
In-Reply-To: <20140409200814.GA15303@thunk.org>
References: <20140409154919.11E6118C106@mercury.lcs.mit.edu> <534580AF.4080602@dcrocker.net> <20140409200814.GA15303@thunk.org>
Date: Wed, 09 Apr 2014 13:15:00 -0700
Message-ID: <CAHBU6ivQbta_kW8L1JWUoELyJWpX53Km60QOnk7xk4qoYNwt-A@mail.gmail.com>
Subject: Re: Security for various IETF services
From: Tim Bray <tbray@textuality.com>
To: Theodore Ts'o <tytso@mit.edu>
Content-Type: multipart/alternative; boundary="089e0122a9246160c704f6a1c1dc"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/gSQYd23FylyxbtPNmWVigqBW16Q
Cc: dcrocker@bbiw.net, IETF Discussion <ietf@ietf.org>, Noel Chiappa <jnc@mercury.lcs.mit.edu>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2014 20:15:07 -0000
While not a solution, I'm thinking the keybase.io 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" <tytso@mit.edu> 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 kernel.org 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 kernel.org 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 > >
- Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Fred Baker (fred)
- RE: Security for various IETF services ned+ietf
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Pranesh Prakash
- Re: Security for various IETF services Fred Baker (fred)
- Re: Security for various IETF services Douglas Otis
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Fred Baker (fred)
- Re: Security for various IETF services Brian E Carpenter
- Re: Security for various IETF services Randy Bush
- Re: Security for various IETF services Scott Brim
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services ned+ietf
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Randy Bush
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Martin Rex
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services t.p.
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Hector Santos
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Hector Santos
- Re: Security for various IETF services Dick Franks
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Pranesh Prakash
- Re: Security for various IETF services Martin Thomson
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Stewart Bryant (stbryant)
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Hector Santos
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services ned+ietf
- Re: Security for various IETF services Tim Bray
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services David Morris
- RE: Security for various IETF services Christian Huitema
- RE: Security for various IETF services l.wood
- Re[2]: Security for various IETF services mohammed serrhini
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Randy Bush
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services S Moonesamy
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Brian Trammell
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Spencer Dawkins
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Ted Lemon
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services Matthew Kaufman (SKYPE)
- RE: Security for various IETF services Eric Gray
- Re: Security for various IETF services t.p.
- Re: Security for various IETF services Scott Brim
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Phillip Hallam-Baker
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Yoav Nir
- Re: Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Yoav Nir
- Re: Security for various IETF services Noel Chiappa
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Tim Bray
- Re: Security for various IETF services Steve Crocker
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Phillip Hallam-Baker
- Web of trust at Internet Scale Sam Hartman
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Mark Andrews
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Jelte Jansen
- Re: Security for various IETF services Stephen Kent