At 8:26 PM +0000 8/29/08, Paul Vixie wrote:
> > 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?

>
>for replacement, but not insertion, yes.


Agree.

> > >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).

>
>i know there are a lot of working configurations which depend on low latency
>cache replacement and so have long ttl's. we'd be breaking these. i suspect
>that there are more such currently working configurations than i know about.


Could you (or someone) describe these? What is their reason for a
long TTL if they know there is going to be a replacement?

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