[dns-operations] Difference between cacheing B data and I data

[Edward Lewis]

At 22:42 +0100 11/20/08, Florian Weimer wrote:
>* Edward Lewis:

>>  I'd add a caveat to this.  If a query is issued and a response comes
>>  that fails validation, my gut is that the recipient ought not give up
>>  listening until the timeout for an unanswered query expires or another
>>  response is heard that is accepted.
>
>This doesn't help that much if you are sending the query to the wrong
>place.  I'm not sure if special-casing this is worth the trouble.

If you are sending the query "to the wrong place" you have bigger 
problems than cache poisoning.

The strategy of continuing to listen assumes that the 
message-inserter can't stop the query (that is, the query is sent to 
the true destination).  As we are playing a heuristic game here, I'd 
bet that a non-bypassable middlebox would be harder to take over than 
an attack that is listening passively and/or an attack relying on the 
lack of egress filtering of addresses (BCP 38).

Yes, I know hackers can hit firewalls and routers.  But I expect that 
it is less common than other attacks.  This is my suspicion, it is 
easily debated endlessly.

>>  In re-examining the message from Florian, this is the penultimate
>>  paragraph, diced up to try to interpret it:
>>
>>  # My conclusion is that validators forwarding to non-validating caches
>>  # just don't work and should be deprecated.
>>
>>  Issue 1 - we can't deprecate this because the distinction can't be
>>  made.
>
>We could say that sending the query to a cache which has a subset of
>your trust anchors installed is an unsupported configuration.

Once again, how can you tell if the cache as a subset of your trust anchors?

>>  # This also means that indeterminate answers are relegated to an odd
>>  # corner case, and once that has happened, key rollovers and redelegation
>>  # with key changes become much less daunting: If the involved zone
>>  # operators make a mistake, RRsets may end up in the BAD cache described
>>  # in RFC 4035, which should be a rather temporary situation.
>>
>>  I really can't figure this out.  Indeterminate answers are a product
>>  of the use of UDP.  We can't rule them out, even if they are rare in
>>  healthy networking environments (healthy as in low packet loss).
>
>Read Insecure instead of Indeterminate, please.

Considering that I believe all of the Internet today to be "insecure" 
and that does not stop me from using it, that it will be a long, long 
time until all of the domain names I rely upon are signed, "insecure 
answer" will never be relegated to being an "odd corner case."

>Let me try again, this time with a concrete example.  Suppose that
>.net is signed, and my validating, security-aware, non-iterative
>resolver has a corresponding trust anchor.  My resolver sends queries

non-iterative = stub, right?

>to security-aware, but non-validating recursive resolvers at my ISP
>(non-validating because it lacks the trust anchor, for instance).  I
>try to resolve www.example.net/IN/A.  Assume that the query results in
>an upstream query from the ISP's resolver.  Someone mounts a
>successful cache poisoning attack against it, and the ISP's resolver
>ends up caching an A RRset with an RRSIG which doesn't match,
>returning it to me.  My resolver detects that the data is Bogus/BAD.
>It puts that information into its BAD cache and signal a resolution
>failure to the application.  My application periodically tries to
>resolve the domain name (because it still needs to download
>something).  After some time, the BAD TTL expires.  Another query is
>sent to my ISP's resolvers.  It responds with the same data is before
>because expiration in their cache is controlled by the regular TTL
>(because the data is in Insecure state).  My resolver detects the
>tampering, and returns a resolution failure to the application, again.
>And so on, until the data expires from the upstream cache.  (With an
>LRU-based cache, my continued queries may ensure that expiration won't
>happen before the original TTL expires.)
>
>Isn't this how the protocol is supposed to work?  Is the continued
>resolution failure an acceptable outcome in this case?

Yes, that's how the protocol is supposed to work.  Yes, it's 
acceptable.  Well, it's all you can get, so you should accept it. 
It's that or nothing.

If you are in a situation in which you need to traverse a single line 
or go through a single box, you are at the mercy of that line or box. 
We spent a lot of time on what was labelled the "clear channel 
problem" in a workshop prior to the IETF in November 2002 on this 
topic.  If you have to get data from a compromised source, your world 
is compromised.

See:
    http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01872.html
and another thread:
    http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01893.html

No way around it, DNSSEC is not going to make packets leap out of the 
wire (or wireless spectrum), bounce around the problem site, and then 
rejoin the network later on.  (Sorry to get colorful.)  DNSSEC can't 
make an underlying untrustworthy media trustworthy, it can only 
prevent you from crossing it.  This is a general dilemma in security 
- if the OS is compromised, so are your cryptographic libraries and 
so on.

In my opinion, this scenario is not too realistic.  In my opinion, 
I'd (first hope for DNSSEC on the ISP server and then) just trust the 
ISP's DNS results.  Sounds risky?  Well, the ISP transports all my 
packets.  If I have problems, I just call their help desk and they 
are moved to fix things.  (Help desk calls are a huge cost.)

We are going to find that doing DNSSEC on the home machines like this 
scenario will cause more headaches than pleasure as time goes by. 
But that's something we shouldn't open up a thread on now.

>I've framed this in terms of an attack, but the same thing happens if
>the zone owner publishes bad DNSKEY records or outdated RRSIG records.
>There are non-DNSSEC equivalents of these errors; a few caching
>recursors implement workarounds (some of which caused problems of
>their own).  With DNSSEC, such workarounds are impossible to provide
>if you haven't got the trust anchors your downstream clients use.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.