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

Wed Dec 12 05:07:07 PST 2001

Hi,

I have the highest regard for Phil (ever since I got PGP 1.0 off Adelante
BBS about two days after Phil released the program - I still have that
disk and posted an image to the CDR last New Years) - HOWEVER....

These ideas are NOT Phil's. A perusal of the CDR archives will demonstrate
that I've been working and talking on these ideas for over ten years.

If Phil, or any others, would like to participate in a real world
demonstration of this sort of technology over the next couple of years
then I invite them to review,

http://plan9.bell-labs.com

and to participate in the community project,

http://einstein.ssz.com/hangar18

On Wed, 12 Dec 2001, Eugene Leitl wrote:

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