Re: Solving the key disclosure algorithm weaknesses

On Fri, 24 Jan 2003, Mikael Olsson wrote:

> 1. The key disclosure interval needs to be randomized to avoid
>    "Moving DDoS" attacks.
>    Tomasz suggested 10 secs -- 10 minutes (avg. 5 minutes)
>    I think I'd say  20 secs --  3 minutes (avg ~1.7 minutes)

I don't like that idea. Avg 1.7 minutes is to low. Think of how many keys
you will be able to fit into Disclosure Key List field (or in one packet
if we will go the on-demand disclosure way). The only one obvious way to
disclosure keys is sign a bunch of (not each separatelly as oryginally
proposed in draft) keys with one signature. This way we can fit about 15
keys in one packet (if we will use on-demand disclosure). Am I right?

It is about 20 minutes of history with your proposition and about 75 with
mine.
Anyway, in my opinion ~75 minutes is not enough either...


The minimal time 10 seconds was proposed because it will render moving
DDoS attacks useless (maybe we should think about 5 seconds here... if we
paranoid :) ). When you will have min. 20 seconds to switch to another
victim the attack will be effective. What I'm saying here is that when
attacker/master will send a command "/attack 'victim'" to his zombies,
there will be about 5 to 10 seconds of latency when the information will
propagate to most zombies. After that latency the attack will be
effective on the victim. If there will be min. 20 seconds it means that
there will be about 10-15 seconds of effective attack on particular
victim.

This is why I proposed 10 seconds (well, it was 5 seconds, but I changed
it just before posting :) )

Remember that "latency" is the key word in case of moving DDoS. There is
no way to immediatelly switch all zombies to different targets (even if
switching is made on zombie itself, without the need of coordination from
attacker/master).

The point is to make evil DDoS utilities developer to say: "Hey, 10
seconds is not good enought for me. I will not be able to do much harm
with such time window".


> 2. It looks like we need to be able to query the router for old
>    keys.  Tomasz suggested pointing to an URL, but I'm not sure
>    that's a good idea. All of a sudden, routers suddenly need lots
>    of smarts and configuration work by admins.

That's true. Pointing to an URL is a good idea only if you have a separate
server to do all the ITrace work. It can't be implemented in router itsef.


>    This means that the router definately needs to keep track of at
>    least the 2 most recent keys.  However, given the (possibly)
>    rapid key changes, I'd say that even more is called for.
>    Maybe just say "enough to build a full-size reply packet"?

This is the only good solution I can think of.


[cut]


>   So... what to do?  Assume that the router is capable of
>   combining a bunch of HMAC keys in a single blob and sign
>   that blob?
>
>   In such a "blob disclosure", we'd be able to fit about a
>   dozen keys, given a more compact representation than is
>   currently specified.  Using the disclosure intervals I
>   suggested, this is about 20 minutes worth of history.
>
>   Is that enough? Perhaps not. Should one add functionality
>   to query for a key used during a specific time?
>
>   Ack, this is rapidly becoming very large.
>   Is there a better solution that I'm simply missing?

The question is: does the rest of the group accepted that the on-demand
key disclosure is the right way to go?


---
Tomasz Grabowski  (0-91)4494234
Akademickie Centrum Informatyki
mailto:[email protected]