Subject: Re: Q-6: May security-aware resolvers cache "Bad" data?

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Mar 2003 14:09:11 +0000

> Pro removal: the crypto equivalent of neg caching is possible.
> OTOH:        an attack of sending bad SIG's can "starve" a cache
> Pro removal: local policy can be to return data only if the cd bit is set
>               (i.e., saves cache from requerying itself on repeated queries)
> OTOH:        not caching it makes the requester try to get it from source
>               (i.e., will return it anyway on +cd, but won't remember)

negative caching functions as a "hold-down", which on the one hand helps
with authority-server and network load as well as average completion time
for queries which will fail due to broken validation chains, but on the
other hand means that a broken chain that is repaired will not be visible
during the negative caching window.

for name nonexistence we tolerate the hold-down because the chance that a
name doesn't exist due to an error is thought to be low compared to the
chance that it really doesn't exist.

for validation failure i think we can make the same assumption.  broken
validation chains are errors, not omissions, and if the minimum retry
interval before trying to validate it again is, say, five minutes, then
it's more likely to help than hurt the zone owner.

but as sam says:

> Maybe it should be left to the implementation.

an implementation who didn't want to do negative caching should not be
considered incorrect by the specification.  so, the language could be
softened from "must not cache" to "may cache, with a negative TTL of up
to the zone minimum ttl, if the SOA was gathered securely, or five
minutes, whichever is shorter."

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Mar 2003 14:15:59 +0000

> Slightly more relevant detail:
> 
> Paul's 14 May message helped reframe the debate for me.  He reminded
> me that opt-in really is optional -- a zone owner can ignore it and
> keep the stronger security guarantees.  If that were the end of the
> story, I'd say we should rely on financial and political pressure, not
> standards process pressure, to make zone owners behave the way we
> want.  Unfortunately, opt-in also adds resolver complexity, which
> means that the proponents need to justify the change.  I'm not sure
> they've done that adequately, but I'm willing to quit fighting.  They
> have contributed to the implementation and testing to show that the
> complexity is manageable, and I thank them for that.

i think that with that as your reason for thinking it's a bad idea, that
standing aside is the right thing to do.  the loss of security to opt-in
is optional, and represents the possibility that some other zone operator
may not want as much security in their zones as you want in yours, and we
would normally say that it's their zone and they should be able to decide
without help from outsiders how secure their zone ought to be.

now as to whether the zone security flexibility being desired is worth,
or not worth, the resolver complexity that's required, we've all been down
that thread and there's apparently nothing new on this controversial topic.
i just want to say: it appears not to be a given, either way.