Subject: Do we need to secure our keyservers against kind of DoS Attacks

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 31 Jan 2009 23:54:48 +0100

Hi.

I having the following issue on my OpenPGP "TODO" list for some very
long time now, and David just remembered me on it.

On Fri, 2009-01-30 at 22:48 -0500, David Shaw wrote: 
> Yes.  However note that you can un-revoke a key by removing the
> revocation signature.  That's very difficult to do in practice
> (keyservers would have the revoked copy).

Keyservers are very critical for any PKI to work, aren't they?
I mean there are plenty of "attacks" which would be possible without
them:
- we couldn't get revocations
- we prone to attacks where someone simply removes some subpackets (e.g.
a revocation signature, or a newer and updated self-signature)
- there might be even more cases I can't think of

Of course our keyservers work quite well, I can to some "upgrade my
keyring" command and get the new keys and all added packets.
And the big advantage is that no one can remove anything from them (it's
even difficult for the admins, though probably not impossible).

But there is the possibility of a kind of a DoS-Attack; service in the
sense of "deliver the whole key and everything belonging to it to the
requester".
Imagine that my ISP is evil, tracks my connections and always removes
some revocation signatures when I get the data.

Are there currently working means to prevent this?

One possibility would be do static_cast<keyservers>(DNSSEC) and
implement a secured keyserver protocol.
Of course we should use OpenPGP for this :-)
A keyring could always sign the data he sends to a user, and the user
could have the public key from that keyserver set up somewhere in his
implementation as valid for acting as keyserver.

Of course one could build trust-paths to the keyserver's public keys, et
cetera, et cetera.

Now the ISP could only block the whole keyserver, but at least I'd
notice it and an implementation could WARN me if for example regularly
updates of the keyrings don't work.

Just an idea,... :-)

Regards,
-- 
Christoph Anton Mitterer
Ludwig-Maximilians-Universität München

[email-masked]
[email-masked]

---

From: Wim Lewis <[email-masked]>
Date: Sat, 31 Jan 2009 16:30:10 -0800

(Attention Conservation Notice: non-expert explaining why he thinks  
the current system is almost-good-enough without securing keyservers)

This is an interesting point. After thinking about it a little,  
though, I think that securing the keyserver (or the communication  
with the keyserver) isn't quite the right approach. One of the  
strengths of the PGP setup, I think, is that you don't have to trust  
the keyserver; all it's doing is making it easier for you to get  
information that you can in theory get elsewhere.

An end-to-end approach is better, IMHO. (It also protects against the  
opposite side of the equation: is Mallory secretly stripping the  
revocation certificate out of your friend's uploads to the keyserver?  
Also, I don't want to have to make trust/policy decisions based on  
how much I trust the people running the keyserver, how strong my  
trust path is to their key, and so on. That way lies X.509...)  
Notionally, I want some sort of periodic, signed communication from  
other keyholders, saying, "The official state of my key-and- 
subpackets is X. Expect another message before date Y". However, not  
all of the subpackets are really important: if I'm missing a  
signature from someone else, or an alternate user ID, I'm not going  
to trust you any *more* than if I have it. So this thing only needs  
to cover packets which reduce trust --- revocations, I guess. (Am I  
missing a scenario here?)

But is this actually any different from periodically renewing a set  
of expiring signatures? (I don't think so, but I could easily be  
missing stuff.) In which case, OpenPGP already supplies everything  
needed to prevent this sort of denial-of-key-distribution attack.

For this to work, the spec has to follow a principle: any subpacket  
must either (a) only increase trust, not decrease it; or (b) be more- 
or-less equivalent to early expiration of another subpacket. How  
close is OpenPGP to this?

Actual implementations might get in the way, on the other hand. In  
the past I have tried maintaining a key with a non-expiring signature  
on the signing key and a rotating, expiring signature on the (sole)  
encryption subkey. A lot of software seemed to dislike this, and  
seemed to assume that if the encryption subkey had *any* expired  
signatures, it was invalid, even if it had a later, still-valid  
signature.

As a UI detail, it might be nice to have a bit on an expiring  
signature indicating whether a renewed signature is expected,  
possibly in the form of an "expiration reason" field a la  
RFC4880-5.2.3.23. This shouldn't, I think, be acted upon by the trust- 
computation code, but might be useful to help decide whether to try  
to refresh that key. On the other hand, maybe the software should  
just infer this bit from the existence of previous, expired  
signatures in the keyring.

> implement a secured keyserver protocol.

Of course I think securing the keyserver communication is *also*  
good, as long as the trust model doesn't depend on it. :) If nothing  
else, doing a keyring refresh broadcasts to a listener or MITM the  
contents of your keyring, which you might consider sensitive  
information.