Robot CA at toehold.com

[Kyle Hasselbacher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying once here to multiple messages...

David Shaw wrote:
> On Fri, Dec 06, 2002 at 01:21:58PM -0600, Kyle Hasselbacher wrote:

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

I hadn't considered that people would have multiple legitimately signed
keys.  The problem will be mitigated by expiring signatures (this makes me
want to expire them faster), but it'll probably still happen a lot (with
people installing multiple email clients and whatnot).

You could automate the check for multiple signed keys.  When it turns up,
explain to the user what it means, and what it MAY mean.  If they choose
"ignore it", then remember the extra key you saw, and pop the dialog again
only if ANOTHER key shows up.  We can have as many dead keys as we want on
the "don't care" list.

People who ignore real attacks are (again) no worse off than if they had no
crypto, except maybe that they're annoyed by perplexing questions.  What
bothers me is people who take action against a false positive.  They
generated two keys without knowing it, but they think the big bad
postmaster is out to get them.

That's a tough one.

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

I've already seen people send in two real keys with the same email
address, so I don't think I'll do that.

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

I think as long as there are some cases where we encrypt productively when
we would not have before, it's victory.  If I fail totally to encrypt when
there are multiple signed keys, or when there's a legitimate key that's not
signed, that won't bother me.  These are users who previously would have
never encrypted anyway.

Say there are 1000 people who aren't encrypting now.  Say 100 of them try
this thing.  Say 10 of them have it work (the other 90 fall victim to the
evil postmaster, or duplicate key creation, or whatever).  That's still 10
more people using encryption that wouldn't have it at all otherwise.

That having been said, in my mind, when there's some doubt, I don't
encrypt.  If I ever get a chance to write the software I'm talking about,
I'll make that the default (unless someone convinces me otherwise).  I'll
also give the user check boxes to change the behavior, if they ever feel
advanced enough to have their own opinion.

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

Yes.  I've had keys for seven years without being connected to the strong
set.  Most of my online time is not spent on crypto mailing lists, so most
of the other keys I see are of the "self-signed only" variety.  Most of the
people I communicate with online are ones I've never met, and may never
meet.  Authenticating their real names is not very important, but being
able to communicate with them privately would be welcome.

This is the situation that I think the robot can help, and I think it's
more common than your situation.  I know it isn't a perfect solution, but
that doesn't bother me.  As has already been pointed out, the perfect
solution requires user education.  I won't hold my breath until that
happens.  I'll go for the less-than-perfect solution in the meantime.

David Shaw wrote:
> On Fri, Dec 06, 2002 at 11:39:18AM -0600, Kyle Hasselbacher wrote:

> > I have a key, and it's published, but I still don't get much encrypted
> > email because my friends don't use it.  Right now if someone made a
> > duplicate key for me, it wouldn't make much difference.  The attacker's key
> > would be used as rarely as mine is.
> > 
> > When things get automated (and most people are encrypting to whatever key
> > they can find that matches the recipient), the duplicate key attack gets
> > easier.  If Alice doesn't have a key, she gets DoSed massively and easily.

> Absolutely, but this applies to the postmaster attack as well.
> Remember that it is trivial for her postmaster to get a signed "Alice"
> key without Alice's participation or knowledge.  Still, I agree that
> this is a genuine example of "better than what we have now".

Yes, postmaster is still a vulnerability.  I'm frankly not very worried
about postmaster, though.  Having been a postmaster, I've seen others'
email during maintenance in various unintentional ways.  I'd never have
gone out of my way to read Alice's mail, though.  I certainly wouldn't have
gone through a procedure that leaves a trail like this one.

I'm sure there really are evil postmasters that will foil this little
scheme, but they're in the minority.  Most don't care.

As I said somewhere else, I can't stop the determined attacker.  My goal is
to stop the casual ones.

> > >Why not have Alice indicate this for herself on her own key?  Simpler,
> > >and less prone to problems if Alice gets to say for herself.
> > 
> > Is there a way to do that?  I hope I haven't reinvented the wheel.
>
> See "Notation Data" in RFC 2440.  Alice can add a notation to her own
> self-signature that indicates whatever she likes.  This is
> particularly elegant for people who have more than one user ID on
> their key, as they can indicate different preferences for each ID.

Very nice.  Thanks for the pointer.



Michael Nahrath <gnupg-users@nahrath.de> wrote:
> Kyle Hasselbacher <kyle-list-gpguser@toehold.com> schrieb am 2002-12-06
> 20:39 Uhr:

> > Back to the robot, if people have keys signed by it, then there's a mapping
> > between a key and an email address.  Then the email address can be an
> > easier "fingerprint" for a user.
>
> If you promoted it like this, I'd see your service as as a danger for
> security.

It was just an idea.  Clearly I hadn't thought it through much.  8-)

> Being only a small reseller for webspace myself I can easily figure out ways
> to be the 'man in the middle' against my users.
>
> I create a key for their addresses, I let it sign by the robot. They will
> never know that there exists a key in their name (if they aren't interested
> in kryptography by their own.
> I get all their mail first, decrypt it, read it, maybe change it and then
> pass it over to them - unencrypted as they expect e-mail.
>
> Feeling safe because everything is encrypted the other side will tell
> details it would not in unencrypted mail.

I think most users feel safe already, but I see what you're saying.  NOT
using email addresses in place of fingerprints doesn't change this attack,
however.  This is another attack that I think the robot makes no worse.
You can, right now, make a key for your unwitting customers.  You can forge
mail from them asking their contacts to use it.  Etc.  The existence of the
robot just means you go through another step along the way.

> > If I
> > look up keys with that email address and find one that's robot-verified, I
> > may feel confident enough to sign it myself based on that.
>
> If you do silly things like this, the whole system of signing in person gets
> worthless.
>
> NEVER SIGN A KEY BASED UPON OTHER PEOPLE'S SIGNINGS !

OK, yes, you're right.  OTOH, if I didn't think you were right, you could
just not trust my signatures, knowing what my policy is.  Reading a little
further down, you already know this.

> I just typed "gpg --edit-key 2A94C484   trust   2   q".
>
> | Please decide how far you trust this user to correctly
> | verify other users' keys (by looking at passports,
> | checking fingerprints from different sources...)?
> | 
> | 1 = I don't know
> | 2 = I do NOT trust
>
> Just in case you really mean what you wrote.

No, I was just brainstorming.  I'm actually kind of embarrassed.

FYI, I've only signed keys of people I know personally.
- -- 
Kyle Hasselbacher
kyle@toehold.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE98XaJ10sofiqUxIQRAtCnAJ41L6pIBc/Voeg+QQnYtMsHlrKbNQCfbEj+
SJKeFiRRXE2nNDo/+cC0vbQ=
=MNJV
-----END PGP SIGNATURE-----