[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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

One possibility would be do static_cast<keyservers>(DNSSEC) and 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.