Re: pgp signing in van

Theodore Ts'o <tytso@mit.edu> Sat, 07 September 2013 15:29 UTC

Return-Path: <tytso@thunk.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED2521F8467 for <ietf@ietfa.amsl.com>; Sat, 7 Sep 2013 08:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.833
X-Spam-Level:
X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 yiyRE9y3QPdK for <ietf@ietfa.amsl.com>; Sat, 7 Sep 2013 08:29:44 -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 A174921F9C0A for <ietf@ietf.org>; Sat, 7 Sep 2013 08:29:44 -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 1VIKSD-0007W3-Vt; Sat, 07 Sep 2013 15:29:42 +0000
Received: by closure.thunk.org (Postfix, from userid 15806) id B7AD75807FA; Sat, 7 Sep 2013 11:29:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1378567780; bh=Wmc0kYS08DAqYvz3mfuJhFycsNsXql6TqBifrAOq1ss=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qQDJpp+i5/VzEqZyOsecfU1pjRxpR7MDbWBvT7VupAZvnKLzJNqzSbMRsLfWN3xWj +mSOb0uKOSK+wCHzSVjOIgoxDjfX3cpmnPHIt8jmIdOBeSyWBFKHcT+9YAerx/dpMd /D6NcGPIsY+LbEUtwlssusrm80OVsSiE6+/s/Skk=
Date: Sat, 07 Sep 2013 11:29:40 -0400
From: Theodore Ts'o <tytso@mit.edu>
To: Phillip Hallam-Baker <hallam@gmail.com>
Subject: Re: pgp signing in van
Message-ID: <20130907152940.GA19067@thunk.org>
References: <m2zjrq22wp.wl%randy@psg.com> <2309.1378487864@sandelman.ca> <522A5A45.7020208@isi.edu> <CA2A6416-7168-480A-8CE1-FB1EB6290C77@nominum.com> <522A71A5.6030808@gmail.com> <6DE840CA-2F3D-4AE5-B86A-90B39E07A35F@nominum.com> <CAMm+Lwj_+Ft0Wy6=wQeFxfkRSuyOZjLy_rKUz1PZRvJy-ixAuA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+Lwj_+Ft0Wy6=wQeFxfkRSuyOZjLy_rKUz1PZRvJy-ixAuA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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
Cc: IETF Disgust <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 07 Sep 2013 15:29:45 -0000

On Fri, Sep 06, 2013 at 11:39:59PM -0400, Phillip Hallam-Baker wrote:
> For purposes of email security it is not about the keys at all. It is the
> email addresses that are the real killer.
> 
> I can be very sure that I have the right key for ted.lemon@nominum.com but
> is that who I know as Ted Lemon?

But if the I-D's that you are reviewing and the protocol suggestions
are coming from ted.lemon@nominum.com, does it matter?

And if you subsequently then meet a bag of protoplasm at a
face-to-face meeting who can speak in great technical detail about his
I-D's, and who hands you a business card which says
ted.lemon@nominum.com, does it really matter what is on the
government-issued I-D?

> One value of IETF key signing parties is that we get a better assurance
> that we know the email address we are sending to is the address of the Ted
> Lemon that participates in IETF than we can possibly get through Web of
> Trust where someone may be signing a key in all good faith but for the
> wrong person.

Exactly.  This is basically how we bootstrapped the GPG keyring used
for Linux kernel submissions after the kernel.org security breech two
years ago.  We required everyone to get new GPG keys, thus forcing a
key rotation, and we did in-person key verification of people, most of
whom we had met at other Linux conferences previously, so we knew who
we were dealing with.

We did look at each other's government-issued ID's, but honestly, that
was much less important than my being able to say, something like,
"Why yes, that's James Bottomley, the SCSI maintainer and someone with
whom I've worked with for the past decade, on mailing lists and
conference calls and at conferences all over the world."

For this reason, it's actually better to do mini-key signings (or
really, exchange of GPG key fingerprints) at the end of each working
group session, rather than trying to do one big key signing one
evening.  The latter is more time-efficient, but the former is what's
actually important, since it will be the working group members who
know each other the best.

The other thing which is useful for a community to maintain is a
centralized keyring of all of the members, backed up on a time stamped
WORM drive, where keys only get added to the keyring after it has been
signed by a threshold number of trusted core signers.  (Initially, for
kernel.org there were only four or five us that were core trusted
signers, and we were people who knew each other and had been working
on the Linux kernel for a long time.)

Of course, all of this is not going to solve the problem of someone
getting bribed by some state actor to introduce some vulnerability
into a codebase, or into some IETF- or NIST- approved
standards/protocol document.  After all, government ID's don't come
with a stamp, "I am an NSA stooge."  :-)

						- Ted