Re: [linux-elitists] Phil Zimmermann on key exchange (fwd)
-- 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@jabberwocky.com> To: linux-elitists@zgp.org Cc: Seth David Schoen <schoen@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@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
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@jabberwocky.com> To: linux-elitists@zgp.org Cc: Seth David Schoen <schoen@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@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
participants (2)
-
Eugene Leitl -
Jim Choate