[dns-operations] The perils of retroactive DNSSEC validation

[Edward Lewis]

At 15:02 +0100 11/20/08, Florian Weimer wrote:

>>  DNSSEC, as it is currently deployed, assumes that it's possible to run
>>  a hierarchy of caches where validition efforts increase down the
>>  hierarchy (that is, an initiator has more trust anchors to work from
>>  than a responding cache).  Therefore, caches are expected to store
>>  data which they cannot validate ("Indeterminate" in the language of
>>  RFC 4035).

>Quoting the original message in full.  Does it make more sense when
>you replace "Indeterminate" with "Insecure"?

No.

First, comparing "Insecure" with "Bad/Bogus".

To me what is called "Insecure" is the same as "Secure."  The reason 
is that, given the complete assortment of records that a validator 
would use in testing the authenticity and integrity of the "RRset 
under test", the validator definitively concludes "DNSSEC is turned 
off for this RRset."  To me that is secure.

Innocent until proven guilty -or- guilty until proven innocent. 
That's the choice.

Given the open nature assumed in the Internet (dang the attacks!) I 
go for the former and believe that unless you can employ the records 
and state that the RRset under test has been tampered with, it's best 
to plough on.  Even if the RRset has a (non-germane to me) signature.

Which assumption is ultimately chosen is up to "local policy" BTW.

So, getting back to the message, and why I curtly answered "no."

Let's look at this question "why would one cache mark an answer as 
'insecure' but another 'secure'?"  The answer lies in local trust 
anchors.  It wouldn't be time-of-day (which might make signature fail 
in one and not the other, bogus) or missing data (indeterminate).

What is the impact of the data being insecure in one place and secure 
in another?  I don't think there is much.  Wouldn't both give the 
same answer regardless of the CD bit setting in the query?  Wouldn't 
both respond with the AD bit set (as in both cases, the data passed 
policy?)

I suppose if a local policy says that cached data that is not 
cryptographically validated is bogus changes things.  And let's go 
with that, even though I think such a policy is not wise (as in 
overly paranoid).  In that case, CD=1 returns SERVFAIL but CD=0 
exposes the bogus data as it is cached.  As always, if you are going 
to validate yourself you should ignore the AD bit in response and set 
CD=1 in the query.

So, what changes insecure to secure - it is the introduction of a DS 
RRset in the right place(s).  It's hard to predict the mean time to 
such an event though, either this happens when a zone transitions 
from one state to another, or someone notices a botched key 
supercession (rollover).  Both of these will involve human 
intervention.  I point that out because I can't see that twiddling 
with the TTL settings is going to matter much.

>>  The question that bugs me is: Why do you think this can actually work?
>>
>>  For Bogus/BAD data (for the distinction or the lack thereof, see my
>>  question on the namedroppers list), an intermediate cache will
>>  eventually make an attempt at fetching the data again.  But not for
>>  Indeterminate data.  So once bad data ends up in the cache hierarchy,
>>  and there's no attempt at validation, it simply stays there, resulting
>>  in a rather effective denial of service.

Considering I equate Secure with Insecure, I don't see the need to 
try to refresh the data.  It'll stay as long as the TTL is ticking 
towards 0.

"So once bad data...it simply stays there" - there isn't any "class" 
of data that is immune to the TTL.  And a nameserver can place a 
limit on how high TTL can be - like, I believe, BIND caps it at one 
week's worth of seconds.

>>  It's hard to see that anyone is going to attempt a cache flush
>>  procedure because our bad experience with updating data before the TTL
>>  expires.  So it's difficult to see how this is going to be fixed.
>>  (Signing the root doesn't help if the caching hierarchy is mostly
>>  non-validating.)

That's true - no one is going to want caches to overwrite data that 
has been used without problem.  And the DNS is careful not to allow a 
TTL to ever be "upped."

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

Never confuse activity with progress.  Activity pays more.