Robot CA at toehold.com

[David Shaw]

On Thu, Dec 05, 2002 at 09:00:02AM -0600, kyle-list-gpguser@toehold.com wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, Dec 05, 2002 at 08:43:44AM -0500, David Shaw wrote:
> >On Wed, Dec 04, 2002 at 01:27:49PM -0600, Kyle Hasselbacher wrote:
> >> I'm interested to hear opinions on this.  In particular, my robot does not
> >> do a challenge/response the way it's usually assumed.  It just signs the
> >> key and sends it to the address in the key ID.  I rely on delivery failure
> >> to eliminate the bad signatures.
> >
> >I think this is not terribly safe - as "postmaster" for a few sites, I
> >know that I get a lot of bounces that would surprise the users the
> >mail was intended for.  An unscruplous postmaster could also get the
> >signed keys from the mail spool and abuse them.  The only way to be
> >totally safe is to never generate a signature unless you intend it to
> >be used.
> 
> The postmaster case is something I hadn't thought of.  I think the earlier
> suggestion of encrypting the response would take care of that.  Am I
> missing something?

Encrypting the response isn't always possible.  Remember that OpenPGP
supports sign-only keys.  Even so, it's just safer design - if the
signature never existed in the first place, then there is no way it
can fall into the wrong hands.

> >2) Alice's key doesn't have such a signature, so I don't know if the
> >   email address has been verified... but I don't care; If the person
> >   behind the email address does not have access to the key, they
> >   won't be able to read the encrypted message I just sent them
> >   anyway.
> >
> >Where's the benefit?  If it was guaranteed that ALL keys would have
> >such a signature then there is the traffic analysis benefit of never
> >sending a message like in the second example.  However, in the real
> >world there is no such guarantee.
> 
> The benefit is in automation.
> 
> Once you have a robot CA, you can make an email client that looks for
> recipient keys and automatically encrypts for them if they have the robot's
> signature.  (More generally, it encrypts to any key that's considered
> valid, and you make the robot's key a trusted signer.)
> 
> Once you have that, you can make the same client automatically generate a
> key on installation and get it signed.  Then people are using encryption
> transparently.
> 
> The "robot only" users won't know what's going on, but they get extra
> security anyway.

How?  I understand the arguments you are making, but they are really a
"here's how it works" rather than a "here's the benefits it brings".

The only reason I have come across thus far to do this at all is to
combat this one particular denial of service attack:

> At the point that we have automatic encryption in the mail client, you need
> something to validate keys, or you get the attack where Eve makes a key
> with Alice's email address and publishes it.  Then Alice gets encrypted
> mails she can't read.  If Bob (the sender) can't figure out his mail
> client, he can't stop sending them.

Mind you, I'm not saying that this isn't a good enough reason to do
it.  I just don't want the impression going around that email
verification is somehow "secure", and the best way to do that is to
lay out in clear terms exactly what this is good for.

You're not saying this is secure, and in fact saying the opposite,
which is admirable.  Many people won't understand that, unfortunately.

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