Re: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard
Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Fri, 03 October 2008 17:25 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B6E3A6A72; Fri, 3 Oct 2008 10:25:49 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36793A68FE; Thu, 2 Oct 2008 16:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.953
X-Spam-Level:
X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87muEqHi-ngb; Thu, 2 Oct 2008 16:18:02 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id DE35C3A6922; Thu, 2 Oct 2008 16:18:02 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m92NHeUe013082; Thu, 2 Oct 2008 16:17:40 -0700 (PDT)
Message-Id: <9D4D9C40-3503-4C85-9236-BE75F4139019@icsi.berkeley.edu>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: ietf@ietf.org
In-Reply-To: <20081002221539.DDFBB3A690B@core3.amsl.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard
Date: Thu, 02 Oct 2008 16:17:40 -0700
References: <20081002221539.DDFBB3A690B@core3.amsl.com>
X-Mailer: Apple Mail (2.929.2)
X-Mailman-Approved-At: Fri, 03 Oct 2008 10:25:48 -0700
Cc: namedroppers@ops.ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, IETF-Announce <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
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@ietf.org mailing lists by 2008-10-16. Exceptionally, > comments may be sent to iesg@ietf.org 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@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: [dnsext] Last Call: draft-ietf-dnsext-forgery… Nicholas Weaver
- Re: [dnsext] Last Call: draft-ietf-dnsext-forgery… Ólafur Guðmundsson /DNSEXT chair
- Re: [dnsext] Last Call: draft-ietf-dnsext-forgery… Nicholas Weaver
- Re: [dnsext] Last Call: draft-ietf-dnsext-forgery… Doug Otis