[linux-elitists] Phil Zimmermann on key exchange (fwd)

[Eugene Leitl]

-- Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBMTO: N48 04'14.8'' E11 36'41.2'' http://www.leitl.org
57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3

---------- Forwarded message ----------
Date: Tue, 11 Dec 2001 19:37:52 -0500
From: David Shaw <dshaw at jabberwocky.com>
To: linux-elitists at zgp.org
Cc: Seth David Schoen <schoen at loyalty.org>
Subject: Re: [linux-elitists] Phil Zimmermann on key exchange

On Fri, Dec 07, 2001 at 11:42:26PM -0800, Seth David Schoen wrote:

> > So Phil's robot CA idea actually sounds more practical to me than
> > Brad's idea; in particular, it has better compatibility with regular
> > PGP encryption -- and it seems that it may be more robust in some
> > ways.  The robot CA is intuitive and fairly secure if you don't expect
> > active MITM attacks.
>
> The Board of Directors of EFF met today in San Francisco, and I made a
> presentation about this, in the presence of Brad Templeton and others.
> One of the conclusions was that EFF's role in implementing something
> like this is still not defined clearly enough, and we don't know what
> we could most usefully do.
>
> For example, some people like the idea of standardizing protocols
> through the IETF; others prefer a completely independent development
> of a spec (possibly with advance commitments or at least expressions
> of interest from vendors), and then submission to standards bodies
> after the technical work is more of a fait accompli.  There is some
> disagreement about who exactly should write which code, for what
> platform, and what effect it would have for different people (e.g.
> famous cryptographers, civil liberties organizations, well-known
> scientists or network engineers) to endorse various approaches in
> various places.
>
> We want to figure out more about what EFF can best do to make this
> happen.  Brad Templeton is planning to write to Phil Zimmermann, and I
> plan to write to Phil Karn and some other people.

After the Zimmermann article appeared, I emailed him and we spoke on
the phone for a few hours about the possibilities here.  He's an
interesting guy.  We discussed some concerns I had with the robot CA
concept as without client support, or a special robot keyserver along
with (or part of) the robot CA, there are some problems.  All in all,
I like his ideas for the robot CA (he had some ideas to extend this to
a robot "designated revoker" as well as a few other useful things).

> Brad was concerned that the robot CA is a single point of failure and
> an easy target for attacks (DOS, subpoena, physical intrusions); it
> _does_ hold some secret and trusted information (its own private
> signing key) and also has a uniquely valuable key which can be
> compromised -- an event which would tend to undermine the entire
> scheme.  He added that both schemes are equally secure against passive
> wiretapping, and the scheme he outlined can survive even if the
> organizations which originally supported it go away.

One possible way to address some of Brad's concerns with Phil
Zimmermann's scheme is to create a meta-key, stored offline, with some
rigidly followed procedure for its use (this should be analogous to a
non-robot CA master key handling).  Use this key to sign a number of
additional keys[1] for each robot CA.  This gives you a few
improvements - one, you have more than one robot CA, all equally
valid, so there is no longer a single point of failure.  A reasonable
optimization here would be for each robot to look for a signature from
a different robot and refuse to sign.  In the case of robot compromise
(legal or illegal), the robot's key can be revoked.  This may hurt the
people who had their keys signed by that particular robot, but does
not affect the rest.  This revision also allows the scheme to survive
if some of the robots go away - as long as the keeper of the master
key does not go away.

For me, the piece of the "get everyone using encryption" project that
Brad really hit on the head is the need for absolutely zero UI.

To do this well in the client, we're really going to need some amount
of vendor buy-in.  Without zero (or pretty darn close to zero) UI, we
can poke around with simplifying key management for years without
accomplishing much because of the "If I have to do anything to use it,
then I won't use it" mindset.  I don't really like doing the
encryption in the MTA as that puts the responsibility on a machine in
the ISP.  This machine is likely to be a far richer prize to an
attacker than a home box, as well as being far more snoopable on via
legal or illegal means.

> I want to bifurcate the issue and ask everyone here:
>
> (1) What's the best design for an "informal key exchange" scheme in
> which active MITM attacks may be permitted, but privacy against
> passive wiretapping (as well as trivial impersonation attacks) is
> maintained?  How can this be implemented with the smaller amount of
> user interface, while maintaining the largest amount of compatibility
> in both directions with existing e-mail privacy systems for
> sophisticated users?

The easiest thing to do would be a email header that contains key
information.  Loads of people do this already ("X-My-PGP-Key: ..." and
similar).  If we could standardize a format, then smart clients could
use it to automatically fetch the key.  I'd suggest some sort of URL,
for maximum flexibility.  For bandwidth and messiness reasons, I don't
really like the S/MIME feature of sending the key around all the time.

Using a new email header for this has the nice feature of not breaking
any of the current email infrastructure - any non-capable clients will
just ignore it.

> (2) What's the best way to get such a system designed and deployed to
> the general public?  How can an organization like EFF best help
> accomplish this?  Whose help do we need?

Microsoft (like it or not, they make one of the most widely used MUAs
on the planet).  AOL/Netscape.  And the developers of as many mailers
we can get to listen.  If this only happens in the open-source world,
then we're not really solving the problem.

Way back when, Netscape did a cute thing to push https: it made a big
deal of the security icons on the browser, and made sure that you knew
you did not have an encrypted connection when you submitted a form.
I'd love to see mailers scold the user this way if they tried to send
an unencrypted email.

I favor using OpenPGP as the underlying protocol for all of this as
there is wide understanding of OpenPGP and lots of code available
under various licenses, including the GPL.  Using OpenPGP also allows
"power users" to use the full OpenPGP trust model if they choose to
without affecting the people using the simplified model.

I am very interested in working on these problems with anyone else who
would like to join me.

David

[1] This could also be OpenPGP-style signing subkeys, but for a
    handful of reasons (the keyservers not handling keys like that
    very well for starters) it may better to use other keys.

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson