ietf
[Top] [All Lists]

Re: pgp signing in van

2013-09-07 10:57:56
On Sat, Sep 7, 2013 at 11:29 AM, Theodore Ts'o <tytso(_at_)mit(_dot_)edu> wrote:

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.combut
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(_dot_)lemon(_at_)nominum(_dot_)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(_dot_)lemon(_at_)nominum(_dot_)com, does it really matter what is on the
government-issued I-D?


The difference is the ability to write a validation criteria that is
auditable. People used to get really freaked out about the fact that my
former employer accepted a CostCo membership card for ID purposes entering
the building.

The control here is accountability. If you claim to be Ted Lemon and I just
accept that then it is fairly hard to see a prosecution being viable. If on
the other hand you present a fraudulent ID then you have committed two
separate acts of fraud (one obtaining, second presenting). There are
criminal sanctions possible.




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.


Which is exactly the type of community where PGP works well. The problem is
that you can't scale to populations of a billion or more by holding key
signing parties.



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."


Government issued IDs do have one big advantage and that is they allow new
people to introduce themselves into the group. They also provide a control
against long term undercover agents.

Police don't usually have access to forged documents when they go
undercover. Even intelligence agencies are forced to use them sparingly as
maintaining them is high cost.



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.


You want me to give up my coffee and biscuits?


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.)


Oddly enough that is similar to the proposal I have been looking at and Ben
Laurie has. Only instead of hardware we are looking at catenate
certificates (Harber & Stornetta hash chains) now the patent is expired.



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."  :-)


And some folk may well have been unwitting stooges.

-- 
Website: http://hallambaker.com/
<Prev in Thread] Current Thread [Next in Thread>