Re: [dnsext] Re: Time-line for forgery resilience phase #2
bert hubert <bert.hubert@netherlabs.nl> Thu, 13 November 2008 20:54 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1683A6807; Thu, 13 Nov 2008 12:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level:
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
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 QL4CM5o7Fd9R; Thu, 13 Nov 2008 12:54:57 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F26223A68B8; Thu, 13 Nov 2008 12:54:56 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1L0j6r-0005xR-6y for namedroppers-data@psg.com; Thu, 13 Nov 2008 20:48:13 +0000
Received: from [2001:888:10:36::2] (helo=adsl-xs4all.ds9a.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <ahu@outpost.ds9a.nl>) id 1L0j6h-0005wq-G4 for namedroppers@ops.ietf.org; Thu, 13 Nov 2008 20:48:09 +0000
Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from <ahu@outpost.ds9a.nl>) id 1L0j6b-0001tR-QF for namedroppers@ops.ietf.org; Thu, 13 Nov 2008 21:47:57 +0100
Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7660F3F64; Thu, 13 Nov 2008 21:47:59 +0100 (CET)
Date: Thu, 13 Nov 2008 21:47:59 +0100
From: bert hubert <bert.hubert@netherlabs.nl>
To: ?lafur Gu?mundsson /DNSEXT chair <ogud@ogud.com>
Cc: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Re: Time-line for forgery resilience phase #2
Message-ID: <20081113204759.GL4821@outpost.ds9a.nl>
References: <200810172024.m9HKOaMV058562@stora.ogud.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200810172024.m9HKOaMV058562@stora.ogud.com>
User-Agent: Mutt/1.5.9i
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
Ok, this is somewhat of a tricky post since my own draft is among the ones circulated. Additionally, some of the criticism I voice below applies to the original forgery-resilience draft as well. So take the below with more than a single grain of salt. Sadly it appears we have not found the magic bullet, where magic bullet is defined as a clear solution that can help us quickly. This rules out anything that takes a lot of parties and time to deploy, or anything that is more of a 'strategy' than a clear cut solution. 0x20 is nice, but breaks some stuff. Repeating queries is nice but breaks some stuff. Determining if we are under attack is nice, but is a DoS vector in some circumstances. Getting smart with disregarding parts of answers is nice, but is not a perfect solution, plus might break some stuff. Etc etc. Summarising, I think the current state of affairs does not allow us to write a draft that recommends full solutions. Sadly, the best we can do right now is standardise things that will give implementors the tools to implement working strategies, strategies which are unkown right now. There is some room for a concise document outlining simple things that help a lot though. Looking at the drafts below: > At this point we have following drafts submitted: > http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.txt Describes a number of valuable strategies, and mandates some others. Unsure if it would reach consensus. > http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt Outlines a lot of theory. Reads like an academic paper. Does not mandate anything, or at least not in capital letters. > http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt > http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00 Both of these provide a way to add more entropy to a query, making it far harder to spoof answers. One of these drafts uses a new record type, the other (mine) a new EDNS0 option. Jim Reid did a great job finding a novel and very hackish way of stuffing in said entropy. The interesting thing about the above two drafts is that they only provide a portal which can be used to develop further spoofing resilience. The strategy of how to use these methods is left up to the caching nameserver implementations, and this strategy is therefore free to evolve over time. > http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt I find this draft to be concise, and it provides a nice mix between theory, recommendations and exhortations. > http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 0x20 is an impressive hack, but does not provide any protection for numerical domains like '123.', and only two bits for '123.nl'. In this sense, it is a very limited measure - as it leaves TLDs especially vulnerable. What would be good is to slip in somewhere that all responding implementations MUST do a bitwise copy of the request name. Implementations are then free to act on the liberty they've gained to assume that complying responders will do a proper copy. Summarising, I'd prefer to focus our attention on: 1) Wouter's document, since it is brief and has the potential to reach consensus. 2) One of the two ways to add entropy to queries (aleatoric, edns-ping) An optimum might be reached if Wouter's document would contain a line like 'responders MUST perform a bitwise copy of the query name'. This would open the door over time for people to rely on 0x20. Kind regards, Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- 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/>
- Time-line for forgery resilience phase #2 Ólafur Guðmundsson /DNSEXT chair
- Re: [dnsext] Re: Time-line for forgery resilience… bert hubert
- [dnsext] Re: Time-line for forgery resilience pha… Stephane Bortzmeyer
- [dnsext] Re: Time-line for forgery resilience pha… Ólafur Guðmundsson /DNSEXT chair
- Re: [dnsext] Re: Time-line for forgery resilience… Ólafur Guðmundsson /DNSEXT chair
- Re: [dnsext] Re: Time-line for forgery resilience… Nicholas Weaver
- Re: [dnsext] Re: Time-line for forgery resilience… Nicholas Weaver
- Re: [dnsext] Re: Time-line for forgery resilience… Otmar Lendl
- RE: [dnsext] Re: Time-line for forgery resilience… Antoin Verschuren