At 7:55 PM +0000 8/29/08, Paul Vixie wrote:
> > What I have not seen, even post-Kaminsky, is a good discussion of
>> what we put into a cache. For example, I am still befuddled about why
>> part of the Kaminsky attack works. If I have a record in my cache
>> with days left on the TTL, why should an attacker be able to change
>> that record with bad information when I'm asking about a different
>> record? The advantage of this ("we gave too long of a TTL and now
>> need to move the IP address quickly") seems to be heavily outweighed
>> by the ease of the attack.
>>
>> --Paul Hoffman, Director
>> --VPN Consortium

>
>RFC 2181 codified a credibility ranking system which controlled some
>aspects of cache replacement.


Right.

>it's possible that it should have said
>more, gone further.


Or that it should be reconsidered in the current light. A small
modification to the text might go a long way. For example, it says:

Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.

Adding "or glue from a primary zone" to the list in the first
sentence would eliminate the effects of the Kaminsky attack, would it
not?

>however, it's ultimately desireable that a long
>TTL not lock out same-credibility replacement data. TTL is about
>expiry not replacement.


That is the crux of the question. It sounds like you disagree with my
assessment that the disadvantage of this policy (the Kaminsky attack)
is stronger than the advantage (allowing replacement before expiry,
even if the replacement is from an attacker).

--Paul Hoffman, Director
--VPN Consortium

--
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: