Robot CA at toehold.com

[David Shaw]

On Fri, Dec 06, 2002 at 01:21:58PM -0600, Kyle Hasselbacher wrote:
> On Thu, Dec 05, 2002 at 05:27:25PM -0500, David Shaw wrote:
> >On Thu, Dec 05, 2002 at 04:03:00PM -0600, Kyle Hasselbacher wrote:
> >> On Thu, Dec 05, 2002 at 09:52:39PM +0100, Volker Gaibler wrote:
> 
> >> >But why use encryption at all in that case? Slightly simplified:
> >> >If someone can read your unencrypted mail (sysadmin or somebody sniffing
> >> >network traffic) - and that's what you want to prevent - also can create
> >> >bogus-but-signed keys.
> >> 
> >> That situation is made no worse by having non-working encryption.
> >> Hopefully the user gets a key working BEFORE people start
> >> sniffing.  When a doppleganger shows up, hopefully people will
> >> notice.  There's some optimism there, I know.
> >
> >This still doesn't stop the doppelganger.  The postmaster attack
> >lets someone get a signed key in addition to the user's signed key.
> >Then there would be two seemingly identical "Alices" on the
> >keyserver.  If people do notice, how do they pick from between the
> >two?  ("I'm Spartacus!  No, I'm Spartacus!").
> 
> If I see a key that's not mine that IS signed by the robot, then I
> know that someone else has access to my email.  That's a big
> improvement over them reading my mail without me knowing.  The
> action I can take when I find out is the same--get another email
> address.  Without knowing, I take no action, and the snooping
> continues.

That's cheating a little bit - you're promoting this to make crypto
simpler for Granny.  Granny won't know what on earth it means to have
multiple signed keys.  Plus, it's going to be a VERY common case to
have multiple signed keys by the robot.  It happens every day that
someone makes a key, sends it to the keyserver, and then forgets the
passphrase so they have to make a new one.  Some people have 4-5 dead
keys on the keyservers that they can't get rid of.

One answer to that is for the robot to track email addresses and only
sign a new key for an old email address after it first revokes the sig
on the old key, or even for Granny to use the most recently signed
key... but both of those open things up to a postmaster attack again.

> It brings a benefit to those who use it.  The ones who get their keys
> signed by the robot and use the robot's signatures ARE the "closed
> community".  People without the robot's signature or who don't trust it do
> not get the benefit--just like the people who don't use GnuPG now.
> 
> This is just like GnuPG itself--it brings a benefit only to those who use
> it.  People with keys are a closed community within the larger set of
> people who have email access.

It's easy to just declare that any key that isn't email validated is
outside of the community, but so long as this is a
community-within-a-community, you do have to deal with the case of
someone inside the community trying to encrypt to someone outside of
the community.

This means problems at the boundaries:

Granny wants to encrypt to Alice.  Granny's MUA fetches all "Alice"
keys from the keyserver.

1) If Granny has a strong trust path to an Alice key, use that key. I
   think everyone can agree on that.

2) If Alice has an email validation, use the key.  Remember that there
   may be more than one validated key - what to do?  Send to all?
   Send unencrypted?

3) If Alice has nothing, what to do?  By definition, we can't prompt
   Granny for help.  Send unencrypted as if Alice had no key?

> It seems, however, that you would not be a user.  If I've understood you
> correctly, your decision is to encrypt to every candidate key you can find
> regardless of whether it has been validated.  If you find two keys for an
> email address, you prefer ones with more validation (such as the robot's),
> but otherwise, you don't care.  Do I have that right?

No, not exactly.  I'm just thinking along the same lines as you to
make use of crypto simpler, and encrypt-to-all-keys is something that
could be easily implemented in a MUA.  What I do personally is harder
to automate in code:

1) If there is a strong trust path, use the key.  This is fairly easy
   for me since my key (99242560) is very well connected.  It is very
   unusual to find a key with more than a couple of signatures that
   I'm not connected to via some path (strong set).

2) If that fails, check the key - is it the key that the person has
   been signing with for months?  Is it in their headers for the same
   period of time?  If so, use it.  Not proof against a MITM attack,
   but they've added evidence that the entity that I have been
   communicating with uses that key.  There is a nice tool called
   "keystory" (http://keystory.sourceforge.net/) that simplifies this.

3) If that fails, and there is only one key available, use it.

4) If that fails, and there are multiple keys available, use either
   all or the most recent.  If more than one key is used, include a
   note in the message saying something along the lines of "Hey, I
   sent this to multiple keys..."

Given the people I communicate with, I rarely have to go past step 2
in practice.

I do see your point that a new user has to start at step 2 or more
often 3.

David

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