Re: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard

[Ólafur Guðmundsson /DNSEXT chair <[e-mail]>]

Speaking as Document Shepherd:

Process history:
DNSEXT WG determined that the scope of this document was to
"make it harder to have spoofed answer packet accepted as legitimate answer",
thus the word "resiliency" in the draft name, thus the focus of the
document is 'packet acceptance'.
The topic of 'data acceptance' was judged to be outside the scope of 
the document.

At 19:17 02/10/2008, Nicholas Weaver wrote:
>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".

While this is true in general, there are number of situations where
not allowing "out-side" queries helps.
For example:
-  Sites that run separate DNS recursive resolvers/caches
    for mail servers than are used by user population in general.
-  Sites that are able to keep malware off internal hosts limit the
    ability of attackers to issue queries from the inside.



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

This is outside the scope of the current document, but the WG is starting
work on the 'data acceptance' topic.


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

After some discussion in the WG this was explicitly ruled outside the
scope of the document.
For the record most of the attacks I'm seeing are trying to spoof the
root and TLD's using "mostly numeric" domain names, in these cases
x20 provides limited defense.


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

This is also in the 'data admission' category not the 'packet acceptance'
but it supports one of my favorite saying: "Optimization is the root cause
of most problems". In this case people were hoping to decrease the
number of queries by learning by a side effect.



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

This is correct and an important observation.
The document should be updated to reflect this.


>And without changing cache acceptance, you must assume that TTL = W in
>sections 7-8.

also correct, Good observation

Thank you for the review.

         Olafur


>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
>>[e-mail] mailing lists by 2008-10-16. Exceptionally,
>>comments may be sent to [e-mail] 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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>