I believe this draft is insufficient:
4.1: Frankly speaking, with all the mechanisms out there, you must
assume that an attacker can force queries of the attacker's choosing
at times of the attacker's choosing, within a fraction of a second in
almost all cases. This is not by directly generating a request to the
server, but by performing some application operation (eg, mail request
where the SMTP resolver checks it, a Javascript loaded in a victim's
browser, etc. Preventing external recursive queries is about as an
effective defense as a chalk line on the ground saying "do not cross".
More importantly, Time to Live ONLY applies if the cache policy is
such that there are no Race until win attacks. In order to eliminate
race-until-win cases on a particular name, different cache behavior is
necessary over how currently it is specified in RFC2181. See http://www.ietf.org/internet-drafts/draft-weaver-dnsext-comprehensive-resolver-00.txt
section 10 for details on one such cache policy which can prevent
all race-until-win attacks. See http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt
section 3.3/3.4 for an approximation of such a policy.
Section 4 also excludes two significant additional entropy sources
which can't always be used but can often be used: 0x20 matching and
duplication, since ~32b entropy is only marginally sufficient, but 40b
+ (achievable through 0x20 and/or duplication) is for protecting the
cache.
Likewise, section 7-8 explicitly ignore the effects of "race until
win". As long as a resolver will accept any additional data from a
result into the cache, even when in scope (section 6's recommendations
enable race-until-win attacks), TTL becomes 0 regardless of the actual
TTL of the record. This is the real power of the Kaminski attack: it
is not a reduction in packet-work for the attacker, but a reduction in
time.
Thus, the paragraph in section 10 is also incorrect: Long TTLs from
the authority provide no protection unless the recursive resolver
implements the conservative acceptance policy. Long TTLs should not
be encouraged as a security measure, because unless resolver cache
acceptance is changed, they are not a security measure, but could
instead cause more failures/difficulties.
And without changing cache acceptance, you must assume that TTL = W in
sections 7-8.
On Oct 2, 2008, at 3:15 PM, The IESG wrote:
The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Measures for making DNS more resilient against forged answers '
<draft-ietf-dnsext-forgery-resilience-07.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
the
ietf@xxxxxxxx mailing lists by 2008-10-16. Exceptionally,
comments may be sent to iesg@xxxxxxxx instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-07.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15593&rfc_flag=0
--
to unsubscribe send a message to namedroppers-request@xxxxxxxxxxxx
with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf