Re: [Sks-devel] Big amount of updated keys yesterday?

[Jeff Johnson]

On Apr 13, 2011, at 12:17 PM, Daniel Kahn Gillmor wrote:

> On 04/13/2011 07:15 AM, Jeff Johnson wrote:
>> Is there really a problem here?
>> 
>> An update of 5000-1000 keys over 2-3 hours isn't wildly out of line
>> with the statistics I've seen.
>> 
>> Key servers come and go, and when there's a diconnection of some sort,
>> then there can be a burst of activity when the disconnection repairs itself.
> 
> yes, i agree with this.  I'm curious about thinking through the
> implications of bursty gossip, though, so we can all better-understand
> the nature of this collaborative project we're engaged in.
> 
> Aside from the performance issues people have identified, i don't think
> that a burst like this is *necessarily* problematic.
> 

> But consider: if there was a sustained huge injection of garbage into
> the keyserver network, it would be good to have some way to figure out
> where it was initially coming from (a malicious attacker could always
> use a distributed injection to foil this kind of analysis, of course).
> 

Well there have already been sustained huge injections of (imho) garbage
for PGP automatically signing keys with a short expiry of like 2 weeks,
thereby forcing repeated automatic signatures to be distributed
everywhere again an again.

Historical details follow this code:

    /*
     * Skip PGP Global Directory Verification signatures.
     * 
http://www.kfwebs.net/articles/article/17/GPG-mass-cleaning-and-the-PGP-Corp.-Global-Directory
     */
    if (pgpGrab(sigp->signid+4, 4) == 0xCA57AD7C
     || (hkp->crl && rpmbfChk(hkp->crl, sigp->signid, 8))) {

The SKS world did not end then, and it won't end in the future even
if more garbage appears in the future.


> I wouldn't be surprised if the recent burst was related to Jonathon
> Weiss' recent work getting pgp.mit.edu to sync again.
> 

Or the outage of DNS ... 5K to 10K is just a busy weekend imho.

>> Sure its an interesting challenge to try and find a "smoking gun".
> 
> Thinking through what sort of analysis is actually possible (and
> optionaly, what additional log info we might want for forensics like
> this) is a useful exercise, i think.
> 

Well look at what's done with torrent's to identify gossip sources.
One never really knows what is coming from where, but one relies on the
sigest and signature checks to prevent maliciousness (at the level
of tampered content, there's many many many forms of evil, some
quite innocent, like in 0xCA57AD7C above).

73 de Jeff

smime.p7s
Description: S/MIME cryptographic signature