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, 9 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