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.