Weakness in the keyserver network (Was Re: Global Directory signatures)

[David Shaw]

On Thu, Jan 06, 2005 at 11:16:40PM -0500, Jason Harris wrote:
> On Thu, Jan 06, 2005 at 10:22:02PM -0500, David Shaw wrote:
> > On Thu, Jan 06, 2005 at 07:27:11PM -0500, Jason Harris wrote:
> 
> > The whole meaning of non-exportable is that the signatures are, well,
> > non-exportable.  Having the GD issue non-exportable signatures rather
> > defeats the point of the thing.  Forgetting for a minute the protocol
> > issues with this, a simple practical reason why this won't work is
> > that GnuPG won't import a non-exportable signature without modifying
> > the config, and PGP won't do it at all.  Mandating code changes in the
> > clients isn't going to happen since it would require all GD users to
> > upgrade, which is unrealistic.
> 
> OK, so GPG users are ahead of the curve because we had to upgrade
> to 1.4.0 to talk to this new keyserver anyway.

No, you can use any version of GPG through the web interface.  The new
LDAP stuff in 1.4 just lets you search the keyserver directly.

Incidentally, the new LDAP code wasn't added to talk to the GD.  It
was added to allow users to store their keys in their own LDAP
servers.  Corporate environments are big on this.  It just so happens
that the GD uses the same LDAP schema, so it all worked painlessly.

> > You call the GD a "nuisance".  I don't agree.  We can have that
> > discussion if you like, but perhaps more interesting is that the GD,
> 
> Oh no, our positions are very clear on this point.  (Besides, didn't
> you say they consulted with you about the GD?  :)

Lightly consulted.  I suggested some ways to handle signature and
designated revocations.  No idea if they were already doing it in a
safe way, but we discussed it.

> > nuisance or not, is illuminating weaknesses in the keyserver network.
> > The keyserver network is dependent on clients being well-behaved.
> > That's a recipe for abuse if I ever saw one.
> 
> So, you can DoS a webserver without even modifying content on it.
> How is this news?

It's not.  Nor is that the point.  The point is that the keyserver net
was vulnerable, but nobody really cared.  Now there is something that
will eventually cause a problem due to this vulnerability.  Plus, the
comparison is apples and oranges.  Hammering a web server with
requests versus uploading terabytes of garbage data that will be
replicated faithfully among many servers.  Pretty nice amplification
there for an attack.

> > To make an extreme example, say there was a rogue signer, pumping out
> > thousands of signatures a day onto the keyserver network, all set to
> > expire in a week.  Due to the design of the web of trust, there is no
> > real impact on it.  However, there is an ugliness to all those
> > signatures.  UI displays (e.g. vindex) are rendered almost useless.
> > Over time, this approaches a denial of service when the signed keys
> > get so big they can't easily be downloaded.  The keyserver database
> > gets huge.  Lots of bandwidth is used to sync all of those signatures
> > between the various nodes in the keyserver net.  It gets messy fast.
> 
> Right, but let someone open some free webmail accounts, create some
> [Open]PGP keys, start placing keys on the GD, and start signing every
> key they find there.
> 
> Even better, use a dyndns service and create unlimited email accounts
> all from the comfort of your own DSL line.

Quite so, but this is a massively more difficult attack against the GD
than it is against the keyserver net.  The GD requires mailback
authentication, so the pace of adding keys cannot be nearly what it is
on the keyserver net where you can just add keys directly 24/7.

Plus, remember that unlike the keyserver net, the GD is under the
control of a single entity.  Abuse it too much, and they can simply
lock you out and refuse to accept more keys and/or key approval web
hits from your IPs.  That simple response doesn't work on the
keyserver net, where you'd need to get all operators to agree to block
an abuser, plus the abuser can resort to other means of getting the
keys in (email would be a good way in).  It's not impossible to block
an attacker from sending to the keyserver net, but it is certainly
vastly more difficult.

> > Now, to be sure, this isn't a brand new keyserver attack that nobody
> > ever thought of, plus the GD is nowhere near as bad as my example
> 
> Or is it?  Uploading garbage keys is still a DoS attack.

*You* have decided that the GD output is garbage.  Many other people
clearly don't think so.  Can we please get past the "it's bad" "no, it
isn't" ?  I'm not going to convince you, and you're not going to
convince me, so why bother?  We both agree that there is an
unfortunate impact on the keyserver net, so let's at least try and
accomplish something useful here.

> > above.  The GD behavior (being a very prolific signer, with no
> > particular effort taken to prevent signatures leaking from the GD onto
> > the keyserver net) is just a reminder that the keyserver net is
> > vulnerable to this sort of flooding.
> 
> Right, but adding cryptographic checks and enforcing no-modify flags
> will just shift the DoS attack to uploading garbage keys instead of
> bloating existing keys.  Of course, if we come to that, real no-
> modify checks will trump the GD by keeping signatures from bogus
> keys from littering actual keys.

Who said anything about cryptographic checks?  That's just one way to
handle the problem, and it opens you up to a DoS like you say.  Why
not start with something like not accepting or sending out expired
sigs?  Periodically, vacuum expired sigs from the database.  You don't
need crypto for that.

There is lots more that can be done, including just ditching any GD
signatures before they even get to the database.  That doesn't require
crypto either.

Doing sig trickery like this will help with the GD problem, but it's
not much of a defense against a general flooding attack,
unfortunately.

> > If you need a reason other than someone just being mean, spammers
> > could fairly easily get keyservers to display their ads with this sort
> > of flooding.  There's incentive right there.  You'll forgive me for
> > not going into excessive detail how exactly to do it, I hope :)
> 
> I'm betting they'll do that with photo IDs first.

Which is why it's not a good idea for keyservers to display photo IDs
from unauthenticated keys in searches.  The biglumber keyserver does
this right.

David