Re: [dnsext] draft-barwood-dnsext-fr-resolver-mitigations-03
Dean Anderson <dean@av8.com> Fri, 17 October 2008 12:41 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 B4DA63A6897; Fri, 17 Oct 2008 05:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.665
X-Spam-Level:
X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 nv6ai64LBPmn; Fri, 17 Oct 2008 05:41:26 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5EC253A67EE; Fri, 17 Oct 2008 05:41:26 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KqoVe-000MNC-Mn for namedroppers-data@psg.com; Fri, 17 Oct 2008 12:32:50 +0000
Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <namedroppers@stora.ogud.com>) id 1KqoVX-000MLy-1m for namedroppers@ops.ietf.org; Fri, 17 Oct 2008 12:32:46 +0000
Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m9HCWe88054170 for <namedroppers@ops.ietf.org>; Fri, 17 Oct 2008 08:32:40 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com)
Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m9HCWeiX054169 for namedroppers@ops.ietf.org; Fri, 17 Oct 2008 08:32:40 -0400 (EDT) (envelope-from namedroppers)
Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from <dean@av8.com>) id 1KqBpy-000Bgo-HJ for namedroppers@ops.ietf.org; Wed, 15 Oct 2008 19:15:23 +0000
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m9FJF8YZ010609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 15 Oct 2008 15:15:09 -0400
Date: Wed, 15 Oct 2008 15:15:07 -0400
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: George Barwood <george.barwood@blueyonder.co.uk>
cc: namedroppers@ops.ietf.org
Subject: Re: [dnsext] draft-barwood-dnsext-fr-resolver-mitigations-03
In-Reply-To: <C68EDF8B003F45D7AE4CB2A734AC61AA@localhost>
Message-ID: <Pine.LNX.4.44.0810151421361.23652-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
[ Note: Post was moderated. ] On Sun, 12 Oct 2008, George Barwood wrote: > I have revised my draft at > > http://www.ietf.org/internet-drafts/draft-barwood-dnsext-fr-resolver-mitigations-03.txt Did the WG decide to take on this draft? My understanding is that 'dnsext' in the name indicates a working group draft as opposed to an individual submission, but the WG page does not list this draft. I must have missed the discussion of whether the WG should take on this work. I am against having the WG take on this draft. Recommendation: Anyone interested in avoiding cache poisoning should use port randomization or TCP, or a combination of both. I suggest that a common deployment scenario consists of a group of site-wide recursors serving stub resolvers. If the stub resolvers are handled with UDP port randomization, and the recursors use TCP, poisoning is limited to MITM attacks. Only the site recursors need to be altered, and this alteration is completely within the current DNS specifications. The stub resolvers (which often do not cache responses) are speedilly serviced by UDP as before. The recursors (which usually do cache responses) get a lot of benefit from the overhead of TCP. Comments on the draft: There is no such thing as a "Kaminsky Attack". The attack to which the draft refers was previously well known, as has been previously reported with complete citations to previous analysis on this list, and on other lists. DNS spoofing and cache poisoning was previously well-known to be trivial, and accomplished in a fraction of a second on many popular name servers; The attack is STILL trivial, and Kaminsky didn't discover anything that made that attack easier. Kaminsky didn't discover ANYTHING novel, nor ANYTHING that bears attachment of a new name. Rather, system administrators unfamiliar with DNS vulnerabilities may have been surprised to learn how easy it was to spoof DNS, but this fact is not new. Continued use of the name "Kaminsky Attack" to describe a previously known attack is a kind of contributory plagarism, since Kaminsky cannot make claim to discovering the attack. The draft asserts that by "repeating the query, additional entropy is obtained". This assertion is false. Repeating the query either lowers the entropy since it just doubles the number of valid outstanding query ids that the attacker. If these QIDs are unique and not reused, there are now only 32k pairs of QIDs (n * n-1; 65536 * 65535), which is less entropy than would be found by ordinary port randomization, but doubling the load on DNS. I have also reported that an attacker can arrange to repeat the same query in an attempt to exploit a birthday problem. Having the nameserver do this on its own initiative just makes the attacker's job that much easier. I am quite uncomfortable with the loose use of the term 'entropy' as a justification that these tests make spoofing any harder. I am especially dubious of the notion that one can inspect DNS payload data to somehow get more 'entropy'. It should also noted that nameservers may reply from a different IP address than the one the query was sent to. This is fairly common on multi-homed computers. One cannot add a check that the IP address is the same. The draft also notes some 'in-essential' information may be lost. There is no 'in-essential' information in DNS, at least, no information that a caching recursor can determine to be 'in-essential'. Any record that exists in DNS must be considered to be meaningful to the site that placed that record. The draft also suggests randomly changing case of the query. DNS is not case sensitive. Randomizing the case of the query and then checking that the case remains the same in the response is a violation of DNS protocol. Whether popular servers currently change case or not has no bearing on whether other servers/implementers can assume this will or will not happen. In 3.4, prepending a random nonce and assuming a "referral is probable" is a violation of protocol. The server that receives a query can send, at its own discretion, a referral or perform recursion. Assuming what the remote server might do when it has a choice is a violation of DNS protoocol. I also note that TCP suffers none of these particular poisoning problems, and the 3way handshake is generally faster than the multi-packet "convergence" contemplated in this draft. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- 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/>
- [dnsext] draft-barwood-dnsext-fr-resolver-mitigat… George Barwood
- Re: [dnsext] draft-barwood-dnsext-fr-resolver-mit… Dean Anderson
- Re: [dnsext] draft-barwood-dnsext-fr-resolver-mit… Eric Rescorla