[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Randy Bush <randy@psg.com>, Olafur Gudmundsson <ogud@ogud.com>
Cc: dnssec@cafax.se
From: Olafur Gudmundsson <ogud@ogud.com>
Date: Wed, 04 Jul 2001 13:54:29 -0400
Delivery-Date: Thu Jul 5 12:17:14 2001
In-Reply-To: <E15HqIz-0009zp-00@rip.psg.com>
Sender: owner-dnssec@cafax.se
Subject: Re: ttl problems in DNSSEC

At 01:19 PM 7/4/2001, Randy Bush wrote:
> >>>>> [1]: perhaps the resolver is able to detect this situation by
> >>>>> comparing the key tag field on S++2(A) with K++1, and then try get
> >>>>> more recent data.
> >>>> then you propose that if data is BAD an extra query for the key most be
> >>>> done? I'm afraid this will yield too many extra queries...
> >>> Not a problem this will only happen once in a long while, thus when this
> >>> happens extra query is fine.
> >> so you are saying if there is bad data it is okay to requery for stuff
> >> you need? (Another key for instance)
> > Yes if you discover another key is needed then you need to get it.
>
>how often will this happen?  O(sig verify failures)?  is it a dos opening?


Hopefully only during
         emergency key rollover
         misconfiguration where key with valid signatures is removed
            prematurely.


> >> I think it is pretty easy for an attacker to fake bad data and thus
> >> generate a huge amount of extra queries. Those queries must alwyas be
> >> validated (as bad data isn't cached) thus generating an extra load on
> >> the nameserver.
> > I know, the simplest one is to toggle the key id's on the signatures.
>
>i am slow this morning.  how does this bring re-fetches to some reasonable
>number?


Does not this how to do a DOS on the authoritative servers.



> >> (is this the old DNSSEC doesn't protect you against DOS attacks? (but
> >> makes them very easy to do))
> > Exactly, that is why you should try to use TSIG/TKEY or TLS or IPSEC when
> > frequently talking to nameservers.
>
>i.e. public key dnssec does not scale well so we go to shared secret schemes
>with non-scalable, or unknown, key distribution schemes?  is something
>broken here?

Any security protocol is vulnerable to DOS attacks if the underlaying
transfer mechanism does NOT have authentication and data integrity.

The two types of DOS that come to mind are
         change key information to cause more fetches (DOS servers)
         modify/falsify answers so signatures do not verify (DOS resolvers)

         Olafur


Home | Date list | Subject list