[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clogging attacks on SKIP
Sorry, I missed this message in the pile of messages.
> > The *worst* that can happen is that, only in case of wildcard
> > ACLs, *unusual* access patterns *may* be denied service during
> > a clogging attack.
>
> This is what I was refering to. It appears a very reasonable case for a
> firewall which allows access to employees of large organization esp. if
> they are allowed to use DHCP.
DHCP doesn't contribute to non-uniform key patterns, since the
premise of SKIP is that there are long-term certified keys.
Whatever is used to bind the node public keys to node's is what
will be used to precompute keys. If this is a DNS name,
and EID etc., then that is fine.
The point is that the certified information is not dynamic,
and that is the basis of precompute caching.
> > This isn't all that bad, especially since
> > someone who desperately seeks service and is being denied,
> > can be asked to put on the priority list and regain access,
> > even if the clogging attack continues. (Note that administrators
> > would always be on the priority list, and would always be
> > able to take such action in a secure manner, even remotely).
>
> Of course such manual solutions would help (but even that should be noted
> in the spec!).
I'll be happy to mention this in the next revision of the spec.
To be fair to my spec, I didn't a see detailed discussion of prevention
of denial of service attacks in your spec either. The Photuris proposal
deserves the credit for highlighting this issue.
> My belief is that we can achieve almost all properties very similarly in the
> interactive and non-interactive cases and therefore we can have one tunable
> design which satisfies all of the goals in the exisiting proposals (inc non]
> interactivity as in SKIP although I still think this should be an option since
> it is less secure - see other note)
We have agreed to defer the discussion of what should be optional
and what should be default so I wont get into this.
However, I'll note that the less or more secure should always be
looked at in terms of a tradeoff.
For example, 1000 bits moduli is less secure than 8000 bit moduli,
but 1000 bits will probably be used for the following two reasons.
a) 8000 bits is not necessary for many (or most) applications and
b) we cant afford the overhead of a 8000 bit computation in many
(or most) circumstances.
This is the same principle we use for many other decisions, namely
a) can we afford it?, and b) is it necessary?
The "more secure is always better" is too simplistic an approach for
deciding on the right tradeoffs in a key-management system. Rather we
have to apply the two basic principles that are used by all of us in
deciding which car, house, computer etc to acquire. Namely, can we
afford it, and is it necessary.
Only after evaluating this cost/benefit tradeoffs in terms of
of some ordered list of requirements can we come to the right
decisions. This requires some work, because different environments
and applications have different requirements.
> (I am still waiting for your response
> > on this issue and the other issue on saving sender resources.)
>
> I"m not sure what this is, but I'll be away for a while (and was too busy
> recently)...
I was referring to your comment that with connection oriented key-management,
the sender saves resources by not sending IP packets, in case the key doesn't
get established. I pointed out that this doesn't work for IP, because
IP doesn't contain a flow-control or disconnect protocol.
Ashar.