DNS keyserver (was Re: gnupg-1.0.7: keyserver subdir?)

[Simon Josefsson]

Michael Graff <explorer@flame.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> > Cool.  A key server DDOS attack is in your future.  :)
>> 
>> How so?
>
> One of the popular DDOS attacks is to use a multiplier of some sort.
> For example, AOL used to have about 26 or so MX records, which just
> fit in a 512 byte response packet.  Attackers would forge a source
> address on a packet to be some poor victim machine, and send a request
> for "aol.com. mx" -- a 63 byte (or so) packet would multiply into a
> 512 byte packet.  So, the attacker needed but 1/8th the bandwidth of
> the target to get this trick to work.
>
> What you're proposing (and I still like the idea, mind you :) is even
> worse -- nearly a 1000x increase.  I send you a small packet as a
> request, and you send me back up to 64k of data.

Is the packet size really the important factor?  I thought a good DDOS
attack used a protocol that generated several packets given only one.
Like broadcast ping.

Also, is it possible to spoof an EDNS.0 session?  I don't remember the
details, but it may include some kind of cookie, like TCP, which you
need to guess in order to continue.

>> > Remember that the max payload (and max rdata size) is still 64k -
>> > headers, so you'll have to handle broken up data even over TCP.
>> 
>> Hm.  That is a problem. Perhaps it is easier to state that it won't
>> work with keys larger than 64kb though.
>
> Then your server won't hold the most popular keys.  :)

Are they that large?

> I'd say reserve a flag somewhere in the returned data that means "more
> data" and they can just tack on .0 on the end.  And then .1, .2, .3,
> etc.  That way, while less efficient, it will work for even large
> keys.

Yup, that could work.

> BTW, remember also that a 64k UDP packet will be fragmented over
> nearly every type of wire, and if even one of those fragments are
> dropped, the entire packet is lost.
>
> It may be better to limit the EDNS0-sized responses to perhaps 1400
> bytes of payload, and use some sort of chaining method to get the full
> key data.  Of course, this is not atomic.

Or switch to TCP.

> What I was considering was to split the signatures up, and return each
> signature in a different packet.  One packet would be the self-signed
> key (if it is self-signed, the bare key otherwise) and each following
> request would return one signature.  It would stop when it was told to
> -- that is, requesting
>
>         keyid-here.sig.21
>
> would return "END OF SIGNATURES"
>
> It got messy fast.

Yes, it looks rather messy.