Re: Security for various IETF services
Theodore Ts'o <tytso@mit.edu> Wed, 09 April 2014 20:08 UTC
Return-Path: <tytso@thunk.org>
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 583241A024F for <ietf@ietfa.amsl.com>; Wed, 9 Apr 2014 13:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.637
X-Spam-Level:
X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham
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 mOv9qDPbqxWr for <ietf@ietfa.amsl.com>; Wed, 9 Apr 2014 13:08:22 -0700 (PDT)
Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1791A0230 for <ietf@ietf.org>; Wed, 9 Apr 2014 13:08:18 -0700 (PDT)
Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from <tytso@thunk.org>) id 1WXynB-0007OH-IC; Wed, 09 Apr 2014 20:08:17 +0000
Received: by closure.thunk.org (Postfix, from userid 15806) id EA9C05804C9; Wed, 9 Apr 2014 16:08:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1397074094; bh=kRWegHfNRnuX5SR6fvRwjsSxc+fghV9opu0MDdVBdzs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ornd91mPS/EeN9d09v7LEuqT6jxplOminK+Gg8/njf5htcoD9TBzrcy4FMTAPCqvQ L/nDrpL7Isqr4/i8P3p3owx+e1zpGoS+Ev/cnoCCRMnF5HX6CggX93xTIqXewxBsO1 9luamig4bq3Io92KM8SBuVtFiy6PRCiEDcK0nZbg=
Date: Wed, 09 Apr 2014 16:08:14 -0400
From: Theodore Ts'o <tytso@mit.edu>
To: dcrocker@bbiw.net
Subject: Re: Security for various IETF services
Message-ID: <20140409200814.GA15303@thunk.org>
References: <20140409154919.11E6118C106@mercury.lcs.mit.edu> <534580AF.4080602@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <534580AF.4080602@dcrocker.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/PsjT1Kh85iPxi_-1vw4QzOQ9Av8
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, ietf@ietf.org
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:08:27 -0000
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