Robot CA at toehold.com

[David Shaw]

On Thu, Dec 05, 2002 at 03:34:54PM -0600, Kyle Hasselbacher wrote:

> On Thu, Dec 05, 2002 at 03:38:16PM -0500, David Shaw wrote:
> >On Thu, Dec 05, 2002 at 11:24:01AM -0600, Kyle Hasselbacher wrote:
> >> The ultimate goal is to bring encryption to people who wouldn't have it
> >> otherwise.  The benefit it brings is some extra security where there would
> >> be none otherwise.  The users of this mailing list (who already know how to
> >> use GnuPG, and do so) are not the "target audience."  The target is the
> >> granny who won't put up with a passphrase in a million years.
> >> 
> >> With tools yet to be created, people could get the benefits of encryption
> >> without having to understand it.  The robot CA will make those tools work
> >> better.
> >
> >Yes, but *how*?  The goals are laudatory, but what exactly does this
> >give us in concrete engineering terms?  What makes this better then
> >Granny just going ahead and using an untrusted key?
> 
> This question is harder than I thought.  Perhaps I don't actually
> understand it.
> 
> All this gives us is a binding between a key and an email address.

Agreed.

> It makes it safer to use that key when sending mail to that address.

Agreed.

> It's better than using an untrusted key because you can be more sure
> it will work and not require the user to backtrack somehow.

Agreed, BUT: in the real world, there is no way to guarantee that
every key holder will get this email checking signature.  Therefore,
there will be some keys with, and some keys without.  Therefore we
must handle both cases.  My thinking is that since we have to handle
both cases, there is no benefit derived here.

If Granny gets Alice's key, and it doesn't have the signature, her
only proper course of action is to use the key untrusted since she
doesn't know if Alice has had her key validated or not.

I think that an email checking robot could be very useful in closed
communities - say, the Debian folks, a university, or even a
particular ISP or email provider (the "hotmail.com" robot?).  In a
closed community, Granny CAN say "if the key isn't signed, I won't use
it".  This is why some companies have a "official key signer" key, and
the Debian folks have their own authentication scheme.

Doing this for all email across communities has no benefit that can't
also be gotten via smart code on Granny's computer, and since we need
that smart code anyway for those keys that aren't email-validated, why
do the work twice?

> >We've discussed one reason thus far: it makes it a lot harder for
> >Mallory to perform a DoS attack against by publishing a bogus "Alice"
> >key.  Still, remember that Granny's software can defeat the same
> >attack by just encrypting to all "Alices".
> 
> If Alice doesn't have a key at all, Granny's software hasn't defeated the
> attack.  It's also not defeated if Granny has a bogus key but not the real
> one (though this seems less likely).

If Alice doesn't have a key at all, then all schemes fail.  Let's
presume at least that Granny can get some of Alice's keys.

If Alice has multiple keys, and one is validated, then Granny
encrypted to the validated one.

If Alice has multiple keys, none validated, Granny encrypts to all
Granny can get.

Now, since Granny has no way to know if Alice has gotten her key
validated, Granny can't tell the difference from the first case and
the second case where she was unable to get the validated key.  This
is the case for all non-closed communities.

(Yes, I know Alice could tell Granny to look for the email validation
signature, but if Alice can communicate securely with Granny, then
Alice could just read her a key fingerprint as well).

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