Re: [dnsext] Re: Protecting caches?

[Dean Anderson <dean@av8.com>]

[ Note: Post was moderated. ] 

On Thu, 9 Oct 2008, Wouter Wijngaards wrote:

> 
> The thing that Kaminsky added was the retry for a different (previously
> unseen) query name, which delivers the race-to-win and no wait for TTLs.
>  The rest is indeed the same.  The race-to-win made the problem very urgent.

I don't think Kaminsky added this. This 'race-to-win' was only remotely
relevant after NXDOMAIN was added in 1998, after the balliwick issue.
When the balliwick issue was being discussed, queries for non-existant
names were not cached.  I don't recall anyone ever proposing TTL as a
solution to spoofing attacks, so I don't think it can be a big surprise
that it wasn't a valid security assumption protecting one from spoofing
attacks. How could it be surprising when no one ever said that?

NXDOMAIN was a offered as a performance enhancement, not a security fix.
(see the abstract of RFC2308). Indeed, RFC2308 security considerations
section actually describes spoofing attacks using NXDOMAIN.

There is nothing 'urgent' in what Kaminsky describes, because there is 
nothing new or novel in what Kaminsky describes. Not even the 
'race-to-win'.

> > So, if you have 200 outstanding ports, with 200 outstanding QIDs,
> > and any correct port can have a coincidence on the 200 QIDs, the
> > cache is spoofed in just under under 5 tries, or in about 943
> > packets!!! Holy added-security flaws!
> 
> Are you saying that using multiple ports at the same time creates
> birthday attack problems?  

Yes. But that isn't the big issue. It requires about 28 million packets
to be successful, and there are some things I have proposed to make this
even harder (see posts on dns@list.cr.yp.to). But Kaminsky's idea makes
it trivially easy. I haven't checked to see if these ideas were included 
in the 'urgent' patches.

The way DJBDNS (DNScache) works now, a new random port is allocated for
each recursive query, a random QID is selected, and the query is sent.
Packets recieved on that port are checked by a function callled
'irrelevant()', which ensures that the QID and the query are the same.

What was proposed was to reuse ports; that is one port may have multiple
outstanding query ids.  To implement that, one would have to keep track
of all the valid outstanding query ids (probably over all ports), and
check any incoming packet on a valid port to see if its query id matches
one of the valid outstanding query ids. So one may also have a
coincidence over the query ids. The combination of two coincidences
drastically reduce the strength of using random port numbers and random
QID, as the math shows.

> Or do you assume in the above that this is the same query that is sent
> out with multiple outstanding ports/multiple outstanding QIDs?

If you reuse the port, presumably, it is for different queries; but the
same query could be repeated by different clients. So all outstanding
queries could be arranged to be the same textual query. Follow?

> > DNS *with* DNSSEC is an additional way to attack the final application.
> > 
> > DNSSEC caches can still be poisoned by setting the CD bit so that the
> > cache does not verify the data, then spoofing by ordinary means with the
> > appropriatly set DO and CD bits. The cache won't verify the data, and so
> > will cache invalid data that it hands to the stub resolver for
> > verification. The resolver that tries to verify the data will reject the
> > invalid signature, but can't get past the cache with the bad data.
> > Result: DOS.
> 
> Unbound has a cache of 'bad' data.  This is data that it considers
> bogus.  This data can be retrieved by setting the CD bit, that is the
> purpose of the CD bit.  This data is not returned to regular stub
> resolvers (withholding the bad data).  The stub resolver can then choose
> via the CD bit to verify that data itself, with its own security policy.

I don't think this is completely correct. If the site intends to offload 
verification on the stub resolver, then the stub has to set the CD bit. 
Such cache setups can be poisoned.

I seem to recall (but haven't verified in the RFCs), that when 
unverified data is cached in the 'bad cache', and the stub doesn't set 
the CD bit, that the cache is supposed to return an error in that case.

And of course, if the cache does verify, it is vulnerable to attacks in 
which many hard to verify records are requested at a high rate.

And of course, I didn't mention before that in either case,
cryptographically valid (but replaced) records can be used to poison the
cache, too. Indeed, in some cases, (specially nsec with unverified
delegations), spoofed delegations can be _created_ in secure zones using
the replaced (but still crypto valid) NSEC records. The stub resolver
will conclude these are valid records.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>