From owner-namedroppers@ops.ietf.org Fri Aug 1 04:29:08 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585763A680C; Fri, 1 Aug 2008 04:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 H1kvipbUwZWp; Fri, 1 Aug 2008 04:29:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6019428C396; Fri, 1 Aug 2008 04:29:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOsdb-0007MR-Ez for namedroppers-data@psg.com; Fri, 01 Aug 2008 11:17:35 +0000 Received: from [74.125.46.31] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOsdW-0007LY-Bj for namedroppers@ops.ietf.org; Fri, 01 Aug 2008 11:17:33 +0000 Received: by yw-out-2324.google.com with SMTP id 9so625190ywe.71 for ; Fri, 01 Aug 2008 04:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=vP12GwdxnMEXNx7DKtK+nmCFOJ9MPdboCrfXga1pIVE=; b=qJtGA+Bns4kQhRwktpPnobyvpKfeMeBTjRvo06o427BxURp8pCuQeAujfBGCxUMwKS 4rwWW5GD/Wi8FGex6bwNMs+EIft94kGXGnPJQF0omFQXp5WmO1CSuET/fEnyfmGm5F8v ++wMKfKGwL0AQU6M45u4LnB5pQQqaTSWlcPw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=Tm7Xp19SF1/+T1gryJ4NIIwn+1WNFZn2WccNapmJ+OumrMhaGrL65/eIY+JQ5skE4l VNjHqhZIxElLCID6+220emaCPhxdWwxpR95vg6WizMpwN62/VSptAOJmgDq8fwN7//NP 3V44VnrdopB1UFM1G7FP/CjLhiLTYD2PH10Ps= Received: by 10.151.155.5 with SMTP id h5mr3058162ybo.241.1217589448991; Fri, 01 Aug 2008 04:17:28 -0700 (PDT) Received: from gotcha.meeting.ietf.org ( [130.129.23.145]) by mx.google.com with ESMTPS id c29sm2059009elf.16.2008.08.01.04.17.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 Aug 2008 04:17:23 -0700 (PDT) Message-Id: From: John Dickinson To: namedroppers@ops.ietf.org In-Reply-To: <20080801005409.GA94387@commandprompt.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: DNS-spoofing Date: Fri, 1 Aug 2008 12:17:01 +0100 References: <2B760B19-5C02-456A-B4BF-C52A67C34432@blipp.com> <20080801005409.GA94387@commandprompt.com> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 1 Aug 2008, at 01:54, Andrew Sullivan wrote: > [no hat] > > On Thu, Jul 31, 2008 at 08:47:12PM +0200, Patrik Wallstrom wrote: >> John Dickinson demonstrated on the dnsext wg meeting today that you >> can >> spoof a local DNS reslover in 95ms. The resolver had a fixed source >> port. > > I understood from his remarks, also, that John hadn't seen anything > except what had leaked. That is correct. I read what was in a cache of the leaked blog post and I did see the metasploit code that was linked to on this list. However, this work is completely new code. I wrote it from scratch to make sure I fully understood the seriousness of the attack that was being suggested. Now I do! I hope this dispels any remaining myths about the need to deploy patches and DNSSEC. As the people in the room will have seen, the time taken to succeed varies and 95ms was one of the better efforts. My suspicion is that there are a variety of ways to optimize this and I hope to do further work on that. However, I will not publish any details until after Aug 6th. Several people have asked if they can get the a copy of the code - While I am happy to do demos, I hope they will understand that this is not something that I want to release. John -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 1 05:50:27 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78CF23A6AAC; Fri, 1 Aug 2008 05:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_42=0.6, MANGLED_LIPS=2.3] 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 znXuH3dY4FSz; Fri, 1 Aug 2008 05:50:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF9A328C49F; Fri, 1 Aug 2008 05:48:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOtvu-000H0r-Ct for namedroppers-data@psg.com; Fri, 01 Aug 2008 12:40:34 +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 ) id 1KOtvo-000Gzi-0P for namedroppers@ops.ietf.org; Fri, 01 Aug 2008 12:40:31 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KOtvk-0001k6-Ud for namedroppers@ops.ietf.org; Fri, 01 Aug 2008 14:40:25 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 573DF4B479; Fri, 1 Aug 2008 14:40:39 +0200 (CEST) Date: Fri, 1 Aug 2008 14:40:39 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: The math of kaminsky-spoofing a randomising source port resolver Message-ID: <20080801124038.GA5994@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi everybody, It was great fun to listen in on the DNSEXT meeting in Dublin yesterday. In it I heard calls for understanding the problem better before rushing out fixes, or even worse, a series of fixes that we ask people to install ASAP. A few days ago I started to do the math on how hard it is to 'kaminksy-spoof' a fully randomised source port resolver. This message will not elaborate on Dan's finding beyond the fact that it allows an attacker a near infinite amount of chances to spoof a question. The math is fairy trivial, but as I'm no expert it took me some time. I've asked Evgeniy Polyakov and Jasper Spaans to read over my work, and they found no obvious mistakes in it. But do take care, this stuff is fresh, and I am a physics dropout! The math -------- I use the same symbols as in http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience#section-7.2 It may be instructive to read this section before delving into the rest of this message. I: Number distinct IDs available (maximum 65536) P: Number of ports used (maximum around 64000 as ports under 1024 are not always available, but often 1) N: Number of authoritative nameservers for a domain (averages around 2.5) F: Number of 'fake' packets sent by the attacker R: Number of packets sent per second by the attacker W: Window of opportunity, in seconds. Bounded by the response time of the authoritative servers (often 0.1s) D: Average number of identical outstanding queries of a resolver (typically 1, see Section 5) The combined chance to succeed with a single 'non-kaminsky spoofing attempt': If the Window of opportunity length is 'W' and the attacker can send 'R' packets per second, the number of fake packets 'F' that are candidates to be accepted is: D * R * W F = R * W -> P_s = --------- N * P * I Let's assume 'R' is fixed (it is a property of the network between the attacker and the resolver). Each spoofing attempt outlined above takes 'W' seconds. This means that if you have T seconds for your attempt, you can perform T/W separate attacks. The combined chance for success then becomes: T/W P_cs = 1 - ( 1 - P_s) If we put some common numbers in P_s, with source port randomization, we find that P_s is really really small - P*I is in the order of 4*2^32, whereas D, R and W are rather small (say 1, 100k and 0.1). The approximation of P_cs is therefore: WARNING: The approximation I use only applies for source port randomized servers, otherwise the error is too big. It also does not hold for large values of T! T * P_s T * D * R P_cs = --------- = --------- W N * P * I Note how 'W' (the latency with the authentic auth server) fell out of the equation! Plugging in some common numbers, this gives: P_cs = H * R / 1150000 Where H is the number of hours allotted. Again note that this is an approximation,. The full formula, which holds for larger values of R and T: T / W 10 * T ( D * R * W ) ( R ) P_cs = 1 - ( 1 - --------- ) = 1 - ( 1 - --------- ) ( N * P * I ) ( 4.2e10 ) A caveat is that this math does not take into account the packet that asks the original question, which happens once every 'W' seconds. The numbers on the right also assume you can guess the authoritative nameserver that you need to spoof. If you plug in some realistic numbers in the P_cs formula, the chance of succesfully spoofing a domain within two hours is around 8.1%, assuming you can get 50000 packets/second to arrive at the resolver. This will have cost you in the order of 1.5-2 gigabyte of packets though. After 24 hours, the chance rises to around 64% - costing your 0.4TB of packets. For your gnuplotting pleasure: D=1.0 R=5000.0 W=0.1 N=1.0 P=64512 I=65535 Pcs(t) = 1 - (1 - ((D*R*W)/(N*P*I)))**(t/W) Discussion ---------- If you delve into this deeper, it is also possible to do 'front loaded' attacks where you do not wait out the full 'W' time window, but start on a new question after (say) 0.1W already. This turns out not to disturb the numbers measurably. Evgeniy also did the math for not randomly blasting source port*ID packets, but to make sure no duplicates are transmitted, and this turns out not to matter a lot either. The numbers above are all for 'perfect spoofing' - in actual life, packets will get dropped, or the authentic authoritative server gets its answer in quicker etc, so expect real life performance to be worse (or from our perspective, 'better'). Interestingly, setting P=1 predicts very perfect chances of spoofing within 4-8 seconds - about in line with what the exploits out there achieve on non-source port randomised servers. The calculations above do not hold for nameservers that drop a query in case of a detected spoofing attempt (when it sees too many "near misses"). This technique does not invalidate the repeatability of the Kaminksy-technique, but does minimise the chances of each individual spoof succeeding. There is a reasonably popular resolver out there with such spoofing detection. Smarter techniques? ------------------- It may be possible that there are smarter, more adaptive ways to spoof a server. But so far I haven't found them. Evgeniy is the kind of genius however that I expect will discover new techniques if they exist - he is currently working on his code. Conclusion ---------- Even a perfectly source port randomized server can be spoofed, but it takes real work and real amounts of time. More work is needed to protect the DNS. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 1 06:33:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8683A6964; Fri, 1 Aug 2008 06:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.439 X-Spam-Level: X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=0.056, 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 0WaugITx8YdR; Fri, 1 Aug 2008 06:33:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D55173A69DD; Fri, 1 Aug 2008 06:33:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOude-000NAZ-8q for namedroppers-data@psg.com; Fri, 01 Aug 2008 13:25:46 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOudX-000N9x-BK for namedroppers@ops.ietf.org; Fri, 01 Aug 2008 13:25:41 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id A9375C2DA3; Fri, 1 Aug 2008 14:25:36 +0100 (BST) Date: Fri, 01 Aug 2008 14:25:34 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: The math of kaminsky-spoofing a randomising source port resolver Message-ID: <32D09E4A730675AF253882C0@Ximines.local> In-Reply-To: <20080801124038.GA5994@outpost.ds9a.nl> References: <20080801124038.GA5994@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bert, --On 1 August 2008 14:40:39 +0200 bert hubert wrote: > T * P_s T * D * R > P_cs = --------- = --------- > W N * P * I I see nothing wrong in your maths. Taking it from this stage put in (as you suggest) D=1 N=2.5 I=65536 And look for P_cs=0.5 0.5 = T * 1 * R ---------- 2.5 * P * 65536 T = 81920 * P / R (seconds, for a 50% success rate) Or R = 81920 * P / T So, for an attack on a non randomised port (P=1) to be more likely to succeed than not within 100ms, you need approx 82,000 pps. Assuming Malory is prepared to wait a day for his attack, he only needs to send one packet every 10 seconds (practically undetectable). With port randomisation (P=64000), Malory will need approximately 64,000 pps to have an even chance of a successful attack within a day. Due to the effect of caching, Malory can presumably stop his attack when he has a first successful hit, and the record will remain for just as long as the TTL of the spoofed record. This is assuming Malory doesn't do anything intelligent to speed up his attack or parallelise multiple attacks, which would of course make things easier. It goes without saying that it would be trivial to orchestrate an attack that focused solely on nameservers with low values of P, as (e.g.) the OARC test demonstrate it's possible to guess this remotely. Alex -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 3 05:03:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307523A6A8D; Sun, 3 Aug 2008 05:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 w4pTVtMz3uR3; Sun, 3 Aug 2008 05:03:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 319413A6A30; Sun, 3 Aug 2008 05:03:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPc9M-000IB8-EE for namedroppers-data@psg.com; Sun, 03 Aug 2008 11:53:24 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPc9D-000IAV-Rd for namedroppers@ops.ietf.org; Sun, 03 Aug 2008 11:53:21 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 3D54033C1C; Sun, 3 Aug 2008 12:53:12 +0100 (BST) Message-ID: <48959C2C.4010107@links.org> Date: Sun, 03 Aug 2008 12:53:16 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Thierry Moreau CC: Eric Rescorla , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> <63353.1216579390@nsa.vix.com> <20080720224723.A215850846@romeo.rtfm.com> <48841429.6050905@links.org> <20080721044832.BA391498162@kilo.rtfm.com> <4884966D.2070801@connotech.com> In-Reply-To: <4884966D.2070801@connotech.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Thierry Moreau wrote: > > > Eric Rescorla wrote: > >> At Mon, 21 Jul 2008 05:44:25 +0100, >> Ben Laurie wrote: >> >>> Eric Rescorla wrote: >>> >>>> >>>> So, I'm not saying that l-o-f will necessarily work here, but >>>> I don't think it's necessary to prompt the user. Rather, you >>>> can just accept the first key you see... >>> >>> And prompt them when it changes? >> >> >> Good question. Probably retry via the original channel. I agree it's >> not a real adequate answer... >> > > This is the pervasive question for almost all security schemes. How does > a client system establish, and then "maintain", trust in a remote party > which you (the designer, with your opinion perhaps reflected reflected > in a "policy") assume equiped with more skills in IT security management. > > DNSEXT revisits this question because ... because what, I don't know. > Actually the question belongs to the IT security community of experts > which never addressed the question for what it is, i.e. pervasive for > almost all security schemes. I think the security community has failed to grasp this nettle in many areas, not just the "trust" question (I dislike that word, but it is the term of art). In practice we've had the cryptographic and protocol answers to many security problems for a long time. What we have consistently failed to address is the fact that security is actually a UI problem, not a technical one. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 3 07:05:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A003A63EC; Sun, 3 Aug 2008 07:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-0.404, 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 LT-4eu3F32I6; Sun, 3 Aug 2008 07:05:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70CFA3A692F; Sun, 3 Aug 2008 07:04:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPe5w-0002V9-QF for namedroppers-data@psg.com; Sun, 03 Aug 2008 13:58:00 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPe5s-0002Ul-WF for namedroppers@ops.ietf.org; Sun, 03 Aug 2008 13:57:58 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 52871FF26C; Sun, 3 Aug 2008 23:57:54 +1000 (EST) Message-ID: <4895B95C.8020906@e164.org> Date: Sun, 03 Aug 2008 23:57:48 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Ben Laurie CC: Thierry Moreau , Eric Rescorla , namedroppers@ops.ietf.org Subject: Re: transaction security in the last mile References: <5721.1216397728@nsa.vix.com> <87abgfosmc.fsf@mid.deneb.enyo.de> <48832197.80603@links.org> <46510.1216569565@nsa.vix.com> <20080720172348.CC45050846@romeo.rtfm.com> <63353.1216579390@nsa.vix.com> <20080720224723.A215850846@romeo.rtfm.com> <48841429.6050905@links.org> <20080721044832.BA391498162@kilo.rtfm.com> <4884966D.2070801@connotech.com> <48959C2C.4010107@links.org> In-Reply-To: <48959C2C.4010107@links.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ben Laurie wrote: > I think the security community has failed to grasp this nettle in many > areas, not just the "trust" question (I dislike that word, but it is the Try 'confidence' instead, as I keep saying every time it comes up, the term 'trust' has been abused by cryptographers for a very long time, and the term only makes sense after a continued relationship to determine if you trust the other party or not. After all would you 'trust' someone with your car or your child just because they have a SSL certificate that is signed by a company with their root certificate in the browser? Where as the term 'confidence' you place a level of confidence in seeing the lock that the connection is encrypted, you have a level of confidence that most companies, most of the time > term of art). In practice we've had the cryptographic and protocol > answers to many security problems for a long time. What we have > consistently failed to address is the fact that security is actually a > UI problem, not a technical one. I think things are actually going backwards to be honest, the way firefox (it's the worst offender now) and other browsers treat invalid and self signed certs means most if not all people that could benefit from at least self signed certs don't use any encryption to prevent pop-up messages from pestering everyone to death. It really is to the detriment of everyone that some of these snake oil sales men have pushed things in this direction. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 3 11:17:16 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174913A6BE7; Sun, 3 Aug 2008 11:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_50=0.001, 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 eMiKJIwcDedT; Sun, 3 Aug 2008 11:17:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3A9B3A691E; Sun, 3 Aug 2008 11:17:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPi26-000Pqg-4b for namedroppers-data@psg.com; Sun, 03 Aug 2008 18:10:18 +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 ) id 1KPi20-000Ppi-K3 for namedroppers@ops.ietf.org; Sun, 03 Aug 2008 18:10:15 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KPi1w-0003UZ-KY for namedroppers@ops.ietf.org; Sun, 03 Aug 2008 20:10:08 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A99754B455; Sun, 3 Aug 2008 20:10:20 +0200 (CEST) Date: Sun, 3 Aug 2008 20:10:20 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: Some lighter thoughts.. Message-ID: <20080803181020.GA12763@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In jest, but I was reading 'The trouble with physics' http://www.thetroublewithphysics.com/ and the resemblance struck me :-) For more about this 11 or 26-dimensional theory, head to http://en.wikipedia.org/wiki/String_Theory The Top-10 Reasons Why DNSSEC Is the String Theory of the Internet ------------------------------------------------------------------ 10. Adds many new dimensions to an already complex problem 9. Hogs all the research funds 8. Has many careers riding on it 7. Widely hailed by expert and layman alike as the next big thing 6. Responds to shortcomings by reinventing itself and doubling its complexity 5. On its third iteration to succes 4. Attracts the brightest minds of the industry 3. Cult-like following among believers 2. Always on the verge of solving a real world problem 1. Will be ready in 6 months! -- 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: From MAILER-DAEMON Sun Aug 3 23:57:41 2008 Return-Path: <> X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC30B3A6C18 for ; Sun, 3 Aug 2008 23:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 fAz-tThY1zEG for ; Sun, 3 Aug 2008 23:57:40 -0700 (PDT) Received: from mail.abanet.org (mail.abanet.org [208.49.131.13]) by core3.amsl.com (Postfix) with ESMTP id BDAD43A6C02 for ; Sun, 3 Aug 2008 23:57:40 -0700 (PDT) From: "Delivery Subsystem" To: Subject: Message Delivery Failure - Angelina Jolie Free Video. Date: Mon, 04 Aug 2008 01:57:00 -0500 Message-ID: <8BA0DE9CA5D148738C65BC7D6A78C053.MAI@mail.abanet.org> X-MEFilter: 1 Precedence: bulk MailEnable: Message could not be delivered to some recipients. The following recipient(s) could not be reached: Recipient: [SMTP:dnsextf@mail.abanet.org] Reason: Remote SMTP Server Returned: 550 No such list. Message headers follow: Received: from gawin-vuqk925em ([81.219.144.210]) by mail.abanet.org with MailEnable ESMTP; Mon, 04 Aug 2008 01:56:59 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Return-Path: communications_msn_cs_enus@cimail15.msn.com Message-Id: <20080804095746.3014.qmail@gawin-vuqk925em> To: Subject: Angelina Jolie Free Video. From: MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit From owner-namedroppers@ops.ietf.org Mon Aug 4 03:52:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14BB3A6992; Mon, 4 Aug 2008 03:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, 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 OC+d6-uInU3t; Mon, 4 Aug 2008 03:52:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E40F03A6BE5; Mon, 4 Aug 2008 03:52:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPxYg-000Ajy-O2 for namedroppers-data@psg.com; Mon, 04 Aug 2008 10:44:58 +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 ) id 1KPxYY-000Aj9-Pt for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 10:44:56 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KPxYW-0005lf-0H for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 12:44:48 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 41DAC4B471; Mon, 4 Aug 2008 12:45:02 +0200 (CEST) Date: Mon, 4 Aug 2008 12:45:02 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: correction! Re: The math of kaminsky-spoofing a randomising source port resolver Message-ID: <20080804104502.GA32568@outpost.ds9a.nl> References: <20080801124038.GA5994@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080801124038.GA5994@outpost.ds9a.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 01, 2008 at 02:40:39PM +0200, bert hubert wrote: > If you plug in some realistic numbers in the P_cs formula, the chance of > succesfully spoofing a domain within two hours is around 8.1%, assuming you > can get 50000 packets/second to arrive at the resolver. > > This will have cost you in the order of 1.5-2 gigabyte of packets though. > > After 24 hours, the chance rises to around 64% - costing your 0.4TB of packets. The first gigabyte number is wrong - 2 hours of this will cost you around 36GB of packets. 24 hours around 0.4TB of packets. This is assuming 100 bytes per attempt, which at 50000 packets/s is around 40 megabits/s. Given some overhead, make it a good 50 megabits/s. 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 05:51:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB383A68F2; Mon, 4 Aug 2008 05:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.796 X-Spam-Level: ** X-Spam-Status: No, score=2.796 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 IBzIfr3Q-UGe; Mon, 4 Aug 2008 05:51:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C6FD33A68E3; Mon, 4 Aug 2008 05:51:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPzSU-000MeO-5K for namedroppers-data@psg.com; Mon, 04 Aug 2008 12:46:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KPzSI-000Mce-En for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 12:46:32 +0000 Received: (qmail 95885 invoked from network); 4 Aug 2008 13:34:04 -0000 Received: from p1027-ipbf212sapodori.hokkaido.ocn.ne.jp (HELO necom830.hpcl.titech.ac.jp) (222.148.0.27) by necom830.hpcl.titech.ac.jp with SMTP; 4 Aug 2008 13:34:04 -0000 Message-ID: <4896FA14.2030103@necom830.hpcl.titech.ac.jp> Date: Mon, 04 Aug 2008 21:46:12 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> In-Reply-To: <20080804104502.GA32568@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert wrote: > correction! Re: The math of kaminsky-spoofing a randomising source port resolver Why do you call such a well known vulnerability of DNS, which was documented in section 2.2 of RFC3822 in 2004 several years after it had been publicly known, kaminsky-spoofing? > This is assuming 100 bytes per attempt, which at 50000 packets/s is around > 40 megabits/s. Given some overhead, make it a good 50 megabits/s. Your bandwidth figure is applicable to attackers but not to victims of the attackers attacking many victims at once. So, if an attacker have 1000 victims, the attacker needs 1/1000 less time to compromise one or more victims of the attacker than an attacker with only one victim and each victim feel 1/1000 less amount of traffic. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 07:05:10 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9B93A6CC1; Mon, 4 Aug 2008 07:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 BE--Scwxtr9x; Mon, 4 Aug 2008 07:05:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4BA453A6803; Mon, 4 Aug 2008 07:05:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0Z3-0004Gn-Cf for namedroppers-data@psg.com; Mon, 04 Aug 2008 13:57:33 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0Yw-0004Ea-QQ for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 13:57:29 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KQ0Yg-00026C-UU; Mon, 04 Aug 2008 15:57:10 +0200 Received: from fweimer by bfk.de with local id 1KQ0Yn-0007Ka-S5; Mon, 04 Aug 2008 15:57:17 +0200 To: Masataka Ohta Cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> From: Florian Weimer Date: Mon, 04 Aug 2008 15:57:17 +0200 In-Reply-To: <4896FA14.2030103@necom830.hpcl.titech.ac.jp> (Masataka Ohta's message of "Mon, 04 Aug 2008 21:46:12 +0900") Message-ID: <82hca0khmq.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Masataka Ohta: > bert hubert wrote: > >> correction! Re: The math of kaminsky-spoofing a randomising source port = resolver > > Why do you call such a well known vulnerability of DNS, which was > documented in section 2.2 of RFC3822 in 2004 several years after it > had been publicly known, kaminsky-spoofing? I think you mean section 2.3 of RFC 3822. I agree that the basic attack is presented in that section. I'm not sure if the authors were fully aware of the implications. I guess ISC would have rolled out source port randomization a long time ago if they were. > So, if an attacker have 1000 victims, the attacker needs 1/1000 less > time to compromise one or more victims of the attacker than an attacker > with only one victim and each victim feel 1/1000 less amount of traffic. Correct. And as we've seen over and over again, you can actually monetize attacks even if you don't know the identities of your victims before you start the attack, so it's a real problem. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 07:24:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C733A6803; Mon, 4 Aug 2008 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PVKh+7087+wH; Mon, 4 Aug 2008 07:24:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E10C3A67B3; Mon, 4 Aug 2008 07:24:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0tK-00071x-VJ for namedroppers-data@psg.com; Mon, 04 Aug 2008 14:18:30 +0000 Received: from [2001:7b8:206:1:216:76ff:feb8:3c02] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0tF-00070i-Re for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 14:18:28 +0000 Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m74EILl0077259 for ; Mon, 4 Aug 2008 16:18:21 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200808041418.m74EILl0077259@bartok.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver In-reply-to: Your message of Mon, 04 Aug 2008 15:57:17 +0200. <82hca0khmq.fsf@mid.bfk.de> Date: Mon, 04 Aug 2008 16:18:21 +0200 From: Jaap Akkerhuis X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (bartok.nlnetlabs.nl [127.0.0.1]); Mon, 04 Aug 2008 16:18:21 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > Why do you call such a well known vulnerability of DNS, which was > documented in section 2.2 of RFC3822 in 2004 several years after it > had been publicly known, kaminsky-spoofing? I think you mean section 2.3 of RFC 3822. I agree that the basic attack is presented in that section. There is no section 2.3 in RFC 3822. That RFC is about "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)" so I'm a bit lost where you all are talking about. jaap -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 07:30:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E5228C2AB; Mon, 4 Aug 2008 07:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 RpLg9pzmObnG; Mon, 4 Aug 2008 07:30:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D2C228C27F; Mon, 4 Aug 2008 07:30:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0xa-0007Y7-Ei for namedroppers-data@psg.com; Mon, 04 Aug 2008 14:22:54 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ0xW-0007XJ-8W for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 14:22:52 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 8F543A45C0 for ; Mon, 4 Aug 2008 14:22:41 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Mon, 04 Aug 2008 15:57:17 +0200." <82hca0khmq.fsf@mid.bfk.de> References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 04 Aug 2008 14:22:41 +0000 Message-ID: <18763.1217859761@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 8F543A45C0.20CD8 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Florian Weimer > > * Masataka Ohta: > > Why do you call such a well known vulnerability of DNS, which was > > documented in section 2.2 of RFC3822 in 2004 several years after it > > had been publicly known, kaminsky-spoofing? > > I think you mean section 2.3 of RFC 3822. I agree that the basic > attack is presented in that section. > > I'm not sure if the authors were fully aware of the implications. I > guess ISC would have rolled out source port randomization a long time > ago if they were. indeed, noone on earth knew that this could be done in 11 seconds until february 2008. given the severe trauma caused by udp port randomization for firewalls and NATs and solaris-10 and so on, i think there was a real and correct cost-benefit tradeoff being made when this attack took days or weeks of sustained multimegabit traffic to pull off. > > So, if an attacker have 1000 victims, the attacker needs 1/1000 less > > time to compromise one or more victims of the attacker than an attacker > > with only one victim and each victim feel 1/1000 less amount of traffic. > > Correct. And as we've seen over and over again, you can actually > monetize attacks even if you don't know the identities of your victims > before you start the attack, so it's a real problem. agreed. my two even-worse-case scenarios for this have been every bot doing a short 200-packet attack on some random RDNS every time it's about to go back into its wait-for-command mode, and then the high-fanout mode described above by masataka. if the attacker's goal is to drive traffic to a phishing site, then rather than think of creative ways to spell ebay's or paypal's or a bank's URI-domain, or hiding that spelling behind images or javascript, they can just toss their seeds into the wind and let them sprout where they may. (i live outside any city, and i have great respect for the power of weeds and wild grasses to gradually take over every open acre.) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 08:46:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E0C3A6CD8; Mon, 4 Aug 2008 08:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 J90uO3tDI1Kk; Mon, 4 Aug 2008 08:46:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E01F3A6B6F; Mon, 4 Aug 2008 08:46:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2AO-000GHw-66 for namedroppers-data@psg.com; Mon, 04 Aug 2008 15:40:12 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2AK-000GGq-4f for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 15:40:10 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KQ2A5-000825-0f; Mon, 04 Aug 2008 17:39:53 +0200 Received: from fweimer by bfk.de with local id 1KQ2A9-0002t0-4Q; Mon, 04 Aug 2008 17:39:57 +0200 To: Jaap Akkerhuis Cc: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver References: <200808041418.m74EILl0077259@bartok.nlnetlabs.nl> From: Florian Weimer Date: Mon, 04 Aug 2008 17:39:56 +0200 In-Reply-To: <200808041418.m74EILl0077259@bartok.nlnetlabs.nl> (Jaap Akkerhuis's message of "Mon, 04 Aug 2008 16:18:21 +0200") Message-ID: <82k5ewiyb7.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Jaap Akkerhuis: > > > > Why do you call such a well known vulnerability of DNS, which was > > documented in section 2.2 of RFC3822 in 2004 several years after it > > had been publicly known, kaminsky-spoofing? >=20=20=20=20=20 > I think you mean section 2.3 of RFC 3822. I agree that the basic > attack is presented in that section. >=20=20=20=20=20 > There is no section 2.3 in RFC 3822. RFC 3833, sorry. *argh* --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 08:57:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF27928C2FA; Mon, 4 Aug 2008 08:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 K0AOw10OpBGZ; Mon, 4 Aug 2008 08:56:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1164C28C2FB; Mon, 4 Aug 2008 08:56:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2MG-000HlX-Uk for namedroppers-data@psg.com; Mon, 04 Aug 2008 15:52:28 +0000 Received: from [2001:748:301::2] (helo=shinjuku.zaphods.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ2MC-000HjY-Th for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 15:52:27 +0000 Received: from zaphodb by shinjuku.zaphods.net with local (Exim 4.69) (envelope-from ) id 1KQ2M5-0004eG-OB for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 17:52:17 +0200 Date: Mon, 4 Aug 2008 17:52:17 +0200 From: Stefan Schmidt To: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver Message-ID: <20080804155217.GL18233@zaphods.net> References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18763.1217859761@nsa.vix.com> X-Origin-AS: AS5430 X-NCC-nic-hdl: ZAP-RIPE User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Aug 04, 2008 at 02:22:41PM +0000, Paul Vixie wrote: > > I'm not sure if the authors were fully aware of the implications. I > > guess ISC would have rolled out source port randomization a long time > > ago if they were. > > indeed, noone on earth knew that this could be done in 11 seconds until > february 2008. given the severe trauma caused by udp port randomization > for firewalls and NATs and solaris-10 and so on, i think there was a real > and correct cost-benefit tradeoff being made when this attack took days > or weeks of sustained multimegabit traffic to pull off. Tradeoff yes, trauma not really for that is something that requires a shock. You knew that this patch needed some ironing out and that the best way of achieving that is to just roll it out, no need to be shocked about that now. When i switched our recursive DNS from BIND9 to PowerDNS recursor in 2006 i was surprised that the recursor didn't use up more system resources than BIND9 even so it did randomize the query port. Apparently this can be done right and from what i hear this also works pretty well on Solaris installations. For years before my switch i wondered why ISC did not simply use Linux' epoll or FreeBSD's kqueue where available, how about you? Stefan -- "cron loves you too, that's why it sends you so much mail." - Paul Vixie, author of Vixie Cron -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 09:58:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936513A6783; Mon, 4 Aug 2008 09:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 jb+YjgFTC2jN; Mon, 4 Aug 2008 09:58:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62CF33A68E4; Mon, 4 Aug 2008 09:58:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ3E6-000Oaa-L0 for namedroppers-data@psg.com; Mon, 04 Aug 2008 16:48:06 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ3E1-000OZp-RH for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 16:48:03 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3BC08A4D84 for ; Mon, 4 Aug 2008 16:47:57 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Mon, 04 Aug 2008 17:52:17 +0200." <20080804155217.GL18233@zaphods.net> References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <20080804155217.GL18233@zaphods.net> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 04 Aug 2008 16:47:57 +0000 Message-ID: <34451.1217868477@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 3BC08A4D84.5264A X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Stefan Schmidt > > On Mon, Aug 04, 2008 at 02:22:41PM +0000, Paul Vixie wrote: > > indeed, noone on earth knew that this could be done in 11 seconds until > > february 2008. given the severe trauma caused by udp port randomization > > for firewalls and NATs and solaris-10 and so on, i think there was a real > > and correct cost-benefit tradeoff being made when this attack took days > > or weeks of sustained multimegabit traffic to pull off. > > Tradeoff yes, trauma not really for that is something that requires a shock. > You knew that this patch needed some ironing out and that the best way of > achieving that is to just roll it out, no need to be shocked about that now. let's be clear about this. neither dnscache nor powerdns was creating as many simultaneous upstream flows in those years as the kaminsky defense requires, and the market size for these tools was in those years so small that many of the firewall / NAT / kernel instabilities BIND is running into as we deploy UDP port randomization were simply not encountered until now. smaller and less popular implementations need have no fear of damaging their reputations by being seen "legislating from the bench". in BIND's case we are not able to adopt simplistic attitudes like "requires a shock" lest our user community storm our front yard with torches and pitchforks in hand. that's why the nuanced view of this is as a "real and correct cost-benefit tradeoff". now that kaminsky changed the costs and benefits, ISC has adapted. > When i switched our recursive DNS from BIND9 to PowerDNS recursor in 2006 > i was surprised that the recursor didn't use up more system resources > than BIND9 even so it did randomize the query port. Apparently this can > be done right and from what i hear this also works pretty well on Solaris > installations. see above. > For years before my switch i wondered why ISC did not simply use Linux' > epoll or FreeBSD's kqueue where available, how about you? because it didn't make any performance difference for the number of descriptors we had open simultaneously, this was another cost-benefit tradeoff. there was insufficient need to justify the complexity. post kaminsky, there is sufficient need to justify the complexity. > "cron loves you too, that's why it sends you so much mail." > - Paul Vixie, author of Vixie Cron :-). -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 10:53:09 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14FB3A67A1; Mon, 4 Aug 2008 10:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 9bkeI8x3P2S8; Mon, 4 Aug 2008 10:53:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2ADF3A6783; Mon, 4 Aug 2008 10:53:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ47c-00056T-4U for namedroppers-data@psg.com; Mon, 04 Aug 2008 17:45:28 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ47V-00054I-TG for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 17:45:24 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KQ47L-00072p-9W for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 19:45:11 +0200 Received: from fweimer by bfk.de with local id 1KQ47S-0008WD-4k for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 19:45:18 +0200 To: namedroppers@ops.ietf.org Subject: Large EDNS0 buffer sizes and IPv6 From: Florian Weimer Date: Mon, 04 Aug 2008 19:45:18 +0200 Message-ID: <82wsiwfzdd.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: How do you make large EDNS0 buffer sizes work with IPv6? I couldn't find anything about that in the RFC or in the draft. Unlike IPv4, IPv6 doesn't fragment in the core. This means that the source must perform path MTU discovery and fragment on its own. This, in turn, requires client-specific state, which is generally considered a bad thing. What am I missing? Apparently, this was raised by Itojun at IETF48 back in 2000, but I don't see how it was resolved. Implementations with buffer sizes greater than 1400 bytes seem to fragment according to the link MTU they are connected to, and do not care about the path MTU. (I haven't got native IPv6, so it's hard for me to tell what's going on.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 12:29:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129523A68F9; Mon, 4 Aug 2008 12:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 fhrcNCzybGMs; Mon, 4 Aug 2008 12:29:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 202DB3A6922; Mon, 4 Aug 2008 12:29:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ5eg-000FRU-3r for namedroppers-data@psg.com; Mon, 04 Aug 2008 19:23:42 +0000 Received: from [209.8.43.226] (helo=triton.bsd-unix.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ5ec-000FR3-BN for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 19:23:40 +0000 Received: from localhost (localhost [127.0.0.1]) by triton.bsd-unix.net (Postfix) with ESMTP id E388B9B43D for ; Mon, 4 Aug 2008 15:23:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at bsd-unix.net Received: from triton.bsd-unix.net ([127.0.0.1]) by localhost (triton.bsd-unix.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VEOcC7oOemlL for ; Mon, 4 Aug 2008 15:23:37 -0400 (EDT) Received: by triton.bsd-unix.net (Postfix, from userid 1001) id C1CDC9B420; Mon, 4 Aug 2008 15:23:37 -0400 (EDT) Date: Mon, 4 Aug 2008 15:23:37 -0400 From: Bryan Seitz To: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver Message-ID: <20080804192337.GA88503@bsd-unix.net> References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <20080804155217.GL18233@zaphods.net> <34451.1217868477@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34451.1217868477@nsa.vix.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Aug 04, 2008 at 04:47:57PM +0000, Paul Vixie wrote: > > From: Stefan Schmidt > > > > On Mon, Aug 04, 2008 at 02:22:41PM +0000, Paul Vixie wrote: > > > indeed, noone on earth knew that this could be done in 11 seconds until > > > february 2008. given the severe trauma caused by udp port randomization > > > for firewalls and NATs and solaris-10 and so on, i think there was a real > > > and correct cost-benefit tradeoff being made when this attack took days > > > or weeks of sustained multimegabit traffic to pull off. > > > > Tradeoff yes, trauma not really for that is something that requires a shock. > > You knew that this patch needed some ironing out and that the best way of > > achieving that is to just roll it out, no need to be shocked about that now. > > let's be clear about this. neither dnscache nor powerdns was creating as many > simultaneous upstream flows in those years as the kaminsky defense requires, > and the market size for these tools was in those years so small that many of > the firewall / NAT / kernel instabilities BIND is running into as we deploy > UDP port randomization were simply not encountered until now. > FYI, In early 2006 I migrated approximately 120 BIND nameserver installations down to approximately 30 PowerDNS installations for a very large ISP. This migration not only allowed us to scale down the number of servers and save money on server hardware, but also improved query latencies and increased security due to port randomization. Thus, source port randomization did not have an impact performance and we were able to reduce our server count by a factor of 4. > > "cron loves you too, that's why it sends you so much mail." > > - Paul Vixie, author of Vixie Cron > > :-). it sure does ;) -- Bryan G. Seitz -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 13:13:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DF63A691C; Mon, 4 Aug 2008 13:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 VPGir5TBZlJc; Mon, 4 Aug 2008 13:13:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C24B93A68AB; Mon, 4 Aug 2008 13:13:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ6KE-000KWL-Qc for namedroppers-data@psg.com; Mon, 04 Aug 2008 20:06:38 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ6K6-000KVD-GF for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 20:06:34 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m74K97dl013040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Aug 2008 13:09:10 -0700 Date: Mon, 4 Aug 2008 16:06:26 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: NomCom call for volunteers Message-ID: <20080804200625.GR387@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Mon, 04 Aug 2008 13:09:11 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, At the request of the Nomcom Chair, I'm sending this reminder that he is looking for volunteers to serve. For more information on this, including eligibility criteria and selection procedures, please have a look at the message the Nomcom Chair sent: https://datatracker.ietf.org/ann/nomcom/1617/ Best regards, Andrew -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 14:04:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092CF3A6A35; Mon, 4 Aug 2008 14:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] 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 iYicWwMyO6WW; Mon, 4 Aug 2008 14:04:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 329273A67FA; Mon, 4 Aug 2008 14:04:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ771-0000OX-EO for namedroppers-data@psg.com; Mon, 04 Aug 2008 20:57:03 +0000 Received: from [2001:748:301::2] (helo=shinjuku.zaphods.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ76f-0000MM-Pm for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 20:57:00 +0000 Received: from gatekeeper.research.zaphods.net ([194.97.1.3]:49422 helo=silver-surfer.vlan23.zaphods.net) by shinjuku.zaphods.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1KQ76d-0001SB-9A for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 22:56:39 +0200 Message-Id: <2834EAE2-6B09-43E7-A012-7B92FA4E7FCD@zaphods.net> From: Stefan Schmidt To: namedroppers@ops.ietf.org In-Reply-To: <34451.1217868477@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver Date: Mon, 4 Aug 2008 22:56:36 +0200 References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <20080804155217.GL18233@zaphods.net> <34451.1217868477@nsa.vix.com> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 04.08.2008, at 18:47, Paul Vixie wrote: > let's be clear about this. neither dnscache nor powerdns was > creating as many > simultaneous upstream flows in those years as the kaminsky defense > requires, There you lost me, i am totally unclear what you mean by upstream flows. In case of PowerDNS recursor: Less outgoing queries per recursive lookup, true, but that did not change post 'kaminsky'. As for releases i don't consider OS distributions upstream but anyway there had been some. > and the market size for these tools was in those years so small that > many of > the firewall / NAT / kernel instabilities BIND is running into as we > deploy > UDP port randomization were simply not encountered until now. True if you're counting market size in deployments and not users served. > smaller and less popular implementations need have no fear of > damaging their > reputations by being seen "legislating from the bench". in BIND's > case we are > not able to adopt simplistic attitudes like "requires a shock" lest > our user > community storm our front yard with torches and pitchforks in hand. > > that's why the nuanced view of this is as a "real and correct cost- > benefit > tradeoff". now that kaminsky changed the costs and benefits, ISC > has adapted. So smaller is easier and closer to the community. Sounds like better to me. *scnr* Stefan -- "Since light travels faster than sound, people appear bright until you hear them speak." - anonymous -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 14:08:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DE93A6D2D; Mon, 4 Aug 2008 14:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[AWL=-0.956, BAYES_50=0.001, 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 yDV4rX+1n6F1; Mon, 4 Aug 2008 14:08:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15B6C3A6CE6; Mon, 4 Aug 2008 14:08:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ7Cv-00015I-Ip for namedroppers-data@psg.com; Mon, 04 Aug 2008 21:03:09 +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 ) id 1KQ7Co-00014E-IN for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 21:03:06 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KQ7Cl-0003uJ-T0 for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 23:02:59 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 367A14B451; Mon, 4 Aug 2008 23:03:14 +0200 (CEST) Date: Mon, 4 Aug 2008 23:03:14 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: calculating the chance of spoofing an agile source port randomised resolver Message-ID: <20080804210313.GA10867@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear working group, This message sets out to calculate how hard it is to spoof a resolver that takes simple, unilateral, steps to prevent such spoofing. Unilateral in this case means that any resolver can implement these steps, without changing the DNS protocol or authoritative server behaviour. Everybody that implements the ideas below immediately improves the general security of the DNS. To save you all the reading, the simple unilateral measures can bring down the chance to be spoofed to under 1% after a year of non-stop 50 megabit/s packet blasting. Note however that my math or my ideas may be wrong. Please read carefully! Work so far ----------- Recapping, calculations so far show that a fully source port randomized nameserver can be spoofed with a 64% chance of success within 24 hours, requiring around 0.4TB of packets to be generated. If 2 hours are available, the chance of success is 8.1%. This assumes that the attacker is able to generate around 50 megabits/s, and also important, that the resolver is able to process 50k incoming responses/s. Details are on http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01194.html with the caveat that where it says "1.5 - 2 GB", it should say "36GB". Since that posting, quite a number of people have studied the calculations, and they appear to hold up. Note that the present post does not address the dangers created by those able to actively intercept and modify traffic - people with such abilities have little need to spoof DNS anyhow. Situation --------- The current situation is not acceptable - the resources needed to perform a successful spoofing attack are available, if not generally, then to an relevant subset of Internet users. It turns out that it takes a lot of effort to get the world to apply even a minor patch that has received tremendous front-page coverage on all the security websites - the source port randomisation patches in this case. So if we want to move quickly, we need a solution that can be rolled out without having to upgrade large parts of the Internet. Agile countermeasures --------------------- There are a number of strategies a resolver could employ to make itself effectively unspoofeable, some of these include: A) Sending out questions over TCP/IP B) Repeating questions a number of times, and requiring the answers to be equivalent The problems with these two techniques is that they imply a certain overhead and increase the general CPU utilization on the Internet. Furthermore there are strategies that make spoofing harder, but not impracticable: C) Case games ('dns-0x20') D) Use multiple source addresses A very comprehensive enumeration of techniques can be found on http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01131.html Sadly, it appears that on this impressive list there is nothing without more or less unacceptable overhead that really gets us out of the woods, where this is arbitrarily defined as reducing the spoofing success rate to below 1% after a year of non-stop trying at 50 megabit/s. Detecting a spoofing attempt in progress ---------------------------------------- Since any spoofed response has a chance of around 2^-32 of being accepted, it stands to reason around 2^31 bogus responses will arrive at the resolver before the attacker manages to achieve his goals. Since we know we have effective countermeasures available, like A and B mentioned above, we could deploy these in case a spoofing attempt is detected. Remember that A and B are generally available, but that we don't want to resort to them all the time, for all domains, because of their overhead. Occasionally, port numbers get modified in transit. Additionally, responses to queries sometimes arrive late enough that a new equivalent query has since been sent. This means we should not consider a single response mismatch to be a sign of a spoofing attempt in progress. If we allow X mismatches before falling back on A or B, the chance of a single query being spoofed is: X --------- ~= 2^-32 * X N * P * I Assuming each individual attack lasts W seconds (being latency between the authentic authoritative server and the resolver), the combined spoofing chance after T seconds becomes: T/W 1 - (1 - 2^-32 * X) ~= 2^-32 * X * T/W Putting in 20 for X and 0.1s for W, this gets us a combined spoofing chance of 0.4% for a full day. Interesting, but not good enough, especially since the attacker might well send only X packets per attempt, and launch far more attempts. However, if the attacker has a defined goal about what to spoof, each successive attempt might be for a different domain name, or differ in other respects, but all those attempts will share some characteristics. Two things that will be identical, or at least reasonably unique are the source address of the spoofed packet (aka, the network address of the authentic authoritative server), plus the 'zone cut apex'. This last bit requires some understanding of the way a resolver works. (I made up this phrase, 'zone cut apex', but I think there are people with better knowledge of DNS verbiage than I, I'd love to hear of a better name) When a resolver asks NS1.EXAMPLE.COM for 'this.is.a.long.example.com', the resolver knows it is asking NS1.EXAMPLE.COM in its role as 'EXAMPLE.COM' nameserver - this is how it selected that server. This means that an attacker might try many variations on 'this.is.a.long.example.com', what will remain identical is the 'zone cut apex', which is 'EXAMPLE.COM'. What will also remain identical is the (small) set of example.com servers available. I'll get into more detail after Dan Kaminksy has held his presentation. The upshot however is that multiple different attempts can be correlated, and thus be counted together in the spoofing-detection counts. If we conservatively decide to impose a 5 minute 'fallback to A or B'-regime for a {source IP, zone cut apex}-tuple, and leave the detection limit at 20, this means an attacker will have one chance every 5 minutes of getting in an attempt. This is equivalent to setting W equal to 300 seconds above, yielding us a combined chance of spoofing a domain after a year of trying of 0.05%. Well within our goal. Reality intrudes ---------------- Sadly, the reality is that we won't recognize all spoofed packets that guessed wrong, so to speak. Typical operating systems will only let a nameserver know about packets that arrived on a socket open for that purpose. In the very worst case, the server is only listening on a single port, and by the time a single mismatch is received by the nameserver process, on average 32000 will have arrived on the network interface. This means that in the calculation above, if we don't take additional measures, we need to set X to 32000, leading to a combined *monthly* spoofing chance of 6.4% (and a yearly near-certainty). Fine tuning things ------------------ By raising the fallback period to an hour, the yearly spoofing chance becomes 6.5%, assuming we only see 1 in every 32000 spoof attempts. If in addition a small number of sockets is kept open, say 10, to function as 'canary ports', X reduces to 3200, and the yearly spoofing chance is back at a low 0.65%. Canary ports serve no function except to detect spoofing attempts. For efficiency reasons, these ports may simply be ports that had previously been used for source port randomisation, but kept around somewhat longer. The number of canary ports, and the fallback period can be tuned at will to achieve desired spoofing resilience levels. Remaining Problems ------------------ Countermeasure 'A' does not work for domains not offering TCP service. Countermeasure 'B' does not work for domains where single authoritative servers generate differing answers to repetitive questions. This might happen in case of (hardware) load balancers, or load balanced desynchronised nameservers. Best results might be achieved by alternately trying countermeasure A and B - any server that does not support TCP *and* sends out inconsistent replies is in for some tough love if someone attempts to spoof the domains it hosts. Conclusion ---------- If the calculations and ideas elaborated above hold up, it appears feasible to achieve arbitrarily low spoofing chances, without doing any further protocol work. Importantly, such changes would allow individual resolvers to protect their users without having to wait for changes to all authoritative servers. In other words, everybody who participates receives an immediate benefit. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 15:13:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7557C3A6A60; Mon, 4 Aug 2008 15:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 OSVNxfH9NGwb; Mon, 4 Aug 2008 15:13:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 953133A6978; Mon, 4 Aug 2008 15:13:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ8FL-0008do-E1 for namedroppers-data@psg.com; Mon, 04 Aug 2008 22:09:43 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ8FH-0008dP-TF for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 22:09:41 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 41A4F33C2E; Mon, 4 Aug 2008 15:09:39 -0700 (PDT) Date: Mon, 04 Aug 2008 15:09:39 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: Large EDNS0 buffer sizes and IPv6 In-Reply-To: References: <82wsiwfzdd.fsf@mid.bfk.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Mon, 04 Aug 2008 15:07:48 -0700, JINMEI Tatuya wrote: > > Apparently, this was raised by Itojun at IETF48 back in 2000, but I > > don't see how it was resolved. Implementations with buffer sizes > > greater than 1400 bytes seem to fragment according to the link MTU > > they are connected to, and do not care about the path MTU. (I haven't > > got native IPv6, so it's hard for me to tell what's going on.) > > My understanding is that the name server is expected to set the > IPV6_USE_MIN_MTU socket option (when available) for its AF_INET6 UDP > sockets. See RFC3542 for this option. BIND9 does that; unbound also > seems to do so according to a quick naive grep. In this context I should have rather focused on authoritative servers...for that matter, NSD also seems to do so according to a quick naive grep. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 15:14:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB253A6A76; Mon, 4 Aug 2008 15:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 HmAvHQG5TcXf; Mon, 4 Aug 2008 15:14:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F4D23A6960; Mon, 4 Aug 2008 15:14:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ8DY-0008T5-4h for namedroppers-data@psg.com; Mon, 04 Aug 2008 22:07:52 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ8DU-0008Sk-GW for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 22:07:50 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 3829933C2E; Mon, 4 Aug 2008 15:07:48 -0700 (PDT) Date: Mon, 04 Aug 2008 15:07:48 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: Large EDNS0 buffer sizes and IPv6 In-Reply-To: <82wsiwfzdd.fsf@mid.bfk.de> References: <82wsiwfzdd.fsf@mid.bfk.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Mon, 04 Aug 2008 19:45:18 +0200, Florian Weimer wrote: > How do you make large EDNS0 buffer sizes work with IPv6? I couldn't > find anything about that in the RFC or in the draft. > > Unlike IPv4, IPv6 doesn't fragment in the core. This means that the > source must perform path MTU discovery and fragment on its own. This, > in turn, requires client-specific state, which is generally considered > a bad thing. > > What am I missing? > > Apparently, this was raised by Itojun at IETF48 back in 2000, but I > don't see how it was resolved. Implementations with buffer sizes > greater than 1400 bytes seem to fragment according to the link MTU > they are connected to, and do not care about the path MTU. (I haven't > got native IPv6, so it's hard for me to tell what's going on.) My understanding is that the name server is expected to set the IPV6_USE_MIN_MTU socket option (when available) for its AF_INET6 UDP sockets. See RFC3542 for this option. BIND9 does that; unbound also seems to do so according to a quick naive grep. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 16:28:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7603A6A7C; Mon, 4 Aug 2008 16:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] 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 fjs5OeTFLZdw; Mon, 4 Aug 2008 16:28:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F1053A6A78; Mon, 4 Aug 2008 16:28:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ9Ly-000GPi-Hw for namedroppers-data@psg.com; Mon, 04 Aug 2008 23:20:38 +0000 Received: from [2001:748:301::2] (helo=shinjuku.zaphods.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ9Lu-000GPG-Q8 for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 23:20:36 +0000 Received: from gatekeeper.research.zaphods.net ([194.97.1.3]:49481 helo=silver-surfer.vlan23.zaphods.net) by shinjuku.zaphods.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1KQ9Ls-0003wP-TO for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 01:20:33 +0200 Message-Id: <488BBCED-95FB-4A7D-83A4-7145BB68D386@zaphods.net> From: Stefan Schmidt To: namedroppers@ops.ietf.org In-Reply-To: <34451.1217868477@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver Date: Tue, 5 Aug 2008 01:20:29 +0200 References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <20080804155217.GL18233@zaphods.net> <34451.1217868477@nsa.vix.com> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 04.08.2008, at 18:47, Paul Vixie wrote: > let's be clear about this. neither dnscache nor powerdns was > creating as many > simultaneous upstream flows in those years as the kaminsky defense > requires, Thanks to another reader of this list the penny dropped. ;) By 'kaminsky defense' you probably referred to the 'repeat the query n- times' or 'fallback to tcp' methods that were under discussion mostly on dns-operations@ and i thought you were referring to the mere port randomization. What Bert Hubert's math is saying is that it requires a tremendous amount of time and packets to successfully spoof a recursive nameserver that uses good randomness on both query id and source port selection. I won't say we're safe now, but i think he has proven that - if done right - it buys us enough time so that we do not need to rush into approving the next best thing. As to catch up with another subthread: The 'Kaminsky Exploit/Bug/ Problem' is in the press and Dan is getting most of the credit for it, thats done, no way around it. I think calling it the Kaminsky whatever for now just simplifies referencing and makes it easier for people to follow the discussion. Lets just make sure we don't create a 'Kaminsky- RFC'. Stefan -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 4 16:28:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BBD13A635F; Mon, 4 Aug 2008 16:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=1.717, BAYES_00=-2.599] 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 Hq1mPLA0sn8y; Mon, 4 Aug 2008 16:28:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 039DA3A6850; Mon, 4 Aug 2008 16:28:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ9Pw-000Gqa-8J for namedroppers-data@psg.com; Mon, 04 Aug 2008 23:24:44 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQ9Ps-000Gq1-HQ for namedroppers@ops.ietf.org; Mon, 04 Aug 2008 23:24:42 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A9721A6480 for ; Mon, 4 Aug 2008 23:24:22 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org reply-to: dns-operations@lists.oarci.net In-Reply-To: Your message of "Mon, 04 Aug 2008 22:56:36 +0200." <2834EAE2-6B09-43E7-A012-7B92FA4E7FCD@zaphods.net> References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <20080804155217.GL18233@zaphods.net> <34451.1217868477@nsa.vix.com> <2834EAE2-6B09-43E7-A012-7B92FA4E7FCD@zaphods.net> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 04 Aug 2008 23:24:22 +0000 Message-ID: <79415.1217892262@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A9721A6480.444D7 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: correction! Re: The math of RFC3822.2.2-spoofing a randomising source port resolver Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > There you lost me, i am totally unclear what you mean by upstream flows. ok, never mind. > > and the market size for these tools was in those years so small that ... > > True if you're counting market size in deployments and not users served. i was not distinguishing. we could argue about that distinction in today's world but i was referring to "in those years" which was yesterday's world and there is no argument to be made about that distinction historically. > > smaller and less popular implementations need have no fear of damaging > > their reputations by being seen "legislating from the bench". in > > BIND's case we are not able to adopt simplistic attitudes like > > "requires a shock" lest our user community storm our front yard with > > torches and pitchforks in hand. > > > > that's why the nuanced view of this is as a "real and correct cost- > > benefit tradeoff". now that kaminsky changed the costs and benefits, > > ISC has adapted. > > So smaller is easier and closer to the community. > Sounds like better to me. *scnr* smaller may be easier, but open source is either close to the community or it's dead, so smaller isn't any closer to the community. ISC chooses to serve the largest possible community, and so we avoid ramming things down the community's throat -- no "shocks" come through us. amusingly, some of the later-coming f/l/oss dns implementors have claimed that ISC was failing to serve the community because we didn't shock enough, and others said we were failing to serve the community because we shocked too often, and some have even said that we got it wrong both ways. followups to dnsops, please -- this thread isn't about the protocol any more. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 00:40:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A205D3A69F5; Tue, 5 Aug 2008 00:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 nzRRaK+3u3KP; Tue, 5 Aug 2008 00:40:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 628773A676A; Tue, 5 Aug 2008 00:40:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQH2E-0004bh-JG for namedroppers-data@psg.com; Tue, 05 Aug 2008 07:32:46 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQH2A-0004ap-40 for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 07:32:44 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m757WXDU056110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2008 09:32:37 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <48980211.3080203@nlnetlabs.nl> Date: Tue, 05 Aug 2008 09:32:33 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org Subject: Re: calculating the chance of spoofing an agile source port randomised resolver References: <20080804210313.GA10867@outpost.ds9a.nl> In-Reply-To: <20080804210313.GA10867@outpost.ds9a.nl> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 05 Aug 2008 09:32:37 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bert, You seem to be hard at work continuing the forgery resilience calculations for this new vulnerability. I would suggest this is not something for the forgery-resilience draft that is in WGLC right now? The calculations are interesting, but I would prefer to discuss after the full disclosure. This means that informed opinions can be given instead of vague guesses. I think your baseline is wrong. You quote 24 hours for one unpatched chance? But in the dnsext working group we saw 95 msec easily achieved? There must be something wrong here. This would bring the one year final result here down to 0.095 / (24*3600) of a year time (about 30 seconds). | Since that posting, quite a number of people have studied the calculations, | and they appear to hold up. Where was that? | Note that the present post does not address the dangers created by those | able to actively intercept and modify traffic - people with such abilities | have little need to spoof DNS anyhow. Well they do, but not criminally so. (it may be an unethical action) | Agile countermeasures | The problems with these two techniques is that they imply a certain overhead | and increase the general CPU utilization on the Internet. Yes, we lack good countermeasures. Except for DNSSEC. DNSSEC is a very good countermeasure. Good protocol work. Serious data protection. The protocol and software implementations have just been completed end of last year (when DNSEXT went to sleep). But it seems that it needs some time before everyone can deploy this. I read your post as looking for interim solutions, to buy the internet time to deploy DNSSEC. | Detecting a spoofing attempt in progress | the attacker might well send only X packets per attempt, and launch far more | attempts. See Masataka Ohta's post. Detection may not work well at all, and as you argue can easily be circumvented. | (I made up this phrase, 'zone cut apex', but I think there are people with | better knowledge of DNS verbiage than I, I'd love to hear of a better name) | I'll get into more detail after Dan Kaminksy has held his presentation. The | upshot however is that multiple different attempts can be correlated, and | thus be counted together in the spoofing-detection counts. Zone cut apex idea. Well I think I understand what you mean with zone cut apex, at least :-) | Conclusion | ---------- | If the calculations and ideas elaborated above hold up, it appears feasible | to achieve arbitrarily low spoofing chances, without doing any further | protocol work. Unfortunately, I do not think the above holds up. | Importantly, such changes would allow individual resolvers to protect their | users without having to wait for changes to all authoritative servers. | | In other words, everybody who participates receives an immediate benefit. This is certainly a good property for solutions (i.e. like 0x20 has). Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiYAhEACgkQkDLqNwOhpPgg6ACgjhoKQgW/M/NO7KZRptiyCXmA WWwAoKHr7kx8aRX0zWnzchjPXMjUnCPk =yi9c -----END PGP SIGNATURE----- -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 01:22:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3198028C19B; Tue, 5 Aug 2008 01:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[AWL=1.405, BAYES_00=-2.599, 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 zr65rJCckbvS; Tue, 5 Aug 2008 01:22:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08D863A6B9E; Tue, 5 Aug 2008 01:22:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQHjV-0008nN-7O for namedroppers-data@psg.com; Tue, 05 Aug 2008 08:17:29 +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 ) id 1KQHjQ-0008ma-8G for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 08:17:27 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KQHjK-0005ek-HY for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 10:17:18 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 5524C4B451; Tue, 5 Aug 2008 10:17:28 +0200 (CEST) Date: Tue, 5 Aug 2008 10:17:28 +0200 From: bert hubert To: Wouter Wijngaards Cc: namedroppers@ops.ietf.org Subject: Re: calculating the chance of spoofing an agile source port randomised resolver Message-ID: <20080805081728.GA17268@outpost.ds9a.nl> References: <20080804210313.GA10867@outpost.ds9a.nl> <48980211.3080203@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48980211.3080203@nlnetlabs.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Aug 05, 2008 at 09:32:33AM +0200, Wouter Wijngaards wrote: > You seem to be hard at work continuing the forgery resilience > calculations for this new vulnerability. I would suggest this is not > something for the forgery-resilience draft that is in WGLC right now? This is most definitely not for the draft, which I consider wrapped up and finished. > I think your baseline is wrong. You quote 24 hours for one unpatched > chance? But in the dnsext working group we saw 95 msec easily achieved? I quote 4-8 seconds for very high chances of success, which is very much in line with what was demonstrated at the working group: Interestingly, setting P=1 predicts very perfect chances of spoofing within 4-8 seconds - about in line with what the exploits out there achieve on non-source port randomised servers. >From the working group demo, I recall the attack succeeding most of the time, and taking a number of seconds on average. > | Since that posting, quite a number of people have studied the calculations, > | and they appear to hold up. > > Where was that? On namedroppers and dns-operations. Alex Bligh and Florian Weimer commented specifically on the lists, Evgeniy Polyakov and Jasper Spaans also verified the calculations, off-list. > went to sleep). But it seems that it needs some time before everyone > can deploy this. I read your post as looking for interim solutions, to > buy the internet time to deploy DNSSEC. Well - I personally would not bet on DNSSEC ever being deployed fully. But that is irrelevant to the discussion - my post is indeed about what can and perhaps needs to be done today, by any resolver on the internet. > | Detecting a spoofing attempt in progress > | the attacker might well send only X packets per attempt, and launch > far more > | attempts. > > See Masataka Ohta's post. Detection may not work well at all, and as > you argue can easily be circumvented. Hmm - I may be wrong, but I've given it a lot of thought and I don't see how the detection can easily be circumvented. Any individual spoofing attack is overwhelmingly likely to fail, and can hence be detected safely. But it would be very good to see if we as a working group could punch practical holes in this. Our track record is not perfect, we did not see everything coming, but the brightest minds of DNS do hang out here. Regarding what Masataka Ohta says, I don't fully understand what he means, but I think what he says does not mean spoofing detection can be evaded easily. 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 01:33:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B3A28C2A0; Tue, 5 Aug 2008 01:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.050, 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 8NVPnGVanK3h; Tue, 5 Aug 2008 01:33:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9188128C29E; Tue, 5 Aug 2008 01:33:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQHrm-0009QG-2C for namedroppers-data@psg.com; Tue, 05 Aug 2008 08:26:02 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQHrh-0009PW-Lf for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 08:25:59 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 2D022C2DA3; Tue, 5 Aug 2008 09:25:53 +0100 (BST) Date: Tue, 05 Aug 2008 09:25:49 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Wouter Wijngaards , bert hubert cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: calculating the chance of spoofing an agile source port randomised resolver Message-ID: <78AA6651EC48A8F0B236D719@Ximines.local> In-Reply-To: <48980211.3080203@nlnetlabs.nl> References: <20080804210313.GA10867@outpost.ds9a.nl> <48980211.3080203@nlnetlabs.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 5 August 2008 09:32:33 +0200 Wouter Wijngaards wrote: >| Since that posting, quite a number of people have studied the > calculations, >| and they appear to hold up. > > Where was that? I verified Bert's formulae down to the point I snipped in my email. I did not verify the numbers he plugged in (I couldn't quite see where he was going) but I did calculate using his formulae the packet rate required where an attack on an unpatched server was more likely than not to yield in less than 100ms (the "John Dickinson number"). This was 82,000 pps (manageable, just, but then John said he demonstrated it yielded once in less than 100ms - to have a 1 in 20 chance of succeeding you'd only need 8,200 pps). The read I took from Bert's calculations (which I think is different from the read Bert took) was: * Brute forcing the calculations shows that there is still a risk with port randomisation * The situation is even worse if NAT is involved * There are several possible bits of cleverness one could add that would make attacks (a) more effective and (b) less detectable. I left a large hint as to one of these but don't really want to spell it out on a public mailing list. These leads me to believe that port randomisation is insufficient as a solution. I believe the extra tweaks (canary ports etc.) are just as likely to lead to DoS vectors as improved security. I realise this may not be quite where Bert was driving, but I do agree with the formula part of his maths. >| The problems with these two techniques is that they imply a certain > overhead >| and increase the general CPU utilization on the Internet. > > Yes, we lack good countermeasures. I think the CPU concern is misplaced. We do not need to do full encryption / decryption (which will be CPU intensive) to avoid spoofing. The worst case CPU required is a hash on a packet, which is really no more CPU than already needed to process a DNSSEC query/answer. This could either be done by DNSSEC itself, by a mechanism like signing (e.g. a hash of the answer with a preshared key), or by a mechanism like IPsec AH transport integrity protection which is no worse (i.e. hashing the transport layer too). There are several possibilities involving existing protocols and potential new protocols but none seems to have particularly serious CPU utilisation ramifications. Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 01:46:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EE53A6BE6; Tue, 5 Aug 2008 01:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.773 X-Spam-Level: X-Spam-Status: No, score=0.773 tagged_above=-999 required=5 tests=[AWL=1.277, BAYES_00=-2.599, 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 5246b0zfiD40; Tue, 5 Aug 2008 01:46:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4EEC93A69B9; Tue, 5 Aug 2008 01:46:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQI48-000AZh-28 for namedroppers-data@psg.com; Tue, 05 Aug 2008 08:38:48 +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 ) id 1KQI43-000AYs-5i for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 08:38:46 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KQI40-0005xO-D7 for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 10:38:40 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 932B34B44F; Tue, 5 Aug 2008 10:38:54 +0200 (CEST) Date: Tue, 5 Aug 2008 10:38:54 +0200 From: bert hubert To: Alex Bligh Cc: Wouter Wijngaards , namedroppers@ops.ietf.org Subject: Re: calculating the chance of spoofing an agile source port randomised resolver Message-ID: <20080805083854.GA19871@outpost.ds9a.nl> References: <20080804210313.GA10867@outpost.ds9a.nl> <48980211.3080203@nlnetlabs.nl> <78AA6651EC48A8F0B236D719@Ximines.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78AA6651EC48A8F0B236D719@Ximines.local> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Aug 05, 2008 at 09:25:49AM +0100, Alex Bligh wrote: > The read I took from Bert's calculations (which I think is different > from the read Bert took) was: > * Brute forcing the calculations shows that there is still a risk with > port randomisation > * The situation is even worse if NAT is involved We agree fully on the above. I do think that we've raised the bar beyond the obvious. I know several people trying to spoof a SPR-nameserver in their own networks and nobody has succeeded so far, mostly for practical reasons. See http://tservice.net.ru/~s0mbre/blog/devel/networking/dns/index.html for an attempt in progress involving 250-300kpps. > (...) > These leads me to believe that port randomisation is insufficient as > a solution. I believe the extra tweaks (canary ports etc.) are just > as likely to lead to DoS vectors as improved security. Your belief may well be correct - but I also believe that if we really apply our minds to it, it may be possible to discover and implement simple countermeasures that make spoofing a fully source port randomised nameserver so hard that it becomes harder than other attacks which would lead to the same result. For one thing, the canary ports don't work behind a stateful firewall without further smartness being applied. So more thinking is definitely needed. > >| The problems with these two techniques is that they imply a certain overhead > >| and increase the general CPU utilization on the Internet. > > > >Yes, we lack good countermeasures. > > I think the CPU concern is misplaced. We do not need to do full encryption / > decryption (which will be CPU intensive) to avoid spoofing. The worst The CPU concern is regarding the mere use of TCP or repeating queries. The bar is set that low. I'm not sure if I agree with this sentiment btw - there is not a lot that can be implemented without increasing packet size or count. 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 01:55:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239703A68B3; Tue, 5 Aug 2008 01:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, 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 apkw+5irgfTR; Tue, 5 Aug 2008 01:55:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5084F3A6407; Tue, 5 Aug 2008 01:55:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQIEb-000BaS-UI for namedroppers-data@psg.com; Tue, 05 Aug 2008 08:49:37 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQIEX-000BZk-2f for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 08:49:35 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KQIEM-0004J8-6p; Tue, 05 Aug 2008 10:49:22 +0200 Received: from fweimer by bfk.de with local id 1KQIET-0005j5-6G; Tue, 05 Aug 2008 10:49:29 +0200 To: JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJ?= Cc: namedroppers@ops.ietf.org Subject: Re: Large EDNS0 buffer sizes and IPv6 References: <82wsiwfzdd.fsf@mid.bfk.de> From: Florian Weimer Date: Tue, 05 Aug 2008 10:49:29 +0200 In-Reply-To: (JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJJ3M=?= message of "Mon, 04 Aug 2008 15:07:48 -0700") Message-ID: <827iavetie.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89: > My understanding is that the name server is expected to set the > IPV6_USE_MIN_MTU socket option (when available) for its AF_INET6 UDP > sockets. See RFC3542 for this option. BIND9 does that; unbound also > seems to do so according to a quick naive grep. Ah, thanks. This socket option was introduced in Linux 2.6.14 (released in October 2005), so it's probably not universally available. (I'm not saying that the Linux kernel is the univeral measure, but if it's not there, several other vendors probably lack it, too.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=C3=9Fe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 03:25:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9938F3A68F6; Tue, 5 Aug 2008 03:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=0.045, 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 YsBD+G1w9pSF; Tue, 5 Aug 2008 03:25:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C04083A67FD; Tue, 5 Aug 2008 03:25:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQJdl-000Iz9-IM for namedroppers-data@psg.com; Tue, 05 Aug 2008 10:19:41 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQJda-000IwF-1T for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 10:19:31 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 6768BC2DA3; Tue, 5 Aug 2008 11:19:02 +0100 (BST) Date: Tue, 05 Aug 2008 11:18:59 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert cc: Wouter Wijngaards , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: calculating the chance of spoofing an agile source port randomised resolver Message-ID: In-Reply-To: <20080805083854.GA19871@outpost.ds9a.nl> References: <20080804210313.GA10867@outpost.ds9a.nl> <48980211.3080203@nlnetlabs.nl> <78AA6651EC48A8F0B236D719@Ximines.local> <20080805083854.GA19871@outpost.ds9a.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 5 August 2008 10:38:54 +0200 bert hubert wrote: > Your belief may well be correct - but I also believe that if we really > apply our minds to it, it may be possible to discover and implement simple > countermeasures that make spoofing a fully source port randomised > nameserver so hard that it becomes harder than other attacks which would > lead to the same result. Sure. Personally I think solutions based on limiting the trust given to the spoofed records supplied (as I think Masataka Ohta suggested) is the most fruitful route here (which would kill the attack dead) but I recognise I don't have sufficient protocol guru qualifications to help much beyond pointing out it might well require caching more than one instance of (purportedly) the same glue record, i.e. the query which resulted in the cache entry is going to end up forming part of the key in the cache lookup, which is a bit of change. Alex -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 06:36:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DAB3A69BF; Tue, 5 Aug 2008 06:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 xG5QmAyje1CQ; Tue, 5 Aug 2008 06:36:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6E953A6848; Tue, 5 Aug 2008 06:36:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQMYe-000AFr-Mg for namedroppers-data@psg.com; Tue, 05 Aug 2008 13:26:36 +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 ) id 1KQMYY-000AF0-TB for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 13:26:33 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m75DQReV041482 for ; Tue, 5 Aug 2008 09:26:28 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808051326.m75DQReV041482@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Aug 2008 09:17:56 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: IETF-72 DNSEXT draft minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Please comment if you see any mistakes, thanks Olafur IETF 72, Dublin, Ireland DNSEXT WG Minutes (draft) by Lars-Johan Liman edited by Olafur Gudmundsson Chairs: Olafur Gudmundsson (OG), Andrew Sullivan (AS) On request from the chairs, there are rough time stamps in the left margin for when actions happened, for reference to jabber and audio recording. Note that the jabber log is in (+0000). Full Jabber log: http://jabber.ietf.org/logs/dnsext/2008-07-31.txt [AC ...] indicates an action on someone. AGENDA Agenda for the meeting of the DNS Extensions Working Group IETF 72 Dublin, IE 2008-07-31 1300 h (+0100) Ballroom 1 1. Minute and Jabber scribes (2 min) 2. Note Well (2 min) 3. WG status 3.1 Drafts published (1 min) 3.2 IESG processing: a. draft-ietf-dnsext-2929bis (2 min) 3.3 Documents in/past WGLC a. draft-ietf-dnsext-forgery-resilience 3.4 Current WG Documents a. draft-ietf-dnsext-dnssec-rsasha256 (8 min) b. draft-ietf-dnsext-rfc2672bis-dname (8 min) c. draft-ietf-dnsext-dnssec-bis-updates (10 min) - discuss clarification on TA handling d. draft-ietf-dnsext-rfc2671bis-edns0 (1 min) e. draft-ietf-dnsext-tsig-md5-deprecated (8 min) - discuss proposal for alternate text f. draft-ietf-dnsext-axfr-clarify (8 min) 3.5 Expired WG Documents a. draft-ietf-dnsext-dns-protocol-profile (5 min) 4. Proposed WG work 4.1 draft-crocker-dnssec-algo-signal (5 min) 4.2 draft-vixie-dnsext-dns0x20 (see below) 4.3 Clarification to RFC 1123 (5 min) 4.4 dynamic zones and DNSSEC (M. Andrews) (5 min) 4.5 Warning: stuff coming because of NAT-PT 5. Discussion: further forgery resilience work (30 min) 5.1 draft-ietf-dnsext-forgery-resilience 5.2 draft-vixie-dnsext-dns0x20 5.3 other suggestions 6. A.O.B 7. Close MINUTES 1. Minute and Jabber scribes Lars-Johan Liman was appointed as minute scribe, and Matthijs Mekking as the jabber scribe. 2. Note Well The participants were made aware of the IETF "NOTE WELL" statement. 3. WG status 3.1 Drafts published There were no new drafts published since the last meeting. 3.2 IESG processing: a. draft-ietf-dnsext-2929bis OG reported that this document now has cleared the IESG "discuss" status. 3.3 Documents in/past WGLC a. draft-ietf-dnsext-forgery-resilience OG reported that it has passed last call (LC) and that a new version went up this morning. The WG members were advised to make sure their LC issues were addressed. 3.4 Current WG Documents a. draft-ietf-dnsext-dnssec-rsasha256 http://www.ietf.org/proceedings/08jul/slides/dnsext-0.pdf Wouter Wijngards (WW) presented (see slides). There were no comments. It was noted that version -05 of the document is out, and the WG was asked to use that for LC comments. 13:08 [AC 72.1] Andrew Sullivan to send out LC a week from today. b. draft-ietf-dnsext-rfc2672bis-dname http://www.ietf.org/proceedings/08jul/slides/dnsext-1.pdf WW presented (see slides). 13:13 [AC 72.2] The chairs to send this document to LC "real soon now". Comments on the mailing list between now and the LC will be treated as "LC comments". c. draft-ietf-dnsext-dnssec-bis-updates - discuss clarification on TA handling OG: Want to come to conclusion in sept. If the editor is comfortable, then the document will be sent to LC, but at least consensus on the list. [AC 72.3] Andrew Sullivan to create a discussion thread for this on the list. d. draft-ietf-dnsext-rfc2671bis-edns0 The editor claims that this document is done. 13:19 [AC 72.4] Olafur Gudmundsson to send the document to LC when the previous document LC ends. e. draft-ietf-dnsext-tsig-md5-deprecated - discuss proposal for alternate text Francis Dupont (FD) requested that the text should say "no longer required" rathern than "deprecated". Peter Koch (PK) noted that there is no good place to record requirement levels. That fact needs to be sorted out. Therefore the document is not ready for LC, even if the document as such is OK. We need to modify registry to contain that type of information. 13:25 [AC 72.5] Peter Koch to send text regarding requirement levels in the registry. f. draft-ietf-dnsext-axfr-clarify http://www.ietf.org/proceedings/08jul/slides/dnsext-5.pdf Ed Lewis (EL) presented and went through history. It has been stuck in "AD has issues" for a long time. Ed is trawling through the archives to find and resolve all issues. Dan Bernstein has raised issues in the past, Andreas Gustafsson (previous editor) has addressed most of them. EL has also checked with 4 implementors that the document doesn't create problems for them. The discussion veered into whether the master server or the slave server has the "right" to remove incorrect zone data from the zone. It was specifically noted that the document needs a section on the differences between loading a zone into a master, and transferring a zone in a zone transfer. [AC 72.6] Ed Lewis to write a scratch proposal on text to address this issue, and send it to the list for discussion. 13:40 PK: There are similar issue with root priming. There is possibly a difference btw. what's transferred in a zone transfer, and what is actually is served out in responses to queries. 13:44 [AC 72.7] The issue was referred to discussion on the mailing list. It was established that transfer of single RR messages is OK, and that it does not conflict with the statement in earlier RFCs that only "complete RR sets" shall be served in responses. 3.5 Expired WG Documents a. draft-ietf-dnsext-dns-protocol-profile Nothing has happened with this document. The chairs have discussed with the editors and arrived at the following: If this document has not started to move at the end of September, the chairs will kill the document. 13:52 4. Proposed WG work 4.1 draft-crocker-dnssec-algo-signal Scott Rose presented. Asked the audience to please read, comment. Note that the document has two goals: a) to reduce the response size between a resolver and an authoritative server; and b) to signal when new algorithms are deployed. [AC 72.8] Scott Rose to send request to mailing list and ask the WG to adopt the document. 4.2 draft-vixie-dnsext-dns0x20 Discussion was deferred to agenda point 5. 4.3 Clarification to RFC 1123 http://www.ietf.org/proceedings/08jul/slides/dnsext-3.pdf TLD labels are always alphabetic per RFC 1123. That needs to be updated. One reason is the use of internationalized domain names in top level domains. Matt Larson & Lars-Johan Liman have volunteered to draft text. Warnings were conveyed that there are issues both in the protocol specification and in registration procedures (which really belong with the IANA). It was also noted that old implementation may have problems accommodating TLDs that don't follow the old spec. Alfred Hoenes noted that there is also a problem with formal specifications of DNS labels, which often differ from document to document. AS noted that the update cannot be an errata, since the issue came up due to an errata! :-) 14:02 [AC 72.9] Matt Larson and Lars-Johan Liman to draft and post new document. 4.4 Dynamic zones and DNSSEC (M. Andrews) Presentation by Mark Andrews (MA). MA is looking for group of people to work on this, and investigate the problems. EL noted that he had written something up once and was willing to contribute it to the discussion. 14:12 WG members were encouraged to contact MA off list if they are interested in working with this. 4.5 Warning: stuff coming because of NAT-PT OG gave a "heads-up" and asked the WG members to watch other WGs, and to speak up early if problems are found, since it is much easier to fix problems that are discovered at an early stage. 5. Discussion: further forgery resilience work http://www.ietf.org/proceedings/08jul/slides/dnsext-6.ppt OG made some initial remarks regarding resilience, and urged the audience to deploy draft-ietf-dnsext-forgery-resilience without delay, even though it has just passed WGLC. 5.1 draft-ietf-dnsext-forgery-resilience 5.2 draft-vixie-dnsext-dns0x20 5.3 other suggestions http://www.ietf.org/proceedings/08jul/slides/dnsext-2.pdf WW acted as a proxy for the author and presented the dns0x20 draft. It is noted that most server implementations echo the query string back to the client verbatim, so this can be implemented "immediately". [Here the minute taker queued at the microphone for a while, and notes were graciously taken by Rob Austein for the duration.] It was noted by the audience that the length of the query name makes a difference, but that the client always poses the "full" query to a server, and that the referral may be shorter, but that is irrelevant. [Minute taker back.] It was noted that we only have seen very few proposals in documents, and that the decision on whether we want to adopt documents or not should be deferred until we have seen more proposals. 14:55 OG urged people with good ideas to send them in as drafts, and requested that they be sent is as personal submissions, but tagged with "dnsext" to identify them as possible future WG work items. [AC 72.9] Chairs will not propose the adoption of any particular work or collection of work until after the details of the attack is officially known and the WG has had time to form an opinion what is appropriate response. 6. A.O.B 14:56 John Dickinson made a short demonstration of a proof of concept program that infected a cache, which, in a very limited environment, succeeded in a matter of seconds. 7. Close The meeting was adjourned. 15:01 [END] -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 07:52:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0E828C26D; Tue, 5 Aug 2008 07:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, 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 N7Qv5m0hH4u8; Tue, 5 Aug 2008 07:52:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A902D28C24C; Tue, 5 Aug 2008 07:52:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQNlJ-000Hex-NM for namedroppers-data@psg.com; Tue, 05 Aug 2008 14:43:45 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQNlE-000Hdl-4X for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 14:43:43 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 11C6733C1E; Tue, 5 Aug 2008 15:43:38 +0100 (BST) Message-ID: <48986721.6010103@links.org> Date: Tue, 05 Aug 2008 15:43:45 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= CC: namedroppers@ops.ietf.org Subject: Re: IETF-72 DNSEXT draft minutes References: <200808051326.m75DQReV041482@stora.ogud.com> In-Reply-To: <200808051326.m75DQReV041482@stora.ogud.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ólafur Guðmundsson /DNSEXT chair wrote: > 4.5 Warning: stuff coming because of NAT-PT > > OG gave a "heads-up" and asked the WG members to watch other > WGs, and to speak up early if problems are found, since it is > much easier to fix problems that are discovered at an early > stage. Could you expand on this slightly for those of us that weren't there? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 09:09:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F6D28C2BD; Tue, 5 Aug 2008 09:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 NRUBjlAkwPDK; Tue, 5 Aug 2008 09:09:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EAF4F28C2C7; Tue, 5 Aug 2008 09:09:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQOys-000PYb-Tc for namedroppers-data@psg.com; Tue, 05 Aug 2008 16:01:50 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQOyk-000PXK-Us for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 16:01:48 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m75G4Ksa010494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Aug 2008 09:04:23 -0700 Date: Tue, 5 Aug 2008 12:01:38 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: IETF-72 DNSEXT draft minutes Message-ID: <20080805160137.GC1403@commandprompt.com> References: <200808051326.m75DQReV041482@stora.ogud.com> <48986721.6010103@links.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48986721.6010103@links.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Tue, 05 Aug 2008 09:04:24 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Aug 05, 2008 at 03:43:45PM +0100, Ben Laurie wrote: >> 4.5 Warning: stuff coming because of NAT-PT >> >> OG gave a "heads-up" and asked the WG members to watch other >> WGs, and to speak up early if problems are found, since it is >> much easier to fix problems that are discovered at an early >> stage. > > Could you expand on this slightly for those of us that weren't there? Unfortunately, no. We know that there is work likely to need review as a result of NAT-PT or other, similar work being done to aid IPv6 deployment. What we don't know exactly is what the drafts will look like, where exactly the "home" group of these things will be, &c. Partly, that's because I have not (and I don't believe Olafur has) had time to review every document in this space. But our AD has drawn our attention to some of that work, so it seemed wise to warn everyone in the working group that something was going to show up. Best, A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 5 11:33:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1136E28C325; Tue, 5 Aug 2008 11:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.35 X-Spam-Level: X-Spam-Status: No, score=-99.35 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Wyqyn3kzeBCh; Tue, 5 Aug 2008 11:33:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16AC928C31E; Tue, 5 Aug 2008 11:33:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQRFF-000F8D-Ob for namedroppers-data@psg.com; Tue, 05 Aug 2008 18:26:53 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQRFB-000F7j-Gs for namedroppers@ops.ietf.org; Tue, 05 Aug 2008 18:26:51 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 398B033C2E; Tue, 5 Aug 2008 11:26:49 -0700 (PDT) Date: Tue, 05 Aug 2008 11:26:49 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: Large EDNS0 buffer sizes and IPv6 In-Reply-To: <827iavetie.fsf@mid.bfk.de> References: <82wsiwfzdd.fsf@mid.bfk.de> <827iavetie.fsf@mid.bfk.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Tue, 05 Aug 2008 10:49:29 +0200, Florian Weimer wrote: > > My understanding is that the name server is expected to set the > > IPV6_USE_MIN_MTU socket option (when available) for its AF_INET6 UDP > > sockets. See RFC3542 for this option. BIND9 does that; unbound also > > seems to do so according to a quick naive grep. > > Ah, thanks. This socket option was introduced in Linux 2.6.14 > (released in October 2005), so it's probably not universally > available. (I'm not saying that the Linux kernel is the univeral > measure, but if it's not there, several other vendors probably lack > it, too.) I have no doubt that some vendors lack it (e.g., Microsoft doesn't implement it as far as I know), but referring to Linux in this context could actually be misleading; the Linux IPv6 protocol stack (including socket API extensions) had been a cretaceous relic largely behind many other OSes, until the USAGI project incorporated their effort to the mainline kernel. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 00:43:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21383A67E6; Wed, 6 Aug 2008 00:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 9rIDBNZ27ec2; Wed, 6 Aug 2008 00:43:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F05D3A68A1; Wed, 6 Aug 2008 00:43:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQdYf-0007Vd-VT for namedroppers-data@psg.com; Wed, 06 Aug 2008 07:35:45 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQdYc-0007V6-8h for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 07:35:44 +0000 Received: (qmail 10578 invoked from network); 6 Aug 2008 08:23:36 -0000 Received: from pppoe244.33.east.tokyo.dcn.ne.jp (HELO necom830.hpcl.titech.ac.jp) (219.105.33.244) by necom830.hpcl.titech.ac.jp with SMTP; 6 Aug 2008 08:23:36 -0000 Message-ID: <48995430.6040306@necom830.hpcl.titech.ac.jp> Date: Wed, 06 Aug 2008 16:35:12 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> <56305.1217978024@nsa.vix.com> In-Reply-To: <56305.1217978024@nsa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >>>i'm comfortable with that approach, although i think it's safe to use >>>it as glue for any NS RR, >> >>It is unsafe, because, 1.2.3.4 will give you forged answer for other >>queries to ns.example2.com. > when we last discussed this, i said that no nameserver should hand out > glue for zones outside its apex, and that if it does hand out such glue > then it ought not be believed. As long as glue is used as glue and no other purposes, which is necessary now, there is no point to avoid any glue information. > my position hasn't changed. has yours? You should change your posision now. BTW, the following senario seemingly require handling of additional As so that "apex" is not a meaningful concept. 1) an attacker ask a victim nameserver NS of example.com. 2) the attacker repeatedly ask a victim nameserver MX of .example.com. 3) the victim nameserver forward the question to NS of example.com 4) the attacker guess ID and gives false answers with source address of NS of example.com: .example.com MX 0 www.example.com with a additional record of www.example.com A That is, except for glue-A, an additional record should be accepted only if its name exactly matches the query name. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 00:58:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185593A6B0C; Wed, 6 Aug 2008 00:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.93 X-Spam-Level: X-Spam-Status: No, score=0.93 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, 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 iLA4BKLw0ZUb; Wed, 6 Aug 2008 00:58:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A4A43A6960; Wed, 6 Aug 2008 00:58:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQdn5-0008lS-IO for namedroppers-data@psg.com; Wed, 06 Aug 2008 07:50:39 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQdn1-0008kg-GS for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 07:50:37 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KQdmq-0005JT-A7; Wed, 06 Aug 2008 09:50:24 +0200 Received: from fweimer by bfk.de with local id 1KQdmw-0005UY-SD; Wed, 06 Aug 2008 09:50:30 +0200 To: JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJ?= Cc: namedroppers@ops.ietf.org Subject: Re: Large EDNS0 buffer sizes and IPv6 References: <82wsiwfzdd.fsf@mid.bfk.de> <827iavetie.fsf@mid.bfk.de> From: Florian Weimer Date: Wed, 06 Aug 2008 09:50:30 +0200 In-Reply-To: (JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJJ3M=?= message of "Tue, 05 Aug 2008 11:26:49 -0700") Message-ID: <82ique8tvd.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89: > I have no doubt that some vendors lack it (e.g., Microsoft doesn't > implement it as far as I know), but referring to Linux in this context > could actually be misleading; the Linux IPv6 protocol stack (including > socket API extensions) had been a cretaceous relic largely behind many > other OSes, until the USAGI project incorporated their effort to the > mainline kernel. Okay. If my stack lacks it, what should I cap the EDNS0 buffer size to? 1232 (1280 minues 40 minus 8)? 1200? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=C3=9Fe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 02:02:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E965F3A6833; Wed, 6 Aug 2008 02:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.221 X-Spam-Level: ** X-Spam-Status: No, score=2.221 tagged_above=-999 required=5 tests=[AWL=1.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 U4ibtVbu8Q+j; Wed, 6 Aug 2008 02:02:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2238B3A6B70; Wed, 6 Aug 2008 02:02:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQeo6-000EkW-QN for namedroppers-data@psg.com; Wed, 06 Aug 2008 08:55:46 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQeo3-000Ejy-6U for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 08:55:44 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KQenq-0008OU-C8; Wed, 06 Aug 2008 10:55:30 +0200 Received: from fweimer by bfk.de with local id 1KQenw-0006PC-Tc; Wed, 06 Aug 2008 10:55:36 +0200 To: Masataka Ohta Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> <56305.1217978024@nsa.vix.com> <48995430.6040306@necom830.hpcl.titech.ac.jp> From: Florian Weimer Date: Wed, 06 Aug 2008 10:55:36 +0200 In-Reply-To: <48995430.6040306@necom830.hpcl.titech.ac.jp> (Masataka Ohta's message of "Wed, 06 Aug 2008 16:35:12 +0900") Message-ID: <82r6927caf.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Masataka Ohta: > That is, except for glue-A, an additional record should be accepted only > if its name exactly matches the query name. This is correct. Additional section processing has been useless for a while. It turns out that it is very difficult to make use of data in the additional section in a dual stack environment because lack of A (or AAAA) RRs in the additional section for a MX DNAME does not mean that these records do not exist in DNS. Consequently, you need to perform an additional DNS transaction anyway in many cases. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 07:08:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654A228C38C; Wed, 6 Aug 2008 07:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 pYuEj-6arFBS; Wed, 6 Aug 2008 07:07:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B38928C375; Wed, 6 Aug 2008 07:07:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQjSc-000LdE-LN for namedroppers-data@psg.com; Wed, 06 Aug 2008 13:53:54 +0000 Received: from [131.111.8.138] (helo=ppsw-8.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQjST-000Lbw-4n for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 13:53:52 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48943) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1KQjSH-0007AN-Qk (Exim 4.70) (return-path ); Wed, 06 Aug 2008 14:53:33 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KQjSH-0006DD-8u (Exim 4.67) (return-path ); Wed, 06 Aug 2008 14:53:33 +0100 Date: Wed, 6 Aug 2008 14:53:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Masataka Ohta cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver In-Reply-To: <4898C830.9040905@necom830.hpcl.titech.ac.jp> Message-ID: References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 6 Aug 2008, Masataka Ohta wrote: > Paul Vixie wrote: > > will you propose text for the forgery-resilience draft that expresses > > your point of view? > > "Glue A from a name server is, in general, outside of the zone served > by the name server and is never authoritative. The glue can be used > only for the original query." Shouldn't this kind of thing go in a revision of RFC 2181? Tony. -- f.anthony.n.finch http://dotat.at/ FITZROY: SOUTHWEST VEERING NORTHWEST 5 TO 7. ROUGH. RAIN OR SHOWERS. MODERATE. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 07:09:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F623A68F7; Wed, 6 Aug 2008 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.675 X-Spam-Level: X-Spam-Status: No, score=-0.675 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, MIME_8BIT_HEADER=0.3, 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 syVaaDSjHSPB; Wed, 6 Aug 2008 07:09:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D31B3A68DF; Wed, 6 Aug 2008 07:09:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQjbc-000MlH-FH for namedroppers-data@psg.com; Wed, 06 Aug 2008 14:03:12 +0000 Received: from [85.17.178.135] (helo=spalding.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQjbV-000Mk3-F8 for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 14:03:10 +0000 Received: from localhost (localhost [127.0.0.1]) by spalding.dds.nl (Postfix) with ESMTP id C91C2628093; Wed, 6 Aug 2008 16:03:04 +0200 (CEST) Received: from [192.168.254.2] (unknown [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by spalding.dds.nl (Postfix) with ESMTP id B35B362808A; Wed, 6 Aug 2008 16:02:55 +0200 (CEST) Message-ID: <4899AF0D.3080403@nlnetlabs.nl> Date: Wed, 06 Aug 2008 16:02:53 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= CC: Florian Weimer , namedroppers@ops.ietf.org Subject: Re: Large EDNS0 buffer sizes and IPv6 References: <82wsiwfzdd.fsf@mid.bfk.de> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.93.1/7959/Wed Aug 6 15:06:37 2008 on spalding X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 JINMEI Tatuya / 神明é”哉 wrote: | At Mon, 04 Aug 2008 15:07:48 -0700, | JINMEI Tatuya wrote: | |>> Apparently, this was raised by Itojun at IETF48 back in 2000, but I |>> don't see how it was resolved. Implementations with buffer sizes |>> greater than 1400 bytes seem to fragment according to the link MTU |>> they are connected to, and do not care about the path MTU. (I haven't |>> got native IPv6, so it's hard for me to tell what's going on.) |> My understanding is that the name server is expected to set the |> IPV6_USE_MIN_MTU socket option (when available) for its AF_INET6 UDP |> sockets. See RFC3542 for this option. BIND9 does that; unbound also |> seems to do so according to a quick naive grep. | | In this context I should have rather focused on authoritative | servers...for that matter, NSD also seems to do so according to a | quick naive grep. Yes, NSD does this: If MIN_MTU option exists - sets that option. Else set the edns bufsize to the IPV6_MIN_MTU Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZrw0ACgkQkDLqNwOhpPjYmQCggZLzbpH7KSIkw6clsP42g37u u/IAnA93Ulwi56wvW/vkljRy9idG/uBO =oy48 -----END PGP SIGNATURE----- -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 08:48:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3918A3A6B7A; Wed, 6 Aug 2008 08:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=2.538, BAYES_00=-2.599] 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 7ArWd-ViZrfg; Wed, 6 Aug 2008 08:48:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C152C3A68BF; Wed, 6 Aug 2008 08:48:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQl8e-000DKH-27 for namedroppers-data@psg.com; Wed, 06 Aug 2008 15:41:24 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQl8a-000DJZ-C3 for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 15:41:22 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 13049A6683; Wed, 6 Aug 2008 15:41:10 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Tony Finch cc: Masataka Ohta , namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 06 Aug 2008 14:53:33 +0100." References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 06 Aug 2008 15:41:10 +0000 Message-ID: <77639.1218037270@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 13049A6683.AF82F X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > > will you propose text for the forgery-resilience draft that expresses > > > your point of view? > > > > "Glue A from a name server is, in general, outside of the zone served > > by the name server and is never authoritative. The glue can be used > > only for the original query." > > Shouldn't this kind of thing go in a revision of RFC 2181? not that text, certainly. but i do agree in general that once we can agree on what should be done, an update to RFC 2181 and 2308 should be made. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 09:19:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399B83A6812; Wed, 6 Aug 2008 09:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553] 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 946dW3pAM6Aw; Wed, 6 Aug 2008 09:19:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 524543A63EC; Wed, 6 Aug 2008 09:19:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQleJ-000HVU-2z for namedroppers-data@psg.com; Wed, 06 Aug 2008 16:14:07 +0000 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQleE-000HUk-KY for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 16:14:04 +0000 Received: from [217.33.138.50] (account jim HELO [172.16.1.72]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 340716 for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 17:14:01 +0100 Message-Id: <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> From: Jim Reid To: Namedroppers Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Fwd: New Version Notification for draft-reid-dnsext-aleatoric-00 Date: Wed, 6 Aug 2008 17:13:00 +0100 References: <20080806144600.1F2E93A6AE8@core3.amsl.com> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This idea is probably even uglier than the 0x20 draft. :-) Begin forwarded message: > From: IETF I-D Submission Tool > Date: August 6, 2008 15:46:00 BST > To: jim@rfc1035.org > Subject: New Version Notification for draft-reid-dnsext-aleatoric-00 > > > A new version of I-D, draft-reid-dnsext-aleatoric-00.txt has been > successfuly submitted by Jim Reid and posted to the IETF repository. > > Filename: draft-reid-dnsext-aleatoric > Revision: 00 > Title: A DNS Resource Record for Additional Entropy > Creation_date: 2008-08-06 > WG ID: Independent Submission > Number_of_pages: 14 > > Abstract: > A scheme to defend against cache poisoning attacks against the Domain > Name System (DNS) by predicting the ID and source port number of > outgoing queries is described in this draft. It proposes a new > resource record to provide a mechanism to introduce additional > entropy into DNS queries. > > > > The IETF Secretariat. > > -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 09:20:33 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C5B3A689B; Wed, 6 Aug 2008 09:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.431 X-Spam-Level: X-Spam-Status: No, score=0.431 tagged_above=-999 required=5 tests=[AWL=3.030, BAYES_00=-2.599] 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 h6AzX1c3H7DQ; Wed, 6 Aug 2008 09:20:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06BB23A67FE; Wed, 6 Aug 2008 09:20:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQle3-000HTb-KH for namedroppers-data@psg.com; Wed, 06 Aug 2008 16:13:51 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQldz-000HT1-P6 for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 16:13:49 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 93B21A66AE; Wed, 6 Aug 2008 16:13:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Masataka Ohta cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 06 Aug 2008 16:35:12 +0900." <48995430.6040306@necom830.hpcl.titech.ac.jp> References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> <56305.1217978024@nsa.vix.com> <48995430.6040306@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 06 Aug 2008 16:13:26 +0000 Message-ID: <81362.1218039206@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 93B21A66AE.41C7E X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > my position hasn't changed. has yours? > > You should change your posision now. that's what you said ten years ago, too. let me caution you now, as then, against any attempt at "proof by vigorous reassertion." i've demonstrated (again) that your proposed solution is more complex than what everybody now does (which is to either not send or not accept out-of-baliwick glue) and that your proposed solution creates some new problems while failing to fully address the problem we have now. what's your factual, detailed, response? > BTW, the following senario seemingly require handling of additional > As so that "apex" is not a meaningful concept. > > 1) an attacker ask a victim nameserver NS of example.com. > > 2) the attacker repeatedly ask a victim nameserver MX of > .example.com. > > 3) the victim nameserver forward the question to NS of > example.com > > 4) the attacker guess ID and gives false answers with source > address of NS of example.com: > > .example.com MX 0 www.example.com > > with a additional record of > > www.example.com A > > That is, except for glue-A, an additional record should be accepted only > if its name exactly matches the query name. > > Masataka Ohta i agree with florian's answer to this, where he said that the additional data section is mostly useless. i agree with your proposed policy, as stated above. the only A or AAAA RRs that should be sent or accepted in the additional data section are those which (a) referenced by an NS RR in the authority or answer sections, and (b) having owner names at or below the owner name of the NS RRset who references them. these records should be sent onward if the NS RRset which references them is sent onward. these records should be used by the iterator to reach the nameservers whose addresses they are. they should not be used in any other way, and if some other use is demanded, then normal recursion should be done to get real answers to replace what's in cache before that use is made. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 10:56:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDC93A680B; Wed, 6 Aug 2008 10:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.363 X-Spam-Level: X-Spam-Status: No, score=-99.363 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 6r3BMbQ0D8sA; Wed, 6 Aug 2008 10:56:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D87523A6809; Wed, 6 Aug 2008 10:56:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQn7X-0002Ny-7E for namedroppers-data@psg.com; Wed, 06 Aug 2008 17:48:23 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQn7O-0002Ma-Mg for namedroppers@ops.ietf.org; Wed, 06 Aug 2008 17:48:16 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 7BB7033C33; Wed, 6 Aug 2008 10:48:13 -0700 (PDT) Date: Wed, 06 Aug 2008 10:48:11 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: Large EDNS0 buffer sizes and IPv6 In-Reply-To: <82ique8tvd.fsf@mid.bfk.de> References: <82wsiwfzdd.fsf@mid.bfk.de> <827iavetie.fsf@mid.bfk.de> <82ique8tvd.fsf@mid.bfk.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 06 Aug 2008 09:50:30 +0200, Florian Weimer wrote: > > I have no doubt that some vendors lack it (e.g., Microsoft doesn't > > implement it as far as I know), but referring to Linux in this context > > could actually be misleading; the Linux IPv6 protocol stack (including > > socket API extensions) had been a cretaceous relic largely behind many > > other OSes, until the USAGI project incorporated their effort to the > > mainline kernel. > > Okay. If my stack lacks it, what should I cap the EDNS0 buffer size > to? 1232 (1280 minues 40 minus 8)? 1200? I don't think the EDNS0 buffer size matters in this context: it's the receiver's (=client's) buffer size, while it's the sender that needs (or has to deal with the case with missing) IPV6_USE_MIN_MTU. Or are you talking about something like BIND9's specific feature "max-udp-size"? If so, I'd say it should be not larger than 1232 (if there's any possibility that some extension headers can be inserted to DNS responses, it should be smaller accordingly). --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 17:55:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B7E3A686E; Wed, 6 Aug 2008 17:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 7VCTIrG9jOv7; Wed, 6 Aug 2008 17:55:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7E683A67A2; Wed, 6 Aug 2008 17:55:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtfe-000NAC-Pl for namedroppers-data@psg.com; Thu, 07 Aug 2008 00:48:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtfa-000N9g-UD for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 00:48:01 +0000 Received: (qmail 78771 invoked from network); 7 Aug 2008 01:36:14 -0000 Received: from diode-ew.iic.hokudai.ac.jp (HELO necom830.hpcl.titech.ac.jp) (133.50.250.2) by necom830.hpcl.titech.ac.jp with SMTP; 7 Aug 2008 01:36:14 -0000 Message-ID: <489A462B.5010101@necom830.hpcl.titech.ac.jp> Date: Thu, 07 Aug 2008 09:47:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> <56305.1217978024@nsa.vix.com> <48995430.6040306@necom830.hpcl.titech.ac.jp> <81362.1218039206@nsa.vix.com> In-Reply-To: <81362.1218039206@nsa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >>>my position hasn't changed. has yours? >> >>You should change your posision now. > that's what you said ten years ago, too. let me caution you now, as then, > against any attempt at "proof by vigorous reassertion." The bitter reality for you is that, if you admitted your mistake 10 years ago, Kaminsky couldn't have used glue-A for his attack. Kaminsky's originality beyond rfc3833 is to have provided a yet another proof that your authority model is broken. > i've demonstrated > (again) that your proposed solution is more complex than what everybody now > does That many people are using a broken authority model means they are insecure. > i agree with florian's answer to this, where he said that the additional > data section is mostly useless. i agree with your proposed policy, as > stated above. the only A or AAAA RRs that should be sent or accepted in > the additional data section are those which (a) referenced by an NS RR > in the authority or answer sections, and (b) having owner names at or below > the owner name of the NS RRset who references them. Totally wrong. I never proposed such a broken policy. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 17:56:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67253A686E; Wed, 6 Aug 2008 17:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 qMoggb1z0IZP; Wed, 6 Aug 2008 17:56:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7B2F3A67A2; Wed, 6 Aug 2008 17:56:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtjt-000NZo-Oa for namedroppers-data@psg.com; Thu, 07 Aug 2008 00:52:25 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtjq-000NZG-3R for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 00:52:24 +0000 Received: (qmail 78981 invoked from network); 7 Aug 2008 01:40:53 -0000 Received: from diode-ew.iic.hokudai.ac.jp (HELO necom830.hpcl.titech.ac.jp) (133.50.250.2) by necom830.hpcl.titech.ac.jp with SMTP; 7 Aug 2008 01:40:53 -0000 Message-ID: <489A4742.6040002@necom830.hpcl.titech.ac.jp> Date: Thu, 07 Aug 2008 09:52:18 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Florian Weimer CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <82vdye7cpx.fsf@mid.bfk.de> In-Reply-To: <82vdye7cpx.fsf@mid.bfk.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Florian Weimer wrote: > Or you cache referrals without storing any name server name. > Conceptually, this seems to be the much simpler approach. If you mean the cached referral is tagged with the original query, the complexity is no different from mine. If you don't, it's insecure. Paul Vixie wrote: > i don't think so, since nameservers can be renumbered without being > renamed. TTL, which must be properly configured by zone administrators, takes care of it. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 18:08:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8969F28C0E5; Wed, 6 Aug 2008 18:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=2.755, BAYES_00=-2.599] 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 GhVZgDMjVaDV; Wed, 6 Aug 2008 18:08:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 999613A67A2; Wed, 6 Aug 2008 18:08:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtw0-000Ol7-C1 for namedroppers-data@psg.com; Thu, 07 Aug 2008 01:04:56 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtvv-000OkJ-8A for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 01:04:53 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9743DA6683; Thu, 7 Aug 2008 01:04:47 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Masataka Ohta cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 07 Aug 2008 09:47:39 +0900." <489A462B.5010101@necom830.hpcl.titech.ac.jp> References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> <56305.1217978024@nsa.vix.com> <48995430.6040306@necom830.hpcl.titech.ac.jp> <81362.1218039206@nsa.vix.com> <489A462B.5010101@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 07 Aug 2008 01:04:47 +0000 Message-ID: <40340.1218071087@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 9743DA6683.60101 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Masataka Ohta > > The bitter reality for you is that, if you admitted your mistake 10 years > ago, Kaminsky couldn't have used glue-A for his attack. kaminsky's initial vector was poisoned NS RRsets, so, i doubt that i would have seen myself as culpable in that way, even if i thought i'd made the mistake you think i made. > Kaminsky's originality beyond rfc3833 is to have provided a yet another > proof that your authority model is broken. that explaination is just not detailed or complete enough. please try again? > That many people are using a broken authority model means they > are insecure. that explaination is just not detailed or complete enough. please try again? > > i agree with florian's answer to this, where he said that the additional > > data section is mostly useless. i agree with your proposed policy, as > > stated above. the only A or AAAA RRs that should be sent or accepted in > > the additional data section are those which (a) referenced by an NS RR > > in the authority or answer sections, and (b) having owner names at or below > > the owner name of the NS RRset who references them. > > Totally wrong. I never proposed such a broken policy. > > Masataka Ohta i was agreeing with what you had stated above, and then explaining how i related this policy change to my own. i think if you read my words carefully you will see that we are not so far apart. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 18:10:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0753A6AAC; Wed, 6 Aug 2008 18:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.941 X-Spam-Level: X-Spam-Status: No, score=0.941 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 LZ+i6sA0CzN0; Wed, 6 Aug 2008 18:10:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EEF373A684D; Wed, 6 Aug 2008 18:10:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtvc-000Ohq-U9 for namedroppers-data@psg.com; Thu, 07 Aug 2008 01:04:32 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQtvY-000OhE-QQ for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 01:04:31 +0000 Received: (qmail 80473 invoked from network); 7 Aug 2008 01:53:00 -0000 Received: from diode-ew.iic.hokudai.ac.jp (HELO necom830.hpcl.titech.ac.jp) (133.50.250.2) by necom830.hpcl.titech.ac.jp with SMTP; 7 Aug 2008 01:53:00 -0000 Message-ID: <489A4A19.2090302@necom830.hpcl.titech.ac.jp> Date: Thu, 07 Aug 2008 10:04:25 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: bert hubert CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <20080806091701.GA13833@outpost.ds9a.nl> In-Reply-To: <20080806091701.GA13833@outpost.ds9a.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert wrote: > How about just not caching the glue-A? If you receive a referral and try several nameservers, you must keep the glue information, which is called caching. > It is out of bailiwick. As I showed with MX, under ID guessing attack, "bailiwick" is a broken concept. Throw it away. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 18:20:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BBDB3A6AAC; Wed, 6 Aug 2008 18:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.444 X-Spam-Level: X-Spam-Status: No, score=0.444 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 oIjgHlomIalm; Wed, 6 Aug 2008 18:20:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83BD13A68A8; Wed, 6 Aug 2008 18:20:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQu5a-000Pti-K3 for namedroppers-data@psg.com; Thu, 07 Aug 2008 01:14:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQu5W-000Pt0-DF for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 01:14:48 +0000 Received: (qmail 81758 invoked from network); 7 Aug 2008 02:03:17 -0000 Received: from diode-ew.iic.hokudai.ac.jp (HELO necom830.hpcl.titech.ac.jp) (133.50.250.2) by necom830.hpcl.titech.ac.jp with SMTP; 7 Aug 2008 02:03:17 -0000 Message-ID: <489A4C82.5010001@necom830.hpcl.titech.ac.jp> Date: Thu, 07 Aug 2008 10:14:42 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> <56305.1217978024@nsa.vix.com> <48995430.6040306@necom830.hpcl.titech.ac.jp> <81362.1218039206@nsa.vix.com> <489A462B.5010101@necom830.hpcl.titech.ac.jp> <40340.1218071087@nsa.vix.com> In-Reply-To: <40340.1218071087@nsa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >>Kaminsky's originality beyond rfc3833 is to have provided a yet another >>proof that your authority model is broken. > that explaination is just not detailed or complete enough. please try again? The bitter reality for you is that, if you admitted your mistake 10 years ago, Kaminsky couldn't have used glue-A for his attack. >>That many people are using a broken authority model means they >>are insecure. > that explaination is just not detailed or complete enough. please try again? The bitter reality for people using a broken authority model is that, if they admitted their mistake 10 years ago, Kaminsky couldn't have used glue-A for his attack. > i was agreeing with what you had stated above, and then explaining how i > related this policy change to my own. i think if you read my words > carefully you will see that we are not so far apart. First, you must forget broken concepts such as apex and bailiwick. Then, you must read my words carefully. > That is, except for glue-A, an additional record should be accepted only > if its name exactly matches the query name. Masastaka Ohta -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 18:54:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1AF3A6B4A; Wed, 6 Aug 2008 18:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.074 X-Spam-Level: X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=2.525, BAYES_00=-2.599] 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 D+ntxvgrGy7o; Wed, 6 Aug 2008 18:54:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D79D43A6BDB; Wed, 6 Aug 2008 18:54:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQudC-00032s-QV for namedroppers-data@psg.com; Thu, 07 Aug 2008 01:49:34 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQud9-00032Y-Dc for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 01:49:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 06BD5A6529; Thu, 7 Aug 2008 01:49:29 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Masataka Ohta cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 07 Aug 2008 10:14:42 +0900." <489A4C82.5010001@necom830.hpcl.titech.ac.jp> References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> <56305.1217978024@nsa.vix.com> <48995430.6040306@necom830.hpcl.titech.ac.jp> <81362.1218039206@nsa.vix.com> <489A462B.5010101@necom830.hpcl.titech.ac.jp> <40340.1218071087@nsa.vix.com> <489A4C82.5010001@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 07 Aug 2008 01:49:29 +0000 Message-ID: <45660.1218073769@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 06BD5A6529.D3927 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: masataka, i think we're done here. i have treated you respectfully, as one internet engineer to another, and you have responded without honour. goodbye. --paul -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 6 19:00:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CD53A6B53; Wed, 6 Aug 2008 19:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.127 X-Spam-Level: * X-Spam-Status: No, score=1.127 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 wPxOieR0WnRO; Wed, 6 Aug 2008 19:00:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 940E23A67D1; Wed, 6 Aug 2008 19:00:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQukT-0003nC-Ed for namedroppers-data@psg.com; Thu, 07 Aug 2008 01:57:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KQukP-0003mr-Ni for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 01:57:03 +0000 Received: (qmail 86071 invoked from network); 7 Aug 2008 02:45:33 -0000 Received: from diode-ew.iic.hokudai.ac.jp (HELO necom830.hpcl.titech.ac.jp) (133.50.250.2) by necom830.hpcl.titech.ac.jp with SMTP; 7 Aug 2008 02:45:33 -0000 Message-ID: <489A566A.6010206@necom830.hpcl.titech.ac.jp> Date: Thu, 07 Aug 2008 10:56:58 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <68656.1217885936@nsa.vix.com> <4898C830.9040905@necom830.hpcl.titech.ac.jp> <56305.1217978024@nsa.vix.com> <48995430.6040306@necom830.hpcl.titech.ac.jp> <81362.1218039206@nsa.vix.com> <489A462B.5010101@necom830.hpcl.titech.ac.jp> <40340.1218071087@nsa.vix.com> <489A4C82.5010001@necom830.hpcl.titech.ac.jp> <45660.1218073769@nsa.vix.com> In-Reply-To: <45660.1218073769@nsa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > masataka, i think we're done here. No. You have been done 10 years ago. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 04:11:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30333A6B78; Thu, 7 Aug 2008 04:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 o6aIN-egC10w; Thu, 7 Aug 2008 04:11:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C49763A6900; Thu, 7 Aug 2008 04:11:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR3Eq-00005Z-Io for namedroppers-data@psg.com; Thu, 07 Aug 2008 11:01:00 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR3Em-00004y-DS for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 11:00:58 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m77B0pVH080090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Aug 2008 13:00:51 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <489AD5E3.20708@nlnetlabs.nl> Date: Thu, 07 Aug 2008 13:00:51 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Namedroppers Subject: Additional filtering of responses X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 07 Aug 2008 13:00:51 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A new version of my resolver (Unbound) with additional filtering of responses to counter the recently disclosed vulnerability at blackhat was just released. This filtering is in addition to the bailiwick checking. I would like to say what I did, here, because this is easy to do, and effective against certain types of 'the Kaminsky attack'. 1) Stuff in the additional section. RFC2181. Understand why Masataka and Paul think it is very important, and worth bickering over. Just mentioning. 2) CNAME chains. The first CNAME, that starts with the query name, is OK. Everything after that, especially if in-bailiwick and giving nice hints about www.example.com and so on is ignored from incoming messages. Instead, the target of the CNAME is queried again. I think BIND already does this. 3) DNAMEs. Unvalidated DNAMEs are not used from the cache. I believe BIND also does this already. Thus, a new request is done for every query under a (not DNSSEC validated) DNAME, receiving a new redirection for that one query. So, only stuff that exactly matches the query is left in the answer section. The rest is ignored (basically, I delete it immediately). This simply rejects a couple of loopholes without great additional complexity or bother. It does not protect fully against 'The Kaminsky Attack', only some variations are stopped. The best solution is of course DNSSEC. Crypto signatures instead of randomisation games. Enable DNSSEC validation now. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkia1eMACgkQkDLqNwOhpPjkHACgpT1+jYxsi5q5MjmZqUVvt1M9 SMQAn1Uk6LvvArsB65qeqXxT9jR+9FyC =jEVJ -----END PGP SIGNATURE----- -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 06:49:09 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAA23A68CF; Thu, 7 Aug 2008 06:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.966 X-Spam-Level: * X-Spam-Status: No, score=1.966 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SARE_LWSHORTT=1.24] 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 Ud6NFsufg2xt; Thu, 7 Aug 2008 06:49:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CFB93A6847; Thu, 7 Aug 2008 06:49:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR5lG-000Gqu-6d for namedroppers-data@psg.com; Thu, 07 Aug 2008 13:42:38 +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 ) id 1KR5lA-000Gpa-IB for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 13:42:35 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KR5l4-000533-RM for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 15:42:26 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A0FA353836; Thu, 7 Aug 2008 15:42:38 +0200 (CEST) Date: Thu, 7 Aug 2008 15:42:37 +0200 From: bert hubert To: Namedroppers Subject: OFFTOPIC: DNSSEC groupthink versus improving DNS Message-ID: <20080807134236.GA19024@outpost.ds9a.nl> References: <489AD5E3.20708@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489AD5E3.20708@nlnetlabs.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 07, 2008 at 01:00:51PM +0200, Wouter Wijngaards wrote: > The best solution is of course DNSSEC. Crypto signatures instead of > randomisation games. Enable DNSSEC validation now. Not specifically aimed at you Wouter, but it appears the most vocal people in the DNS world are starting to suffer from "groupthink". http://en.wikipedia.org/wiki/Groupthink "A mode of thinking that people engage in when they are deeply involved in a cohesive in-group, when the members' strivings for unanimity override their motivation to realistically appraise alternative courses of action" "Groupthink tends to occur on committees and in large organizations. [..]" For a fine compendium of the kind of statements I mean, please see http://www.dnssec-deployment.org/news/dnssecthismonth/current/ DNSSEC cited as "only full solution" to recent DNS vulnerability "DNSSEC is the only full solution." "We at ISC hope that this issue will draw attention to DNSSEC, which in the end will only be the real solution" And this can't be good - it is leading us to make statements which are patently untrue, like "turn on DNSSEC to be safe". Or 79 page presentations called "DNSSEC in six minutes" - giving people 4.6 seconds per page. It is just not real. http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf Or asking people repeatedly to remove the phrase "under development" when DNSSEC is referred to as a solution under development - which it patently is. If the goal is to deploy DNSSEC quickly, roll out the tools surrounding it, invent the protocols for getting your keying material upstream, widen the registry-registrar protocols to fit these records, create the emergency key rollover procedures (and don't hide the need for them), implement 'auto-sign yes;' etc etc etc. The only way DNSSEC will ever work if it is only slightly harder to operate than DNS. But if you care about DNSSEC, please stop pretending DNSSEC is ready to deploy and just waiting for people to get around to it. If you care about DNSSEC, don't hide that it might in itself have security implications. If you care about DNSSEC, please also stop pretending it is not far harder to operate than DNS itself. DNS is already considered to be difficult, and operators mess it up all the time. It is not like adding an 's' to 'http://'. All these things will come back to haunt you when people actually do follow the advice to turn on DNSSEC now, and discover they've either done something that doesn't help (signing without getting the trust anchor used), or have actually caused their domains to go down, because they did not institutionalize the key rollover procedures. ("You mean this goes down if I don't re-sign in time? Wow!"). The reason I rant on about this is that I care deeply about DNS, and that DNS is *currently* under attack. While DNSSEC is agressively branded as a fine solution, at best, it will be a solution in a few years. Additionally, given things I've said before, I personally don't think DNSSEC will ever see wide usage in the real world, so I feel very strongly that not only do we need to improve DNS in the short term, the short term solution also needs to be the long term solution. But no matter what I feel - please everybody take a minute to read the symptoms of groupthink, and wonder if we are still doing the best job we can to improve DNS in the real world. Because that is our goal. I hope. 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 07:50:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B753B28C0FC; Thu, 7 Aug 2008 07:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-0.378, 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 UeArLXy46fTz; Thu, 7 Aug 2008 07:50:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EDBD28C1A3; Thu, 7 Aug 2008 07:50:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR6i7-000N2X-4P for namedroppers-data@psg.com; Thu, 07 Aug 2008 14:43:27 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR6hv-000N1A-7K for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 14:43:24 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 6AF38FF26C; Fri, 8 Aug 2008 00:43:14 +1000 (EST) Message-ID: <489B09FE.8050701@e164.org> Date: Fri, 08 Aug 2008 00:43:10 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: bert hubert CC: Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> In-Reply-To: <20080807134236.GA19024@outpost.ds9a.nl> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert wrote: > Or 79 page presentations called "DNSSEC in six minutes" - giving people 4.6 > seconds per page. It is just not real. > http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf I've seen this document in the past and it actually turned me and others completely off the idea of DNSSEC, which in part was what led to me playing with encryption funnily enough, because it seems to me most are promoting 30 day TTLs on the sigs, which means 30 days of replay attacks potentially, not to mention the whole re-signing every 30 days. Who ever thought that does not live in the real world, people administering servers with X.509 certs that expire yearly is bad enough, but every 30 days or less??? That alone is going to be a show stopped for most if not all admins with too many things to do and not enough time to do everything. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 08:31:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA10F3A6ABD; Thu, 7 Aug 2008 08:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=2.330, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] 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 mkJSSy+H6X6Z; Thu, 7 Aug 2008 08:31:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C10C3A6992; Thu, 7 Aug 2008 08:31:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR7KM-0001ZP-E2 for namedroppers-data@psg.com; Thu, 07 Aug 2008 15:22:58 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR7KE-0001YM-Bm for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 15:22:53 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4B463A66B2; Thu, 7 Aug 2008 15:22:32 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Wouter Wijngaards cc: Namedroppers In-Reply-To: Your message of "Thu, 07 Aug 2008 13:00:51 +0200." <489AD5E3.20708@nlnetlabs.nl> References: <489AD5E3.20708@nlnetlabs.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 07 Aug 2008 15:22:32 +0000 Message-ID: <45759.1218122552@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 4B463A66B2.CB480 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Additional filtering of responses Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > 1) Stuff in the additional section. RFC2181. Understand why Masataka and > Paul think it is very important, and worth bickering over. Just mentioning. first, we should not send, or if we receive, we should not cache or forward, anything in the additional section that could be found using a new query. this rules out all records except those referred to by NS RRs in an authority or answer section, whose target names are at-or-below the NS RR owner name. second, use these "glue" records only when trying to reach these nameservers, or when answering questions or sending referrals about these nameservers. do not use them in answer sections, nor as additional data for MX or SRV or any other purpose. if needed for such "other purpose", go fetch them normally. the small technical differences that masataka and i were bickering over have to do with implicit antialiasing, and circular nonreachability. i'll explain for the gallery, even though i do not think that masataka will hear me. if the following responses are heard: authority foo.org NS ns1.a.foo.org additional ns1.a.foo.org A 10.0.0.51 authority a.foo.org NS ns1.a.foo.org additional ns1.a.foo.org A 10.0.0.71 then there is a configuration error which crosses zone boundaries and is not subject to normally operational fixits. since both glue records are necessary for reaching the nameserver, an RDNS has a difficult decision to make. masataka recommends one choice, i recommend the other. in masataka's design the RDNS would contextualize the values of ns1.a.foo.org and use each one at different times, depending on which NS RR was being followed. in my design there would never be more than one value for the glue in the rdns cache, and it would be the deepest one (so, the one matching the most labels with the zone whose delegation it was given for.) then there's circular nonreachability. in the following configuration: foo.org NS ns1.bar.net bar.net NS ns2.foo.org my design says that neither zone is reachable, since no glue given by the foo.org or .org servers for the ns1.bar.net nameserver would be believed, and no glue given by the bar.net or .net servers for ns1.foo.org would be believed. in masataka's design, this glue can be sent, and heard, and then used contextually, and both zones would be reachable. these issues are now moot, since the baliwick rules of glue transmission and reception are now enshrined in most operating nameservers as well as several RFCs, and are "house rules" in terms of the DNSSEC design, which contemplates baliwick issues more deeply than pre-SEC DNS did. we can go on bickering, and we could reopen these settled standards questions, but we should stop treating them as open or unsettled questions. i remain troubled and saddened by my inability to communicate effectively with masataka, he is a brilliant and passionate dns engineer who among other things came up with a better design for Secure DNS than any of the ones we have standardized, and anyone who studies his work can learn a lot. however, our far flung rough and tumble community demands proper decorum and not just technical excellence, and for my own self esteem i have to draw the line someplace. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 08:59:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBE93A6BA2; Thu, 7 Aug 2008 08:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[AWL=2.164, BAYES_00=-2.599] 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 w4RHav3qmzOd; Thu, 7 Aug 2008 08:59:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC4D73A68EF; Thu, 7 Aug 2008 08:59:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR7on-0004U7-Q0 for namedroppers-data@psg.com; Thu, 07 Aug 2008 15:54:25 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR7oi-0004Sw-QU for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 15:54:23 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5B441A66AC; Thu, 7 Aug 2008 15:54:17 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Duane cc: bert hubert , Namedroppers In-Reply-To: Your message of "Fri, 08 Aug 2008 00:43:10 +1000." <489B09FE.8050701@e164.org> References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489B09FE.8050701@e164.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 07 Aug 2008 15:54:17 +0000 Message-ID: <49451.1218124457@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 5B441A66AC.5D32A X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Duane > > bert hubert wrote: > > Or 79 page presentations called "DNSSEC in six minutes" - giving people 4.6 > > seconds per page. It is just not real. > > http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf > > I've seen this document in the past and it actually turned me and others > completely off the idea of DNSSEC, ... you are both missing the point of that document. it's not a six minute presentation. but after you sit through that presentation, you can get dnssec running in six minutes. (we've measured.) which is not to say that dnssec is easy -- i know that at ISC we're thinking seriously of dedicating the whole BIND 9.7 release to dnssec tools and usability. > ... which in part was what led to me playing with encryption funnily > enough, because it seems to me most are promoting 30 day TTLs on the > sigs, which means 30 days of replay attacks potentially, not to mention > the whole re-signing every 30 days. you can use whatever TTL you want. but more importantly, are you saying we should discard a protocol because of the quality of early implementations especially in terms of usability? because if that were true i'm pretty sure TCP/IP should have been shot dead back in 1985 or so. likewise X11, BSD, Linux, Windows, and MAC/OS. > Who ever thought that does not live in the real world, people > administering servers with X.509 certs that expire yearly is bad enough, > but every 30 days or less??? > > That alone is going to be a show stopped for most if not all admins with > too many things to do and not enough time to do everything. duane, i understand why bert's a dnssec denier. but i urge you to study the historical debates and the threat models document and think carefully before you climb on that bandwagon. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 09:04:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E63D3A6900; Thu, 7 Aug 2008 09:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=2.020, BAYES_00=-2.599] 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 vRGQ8oB0IO+4; Thu, 7 Aug 2008 09:04:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79A373A68EF; Thu, 7 Aug 2008 09:04:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR7uP-0005A8-K7 for namedroppers-data@psg.com; Thu, 07 Aug 2008 16:00:13 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR7uL-00059a-OS for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 16:00:11 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id BA910A6684; Thu, 7 Aug 2008 16:00:05 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bert hubert cc: Namedroppers In-Reply-To: Your message of "Thu, 07 Aug 2008 15:42:37 +0200." <20080807134236.GA19024@outpost.ds9a.nl> References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 07 Aug 2008 16:00:05 +0000 Message-ID: <50190.1218124805@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: BA910A6684.5487C X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: bert hubert > ... > And this can't be good - it is leading us to make statements which are > patently untrue, like "turn on DNSSEC to be safe". "turn on DNSSEC so that some day we can stop fighting endless brushfires." > But if you care about DNSSEC, please stop pretending DNSSEC is ready to > deploy and just waiting for people to get around to it. dnssec (the protocol) is ready to deploy. the usability of the tools is a bit low at the moment but that's expected in early days. > ("You mean this goes down if I don't re-sign in time? Wow!"). BIND 9.6 will have online re-signing. presumably others will also do this. > But no matter what I feel - please everybody take a minute to read the > symptoms of groupthink, and wonder if we are still doing the best job we > can to improve DNS in the real world. > > Because that is our goal. I hope. i'd like to avoid re-debating the need for dnssec every few weeks. it's been a decade and a half. these debates are just distractions. anyone whose vision or business plan or past representations to customers or code base is just not adaptable to dnssec, please simply indulge those of us who can see a need for it and who think we know how to make it happen. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 09:21:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC123A67B3; Thu, 7 Aug 2008 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.425 X-Spam-Level: X-Spam-Status: No, score=0.425 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 h62QIelk8-mI; Thu, 7 Aug 2008 09:21:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 254C83A6768; Thu, 7 Aug 2008 09:21:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR8AZ-0007wJ-EH for namedroppers-data@psg.com; Thu, 07 Aug 2008 16:16:55 +0000 Received: from [204.9.75.100] (helo=kansas.jhsoft.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR8AU-0007va-I7 for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 16:16:52 +0000 Received: from hemsen by kansas.jhsoft.com (MDaemon PRO v9.6.2) with ESMTP id md50000107337.msg for ; Thu, 07 Aug 2008 16:16:49 +0000 From: =?iso-8859-1?Q?Jesper_G._H=F8y?= To: "'bert hubert'" , "'Namedroppers'" References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> In-Reply-To: <20080807134236.GA19024@outpost.ds9a.nl> Subject: RE: OFFTOPIC: DNSSEC groupthink versus improving DNS Date: Thu, 7 Aug 2008 18:16:20 +0200 Message-ID: <016a01c8f8a8$ee94ea30$cbbebe90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj4lpNKZJO53v0mREik1wC0PirzDQAEioGw Content-Language: en-us X-Authenticated-Sender: jesper@jhsoft.com X-MDRemoteIP: 87.56.149.202 X-Return-Path: jesper@jhsoft.com X-Envelope-From: jesper@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hear hear !! Jesper > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner- > namedroppers@ops.ietf.org] On Behalf Of bert hubert > Sent: Thursday, August 07, 2008 3:43 PM > To: Namedroppers > Subject: OFFTOPIC: DNSSEC groupthink versus improving DNS > > On Thu, Aug 07, 2008 at 01:00:51PM +0200, Wouter Wijngaards wrote: > > The best solution is of course DNSSEC. Crypto signatures instead of > > randomisation games. Enable DNSSEC validation now. > > Not specifically aimed at you Wouter, but it appears the most vocal > people > in the DNS world are starting to suffer from "groupthink". > > http://en.wikipedia.org/wiki/Groupthink > > "A mode of thinking that people engage in when they are deeply involved > in a > cohesive in-group, when the members' strivings for unanimity override > their > motivation to realistically appraise alternative courses of action" > > "Groupthink tends to occur on committees and in large organizations. > [..]" > > For a fine compendium of the kind of statements I mean, please see > http://www.dnssec-deployment.org/news/dnssecthismonth/current/ > > DNSSEC cited as "only full solution" to recent DNS vulnerability > > "DNSSEC is the only full solution." > > "We at ISC hope that this issue will draw attention to DNSSEC, > which > in the end will only be the real solution" > > And this can't be good - it is leading us to make statements which are > patently untrue, like "turn on DNSSEC to be safe". > > Or 79 page presentations called "DNSSEC in six minutes" - giving people > 4.6 > seconds per page. It is just not real. > http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf > > Or asking people repeatedly to remove the phrase "under development" > when > DNSSEC is referred to as a solution under development - which it > patently > is. > > If the goal is to deploy DNSSEC quickly, roll out the tools surrounding > it, > invent the protocols for getting your keying material upstream, widen > the > registry-registrar protocols to fit these records, create the emergency > key > rollover procedures (and don't hide the need for them), implement > 'auto-sign > yes;' etc etc etc. The only way DNSSEC will ever work if it is only > slightly > harder to operate than DNS. > > But if you care about DNSSEC, please stop pretending DNSSEC is ready to > deploy and just waiting for people to get around to it. > > If you care about DNSSEC, don't hide that it might in itself have > security > implications. > > If you care about DNSSEC, please also stop pretending it is not far > harder > to operate than DNS itself. DNS is already considered to be difficult, > and > operators mess it up all the time. It is not like adding an 's' to > 'http://'. > > All these things will come back to haunt you when people actually do > follow > the advice to turn on DNSSEC now, and discover they've either done > something > that doesn't help (signing without getting the trust anchor used), or > have > actually caused their domains to go down, because they did not > institutionalize the key rollover procedures. > > ("You mean this goes down if I don't re-sign in time? Wow!"). > > The reason I rant on about this is that I care deeply about DNS, and > that > DNS is *currently* under attack. While DNSSEC is agressively branded as > a > fine solution, at best, it will be a solution in a few years. > > Additionally, given things I've said before, I personally don't think > DNSSEC > will ever see wide usage in the real world, so I feel very strongly > that not > only do we need to improve DNS in the short term, the short term > solution > also needs to be the long term solution. > > But no matter what I feel - please everybody take a minute to read the > symptoms of groupthink, and wonder if we are still doing the best job > we can > to improve DNS in the real world. > > Because that is our goal. I hope. > > 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: -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 09:36:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3B93A6BF9; Thu, 7 Aug 2008 09:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 8hi3e8bOCDQ6; Thu, 7 Aug 2008 09:36:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4CEE3A6BA2; Thu, 7 Aug 2008 09:36:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR8Px-000AFb-Vy for namedroppers-data@psg.com; Thu, 07 Aug 2008 16:32:49 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR8Pu-000AEO-2r for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 16:32:48 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=JtDeleDE+IhHCCcx1sDp1EvSxwmcofawUDyiE4tbCuFpqHZJMNaItoxQ WZrlxBD+bynZyFZICHgTOmjQodaKU9FPkfae7aRQloRjo9Khjre8gd7or hO85nJ0S6ospnyP; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1218126766; x=1249662766; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20Additional=20filtering=20of=20responses|Date:=20 Thu,=207=20Aug=202008=2018:32:35=20+0200|Message-ID:=20|To:=20Paul=20Vixie=20|Cc: =20Namedroppers=20,=0D=0A=09Wo uter=20Wijngaards=20|MIME-Version: =201.0|In-Reply-To:=20<45759.1218122552@nsa.vix.com> |References:=20<489AD5E3.20708@nlnetlabs.nl>=20<45759.121 8122552@nsa.vix.com>; bh=xdf0tN6pBgXdbh/qXsFiY3lNsdRa8+asNFFp5tjjvO0=; b=dDdhCd1wixZY2AtgbYI25S9BijxZMHOBPZi2rLeiTfw+x6dPK9o0R0w0 GpyUwx6qQWtWonqybXxjnOQExJH90vEOd6EBkFAUiJlnNp098WCy+bbgL dPq6YnUIhjDyT0Y; X-IronPort-AV: E=Sophos;i="4.31,321,1215385200"; d="scan'208";a="4641852" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 07 Aug 2008 17:32:37 +0100 In-Reply-To: <45759.1218122552@nsa.vix.com> References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> To: Paul Vixie Cc: Namedroppers , Wouter Wijngaards Subject: Re: Additional filtering of responses MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Thu, 7 Aug 2008 18:32:35 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 07/08/2008 05:32:37 PM, Serialize complete at 07/08/2008 05:32:37 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote on 08/07/2008 05:22:32 PM: > Re: Additional filtering of responses > > > 1) Stuff in the additional section. RFC2181. Understand why Masataka and > > Paul think it is very important, and worth bickering over. Just mentioning. > > first, we should not send, or if we receive, we should not cache or forward, > anything in the additional section that could be found using a new query. > this rules out all records except those referred to by NS RRs in an authority > or answer section, whose target names are at-or-below the NS RR owner name. What does the scripture say about the following, very small (see * below) response: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;010a.example. IN A ;; ANSWER SECTION: 010a.example. 86400 IN A 192.0.2.9 ;; AUTHORITY SECTION: example. 86400 IN NS 010a.example. ;; Query time: 3 msec ;; SERVER: 192.0.2.10#53(192.0.2.10) No glue. No additional section. Is the address record in the answer section cached? When cached, is 192.0.2.9 considered authoritative now for future lookups under example? Will that NS record ever expire if a query is send once a day ? With all scrubbing and additional filtering of responses, will this response cause a successful cache-(over)write of example NS records? No criticism about scrubbers and filters, just curious of what implementations do and what the protocol dictates. Roy Arends Nominet. (*) The wireformat of this DNS message is just 60 octets due to the use of compression pointers. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 09:52:09 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CB03A6902; Thu, 7 Aug 2008 09:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=1.894, BAYES_00=-2.599] 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 WLW3C4t3jK58; Thu, 7 Aug 2008 09:52:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E3AC3A67B3; Thu, 7 Aug 2008 09:52:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR8dZ-000CBq-Mu for namedroppers-data@psg.com; Thu, 07 Aug 2008 16:46:53 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR8dV-000CBN-V6 for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 16:46:51 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A9B74A6534; Thu, 7 Aug 2008 16:46:44 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "Roy Arends" cc: Namedroppers , Wouter Wijngaards In-Reply-To: Your message of "Thu, 07 Aug 2008 18:32:35 +0200." References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 07 Aug 2008 16:46:44 +0000 Message-ID: <55353.1218127604@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A9B74A6534.D2A34 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Additional filtering of responses Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: From: "Roy Arends" > Paul Vixie wrote on 08/07/2008 05:22:32 PM: > > ... > > What does the scripture say about the following, very small (see * below) > response: what am i, your prophet? to hell with the scriptures, here's my take on it. > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;010a.example. IN A > > ;; ANSWER SECTION: > 010a.example. 86400 IN A 192.0.2.9 > > ;; AUTHORITY SECTION: > example. 86400 IN NS 010a.example. > > ;; Query time: 3 msec > ;; SERVER: 192.0.2.10#53(192.0.2.10) > > No glue. No additional section. > > Is the address record in the answer section cached? yes, since it matches the qname and it's in the zone you were querying. > When cached, is 192.0.2.9 considered authoritative now for future lookups > under example? yes, since it was received as an answer, it's presumed to be the same as the answer one would get by discarding it and re-asking for it. (that's what's different about this case vs. the additional data case.) > Will that NS record ever expire if a query is send once a day ? your example shows an authoritative response. your question here is about expiry and therefore caching. the TTL would tick down, and on the seventh day it would expire, and a subsequent query would cause us to go back to the root zone for a new delegation response. > With all scrubbing and additional filtering of responses, will this > response cause a successful cache-(over)write of example NS records? yes. > No criticism about scrubbers and filters, just curious of what > implementations do and what the protocol dictates. the protocol is horribly weak in terms of datapath protection. the whole thing is laboratory-grade. the only true fix for any of this is dnssec. > Roy Arends > Nominet. > > (*) The wireformat of this DNS message is just 60 octets due to the use > of compression pointers. i think DW (DNS-OARC) has a wiki where stuff like this can be shared, fwiw. note that RTT banding, to make more random the RDNS' selection of an ADNS, is another terrible idea (similar to dns-0x20 in its terribleness but also in the ability to deploy it without a forklift of the whole infrastructure), which would make it little bit harder to spoof .COM delegation responses. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 10:02:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D703A6920; Thu, 7 Aug 2008 10:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_RAND_1=2] 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 tC8Qi3gMH7vA; Thu, 7 Aug 2008 10:02:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BEBF3A6899; Thu, 7 Aug 2008 10:02:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR8nU-000DJJ-Kd for namedroppers-data@psg.com; Thu, 07 Aug 2008 16:57:08 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR8nQ-000DIc-Cx for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 16:57:06 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KR8nM-0007VF-Ac; Thu, 07 Aug 2008 12:57:00 -0400 Message-ID: <489B295C.3020002@ca.afilias.info> Date: Thu, 07 Aug 2008 12:57:00 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Paul Vixie CC: Wouter Wijngaards , Namedroppers , dns-operations@lists.oarci.net Subject: Forgery resilience idea - wildcard cooperative defense References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> In-Reply-To: <45759.1218122552@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: While doing some free-associating around the Kaminsky presentation, I began pondering wildcards. Specifically, what could we do, using wildcards, to nip the $RANDOM.example.com problem in the bud? Here's the beginnings of a meme on this concept... If: Authority server for example.com has a wildcard which means to communicate that anything matching the wildcard should get NXDOMAIN answers; And: A recursive resolver, upon getting an NXDOMAIN for a *specific* subdomain query, such as foo000001.example.com, do a query for the "*" literal; Then: The recursive resolver could cache the wildcard NXDOMAIN for $TTL, and immediately answer queries for all such garbage subdomains. Then, anyone wanting to protect their domain would be able to add in the wildcard NXDOMAIN. Or, plan B (which does not require any work on the part of domain administrators, only modified code on resolvers and authority servers): If: An authority server, upon receiving a query for wildcard literal "*", if it does not find a match, returns in the Additional section, an enumerated list of delegated subdomains. And: (same as "And" clause above) Then: Additional responses get cached for positive enumerated answers, and an additional wildcard literal "*" gets synthesized for NXDOMAIN on all other subdomains. Both of these appear, at first blush, to remove the non-TTL basis for triggering new windows for birthday attacks, and thus can significantly improve the resilience to forgery attacks of the new Kaminsky vector variants. Thoughts? Brian Dickson -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 10:23:16 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EBE3A697F; Thu, 7 Aug 2008 10:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, SARE_RAND_1=2] 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 uviUs9PXhxiY; Thu, 7 Aug 2008 10:23:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CC4A3A6BF6; Thu, 7 Aug 2008 10:23:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR98F-000FUc-Pd for namedroppers-data@psg.com; Thu, 07 Aug 2008 17:18:35 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR98B-000FTq-Pd for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 17:18:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6E60FA66A7; Thu, 7 Aug 2008 17:18:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Brian Dickson cc: Wouter Wijngaards , Namedroppers , dns-operations@lists.oarci.net In-Reply-To: Your message of "Thu, 07 Aug 2008 12:57:00 -0400." <489B295C.3020002@ca.afilias.info> References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <489B295C.3020002@ca.afilias.info> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 07 Aug 2008 17:18:28 +0000 Message-ID: <59360.1218129508@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 6E60FA66A7.EC457 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Forgery resilience idea - wildcard cooperative defense Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > While doing some free-associating around the Kaminsky presentation, I > began pondering wildcards. > > Specifically, what could we do, using wildcards, to nip the > $RANDOM.example.com problem in the bud? > ... any solution requiring cooperative action/change by both the RDNS and ADNS has a cost that's equivilent to "deploy DNSSEC". the thing that's good about UDP port randomization, or DNS-0x20, is that it only requires change in one place (the RDNS in those cases, but an ADNS-only solution would also be cheaper than "deploy DNSSEC".) for solutions involving "upgrade all nodes", the first term of the expression of deployment cost is in touching all those nodes, and the actual complexity or difficulty of the new protocol is a distant second term, easily managed through normal and inevitable capitalistic incentives. for all solutions having the same cost as "deploy DNSSEC", compare the expected benefits. the DNS datapath is long and twisty and involves both on-wire and off-wire transport. zone storage on primary and secondary servers, zone transfer between those servers, zone content generation from databases, responses from ADNS to RDNS, responses from RDNS to stub, and application to stub API, are all corruptible elements of the DNS datapath. > Thoughts? > > Brian Dickson among all same-cost solutions, which one protects the largest amount of the DNS datapath? hint: it's not based on wildcards. i would love to hear more ideas that involve only one point of action/change, like UDP port randomization or DNS-0x20. paul -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 10:26:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F79F3A68CF; Thu, 7 Aug 2008 10:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.049 X-Spam-Level: X-Spam-Status: No, score=-4.049 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 pyzZrgr4X0uk; Thu, 7 Aug 2008 10:26:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BFD53A67ED; Thu, 7 Aug 2008 10:26:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9Co-000Fu6-OF for namedroppers-data@psg.com; Thu, 07 Aug 2008 17:23:18 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9CJ-000FrS-M7 for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 17:22:49 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=L53Js9xCz97NO4F3/o7bC6A4Hb8iDbf1a9GyckLV/28UJeovhFZIdYIi iHNch8+jTwE3POGfoFKIte3dx3M206TMWsOfLAdgM5wA/mKr3q470zIeO lX+F2GLCjQckYEN; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1218129767; x=1249665767; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20Additional=20filtering=20of=20responses|Date:=20 Thu,=207=20Aug=202008=2019:22:44=20+0200|Message-ID:=20|To:=20Paul=20Vixie=20|Cc: =20Namedroppers=20,=0D=0A=09vi xie@vix.com,=0D=0A=09Wouter=20Wijngaards=20|MIME-Version:=201.0|In-Reply-To:=20<55353.1218127 604@nsa.vix.com>|References:=20<489AD5E3.20708@nlnetlabs. nl>=20<45759.1218122552@nsa.vix.com>=20=20=20<55353.1218127604@nsa.vix.com>; bh=98gNVOETLkeTDzRzyEaR+/2ey+lEsXloWpP1BuomwWU=; b=mwOIF3XRT9DnxzKwS4IgMx9ndXr2V9KMa8QoTi11lFGi701KOXJ1EfBU GYkEkUSg8KErj6u5fWi8aaBLyk44mGip6P6s4f6q7e1VWURQonahpC9u4 UjoJETqzS2jazMO; X-IronPort-AV: E=Sophos;i="4.31,321,1215385200"; d="scan'208";a="5818904" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 07 Aug 2008 18:22:46 +0100 In-Reply-To: <55353.1218127604@nsa.vix.com> References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <55353.1218127604@nsa.vix.com> To: Paul Vixie Cc: Namedroppers , vixie@vix.com, Wouter Wijngaards Subject: Re: Additional filtering of responses MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Thu, 7 Aug 2008 19:22:44 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 07/08/2008 06:22:45 PM, Serialize complete at 07/08/2008 06:22:45 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: vixie@vix.com wrote on 08/07/2008 06:46:44 PM: > From: "Roy Arends" > > Paul Vixie wrote on 08/07/2008 05:22:32 PM: > > > ... > > > > What does the scripture say about the following, very small (see * below) > > response: > > what am i, your prophet? to hell with the scriptures, here's my take on it. I was trying to address the group in general, you happened to be on the recipient list. Forgot to scrub that ;-) > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612 > > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;010a.example. IN A > > > > ;; ANSWER SECTION: > > 010a.example. 86400 IN A 192.0.2.9 > > > > ;; AUTHORITY SECTION: > > example. 86400 IN NS 010a.example. > > > > ;; Query time: 3 msec > > ;; SERVER: 192.0.2.10#53(192.0.2.10) > > > > No glue. No additional section. > > > > Is the address record in the answer section cached? > > yes, since it matches the qname and it's in the zone you were querying. > > > When cached, is 192.0.2.9 considered authoritative now for future lookups > > under example? > > yes, since it was received as an answer, it's presumed to be the same as > the answer one would get by discarding it and re-asking for it. (that's > what's different about this case vs. the additional data case.) > > > Will that NS record ever expire if a query is send once a day ? > > your example shows an authoritative response. your question here is about > expiry and therefore caching. the TTL would tick down, and on the seventh > day it would expire, and a subsequent query would cause us to go back to > the root zone for a new delegation response. > > > With all scrubbing and additional filtering of responses, will this > > response cause a successful cache-(over)write of example NS records? > > yes. > > > No criticism about scrubbers and filters, just curious of what > > implementations do and what the protocol dictates. > > the protocol is horribly weak in terms of datapath protection. the whole > thing is laboratory-grade. the only true fix for any of this is dnssec. > > > Roy Arends > > Nominet. > > > > (*) The wireformat of this DNS message is just 60 octets due to the use > > of compression pointers. > > i think DW (DNS-OARC) has a wiki where stuff like this can be shared, fwiw. Thanks for the pointer. I'll ping DW. > note that RTT banding, to make more random the RDNS' selection of an ADNS, > is another terrible idea (similar to dns-0x20 in its terribleness but also > in the ability to deploy it without a forklift of the whole infrastructure), > which would make it little bit harder to spoof .COM delegation responses. Agree Roy -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 10:34:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135023A6C24; Thu, 7 Aug 2008 10:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.63 X-Spam-Level: X-Spam-Status: No, score=-4.63 tagged_above=-999 required=5 tests=[AWL=-1.331, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 JBRHylUttYBE; Thu, 7 Aug 2008 10:34:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 279953A6C21; Thu, 7 Aug 2008 10:34:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9JV-000GbF-R4 for namedroppers-data@psg.com; Thu, 07 Aug 2008 17:30:13 +0000 Received: from [131.111.8.132] (helo=ppsw-2.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9JO-000GaW-Cm for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 17:30:08 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:35783) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1KR9JG-0000F2-7f (Exim 4.70) (return-path ); Thu, 07 Aug 2008 18:29:58 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KR9JG-0006ZY-BQ (Exim 4.67) (return-path ); Thu, 07 Aug 2008 18:29:58 +0100 Date: Thu, 7 Aug 2008 18:29:58 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Vixie cc: Wouter Wijngaards , Namedroppers Subject: Re: Additional filtering of responses In-Reply-To: <45759.1218122552@nsa.vix.com> Message-ID: References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 7 Aug 2008, Paul Vixie wrote: > > first, we should not send, or if we receive, we should not cache or forward, > anything in the additional section that could be found using a new query. > this rules out all records except those referred to by NS RRs in an authority > or answer section, whose target names are at-or-below the NS RR owner name. > > second, use these "glue" records only when trying to reach these nameservers, > or when answering questions or sending referrals about these nameservers. do > not use them in answer sections, nor as additional data for MX or SRV or any > other purpose. if needed for such "other purpose", go fetch them normally. Also, these glue records (both authority and additional) should be ignored if they are already in the cache. Tony. -- f.anthony.n.finch http://dotat.at/ CROMARTY FORTH TYNE: NORTHERLY 5 OR 6, BECOMING VARIABLE 3 OR 4 LATER. MODERATE OR ROUGH. RAIN OR SHOWERS THEN MAINLY FAIR. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 10:42:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CCE73A6B3C; Thu, 7 Aug 2008 10:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.258 X-Spam-Level: * X-Spam-Status: No, score=1.258 tagged_above=-999 required=5 tests=[AWL=1.762, BAYES_00=-2.599, 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 brp3vN93w6kY; Thu, 7 Aug 2008 10:42:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D4393A6AE6; Thu, 7 Aug 2008 10:42:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9RD-000HXa-JA for namedroppers-data@psg.com; Thu, 07 Aug 2008 17:38:11 +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 ) id 1KR9R9-000HWa-Bv for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 17:38: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 ) id 1KR9R7-0000ea-6n for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 19:38:05 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 48CED3F6C; Thu, 7 Aug 2008 19:38:19 +0200 (CEST) Date: Thu, 7 Aug 2008 19:38:19 +0200 From: bert hubert To: Paul Vixie Cc: Brian Dickson , Wouter Wijngaards , Namedroppers , dns-operations@lists.oarci.net Subject: Re: Forgery resilience idea - wildcard cooperative defense Message-ID: <20080807173819.GA25195@outpost.ds9a.nl> Mail-Followup-To: bert hubert , Paul Vixie , Brian Dickson , Wouter Wijngaards , Namedroppers , dns-operations@lists.oarci.net References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <489B295C.3020002@ca.afilias.info> <59360.1218129508@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59360.1218129508@nsa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 07, 2008 at 05:18:28PM +0000, Paul Vixie wrote: > any solution requiring cooperative action/change by both the RDNS and ADNS > has a cost that's equivilent to "deploy DNSSEC". the thing that's good That's simply not true - DNSSEC does not function automatically even if both ADNS and RDNS support it. DNSSEC needs a change to: ADNS, RDNS, the zone, the registry, the registrar, and even the operational procedures of domain owner. (the stub, the application - if you want to give the end-user a choice) EDNS PING or other entropy enhancing solutions provide benefit to anybody deploying them, without further work, and require only ADNS and RDNS work. DNSSEC provides lots of other things beyond entropy of course. 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 10:56:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68473A6ABC; Thu, 7 Aug 2008 10:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, 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 CLIhZ0zfqw6Y; Thu, 7 Aug 2008 10:56:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D0AA3A6B16; Thu, 7 Aug 2008 10:56:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9cc-000Iwu-Kb for namedroppers-data@psg.com; Thu, 07 Aug 2008 17:49:58 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KR9cX-000Iw9-Og for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 17:49:56 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KR9cS-0001V0-5V; Thu, 07 Aug 2008 13:49:48 -0400 Message-ID: <489B35BB.9010105@ca.afilias.info> Date: Thu, 07 Aug 2008 13:49:47 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: bert hubert , Paul Vixie , Wouter Wijngaards , Namedroppers , dns-operations@lists.oarci.net Subject: Re: Forgery resilience idea - wildcard cooperative defense References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <489B295C.3020002@ca.afilias.info> <59360.1218129508@nsa.vix.com> <20080807173819.GA25195@outpost.ds9a.nl> In-Reply-To: <20080807173819.GA25195@outpost.ds9a.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert wrote: > On Thu, Aug 07, 2008 at 05:18:28PM +0000, Paul Vixie wrote: > >> any solution requiring cooperative action/change by both the RDNS and ADNS >> has a cost that's equivilent to "deploy DNSSEC". the thing that's good >> > > That's simply not true - DNSSEC does not function automatically even if both > ADNS and RDNS support it. > > DNSSEC needs a change to: > ADNS, > RDNS, > the zone, > the registry, > the registrar, > and even the operational procedures of domain owner. > (the stub, the application - if you want to give the end-user a > choice) > > Paul's point was that there are orders (many) of magnitude more systems enumerated in the sets { ADNS } and { RDNS } than in all the rest of the items. And, if you are talking about touching them, you may as well touch them in a way that facilitates DNSSEC - possibly in addition to other things. Furthermore: "the zone" and "the registry" are often under the same administrative control, and in the case of TLDs, (a) there are very few currently, and (b) there are choices of TLD once there exists one TLD that does DNSSEC. And, technically, it only requires a change to ONE registrar, to enable DNSSEC, since it is possible to change registrars, if one wants DNSSEC. So, the bare minimum for DNSSEC deployment is: ADNS, RDNS, *one* zone + registry, *one* registrar, and the ops procedures and tools for the domain owner - which may be further facilitated by the outsourcing of some aspects of domain maintenance to a DNS hosting provider that "does" DNSSEC. Brian > EDNS PING or other entropy enhancing solutions provide benefit to anybody > deploying them, without further work, and require only ADNS and RDNS work. > > DNSSEC provides lots of other things beyond entropy of course. > > Bert > > -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 11:21:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D55B3A685B; Thu, 7 Aug 2008 11:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 K6MRbXA3+3lr; Thu, 7 Aug 2008 11:21:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B031F3A6BF6; Thu, 7 Aug 2008 11:21:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRA0E-000MBo-Og for namedroppers-data@psg.com; Thu, 07 Aug 2008 18:14:22 +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 ) id 1KRA0A-000MBH-N7 for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 18:14:20 +0000 Received: from [10.31.201.66] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m77IEDIj003379; Thu, 7 Aug 2008 14:14:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> Date: Thu, 7 Aug 2008 13:44:34 -0400 To: Namedroppers From: Edward Lewis Subject: Re: Additional filtering of responses Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 18:32 +0200 8/7/08, Roy Arends wrote: >What does the scripture say about the following, very small (see * below) >response: > >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612 >;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > >;; QUESTION SECTION: >;010a.example. IN A > >;; ANSWER SECTION: >010a.example. 86400 IN A 192.0.2.9 > >;; AUTHORITY SECTION: >example. 86400 IN NS 010a.example. > >;; Query time: 3 msec >;; SERVER: 192.0.2.10#53(192.0.2.10) What bothers me about this is that the SERVER: address is not in the list (of 1) addresses authoritative for the zone owning the QNAME. (That is, 192.0.2.10 is not 192.0.2.9.) I would probably reject this as an inappropriate setting of the AA bit - or chalk it up to an old BIND recursive server giving me a copy back of what it had just gotten from an authoritative server. If I were paranoid, reject. If I were paranoid but trying to be flexible, i would try to determine the vintage of what was at 192.0.2.10 and then decide on rejection. Otherwise, it seems like a valid answer. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 12:07:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3497B3A67ED; Thu, 7 Aug 2008 12:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 zhE3lkbwXsxg; Thu, 7 Aug 2008 12:07:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 576603A67EB; Thu, 7 Aug 2008 12:06:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRAlB-0001Ih-4E for namedroppers-data@psg.com; Thu, 07 Aug 2008 19:02:53 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRAl7-0001I3-4J for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 19:02:51 +0000 Received: from [IPv6:2001:888:1243::21b:63ff:fec4:a963] ([IPv6:2001:888:1243:0:21b:63ff:fec4:a963]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m77J2gV2072200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2008 21:02:42 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Cc: Namedroppers Message-Id: From: Olaf Kolkman To: bert hubert In-Reply-To: <20080807134236.GA19024@outpost.ds9a.nl> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5--689606043" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Date: Thu, 7 Aug 2008 21:02:42 +0200 References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> X-Pgp-Agent: GPGMail d52 (v52, Leopard) X-Mailer: Apple Mail (2.926) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 07 Aug 2008 21:02:43 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5--689606043 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Bert, Imagine a person that has spend considerable amount of time, money and energy in implementing DNSSEC in servers, tools and libraries; has 'evanginered' DNSSEC for years in a consistently balanced way, recognizing that implementing DNSSEC is far from easy; and has provided multiple pieces of documentation. In other words a person who has put the money where the mouth is. How would such person defend against being assessed to suffer from groupthink or tunnelvission? Every word such a person would utter in defense would be to responded to as "That person has a vetted interest and is part of the groupthinking tunnelvisionaires". These sort of remarks are not very helpful for constructive engineering and don't help to get the core of your message across: "Keep an open mind in alternative interim(?) approaches and work on making DNSSEC easier to operate" --Olaf --Apple-Mail-5--689606043 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkibRtIACgkQtN/ca3YJIocJSgCbB5lqH65uhaBKXiHgw6fHb9cr 3WQAniEvGU49M4e01vB8ENzgvKzwyhcf =5wg7 -----END PGP SIGNATURE----- --Apple-Mail-5--689606043-- -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 12:08:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0F33A6847; Thu, 7 Aug 2008 12:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 yAldETuv5kgO; Thu, 7 Aug 2008 12:08:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D38F63A6824; Thu, 7 Aug 2008 12:07:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRAm1-0001Nj-CT for namedroppers-data@psg.com; Thu, 07 Aug 2008 19:03:45 +0000 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRAlv-0001MW-2w for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 19:03:42 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39440) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1KRAlu-0001zo-Nf (Exim 4.70) (return-path ); Thu, 07 Aug 2008 20:03:38 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KRAlu-0000QG-AV (Exim 4.67) (return-path ); Thu, 07 Aug 2008 20:03:38 +0100 Date: Thu, 7 Aug 2008 20:03:38 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Edward Lewis cc: Namedroppers Subject: Re: Additional filtering of responses In-Reply-To: Message-ID: References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 7 Aug 2008, Edward Lewis wrote: > What bothers me about this is that the SERVER: address is not in the list (of > 1) addresses authoritative for the zone owning the QNAME. (That is, 192.0.2.10 > is not 192.0.2.9.) dig's server is the rDNS, not the aDNS. Tony. -- f.anthony.n.finch http://dotat.at/ SHANNON ROCKALL: NORTHERLY BACKING SOUTHERLY 5 OR 6, OCCASIONALLY 7 LATER. MODERATE OR ROUGH. SHOWERS. MAINLY GOOD. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 13:18:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EED23A6936; Thu, 7 Aug 2008 13:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 5MlGaHwsN-WJ; Thu, 7 Aug 2008 13:18:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08A753A67B3; Thu, 7 Aug 2008 13:18:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRBqO-0008Gi-DE for namedroppers-data@psg.com; Thu, 07 Aug 2008 20:12:20 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRBqK-0008GE-NY for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 20:12:18 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id B4C0E2BE1E9; Thu, 7 Aug 2008 13:12:15 -0700 (PDT) Cc: Namedroppers Message-Id: <26DBE8D4-8C4A-4E4E-BF1C-7B2B951C9FD4@virtualized.org> From: David Conrad To: bert hubert In-Reply-To: <20080807134236.GA19024@outpost.ds9a.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Date: Thu, 7 Aug 2008 13:12:09 -0700 References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bert, On Aug 7, 2008, at 6:42 AM, bert hubert wrote: > On Thu, Aug 07, 2008 at 01:00:51PM +0200, Wouter Wijngaards wrote: >> The best solution is of course DNSSEC. Crypto signatures instead of >> randomisation games. Enable DNSSEC validation now. > Not specifically aimed at you Wouter, but it appears the most vocal > people > in the DNS world are starting to suffer from "groupthink". If constructive discussion is desirable, I suspect it would probably be best to avoid labeling. > The reason I rant on about this is that I care deeply about DNS, and > that > DNS is *currently* under attack. While DNSSEC is agressively branded > as a > fine solution, at best, it will be a solution in a few years. This isn't quite accurate. DNSSEC is an incrementally deployable solution. It can fully protect zones that take the trouble to sign today if caching server operators take the trouble to configure trust anchors for those zones. I have some skepticism DNSSEC will be a fully deployed solution in the foreseeable future, however that does not mean that there isn't potential benefit from its use. And I say this as someone who hates DNSSEC with the passion of a thousands suns of passionate hate. > Additionally, given things I've said before, I personally don't > think DNSSEC > will ever see wide usage in the real world, so I feel very strongly > that not > only do we need to improve DNS in the short term, the short term > solution > also needs to be the long term solution. The short term solutions proposed to date are protecting the data _channel_, not the actual data itself. Fundamentally, this is a flawed approach because as long as the data in the response is vulnerable, there will be ways to abuse it. Perfect source port/128 bit XQID randomization, query/response TTL windowing, whatever is meaningless if you have write access to the path over which the query or response travels. Those hacks are treating the symptom and are a holding action whereas DNSSEC, like aggressive chemotherapy, treats the disease. One can reasonably argue that the side effects of treating the disease may be worse than the disease, but my view is that is simply a "small matter of programming" that will be addressed over time. > But no matter what I feel - please everybody take a minute to read the > symptoms of groupthink, and wonder if we are still doing the best > job we can > to improve DNS in the real world. I will admit that this feels sort of like someone from the petroleum industry accusing folks at the IPCC of "groupthink". In the end, rants on either side don't actually matter all that much. There is a problem for which DNSSEC is proposed as a solution. There are implementations that both do and do not support DNSSEC. There are costs, benefits, and risks on which individual organizations will have to base their decisions to deploy DNSSEC or not. As such, I can't get too worked up on this topic -- I suspect the market will decide. Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 13:55:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C277F3A6943; Thu, 7 Aug 2008 13:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.355 X-Spam-Level: * X-Spam-Status: No, score=1.355 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 gvcmgNdmGq3b; Thu, 7 Aug 2008 13:55:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC7B03A6819; Thu, 7 Aug 2008 13:55:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRCO6-000Bqq-E3 for namedroppers-data@psg.com; Thu, 07 Aug 2008 20:47:10 +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 ) id 1KRCNz-000Bpr-D3 for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 20:47:08 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KRCNr-0003lI-5W for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 22:46:55 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id DE8083F6C; Thu, 7 Aug 2008 22:47:08 +0200 (CEST) Date: Thu, 7 Aug 2008 22:47:08 +0200 From: bert hubert To: Olaf Kolkman Cc: Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Message-ID: <20080807204708.GA27914@outpost.ds9a.nl> References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 07, 2008 at 09:02:42PM +0200, Olaf Kolkman wrote: > Imagine a person that has spend considerable amount of time, money and > energy in implementing DNSSEC in servers, tools and libraries; has > 'evanginered' DNSSEC for years in a consistently balanced way, > recognizing that implementing DNSSEC is far from easy; and has > provided multiple pieces of documentation. In other words a person who > has put the money where the mouth is. Olaf - I can imagine only too well. Around 7 years ago I attended a talk by you where you publicly wondered out loud which problem DNSSEC would solve, and how it could actually be implemented. I was impressed by your open-mindedness. Over the years, I've seen the open mindedness disappear from the community. As a decade passed away and DNSSEC stil hadn't caught on, self-doubt has been replaced by the mantra that DNSSEC will soon be deployed, and that it is ready - when there is much still up in the air. > How would such person defend against being assessed to suffer from > groupthink or tunnelvission? That is very valid criticism, and I spent quite some time tonight figuring out what I'm actually hoping to achieve - besides what is described very well on http://xkcd.com/386/ . The main thing I hope is that we won't forget the pre-DNSSEC world. In short this means committing towards finding a solution in short order that will address remaining spoofing dangers - 64% chance of success within 24 hours using reasonable resources. Success in these terms might be "effectively taking over the root for 100000 people". I've already seen influential WG members state that we'll have only one chance to seriously change DNS in the coming decade. And furthermore, that we should use this one chance for implementing DNSSEC. In addition, it has been reasoned that implementing DNSSEC is just as hard or easy as implementing entropy additions. The upshot of this all is that people are effectively saying they will not be supporting anything *but* DNSSEC. And that would be sad, if not dangerous, especially since quite a number of wise people agree DNSSEC rollout will take years. We don't have years to address the 64% chance. > These sort of remarks are not very helpful for constructive > engineering and don't help to get the core of your message across: > "Keep an open mind in alternative interim(?) approaches and work on > making DNSSEC easier to operate" I'd love to be able to put it less bluntly. What is also not helpful is the near-religious mantra that DNSSEC is the only solution, a mantra which is part of an astoundingly large part of recent postings and literature. So - I apologise for accusing people of something it is hard to defend against. But I sincerely hope we won't let the dream of large-scale DNSSEC deployment over time stand in the way of doing something now. 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 14:03:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE5628C128; Thu, 7 Aug 2008 14:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, 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 TDkeu-FFyJ-p; Thu, 7 Aug 2008 14:03:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB2383A6967; Thu, 7 Aug 2008 14:03:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRCUy-000CX9-7X for namedroppers-data@psg.com; Thu, 07 Aug 2008 20:54:16 +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 ) id 1KRCUu-000CWf-OQ for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 20:54:14 +0000 Received: from [10.31.201.66] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m77Ks3cS004528; Thu, 7 Aug 2008 16:54:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> Date: Thu, 7 Aug 2008 16:44:05 -0400 To: Tony Finch From: Edward Lewis Subject: Re: Additional filtering of responses Cc: Edward Lewis , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 20:03 +0100 8/7/08, Tony Finch wrote: >On Thu, 7 Aug 2008, Edward Lewis wrote: > >> What bothers me about this is that the SERVER: address is not in >>the list (of >> 1) addresses authoritative for the zone owning the QNAME. (That >>is, 192.0.2.10 >> is not 192.0.2.9.) > >dig's server is the rDNS, not the aDNS. Ok, but still, the aa bit would then make me do some more sanity checking if I were paranoid. Is(n't) it true that BIND 9 no longer sets AA bit on answers a'coming through the cache? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 14:07:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910B63A6872; Thu, 7 Aug 2008 14:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 lUS5eExO-zKd; Thu, 7 Aug 2008 14:07:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4EB43A69A7; Thu, 7 Aug 2008 14:07:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRCcc-000DOj-5v for namedroppers-data@psg.com; Thu, 07 Aug 2008 21:02:10 +0000 Received: from [69.17.117.5] (helo=mail3.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRCcX-000DO9-Lm for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 21:02:07 +0000 Received: (qmail 19341 invoked from network); 7 Aug 2008 21:02:04 -0000 Received: from unknown (HELO [164.99.130.55]) (federico@[130.57.22.201]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 Aug 2008 21:02:04 -0000 Message-ID: <489B63C7.3090700@ximian.com> Date: Thu, 07 Aug 2008 17:06:15 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: bert hubert CC: Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> In-Reply-To: <20080807134236.GA19024@outpost.ds9a.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I have read Hubert-DNSSEC-groupthink and support its adoption as a WG document :-) -F bert hubert wrote: > On Thu, Aug 07, 2008 at 01:00:51PM +0200, Wouter Wijngaards wrote: >> The best solution is of course DNSSEC. Crypto signatures instead of >> randomisation games. Enable DNSSEC validation now. > > Not specifically aimed at you Wouter, but it appears the most vocal people > in the DNS world are starting to suffer from "groupthink". > > http://en.wikipedia.org/wiki/Groupthink > > "A mode of thinking that people engage in when they are deeply involved in a > cohesive in-group, when the members' strivings for unanimity override their > motivation to realistically appraise alternative courses of action" > > "Groupthink tends to occur on committees and in large organizations. > [..]" > > For a fine compendium of the kind of statements I mean, please see > http://www.dnssec-deployment.org/news/dnssecthismonth/current/ > > DNSSEC cited as "only full solution" to recent DNS vulnerability > > "DNSSEC is the only full solution." > > "We at ISC hope that this issue will draw attention to DNSSEC, which > in the end will only be the real solution" > > And this can't be good - it is leading us to make statements which are > patently untrue, like "turn on DNSSEC to be safe". > > Or 79 page presentations called "DNSSEC in six minutes" - giving people 4.6 > seconds per page. It is just not real. > http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf > > Or asking people repeatedly to remove the phrase "under development" when > DNSSEC is referred to as a solution under development - which it patently > is. > > If the goal is to deploy DNSSEC quickly, roll out the tools surrounding it, > invent the protocols for getting your keying material upstream, widen the > registry-registrar protocols to fit these records, create the emergency key > rollover procedures (and don't hide the need for them), implement 'auto-sign > yes;' etc etc etc. The only way DNSSEC will ever work if it is only slightly > harder to operate than DNS. > > But if you care about DNSSEC, please stop pretending DNSSEC is ready to > deploy and just waiting for people to get around to it. > > If you care about DNSSEC, don't hide that it might in itself have security > implications. > > If you care about DNSSEC, please also stop pretending it is not far harder > to operate than DNS itself. DNS is already considered to be difficult, and > operators mess it up all the time. It is not like adding an 's' to > 'http://'. > > All these things will come back to haunt you when people actually do follow > the advice to turn on DNSSEC now, and discover they've either done something > that doesn't help (signing without getting the trust anchor used), or have > actually caused their domains to go down, because they did not > institutionalize the key rollover procedures. > > ("You mean this goes down if I don't re-sign in time? Wow!"). > > The reason I rant on about this is that I care deeply about DNS, and that > DNS is *currently* under attack. While DNSSEC is agressively branded as a > fine solution, at best, it will be a solution in a few years. > > Additionally, given things I've said before, I personally don't think DNSSEC > will ever see wide usage in the real world, so I feel very strongly that not > only do we need to improve DNS in the short term, the short term solution > also needs to be the long term solution. > > But no matter what I feel - please everybody take a minute to read the > symptoms of groupthink, and wonder if we are still doing the best job we can > to improve DNS in the real world. > > Because that is our goal. I hope. > > Bert > -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@ximian.com -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 16:03:10 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014DA3A6A86; Thu, 7 Aug 2008 16:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_21=0.6] 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 RMCUMHWMI6mf; Thu, 7 Aug 2008 16:03:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38A2A3A6AFD; Thu, 7 Aug 2008 16:03:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRENw-000OUl-NX for namedroppers-data@psg.com; Thu, 07 Aug 2008 22:55:08 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRENs-000OTw-JZ for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 22:55:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 113ABA6682; Thu, 7 Aug 2008 22:54:56 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Edward Lewis cc: Tony Finch , Namedroppers In-Reply-To: Your message of "Thu, 07 Aug 2008 16:44:05 -0400." References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 07 Aug 2008 22:54:56 +0000 Message-ID: <5610.1218149696@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 113ABA6682.AA8DD X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Additional filtering of responses Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Is(n't) it true that BIND 9 no longer sets AA bit on answers a'coming > through the cache? yes. everything is cached and regenerated. bind9 RDNS never sets AA. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 18:00:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4593A6C64; Thu, 7 Aug 2008 18:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 2g7RpmLD+RUZ; Thu, 7 Aug 2008 18:00:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E2583A6C5A; Thu, 7 Aug 2008 18:00:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGEN-0008tI-VP for namedroppers-data@psg.com; Fri, 08 Aug 2008 00:53:23 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGEK-0008sl-Gr for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 00:53:22 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id F3FE0FF26C; Fri, 8 Aug 2008 10:53:20 +1000 (EST) Message-ID: <489B98FA.40307@e164.org> Date: Fri, 08 Aug 2008 10:53:14 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Paul Vixie CC: bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> In-Reply-To: <49451.1218124457@nsa.vix.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > you are both missing the point of that document. it's not a six minute > presentation. but after you sit through that presentation, you can get > dnssec running in six minutes. (we've measured.) which is not to say > that dnssec is easy -- i know that at ISC we're thinking seriously of > dedicating the whole BIND 9.7 release to dnssec tools and usability. I never mentioned anything about the time of the presentation or time to set it up, my comment was how convoluted and complicated the process is caused me to to instantly dislike it due to that reason. > you can use whatever TTL you want. but more importantly, are you saying I realise this, but I was under the mistaken assumption, before Bert corrected me that sigs were generated on the fly and were only valid for a small window. > we should discard a protocol because of the quality of early implementations > especially in terms of usability? because if that were true i'm pretty > sure TCP/IP should have been shot dead back in 1985 or so. likewise X11, > BSD, Linux, Windows, and MAC/OS. Ummm a good 'security' model in this sense would be to look at the credit card industry, unless payment gateways are down merchants are instantly notified of problems with credit cards, not 30 days later. > duane, i understand why bert's a dnssec denier. but i urge you to study > the historical debates and the threat models document and think carefully > before you climb on that bandwagon. Oh please give me a little credit here and drop the 'denier' nonsense right now, that term is often used as an emotive response that has no basis in logic or reason where the underlying argument is weak in order to silence criticisms. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 18:01:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED4D3A6C71; Thu, 7 Aug 2008 18:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 bcjfCgajVtWP; Thu, 7 Aug 2008 18:01:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27DD63A6C64; Thu, 7 Aug 2008 18:01:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGDh-0008pp-70 for namedroppers-data@psg.com; Fri, 08 Aug 2008 00:52:41 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGDb-0008oj-V4 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 00:52:39 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m780qMd2002912; Fri, 8 Aug 2008 10:52:22 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808080052.m780qMd2002912@drugs.dv.isc.org> To: Duane Cc: bert hubert , Namedroppers From: Mark Andrews Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS In-reply-to: Your message of "Fri, 08 Aug 2008 00:43:10 +1000." <489B09FE.8050701@e164.org> Date: Fri, 08 Aug 2008 10:52:22 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > bert hubert wrote: > > Or 79 page presentations called "DNSSEC in six minutes" - giving people 4.6 > > seconds per page. It is just not real. > > http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf > > I've seen this document in the past and it actually turned me and others > completely off the idea of DNSSEC, which in part was what led to me > playing with encryption funnily enough, because it seems to me most are > promoting 30 day TTLs on the sigs, which means 30 days of replay attacks > potentially, and the alterative is arbitary data insertion. You could have online keys and sign every response with a ttl + clock skew based window. This requires that the private key is on all slaves. The crypto hardware guys will love you :-) Note this is a implementation / deployment trade off. The protocol supports either senario. > not to mention the whole re-signing every 30 days. Which can be completely automated. Has already been in some senarios. I havn't re-signed my zones for months despite using a 30 day expiry period on the signatures. It is set and forget. More and more of the process will become "set and forget" as the tools develop. > Who ever thought that does not live in the real world, people > administering servers with X.509 certs that expire yearly is bad enough, > but every 30 days or less??? Well if you know that the data will be stable for a year you can sign once a year. > That alone is going to be a show stopped for most if not all admins with > too many things to do and not enough time to do everything. The tools today can take a signed zone and re-sign it as well as incrementing the SOA serial in the process. Re-signing then reloading can be run from cron on a weekly basis. Note the tools will only get better so the costs will continue to go down. They have gone down enormously from the original design costs. Mark > -- > > Best regards, > Duane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 18:08:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03DB3A6C17; Thu, 7 Aug 2008 18:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 0FZbmSYr0eN5; Thu, 7 Aug 2008 18:08:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA6733A682A; Thu, 7 Aug 2008 18:08:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGNr-0009oI-SQ for namedroppers-data@psg.com; Fri, 08 Aug 2008 01:03:12 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGNo-0009nl-C3 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 01:03:10 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 7B2E1FF26C; Fri, 8 Aug 2008 11:03:09 +1000 (EST) Message-ID: <489B9B48.4090605@e164.org> Date: Fri, 08 Aug 2008 11:03:04 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Olaf Kolkman CC: bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Olaf Kolkman wrote: > Imagine a person that has spend considerable amount of time, money and > energy in implementing DNSSEC in servers, tools and libraries; has > 'evanginered' DNSSEC for years in a consistently balanced way, > recognizing that implementing DNSSEC is far from easy; and has provided > multiple pieces of documentation. In other words a person who has put > the money where the mouth is. You summed it up so nicely, they have put so much time and effort into this that they can't see if there are other options because they are blinded by the blinkers they have on, to go forward no matter what the cost or no matter what other solutions could solve the same problem. > How would such person defend against being assessed to suffer from > groupthink or tunnelvission? All I've heard lately is shouts of enable DNSSEC now, or die, frankly I'm not very moved by them nor anyone else I know, it's 2008 and DNSSEC is using a model even X.509 threw out years ago and has been trying to fix every since. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 18:14:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636273A6C70; Thu, 7 Aug 2008 18:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 OX6t+JERQKwL; Thu, 7 Aug 2008 18:14:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 678F93A6C65; Thu, 7 Aug 2008 18:14:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGUu-000ATd-TO for namedroppers-data@psg.com; Fri, 08 Aug 2008 01:10:28 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGUq-000AT3-PS for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 01:10:26 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 7A9DBFF272; Fri, 8 Aug 2008 11:10:25 +1000 (EST) Message-ID: <489B9CFB.30002@e164.org> Date: Fri, 08 Aug 2008 11:10:19 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Mark Andrews CC: bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080052.m780qMd2002912@drugs.dv.isc.org> In-Reply-To: <200808080052.m780qMd2002912@drugs.dv.isc.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > and the alterative is arbitary data insertion. > > You could have online keys and sign every response with a > ttl + clock skew based window. This requires that the > private key is on all slaves. The crypto hardware guys > will love you :-) I'm working on it, I'm fighting 2 issues at present, one to standardise attributes on OpenPGP keys for server purposes, and once that's sorted and all the hubbub about DNS has died down the 2nd issue is using encryption to provide both confidentiality and effectively remove the need for signing at all. Thanks to feed back from people in this group I've improve the draft considerably but yea, the idea now is to setup a AES session key that is good for X hours using an initial RSA encrypted request from the client. > Note this is a implementation / deployment trade off. The > protocol supports either senario. It's 2008 and hardware is cheap it's silly to think of 1960's credit card processing models are even valid 10 years ago let alone now. > Which can be completely automated. Has already been in > some senarios. I havn't re-signed my zones for months > despite using a 30 day expiry period on the signatures. Shows how much DNSSEC is used by you then, otherwise you would be rejecting your own DNS replies. > It is set and forget. More and more of the process will > become "set and forget" as the tools develop. You miss the point, that presentation outlined what is now, not what will be when someone can be bothered to. > Well if you know that the data will be stable for a year > you can sign once a year. At the vest least natural disasters don't stick to time tables last time I checked. > The tools today can take a signed zone and re-sign it as > well as incrementing the SOA serial in the process. Re-signing > then reloading can be run from cron on a weekly basis. That's a nice 'hack' > Note the tools will only get better so the costs will > continue to go down. They have gone down enormously from > the original design costs. Again, I can only comment on what is, not what will be. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 18:44:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8058F3A6C60; Thu, 7 Aug 2008 18:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] 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 GqENs1vKmCtn; Thu, 7 Aug 2008 18:44:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A33B28C113; Thu, 7 Aug 2008 18:44:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGw2-000Cvg-Fr for namedroppers-data@psg.com; Fri, 08 Aug 2008 01:38:30 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRGvz-000CvF-1G for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 01:38:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A128CA6659; Fri, 8 Aug 2008 01:38:18 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Duane cc: bert hubert , Namedroppers In-Reply-To: Your message of "Fri, 08 Aug 2008 10:53:14 +1000." <489B98FA.40307@e164.org> References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> <489B98FA.40307@e164.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 08 Aug 2008 01:38:18 +0000 Message-ID: <26046.1218159498@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A128CA6659.B9CC8 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: duane, if your point is that dnssec is horrid misshapen pig that even its mother could not love, then you will find noone (anywhere) willing to argue otherwise. it's late, it's ugly, it's fragile, it's a pig, and that's the universal view of it, there are no dissenters. but having ridden the whole ride and having seen victory declared several times, i am in the "it can be made to work in its present form without any more flag days" camp. call that groupthink if you must, say what you want about me, but say also that i hate dnssec but plan to deploy it anyway. --paul -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 18:59:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01233A6C81; Thu, 7 Aug 2008 18:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 Q15wFH5dBlKr; Thu, 7 Aug 2008 18:59:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDF383A6C7F; Thu, 7 Aug 2008 18:59:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRH8V-000E62-AA for namedroppers-data@psg.com; Fri, 08 Aug 2008 01:51:23 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRH8N-000E5I-2c for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 01:51:20 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 599CCA66B8; Fri, 8 Aug 2008 01:51:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Duane cc: Olaf Kolkman , bert hubert , Namedroppers In-Reply-To: Your message of "Fri, 08 Aug 2008 11:03:04 +1000." <489B9B48.4090605@e164.org> References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489B9B48.4090605@e164.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 08 Aug 2008 01:51:01 +0000 Message-ID: <28119.1218160261@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 599CCA66B8.C466A X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Duane > > You summed it up so nicely, they have put so much time and effort into > this that they can't see if there are other options because they are > blinded by the blinkers they have on, to go forward no matter what the > cost or no matter what other solutions could solve the same problem. as a possible proposed "they" in that example, i wonder what other option will allow arbitrary end users to be sure that an NXDOMAIN has not been remapped by their ISP or by their RDNS? or that a secondary name service provider (or a primary name service provider for that matter) hasn't added a wildcard to catch typo's in their customer domains and send them to an advertising server? in other words, what other options provide end-to-end data integrity for DNS? if all you've got is hop-by-hop, i'm uninterested. amit klein and dan kaminsky have showed us some off-path attacks, to which dan bernstein and amit klein and david dagon have shown us some RDNS-only defenses. but provider-in-the-middle and more generally man-in-the-middle attacks are on-path not off-path. i want protection against on-path attacks, as well as against all possible future off-path attacks. you're right that i'm dismissing proposals that do not address those requirements. now you know exactly why. > > How would such person defend against being assessed to suffer from > > groupthink or tunnelvission? > > All I've heard lately is shouts of enable DNSSEC now, or die, frankly > I'm not very moved by them nor anyone else I know, it's 2008 and DNSSEC > is using a model even X.509 threw out years ago and has been trying to > fix every since. after watching masataka's superior approach get railroaded into a ditch back in 1996 or 1997 or so, i can no longer get bogged down in how ugly the protocol is or how ugly was the process that begat that protocol. my pragmatic concerns are only, is it end-to-end, and can it be made to work? show me an option that's end-to-end and can be made to work and i'll pay close attention and if it's real i'll say "dnssec or this other thing are the only real solutions." but show me a hop-by-hop solution and i'll say "this isn't complete" and if it requires a replacement or upgrade of both RDNS and ADNS nodes then i'll say "at that price i'd prefer end-to-end data integrity, please." let's stop talking personalities and focus on the engineering economics. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 19:06:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C363A6C64; Thu, 7 Aug 2008 19:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 dxF8stUL9pbh; Thu, 7 Aug 2008 19:06:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 875183A6C7B; Thu, 7 Aug 2008 19:06:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRHIb-000Exq-HJ for namedroppers-data@psg.com; Fri, 08 Aug 2008 02:01:49 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRHIX-000ExQ-BP for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 02:01:47 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7821bHu004699; Fri, 8 Aug 2008 12:01:37 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808080201.m7821bHu004699@drugs.dv.isc.org> To: Duane Cc: bert hubert , Namedroppers From: Mark Andrews Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS In-reply-to: Your message of "Fri, 08 Aug 2008 11:10:19 +1000." <489B9CFB.30002@e164.org> Date: Fri, 08 Aug 2008 12:01:37 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Mark Andrews wrote: > > and the alterative is arbitary data insertion. > > > > You could have online keys and sign every response with a > > ttl + clock skew based window. This requires that the > > private key is on all slaves. The crypto hardware guys > > will love you :-) > > I'm working on it, I'm fighting 2 issues at present, one to standardise > attributes on OpenPGP keys for server purposes, and once that's sorted > and all the hubbub about DNS has died down the 2nd issue is using > encryption to provide both confidentiality and effectively remove the > need for signing at all. > > Thanks to feed back from people in this group I've improve the draft > considerably but yea, the idea now is to setup a AES session key that is > good for X hours using an initial RSA encrypted request from the client. > > > Note this is a implementation / deployment trade off. The > > protocol supports either senario. > > It's 2008 and hardware is cheap it's silly to think of 1960's credit > card processing models are even valid 10 years ago let alone now. > > > Which can be completely automated. Has already been in > > some senarios. I havn't re-signed my zones for months > > despite using a 30 day expiry period on the signatures. > > Shows how much DNSSEC is used by you then, otherwise you would be > rejecting your own DNS replies. I missed the "by hand" part. I havn't re-signed my zones, by hand, for months despite using a 30 day expiry period on the signatures. Completely automated re-signing. > > It is set and forget. More and more of the process will > > become "set and forget" as the tools develop. > > You miss the point, that presentation outlined what is now, not what > will be when someone can be bothered to. > > > Well if you know that the data will be stable for a year > > you can sign once a year. > > At the vest least natural disasters don't stick to time tables last time > I checked. > > > The tools today can take a signed zone and re-sign it as > > well as incrementing the SOA serial in the process. Re-signing > > then reloading can be run from cron on a weekly basis. > > That's a nice 'hack' > > > Note the tools will only get better so the costs will > > continue to go down. They have gone down enormously from > > the original design costs. > > Again, I can only comment on what is, not what will be. > > -- > > Best regards, > Duane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 19:22:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4583A6C74; Thu, 7 Aug 2008 19:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_21=0.6] 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 Foc3bivn-jyX; Thu, 7 Aug 2008 19:22:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AEC33A6C5D; Thu, 7 Aug 2008 19:22:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRHYJ-000GQ2-Ie for namedroppers-data@psg.com; Fri, 08 Aug 2008 02:18:03 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRHYF-000GPO-Ga for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 02:18:01 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m782HkLs005190; Fri, 8 Aug 2008 12:17:48 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808080217.m782HkLs005190@drugs.dv.isc.org> To: Edward Lewis Cc: Tony Finch , Namedroppers From: Mark Andrews Subject: Re: Additional filtering of responses In-reply-to: Your message of "Thu, 07 Aug 2008 16:44:05 -0400." Date: Fri, 08 Aug 2008 12:17:46 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 20:03 +0100 8/7/08, Tony Finch wrote: > >On Thu, 7 Aug 2008, Edward Lewis wrote: > > > >> What bothers me about this is that the SERVER: address is not in > >>the list (of > >> 1) addresses authoritative for the zone owning the QNAME. (That > >>is, 192.0.2.10 > >> is not 192.0.2.9.) > > > >dig's server is the rDNS, not the aDNS. > > Ok, but still, the aa bit would then make me do some more sanity > checking if I were paranoid. > > Is(n't) it true that BIND 9 no longer sets AA bit on answers a'coming > through the cache? It *never* set AA on answers from the cache. All remote answers go through the cache. AA is only set on answers from zone data. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 19:43:46 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A248A3A6847; Thu, 7 Aug 2008 19:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] 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 XzEZxdTgp1Lg; Thu, 7 Aug 2008 19:43:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D272B3A6828; Thu, 7 Aug 2008 19:43:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRHr4-000Htk-UR for namedroppers-data@psg.com; Fri, 08 Aug 2008 02:37:26 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRHr1-000HtN-18 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 02:37:25 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m782bBqk005628; Fri, 8 Aug 2008 12:37:11 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808080237.m782bBqk005628@drugs.dv.isc.org> To: Duane Cc: Paul Vixie , bert hubert , Namedroppers From: Mark Andrews Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS In-reply-to: Your message of "Fri, 08 Aug 2008 10:53:14 +1000." <489B98FA.40307@e164.org> Date: Fri, 08 Aug 2008 12:37:11 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Ummm a good 'security' model in this sense would be to look at the > credit card industry, unless payment gateways are down merchants are > instantly notified of problems with credit cards, not 30 days later. Well we could stop caching any DNS data. That's the only way to make it match the credit card industry model where changes are instantly available. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 19:59:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8598E3A685C; Thu, 7 Aug 2008 19:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 GC0ghIefKB76; Thu, 7 Aug 2008 19:59:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA73F3A635F; Thu, 7 Aug 2008 19:59:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRI86-000JKY-M6 for namedroppers-data@psg.com; Fri, 08 Aug 2008 02:55:02 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRI83-000JJo-2o for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 02:55:00 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id E0F49FF26C; Fri, 8 Aug 2008 12:54:59 +1000 (EST) Message-ID: <489BB57C.80001@e164.org> Date: Fri, 08 Aug 2008 12:54:52 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Paul Vixie CC: bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> <489B98FA.40307@e164.org> <26046.1218159498@nsa.vix.com> In-Reply-To: <26046.1218159498@nsa.vix.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > duane, if your point is that dnssec is horrid misshapen pig that even > its mother could not love, then you will find noone (anywhere) willing > to argue otherwise. it's late, it's ugly, it's fragile, it's a pig, > and that's the universal view of it, there are no dissenters. No arguments here. > but having ridden the whole ride and having seen victory declared several > times, i am in the "it can be made to work in its present form without any > more flag days" camp. call that groupthink if you must, say what you want > about me, but say also that i hate dnssec but plan to deploy it anyway. I most sincerely apologise if I made any person comment to or about you that most certainly was not my intention. I like everyone else want a solution to this and other problems with DNS but for a number of reasons I don't like the form it's taken in DNSSEC. I'm trying to stick to the non-political factual reasons for my concerns over it, however it wouldn't be terribly difficult to figure out other concerns I have with it. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 20:13:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511873A6983; Thu, 7 Aug 2008 20:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 GoeFr1d0BEN8; Thu, 7 Aug 2008 20:13:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F27F43A69E0; Thu, 7 Aug 2008 20:12:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIIt-000KEQ-JL for namedroppers-data@psg.com; Fri, 08 Aug 2008 03:06:11 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIIp-000KA2-En for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 03:06:09 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id CF906FF26C; Fri, 8 Aug 2008 13:05:26 +1000 (EST) Message-ID: <489BB7F0.4040500@e164.org> Date: Fri, 08 Aug 2008 13:05:20 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Paul Vixie CC: Olaf Kolkman , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489B9B48.4090605@e164.org> <28119.1218160261@nsa.vix.com> In-Reply-To: <28119.1218160261@nsa.vix.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > as a possible proposed "they" in that example, i wonder what other option > will allow arbitrary end users to be sure that an NXDOMAIN has not been > remapped by their ISP or by their RDNS? or that a secondary name service > provider (or a primary name service provider for that matter) hasn't added > a wildcard to catch typo's in their customer domains and send them to an > advertising server? in other words, what other options provide end-to-end > data integrity for DNS? if all you've got is hop-by-hop, i'm uninterested. I maybe late to this party but I tried to engage you in this in previous email correspondences, suffice to say I don't think either of us have all the answers but dismissing alternative opinions on how this could be solved out of hand isn't going to help either. > amit klein and dan kaminsky have showed us some off-path attacks, to which > dan bernstein and amit klein and david dagon have shown us some RDNS-only > defenses. but provider-in-the-middle and more generally man-in-the-middle > attacks are on-path not off-path. i want protection against on-path > attacks, as well as against all possible future off-path attacks. you're > right that i'm dismissing proposals that do not address those requirements. > now you know exactly why. You just pointed out the solution, and I'm pretty sure you or others have mentioned this before, but as far as end to end solutions go the only solution is to run the resolving DNS caching at the end points. While this negates some of the benefits of caching by say ISPs, it's more than obvious the ISPs can no longer be trusted on that front in any case and end user directly requesting to authoritative DNS servers is the only option. After all, do we allow ISPs to cache SSL connections, why should DNS be any different? > after watching masataka's superior approach get railroaded into a ditch > back in 1996 or 1997 or so, i can no longer get bogged down in how ugly > the protocol is or how ugly was the process that begat that protocol. my > pragmatic concerns are only, is it end-to-end, and can it be made to work? How much enthusiasm has been garnered for DNSSEC since well ever except by those evangelising it? If you can't sell it to people like me purely on its merits it's already a forgone conclusion, I'm not trying to be facetious here or antagonistic but pointing out a reality of the way the world is, not the way we'd like the world to be. > but show me a hop-by-hop solution and i'll say "this isn't complete" and if > it requires a replacement or upgrade of both RDNS and ADNS nodes then i'll > say "at that price i'd prefer end-to-end data integrity, please." You've already outlined numerous corner cases where DNSSEC will fail in end to end data integrity, so obviously it's not solving the issue in all cases either. My hop-by-hop approach wasn't the end game, merely a stepping stone until something better could occur at the end points, my approach is simply trying to go the path of least resistance and work up from there. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 20:18:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2C63A67A8; Thu, 7 Aug 2008 20:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 D26LZEtHDZUg; Thu, 7 Aug 2008 20:18:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCD113A6954; Thu, 7 Aug 2008 20:18:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIRB-000Kzx-5T for namedroppers-data@psg.com; Fri, 08 Aug 2008 03:14:45 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIR7-000KzM-QE for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 03:14:43 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 2C2D4FF26C; Fri, 8 Aug 2008 13:14:42 +1000 (EST) Message-ID: <489BBA1C.1040107@e164.org> Date: Fri, 08 Aug 2008 13:14:36 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Mark Andrews CC: Paul Vixie , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080237.m782bBqk005628@drugs.dv.isc.org> In-Reply-To: <200808080237.m782bBqk005628@drugs.dv.isc.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > Well we could stop caching any DNS data. That's the only > way to make it match the credit card industry model where > changes are instantly available. Anyone have any idea how many credit card transactions per second occur? Seems to me they are very similar in topology, so even if you only cached information for a small amount of time that would mitigate most attacks people seem to be so concerned about at present. Since the window of opportunity for these sort of attacks would be greatly reduced, the cost to commit these types of attacks would greatly increase if not be virtually impossible to commit on any kind of scale worth doing, so problem solved. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 20:38:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7165E3A6975; Thu, 7 Aug 2008 20:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 kkMnuFlCU3Fy; Thu, 7 Aug 2008 20:38:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 957E13A695C; Thu, 7 Aug 2008 20:38:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIij-000Muk-3f for namedroppers-data@psg.com; Fri, 08 Aug 2008 03:32:53 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIif-000MtH-6E for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 03:32:51 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m783WaYI006465; Fri, 8 Aug 2008 13:32:36 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808080332.m783WaYI006465@drugs.dv.isc.org> To: Duane Cc: Paul Vixie , bert hubert , Namedroppers From: Mark Andrews Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS In-reply-to: Your message of "Fri, 08 Aug 2008 13:14:36 +1000." <489BBA1C.1040107@e164.org> Date: Fri, 08 Aug 2008 13:32:36 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Mark Andrews wrote: > > > Well we could stop caching any DNS data. That's the only > > way to make it match the credit card industry model where > > changes are instantly available. > > Anyone have any idea how many credit card transactions per second occur? > > Seems to me they are very similar in topology, so even if you only > cached information for a small amount of time that would mitigate most > attacks people seem to be so concerned about at present. > > Since the window of opportunity for these sort of attacks would be > greatly reduced, the cost to commit these types of attacks would greatly > increase if not be virtually impossible to commit on any kind of scale > worth doing, so problem solved. Except it wouldn't solve NXDOMAIN re-writing and other on-path attacks which modify the returned data such that it is believed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 20:45:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8040A3A69E0; Thu, 7 Aug 2008 20:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 J64fSfU4-FnR; Thu, 7 Aug 2008 20:45:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B149C3A67A8; Thu, 7 Aug 2008 20:45:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIqp-000NrG-DI for namedroppers-data@psg.com; Fri, 08 Aug 2008 03:41:15 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIqm-000NqZ-2z for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 03:41:13 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 968EEFF26C; Fri, 8 Aug 2008 13:41:13 +1000 (EST) Message-ID: <489BC053.5080904@e164.org> Date: Fri, 08 Aug 2008 13:41:07 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Mark Andrews CC: Paul Vixie , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080332.m783WaYI006465@drugs.dv.isc.org> In-Reply-To: <200808080332.m783WaYI006465@drugs.dv.isc.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > Except it wouldn't solve NXDOMAIN re-writing and other > on-path attacks which modify the returned data such that > it is believed. Others have pointed out other cases where DNSSEC won't either. Reducing the caching time only requires changes at the resolver end, unlike DNSSEC which if Bert's list is accurate is quite long and involved code wise. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 20:48:41 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE5C3A6821; Thu, 7 Aug 2008 20:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] 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 R6Jq4IKmD+tr; Thu, 7 Aug 2008 20:48:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 020FB28C12D; Thu, 7 Aug 2008 20:47:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIsl-000O5h-HY for namedroppers-data@psg.com; Fri, 08 Aug 2008 03:43:15 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIsg-000O4x-RK for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 03:43:13 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m783gnXT006554; Fri, 8 Aug 2008 13:42:49 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808080342.m783gnXT006554@drugs.dv.isc.org> To: Duane Cc: Paul Vixie , Olaf Kolkman , bert hubert , Namedroppers From: Mark Andrews Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS In-reply-to: Your message of "Fri, 08 Aug 2008 13:05:20 +1000." <489BB7F0.4040500@e164.org> Date: Fri, 08 Aug 2008 13:42:49 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Paul Vixie wrote: > > > as a possible proposed "they" in that example, i wonder what other option > > will allow arbitrary end users to be sure that an NXDOMAIN has not been > > remapped by their ISP or by their RDNS? or that a secondary name service > > provider (or a primary name service provider for that matter) hasn't added > > a wildcard to catch typo's in their customer domains and send them to an > > advertising server? in other words, what other options provide end-to-end > > data integrity for DNS? if all you've got is hop-by-hop, i'm uninterested. > > I maybe late to this party but I tried to engage you in this in previous > email correspondences, suffice to say I don't think either of us have > all the answers but dismissing alternative opinions on how this could be > solved out of hand isn't going to help either. > > > amit klein and dan kaminsky have showed us some off-path attacks, to which > > dan bernstein and amit klein and david dagon have shown us some RDNS-only > > defenses. but provider-in-the-middle and more generally man-in-the-middle > > attacks are on-path not off-path. i want protection against on-path > > attacks, as well as against all possible future off-path attacks. you're > > right that i'm dismissing proposals that do not address those requirements. > > now you know exactly why. > > You just pointed out the solution, and I'm pretty sure you or others > have mentioned this before, but as far as end to end solutions go the > only solution is to run the resolving DNS caching at the end points. I don't think anyone would disagree with you. Preferably validation should be done in the application. If that is not supported by the application then on the local machine. Validation in off machine caches is only there for the legacy machines. > While this negates some of the benefits of caching by say ISPs, it's > more than obvious the ISPs can no longer be trusted on that front in any > case and end user directly requesting to authoritative DNS servers is > the only option. Only if the ISP's don't supply clean path. DNSSEC allows you to detect when the path has been compromised. > After all, do we allow ISPs to cache SSL connections, why should DNS be > any different? > > > after watching masataka's superior approach get railroaded into a ditch > > back in 1996 or 1997 or so, i can no longer get bogged down in how ugly > > the protocol is or how ugly was the process that begat that protocol. my > > pragmatic concerns are only, is it end-to-end, and can it be made to work? > > How much enthusiasm has been garnered for DNSSEC since well ever except > by those evangelising it? > > If you can't sell it to people like me purely on its merits it's already > a forgone conclusion, I'm not trying to be facetious here or > antagonistic but pointing out a reality of the way the world is, not the > way we'd like the world to be. > > > but show me a hop-by-hop solution and i'll say "this isn't complete" and if > > it requires a replacement or upgrade of both RDNS and ADNS nodes then i'll > > say "at that price i'd prefer end-to-end data integrity, please." > > You've already outlined numerous corner cases where DNSSEC will fail in > end to end data integrity, so obviously it's not solving the issue in > all cases either. > > My hop-by-hop approach wasn't the end game, merely a stepping stone > until something better could occur at the end points, my approach is > simply trying to go the path of least resistance and work up from there. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 20:52:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F9E3A69E0; Thu, 7 Aug 2008 20:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 tpPum7HA3PYk; Thu, 7 Aug 2008 20:52:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A67CA3A68C0; Thu, 7 Aug 2008 20:52:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIv4-000OMS-WC for namedroppers-data@psg.com; Fri, 08 Aug 2008 03:45:39 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRIv1-000OLt-Kp for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 03:45:37 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id E3525FF26C; Fri, 8 Aug 2008 13:45:36 +1000 (EST) Message-ID: <489BC15A.1000407@e164.org> Date: Fri, 08 Aug 2008 13:45:30 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Mark Andrews CC: Paul Vixie , Olaf Kolkman , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080342.m783gnXT006554@drugs.dv.isc.org> In-Reply-To: <200808080342.m783gnXT006554@drugs.dv.isc.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > Validation in off machine caches is only there for the legacy machines. That's always going to be an issue unless you can get all parties to implement something better. > Only if the ISP's don't supply clean path. DNSSEC allows you to > detect when the path has been compromised. Only if you already know DNSSEC mechanisms exist and they haven't been filtered. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 21:16:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FF23A6A3E; Thu, 7 Aug 2008 21:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 CLEWeOCwZpuC; Thu, 7 Aug 2008 21:16:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F52E3A68C0; Thu, 7 Aug 2008 21:16:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRJIJ-0001UM-Ps for namedroppers-data@psg.com; Fri, 08 Aug 2008 04:09:39 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRJIF-0001SX-PX for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 04:09:37 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7849E6h006829; Fri, 8 Aug 2008 14:09:14 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808080409.m7849E6h006829@drugs.dv.isc.org> To: Duane Cc: Paul Vixie , Olaf Kolkman , bert hubert , Namedroppers From: Mark Andrews Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS In-reply-to: Your message of "Fri, 08 Aug 2008 13:45:30 +1000." <489BC15A.1000407@e164.org> Date: Fri, 08 Aug 2008 14:09:14 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Mark Andrews wrote: > > > Validation in off machine caches is only there for the legacy machines. > > That's always going to be an issue unless you can get all parties to > implement something better. Well every PC owner can do this today. It is not that hard to setup a on machine validating caching server and to configure the PC to use it. It's only administative inertia that stops people doing it today. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 21:23:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DB43A6AC4; Thu, 7 Aug 2008 21:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 E7Xqn0vCamU9; Thu, 7 Aug 2008 21:23:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FA5C3A691F; Thu, 7 Aug 2008 21:22:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRJQT-0002OX-0N for namedroppers-data@psg.com; Fri, 08 Aug 2008 04:18:05 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRJQP-0002Ns-2n for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 04:18:02 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id B95DEFF26C; Fri, 8 Aug 2008 14:18:01 +1000 (EST) Message-ID: <489BC8F2.3040204@e164.org> Date: Fri, 08 Aug 2008 14:17:54 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Mark Andrews CC: Paul Vixie , Olaf Kolkman , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080409.m7849E6h006829@drugs.dv.isc.org> In-Reply-To: <200808080409.m7849E6h006829@drugs.dv.isc.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: >> Mark Andrews wrote: >> >>> Validation in off machine caches is only there for the legacy machines. >> That's always going to be an issue unless you can get all parties to >> implement something better. > > Well every PC owner can do this today. It is not that hard to setup > a on machine validating caching server and to configure the PC to use > it. Ok so you're saying these people that get suckered by internet/email scams would be capable of setting this up properly? > It's only administative inertia that stops people doing it today. No, there is a lot more to it than that, most people don't understand internet security, you know it's bad when most people get warm fuzzy feelings over actions taken to make them feel secure, when the reality is so far from the truth it's not funny. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 21:49:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0ECA3A6C0A; Thu, 7 Aug 2008 21:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, 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 Jg67rhQM-nVp; Thu, 7 Aug 2008 21:49:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD7803A65A6; Thu, 7 Aug 2008 21:49:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRJpq-00055x-1P for namedroppers-data@psg.com; Fri, 08 Aug 2008 04:44:18 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRJpm-00055X-Fb for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 04:44:16 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KRJpl-0006Bm-QI; Fri, 08 Aug 2008 00:44:13 -0400 Message-ID: <489BCF1D.20804@ca.afilias.info> Date: Fri, 08 Aug 2008 00:44:13 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Duane CC: Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080332.m783WaYI006465@drugs.dv.isc.org> <489BC053.5080904@e164.org> In-Reply-To: <489BC053.5080904@e164.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Duane wrote: > Mark Andrews wrote: > > >> Except it wouldn't solve NXDOMAIN re-writing and other >> on-path attacks which modify the returned data such that >> it is believed. >> > > Others have pointed out other cases where DNSSEC won't either. Reducing > the caching time only requires changes at the resolver end, unlike > DNSSEC which if Bert's list is accurate is quite long and involved code > wise. > > I don't recall any specific cases being pointed out. If you wouldn't mind, could you give some kind of reference (e.g. who, or what case, or ideally, a URL pointing into the archives)? To clarify - what DNSSEC does (or at least claims to do) is make it possible to validate answers to queries, against a chain of trust to some trust anchor. This means one of three results occurs - a valid answer is confirmed, an unverified answer exists due to lack of signature (where the lack of signature itself is able to be validated), or tampering occurs and is detected. So, it won't *prevent* tampering, but does make the data itself tamper-evident. Tampering is only slightly worse than a blind DoS attack, and has the same results in a DNSSEC-protected world. The only incremental benefit of hop-by-hop crypto security would be to make the data opaque, which while in theory seems better, in practice is irrelevant. If you can't tamper with the data, it doesn't matter whether you can see it. And hop-by-hop data encryption is a bigger cost than validation via signatures, particularly in the increase in state, and in the asymmetric cost model. Signatures scale very well, especially in an one-to-many world, which DNS is. >> > Only if the ISP's don't supply clean path. DNSSEC allows you to >> > detect when the path has been compromised. >> > > Only if you already know DNSSEC mechanisms exist and they haven't been > filtered. > ?? You can't filter DNSSEC mechanisms without that filtration being detected (on a validating resolver). This includes the ability to determine whether DNSSEC mechanisms exist. (The above is predicated on some configured trust anchor, either a signed root or via locally configured trust anchors, or DLV.) If you believe these aren't correct statements, I encourage you to provide something more than a mere assertion, e.g. example, reference, proof, counter-example, or anything else that you think will support your position. BTW - critical analysis of DNSSEC and alternatives is by no means discouraged, and I think any time anyone brings fresh eyes to the problem, only good things can come of it - if polite, reasoned discourse is the result. Brian -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 21:58:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1FA3A6C86; Thu, 7 Aug 2008 21:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] 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 EfnNN2O2n9Vc; Thu, 7 Aug 2008 21:58:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB1853A6BF8; Thu, 7 Aug 2008 21:56:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRJxk-0005xE-21 for namedroppers-data@psg.com; Fri, 08 Aug 2008 04:52:28 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRJxg-0005wd-4q for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 04:52:26 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m784q46m007017; Fri, 8 Aug 2008 14:52:04 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808080452.m784q46m007017@drugs.dv.isc.org> To: Duane Cc: Paul Vixie , Olaf Kolkman , bert hubert , Namedroppers From: Mark Andrews Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS In-reply-to: Your message of "Fri, 08 Aug 2008 14:17:54 +1000." <489BC8F2.3040204@e164.org> Date: Fri, 08 Aug 2008 14:52:04 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Mark Andrews wrote: > >> Mark Andrews wrote: > >> > >>> Validation in off machine caches is only there for the legacy machines. > >> That's always going to be an issue unless you can get all parties to > >> implement something better. > > > > Well every PC owner can do this today. It is not that hard to setup > > a on machine validating caching server and to configure the PC to use > > it. > > Ok so you're saying these people that get suckered by internet/email > scams would be capable of setting this up properly? People setup caching servers everyday today. Setting up one to also do validation is not that much extra. > > It's only administative inertia that stops people doing it today. > > No, there is a lot more to it than that, most people don't understand > internet security, you know it's bad when most people get warm fuzzy > feelings over actions taken to make them feel secure, when the reality > is so far from the truth it's not funny. And education is the solution to that. People aren't as stupid as we often portray then as. Give them good information and they will use it. Do best practice from the start. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 22:17:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834593A6C13; Thu, 7 Aug 2008 22:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 uaoOodxztMrm; Thu, 7 Aug 2008 22:17:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F4683A68C0; Thu, 7 Aug 2008 22:17:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRKFy-00080U-R3 for namedroppers-data@psg.com; Fri, 08 Aug 2008 05:11:18 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRKFv-000806-2j for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 05:11:16 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 4F4A7FF26C; Fri, 8 Aug 2008 15:11:17 +1000 (EST) Message-ID: <489BD56E.9070503@e164.org> Date: Fri, 08 Aug 2008 15:11:10 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Brian Dickson CC: Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080332.m783WaYI006465@drugs.dv.isc.org> <489BC053.5080904@e164.org> <489BCF1D.20804@ca.afilias.info> In-Reply-To: <489BCF1D.20804@ca.afilias.info> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Brian Dickson wrote: > I don't recall any specific cases being pointed out. http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01264.html >> Only if you already know DNSSEC mechanisms exist and they haven't been >> filtered. > > You can't filter DNSSEC mechanisms without that filtration being > detected (on a validating resolver). > > This includes the ability to determine whether DNSSEC mechanisms exist. > > (The above is predicated on some configured trust anchor, either a > signed root or via locally configured trust anchors, or DLV.) That was my point, you have to know about it already one way or another for it to work, otherwise it can simply be ignored by upstream caching servers. > BTW - critical analysis of DNSSEC and alternatives is by no means > discouraged, and I think any time anyone brings fresh eyes to the > problem, only good things can come of it - if polite, reasoned discourse > is the result. Again I apologise if I've said anything that unduly offended anyone, I'm merely expressing my opinions based on what I know about certain topics and I may have made incorrect assumptions and I'm only too happy to be corrected so I don't make the same mistakes in future. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 22:20:41 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623873A6C48; Thu, 7 Aug 2008 22:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 Q5ZQZ2vvVqkk; Thu, 7 Aug 2008 22:20:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E1663A68C0; Thu, 7 Aug 2008 22:20:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRKLW-0008ad-JD for namedroppers-data@psg.com; Fri, 08 Aug 2008 05:17:02 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRKLT-0008aF-6I for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 05:17:00 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id A8515FF26C; Fri, 8 Aug 2008 15:17:00 +1000 (EST) Message-ID: <489BD6C6.6070003@e164.org> Date: Fri, 08 Aug 2008 15:16:54 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Mark Andrews CC: Paul Vixie , Olaf Kolkman , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080452.m784q46m007017@drugs.dv.isc.org> In-Reply-To: <200808080452.m784q46m007017@drugs.dv.isc.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > People setup caching servers everyday today. Setting up one to > also do validation is not that much extra. Most people don't, the ones that do can probably do as you suggest, but in reality the ones that would most benefit are those that rely on ISPs or their routers/modems to do it all for them. > And education is the solution to that. That only works if people are interested in the learning you are trying to impart to them. Most people will be complacent about such matters until it really really matters to them personally. Such as loosing money to an internet scam. > People aren't as stupid as we often portray then as. Give them > good information and they will use it. Do best practice from the > start. I'm not commenting on people's intelligence, I should have made my point clearer I suppose, a general apathy plus some ignorance of the mechanisms of how computers work and people don't care to learn beyond that, until they have to and well by then it's usually too late the horse has already bolted and they do the whole talk show scene trying to get everyone to learn from their mistakes, which for the most part most people don't. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 23:02:08 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEDD3A6C41; Thu, 7 Aug 2008 23:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 b+1lJagD+Bpw; Thu, 7 Aug 2008 23:02:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 311D53A6C81; Thu, 7 Aug 2008 23:02:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRKyo-000CgN-AX for namedroppers-data@psg.com; Fri, 08 Aug 2008 05:57:38 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRKyj-000CdH-Am for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 05:57:36 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id A8D50FF26C; Fri, 8 Aug 2008 15:57:34 +1000 (EST) Message-ID: <489BE047.1010100@e164.org> Date: Fri, 08 Aug 2008 15:57:27 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Namedroppers , Mark Andrews , Paul Vixie , bert hubert Subject: The problem I see with DNSSEC as a potential end user and administrator. X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I just spoke to Mark on the phone, I'm sure he'll have some interesting remarks about that in private, but to sum things up the conclusion I was trying (poorly) to get across to Mark was this. The higher the perceived cost, and the lower the perceived benefit will make people complacent about deploying DNSSEC. If the PDF link Bert posted is anything to go by there is a long way to go before it's simple enough for people not to care about doing 1 or 2 things extra to implement DNSSEC. However while ever the process is so long and drawn out, regardless of how much worst it was in the past, people won't be bothered with it until or unless they are personally effected in some respect. You can't over come complacency by saying the process is simpler now then it used to be and how easy it is to setup, it doesn't wash with me or anyone else like me. We all live busy lives and all have better things to do then care about if the zone is signed or not at present because of a lack of tangible benefit. Further more when anything gets more complicated I worry about how much additional maintenance work it will take putting out fires in the future when something breaks. Something always breaks so it isn't a matter of if but when. To sum things up, I don't care how easy the people promoting DNSSEC is, it is still much too drawn out and I have better things to do with my time then doing a bunch on mundane and repetitive things which computers are so much better at. Make the setup so easy a cave man could do it, or even better, fully automate then when there is no perceived additional cost people will start adopting it. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 23:05:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CE93A6C84; Thu, 7 Aug 2008 23:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, 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 ABncUcGuEZKz; Thu, 7 Aug 2008 23:04:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D1F93A6C88; Thu, 7 Aug 2008 23:04:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRL1z-000D4g-Lq for namedroppers-data@psg.com; Fri, 08 Aug 2008 06:00:55 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRL1w-000D4L-59 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 06:00:53 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KRL1r-0000Tp-Pn; Fri, 08 Aug 2008 02:00:47 -0400 Message-ID: <489BE10F.7040407@ca.afilias.info> Date: Fri, 08 Aug 2008 02:00:47 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Duane CC: Mark Andrews , Paul Vixie , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> In-Reply-To: <489BBA1C.1040107@e164.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Duane wrote: > Mark Andrews wrote: > > >> Well we could stop caching any DNS data. That's the only >> way to make it match the credit card industry model where >> changes are instantly available. >> > > Anyone have any idea how many credit card transactions per second occur? > > Ballpark figure - 6.5 B people, 10 transactions per day average, gives ~ 1M/s worldwide. There are about 1.5M unique hosts seen at the root and TLD servers per day, most are caching resolvers. If the rates were comparable, each resolver would process ~ 1 query/second. Off by several orders of magnitude. > Seems to me they are very similar in topology, so even if you only > cached information for a small amount of time that would mitigate most > attacks people seem to be so concerned about at present. > > Sorry, the details on the attack methods and vectors means you would throw away good answers more often than you would throw away bad answers (from the cache), but an empty cache for a given domain is an extra vector. Long TTLs are your friend. That those happen to benefit scaling is a bonus, not an assumption. Here's a clue - credit card transactions are in effect only signed in real-time, not processed per se. The actual transactions are still batch processed much later. This is in part to avoid data leakage through the authentication process itself. So, DNSSEC is already pretty similar to CC's, just with better scaling properties and less overhead. > Since the window of opportunity for these sort of attacks would be > greatly reduced, the cost to commit these types of attacks would greatly > increase if not be virtually impossible to commit on any kind of scale > worth doing, so problem solved. > > Not. Brian -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 23:29:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C9F3A6C8E; Thu, 7 Aug 2008 23:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 5QxXdSlyXTHL; Thu, 7 Aug 2008 23:29:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C5633A68F4; Thu, 7 Aug 2008 23:29:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLPL-000Ff6-EB for namedroppers-data@psg.com; Fri, 08 Aug 2008 06:25:03 +0000 Received: from [64.158.219.15] (helo=secure.perfectemail.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLPH-000FeV-U1 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 06:25:01 +0000 Received: (qmail 16144 invoked from network); 8 Aug 2008 06:24:59 -0000 Received: from c-71-202-44-149.hsd1.ca.comcast.net (HELO Zion.local) (71.202.44.149) by secure.perfectemail.net with SMTP; 8 Aug 2008 06:24:59 -0000 Message-ID: <489BE6BA.8050200@everydns.net> Date: Thu, 07 Aug 2008 23:24:58 -0700 From: David Ulevitch User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Duane CC: Namedroppers , Mark Andrews , Paul Vixie , bert hubert Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. References: <489BE047.1010100@e164.org> In-Reply-To: <489BE047.1010100@e164.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Duane, Can we get a last name please? We already have one Duane on this list and it's hard to know who you are. Is that too much to ask? This is an IETF mailing list, after all. -David Duane wrote: > I just spoke to Mark on the phone, I'm sure he'll have some interesting > remarks about that in private, but to sum things up the conclusion I was > trying (poorly) to get across to Mark was this. > > The higher the perceived cost, and the lower the perceived benefit will > make people complacent about deploying DNSSEC. > > If the PDF link Bert posted is anything to go by there is a long way to > go before it's simple enough for people not to care about doing 1 or 2 > things extra to implement DNSSEC. > > However while ever the process is so long and drawn out, regardless of > how much worst it was in the past, people won't be bothered with it > until or unless they are personally effected in some respect. > > You can't over come complacency by saying the process is simpler now > then it used to be and how easy it is to setup, it doesn't wash with me > or anyone else like me. We all live busy lives and all have better > things to do then care about if the zone is signed or not at present > because of a lack of tangible benefit. > > Further more when anything gets more complicated I worry about how much > additional maintenance work it will take putting out fires in the future > when something breaks. Something always breaks so it isn't a matter of > if but when. > > To sum things up, I don't care how easy the people promoting DNSSEC is, > it is still much too drawn out and I have better things to do with my > time then doing a bunch on mundane and repetitive things which computers > are so much better at. > > Make the setup so easy a cave man could do it, or even better, fully > automate then when there is no perceived additional cost people will > start adopting it. > -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 23:29:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A1B3A6C93; Thu, 7 Aug 2008 23:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 YjAKKpP42gxj; Thu, 7 Aug 2008 23:29:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A35C13A6A92; Thu, 7 Aug 2008 23:29:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLLB-000FFD-QN for namedroppers-data@psg.com; Fri, 08 Aug 2008 06:20:45 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLL7-000FB8-Ak for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 06:20:43 +0000 Received: (qmail 8723 invoked from network); 8 Aug 2008 07:02:10 -0000 Received: from s208130.ppp.asahi-net.or.jp (HELO necom830.hpcl.titech.ac.jp) (220.157.208.130) by necom830.hpcl.titech.ac.jp with SMTP; 8 Aug 2008 07:02:10 -0000 Message-ID: <489BE3FB.8030104@necom830.hpcl.titech.ac.jp> Date: Fri, 08 Aug 2008 15:13:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Wouter Wijngaards CC: Namedroppers Subject: Re: Additional filtering of responses References: <489AD5E3.20708@nlnetlabs.nl> In-Reply-To: <489AD5E3.20708@nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Wouter Wijngaards wrote: > A new version of my resolver (Unbound) with additional filtering of > responses to counter the recently disclosed vulnerability at blackhat > was just released. This filtering is in addition to the bailiwick > checking. No. If you properly handle additional glue As to be tagged by query, glue As does not need any bailiwick checking. As answer non-glue additional information needs exact matching with query, the information needs no bailiwick checking. "Bailiwick" was considered to be a valid concept for non-glue information but is never a valid concept for glue-As. No WG consensus can override scientific nature of the DNS referral mechanism. > The best solution is of course DNSSEC. A better solution, a lot more easier to deploy than DNSSEC, is to use TCP, deployment of which is, of course, still hard. However, it is only as hard as updating all the install bases, including those on various types of NAT boxed, of DNS so that they can treat glue and other information properly. > Crypto signatures instead of randomisation games. Enable DNSSEC > validation now. Because of complexity of DNSSEC caused by poor combination of DNS and public key cryptography, there are a several subtle hacking, which are not present in PODS (plain old DNS), performed to make it work. With such additional subtlities, it is practically impossible to be sure that DNSSEC is more secure than PODS. Remember that even PODS has a lot of unexpected security holes. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 23:36:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1DA3A6C92; Thu, 7 Aug 2008 23:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 xRkesiyP4DuV; Thu, 7 Aug 2008 23:35:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B1533A6C83; Thu, 7 Aug 2008 23:35:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLRV-000FsH-OU for namedroppers-data@psg.com; Fri, 08 Aug 2008 06:27:17 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLRS-000Frs-5Y for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 06:27:15 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id C42FAFF26C; Fri, 8 Aug 2008 16:27:15 +1000 (EST) Message-ID: <489BE73D.6020409@e164.org> Date: Fri, 08 Aug 2008 16:27:09 +1000 From: Duane User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Brian Dickson CC: Mark Andrews , Paul Vixie , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489BE10F.7040407@ca.afilias.info> In-Reply-To: <489BE10F.7040407@ca.afilias.info> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Brian Dickson wrote: > Ballpark figure - 6.5 B people, 10 transactions per day average, gives ~ > 1M/s worldwide. > If the rates were comparable, each resolver would process ~ 1 > query/second. Off by several orders of magnitude. So you are stating there is more CC authorisations per second for CC's than DNS, and if that system works so well (most of the time) why can't DNS follow that approach too? > Sorry, the details on the attack methods and vectors means you would > throw away good answers more often > than you would throw away bad answers (from the cache), but an empty > cache for a given domain is an extra vector. Very few ISPs cache websites any more even though there is tangible benefits in doing so still, but due to a variety of reasons many stopped doing caching because it was more hassle then it was worth, at present for me and others DNSSEC is more hassle then it's worth. In short web pages could be cached rather than 'throw' away good answers but they don't, why should caching DNS be given any more consideration in this respect? -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 23:43:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714783A6CAB; Thu, 7 Aug 2008 23:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 ADOVdjnu7uQE; Thu, 7 Aug 2008 23:43:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FFF93A6A39; Thu, 7 Aug 2008 23:42:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLbN-000H1M-Qy for namedroppers-data@psg.com; Fri, 08 Aug 2008 06:37:29 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLbK-000H0N-D1 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 06:37:28 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id DF0C1FF26C; Fri, 8 Aug 2008 16:37:28 +1000 (EST) Message-ID: <489BE9A2.9040608@e164.org> Date: Fri, 08 Aug 2008 16:37:22 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: David Ulevitch CC: Namedroppers Subject: Re: list policies References: <489BE047.1010100@e164.org> <489BE6BA.8050200@everydns.net> In-Reply-To: <489BE6BA.8050200@everydns.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: David Ulevitch wrote: > Duane, > > Can we get a last name please? We already have one Duane on this list > and it's hard to know who you are. Is that too much to ask? This is an > IETF mailing list, after all. In all the time I've used the internet you are the only person to care at all. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 7 23:55:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E92E3A6C0C; Thu, 7 Aug 2008 23:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 B1O0IzDR4iFe; Thu, 7 Aug 2008 23:55:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AA4C3A6B82; Thu, 7 Aug 2008 23:55:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLoZ-000IfE-HZ for namedroppers-data@psg.com; Fri, 08 Aug 2008 06:51:07 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRLoS-000Ief-ID for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 06:51:02 +0000 Received: (qmail 10787 invoked from network); 8 Aug 2008 07:39:53 -0000 Received: from s208130.ppp.asahi-net.or.jp (HELO necom830.hpcl.titech.ac.jp) (220.157.208.130) by necom830.hpcl.titech.ac.jp with SMTP; 8 Aug 2008 07:39:53 -0000 Message-ID: <489BECD1.5020001@necom830.hpcl.titech.ac.jp> Date: Fri, 08 Aug 2008 15:50:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Roy Arends CC: Paul Vixie , Namedroppers , Wouter Wijngaards Subject: Re: Additional filtering of responses References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Roy Arends wrote: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;010a.example. IN A > > ;; ANSWER SECTION: > 010a.example. 86400 IN A 192.0.2.9 > > ;; AUTHORITY SECTION: > example. 86400 IN NS 010a.example. > > ;; Query time: 3 msec > ;; SERVER: 192.0.2.10#53(192.0.2.10) > > No glue. No additional section. > > Is the address record in the answer section cached? > When cached, is 192.0.2.9 considered authoritative now for future lookups > under example? It seems to me that referral NSes should also be cached tagged by the query domain, which means 010a.example will be authoritative for future lookups on 010a.example but nothing else. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 00:08:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854373A6AD8; Fri, 8 Aug 2008 00:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 CzQDjnZ0PuwQ; Fri, 8 Aug 2008 00:08:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B22DB3A682F; Fri, 8 Aug 2008 00:08:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRM1M-000K1c-N2 for namedroppers-data@psg.com; Fri, 08 Aug 2008 07:04:20 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRM1I-000K19-Rt for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 07:04:18 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=4/r0GYqyjzITks2KGDskYp2W2iiOcdIf2RDyPLSBq/KWolU6EIt8OSix cnVyMv/+xEzVQcsdrdbfSmoDeUznPtFVUMzozgrMBOd96oip6IYth8m6o vW7Qk+K+BrnhzjH; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1218179056; x=1249715056; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20Re:=20Additional=20filtering=20of=20responses|Date:=20 Fri,=208=20Aug=202008=2009:04:18=20+0200|Message-ID:=20|To:=20Masataka=20Ohta=20|Cc:=20Namedroppers=20,=0D=0A=09Paul=20Vixie=20,=0D=0A =09Wouter=20Wijngaards=20 |MIME-Version:=201.0|In-Reply-To:=20<489BECD1.5020001@nec om830.hpcl.titech.ac.jp>|References:=20<489AD5E3.20708@nl netlabs.nl>=20<45759.1218122552@nsa.vix.com>=20=20<489BECD1.5020001@necom830.hpcl.titech.ac.jp>; bh=rICDkqDreTHapOlb2+v9IuSyBrZMR4romxn6Sze62/g=; b=zQOmfzhbHCt+mkE2uxtsEgeV88s0wDvK3EIlJ/lRejj4jm0feL/FzA+l CxoE1MynycwMPoMazdPGoY3sGikDL6EObdbQx1yLxLIeHIQZCN/Ppjs+5 o3noBoq+2I3Fb5n; X-IronPort-AV: E=Sophos;i="4.31,325,1215385200"; d="scan'208";a="4657569" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 08 Aug 2008 08:04:14 +0100 In-Reply-To: <489BECD1.5020001@necom830.hpcl.titech.ac.jp> References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <489BECD1.5020001@necom830.hpcl.titech.ac.jp> To: Masataka Ohta Cc: Namedroppers , Paul Vixie , Wouter Wijngaards Subject: Re: Additional filtering of responses MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Fri, 8 Aug 2008 09:04:18 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 08/08/2008 08:04:14 AM, Serialize complete at 08/08/2008 08:04:14 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Masataka Ohta wrote on 08/08/2008 08:50:57 AM: > Roy Arends wrote: > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612 > > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;010a.example. IN A > > > > ;; ANSWER SECTION: > > 010a.example. 86400 IN A 192.0.2.9 > > > > ;; AUTHORITY SECTION: > > example. 86400 IN NS 010a.example. > > > > ;; Query time: 3 msec > > ;; SERVER: 192.0.2.10#53(192.0.2.10) > > > > No glue. No additional section. > > > > Is the address record in the answer section cached? > > When cached, is 192.0.2.9 considered authoritative now for future lookups > > under example? > > It seems to me that referral NSes should also be cached tagged by > the query domain, which means 010a.example will be authoritative > for future lookups on 010a.example but nothing else. Okay. Where does the resolver get the address to go for lookups (other than 010a.example) under example ? Thanks Roy -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 00:08:41 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E905B3A6B0A; Fri, 8 Aug 2008 00:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.977 X-Spam-Level: * X-Spam-Status: No, score=1.977 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 p5qyvCXZdVH7; Fri, 8 Aug 2008 00:08:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEFF93A68F4; Fri, 8 Aug 2008 00:08:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRM2C-000K5m-8J for namedroppers-data@psg.com; Fri, 08 Aug 2008 07:05:12 +0000 Received: from [212.74.77.49] (helo=smtp.lon.dcn.colt.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRM28-000K5O-AC for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 07:05:10 +0000 Received: from [194.45.79.6] (quo.fra.ws.COLT.NET [212.74.79.242]) by smtp.lon.dcn.colt.net (Postfix) with ESMTP id C751F35833; Fri, 8 Aug 2008 09:05:05 +0200 (CEST) Message-Id: From: Ralf Weber To: bert hubert , Namedroppers In-Reply-To: <20080807134236.GA19024@outpost.ds9a.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Date: Fri, 8 Aug 2008 09:05:04 +0200 References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Moin! On Aug 7, 2008, at 15:42 , bert hubert wrote: > On Thu, Aug 07, 2008 at 01:00:51PM +0200, Wouter Wijngaards wrote: >> The best solution is of course DNSSEC. Crypto signatures instead of >> randomisation games. Enable DNSSEC validation now. > > Not specifically aimed at you Wouter, but it appears the most vocal =20= > people > in the DNS world are starting to suffer from "groupthink". Ok so let me state my opinion as someone who argued against DNSSEC =20 until last year hopefully does not fall into the "groupthink" theory. The reason it changed is that we, or to be more precise a customer was =20= hit by cache poisoning, and I had show up at there board and explain =20 it to them. So there question was and I raise it to the WG here: Is there a technology that can prove that the answer I am getting from =20= my DNS resolver is correct? To my limited knowledge the only answer to the above question is: Yes DNSSEC can do this. But please tell me if you know another solution. All other solutions proposed here so far only lower the chance of an =20 attacker to poison the cache. But still with a 0.0001% chance the =20 attacker might just have that lucky packet and poison your cache. So =20 why I think it is good to do countermeasures none of them can assure =20 me that I won't be hit by cache poisoning. Also as stated elsewhere here, if someone today wanted to secure DNS =20 between him and his business partners he could do it today without =20 involving anyone else but him and the business partners (and this is =20 happening). Now having played around with DNSSEC for a year now I also must say =20 that it does it's job, but with the current software and tools =20 available it's simply not ready for widespread adoption. But this is a =20= problem that can be solved, there is IMHO nothing wrong with the =20 protocol, it's the tools that don't offer a user friendly way to =20 deploy it. So people should focus on getting the tools right. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: Ralf.Weber@colt.net http://www.colt.net/ Data | Voice | Managed Services ***************************************** COLT Telecom GmbH, Herriotstra=DFe 4, 60528 Frankfurt/Main, Deutschland = * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch=E4ftsf=FChrer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 00:18:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6A63A6B3A; Fri, 8 Aug 2008 00:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 sQZ5m0luhFCw; Fri, 8 Aug 2008 00:18:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11F4B3A6C91; Fri, 8 Aug 2008 00:17:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRM9o-000KtP-AR for namedroppers-data@psg.com; Fri, 08 Aug 2008 07:13:04 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRM9k-000Ksz-C9 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 07:13:02 +0000 Received: (qmail 13189 invoked from network); 8 Aug 2008 08:01:52 -0000 Received: from s208130.ppp.asahi-net.or.jp (HELO necom830.hpcl.titech.ac.jp) (220.157.208.130) by necom830.hpcl.titech.ac.jp with SMTP; 8 Aug 2008 08:01:52 -0000 Message-ID: <489BF1F9.8060506@necom830.hpcl.titech.ac.jp> Date: Fri, 08 Aug 2008 16:12:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Roy Arends CC: Namedroppers , Paul Vixie , Wouter Wijngaards Subject: Re: Additional filtering of responses References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <489BECD1.5020001@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Roy Arends wrote: > Where does the resolver get the address to go for lookups (other than > 010a.example) under example ? Root nameservers, I'm afraid. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 00:30:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F01A3A6BEB; Fri, 8 Aug 2008 00:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 8Js47eGFABbw; Fri, 8 Aug 2008 00:30:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5529D3A6B3A; Fri, 8 Aug 2008 00:30:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMLS-000MaY-NQ for namedroppers-data@psg.com; Fri, 08 Aug 2008 07:25:06 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMLP-000MZw-7h for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 07:25:04 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 4092EFF26C; Fri, 8 Aug 2008 17:25:04 +1000 (EST) Message-ID: <489BF4C8.9000309@e164.org> Date: Fri, 08 Aug 2008 17:24:56 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Ralf Weber CC: bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ralf Weber wrote: > The reason it changed is that we, or to be more precise a customer was > hit by cache poisoning, and I had show up at there board and explain it > to them. Thanks for proving my point, people won't do anything until something happens to them personally. > Is there a technology that can prove that the answer I am getting from my DNS resolver is correct? Don't use someone else's resolver for starters, then reduce the TTL to almost nothing and the chance of being effected is greatly reduced, of course DNSSEC won't solve this problem without critical mass either so even if you deploy or utilise DNSSEC you could still be effected by cache poisoning. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 00:43:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0243C3A6963; Fri, 8 Aug 2008 00:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 WjS2hEznW4OR; Fri, 8 Aug 2008 00:43:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF88A3A68C0; Fri, 8 Aug 2008 00:43:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMXw-000OEC-9j for namedroppers-data@psg.com; Fri, 08 Aug 2008 07:38:00 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMXi-000OCx-B6 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 07:37:56 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id AC189FF26C; Fri, 8 Aug 2008 17:37:46 +1000 (EST) Message-ID: <489BF7C4.8030007@e164.org> Date: Fri, 08 Aug 2008 17:37:40 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Masataka Ohta CC: Roy Arends , Namedroppers , Paul Vixie , Wouter Wijngaards Subject: Re: Additional filtering of responses References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <489BECD1.5020001@necom830.hpcl.titech.ac.jp> <489BF1F9.8060506@necom830.hpcl.titech.ac.jp> In-Reply-To: <489BF1F9.8060506@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Masataka Ohta wrote: > Roy Arends wrote: > >> Where does the resolver get the address to go for lookups (other than >> 010a.example) under example ? > > Root nameservers, I'm afraid. Oh so this is what Verisign had in mind when they announced they were ramping up DNS response capabilities by 10 or 100 fold. -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Global Communication for the 21st Century "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 00:48:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0AA3A68C0; Fri, 8 Aug 2008 00:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 l4OlqpOSUJpc; Fri, 8 Aug 2008 00:48:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AEC63A6C89; Fri, 8 Aug 2008 00:48:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMda-000Oph-9c for namedroppers-data@psg.com; Fri, 08 Aug 2008 07:43:50 +0000 Received: from [212.74.77.49] (helo=smtp.lon.dcn.colt.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMdU-000Onu-Ue for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 07:43:48 +0000 Received: from [194.45.79.6] (quo.fra.ws.COLT.NET [212.74.79.242]) by smtp.lon.dcn.colt.net (Postfix) with ESMTP id 73F2735833; Fri, 8 Aug 2008 09:43:43 +0200 (CEST) Message-Id: From: Ralf Weber To: Duane at e164 dot org , bert hubert , Namedroppers In-Reply-To: <489BF4C8.9000309@e164.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Date: Fri, 8 Aug 2008 09:43:42 +0200 References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489BF4C8.9000309@e164.org> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Moin! On Aug 8, 2008, at 09:24 , Duane at e164 dot org wrote: > Ralf Weber wrote: > >> The reason it changed is that we, or to be more precise a customer =20= >> was >> hit by cache poisoning, and I had show up at there board and =20 >> explain it >> to them. > > Thanks for proving my point, people won't do anything until something > happens to them personally. Well this might happen more often now when the hackers do code that =20 utilises Dan Kaminskys findings. And it just need to happen to the =20 "right" people, as we see with IPv6 now that which is at least getting =20= some traction after governments endorsed it. >> Is there a technology that can prove that the answer I am getting =20 >> from my DNS resolver is correct? > > Don't use someone else's resolver for starters, Hmm shall I stop offering resolving service to our customers, so that =20= they can have their own ;-). > then reduce the TTL to > almost nothing and the chance of being effected is greatly reduced, of > course DNSSEC won't solve this problem without critical mass either so > even if you deploy or utilise DNSSEC you could still be effected by > cache poisoning. True, but if A and B agree on using it they can at least secure the =20 resolving of A and Bs domains, and if C, D and E join them when a TLD =20= operator offers DNSSEC domains they will be also secured. So it will =20 get better the more people do it, and the of non DNSSEC servers to =20 speak to DNSSEC servers is at least defined (unless IPv6). So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: Ralf.Weber@colt.net http://www.colt.net/ Data | Voice | Managed Services ***************************************** COLT Telecom GmbH, Herriotstra=DFe 4, 60528 Frankfurt/Main, Deutschland = * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch=E4ftsf=FChrer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 00:56:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7B03A6975; Fri, 8 Aug 2008 00:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 k5zGlKuwvLhl; Fri, 8 Aug 2008 00:56:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F9A23A693E; Fri, 8 Aug 2008 00:56:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMld-000PuI-D8 for namedroppers-data@psg.com; Fri, 08 Aug 2008 07:52:09 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMlQ-000Psc-Mu for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 07:51:59 +0000 Received: from [192.168.100.28] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 1CB4CC2DA3; Fri, 8 Aug 2008 08:51:49 +0100 (BST) Date: Fri, 08 Aug 2008 08:55:18 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Duane at e164 dot org , Ralf Weber cc: bert hubert , Namedroppers , Alex Bligh Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Message-ID: <09B9BDC1BA78A4C82CC20893@nimrod.local> In-Reply-To: <489BF4C8.9000309@e164.org> References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489BF4C8.9000309@e164.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 8 August 2008 17:24:56 +1000 Duane at e164 dot org wrote: >> Is there a technology that can prove that the answer I am getting from >> my DNS resolver is correct? > > Don't use someone else's resolver for starters, then reduce the TTL to > almost nothing and the chance of being effected is greatly reduced, of > course DNSSEC won't solve this problem without critical mass either so > even if you deploy or utilise DNSSEC you could still be effected by > cache poisoning. That just goes to prove Ralf's point. a) DNSSEC may be an ugly pig, but it's the only technology available today that PROVES the answer is correct (rather than 'greatly reduces' the chance of it being wrong) b) Like most security measures, both sides need to be using it. It does little in practice at the moment because it isn't deployed (no critical mass, as you put it). This is not an argument not to deploy it ("my gun does not work because it is not loaded, therefore do not load it because it does not work"); if anything, it's the opposite. Alex -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 01:09:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13EC03A68FF; Fri, 8 Aug 2008 01:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 NXyLb4aD78Yt; Fri, 8 Aug 2008 01:09:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4F083A6963; Fri, 8 Aug 2008 01:09:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMtL-0001CT-VF for namedroppers-data@psg.com; Fri, 08 Aug 2008 08:00:07 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRMtG-0001AY-TK for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 08:00:05 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KRMsy-0001VB-FF; Fri, 08 Aug 2008 09:59:44 +0200 Received: from fweimer by bfk.de with local id 1KRMt5-0006yu-AQ; Fri, 08 Aug 2008 09:59:51 +0200 To: Masataka Ohta Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: correction! Re: The math of RFC3833.2.2-spoofing a randomising source port resolver References: <20080801124038.GA5994@outpost.ds9a.nl> <20080804104502.GA32568@outpost.ds9a.nl> <4896FA14.2030103@necom830.hpcl.titech.ac.jp> <82hca0khmq.fsf@mid.bfk.de> <18763.1217859761@nsa.vix.com> <48976E0A.7020603@necom830.hpcl.titech.ac.jp> <82vdye7cpx.fsf@mid.bfk.de> <489A4742.6040002@necom830.hpcl.titech.ac.jp> From: Florian Weimer Date: Fri, 08 Aug 2008 09:59:51 +0200 Message-ID: <82k5esym14.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Masataka Ohta: >> Or you cache referrals without storing any name server name. >> Conceptually, this seems to be the much simpler approach. > > If you mean the cached referral is tagged with the original query, > the complexity is no different from mine. No, after detecting a referral, you record the addresses in the additional section and store it at the name of the zone. You don't associate it with any name server names. This means that the data can only be used for this referral, and nowhere else. This prevents cache insertion through glue records. You can even use address information from out-of-zone glue to locate servers (provided that the upstream server filters out-of-zone data properly, which is probably something you cannot assume). > Paul Vixie wrote: > >> i don't think so, since nameservers can be renumbered without being >> renamed. > > TTL, which must be properly configured by zone administrators, takes > care of it. Agreed. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 01:31:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8013E3A6CBD; Fri, 8 Aug 2008 01:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 VesTTfEtYkNA; Fri, 8 Aug 2008 01:31:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A42B23A6C9C; Fri, 8 Aug 2008 01:31:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRNJv-0004hR-QB for namedroppers-data@psg.com; Fri, 08 Aug 2008 08:27:35 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRNJs-0004f3-Dg for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 08:27:33 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 2475EFF26C; Fri, 8 Aug 2008 18:27:34 +1000 (EST) Message-ID: <489C0370.4080502@e164.org> Date: Fri, 08 Aug 2008 18:27:28 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Ralf Weber CC: bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489BF4C8.9000309@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ralf Weber wrote: > Well this might happen more often now when the hackers do code that > utilises Dan Kaminskys findings. And it just need to happen to the > "right" people, as we see with IPv6 now that which is at least getting > some traction after governments endorsed it. Either that or they all migrated to recursors that weren't affected and so that would mitigate any migration to DNSSEC. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 01:32:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5B43A6B3A; Fri, 8 Aug 2008 01:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, 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 jL9tjJSXlZuY; Fri, 8 Aug 2008 01:32:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 87A1C3A6C9C; Fri, 8 Aug 2008 01:32:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRNI7-0004QG-Jv for namedroppers-data@psg.com; Fri, 08 Aug 2008 08:25:43 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRNI2-0004Ns-UA for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 08:25:41 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 85D88FF271; Fri, 8 Aug 2008 18:25:40 +1000 (EST) Message-ID: <489C02FC.3010904@e164.org> Date: Fri, 08 Aug 2008 18:25:32 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Alex Bligh CC: Ralf Weber , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489BF4C8.9000309@e164.org> <09B9BDC1BA78A4C82CC20893@nimrod.local> In-Reply-To: <09B9BDC1BA78A4C82CC20893@nimrod.local> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE7F7101EC72E72A673234889" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE7F7101EC72E72A673234889 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex Bligh wrote: Ignore the fact of what DNSSEC can do, ignore even what it can't do, the bigger hurdle to getting most people to deploy it will be the ease at which they can set it up, other external factors will occur that may change the rate of deployment but why people aren't actively trying to make the process as simple as possible is beyond me. --=20 Best regards, Duane --------------enigE7F7101EC72E72A673234889 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFInAL8EpWoZMmo/c8RAqaSAJ9cowlxQB5dg9IviD/gd3qQVVyTywCfeyFT U17tsZzwiiSx9SEVz6FSZAk= =ox/F -----END PGP SIGNATURE----- --------------enigE7F7101EC72E72A673234889-- -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 01:56:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CBFD3A6CBB; Fri, 8 Aug 2008 01:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 ovW4bOngvhMc; Fri, 8 Aug 2008 01:56:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 941553A6CAA; Fri, 8 Aug 2008 01:56:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRNff-0007A6-90 for namedroppers-data@psg.com; Fri, 08 Aug 2008 08:50:03 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRNfb-000790-4i for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 08:50:01 +0000 Received: (qmail 52843 invoked from network); 8 Aug 2008 08:49:57 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Aug 2008 08:49:57 -0000 Date: Fri, 08 Aug 2008 10:49:57 +0200 (CEST) Message-Id: <20080808.104957.74720707.sthaug@nethelp.no> To: duane@e164.org Cc: denic@eng.colt.net, bert.hubert@netherlabs.nl, namedroppers@ops.ietf.org Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS From: sthaug@nethelp.no In-Reply-To: <489C0370.4080502@e164.org> References: <489BF4C8.9000309@e164.org> <489C0370.4080502@e164.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > Well this might happen more often now when the hackers do code that > > utilises Dan Kaminskys findings. And it just need to happen to the > > "right" people, as we see with IPv6 now that which is at least getting > > some traction after governments endorsed it. > > Either that or they all migrated to recursors that weren't affected and > so that would mitigate any migration to DNSSEC. Your "recursors that weren't affected" don't exist. Using more entropy (by using query ID randomization, port randomzation etc) reduces the probability of spoofing - but as has been pointed out many times here, this is not a *solution*. It mitigates the problem, it doesn't solve it. Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 01:58:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CCB3A6CB2; Fri, 8 Aug 2008 01:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.425 X-Spam-Level: X-Spam-Status: No, score=0.425 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, 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 KTsxtg1-HAss; Fri, 8 Aug 2008 01:58:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 753323A6C89; Fri, 8 Aug 2008 01:58:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRNjw-0007bi-Gv for namedroppers-data@psg.com; Fri, 08 Aug 2008 08:54:28 +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 ) id 1KRNjo-0007al-B3 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 08:54:24 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KRNjl-00083E-5S for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 10:54:17 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id EE77E4B44D; Fri, 8 Aug 2008 10:54:30 +0200 (CEST) Date: Fri, 8 Aug 2008 10:54:30 +0200 From: bert hubert To: sthaug@nethelp.no Cc: duane@e164.org, denic@eng.colt.net, namedroppers@ops.ietf.org Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS Message-ID: <20080808085430.GC6566@outpost.ds9a.nl> References: <489BF4C8.9000309@e164.org> <489C0370.4080502@e164.org> <20080808.104957.74720707.sthaug@nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080808.104957.74720707.sthaug@nethelp.no> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 08, 2008 at 10:49:57AM +0200, sthaug@nethelp.no wrote: > probability of spoofing - but as has been pointed out many times here, > this is not a *solution*. It mitigates the problem, it doesn't solve > it. Mitigation to the point where it will take a million years is effectively a solution against spoofing. People with sufficiently powerful computers could also break DNSSEC security. This is equally likely to take a million years, although I haven't studied the effective keylenghts that fit in DNS. I'll repeat the mantra that DNSSEC protects against more than spoofing. 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:17:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9754D3A6B45; Fri, 8 Aug 2008 02:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 MEtlVe17gGhM; Fri, 8 Aug 2008 02:17:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B939B3A690C; Fri, 8 Aug 2008 02:17:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRO1h-0009UO-Sc for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:12:49 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRO1e-0009Tt-7s for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:12:47 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id AAFE6FF271; Fri, 8 Aug 2008 19:12:43 +1000 (EST) Message-ID: <489C0E08.3040406@e164.org> Date: Fri, 08 Aug 2008 19:12:40 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: Namedroppers , Mark Andrews , Paul Vixie , bert hubert Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. References: <489BE047.1010100@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ond=C5=99ej Sur=C3=BD wrote: > I know that it does add more burder of shoulder of any sysadmin, but > is it really so much - add a cron job and some monitoring script and > you are done? at some point you load the beasts of burden up with so much work that one extra piece of straw is all that is needed or takes to break the poor animals back. --=20 Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:22:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B1D3A6C66; Fri, 8 Aug 2008 02:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.377 X-Spam-Level: **** X-Spam-Status: No, score=4.377 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 U5493o+FVHe0; Fri, 8 Aug 2008 02:22:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5F7E3A6C9E; Fri, 8 Aug 2008 02:22:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRO7D-000AAO-56 for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:18:31 +0000 Received: from [64.233.182.187] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRO78-000A9U-2b for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:18:29 +0000 Received: by nf-out-0910.google.com with SMTP id g13so799346nfb.11 for ; Fri, 08 Aug 2008 02:18:25 -0700 (PDT) Received: by 10.210.66.13 with SMTP id o13mr5162482eba.193.1218187104314; Fri, 08 Aug 2008 02:18:24 -0700 (PDT) Received: by 10.210.121.1 with HTTP; Fri, 8 Aug 2008 02:18:24 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 11:18:24 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: "Duane at e164 dot org" Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. Cc: Namedroppers , "Mark Andrews" , "Paul Vixie" , "bert hubert" In-Reply-To: <489C0E08.3040406@e164.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: MjAwOC84LzggRHVhbmUgYXQgZTE2NCBkb3Qgb3JnIDxkdWFuZUBlMTY0Lm9yZz46Cj4gT25kxZll aiBTdXLDvSB3cm90ZToKPgo+PiBJIGtub3cgdGhhdCBpdCBkb2VzIGFkZCBtb3JlIGJ1cmRlciBv ZiBzaG91bGRlciBvZiBhbnkgc3lzYWRtaW4sIGJ1dAo+PiBpcyBpdCByZWFsbHkgc28gbXVjaCAt IGFkZCBhIGNyb24gam9iIGFuZCBzb21lIG1vbml0b3Jpbmcgc2NyaXB0IGFuZAo+PiB5b3UgYXJl IGRvbmU/Cj4KPiBhdCBzb21lIHBvaW50IHlvdSBsb2FkIHRoZSBiZWFzdHMgb2YgYnVyZGVuIHVw IHdpdGggc28gbXVjaCB3b3JrIHRoYXQKPiBvbmUgZXh0cmEgcGllY2Ugb2Ygc3RyYXcgaXMgYWxs IHRoYXQgaXMgbmVlZGVkIG9yIHRha2VzIHRvIGJyZWFrIHRoZQo+IHBvb3IgYW5pbWFscyBiYWNr LgoKQnV0IG5vdyBpcyBzdGFydHMgdG8gYmUgb25seSByaGV0aG9yaWNhbCBkaXNjdXNzaW9uLiAg SGF2ZSB5b3UgY2FsY3VsYXRlZApob3cgbXVjaCBhZGRpdGlvbmFsIHdvcmsgaXQgd291bGQgYmUg Zm9yIHlvdT8gIFVzaW5nIHJpZ2h0IHRvb2xzIGZvciBpdAoobGlrZSBkbnNzZWMtdG9vbHNbMV0g b3IgWktUWzJdKT8KCk9uZHJlagoxLiB3d3cuZG5zc2VjLXRvb2xzLm9yZwoyLiBodHRwOi8vd3d3 Lmh6bmV0LmRlL2Rucy96a3QvCi0tIAogT25kxZllaiBTdXLDvQogdGVjaG5pY2vDvSDFmWVkaXRl bC9DaGllZiBUZWNobmljYWwgT2ZmaWNlcgogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KIENaLk5JQywgei5zLnAuby4gLS0gLmN6IGRvbWFpbiByZWdpc3RyeQogQW1l cmlja8OhIDIzLDEyMCAwMCBQcmFoYSAyLEN6ZWNoIFJlcHVibGljCiBtYWlsdG86b25kcmVqLnN1 cnlAbmljLmN6IGh0dHA6Ly9uaWMuY3ovCiBzaXA6b25kcmVqLnN1cnlAbmljLmN6IHRlbDorNDIw LjIyMjc0NTExMAogbW9iOis0MjAuNzM5MDEzNjk5IGZheDorNDIwLjIyMjc0NTExMgogLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:31:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2EC3A6CB5; Fri, 8 Aug 2008 02:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 bcWx1WEcwxVj; Fri, 8 Aug 2008 02:31:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70D403A6CA3; Fri, 8 Aug 2008 02:31:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROEe-000BI5-8m for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:26:12 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROEa-000BHI-C1 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:26:09 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id C21EDFF26C; Fri, 8 Aug 2008 19:26:05 +1000 (EST) Message-ID: <489C112A.8000306@e164.org> Date: Fri, 08 Aug 2008 19:26:02 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , Namedroppers , Mark Andrews , Paul Vixie , bert hubert Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ond=C5=99ej Sur=C3=BD wrote: > 2008/8/8 Duane at e164 dot org : >> Ond=C5=99ej Sur=C3=BD wrote: >> >>> I know that it does add more burder of shoulder of any sysadmin, but >>> is it really so much - add a cron job and some monitoring script and >>> you are done? >> at some point you load the beasts of burden up with so much work that >> one extra piece of straw is all that is needed or takes to break the >> poor animals back. >=20 > But now is starts to be only rhethorical discussion. Have you calculat= ed > how much additional work it would be for you? Using right tools for it= > (like dnssec-tools[1] or ZKT[2])? If I have to go out of my way to learn about this stuff you again have shown it is neither straight forward nor simple to do. Until I can type a single command (or no commands) that sets everything up I really can't be bothered, since there is no perceived benefit in doing so for me. --=20 Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:34:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC10A3A6C31; Fri, 8 Aug 2008 02:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ztRvhwjxBuWY; Fri, 8 Aug 2008 02:34:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D715F3A68B3; Fri, 8 Aug 2008 02:34:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROIO-000Boy-Aa for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:30:04 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROII-000Bmo-14 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:30:00 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 02762FF26C; Fri, 8 Aug 2008 19:29:55 +1000 (EST) Message-ID: <489C1211.3030207@e164.org> Date: Fri, 08 Aug 2008 19:29:53 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: bert hubert CC: sthaug@nethelp.no, denic@eng.colt.net, namedroppers@ops.ietf.org Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489BF4C8.9000309@e164.org> <489C0370.4080502@e164.org> <20080808.104957.74720707.sthaug@nethelp.no> <20080808085430.GC6566@outpost.ds9a.nl> In-Reply-To: <20080808085430.GC6566@outpost.ds9a.nl> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bert hubert wrote: > On Fri, Aug 08, 2008 at 10:49:57AM +0200, sthaug@nethelp.no wrote: > >> probability of spoofing - but as has been pointed out many times here, >> this is not a *solution*. It mitigates the problem, it doesn't solve >> it. > > Mitigation to the point where it will take a million years is effectively a > solution against spoofing. > > People with sufficiently powerful computers could also break DNSSEC > security. Or knowledge to factor asymmetric keys in a way no one else has thought of would be able to perpetrate a DNSSEC attack much easier again. Currently it's assumed that quantum computing would be needed to solve this problem, however people assumed md5/sha1 didn't suffer any flaws until it came out they were vulnerable. Brute force is merely the slowest way to break keys, not the only way. As for CPU hours needed to brute force keys: http://en.wikipedia.org/wiki/RSA_Factoring_Challenge A tad less than a million ;) -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:36:29 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2653A6CB5; Fri, 8 Aug 2008 02:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.127 X-Spam-Level: **** X-Spam-Status: No, score=4.127 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 L-HGrSAP1gqZ; Fri, 8 Aug 2008 02:36:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4580B3A6CF9; Fri, 8 Aug 2008 02:36:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROKn-000CAN-0U for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:32:33 +0000 Received: from [64.233.182.184] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROKj-000C9s-Bw for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:32:31 +0000 Received: by nf-out-0910.google.com with SMTP id g13so804170nfb.11 for ; Fri, 08 Aug 2008 02:32:28 -0700 (PDT) Received: by 10.210.11.13 with SMTP id 13mr5191929ebk.142.1218187947943; Fri, 08 Aug 2008 02:32:27 -0700 (PDT) Received: by 10.210.121.1 with HTTP; Fri, 8 Aug 2008 02:32:27 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 11:32:27 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: "Duane at e164 dot org" Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. Cc: Namedroppers , "Mark Andrews" , "Paul Vixie" , "bert hubert" In-Reply-To: <489C112A.8000306@e164.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: MjAwOC84LzggRHVhbmUgYXQgZTE2NCBkb3Qgb3JnIDxkdWFuZUBlMTY0Lm9yZz46Cj4gT25kxZll aiBTdXLDvSB3cm90ZToKPj4gMjAwOC84LzggRHVhbmUgYXQgZTE2NCBkb3Qgb3JnIDxkdWFuZUBl MTY0Lm9yZz46Cj4+PiBPbmTFmWVqIFN1csO9IHdyb3RlOgo+Pj4KPj4+PiBJIGtub3cgdGhhdCBp dCBkb2VzIGFkZCBtb3JlIGJ1cmRlciBvZiBzaG91bGRlciBvZiBhbnkgc3lzYWRtaW4sIGJ1dAo+ Pj4+IGlzIGl0IHJlYWxseSBzbyBtdWNoIC0gYWRkIGEgY3JvbiBqb2IgYW5kIHNvbWUgbW9uaXRv cmluZyBzY3JpcHQgYW5kCj4+Pj4geW91IGFyZSBkb25lPwo+Pj4gYXQgc29tZSBwb2ludCB5b3Ug bG9hZCB0aGUgYmVhc3RzIG9mIGJ1cmRlbiB1cCB3aXRoIHNvIG11Y2ggd29yayB0aGF0Cj4+PiBv bmUgZXh0cmEgcGllY2Ugb2Ygc3RyYXcgaXMgYWxsIHRoYXQgaXMgbmVlZGVkIG9yIHRha2VzIHRv IGJyZWFrIHRoZQo+Pj4gcG9vciBhbmltYWxzIGJhY2suCj4+Cj4+IEJ1dCBub3cgaXMgc3RhcnRz IHRvIGJlIG9ubHkgcmhldGhvcmljYWwgZGlzY3Vzc2lvbi4gIEhhdmUgeW91IGNhbGN1bGF0ZWQK Pj4gaG93IG11Y2ggYWRkaXRpb25hbCB3b3JrIGl0IHdvdWxkIGJlIGZvciB5b3U/ICBVc2luZyBy aWdodCB0b29scyBmb3IgaXQKPj4gKGxpa2UgZG5zc2VjLXRvb2xzWzFdIG9yIFpLVFsyXSk/Cj4K PiBJZiBJIGhhdmUgdG8gZ28gb3V0IG9mIG15IHdheSB0byBsZWFybiBhYm91dCB0aGlzIHN0dWZm IHlvdSBhZ2FpbiBoYXZlCj4gc2hvd24gaXQgaXMgbmVpdGhlciBzdHJhaWdodCBmb3J3YXJkIG5v ciBzaW1wbGUgdG8gZG8uCj4KPiBVbnRpbCBJIGNhbiB0eXBlIGEgc2luZ2xlIGNvbW1hbmQgKG9y IG5vIGNvbW1hbmRzKSB0aGF0IHNldHMgZXZlcnl0aGluZwo+IHVwIEkgcmVhbGx5IGNhbid0IGJl IGJvdGhlcmVkLCBzaW5jZSB0aGVyZSBpcyBubyBwZXJjZWl2ZWQgYmVuZWZpdCBpbgo+IGRvaW5n IHNvIGZvciBtZS4KClNvIHdoZW4geW91IGluc3RhbGxlZCB5b3VyIEROUyBzZXJ2ZXIgaW5mcmFz dHJ1Y3R1cmUsIHdhcyBpdCBqdXN0CnNvbWUgIm1hZ2ljIiBjb21tYW5kIHdoaWNoIGNhdXNlZCBh bGwgeW91ciBkb21haW4gbmFtZXMgdG8gYmUgc2VydmVyCmJ5IHRoYXQgc2VydmVycz8gIE9yIGRp ZCB5b3UgaGF2ZSB0byBtYWtlIGNoYW5nZXMgdG8gY29uZmlnIGZpbGVzLApnZW5lcmF0ZSBUU0lH IGtleXMsIGNvbmZpZ3VyZSBwcmltYXJ5LCBjb25maWd1cmUgc2xhdmVzLCBhZGQgem9uZXMKdG8g Y29uZmlnIGZpbGUuLi4KCkkgc2VlIGtpbmQgb2YgYW5hbG9neSBoZXJlLiAgQXZhaWxhYmxlIHRv b2xzIGFyZSBiaXQgcm91Z2ggYXQgdGhpcyB0aW1lLApidXQgaXQncyBtYWduaXR1dGVkIGJldHRl ciB0aGF0IGl0IHdhcyBoYWxmIGEgeWVhciBhZ28uCgpPbmRyZWouCi0tIAogT25kxZllaiBTdXLD vQogdGVjaG5pY2vDvSDFmWVkaXRlbC9DaGllZiBUZWNobmljYWwgT2ZmaWNlcgogLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIENaLk5JQywgei5zLnAuby4gLS0gLmN6 IGRvbWFpbiByZWdpc3RyeQogQW1lcmlja8OhIDIzLDEyMCAwMCBQcmFoYSAyLEN6ZWNoIFJlcHVi bGljCiBtYWlsdG86b25kcmVqLnN1cnlAbmljLmN6IGh0dHA6Ly9uaWMuY3ovCiBzaXA6b25kcmVq LnN1cnlAbmljLmN6IHRlbDorNDIwLjIyMjc0NTExMAogbW9iOis0MjAuNzM5MDEzNjk5IGZheDor NDIwLjIyMjc0NTExMgogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:42:27 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70A73A68FF; Fri, 8 Aug 2008 02:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 pGufrcIvK46Y; Fri, 8 Aug 2008 02:42:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C18C3A68C0; Fri, 8 Aug 2008 02:42:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROQW-000CzN-Ir for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:38:28 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROQS-000CyT-L7 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:38:26 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 692ADFF26C; Fri, 8 Aug 2008 19:38:22 +1000 (EST) Message-ID: <489C140C.60205@e164.org> Date: Fri, 08 Aug 2008 19:38:20 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: Namedroppers , Mark Andrews , Paul Vixie , bert hubert Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ond=C5=99ej Sur=C3=BD wrote: > So when you installed your DNS server infrastructure, was it just > some "magic" command which caused all your domain names to be server > by that servers? Or did you have to make changes to config files, > generate TSIG keys, configure primary, configure slaves, add zones > to config file... apt-get scripts either prompt for more information or pre-config nearly everything out of the box. > I see kind of analogy here. Available tools are bit rough at this time= , > but it's magnituted better that it was half a year ago. What was, is meaningless to those that don't know or care, what is, is all that matters if you are trying to sell DNSSEC to the unwashed masses that aren't drinking the koolaid. --=20 Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:44:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2455E3A6B1F; Fri, 8 Aug 2008 02:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, 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 p-neJJNJ03IX; Fri, 8 Aug 2008 02:44:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 350213A6850; Fri, 8 Aug 2008 02:44:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRORw-000DDv-Kn for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:39:56 +0000 Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRORs-000DD5-R7 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:39:54 +0000 Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KRORo-0007mo-Ni; Fri, 08 Aug 2008 11:39:48 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 9A94C7E1F81; Fri, 8 Aug 2008 11:39:48 +0200 (CEST) Date: Fri, 8 Aug 2008 11:39:48 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: Additional filtering of responses Message-ID: <20080808093948.GA25373@unknown.office.denic.de> References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 07, 2008 at 06:32:35PM +0200, Roy Arends wrote: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 note: neither RD nor RA, so this is a response from an authoritative server. > ;; QUESTION SECTION: > ;010a.example. IN A > > ;; ANSWER SECTION: > 010a.example. 86400 IN A 192.0.2.9 > > ;; AUTHORITY SECTION: > example. 86400 IN NS 010a.example. > > ;; Query time: 3 msec > ;; SERVER: 192.0.2.10#53(192.0.2.10) > > No glue. No additional section. There's nothing to glue here anyway. > Is the address record in the answer section cached? > When cached, is 192.0.2.9 considered authoritative now for future lookups > under example? The question is whether "recursive servers" should continue to believe the NS RRSet in the authority section more than what they had learned by referral. Insofar your question has two parts: 1) should the NS RR in the authority section be used for further lookups within the example domain? 2) If "yes" or the referral already had the same data, should "192.0.2.9" be used as an address no matter what the referral had provided as additional information (and, this time, originating from glue)? If you say "no" to the first question, given all the parent/child inconsistencies, I'd be scared by the operational effects of such a paradigm shift. > Will that NS record ever expire if a query is send once a day ? This question of "auth server lock in" has been brought up by Antoin a couple of times and is probably independent of the current discussion. We know it "should not happen". -Peter -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:50:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B6B3A6CA3; Fri, 8 Aug 2008 02:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 4Vky0mJhTRrn; Fri, 8 Aug 2008 02:50:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 982763A6407; Fri, 8 Aug 2008 02:50:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROYe-000EBt-SM for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:46:52 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROYb-000EBU-Cq for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:46:51 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id E4C3EFF26C; Fri, 8 Aug 2008 19:46:47 +1000 (EST) Message-ID: <489C1605.2040408@e164.org> Date: Fri, 08 Aug 2008 19:46:45 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: namedroppers@ops.ietf.org Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489BF4C8.9000309@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ond=C5=99ej Sur=C3=BD wrote: > Did you imagined how would this impact root and tld servers (well and > registrars and others) servers > if everybody would do this? I highly doubt everyone will do this, then again everyone keeps going on about end to end verification and the end user talking directly to authority name servers would get rid of the whole issue over cache poisoning altogether, wouldn't mitigate ISP attacks, but then again Paul Vixie wasn't looking to fight that battle in a previous email thread. Web caches/proxies for the most part have gone away, site owners that do large amounts of hits didn't bemoan how bad that was, why do we still cling to the notion that we must at all cost use DNS caches? --=20 Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 02:56:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DDCE3A6CB4; Fri, 8 Aug 2008 02:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.752 X-Spam-Level: **** X-Spam-Status: No, score=4.752 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_ASCII0=1.5, 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 DzH3PDC60hxM; Fri, 8 Aug 2008 02:56:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0555C3A6C9E; Fri, 8 Aug 2008 02:56:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROdq-000EvS-C8 for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:52:14 +0000 Received: from [64.233.182.185] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROdl-000Eul-Q5 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:52:12 +0000 Received: by nf-out-0910.google.com with SMTP id g13so810451nfb.11 for ; Fri, 08 Aug 2008 02:52:08 -0700 (PDT) Received: by 10.210.58.17 with SMTP id g17mr5206245eba.190.1218189128291; Fri, 08 Aug 2008 02:52:08 -0700 (PDT) Received: by 10.210.121.1 with HTTP; Fri, 8 Aug 2008 02:52:08 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 11:52:08 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: "Duane at e164 dot org" Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. Cc: Namedroppers , "Mark Andrews" , "Paul Vixie" , "bert hubert" In-Reply-To: <489C140C.60205@e164.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> <489C140C.60205@e164.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: MjAwOC84LzggRHVhbmUgYXQgZTE2NCBkb3Qgb3JnIDxkdWFuZUBlMTY0Lm9yZz46Cj4gT25kxZll aiBTdXLDvSB3cm90ZToKPgo+PiBTbyB3aGVuIHlvdSBpbnN0YWxsZWQgeW91ciBETlMgc2VydmVy IGluZnJhc3RydWN0dXJlLCB3YXMgaXQganVzdAo+PiBzb21lICJtYWdpYyIgY29tbWFuZCB3aGlj aCBjYXVzZWQgYWxsIHlvdXIgZG9tYWluIG5hbWVzIHRvIGJlIHNlcnZlcgo+PiBieSB0aGF0IHNl cnZlcnM/ICBPciBkaWQgeW91IGhhdmUgdG8gbWFrZSBjaGFuZ2VzIHRvIGNvbmZpZyBmaWxlcywK Pj4gZ2VuZXJhdGUgVFNJRyBrZXlzLCBjb25maWd1cmUgcHJpbWFyeSwgY29uZmlndXJlIHNsYXZl cywgYWRkIHpvbmVzCj4+IHRvIGNvbmZpZyBmaWxlLi4uCj4KPiBhcHQtZ2V0IHNjcmlwdHMgZWl0 aGVyIHByb21wdCBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvciBwcmUtY29uZmlnIG5lYXJseQo+IGV2 ZXJ5dGhpbmcgb3V0IG9mIHRoZSBib3guCgpObywgaXQgZG9lc24ndC4gIEl0IGp1c3QgYWRkIHNv bWUgcHJlY29uZmlndXJhdGlvbiBmb3IgckROUywgYnV0IGl0IGRvZXNuJ3QKc2V0dXAgeW91ciB6 b25lcy4gIFlvdSBoYXZlIHRvIGFkZCB0aGVtIG1hbnVhbGx5LiAgU2FtZSB3aXRoIFRTSUcsIHNs YXZlcywKZXRjLgoKPj4gSSBzZWUga2luZCBvZiBhbmFsb2d5IGhlcmUuICBBdmFpbGFibGUgdG9v bHMgYXJlIGJpdCByb3VnaCBhdCB0aGlzIHRpbWUsCj4+IGJ1dCBpdCdzIG1hZ25pdHV0ZWQgYmV0 dGVyIHRoYXQgaXQgd2FzIGhhbGYgYSB5ZWFyIGFnby4KPgo+IFdoYXQgd2FzLCBpcyBtZWFuaW5n bGVzcyB0byB0aG9zZSB0aGF0IGRvbid0IGtub3cgb3IgY2FyZSwgd2hhdCBpcywgaXMKPiBhbGwg dGhhdCBtYXR0ZXJzIGlmIHlvdSBhcmUgdHJ5aW5nIHRvIHNlbGwgRE5TU0VDIHRvIHRoZSB1bndh c2hlZCBtYXNzZXMKPiB0aGF0IGFyZW4ndCBkcmlua2luZyB0aGUga29vbGFpZC4KCldlbGwsIHdl IGRvbid0IG5lZWQgdG8gc2VsbCBpdCB0byBtYXNzZXMuICBXZSBqdXN0IG5lZWQgdG8gZWR1Y2F0 ZWQgcmVnaXN0cmFycywKSVNQcyBhbmQgYmlnIHpvbmUgaG9zdGVycywgd2hlcmUgcGVvcGxlIHdp dGggKGF0IGxlYXN0IHNvbWUpIGNsdWUgd29ya3MuCkFuZCB0aGF0J3Mgc29tZXRoaW5nIHdoYXQg d2UgYXJlIHdvcmtpbmcgb24uCgpPbmRyZWoKLS0gCiBPbmTFmWVqIFN1csO9CiB0ZWNobmlja8O9 IMWZZWRpdGVsL0NoaWVmIFRlY2huaWNhbCBPZmZpY2VyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQogQ1ouTklDLCB6LnMucC5vLiAtLSAuY3ogZG9tYWluIHJlZ2lz dHJ5CiBBbWVyaWNrw6EgMjMsMTIwIDAwIFByYWhhIDIsQ3plY2ggUmVwdWJsaWMKIG1haWx0bzpv bmRyZWouc3VyeUBuaWMuY3ogaHR0cDovL25pYy5jei8KIHNpcDpvbmRyZWouc3VyeUBuaWMuY3og dGVsOis0MjAuMjIyNzQ1MTEwCiBtb2I6KzQyMC43MzkwMTM2OTkgZmF4Ois0MjAuMjIyNzQ1MTEy CiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo= -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 03:00:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41143A6CF0; Fri, 8 Aug 2008 03:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 NfWX7s2pxbWP; Fri, 8 Aug 2008 03:00:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB3B13A6BB9; Fri, 8 Aug 2008 03:00:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROgg-000FLS-BF for namedroppers-data@psg.com; Fri, 08 Aug 2008 09:55:10 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KROgc-000FKh-UW for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 09:55:08 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 1AFB2FF272; Fri, 8 Aug 2008 19:55:03 +1000 (EST) Message-ID: <489C17F5.8030405@e164.org> Date: Fri, 08 Aug 2008 19:55:01 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: Namedroppers , Mark Andrews , Paul Vixie , bert hubert Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> <489C140C.60205@e164.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ond=C5=99ej Sur=C3=BD wrote: > Well, we don't need to sell it to masses. We just need to educated reg= istrars, > ISPs and big zone hosters, where people with (at least some) clue works= =2E > And that's something what we are working on. I wish you well on your endeavour, I've said my piece but so far no one has convinced me over DNSSEC to date. Also you are assuming I don't have anything to do with administering a large number of zones, but that's ok :) --=20 Best regards, Duane -- 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: From dnserics@grcontrols.com Fri Aug 8 03:17:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5CE3A6ACC for ; Fri, 8 Aug 2008 03:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.19 X-Spam-Level: X-Spam-Status: No, score=-87.19 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, HOST_EQ_RU=0.875, HTML_EXTRA_CLOSE=2.809, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, USER_IN_WHITELIST=-100] 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 lBml-BBtQLa3 for ; Fri, 8 Aug 2008 03:17:57 -0700 (PDT) Received: from MS-81-107.dyn-ip.SPb.SkyLink.RU (MS-81-107.dyn-ip.SPb.SkyLink.RU [212.129.107.81]) by core3.amsl.com (Postfix) with SMTP id E8D4D3A6B91 for ; Fri, 8 Aug 2008 03:17:55 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080808053604.4425.qmail@MS-81-107.dyn-ip.SPb.SkyLink.RU> To: Subject: Internet Explorer 7 From: admin@microsoft.com MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Date: Fri, 8 Aug 2008 03:17:55 -0700 (PDT)
Download the latest version!

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From owner-namedroppers@ops.ietf.org Fri Aug 8 03:25:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABAA3A6CEB; Fri, 8 Aug 2008 03:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.151 X-Spam-Level: X-Spam-Status: No, score=-101.151 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 s6KgFv9a8CUp; Fri, 8 Aug 2008 03:25:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C49593A6CAD; Fri, 8 Aug 2008 03:25:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRP37-000IY7-4W for namedroppers-data@psg.com; Fri, 08 Aug 2008 10:18:21 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRP2s-000IWg-Th for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 10:18:17 +0000 Received: from [IPv6:2001:7b8:206:1:21b:63ff:fec4:a963] ([IPv6:2001:7b8:206:1:21b:63ff:fec4:a963]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m78AHnt7051985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2008 12:17:49 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Cc: Namedroppers WG , Mark Andrews , Paul Vixie , bert hubert Message-Id: <56DE84F3-E432-40F8-B174-EC9B5EDB4FDE@NLnetLabs.nl> From: Olaf Kolkman To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Duane In-Reply-To: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-13--634699688" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. Date: Fri, 8 Aug 2008 12:17:48 +0200 References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> <489C140C.60205@e164.org> X-Pgp-Agent: GPGMail d52 (v52, Leopard) X-Mailer: Apple Mail (2.926) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 08 Aug 2008 12:17:49 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-13--634699688 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable [This thread has gone off-topic, so has this reply] On Aug 8, 2008, at 11:52 AM, Ond=C5=99ej Sur=C3=BD wrote: > 2008/8/8 Duane at e164 dot org : >> Ond=C5=99ej Sur=C3=BD wrote: >> >>> So when you installed your DNS server infrastructure, was it just >>> some "magic" command which caused all your domain names to be server >>> by that servers? Or did you have to make changes to config files, >>> generate TSIG keys, configure primary, configure slaves, add zones >>> to config file... >> >> apt-get scripts either prompt for more information or pre-config =20 >> nearly >> everything out of the box. > > No, it doesn't. It just add some preconfiguration for rDNS, but it =20= > doesn't > setup your zones. You have to add them manually. Same with TSIG, =20 > slaves, > etc. > >>> I see kind of analogy here. Available tools are bit rough at this =20= >>> time, >>> but it's magnituted better that it was half a year ago. >> >> What was, is meaningless to those that don't know or care, what is, =20= >> is >> all that matters if you are trying to sell DNSSEC to the unwashed =20 >> masses >> that aren't drinking the koolaid. > > Well, we don't need to sell it to masses. We just need to educated =20= > registrars, > ISPs and big zone hosters, where people with (at least some) clue =20 > works. > And that's something what we are working on. Ond=C5=99ej Sur=C3=BD, Duane Groth, You are both right. We need the clueful folk to deploy and provide basic infrastructure, =20 we need the clueful folk to build the tools, the devices and auto-=20 scripts, and then we need the masses to make deployment a success. We =20= are still at the beginning of the deployment curve. But mind you. If you want to do DNSSEC in a no-brain fashion there are =20= proprietary solutions already (just like there are proprietary =20 solutions for plain-old DNSSEC management). The design of management software is to a great extend off-topic for =20 this list, unless we need protocols to make them interoperate. We have RFC5011 to manage part of that (open-source implementation =20 forthcoming) and numerous folk are working on key-maintenance tools. =20 See for instance: http://www.dnssec-tools/, http://=20 www.opendnssec.org/, http://www.xtcn.com/ lamb/pkcs11HSMtools.tar.gz, =20= and http://www.ripe.net/disi/dnssec_maint_tool/ are some initiatives I =20= am aware of. ISC has announced work on tools for the next version of =20 bind. I would agree with claims that most of them are far from state-of the =20= art, but the activity in this area is rapidly increasing. Duane , you seem to be the kind of guy that knows both what end-users =20= really need, and have the clue to spec and implement that ;-) --Olaf PS. I will keep an open eye on alternative protocol or operational =20 practices that will help to bridge the gap between now and the time =20 that DNSSEC has seen sufficient deployment to make it useful, but I =20 will try to refrain from entering in future off-topic debates on this =20= issue on this list. --Apple-Mail-13--634699688 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkicHUwACgkQtN/ca3YJIocRygCfQjbXt6qxO0jie5eHwpMiFfL/ NKcAoNaPBBi4t7cRrCefMM4ECQN4ePJI =Vbog -----END PGP SIGNATURE----- --Apple-Mail-13--634699688-- -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 03:25:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D413A6CEB; Fri, 8 Aug 2008 03:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.111 X-Spam-Level: X-Spam-Status: No, score=-101.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 RnYg4qbTEJYl; Fri, 8 Aug 2008 03:25:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 941073A6CAD; Fri, 8 Aug 2008 03:25:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRP6J-000J1P-E0 for namedroppers-data@psg.com; Fri, 08 Aug 2008 10:21:39 +0000 Received: from [2001:748:301::2] (helo=shinjuku.zaphods.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRP6F-000IzT-HT for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 10:21:37 +0000 Received: from zaphodb by shinjuku.zaphods.net with local (Exim 4.69) (envelope-from ) id 1KRP6D-00014I-3L for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 12:21:33 +0200 Date: Fri, 8 Aug 2008 12:21:32 +0200 From: Stefan Schmidt To: Namedroppers Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. Message-ID: <20080808102132.GO18233@zaphods.net> References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> <489C140C.60205@e164.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Origin-AS: AS5430 X-NCC-nic-hdl: ZAP-RIPE User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 08, 2008 at 11:52:08AM +0200, Ond??ej Surý wrote: > > What was, is meaningless to those that don't know or care, what is, is > > all that matters if you are trying to sell DNSSEC to the unwashed masses > > that aren't drinking the koolaid. > > Well, we don't need to sell it to masses. We just need to educated registrars, > ISPs and big zone hosters, where people with (at least some) clue works. > And that's something what we are working on. If you don't deploy it to a hundred percent it simply won't be 'the solution' to the spoofing and man-in-the-middle problem as some people here like to think. Saturation is important to the success of a protocol, think of blueray vs. hd-dvd so you need not only to address the forbes500 but also www.mylittlewebsitethatsellsstuff.cctld, that kind of thing is often run by small companys that lack the clue you want people to have. Stefan -- There is hopeful symbolism in the fact that flags don't wave in a vacuum. - Arthur C. Clark -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 03:37:10 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970743A6ACC; Fri, 8 Aug 2008 03:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, 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 xGTqvt93mzYB; Fri, 8 Aug 2008 03:37:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82AEB3A6830; Fri, 8 Aug 2008 03:37:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRPGC-000KSR-IN for namedroppers-data@psg.com; Fri, 08 Aug 2008 10:31:52 +0000 Received: from [212.74.77.49] (helo=smtp.lon.dcn.colt.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRPG4-000KRe-I6 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 10:31:47 +0000 Received: from [194.45.79.6] (quo.fra.ws.COLT.NET [212.74.79.242]) by smtp.lon.dcn.colt.net (Postfix) with ESMTP id 3C5B43574A; Fri, 8 Aug 2008 12:31:42 +0200 (CEST) From: Ralf Weber To: =?UTF-8?Q?=22Ond=C5=99ej_Sur=C3=BD=22?= In-Reply-To: Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> <489C140C.60205@e164.org> Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 8 Aug 2008 12:31:41 +0200 Cc: "Duane at e164 dot org" , Namedroppers , "Mark Andrews" , "Paul Vixie" , "bert hubert" X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Moin! On Aug 8, 2008, at 11:52 , Ond=C5=99ej Sur=C3=BD wrote: > Well, we don't need to sell it to masses. We just need to educated =20= > registrars, > ISPs and big zone hosters, where people with (at least some) clue =20 > works. Well even these guys (I think my company is in one of the above =20 mentioned business ;-) want tools that don't put to much operational =20 burden on them. So a switch or checkbox that says DNSSEC enabled for =20 that zone, and does all the rest in background (KSK, ZSK generation, =20 zone signing and resigning, ZSK rollover, KSK rollover) is something =20 that we and I guess others want. Ok for KSK it would be good if it =20 offer to access it via an external storage that you only attach to the =20= box at certain times to not have always on the box and at risk being =20 compromised. And we do want it in an integrated manner and not as a =20 bunch of different toolsets that you can stick together. So far I know of no solution that does offer that, but if anyone knows =20= tell me. > And that's something what we are working on. You can try, but I guess you will have problems when the operational =20 overhead is bigger than the potential benefit. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: Ralf.Weber@colt.net http://www.colt.net/ Data | Voice | Managed Services ***************************************** COLT Telecom GmbH, Herriotstra=C3=9Fe 4, 60528 Frankfurt/Main, = Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch=C3=A4ftsf=C3=BChrer: Albertus Marinus Oosterom (Vors.), Rita Thies = * Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 03:53:24 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A7F3A6841; Fri, 8 Aug 2008 03:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.031, 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 XVlsSpQcLM3Z; Fri, 8 Aug 2008 03:53:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 761393A6407; Fri, 8 Aug 2008 03:53:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRPWT-000NCL-G1 for namedroppers-data@psg.com; Fri, 08 Aug 2008 10:48:41 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRPWP-000NBK-TB for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 10:48:39 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id B377AFF26C; Fri, 8 Aug 2008 20:48:36 +1000 (EST) Message-ID: <489C2480.2020801@e164.org> Date: Fri, 08 Aug 2008 20:48:32 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Stefan Schmidt CC: Namedroppers Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> <489C140C.60205@e164.org> <20080808102132.GO18233@zaphods.net> In-Reply-To: <20080808102132.GO18233@zaphods.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Stefan Schmidt wrote: > think. Saturation is important to the success of a protocol, think of blueray > vs. hd-dvd so you need not only to address the forbes500 but also Actually funny you should mention blueray, an article about it today how it may have won the format wars but no one really cares about it because DVDs are good enough. Many think DNS is more or less good enough and well you get the idea. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 04:18:29 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A11E3A6B3A; Fri, 8 Aug 2008 04:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.89 X-Spam-Level: X-Spam-Status: No, score=0.89 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, 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 S8QhM1qw+epc; Fri, 8 Aug 2008 04:18:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 369B23A6830; Fri, 8 Aug 2008 04:18:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRPtf-00014s-Qv for namedroppers-data@psg.com; Fri, 08 Aug 2008 11:12:39 +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 ) id 1KRPtX-00012I-EZ for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 11:12:35 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KRPtV-0001Qb-8F for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 13:12:29 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 45CD94B44F; Fri, 8 Aug 2008 13:12:43 +0200 (CEST) Date: Fri, 8 Aug 2008 13:12:42 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: first succesful (lab) spoof of a fully source port randomized server reported Message-ID: <20080808111242.GI6566@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: http://tservice.net.ru/~s0mbre/blog//devel/networking/dns/2008_08_08 "Attack took about half of the day, i.e. a bit less than 10 hours. So, if you have a GigE lan, any trojaned machine can poison your DNS during one night... " Congratulations are due to Evgeniy Polyakov! He includes the source of his exploit. In the meantime, please ponder http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01213.html 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 04:31:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EE13A6D40; Fri, 8 Aug 2008 04:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, 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 3K0x0nCY1tyY; Fri, 8 Aug 2008 04:31:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE5FD3A6C95; Fri, 8 Aug 2008 04:31:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRQ6o-0002P0-9u for namedroppers-data@psg.com; Fri, 08 Aug 2008 11:26:14 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRQ6j-0002OD-H0 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 11:26:11 +0000 Received: (qmail 82468 invoked from network); 8 Aug 2008 11:26:07 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Aug 2008 11:26:07 -0000 Date: Fri, 08 Aug 2008 13:26:07 +0200 (CEST) Message-Id: <20080808.132607.41660169.sthaug@nethelp.no> To: namedroppers@ops.ietf.org Subject: Re: first succesful (lab) spoof of a fully source port randomized server reported From: sthaug@nethelp.no In-Reply-To: <20080808111242.GI6566@outpost.ds9a.nl> References: <20080808111242.GI6566@outpost.ds9a.nl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > http://tservice.net.ru/~s0mbre/blog//devel/networking/dns/2008_08_08 > > "Attack took about half of the day, i.e. a bit less than 10 hours. > So, if you have a GigE lan, any trojaned machine can poison your DNS during > one night... " > > Congratulations are due to Evgeniy Polyakov! He includes the source of his > exploit. Interesting enough. Meanwhile, if I have a recursive name server where the total traffic from the authoritative servers is in the range of 2 - 3 Mbps, I believe I could safely rate limit the traffic from each individual IP (representing a possibly spoofed authoritative server) to 100 - 200 kbps. This should raise the bar somewhat. Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 04:52:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F411F3A6D51; Fri, 8 Aug 2008 04:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 lvV7mW5S1UGi; Fri, 8 Aug 2008 04:52:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D0863A6CB4; Fri, 8 Aug 2008 04:52:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRQRP-0004qU-Fl for namedroppers-data@psg.com; Fri, 08 Aug 2008 11:47:31 +0000 Received: from [2001:41e0:ff00:0:216:3eff:fe00:4] (helo=abaddon.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRQRJ-0004pa-5S for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 11:47:29 +0000 Received: from [IPv6:2001:620:20:1000:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1000:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 6E3C235A525; Fri, 8 Aug 2008 13:47:23 +0200 (CEST) Message-ID: <489C324B.1090603@spaghetti.zurich.ibm.com> Date: Fri, 08 Aug 2008 13:47:23 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Lightning/0.8 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: sthaug@nethelp.no CC: namedroppers@ops.ietf.org Subject: Re: first succesful (lab) spoof of a fully source port randomized server reported References: <20080808111242.GI6566@outpost.ds9a.nl> <20080808.132607.41660169.sthaug@nethelp.no> In-Reply-To: <20080808.132607.41660169.sthaug@nethelp.no> X-Enigmail-Version: 0.95.6 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig36D8B2929DAB60542EAD7BE7" X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on abaddon.unfix.org X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36D8B2929DAB60542EAD7BE7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable sthaug@nethelp.no wrote: >> http://tservice.net.ru/~s0mbre/blog//devel/networking/dns/2008_08_08 >> >> "Attack took about half of the day, i.e. a bit less than 10 hours. >> So, if you have a GigE lan, any trojaned machine can poison your DNS = during >> one night... " >> >> Congratulations are due to Evgeniy Polyakov! He includes the source of= his >> exploit. >=20 > Interesting enough. Meanwhile, if I have a recursive name server where > the total traffic from the authoritative servers is in the range of > 2 - 3 Mbps, I believe I could safely rate limit the traffic from each > individual IP (representing a possibly spoofed authoritative server) to= > 100 - 200 kbps. This should raise the bar somewhat. /me reconfigures the 1M-node botnets to only send 100 packets/s per bot. Isn't distributed^Wcloud computing amazing? Unfortunately, as long as one can try all the combinations in one way or = another the problem keeps on existing. And if people can send 1G for 12=20 hours without nobody noticing, you have worse problems in your network. Bad part is that one can most likely also crack dnssec or tls in this=20 method, it basically is the infinite monkeys typing problem, they will=20 produce the answer that you expected. If you work against it, eg "the=20 monkeys send me X fake responses lets ratelimit" you might be blocking=20 service (denial of service) to something legit again. Nice and annoying problem, thanks Dan* :) Greets, Jeroen * =3D do the dictionaries already contain a proper definition for "to pul= l=20 a Kaminsky on someone"? :) --------------enig36D8B2929DAB60542EAD7BE7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFInDJLKaooUjM+fCMRAvlDAKCP0WMnaz3oTqKMnQ6q1axGQMilPQCcCMvQ 5Qf5awYAmZF1504RolHIWcs= =uU3n -----END PGP SIGNATURE----- --------------enig36D8B2929DAB60542EAD7BE7-- -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 05:07:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1FD3A6CBB; Fri, 8 Aug 2008 05:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.707 X-Spam-Level: *** X-Spam-Status: No, score=3.707 tagged_above=-999 required=5 tests=[AWL=0.821, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 i69XIqFIwaaV; Fri, 8 Aug 2008 05:07:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 899293A67B2; Fri, 8 Aug 2008 05:07:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRQeu-0006J4-06 for namedroppers-data@psg.com; Fri, 08 Aug 2008 12:01:28 +0000 Received: from [64.233.182.184] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRQep-0006IC-5a for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 12:01:25 +0000 Received: by nf-out-0910.google.com with SMTP id g13so845299nfb.11 for ; Fri, 08 Aug 2008 05:01:20 -0700 (PDT) Received: by 10.210.71.12 with SMTP id t12mr5411317eba.36.1218196880099; Fri, 08 Aug 2008 05:01:20 -0700 (PDT) Received: by 10.210.121.1 with HTTP; Fri, 8 Aug 2008 05:01:20 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 14:01:20 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: Namedroppers Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. In-Reply-To: <20080808102132.GO18233@zaphods.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> <489C140C.60205@e164.org> <20080808102132.GO18233@zaphods.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: MjAwOC84LzggU3RlZmFuIFNjaG1pZHQgPHphcGhvZGJAemFwaG9kcy5uZXQ+Ogo+IE9uIEZyaSwg QXVnIDA4LCAyMDA4IGF0IDExOjUyOjA4QU0gKzAyMDAsIE9uZD8/ZWogU3Vyw70gd3JvdGU6Cj4+ ID4gV2hhdCB3YXMsIGlzIG1lYW5pbmdsZXNzIHRvIHRob3NlIHRoYXQgZG9uJ3Qga25vdyBvciBj YXJlLCB3aGF0IGlzLCBpcwo+PiA+IGFsbCB0aGF0IG1hdHRlcnMgaWYgeW91IGFyZSB0cnlpbmcg dG8gc2VsbCBETlNTRUMgdG8gdGhlIHVud2FzaGVkIG1hc3Nlcwo+PiA+IHRoYXQgYXJlbid0IGRy aW5raW5nIHRoZSBrb29sYWlkLgo+Pgo+PiBXZWxsLCB3ZSBkb24ndCBuZWVkIHRvIHNlbGwgaXQg dG8gbWFzc2VzLiAgV2UganVzdCBuZWVkIHRvIGVkdWNhdGVkIHJlZ2lzdHJhcnMsCj4+IElTUHMg YW5kIGJpZyB6b25lIGhvc3RlcnMsIHdoZXJlIHBlb3BsZSB3aXRoIChhdCBsZWFzdCBzb21lKSBj bHVlIHdvcmtzLgo+PiBBbmQgdGhhdCdzIHNvbWV0aGluZyB3aGF0IHdlIGFyZSB3b3JraW5nIG9u Lgo+Cj4gSWYgeW91IGRvbid0IGRlcGxveSBpdCB0byBhIGh1bmRyZWQgcGVyY2VudCBpdCBzaW1w bHkgd29uJ3QgYmUgJ3RoZSBzb2x1dGlvbicKPiB0byB0aGUgc3Bvb2ZpbmcgYW5kIG1hbi1pbi10 aGUtbWlkZGxlIHByb2JsZW0gYXMgc29tZSBwZW9wbGUgaGVyZSBsaWtlIHRvCj4gdGhpbmsuIFNh dHVyYXRpb24gaXMgaW1wb3J0YW50IHRvIHRoZSBzdWNjZXNzIG9mIGEgcHJvdG9jb2wsIHRoaW5r IG9mIGJsdWVyYXkKPiB2cy4gaGQtZHZkIHNvIHlvdSBuZWVkIG5vdCBvbmx5IHRvIGFkZHJlc3Mg dGhlIGZvcmJlczUwMCBidXQgYWxzbwo+IHd3dy5teWxpdHRsZXdlYnNpdGV0aGF0c2VsbHNzdHVm Zi5jY3RsZCwgdGhhdCBraW5kIG9mIHRoaW5nIGlzIG9mdGVuIHJ1biBieQo+IHNtYWxsIGNvbXBh bnlzIHRoYXQgbGFjayB0aGUgY2x1ZSB5b3Ugd2FudCBwZW9wbGUgdG8gaGF2ZS4KClRoYXQncyB0 aGUgcmVhc29uIHdoeSB0byB0YWxrIHRvIHJlZ2lzdHJhcnMsIHdlYmhvc3RlcnMgYW5kIHpvbmUg aG9zdGVycyAod2hpY2gKaXMgYWxtb3N0IHRoZSBzYW1lIHBlb3BsZSBoZXJlKS4gIFRoYXQgd2F5 IHlvdSBoaXQgbm90IG9ubHkgdG9wIGNvbXBhbmllcwpidXQgYWxzbyBsb3RzIGFuZCBsb3RzIG9m IHNtYWxsIGZvbGtzLgoKT25kcmVqCi0tIAogT25kxZllaiBTdXLDvQogdGVjaG5pY2vDvSDFmWVk aXRlbC9DaGllZiBUZWNobmljYWwgT2ZmaWNlcgogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KIENaLk5JQywgei5zLnAuby4gLS0gLmN6IGRvbWFpbiByZWdpc3RyeQog QW1lcmlja8OhIDIzLDEyMCAwMCBQcmFoYSAyLEN6ZWNoIFJlcHVibGljCiBtYWlsdG86b25kcmVq LnN1cnlAbmljLmN6IGh0dHA6Ly9uaWMuY3ovCiBzaXA6b25kcmVqLnN1cnlAbmljLmN6IHRlbDor NDIwLjIyMjc0NTExMAogbW9iOis0MjAuNzM5MDEzNjk5IGZheDorNDIwLjIyMjc0NTExMgogLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 05:40:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C833A6ACC; Fri, 8 Aug 2008 05:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_00=-2.599, TRACKER_ID=2.003] 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 bOanmGJlZ-Df; Fri, 8 Aug 2008 05:40:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A1923A6887; Fri, 8 Aug 2008 05:40:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRCW-000AEL-KI for namedroppers-data@psg.com; Fri, 08 Aug 2008 12:36:12 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRCR-000ADU-DR for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 12:36:10 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m78Ca2u6032104 for ; Fri, 8 Aug 2008 22:36:03 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808081236.m78Ca2u6032104@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark_Andrews@isc.org Subject: majordomo is broken Date: Fri, 08 Aug 2008 22:36:02 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Can someone fix majordomo to properly recognise base64 encoded content. Hint whitespace can occur *anywhere* in the base64 encoded content not just after a multiple of 4 base64 characters. Mark ------- Forwarded Message Return-Path: owner-namedroppers@ops.ietf.org Delivery-Date: Fri Aug 8 22:11:02 2008 Return-Path: Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m78CB02T031592 for ; Fri, 8 Aug 2008 22:11:02 +1000 (EST) (envelope-from owner-namedroppers@ops.ietf.org) X-Original-To: marka@farside.isc.org Delivered-To: marka@farside.isc.org Received: from farside.isc.org [204.152.187.5] by drugs.dv.isc.org with IMAP (fetchmail-6.3.8) for (single-drop); Fri, 08 Aug 2008 22:11:02 +1000 (EST) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id E5AA3E6064; Fri, 8 Aug 2008 12:10:24 +0000 (UTC) (envelope-from owner-namedroppers@ops.ietf.org) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "psg.com", Issuer "RGnet Root CA" (not verified)) by mx.isc.org (Postfix) with ESMTPS id F067311407E; Fri, 8 Aug 2008 12:10:19 +0000 (UTC) (envelope-from owner-namedroppers@ops.ietf.org) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRQeu-0006J4-06 for namedroppers-data@psg.com; Fri, 08 Aug 2008 12:01:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mx.isc.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_WHITELIST_TO autolearn=no version=3.2.4 Received: from [64.233.182.184] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRQep-0006IC-5a for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 12:01:25 +0000 Received: by nf-out-0910.google.com with SMTP id g13so845299nfb.11 for ; Fri, 08 Aug 2008 05:01:20 -0700 (PDT) Received: by 10.210.71.12 with SMTP id t12mr5411317eba.36.1218196880099; Fri, 08 Aug 2008 05:01:20 -0700 (PDT) Received: by 10.210.121.1 with HTTP; Fri, 8 Aug 2008 05:01:20 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 14:01:20 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: Namedroppers Subject: Re: The problem I see with DNSSEC as a potential end user and administrator. In-Reply-To: <20080808102132.GO18233@zaphods.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <489BE047.1010100@e164.org> <489C0E08.3040406@e164.org> <489C112A.8000306@e164.org> <489C140C.60205@e164.org> <20080808102132.GO18233@zaphods.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: MjAwOC84LzggU3RlZmFuIFNjaG1pZHQgPHphcGhvZGJAemFwaG9kcy5uZXQ+Ogo+IE9uIEZyaSwg QXVnIDA4LCAyMDA4IGF0IDExOjUyOjA4QU0gKzAyMDAsIE9uZD8/ZWogU3Vyw70gd3JvdGU6Cj4+ ID4gV2hhdCB3YXMsIGlzIG1lYW5pbmdsZXNzIHRvIHRob3NlIHRoYXQgZG9uJ3Qga25vdyBvciBj YXJlLCB3aGF0IGlzLCBpcwo+PiA+IGFsbCB0aGF0IG1hdHRlcnMgaWYgeW91IGFyZSB0cnlpbmcg dG8gc2VsbCBETlNTRUMgdG8gdGhlIHVud2FzaGVkIG1hc3Nlcwo+PiA+IHRoYXQgYXJlbid0IGRy aW5raW5nIHRoZSBrb29sYWlkLgo+Pgo+PiBXZWxsLCB3ZSBkb24ndCBuZWVkIHRvIHNlbGwgaXQg dG8gbWFzc2VzLiAgV2UganVzdCBuZWVkIHRvIGVkdWNhdGVkIHJlZ2lzdHJhcnMsCj4+IElTUHMg YW5kIGJpZyB6b25lIGhvc3RlcnMsIHdoZXJlIHBlb3BsZSB3aXRoIChhdCBsZWFzdCBzb21lKSBj bHVlIHdvcmtzLgo+PiBBbmQgdGhhdCdzIHNvbWV0aGluZyB3aGF0IHdlIGFyZSB3b3JraW5nIG9u Lgo+Cj4gSWYgeW91IGRvbid0IGRlcGxveSBpdCB0byBhIGh1bmRyZWQgcGVyY2VudCBpdCBzaW1w bHkgd29uJ3QgYmUgJ3RoZSBzb2x1dGlvbicKPiB0byB0aGUgc3Bvb2ZpbmcgYW5kIG1hbi1pbi10 aGUtbWlkZGxlIHByb2JsZW0gYXMgc29tZSBwZW9wbGUgaGVyZSBsaWtlIHRvCj4gdGhpbmsuIFNh dHVyYXRpb24gaXMgaW1wb3J0YW50IHRvIHRoZSBzdWNjZXNzIG9mIGEgcHJvdG9jb2wsIHRoaW5r IG9mIGJsdWVyYXkKPiB2cy4gaGQtZHZkIHNvIHlvdSBuZWVkIG5vdCBvbmx5IHRvIGFkZHJlc3Mg dGhlIGZvcmJlczUwMCBidXQgYWxzbwo+IHd3dy5teWxpdHRsZXdlYnNpdGV0aGF0c2VsbHNzdHVm Zi5jY3RsZCwgdGhhdCBraW5kIG9mIHRoaW5nIGlzIG9mdGVuIHJ1biBieQo+IHNtYWxsIGNvbXBh bnlzIHRoYXQgbGFjayB0aGUgY2x1ZSB5b3Ugd2FudCBwZW9wbGUgdG8gaGF2ZS4KClRoYXQncyB0 aGUgcmVhc29uIHdoeSB0byB0YWxrIHRvIHJlZ2lzdHJhcnMsIHdlYmhvc3RlcnMgYW5kIHpvbmUg aG9zdGVycyAod2hpY2gKaXMgYWxtb3N0IHRoZSBzYW1lIHBlb3BsZSBoZXJlKS4gIFRoYXQgd2F5 IHlvdSBoaXQgbm90IG9ubHkgdG9wIGNvbXBhbmllcwpidXQgYWxzbyBsb3RzIGFuZCBsb3RzIG9m IHNtYWxsIGZvbGtzLgoKT25kcmVqCi0tIAogT25kxZllaiBTdXLDvQogdGVjaG5pY2vDvSDFmWVk aXRlbC9DaGllZiBUZWNobmljYWwgT2ZmaWNlcgogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KIENaLk5JQywgei5zLnAuby4gLS0gLmN6IGRvbWFpbiByZWdpc3RyeQog QW1lcmlja8OhIDIzLDEyMCAwMCBQcmFoYSAyLEN6ZWNoIFJlcHVibGljCiBtYWlsdG86b25kcmVq LnN1cnlAbmljLmN6IGh0dHA6Ly9uaWMuY3ovCiBzaXA6b25kcmVqLnN1cnlAbmljLmN6IHRlbDor NDIwLjIyMjc0NTExMAogbW9iOis0MjAuNzM5MDEzNjk5IGZheDorNDIwLjIyMjc0NTExMgogLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K - -- 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: ------- End of Forwarded Message -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 05:41:26 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62E23A6D51; Fri, 8 Aug 2008 05:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 omyt9NmxcEJW; Fri, 8 Aug 2008 05:41:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE8143A6AEA; Fri, 8 Aug 2008 05:41:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRCk-000AFT-DL for namedroppers-data@psg.com; Fri, 08 Aug 2008 12:36:26 +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 ) id 1KRRCg-000AF0-FV for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 12:36:24 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m78CaKVv012229 for ; Fri, 8 Aug 2008 08:36:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808081236.m78CaKVv012229@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Aug 2008 08:35:09 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: DNSEXT/namedroppers list policy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Periodic posting, updated 08/Aug/2008. (new note well statement) List Purpose: namedroppers at ops.ietf.org is the mailing list for the IETF DNSEXT (DNS EXTensions) working group. See for the WG charter. Messages should be on topics appropriate to the DNSEXT WG, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfiguration, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for DNS operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailing list. Discussion about the quality of implementations is outside the scope of this list. Moderation: Moderator: DNSEXT chair(s) unless otherwise announced on mailing list. Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails, messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the WG chair, with follow up appeals using the normal appeals process of RFC 2026 (i.e. follow up with area directors, then IESG, etc.). --- NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: the IETF plenary session, any IETF working group or portion thereof, the IESG, or any member thereof on behalf of the IESG, the IAB or any member thereof on behalf of the IAB, any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3978 (updated by RFC 4748) and RFC 3979(updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3978 (and RFC 4748) for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. IETF Secretariat - Please send problem reports to ietf-web@ietf.org. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 05:42:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74333A6AEA; Fri, 8 Aug 2008 05:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.69 X-Spam-Level: **** X-Spam-Status: No, score=4.69 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_ASCII0=1.5, 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 xQadujuBLvBD; Fri, 8 Aug 2008 05:42:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C6D833A6887; Fri, 8 Aug 2008 05:42:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRCD-000ACB-UY for namedroppers-data@psg.com; Fri, 08 Aug 2008 12:35:53 +0000 Received: from [64.233.182.189] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRCA-000ABX-39 for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 12:35:52 +0000 Received: by nf-out-0910.google.com with SMTP id g13so853759nfb.11 for ; Fri, 08 Aug 2008 05:35:48 -0700 (PDT) Received: by 10.210.73.12 with SMTP id v12mr5433306eba.101.1218198947878; Fri, 08 Aug 2008 05:35:47 -0700 (PDT) Received: by 10.210.121.1 with HTTP; Fri, 8 Aug 2008 05:35:47 -0700 (PDT) Message-ID: Date: Fri, 8 Aug 2008 14:35:47 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: "Jeroen Massar" Subject: Re: first succesful (lab) spoof of a fully source port randomized server reported Cc: sthaug@nethelp.no, namedroppers@ops.ietf.org In-Reply-To: <489C324B.1090603@spaghetti.zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20080808111242.GI6566@outpost.ds9a.nl> <20080808.132607.41660169.sthaug@nethelp.no> <489C324B.1090603@spaghetti.zurich.ibm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: PiAvbWUgcmVjb25maWd1cmVzIHRoZSAxTS1ub2RlIGJvdG5ldHMgdG8gb25seSBzZW5kIDEwMCBw YWNrZXRzL3MgcGVyIGJvdC4KCkhtbSwgYW5kIGhvdyBkbyB5b3Ugc3Bvb2Ygc291cmNlIElQIGFk ZHJlc3MgdG9nZXRoZXIgd2l0aCBub3QgYmVpbmcgYmxvY2tlZCBieQpwZXIgc291cmNlIElQIGxp bWl0IGZpbHRlcj8KCk9uZHJlai4KLS0gCiBPbmTFmWVqIFN1csO9CiB0ZWNobmlja8O9IMWZZWRp dGVsL0NoaWVmIFRlY2huaWNhbCBPZmZpY2VyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQogQ1ouTklDLCB6LnMucC5vLiAtLSAuY3ogZG9tYWluIHJlZ2lzdHJ5CiBB bWVyaWNrw6EgMjMsMTIwIDAwIFByYWhhIDIsQ3plY2ggUmVwdWJsaWMKIG1haWx0bzpvbmRyZWou c3VyeUBuaWMuY3ogaHR0cDovL25pYy5jei8KIHNpcDpvbmRyZWouc3VyeUBuaWMuY3ogdGVsOis0 MjAuMjIyNzQ1MTEwCiBtb2I6KzQyMC43MzkwMTM2OTkgZmF4Ois0MjAuMjIyNzQ1MTEyCiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo= -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 06:05:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4405428C176; Fri, 8 Aug 2008 06:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 pz-8JTUvcOfr; Fri, 8 Aug 2008 06:05:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 377BA28C14C; Fri, 8 Aug 2008 06:05:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRVo-000D4O-F2 for namedroppers-data@psg.com; Fri, 08 Aug 2008 12:56:08 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRVj-000D3C-PS for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 12:56:06 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m78Cwi04007196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Aug 2008 05:58:47 -0700 Date: Fri, 8 Aug 2008 08:55:59 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Please stop this thread (was: OFFTOPIC: DNSSEC groupthink versus improving DNS) Message-ID: <20080808125558.GA56310@commandprompt.com> References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Fri, 08 Aug 2008 05:58:48 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, Speaking as the one who has the current moderation token on this list, I'd like to ask that we stop this thread. Irrespective of what you personally think about DNSSEC, the liklihood of its future deployment, its utility, the chances of it solving the problems we have in the DNS, &c., the fact is that the WG adopted it, and the specification is available. Proposals for clarification, discussion of what additional tools are needed (to the extent those require protocol work), and even opposition to continued work in this area are all on-topic for this working group. Claims that DNSSEC will never be deployed or that it is currently unworkable are _not_ on topic here, because those claims have nothing to do with the protocol itself. Moreover, arguments that individuals are suffering from group-think runs perilously close to the line of _ad hominem_ attack. We have had problems with that sort of discussion in the past, and I want to remind everyone that we will not tolerate such attacks. If you have a problem with the protocol, feel free to discuss it here. If you instead have a problem just with what other people believe, then this is not the right forum for your discussion. Best regards, Andrew -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 06:10:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80A63A6BF1; Fri, 8 Aug 2008 06:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 4oTfidQD4r+W; Fri, 8 Aug 2008 06:10:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF2E93A69B9; Fri, 8 Aug 2008 06:10:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRfO-000EXk-QZ for namedroppers-data@psg.com; Fri, 08 Aug 2008 13:06:02 +0000 Received: from [2001:41e0:ff00:0:216:3eff:fe00:4] (helo=abaddon.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRRfK-000EWw-MY for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 13:06:00 +0000 Received: from [IPv6:2001:620:20:1000:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1000:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 3B61035A525; Fri, 8 Aug 2008 15:05:57 +0200 (CEST) Message-ID: <489C44B4.4050404@spaghetti.zurich.ibm.com> Date: Fri, 08 Aug 2008 15:05:56 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Lightning/0.8 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: first succesful (lab) spoof of a fully source port randomized server reported References: <20080808111242.GI6566@outpost.ds9a.nl> <20080808.132607.41660169.sthaug@nethelp.no> <489C324B.1090603@spaghetti.zurich.ibm.com> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig327FA6BAD7A43C283CA6E562" X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on abaddon.unfix.org X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig327FA6BAD7A43C283CA6E562 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ond=C5=99ej Sur=C3=BD wrote: >> /me reconfigures the 1M-node botnets to only send 100 packets/s per bo= t. >=20 > Hmm, and how do you spoof source IP address together with not being blo= cked by > per source IP limit filter? Why bother with spoofing? You have a million *real* hosts available, and = soon, because of DNS hijacking and then $tricks quite a number more. We really have to be happy that the updates provided by at least Windows = Update are reasonably secure ;) Greets, Jeroen --------------enig327FA6BAD7A43C283CA6E562 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFInES1KaooUjM+fCMRAkijAJ4rmwQMKy3UWcGzSLB/bH173554/QCgufgg pdNFW2TBl23+GJN/vlPssHI= =3KSc -----END PGP SIGNATURE----- --------------enig327FA6BAD7A43C283CA6E562-- -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 07:09:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582F43A6D77; Fri, 8 Aug 2008 07:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_LOW=-1, 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 EDLeLHdbxJCV; Fri, 8 Aug 2008 07:09:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 661793A6CE2; Fri, 8 Aug 2008 07:09:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRSXl-000LdG-Ms for namedroppers-data@psg.com; Fri, 08 Aug 2008 14:02:13 +0000 Received: from [88.198.34.164] (helo=mail.bofh.priv.at) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRSXe-000LbX-Jz for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 14:02:08 +0000 Received: from [10.10.0.107] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id F10A04D41C for ; Fri, 8 Aug 2008 16:02:01 +0200 (CEST) Message-ID: <489C5202.4080405@nic.at> Date: Fri, 08 Aug 2008 16:02:42 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> In-Reply-To: <49451.1218124457@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > > which is not to say > that dnssec is easy -- i know that at ISC we're thinking seriously of > dedicating the whole BIND 9.7 release to dnssec tools and usability. This is a good idea. We really need a single checkbox "Automatically sign all my zones" in the nameserver implementations. That, and not the protocol itself is holding up DNSSEC deployment. IMHO and all that. But back to the namedropper charter: * Are there any open protocol issues which make such a "single checkbox" deployment of DNSSEC impossible? * In order to facilitate this, we need automatic DS generation in the parent zone, and means to deal with lost keys and other "crypto-emergencies". Is this all defined? What I really want is a Debian upgrade which just asks for my confirmation to enable DNSSEC on my box without any further interactions. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 15:58:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E513A6B20; Fri, 8 Aug 2008 15:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ZK8D6MnaE6Oy; Fri, 8 Aug 2008 15:58:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 701B23A6B4F; Fri, 8 Aug 2008 15:58:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRamD-0000Ly-L0 for namedroppers-data@psg.com; Fri, 08 Aug 2008 22:49:41 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRam8-0000Eu-Ck for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 22:49:39 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m78Mm5IP005263; Fri, 8 Aug 2008 22:48:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m78Mm3hS005262; Fri, 8 Aug 2008 22:48:03 GMT Date: Fri, 8 Aug 2008 22:48:03 +0000 From: bmanning@vacation.karoshi.com To: Duane at e164 dot org Cc: David Ulevitch , Namedroppers Subject: Re: list policies Message-ID: <20080808224803.GA5217@vacation.karoshi.com.> References: <489BE047.1010100@e164.org> <489BE6BA.8050200@everydns.net> <489BE9A2.9040608@e164.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489BE9A2.9040608@e164.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: "Duane" - David is not the only one... he's just more vocal. you invite confusion ... based on public records, I will presume this is you until or unless othewise proven by credible parties. Duane Groth P.O. Box 75 Banksia NSW 2216 AU --bill On Fri, Aug 08, 2008 at 04:37:22PM +1000, Duane at e164 dot org wrote: > David Ulevitch wrote: > > Duane, > > > > Can we get a last name please? We already have one Duane on this list > > and it's hard to know who you are. Is that too much to ask? This is an > > IETF mailing list, after all. > > In all the time I've used the internet you are the only person to care > at all. > > -- > > Best regards, > Duane > > -- > 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: -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 16:42:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A633A6835; Fri, 8 Aug 2008 16:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 eQXCb4GKGjmP; Fri, 8 Aug 2008 16:42:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB5FD3A68C0; Fri, 8 Aug 2008 16:42:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRbWw-0003vH-8t for namedroppers-data@psg.com; Fri, 08 Aug 2008 23:37:58 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRbWs-0003uR-Mb for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 23:37:56 +0000 Received: from sirocco.local (pool-71-178-166-113.washdc.fios.verizon.net [71.178.166.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id 66E31136771 for ; Fri, 8 Aug 2008 19:37:51 -0400 (EDT) Date: Fri, 8 Aug 2008 19:37:51 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Re: Please stop this thread (was: OFFTOPIC: DNSSEC groupthink versus improving DNS) Message-ID: <20080808233750.GA1799@sirocco.local> References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <20080808125558.GA56310@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080808125558.GA56310@commandprompt.com> User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, 08 Aug 2008, Andrew Sullivan wrote: > Moreover, arguments that individuals are suffering from group-think > runs perilously close to the line of _ad hominem_ attack. We have had > problems with that sort of discussion in the past, and I want to > remind everyone that we will not tolerate such attacks. If you have a > problem with the protocol, feel free to discuss it here. If you > instead have a problem just with what other people believe, then this > is not the right forum for your discussion. I wasn't going to jump into this thread, but I can't let this message pass without comment. Your message prompted me to re-read Bert's original "group-think" message and I find nothing inappropriate about it. It was certainly not "perilously close to the line of _ad hominem_ attack", nor was it an attack at all. I'd argue it was even on-topic, in that it questions if we're all doing the best engineering we can. How big is the worldwide DNS protocol engineering community? Certainly no more than hundreds of people. We have been breathing our own DNSSEC exhaust fumes for a long time. Personally, I find it refreshing for someone with demonstrated clue to come in and politely question things. I've seen several creative proposals to deal with the recently described cache-poisoning attacks and the urgency will spur further creative thinking. A hop-by-hop solution of adding more entropy would go a long way to addressing this attack. The lack of will I have perceived recently in this working group to pursue non-DNSSEC solutions frustrates me. A lot of us have a lot invested in DNSSEC, but shame on us as engineers if this is the only hammer in our toolbox and we use it to hit every nail. So I join Bert in asking everyone to keep an open mind, think critically and keep engineering. Matt -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 17:18:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D9D3A687A; Fri, 8 Aug 2008 17:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.030, 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 cUMxKVV8KwaG; Fri, 8 Aug 2008 17:18:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E68D13A687E; Fri, 8 Aug 2008 17:18:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRc3j-00079H-T1 for namedroppers-data@psg.com; Sat, 09 Aug 2008 00:11:51 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRc3f-00078q-TS for namedroppers@ops.ietf.org; Sat, 09 Aug 2008 00:11:49 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id BE785FF26C; Sat, 9 Aug 2008 10:11:48 +1000 (EST) Message-ID: <489CE0BE.6020902@e164.org> Date: Sat, 09 Aug 2008 10:11:42 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: David Ulevitch , Namedroppers Subject: Re: list policies References: <489BE047.1010100@e164.org> <489BE6BA.8050200@everydns.net> <489BE9A2.9040608@e164.org> <20080808224803.GA5217@vacation.karoshi.com.> In-Reply-To: <20080808224803.GA5217@vacation.karoshi.com.> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bmanning@vacation.karoshi.com wrote: > "Duane" - David is not the only one... he's just more vocal. > you invite confusion ... Basing identity on names is pointless, especially with how easily mail headers can be spoofed, well not even spoofed, but 'set'. Although should there be an uproar about you not setting your full name? > based on public records, I will presume this is you until or unless > othewise proven by credible parties. You can presume what ever you wish, does it change who I am by what name I choose to be known as? I wonder how the guy went who allegedly changed his name legally to Sony Playstation... http://www.wattpad.com/72957-List-of-unusual-personal-names- -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 8 18:14:04 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA5D3A6A5C; Fri, 8 Aug 2008 18:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.817 X-Spam-Level: X-Spam-Status: No, score=-3.817 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, 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 C6Q2hk7wDi-R; Fri, 8 Aug 2008 18:14:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EBA53A69EC; Fri, 8 Aug 2008 18:14:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRcw1-000B6e-W1 for namedroppers-data@psg.com; Sat, 09 Aug 2008 01:07:57 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KRcvx-000B6L-OL for namedroppers@ops.ietf.org; Sat, 09 Aug 2008 01:07:55 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 124242C1E52; Fri, 8 Aug 2008 18:07:52 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <819017D2-542B-4552-954B-9421995B24ED@virtualized.org> From: David Conrad To: Matt Larson In-Reply-To: <20080808233750.GA1799@sirocco.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Please stop this thread (was: OFFTOPIC: DNSSEC groupthink versus improving DNS) Date: Fri, 8 Aug 2008 18:07:51 -0700 References: <489AD5E3.20708@nlnetlabs.nl> <20080807134236.GA19024@outpost.ds9a.nl> <20080808125558.GA56310@commandprompt.com> <20080808233750.GA1799@sirocco.local> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Matt, > Your message prompted me to re-read Bert's original "group-think" > message and I find nothing inappropriate about it. It was certainly > not "perilously close to the line of _ad hominem_ attack", nor was it > an attack at all. I'd argue it was even on-topic, in that it > questions if we're all doing the best engineering we can. There is a difference between questioning whether we're doing the best that we can and implicitly accusing some number of us of intellectual laziness (at best) or actual dishonesty (at worst). As you may be aware, I am no fan of DNSSEC (to put it mildly) and have actively argued caution on spending resources on deploying DNSSEC in numerous venues because I felt the cost outweighed the benefits it would bring towards ameliorating the risks inherent in the DNS and felt those resources would be better applied to things like routing security. I have since changed my mind. The cost of deploying DNSSEC is high, however the risk is greater than I originally estimated, hence I believe the benefit is worth the cost. I still feel significant work needs to be done to DNSSEC to make it an effective defense, but it is clear to me that it is the right direction to go and we should go that direction sooner rather than later. Others may feel differently. However, I would not label those individuals nor would I accuse them of engaging in some deprecatory psychobabble buzzword of the day. Such labeling and accusations needlessly polarize discussions, which I feel does not contribute towards forward motion. But maybe that's just me. > A hop-by-hop solution of adding more entropy would > go a long way to addressing this attack. This particular instantiation of the attack, maybe (how do you protect against on-the-datapath spoofing with hop-by-hop entropy addition?). However, again, it is treating the symptoms, not the disease. How many times does the DNS community have to be bitten by the same fundamental bug before we finally squash that bug? Do you or Bert or any of his Me too! supporters think the problem is going to get better over time with computers (and hence zombies) and networks constantly getting better/faster/more numerous? > The lack of will I have > perceived recently in this working group to pursue non-DNSSEC > solutions frustrates me. I'm sorry, what lack of will are you talking about? I seem to recall a number of drafts being proposed and discussed that are not DNSSEC- related. Forgery-resilience and dns-0x20 are two examples. I have seen numerous people ask for solutions other than DNSSEC that address the fundamental weakness in the DNS. I myself would love to see an alternative to the bloated pig of a protocol, yet most of what I have seen appears to add even more fragility than DNSSEC and/or doesn't address the fundamental problem. > So I join Bert in asking everyone to keep an open mind, think >> > critically and keep engineering. Suggestions of keeping an open mind and thinking critically should also be applied to those who do not want to implement DNSSEC (for whatever reason). Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 9 19:15:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E94428C0F0; Sat, 9 Aug 2008 19:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.977 X-Spam-Level: * X-Spam-Status: No, score=1.977 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 K55bQusvzOJF; Sat, 9 Aug 2008 19:15:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9388C28C100; Sat, 9 Aug 2008 19:15:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS0Ko-000FGT-FI for namedroppers-data@psg.com; Sun, 10 Aug 2008 02:07:06 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS0Kk-000FG2-7U for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 02:07:04 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 69E5933C1A; Sun, 10 Aug 2008 03:06:56 +0100 (BST) Message-ID: <489E4D44.1080306@links.org> Date: Sun, 10 Aug 2008 03:07:00 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Duane CC: Mark Andrews , Paul Vixie , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> In-Reply-To: <489BBA1C.1040107@e164.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Duane wrote: > Mark Andrews wrote: > >> Well we could stop caching any DNS data. That's the only >> way to make it match the credit card industry model where >> changes are instantly available. > > Anyone have any idea how many credit card transactions per second occur? Far fewer than domain lookups. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 9 21:29:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE1F3A6A15; Sat, 9 Aug 2008 21:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, USER_IN_WHITELIST=-100] 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 iaFrwoJGEmkF; Sat, 9 Aug 2008 21:29:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D6313A6879; Sat, 9 Aug 2008 21:29:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS2Ss-000OkH-Gu for namedroppers-data@psg.com; Sun, 10 Aug 2008 04:23:34 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS2So-000ObT-Am for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 04:23:32 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m7A4LbIP018699; Sun, 10 Aug 2008 04:21:37 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m7A4Laup018698; Sun, 10 Aug 2008 04:21:36 GMT Date: Sun, 10 Aug 2008 04:21:36 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: Namedroppers Subject: how many angels can dance on the head of a pin? Message-ID: <20080810042136.GA18568@vacation.karoshi.com.> References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489E4D44.1080306@links.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Aug 10, 2008 at 03:07:00AM +0100, Ben Laurie wrote: > >Mark Andrews wrote: > > > >> Well we could stop caching any DNS data. That's the only > >> way to make it match the credit card industry model where > >> changes are instantly available. these days, i am thinking Mark is just baiting trolls. caches are too useful to abandon outright, but i'm pretty sure rethinking them is a great idea. --bill -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 9 23:32:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325A43A6808; Sat, 9 Aug 2008 23:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=0.029, 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 IcvnVtPclAKf; Sat, 9 Aug 2008 23:32:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3244A3A695B; Sat, 9 Aug 2008 23:32:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS4MR-0007zn-Ex for namedroppers-data@psg.com; Sun, 10 Aug 2008 06:25:03 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS4MN-0007z3-US for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 06:25:01 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 4E2FFFF26C; Sun, 10 Aug 2008 16:25:01 +1000 (EST) Message-ID: <489E89B6.6090208@e164.org> Date: Sun, 10 Aug 2008 16:24:54 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: bmanning@vacation.karoshi.com, Namedroppers Subject: Re: how many angels can dance on the head of a pin? References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> In-Reply-To: <20080810042136.GA18568@vacation.karoshi.com.> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bmanning@vacation.karoshi.com wrote: > On Sun, Aug 10, 2008 at 03:07:00AM +0100, Ben Laurie wrote: >>> Mark Andrews wrote: >>> >>>> Well we could stop caching any DNS data. That's the only >>>> way to make it match the credit card industry model where >>>> changes are instantly available. > > > these days, i am thinking Mark is just baiting trolls. > caches are too useful to abandon outright, but i'm pretty sure > rethinking them is a great idea. Caches seem to be the majority of concern in the last 3 to 4 weeks, I doubt anyone would disagree they can be useful just like web caching can be useful. The question is does the pros outweigh the cons? If shared caching at the ISP level is abandoned in favour of moving them closer to the end user, either on their computer or on the LAN but isn't accessible usually from beyond the LAN, would that not solve the majority of concerns currently being expressed? -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 00:43:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8D63A6888; Sun, 10 Aug 2008 00:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.485 X-Spam-Level: X-Spam-Status: No, score=0.485 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, 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 bcvHbhYz3sR0; Sun, 10 Aug 2008 00:43:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE88B3A67E3; Sun, 10 Aug 2008 00:43:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS5UT-000CyL-BD for namedroppers-data@psg.com; Sun, 10 Aug 2008 07:37:25 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS5UP-000CxX-He for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 07:37:23 +0000 Received: (qmail 68037 invoked from network); 10 Aug 2008 07:37:18 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Aug 2008 07:37:18 -0000 Date: Sun, 10 Aug 2008 09:37:18 +0200 (CEST) Message-Id: <20080810.093718.74690983.sthaug@nethelp.no> To: jeroen@unfix.org Cc: namedroppers@ops.ietf.org Subject: Re: first succesful (lab) spoof of a fully source port randomized server reported From: sthaug@nethelp.no In-Reply-To: <489C324B.1090603@spaghetti.zurich.ibm.com> References: <20080808111242.GI6566@outpost.ds9a.nl> <20080808.132607.41660169.sthaug@nethelp.no> <489C324B.1090603@spaghetti.zurich.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > Interesting enough. Meanwhile, if I have a recursive name server where > > the total traffic from the authoritative servers is in the range of > > 2 - 3 Mbps, I believe I could safely rate limit the traffic from each > > individual IP (representing a possibly spoofed authoritative server) to > > 100 - 200 kbps. This should raise the bar somewhat. > > /me reconfigures the 1M-node botnets to only send 100 packets/s per bot. > > Isn't distributed^Wcloud computing amazing? The attacker needs to spoof a *specific* source IP. The 1M node botnet doesn't help here. As Paul Vixie said on bind-users today: > note that any dns server with a host based firewall can implement a 100% > effective mitigation for the Polyakov attack, and it's possible that an > upstream/outboard firewall could also be made to do it. in freebsd ipfw > it looks like this: > > add pipe 1 udp from any 53 to 204.152.188.20 in > pipe 1 config mask src-ip 0xffffffff buckets 32768 bw 56Kbit/s queue 1 which is exactly what I was thinking of. Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 01:53:04 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2B43A683B; Sun, 10 Aug 2008 01:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 EEWKnc0YvuyK; Sun, 10 Aug 2008 01:53:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62F8C3A6811; Sun, 10 Aug 2008 01:53:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS6Zu-0005eH-27 for namedroppers-data@psg.com; Sun, 10 Aug 2008 08:47:06 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS6Zq-0005dH-1K for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 08:47:04 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 800DFC2DB3; Sun, 10 Aug 2008 09:46:52 +0100 (BST) Date: Sun, 10 Aug 2008 09:50:35 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Duane at e164 dot org , bmanning@vacation.karoshi.com, Namedroppers cc: Alex Bligh Subject: Re: how many angels can dance on the head of a pin? Message-ID: <01B9CF1DF0A4A4443A6E73A4@nimrod.local> In-Reply-To: <489E89B6.6090208@e164.org> References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 10 August 2008 16:24:54 +1000 Duane at e164 dot org wrote: > If shared caching at the ISP level is abandoned in favour of moving them > closer to the end user, either on their computer or on the LAN but isn't > accessible usually from beyond the LAN, would that not solve the > majority of concerns currently being expressed? I think ISP-level caching has only been targeted here because it's the most obvious way to obtain maximum impact for a cache poisoning attack. However, unfortunately, it's not the only way to use cache poisoning techniques. Not using ISP-level caching means (aside from the increased load): 1. Lookups would more often take place from behind a NAT. This can reduce entropy and make any given attack easier. Thus remember unlike many attack profiles, sticking a shared cache behind a NAT only serves to make things worse. 2. For specifically targeted attacks (e.g. where what Mallory really wants to do is poison the DNS for a particular mail smarthost), it gets no more difficult. Let's also remember that no intermediate caching at all means lots of additional load and complexity on the end user device (as full caching and recursion needs to be implemented there) and/or greater latency, as the recursive element requires lookups from "." upwards go over an end user link. Consider how, for instance, internet browsing on a mobile phone would be affected by a total absence of intermediate caching servers. To return to the original angels and pins discussion, when this group was first busying itself designing just how the lipstick might be applied to the DNSSEC pig, one of the original design criteria was that the security worked in such a way that it was transparent to dumb caches between authoritative server and end resolver. Solving integrity problems without dumb caches being the ones providing the data (i.e. assuming resolver could always talk directly to the authoritative server) would have been far easier, and would no doubt have resulted in a far less ugly beast of a protocol. If we were wrong to include caching as a design criterion at all (i.e. if we can ditch it now), then yes, that is seems consistent with your view of DNSSEC. I don't, however, think dropping caching is a realistic option, either for vanilla DNS or for DNSSEC or any substitute thereof. Alex -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 01:54:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B383A6811; Sun, 10 Aug 2008 01:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11, 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 vlSIA+2m048T; Sun, 10 Aug 2008 01:54:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEC303A68A0; Sun, 10 Aug 2008 01:54:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS6df-00066p-TV for namedroppers-data@psg.com; Sun, 10 Aug 2008 08:50:59 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS6dc-00066K-CH for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 08:50:58 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 9678AC2DB3; Sun, 10 Aug 2008 09:50:50 +0100 (BST) Date: Sun, 10 Aug 2008 09:54:34 +0100 From: Alex Bligh Reply-To: Alex Bligh To: sthaug@nethelp.no, jeroen@unfix.org cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: first succesful (lab) spoof of a fully source port randomized server reported Message-ID: <1BDC660168661516D7087994@nimrod.local> In-Reply-To: <20080810.093718.74690983.sthaug@nethelp.no> References: <20080808111242.GI6566@outpost.ds9a.nl> <20080808.132607.41660169.sthaug@nethelp.no> <489C324B.1090603@spaghetti.zurich.ibm.com> <20080810.093718.74690983.sthaug@nethelp.no> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 10 August 2008 09:37:18 +0200 sthaug@nethelp.no wrote: > The attacker needs to spoof a *specific* source IP. The 1M node botnet > doesn't help here. As Paul Vixie said on bind-users today: Let's suppose the attacker /does/ spoof a specific source IP (or a small group thereof), and uses it to target servers configured like this... >> note that any dns server with a host based firewall can implement a 100% >> effective mitigation for the Polyakov attack, and it's possible that an >> upstream/outboard firewall could also be made to do it. in freebsd ipfw >> it looks like this: >> >> add pipe 1 udp from any 53 to 204.152.188.20 in >> pipe 1 config mask src-ip 0xffffffff buckets 32768 bw 56Kbit/s queue 1 > > which is exactly what I was thinking of. ...I think we've just succeeded in converting a poisoning attack into a DoS vector. Just spoof the IPs of the root nameservers, or NS for google.com or whatever. I realise DoS of root nameserver access is probably less dangerous that poisoning then, but... Alex -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 02:12:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB343A6C6D; Sun, 10 Aug 2008 02:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.028, 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 ZDNFGAQabylv; Sun, 10 Aug 2008 02:12:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8A353A6AA5; Sun, 10 Aug 2008 02:12:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS6to-000FDb-PW for namedroppers-data@psg.com; Sun, 10 Aug 2008 09:07:40 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS6tl-000F5q-8R for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 09:07:39 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 1746BFF26C; Sun, 10 Aug 2008 19:07:31 +1000 (EST) Message-ID: <489EAFCD.2090204@e164.org> Date: Sun, 10 Aug 2008 19:07:25 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Alex Bligh CC: bmanning@vacation.karoshi.com, Namedroppers Subject: Re: how many angels can dance on the head of a pin? References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> In-Reply-To: <01B9CF1DF0A4A4443A6E73A4@nimrod.local> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Alex Bligh wrote: > 1. Lookups would more often take place from behind a NAT. This can reduce > entropy and make any given attack easier. Thus remember unlike many > attack profiles, sticking a shared cache behind a NAT only serves > to make things worse. I fail to see how this would apply, the reason for randomising the ports was for publicly accessible caches, such that ISPs run, which can be queried by the attacker and also for the attacker to send fake replies at the same time. If the attacker can't send requests and replies they would need to be in the path to alter things. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 02:22:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D323A6CD9; Sun, 10 Aug 2008 02:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 09DzVPS-Ax5f; Sun, 10 Aug 2008 02:22:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03C263A68A0; Sun, 10 Aug 2008 02:22:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS73d-000J22-Pq for namedroppers-data@psg.com; Sun, 10 Aug 2008 09:17:49 +0000 Received: from [2001:14b0:202:1::a7] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS73Z-000J1V-TP for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 09:17:47 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1KS72n-0007eB-Hf; Sun, 10 Aug 2008 11:16:57 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1KS72n-0004Pu-1O; Sun, 10 Aug 2008 11:16:57 +0200 From: Florian Weimer To: Mark Andrews Cc: Duane , bert hubert , Namedroppers Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS References: <200808080052.m780qMd2002912@drugs.dv.isc.org> Date: Sun, 10 Aug 2008 11:16:57 +0200 In-Reply-To: <200808080052.m780qMd2002912@drugs.dv.isc.org> (Mark Andrews's message of "Fri, 08 Aug 2008 10:52:22 +1000") Message-ID: <87r68xut4m.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Mark Andrews: > You could have online keys and sign every response with a > ttl + clock skew based window. This requires that the > private key is on all slaves. The crypto hardware guys > will love you :-) Crypto accelerators for RSA are dead. You can buy four 64x64 -> 128 bit multipliers supporting a rate of more than 0.5 billion multiplications per second each for 150 EUR. > Which can be completely automated. Has already been in > some senarios. I havn't re-signed my zones for months > despite using a 30 day expiry period on the signatures. > > It is set and forget. More and more of the process will > become "set and forget" as the tools develop. It's not just the tools. It requires a change of minds, too. For a long time, DNSSEC operations were based not on classic DNS approaches, but on the CA/PKI model (involving off-line keys, different registration requirements, audit trails etc.). However, for obvious reasons, hardly anybody wanted to deploy it this way. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 02:23:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25C63A6952; Sun, 10 Aug 2008 02:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.486 X-Spam-Level: * X-Spam-Status: No, score=1.486 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001, 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 A7W6S1GjGw2J; Sun, 10 Aug 2008 02:23:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E336C3A68A0; Sun, 10 Aug 2008 02:22:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS74c-000JaS-Hq for namedroppers-data@psg.com; Sun, 10 Aug 2008 09:18:50 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS74Y-000JX1-NV for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 09:18:48 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 55328C2DA3; Sun, 10 Aug 2008 10:18:43 +0100 (BST) Date: Sun, 10 Aug 2008 10:22:27 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Duane at e164 dot org cc: bmanning@vacation.karoshi.com, Namedroppers , Alex Bligh Subject: Re: how many angels can dance on the head of a pin? Message-ID: <6751CAB7406138E7F72B474E@nimrod.local> In-Reply-To: <489EAFCD.2090204@e164.org> References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> <489EAFCD.2090204@e164.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 10 August 2008 19:07:25 +1000 Duane at e164 dot org wrote: >> 1. Lookups would more often take place from behind a NAT. This can >> reduce entropy and make any given attack easier. Thus remember unlike >> many attack profiles, sticking a shared cache behind a NAT only >> serves to make things worse. > > I fail to see how this would apply, the reason for randomising the ports > was for publicly accessible caches, such that ISPs run, which can be > queried by the attacker and also for the attacker to send fake replies > at the same time. > > If the attacker can't send requests and replies they would need to be in > the path to alter things. Some NATs (e.g.) have the behaviour of using a constant source port by DNS, or a source port incrementing by 1 for each query (which is just as bad). So, if the caching resolver is behind that NAT (or more accurately NAPT) then simply spoof the NAT's external IP address and guess the source port it used (using that as your destination port). The NAT then helpfully rewrites this to the randomised source port inside the NAT. Roy Arends has been doing a survey of NAT behaviour. I'm not sure whether he's demonstrated poisoning through broken NAT with a randomised source port cache in the lab, but I don't think it should be hard; a NAPT which rewrites the source port to a constant value effectively removes all the entropy given by the recent bind patches. I mentioned this on namedroppers a while ago but I was being somewhat cryptic as the nature of the attack itself wasn't public then. Alex -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 02:33:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7E83A68A0; Sun, 10 Aug 2008 02:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.271 X-Spam-Level: * X-Spam-Status: No, score=1.271 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_20=-0.74, 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 JfZqGmTy6i7W; Sun, 10 Aug 2008 02:33:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75E1C3A67F9; Sun, 10 Aug 2008 02:33:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS7DY-000Pf7-6c for namedroppers-data@psg.com; Sun, 10 Aug 2008 09:28:04 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS7DU-000Pdz-J1 for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 09:28:02 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 814F6C2DB3; Sun, 10 Aug 2008 10:27:56 +0100 (BST) Date: Sun, 10 Aug 2008 10:31:41 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , Duane at e164 dot org cc: bmanning@vacation.karoshi.com, Namedroppers , Alex Bligh Subject: Re: how many angels can dance on the head of a pin? Message-ID: <70CC931622BD9710F13283EA@nimrod.local> In-Reply-To: <6751CAB7406138E7F72B474E@nimrod.local> References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> <489EAFCD.2090204@e164.org> <6751CAB7406138E7F72B474E@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 10 August 2008 10:22:27 +0100 Alex Bligh wrote: > Some NATs (e.g.) have the behaviour of using a constant source port by > DNS, or a source port incrementing by 1 for each query (which is just > as bad). I should have added that whilst non-broken NATs don't make things worse (*), they also don't make things better. * = though arguably anything that compresses the > If the attacker can't send requests and replies they would need to be in > the path to alter things. The data path being directly attacked is that from the caching server (via the NAT) to the authoritative server (which is partly outside the NAT) not between the stub resolver and the caching server (which is entirely inside the NAT). Alex -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 04:22:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959EB3A679F; Sun, 10 Aug 2008 04:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_50=0.001, FH_RELAY_NODNS=1.451, 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 v-ZAtWOUs3yu; Sun, 10 Aug 2008 04:22:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4C5A3A6A18; Sun, 10 Aug 2008 04:22:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS8rr-0000gQ-DY for namedroppers-data@psg.com; Sun, 10 Aug 2008 11:13:47 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS8rn-0000fr-0p for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 11:13:45 +0000 Received: (qmail 398 invoked from network); 10 Aug 2008 11:07:26 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Aug 2008 11:07:26 -0000 Date: Sun, 10 Aug 2008 13:07:23 +0200 (CEST) Message-Id: <20080810.130723.71154003.sthaug@nethelp.no> To: duane@e164.org Cc: alex@alex.org.uk, bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: how many angels can dance on the head of a pin? From: sthaug@nethelp.no In-Reply-To: <489EAFCD.2090204@e164.org> References: <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> <489EAFCD.2090204@e164.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > 1. Lookups would more often take place from behind a NAT. This can reduce > > entropy and make any given attack easier. Thus remember unlike many > > attack profiles, sticking a shared cache behind a NAT only serves > > to make things worse. > > I fail to see how this would apply, the reason for randomising the ports > was for publicly accessible caches, such that ISPs run, which can be > queried by the attacker and also for the attacker to send fake replies > at the same time. At least for the ISP *I* work for, our publicly accessible caches are accessible for direct recursive queries only from IP addresses within our own AS, not from the Internet at large. There are of course lots ways an attacker can *indirectly* get queries to be made from IPs within our AS (see for instance Dan Kaminsky's presentation). On the other hand, we implement RPF checking for our customers, so an attacker can *not* easily get our customers to spoof addresses and thus participate in the poisoning part of the attack. Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 04:34:23 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6567A28C16B; Sun, 10 Aug 2008 04:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 iQhory+funSo; Sun, 10 Aug 2008 04:34:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75EAF28C132; Sun, 10 Aug 2008 04:34:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS97o-0006AR-HZ for namedroppers-data@psg.com; Sun, 10 Aug 2008 11:30:16 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS97h-00069R-LL for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 11:30:14 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 90C2933C45; Sun, 10 Aug 2008 12:30:06 +0100 (BST) Message-ID: <489ED142.8010500@links.org> Date: Sun, 10 Aug 2008 12:30:10 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Alex Bligh CC: Duane at e164 dot org , bmanning@vacation.karoshi.com, Namedroppers Subject: Re: how many angels can dance on the head of a pin? References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> <489EAFCD.2090204@e164.org> <6751CAB7406138E7F72B474E@nimrod.local> <70CC931622BD9710F13283EA@nimrod.local> In-Reply-To: <70CC931622BD9710F13283EA@nimrod.local> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Alex Bligh wrote: > > > --On 10 August 2008 10:22:27 +0100 Alex Bligh wrote: > >> Some NATs (e.g.) have the behaviour of using a constant source port by >> DNS, or a source port incrementing by 1 for each query (which is just >> as bad). > > I should have added that whilst non-broken NATs don't make things worse > (*), they also don't make things better. Not so, actually. If the NAT does random port assignment, then the resolver's assignment can be predictable. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 05:06:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85E928C0FB; Sun, 10 Aug 2008 05:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.289 X-Spam-Level: * X-Spam-Status: No, score=1.289 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_20=-0.74, 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 sQ8qSd2IBBcc; Sun, 10 Aug 2008 05:06:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE9B53A6DBB; Sun, 10 Aug 2008 05:06:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS9YV-000B2n-Ti for namedroppers-data@psg.com; Sun, 10 Aug 2008 11:57:51 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS9YS-000B2V-9h for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 11:57:50 +0000 Received: from [192.168.100.3] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 43346C2DA3; Sun, 10 Aug 2008 12:57:43 +0100 (BST) Date: Sun, 10 Aug 2008 13:01:26 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie cc: Duane at e164 dot org , bmanning@vacation.karoshi.com, Namedroppers , Alex Bligh Subject: Re: how many angels can dance on the head of a pin? Message-ID: <9638F8EA548C822160EF40E4@nimrod.local> In-Reply-To: <489ED142.8010500@links.org> References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> <489EAFCD.2090204@e164.org> <6751CAB7406138E7F72B474E@nimrod.local> <70CC931622BD9710F13283EA@nimrod.local> <489ED142.8010500@links.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ben, --On 10 August 2008 12:30:10 +0100 Ben Laurie wrote: >> I should have added that whilst non-broken NATs don't make things worse >> (*), they also don't make things better. > > Not so, actually. If the NAT does random port assignment, then the > resolver's assignment can be predictable. Yep quite possibly. My post was precaffeinated and I was referring to resolvers that were fixed-up, i.e. unpredictable. In practice though, I suspect (Roy will know better) that a NAT seeing traffic from a single internal (src IP, src port) tuple will continue to map that to a single external (src IP, src port) tuple because, unless it's doing deeper inspection than normal, it doesn't know which packets form separable conversations. So the improvement would only occur where the broken resolver used a non-constant but predictable port, which is the minority of cases. My point was that one should not think one can just stick a caching resolver behind a NAT device and suddenly achieve immunity from this particular poisoning attack. I presume you agree with that? Alex -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 05:15:09 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54F273A680E; Sun, 10 Aug 2008 05:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.931 X-Spam-Level: * X-Spam-Status: No, score=1.931 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 YYxcl8ez47T8; Sun, 10 Aug 2008 05:15:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DECB3A679F; Sun, 10 Aug 2008 05:15:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS9j5-000FTL-Ay for namedroppers-data@psg.com; Sun, 10 Aug 2008 12:08:47 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KS9iz-000FSN-1O for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 12:08:45 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7604B33C1C; Sun, 10 Aug 2008 13:08:39 +0100 (BST) Message-ID: <489EDA4C.3080300@links.org> Date: Sun, 10 Aug 2008 13:08:44 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Alex Bligh CC: Duane at e164 dot org , bmanning@vacation.karoshi.com, Namedroppers Subject: Re: how many angels can dance on the head of a pin? References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> <489EAFCD.2090204@e164.org> <6751CAB7406138E7F72B474E@nimrod.local> <70CC931622BD9710F13283EA@nimrod.local> <489ED142.8010500@links.org> <9638F8EA548C822160EF40E4@nimrod.local> In-Reply-To: <9638F8EA548C822160EF40E4@nimrod.local> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Alex Bligh wrote: > Ben, > > --On 10 August 2008 12:30:10 +0100 Ben Laurie wrote: > >>> I should have added that whilst non-broken NATs don't make things worse >>> (*), they also don't make things better. >> >> Not so, actually. If the NAT does random port assignment, then the >> resolver's assignment can be predictable. > > Yep quite possibly. My post was precaffeinated and I was referring to > resolvers that were fixed-up, i.e. unpredictable. In practice though, I > suspect (Roy will know better) that a NAT seeing traffic from a single > internal (src IP, src port) tuple will continue to map that to a single > external (src IP, src port) tuple because, unless it's doing deeper > inspection than normal, it doesn't know which packets form separable > conversations. So the improvement would only occur where the broken > resolver used a non-constant but predictable port, which is the minority of > cases. > > My point was that one should not think one can just stick a caching > resolver behind a NAT device and suddenly achieve immunity from this > particular poisoning attack. I presume you agree with that? Depends on your resolver, as you explained above. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 08:46:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3603A6DBB; Sun, 10 Aug 2008 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] 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 z4vFxC9h8Ex9; Sun, 10 Aug 2008 08:46:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44A2E3A6B36; Sun, 10 Aug 2008 08:46:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSD3J-00018g-K1 for namedroppers-data@psg.com; Sun, 10 Aug 2008 15:41:53 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSD3G-00018G-1n for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 15:41:51 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1CC1EA200B; Sun, 10 Aug 2008 15:41:40 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: sthaug@nethelp.no cc: duane@e164.org, alex@alex.org.uk, bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 10 Aug 2008 13:07:23 +0200." <20080810.130723.71154003.sthaug@nethelp.no> References: <489E89B6.6090208@e164.org> <01B9CF1DF0A4A4443A6E73A4@nimrod.local> <489EAFCD.2090204@e164.org> <20080810.130723.71154003.sthaug@nethelp.no> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 10 Aug 2008 15:41:40 +0000 Message-ID: <40886.1218382900@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 1CC1EA200B.AFF16 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: how many angels can dance on the head of a pin? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: sthaug@nethelp.no > > At least for the ISP *I* work for, our publicly accessible caches are > accessible for direct recursive queries only from IP addresses within > our own AS, not from the Internet at large. may i ask that you write an FYI RFC for dnsop explaining this policy with special emphasis on (1) how you did it, (2) how easy it was to do it, and (3) how beneficial it's been that you did it. many of your coopetitors across the industry are not yet following in these excellent footsteps. (and it won't make you safe from spoofing if you have a dialup or enduser population who can be infested with bots, or if you have SMTP servers who can be triggered to make DNS requests for an attacker with very fine timing, but this kind of network hygiene certainly limits the scope of the problem.) (if you also enforce BCP38 against your customers, you might mention this in passing in your FYI RFC, again explaining how easy it was and how much cost and/or benefit you get from it.) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 08:47:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9950528C167; Sun, 10 Aug 2008 08:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-1.953, 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 9pk93g8KKBxH; Sun, 10 Aug 2008 08:47:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 999103A6B36; Sun, 10 Aug 2008 08:47:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSD1Y-0000y0-SS for namedroppers-data@psg.com; Sun, 10 Aug 2008 15:40:04 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSD1V-0000x8-C0 for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 15:40:03 +0000 Received: from [165.227.249.203] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7AFchOn052948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Aug 2008 08:38:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080810042136.GA18568@vacation.karoshi.com.> References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> Date: Sun, 10 Aug 2008 08:38:41 -0700 To: Namedroppers From: Paul Hoffman Subject: Re: how many angels can dance on the head of a pin? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: "Caching" is not the currently-discussed problem: it is a too-brief shorthand for the currently-discussed problem. A better problem statement might be "caches (a) that can be easily poisoned and (b) from which data that will be trusted by compliant resolvers will be served". This WG seems to be trying to make (a) harder to make the attack harder. We haven't spent much time analyzing how to fix (b), which might give us a much better fix. Assuming a poisoned cache, if either the poison is never emitted from the cache, or if resolvers stop believing emitted poison, the attack fails completely. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 11:09:26 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9843A6C10; Sun, 10 Aug 2008 11:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.405 X-Spam-Level: ** X-Spam-Status: No, score=2.405 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 FuXEJ-m4bTKY; Sun, 10 Aug 2008 11:09:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F169F3A68B0; Sun, 10 Aug 2008 11:09:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSFFH-000Ilk-1I for namedroppers-data@psg.com; Sun, 10 Aug 2008 18:02:23 +0000 Received: from [204.9.75.100] (helo=kansas.jhsoft.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSFFD-000Ika-3D for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 18:02:20 +0000 Received: from hemsen by kansas.jhsoft.com (MDaemon PRO v9.6.2) with ESMTP id md50000107922.msg for ; Sun, 10 Aug 2008 18:02:18 +0000 From: =?iso-8859-1?Q?Jesper_G._H=F8y?= To: Cc: References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> <028a01c8f18c$7f6bb620$7e432260$@com> <572015C3F44995F54736D38B@Ximines.local> <029401c8f196$c5822bd0$50868370$@com> <489F0F8E.6020607@gis.net> In-Reply-To: <489F0F8E.6020607@gis.net> Subject: RE: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Sun, 10 Aug 2008 20:02:06 +0200 Message-ID: <021101c8fb13$34634310$9d29c930$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj7AfORCL8Fla8BSxajfSrdKiyT2QADPx4A Content-Language: en-us X-Authenticated-Sender: jesper@jhsoft.com X-MDRemoteIP: 87.56.149.202 X-Return-Path: jesper@jhsoft.com X-Envelope-From: jesper@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Danny Mayer wrote: > > I agree - and I am not arguing against DNSSEC as a whole. > > As I started out saying - "There may be other good reasons to push > DNSSEC" - distributing public keys certainly may be one of those. > > However, this was in regards to the Kaminsky bug, which is all about > carrying IP addresses (A/AAAA RRSets in response Additional section). > > So to clarify: DNSSEC doesn't make much difference when the bad guy > > is on-the-wire - for IP address records. > That's not true either way. DNSSEC will protect you from the bad guy on > the wire. My point was that it doesn't matter that you get the correct IP address (signed by DNSSEC) if the bad buy is on the wire. In that scenario he can just spoof that IP address and replace web-sites etc. with his own data. Only SSL can protect you here. > But the A/AAAA records in the additional section is not the > only part that needs protection. The authority section also needs > protection since they contain the authorative nameserver names. By > diverting further queries to their own nameservers they no longer need > a cachepoisoning attack. Right - but NS-records point to host names which point to A/AAAA records which point to IP addresses. Comes back to the same thing - if the bad guy is on the wire, you are still in trouble... DNSSEC or not. > > Without having thought this through, I think resolvers could probably > > ignore anything else (non A/AAAA RRSets) in the response Additional > section - limiting the Kaminsky bug to such records. But that's a > different thread... > And what about the authority section? Se above. > > Carrying IP addresses is still by far the biggest use of DNS. > No it isn't. MX records are almost as big. And then there are SRV > records. OK - but MX-records point to host names which point to A/AAAA records which point to IP addresses... If the bad guy is on the wire, he can intercept and replace your SMTP traffic anyway. DNSSEC or not. SRV-records also point to host names which... > > And I am just not convinced that it is a good idea to apply DNSSEC's > complexity to this most fundamental part of our Internet. > > I believe a simpler solution stands a much better chance of actually > being implemented and used, and therefore is more secure overall. > > Especially if such a solution does not require any end-user action > other than patching. > Go look at Dan Kaminsky's slides for the fuller picture I see nothing in the slides that suggest that DNSSEC is the only true solution or that rule out other solutions. On the contrary it seems to me that Dan Kaminsky himself is suggesting other solutions in his latest blog entry on the matter... Sincerely, Jesper -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 10 11:37:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69DE3A6902; Sun, 10 Aug 2008 11:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 pDAABt2IVxnD; Sun, 10 Aug 2008 11:37:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F9773A69DE; Sun, 10 Aug 2008 11:37:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSFhC-0006j2-7n for namedroppers-data@psg.com; Sun, 10 Aug 2008 18:31:14 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSFh8-0006hI-Nh for namedroppers@ops.ietf.org; Sun, 10 Aug 2008 18:31:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 42B18A669B; Sun, 10 Aug 2008 18:30:57 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Alex Bligh cc: sthaug@nethelp.no, jeroen@unfix.org, namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 10 Aug 2008 09:54:34 +0100." <1BDC660168661516D7087994@nimrod.local> References: <20080808111242.GI6566@outpost.ds9a.nl> <20080808.132607.41660169.sthaug@nethelp.no> <489C324B.1090603@spaghetti.zurich.ibm.com> <20080810.093718.74690983.sthaug@nethelp.no> <1BDC660168661516D7087994@nimrod.local> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 10 Aug 2008 18:30:57 +0000 Message-ID: <59801.1218393057@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 42B18A669B.36BA0 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: first succesful (lab) spoof of a fully source port randomized server reported Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > >> add pipe 1 udp from any 53 to 204.152.188.20 in > >> pipe 1 config mask src-ip 0xffffffff buckets 32768 bw 56Kbit/s queue 1 > ...I think we've just succeeded in converting a poisoning attack into a > DoS vector. Just spoof the IPs of the root nameservers, or NS for > google.com or whatever. I realise DoS of root nameserver access is > probably less dangerous that poisoning then, but... there are easier ways to DoS a nameserver. this isn't an exciting new vector. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 09:39:33 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5C13A6C06; Mon, 11 Aug 2008 09:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.066 X-Spam-Level: X-Spam-Status: No, score=-101.066 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_20=-0.74, USER_IN_WHITELIST=-100] 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 GuEVNiKrHgj3; Mon, 11 Aug 2008 09:39:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 35A603A6BBE; Mon, 11 Aug 2008 09:39:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSaHD-0001ma-Sj for namedroppers-data@psg.com; Mon, 11 Aug 2008 16:29:47 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSaH9-0001US-6x for namedroppers@ops.ietf.org; Mon, 11 Aug 2008 16:29:45 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m7B2qnIP003220; Mon, 11 Aug 2008 02:52:49 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m7B2qgr8003219; Mon, 11 Aug 2008 02:52:42 GMT Date: Mon, 11 Aug 2008 02:52:42 +0000 From: bmanning@vacation.karoshi.com To: Duane at e164 dot org Cc: bmanning@vacation.karoshi.com, Namedroppers Subject: Re: how many angels can dance on the head of a pin? Message-ID: <20080811025242.GA3158@vacation.karoshi.com.> References: <200808080237.m782bBqk005628@drugs.dv.isc.org> <489BBA1C.1040107@e164.org> <489E4D44.1080306@links.org> <20080810042136.GA18568@vacation.karoshi.com.> <489E89B6.6090208@e164.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489E89B6.6090208@e164.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > >>>> Well we could stop caching any DNS data. That's the only > >>>> way to make it match the credit card industry model where > >>>> changes are instantly available. > > > > > > these days, i am thinking Mark is just baiting trolls. > > caches are too useful to abandon outright, but i'm pretty sure > > rethinking them is a great idea. > > Caches seem to be the majority of concern in the last 3 to 4 weeks, I > doubt anyone would disagree they can be useful just like web caching can > be useful. > > The question is does the pros outweigh the cons? > > If shared caching at the ISP level is abandoned in favour of moving them > closer to the end user, either on their computer or on the LAN but isn't > accessible usually from beyond the LAN, would that not solve the > majority of concerns currently being expressed? > > -- > > Best regards, > Duane if your caching at all (near/far) your caching. if you keep zero state "...stop caching any DNS data... (Mark Andrews)" then you are not. my gentle assertion was that caching is valuable, should be kept/rethought. theevents of the day are only tangential to cache design. -IF- caching is to be re-thought, then it should be carefully thought out, not a twitch reaction to a (perceived) threat. --bill -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 10:55:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7EF93A6B27; Mon, 11 Aug 2008 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] 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 XWMUpHH7M8Iv; Mon, 11 Aug 2008 10:55:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F9C53A6B7D; Mon, 11 Aug 2008 10:55:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSbXX-000EDt-SA for namedroppers-data@psg.com; Mon, 11 Aug 2008 17:50:43 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSbXU-000EDN-Eo for namedroppers@ops.ietf.org; Mon, 11 Aug 2008 17:50:42 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id C814511401E for ; Mon, 11 Aug 2008 01:19:10 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 1BC09E6024 for ; Mon, 11 Aug 2008 01:19:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7B1If7Z052960 for ; Mon, 11 Aug 2008 11:18:41 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808110118.m7B1If7Z052960@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Sun, 10 Aug 2008 20:02:06 +0200." <021101c8fb13$34634310$9d29c930$@com> Date: Mon, 11 Aug 2008 11:18:41 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > OK - but MX-records point to host names which point to A/AAAA records which > point to IP addresses... > If the bad guy is on the wire, he can intercept and replace your SMTP > traffic anyway. > DNSSEC or not. > > SRV-records also point to host names which... DNS security is required for SMTP security to work. How else fo you securely workout who you are supposed to be communicating with. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 12:12:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A533A6895; Mon, 11 Aug 2008 12:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.346 X-Spam-Level: *** X-Spam-Status: No, score=3.346 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_LWSHORTT=1.24, WHOIS_NETSOLPR=0.001] 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 AQmiIt2emmmN; Mon, 11 Aug 2008 12:12:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 579B13A6822; Mon, 11 Aug 2008 12:12:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KScgy-000Lwf-Bv for namedroppers-data@psg.com; Mon, 11 Aug 2008 19:04:32 +0000 Received: from [216.85.69.3] (helo=cgi.jachomes.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KScgu-000LwG-MT for namedroppers@psg.com; Mon, 11 Aug 2008 19:04:30 +0000 Received: by cgi.jachomes.com (Postfix, from userid 1002) id F33B2E00084; Mon, 11 Aug 2008 15:04:27 -0400 (EDT) Date: Mon, 11 Aug 2008 15:04:27 -0400 From: "Jay R. Ashworth" To: namedroppers@psg.com Subject: Why *can* cached DNS replies be overwritten? Message-ID: <20080811190427.GD9082@cgi.jachomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ cross-posted from NANOG, cause vix told me to :-) On Mon, Aug 11, 2008 at 11:20:07AM -0400, Leo Bicknell wrote: > If your vendor told you that you are not at risk they are wrong, > and need to go re-read the Kaminski paper. EVERYONE is vunerable, > the only question is if the attack takes 1 second, 1 minute, 1 hour > or 1 day. While possibly interesting for short term problem > management none of those are long term fixes. I'm not sure your > customers care when .COM is poisoned if it took the attacker 1 > second or 1 day. Correct me if I'm wrong, Leo, but your assertion turns on the fact that the server will accept an overwriting cache entry for something it already has cacheed, does it not? Do djb and Power in fact do that? If they don't, the window of opportunity to poison something like .com is limited to the period between when that entry expires from the local server's cache and the next time it hears a reply -- which will be the time after that expiry when someone next requests a .com name; IE almost immediately, no? Everyone seems to continue asking "why can poisoning overwrite already cached answer" and no one seems to be answering, and, unless I'm a moron (which is not impossible), that's the crux of this issue. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 13:08:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7FC3A693E; Mon, 11 Aug 2008 13:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 qFrcQ76omBCY; Mon, 11 Aug 2008 13:08:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E60C3A6892; Mon, 11 Aug 2008 13:08:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdcj-0002VO-10 for namedroppers-data@psg.com; Mon, 11 Aug 2008 20:04:13 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdcf-0002Uv-Dj for namedroppers@ops.ietf.org; Mon, 11 Aug 2008 20:04:11 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id A0C472CCA40; Mon, 11 Aug 2008 13:04:08 -0700 (PDT) Cc: Namedroppers WG Message-Id: From: David Conrad To: =?ISO-8859-1?Q?Jesper_G._H=F8y?= In-Reply-To: <021101c8fb13$34634310$9d29c930$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Mon, 11 Aug 2008 13:04:07 -0700 References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> <028a01c8f18c$7f6bb620$7e432260$@com> <572015C3F44995F54736D38B@Ximines.local> <029401c8f196$c5822bd0$50868370$@com> <489F0F8E.6020607@gis.net> <021101c8fb13$34634310$9d29c930$@com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Jesper, On Aug 10, 2008, at 11:02 AM, Jesper G. H=F8y wrote: > My point was that it doesn't matter that you get the correct IP =20 > address > (signed by DNSSEC) if the bad buy is on the wire. > In that scenario he can just spoof that IP address and replace web-=20 > sites etc. with his own data. Ignoring for the moment the fact that 134 million (or even 4 billion) =20= packets isn't that much anymore (and will be less and less over time), =20= the DNS lookup 'wire' is logically distinct from the content 'wire'. =20= The ability to "intercept spoof" a DNS response can occur anywhere on =20= the DNS lookup 'wire', not only on the content producer/consumer's =20 local LAN. By not protecting the packet content, you open yourself up =20= to a distinct set of attackers beyond the local wire. > Only SSL can protect you here. As Dan Kaminsky points out: "SSL certs themselves are dependent on the =20= DNS". > I see nothing in the slides that suggest that DNSSEC is the only true > solution or that rule out other solutions. Indeed. DNSSEC may not be the 'only true solution' and there may be =20 other solutions. The vast majority of folks who have burned brain =20 cells and stomach lining on DNSSEC could be complete idiots and an =20 obvious, complete, lightweight, and architecturally clean solution =20 could be staring all of us in the face. I look forward to reading =20 your draft on the topic (note that I wouldn't consider a solution =20 that ignores the risk on the DNS lookup 'wire' complete, but maybe =20 that's just me). I would however note that partly as a result of this latest incident =20 of having it pointed out that it is better to protect data content =20 than the data channel, the amount of DNS infrastructure out there =20 capable of supporting DNSSEC (and the political will to see it =20 deployed) has likely taken a very significant jump... Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 13:09:16 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C6B3A6856; Mon, 11 Aug 2008 13:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 omUtf0xOifw5; Mon, 11 Aug 2008 13:09:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 01FAC3A688E; Mon, 11 Aug 2008 13:09:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdc5-0002Qv-7X for namedroppers-data@psg.com; Mon, 11 Aug 2008 20:03:33 +0000 Received: from [76.96.30.16] (helo=QMTA01.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdc1-0002QV-J2 for namedroppers@ops.ietf.org; Mon, 11 Aug 2008 20:03:31 +0000 Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id 154e1a01f1HpZEsA183V1A; Mon, 11 Aug 2008 20:03:29 +0000 Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id 183T1a00B2P9w058a83UrY; Mon, 11 Aug 2008 20:03:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=RsSsFw0Y2BEA:10 a=cY4EPkZNyTwA:10 a=48vgC7mUAAAA:8 a=mXwbroN_EYgI7aQMUw0A:9 a=By90Z84A-yeFKhaXTKYA:7 a=TEac13WDZ9pLD_4biGj2qpodl_oA:4 a=iw4bf7yTzGQA:10 a=h9s5Ru71U4oA:10 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Aug 2008 16:03:27 -0400 To: Mark Andrews ,namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: <200808110118.m7B1If7Z052960@drugs.dv.isc.org> References: <200808110118.m7B1If7Z052960@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: At 09:18 PM 8/10/2008, Mark Andrews wrote: >> OK - but MX-records point to host names which point to A/AAAA records which >> point to IP addresses... >> If the bad guy is on the wire, he can intercept and replace your SMTP >> traffic anyway. >> DNSSEC or not. >> >> SRV-records also point to host names which... > > DNS security is required for SMTP security to work. Absurd claim. >How > else fo you securely workout who you are supposed to be > communicating with. Um.. maybe with SSL? Check the offered certificate matches some criteria to relate it to the name and that it chains back to someplace you trust. I'm sure there are all sorts of arguments you could make on how this isn't sufficient - but DNSSEC only at MOST gives me a validatable mapping between a domain name and the ultimate IP address - it doesn't protect against post-resolution attacks of various flavors, so I could argue DNSSEC isn't sufficient. SSL/TLS has the nice properties that I can deploy it per server (e.g. I can get incremental benefit), that I can do off-tree validations, and that a hell of a lot of servers already implement it. DNSSEC can't be deployed per server (requires the zone to be signed even if mostly opted out), can't do off-tree validations (DLV is a hack - I might split a hair and call it off-tree, but it really is more of a trust anchor registry than anything else), and few SMTP servers (any?) implement DNSSEC resolution/validation. > Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > >-- >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: -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 13:14:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6585A3A6B08; Mon, 11 Aug 2008 13:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.143 X-Spam-Level: ** X-Spam-Status: No, score=2.143 tagged_above=-999 required=5 tests=[AWL=-1.407, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 7tt0zQinc3NE; Mon, 11 Aug 2008 13:14:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D1733A688E; Mon, 11 Aug 2008 13:14:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdiA-00037v-Lq for namedroppers-data@psg.com; Mon, 11 Aug 2008 20:09:50 +0000 Received: from [85.17.220.215] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSdhy-00036Y-EO for namedroppers@psg.com; Mon, 11 Aug 2008 20:09:47 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 24F5D4B44B; Mon, 11 Aug 2008 22:09:50 +0200 (CEST) Date: Mon, 11 Aug 2008 22:09:50 +0200 From: bert hubert To: "Jay R. Ashworth" Cc: namedroppers@psg.com Subject: Re: Why *can* cached DNS replies be overwritten? Message-ID: <20080811200950.GB17121@outpost.ds9a.nl> References: <20080811190427.GD9082@cgi.jachomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080811190427.GD9082@cgi.jachomes.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Aug 11, 2008 at 03:04:27PM -0400, Jay R. Ashworth wrote: > Correct me if I'm wrong, Leo, but your assertion turns on the fact that > the server will accept an overwriting cache entry for something it > already has cacheed, does it not? > > Do djb and Power in fact do that? Yes - PowerDNS does that because of reasons which used to be persuasive. It is in fact probably possible to ignore such updates. Costs are that (nameserver) changes get picked up later. I'll try this in PowerDNS on the several billion test queries and answers we have to see if this breaks things. > Everyone seems to continue asking "why can poisoning overwrite already > cached answer" and no one seems to be answering, and, unless I'm a > moron (which is not impossible), that's the crux of this issue. It feels odd to deviate from 25 years of DNS practice. This may be one reason why people find it hard to try such things. Thanks for persistenly asking about this. It may be something that is not theoretically allowed, but that practically helps us out of the woods. Will report results of the tests here. 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 14:54:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21323A6961; Mon, 11 Aug 2008 14:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.034 X-Spam-Level: ** X-Spam-Status: No, score=2.034 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 EnIQSEUCPKb6; Mon, 11 Aug 2008 14:54:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D7BC3A69B9; Mon, 11 Aug 2008 14:54:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSfFK-000DwI-78 for namedroppers-data@psg.com; Mon, 11 Aug 2008 21:48:10 +0000 Received: from [204.9.75.100] (helo=kansas.jhsoft.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSfFG-000DvP-0A for namedroppers@ops.ietf.org; Mon, 11 Aug 2008 21:48:07 +0000 Received: from hemsen by kansas.jhsoft.com (MDaemon PRO v9.6.2) with ESMTP id md50000108268.msg for ; Mon, 11 Aug 2008 21:48:03 +0000 From: =?iso-8859-1?Q?Jesper_G._H=F8y?= To: "'David Conrad'" Cc: "'Namedroppers WG'" References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> <028a01c8f18c$7f6bb620$7e432260$@com> <572015C3F44995F54736D38B@Ximines.local> <029401c8f196$c5822bd0$50868370$@com> <489F0F8E.6020607@gis.net> <021101c8fb13$34634310$9d29c930$@com> In-Reply-To: Subject: RE: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Mon, 11 Aug 2008 23:47:44 +0200 Message-ID: <028c01c8fbfb$e44131a0$acc394e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj77W3rsN4jciBcS4uyej+NldsccAACMdbw Content-Language: en-us X-Authenticated-Sender: jesper@jhsoft.com X-MDRemoteIP: 87.56.149.202 X-Return-Path: jesper@jhsoft.com X-Envelope-From: jesper@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: David Conrad write: > Ignoring for the moment the fact that 134 million (or even 4 billion) > packets isn't that much anymore (and will be less and less over time), > the DNS lookup 'wire' is logically distinct from the content 'wire'. > The ability to "intercept spoof" a DNS response can occur anywhere on > the DNS lookup 'wire', not only on the content producer/consumer's > local LAN. By not protecting the packet content, you open yourself up > to a distinct set of attackers beyond the local wire. Thank you - my point exactly! 4 billion packets may not be enough - we need a longer transaction ID. We have now come full circle to my initial post which was: The core problem with the Kaminsky bug, and other cache poisoning = scenarios, is the short 16 bit transaction ID. So why not simply expand this ID to a secure length? And not just ~16 bits (random ports) or 2+ bits (x020) - but really = secure length like 128 bits. This seems a lot easier than getting DNSSEC in place, signing the root, getting EVERYBODY to sign their zones, repeat for rollover, etc., etc. Some will probably argue that this doesn't help against = on-the-wire-attacks. But if the bad buy is one-the-wire, then he can replace any data at will anyway. DNSSEC is no help here. Of course we already have SSL to solve that problem. So why not keep DNS simple? Am I oversimplifying matters? > Indeed. DNSSEC may not be the 'only true solution' and there may be > other solutions. The vast majority of folks who have burned brain > cells and stomach lining on DNSSEC could be complete idiots and an > obvious, complete, lightweight, and architecturally clean solution > could be staring all of us in the face. That=92s not fair! I most certainly never suggested anything like that.=20 I have the deepest respect for the people behind DNSSEC and all the work that has gone into this. But DNSSEC was not invented to fix the Kaminsky bug (the topic of this thread). In fact DNSSEC was invented more than 10 years earlier. I do think it is fair to ask that other possibilities at least be = considered before applying something as complex as DNSSEC to this fairly simple = problem (short transaction ID). Sincerely, Jesper -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 15:53:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF493A6CE3; Mon, 11 Aug 2008 15:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 SVM6YxHn9H3X; Mon, 11 Aug 2008 15:53:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FB083A6CC1; Mon, 11 Aug 2008 15:53:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSgBq-000KKY-P1 for namedroppers-data@psg.com; Mon, 11 Aug 2008 22:48:38 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSgBn-000KKB-7b for namedroppers@ops.ietf.org; Mon, 11 Aug 2008 22:48:37 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id CE73B2CE911; Mon, 11 Aug 2008 15:48:34 -0700 (PDT) Cc: "'Namedroppers WG'" Message-Id: <940FDC7A-9D3C-4ACE-9518-4BCBC86403B0@virtualized.org> From: David Conrad To: =?ISO-8859-1?Q?Jesper_G._H=F8y?= In-Reply-To: <028c01c8fbfb$e44131a0$acc394e0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Mon, 11 Aug 2008 15:48:34 -0700 References: <48875934.8080101@links.org> <20080723183227.GA11957@outpost.ds9a.nl> <028601c8f185$eeb51b90$cc1f52b0$@com> <028a01c8f18c$7f6bb620$7e432260$@com> <572015C3F44995F54736D38B@Ximines.local> <029401c8f196$c5822bd0$50868370$@com> <489F0F8E.6020607@gis.net> <021101c8fb13$34634310$9d29c930$@com> <028c01c8fbfb$e44131a0$acc394e0$@com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Jesper, On Aug 11, 2008, at 2:47 PM, Jesper G. H=F8y wrote: > 4 billion packets may not be enough - we need a longer transaction ID. Or, we could remove the vulnerability by protecting the data, not the =20= transport. > > The core problem with the Kaminsky bug, and other cache poisoning =20 > scenarios, > is the short 16 bit transaction ID. No. The core problem with the Kaminsky bug is the fact that DNS data =20= is unprotected during transport. Making the transaction ID bigger =20 reduces the chance of an blind insertion spoof attack, but does =20 nothing for an interception spoof attack where the attacker is in the =20= DNS data path. Your XTID proposal is one of a class that treats the =20 symptoms, not the underlying disease. DNSSEC is one of a class that =20 treats the disease. In a DNSSEC-enabled world, it wouldn't matter =20 where you got the response from or what zombie-laden networks the =20 response traversed, you would be able to validate the response hadn't =20= been tampered with. That isn't to say that I don't think XTID et al shouldn't be =20 considered and even implemented if they improve the status quo, but it =20= solves a subset of the problems DNSSEC solves and as such, one has to =20= consider whether it is superfluous, particularly as XTID (appears to) =20= require a redeployment of both authoritative and caching servers, just =20= like DNSSEC (and if you're going to redeploy, you're probably going to =20= be redeploying something that is DNSSEC-capable). > But DNSSEC was not invented to fix the Kaminsky bug (the topic of this > thread). Actually, it was. Not the Kaminsky bug specifically of course, but =20 the entire class of bugs that revolve around modifying DNS data in =20 transit. > I do think it is fair to ask that other possibilities at least be =20 > considered > before applying something as complex as DNSSEC to this fairly simple =20= > problem > (short transaction ID). First, I am unaware of anyone even suggesting that other possibilities =20= not be considered. On the contrary, I seem to recall pretty much =20 everyone clamoring for an alternative that provides the same level of =20= protection as DNSSEC albeit with less =20 {development,operational,infrastructure} cost. Second, the problem isn't that the transaction ID is too short. The =20 short transaction ID exacerbates the problem by allowing remote =20 insertion spoofing particularly when additional section processing =20 comes into play. The real problem is that the DNS protocol was =20 developed during a time when "be liberal in what you accept" was a =20 good idea and when nobody would intentionally muck up network data for =20= illicit gain. Times have changed. Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 16:51:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F34B3A6912; Mon, 11 Aug 2008 16:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] 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 mFgD5ZTJCTHv; Mon, 11 Aug 2008 16:51:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84A8B3A6E02; Mon, 11 Aug 2008 16:51:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSh5g-000Pp3-GZ for namedroppers-data@psg.com; Mon, 11 Aug 2008 23:46:20 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSh5c-000Poe-O1 for namedroppers@ops.ietf.org; Mon, 11 Aug 2008 23:46:18 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7BNk9pg063448; Tue, 12 Aug 2008 09:46:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808112346.m7BNk9pg063448@drugs.dv.isc.org> To: Michael StJohns Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Mon, 11 Aug 2008 16:03:27 -0400." <20080811200329.9A7A4114027@mx.isc.org> Date: Tue, 12 Aug 2008 09:46:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 09:18 PM 8/10/2008, Mark Andrews wrote: > > >> OK - but MX-records point to host names which point to A/AAAA records whic > h > >> point to IP addresses... > >> If the bad guy is on the wire, he can intercept and replace your SMTP > >> traffic anyway. > >> DNSSEC or not. > >> > >> SRV-records also point to host names which... > > > > DNS security is required for SMTP security to work. > > Absurd claim. Not really. SMTP is not HTTPS where you know apriori which certificate to check for. For SMTP you need to check the certificate of the mail exchanger and to find that securely you need DNSSEC to verify the MX record or its absence so you know when to use the implict MX record. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 17:40:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8553A6E07; Mon, 11 Aug 2008 17:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.482 X-Spam-Level: * X-Spam-Status: No, score=1.482 tagged_above=-999 required=5 tests=[AWL=-1.677, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] 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 1j1u-3BMnvex; Mon, 11 Aug 2008 17:40:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFB8E3A6E18; Mon, 11 Aug 2008 17:40:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KShq3-0004bU-Ar for namedroppers-data@psg.com; Tue, 12 Aug 2008 00:34:15 +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 ) id 1KShpz-0004az-Fa for namedroppers@psg.com; Tue, 12 Aug 2008 00:34:13 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7C0WqNc078602; Mon, 11 Aug 2008 20:32:53 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808120032.m7C0WqNc078602@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Aug 2008 20:32:48 -0400 To: "Jay R. Ashworth" , namedroppers@psg.com From: Olafur Gudmundsson Subject: Re: Why *can* cached DNS replies be overwritten? In-Reply-To: <20080811190427.GD9082@cgi.jachomes.com> References: <20080811190427.GD9082@cgi.jachomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 15:04 11/08/2008, Jay R. Ashworth wrote: >[ cross-posted from NANOG, cause vix told me to :-) > >On Mon, Aug 11, 2008 at 11:20:07AM -0400, Leo Bicknell wrote: > > If your vendor told you that you are not at risk they are wrong, > > and need to go re-read the Kaminski paper. EVERYONE is vunerable, > > the only question is if the attack takes 1 second, 1 minute, 1 hour > > or 1 day. While possibly interesting for short term problem > > management none of those are long term fixes. I'm not sure your > > customers care when .COM is poisoned if it took the attacker 1 > > second or 1 day. > >Correct me if I'm wrong, Leo, but your assertion turns on the fact that >the server will accept an overwriting cache entry for something it >already has cacheed, does it not? > >Do djb and Power in fact do that? > >If they don't, the window of opportunity to poison something like .com >is limited to the period between when that entry expires from the local >server's cache and the next time it hears a reply -- which will be the >time after that expiry when someone next requests a .com name; IE >almost immediately, no? > >Everyone seems to continue asking "why can poisoning overwrite already >cached answer" and no one seems to be answering, and, unless I'm a >moron (which is not impossible), that's the crux of this issue. > >Cheers, >-- jra >-- The cynical answer is "optimization" the real answer is "trying to be helpful". What most/all implementations are doing is assuming that "newer" data is better if it has the same criticality [RFC2181], this takes two forms: if the data is identical to the existing one, the TTL on the set is extended. If the data is different the old data is replaced. Personally I think we need to sit down and analyze this carefully if we are better of by outlawing/discouraging this behavior and have all RRsets expire after the original TTL expires or do something else. One proposal is to use the "Authority Section data for the question being asked" and then ask a direct query to fetch the data inserted into the Authority section data and overwrite that with the data from Answer section which should have higher criticality than the stuff from Authority Section and this should prevent overwrites. (This is strictly/almost a protocol change) The effect of not overwriting/stretching TTL on RRsets is that an attacker can only poison the set of their choice once in a while (depends on the RRset TTL and the cache's memory constraints). What the overall effect is going to be if caches changed this behavior is debatable but conducting few experiments would be real useful. Both in seeing if anything in resolution break as well as see if this helps prevent acceptance of forgeries. At the same time the WG should look into other approaches in this and related spaces. Comments Olafur -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 11 18:09:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651433A6E02; Mon, 11 Aug 2008 18:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 omUGfvqZHuyY; Mon, 11 Aug 2008 18:09:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 825723A69F5; Mon, 11 Aug 2008 18:09:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSiJd-000797-EL for namedroppers-data@psg.com; Tue, 12 Aug 2008 01:04:49 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSiJZ-00078Q-N5 for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 01:04:47 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7C14dY3065091; Tue, 12 Aug 2008 11:04:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808120104.m7C14dY3065091@drugs.dv.isc.org> To: "=?iso-8859-1?Q?Jesper_G._H=F8y?=" Cc: "'Namedroppers WG'" From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Mon, 11 Aug 2008 23:47:44 +0200." <028c01c8fbfb$e44131a0$acc394e0$@com> Date: Tue, 12 Aug 2008 11:04:39 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > But DNSSEC was not invented to fix the Kaminsky bug (the topic of this > thread). > In fact DNSSEC was invented more than 10 years earlier. Incorrect. It was invented to protect against several classes of attack of which Kaminsky is just one example. It was assumed back when DNSSEC was originally being developed that someone would work out a good method for injecting spoofed responses. DNSSEC was designed to deal with that threat. We just hoped we would have more deployment before the threat became a reality. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 01:39:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F31D3A6994; Tue, 12 Aug 2008 01:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.55 X-Spam-Level: *** X-Spam-Status: No, score=3.55 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 ZrARqoNt-pMh; Tue, 12 Aug 2008 01:39:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFDE53A63C9; Tue, 12 Aug 2008 01:39:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSpHq-000JhX-BW for namedroppers-data@psg.com; Tue, 12 Aug 2008 08:31:26 +0000 Received: from [193.176.144.134] (helo=gw.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSpHm-000JgY-2x for namedroppers@psg.com; Tue, 12 Aug 2008 08:31:24 +0000 Received: by localhost.sidn.nl (TUNIX/Firewall Mail Server) with ESMTP id A25463A9AD for ; Tue, 12 Aug 2008 10:31:19 +0200 (CEST) Received: by gw.sidn.nl (TUNIX/Firewall Mail Server) with ESMTP for ; Tue, 12 Aug 2008 10:31:19 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: Why *can* cached DNS replies be overwritten? Date: Tue, 12 Aug 2008 10:31:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why *can* cached DNS replies be overwritten? Thread-Index: Acj75+GsMv0svaFfTUKaqmpZUgMU8AAZyyXA References: <20080811190427.GD9082@cgi.jachomes.com> From: "Antoin Verschuren" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner- > Subject: Why *can* cached DNS replies be overwritten? >=20 > Do djb and Power in fact do that? I did some investigation after my post of = http://lists.oarci.net/pipermail/dns-operations/2008-February/002526.html= I did not test this myself, but what people have told me is: Dnscache, powerdns: Updates the cache by resetting the TTL if a new = authoritative answer for the same entry is received. Bind: Updates the cache, but only replaces the TTL with the min value Unbound: Never updates, always waits for an entry to expire before = accepting a new entry > Everyone seems to continue asking "why can poisoning overwrite already > cached answer" and no one seems to be answering, and, unless I'm a > moron (which is not impossible), that's the crux of this issue. I actually like the simple behavior that an authoritative answer can = override an already cached answer. It's efficient, and follows the simple rule that an authorative answer = can be cached. It only goes wrong if people don't maintain their DNS entries = operationally, and forget to delete entries they are no longer = authoritative for. So the bad guys get hit. The benefit for the good guys is that less lookups are needed, and more = importantly, parents are hit less. In the DNS hierarchy, you don't want every query to hit the root. My concern is that if records always expire, like Unbound does, parent = nameservers are hit more. Now we can start an argument on the fact that traffic has become = inexpensive, and root and TLD nameservers should be able to cope with = this minimal increase in queries, but I think we should define a = protocol to be as efficient as it can be. I actually don't know how parent traffic will be affected, I'm = interested to see measurements on that. But I stay with the thought that even though we only win some bits in = traffic, we should always aim to design a protocol to do so. I also think we must not create protocol complexity to protect ignorant = users from making mistakes when that does not benefit educated users. And then there's the argument that when cached entries cannot be = replaced, an attacker can make use of that. "fixing" a bad cache entry remotely by sending the correct authoritative = answer might reduce the time window a poisoned cache is operational. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/ -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 05:19:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBC63A6A5B; Tue, 12 Aug 2008 05:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, 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 8NOdeWvsh79C; Tue, 12 Aug 2008 05:19:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 877C13A6833; Tue, 12 Aug 2008 05:19:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSsgy-000H5B-Mm for namedroppers-data@psg.com; Tue, 12 Aug 2008 12:09:36 +0000 Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSsgp-000H49-Kr for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 12:09:34 +0000 Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KSsgm-0005Bo-Gk; Tue, 12 Aug 2008 14:09:24 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 6A25E7E55F5; Tue, 12 Aug 2008 14:09:24 +0200 (CEST) Date: Tue, 12 Aug 2008 14:09:23 +0200 From: Peter Koch To: Antoin Verschuren Cc: IETF DNSEXT WG Subject: Dealing with the NS RRSet [Re: Why *can* cached DNS replies be overwritten?] Message-ID: <20080812120923.GB39395@unknown.office.denic.de> References: <20080811190427.GD9082@cgi.jachomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Aug 12, 2008 at 10:31:21AM +0200, Antoin Verschuren wrote: > I actually like the simple behavior that an authoritative answer can override an already cached answer. > It's efficient, and follows the simple rule that an authorative answer can be cached. well, I had read your earlier comments slightly differently, especially w.r.t. the "name server lock-in" problem. > It only goes wrong if people don't maintain their DNS entries operationally, and forget to delete entries they are no longer authoritative for. ... or aren't informed or don't cooperate for other reasons. We know how to gracefully migrate from one NS RRSet do another, even disjoint, one, but we also know that this migration doesn't really happen that often in today's mass hosting environments. But can catch two birds with one stone here, I believe: Let's see what different flavors the forged responses can have: ----------------------------------------------------------------------------- ;; QUESTION SECTION: ;345678.example.org. IN A ;; ANSWER SECTION: 345678.example.org. 3600 IN A 192.0.2.1 ;; AUTHORITY SECTION: example.org. 3600 IN NS ns1.example.org. example.org. 3600 IN NS ns2.example.net. ;; ADDITIONAL SECTION: ns1.example.org. 3600 IN A 10.0.0.42 www.example.org. 3600 IN A 192.0.2.80 ----------------------------------------------------------------------------- Unsolicited additional information should already be ignored and data from the additional section shouldn't overwrite a (previous) authoritative answer as per RFC 2181. 0 points. ----------------------------------------------------------------------------- ;; QUESTION SECTION: ;345678.example.org. IN A ;; ANSWER SECTION: 345678.example.org. 3600 IN A 192.0.2.1 ;; AUTHORITY SECTION: example.org. 3600 IN NS www.example.org. example.org. 3600 IN NS ns2.example.net. ;; ADDITIONAL SECTION: www.example.org. 3600 IN A 192.0.2.80 ----------------------------------------------------------------------------- The additional section data is logically justified, but RFC 2181 helps. 0 points. ----------------------------------------------------------------------------- ;; QUESTION SECTION: ;345678.example.org. IN A ;; ANSWER SECTION: 345678.example.org. 3600 IN A 192.0.2.1 ;; AUTHORITY SECTION: example.org. 3600 IN NS evil1.example.net. example.org. 3600 IN NS evil2.example.net. ----------------------------------------------------------------------------- Now, to have gotten here, the resolver has already followed a referral. In theory, the referral and the authoritative data are always in sync, so there's no need to replace one with the other. In practice, though, the authoritative NS RRSet is the more credible one. Distinguish between a referral NS RRSet and an "authoritative" NS RRSet (quotes because it stems from the authoritative source, but isn't formally covered by the AA bit): let the latter _only_ overwrite the former. This brings back the window of opportunity whose size is determined by the TTL of the "authoritative" NS RRSet. However, there's a remaining risk here at those levels where a positive authoritative response does not normally occur under normal operations, most prominently most of the TLDs. ----------------------------------------------------------------------------- ;; QUESTION SECTION: ;345678.example.org. IN A ;; ANSWER SECTION: 345678.example.org. 3600 IN A 192.0.2.1 ;; AUTHORITY SECTION: example.org. 3600 IN NS 345678.example.org. ----------------------------------------------------------------------------- Same as above. It's the NS RRSet, not the address data. > In the DNS hierarchy, you don't want every query to hit the root. > My concern is that if records always expire, like Unbound does, parent nameservers are hit more. Sure, but this is hard to predict. It depends on the relation of TTLs between both NS RRSets as well as the TTLs of the authoritative NS RRSet and the TTL of the data you're actually interested in. But, isn't the phantom referral the really hard one: ----------------------------------------------------------------------------- ;; QUESTION SECTION: ;345678.www.example.org. IN A ;; AUTHORITY SECTION: www.example.org. 3600 IN NS evil1.example.net. www.example.org. 3600 IN NS evil2.example.net. ----------------------------------------------------------------------------- What are mitigation techniques here? o let the resolver remember the (potentially invisible) zone cut o expire all RRSets atthe same owner at once (bad effect on the parent) o really delegate at every level (have fun with IP6.ARPA and ENUM) o ... -Peter -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 06:45:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2EA3A6ACE; Tue, 12 Aug 2008 06:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 zWNFFV4vd2Ym; Tue, 12 Aug 2008 06:45:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACB283A68F5; Tue, 12 Aug 2008 06:45:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSu53-0000HB-Lw for namedroppers-data@psg.com; Tue, 12 Aug 2008 13:38:33 +0000 Received: from [131.111.8.133] (helo=ppsw-3.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSu4v-0000Fx-Hj for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 13:38:27 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56015) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:25) with esmtpa (EXTERNAL:fanf2) id 1KSu4s-0004qY-BZ (Exim 4.70) (return-path ); Tue, 12 Aug 2008 14:38:22 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KSu4s-0004vT-II (Exim 4.67) (return-path ); Tue, 12 Aug 2008 14:38:22 +0100 Date: Tue, 12 Aug 2008 14:38:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Peter Koch cc: IETF DNSEXT WG Subject: Re: Dealing with the NS RRSet [Re: Why *can* cached DNS replies be overwritten?] In-Reply-To: <20080812120923.GB39395@unknown.office.denic.de> Message-ID: References: <20080811190427.GD9082@cgi.jachomes.com> <20080812120923.GB39395@unknown.office.denic.de> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, 12 Aug 2008, Peter Koch wrote: > > Let's see what different flavors the forged responses can have: Now about ;; QUESTION SECTION: ;345678.example.org. IN A ;; ANSWER SECTION: 345678.example.org. 3600 IN CNAME www.example.org. www.example.org. 3600 IN A 192.0.2.80 ; evil Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST ICELAND: NORTHEASTERLY 5 TO 7, OCCASIONALLY GALE 8. ROUGH OR VERY ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 07:01:09 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923273A6B20; Tue, 12 Aug 2008 07:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 eKOGWvM-jHOc; Tue, 12 Aug 2008 07:01:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE7E73A6ADF; Tue, 12 Aug 2008 07:01:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSuKP-0001kn-2T for namedroppers-data@psg.com; Tue, 12 Aug 2008 13:54:25 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSuKI-0001k9-Pm for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 13:54:23 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m7CDs2e8010319; Tue, 12 Aug 2008 09:54:04 -0400 Message-ID: <48A195FD.1040604@nist.gov> Date: Tue, 12 Aug 2008 09:54:05 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: IETF DNSEXT WG CC: Steve Crocker , dnsext-chairs@tools.ietf.org Subject: request for draft-crocker-dnssec-algo-signal-01 to become WG item Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: As mentioned during the WG meeting in Dublin, we would like draft "Signaling Cryptographic Algorithm Understanding in DNSSEC" to become a working group document. the latest version is in the ID database: https://datatracker.ietf.org/drafts/draft-crocker-dnssec-algo-signal/ Comments welcome (as always). Please send nits/edits/typos directly to the authors (Steve Crocker and me). Thanks, Scott -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 07:06:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1CDC3A6A1C; Tue, 12 Aug 2008 07:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 AgK+nFDJUF4N; Tue, 12 Aug 2008 07:06:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B4393A68F8; Tue, 12 Aug 2008 07:06:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSuQ5-0002SQ-UM for namedroppers-data@psg.com; Tue, 12 Aug 2008 14:00:17 +0000 Received: from [131.111.8.133] (helo=ppsw-3.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSuPk-0002OE-1V for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 14:00:02 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:41417) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:25) with esmtpa (EXTERNAL:fanf2) id 1KSuPh-0002tE-AZ (Exim 4.70) (return-path ); Tue, 12 Aug 2008 14:59:53 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KSuPh-00083W-8B (Exim 4.67) (return-path ); Tue, 12 Aug 2008 14:59:53 +0100 Date: Tue, 12 Aug 2008 14:59:53 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Michael StJohns cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: Message-ID: References: <200808110118.m7B1If7Z052960@drugs.dv.isc.org> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, 11 Aug 2008, Michael StJohns wrote: > > SSL/TLS has the nice properties that I can deploy it per server (e.g. I > can get incremental benefit), that I can do off-tree validations, and > that a hell of a lot of servers already implement it. It has the problem that a large proportion of MXs that offer TLS have the wrong certificate, so you can't easily turn on certificate verification for your outgoing email. There's essentially no requirement for certificate verification in the specification, nor is it clear exactly which domain you are supposed to compare against any certificate. Tony. -- f.anthony.n.finch http://dotat.at/ NORTH UTSIRE SOUTH UTSIRE: SOUTHEASTERLY 4, BACKING NORTHEASTERLY 5 TO 7 FOR A TIME. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 07:47:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4523A6AB9; Tue, 12 Aug 2008 07:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] 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 yIw-ggpLG9-N; Tue, 12 Aug 2008 07:47:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 651DA3A68B9; Tue, 12 Aug 2008 07:47:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSv3P-0007Wy-A2 for namedroppers-data@psg.com; Tue, 12 Aug 2008 14:40:55 +0000 Received: from [2001:700:1:0:211:9ff:fe8c:7386] (helo=smistad.uninett.no) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSv3H-0007W3-EA for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 14:40:52 +0000 Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id DC51721DC44; Tue, 12 Aug 2008 16:40:48 +0200 (CEST) Date: Tue, 12 Aug 2008 16:40:48 +0200 (CEST) Message-Id: <20080812.164048.246546894.he@uninett.no> To: lendl@nic.at Cc: namedroppers@ops.ietf.org Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS From: Havard Eidnes In-Reply-To: <489C5202.4080405@nic.at> References: <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> <489C5202.4080405@nic.at> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > * Are there any open protocol issues which make such a > "single checkbox" deployment of DNSSEC impossible? The need to communicate off-line or at least out-of-protocol with the parent zone administrator when you need to change/roll-over your KSKs -- this is probably what you meant by "automatic DS generation in the parent" in your next item. Although this might be seen as similar to making changes to the NS RRset, the initiative is triggered by a timer and not by administrator action, which is a considerable change from previous operational practice. There's also the issue of trust anchor maintenance, but that's being worked on, as I understand it. When reading some of the DNSSEC RFCs, I've sometimes come away with the= understanding that the authors think that "zone administrators needs to= sign the zone on an off-line machine to maintain a sufficiently high level of security". If I've understood correctly, that's completely at= odds with the goal of having a fully automated feature with a checkbox for "maintain (generate and periodically roll) ZSKs and KSKs and sign and re-sign all my zones automatically". My guess is that only TLD and= root zone maintainers would care enough about their zones and keys to bear the level of pain involved in implementing complete off-line signing ("zone transfer via sneakernet"). For a simple leaf zone maste= r name server administrator, is there a good reason he needs to care more= about his DNS private keys than about the protection and host security on the master name server (which might be "hidden", i.e. not in the NS set)? (OK, that probably wasn't a protocol issue...) Then there's the aspect of having the root signed, which is really needed in order to alleviate the pain of maintaining the trust anchors, a pain which is to be felt on all the recursive name servers who want to get the benefits of DNSSEC. Even if it appears to be a non-protocol issue does not make it any less important in the view of deployment. Best regards, - H=E5vard -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 08:11:17 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95F23A6B3B; Tue, 12 Aug 2008 08:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] 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 OICmcbkLLHox; Tue, 12 Aug 2008 08:11:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27BEE3A6A5F; Tue, 12 Aug 2008 08:11:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSvPx-0009xr-BK for namedroppers-data@psg.com; Tue, 12 Aug 2008 15:04:13 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSvPp-0009wH-Lb for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 15:04:09 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7CF3taj069712; Wed, 13 Aug 2008 01:03:56 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808121503.m7CF3taj069712@drugs.dv.isc.org> To: Tony Finch Cc: Michael StJohns , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Tue, 12 Aug 2008 14:59:53 +0100." Date: Wed, 13 Aug 2008 01:03:55 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On Mon, 11 Aug 2008, Michael StJohns wrote: > > > > SSL/TLS has the nice properties that I can deploy it per server (e.g. I > > can get incremental benefit), that I can do off-tree validations, and > > that a hell of a lot of servers already implement it. > > It has the problem that a large proportion of MXs that offer TLS have the > wrong certificate, so you can't easily turn on certificate verification > for your outgoing email. There's essentially no requirement for > certificate verification in the specification, nor is it clear exactly > which domain you are supposed to compare against any certificate. The certificate should match the host name in the reply to the HELO message which should in turn also match EXCHANGE in the MX record in the general case. Checking the later part was specified in RFC 821 Section 3.5. OPENING AND CLOSING. "At the time the transmission channel is opened there is an exchange to ensure that the hosts are communicating with the hosts they think they are." The former is a logical extension. Mark > Tony. > -- > f.anthony.n.finch http://dotat.at/ > NORTH UTSIRE SOUTH UTSIRE: SOUTHEASTERLY 4, BACKING NORTHEASTERLY 5 TO 7 FOR > A > TIME. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR > . > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 08:21:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA843A6A5F; Tue, 12 Aug 2008 08:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 nthQ78mRYhAk; Tue, 12 Aug 2008 08:21:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2BFB63A6B86; Tue, 12 Aug 2008 08:21:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSvav-000B7r-35 for namedroppers-data@psg.com; Tue, 12 Aug 2008 15:15:33 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSvan-000B6j-0r for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 15:15:27 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7CFFIvi069878; Wed, 13 Aug 2008 01:15:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808121515.m7CFFIvi069878@drugs.dv.isc.org> To: Havard Eidnes Cc: lendl@nic.at, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: OFFTOPIC: DNSSEC groupthink versus improving DNS In-reply-to: Your message of "Tue, 12 Aug 2008 16:40:48 +0200." <20080812.164048.246546894.he@uninett.no> Date: Wed, 13 Aug 2008 01:15:18 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > * Are there any open protocol issues which make such a > > "single checkbox" deployment of DNSSEC impossible? > > The need to communicate off-line or at least out-of-protocol with > the parent zone administrator when you need to change/roll-over your > KSKs -- this is probably what you meant by "automatic DS generation > in the parent" in your next item. Although this might be seen as > similar to making changes to the NS RRset, the initiative is > triggered by a timer and not by administrator action, which is a > considerable change from previous operational practice. Which, in practice, may not be necessary though I would expect that TLD's will continue to rollover keys For end user zones the only key roll overs may be emergency key rollovers. > There's also the issue of trust anchor maintenance, but that's being > worked on, as I understand it. > > When reading some of the DNSSEC RFCs, I've sometimes come away with the= > > understanding that the authors think that "zone administrators needs to= > > sign the zone on an off-line machine to maintain a sufficiently high > level of security". If I've understood correctly, that's completely at= > > odds with the goal of having a fully automated feature with a checkbox > for "maintain (generate and periodically roll) ZSKs and KSKs and sign > and re-sign all my zones automatically". My guess is that only TLD and= > > root zone maintainers would care enough about their zones and keys to > bear the level of pain involved in implementing complete off-line > signing ("zone transfer via sneakernet"). For a simple leaf zone maste= > r > name server administrator, is there a good reason he needs to care more= > > about his DNS private keys than about the protection and host security > on the master name server (which might be "hidden", i.e. not in the NS > set)? (OK, that probably wasn't a protocol issue...) The protocol had to support completely offline keys. The actual practice is up to the zone administrator. > Then there's the aspect of having the root signed, which is really > needed in order to alleviate the pain of maintaining the trust > anchors, a pain which is to be felt on all the recursive name servers > who want to get the benefits of DNSSEC. Even if it appears to be a > non-protocol issue does not make it any less important in the view of > deployment. But it's lack isn't a show stopper either. > Best regards, > > - H=E5vard > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 08:32:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA1E3A6B18; Tue, 12 Aug 2008 08:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.105 X-Spam-Level: * X-Spam-Status: No, score=1.105 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, 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 4fvMBCKBh4ia; Tue, 12 Aug 2008 08:31:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 748C53A6A46; Tue, 12 Aug 2008 08:31:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSvlN-000CTG-L2 for namedroppers-data@psg.com; Tue, 12 Aug 2008 15:26:21 +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 ) id 1KSvlJ-000CSb-I4 for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 15:26:19 +0000 Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7CFQCBS085832; Tue, 12 Aug 2008 11:26:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Tue, 12 Aug 2008 08:25:46 -0700 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: transfering vs. loading a zone Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: During the DNSEXT meeting at IETF 72 one topic came up regarding the "AXFR clarify" draft. The topic is "the difference between a zone transfer and zone load operation." The issue begins with the question "what is in a zone?" That question is what derailed the document a half decade ago. The question is not that easy to answer. There is a statement in the original RFCs about what is in a zone, and the statement is pretty clear. However, the advent of dynamic update (with the ability to add a cut point) created a class of records now called "obscured records" and this class gained additional importance with the advent of DNAME. Obscured records are not the first records which can be classified as "wrong" but are legitimately tied to a zone, earlier examples of this are "bad" glue records, i.e., glue record with different address(es) than the authoritative data they represent. Complicating matters, once we recognize that bad glue and obscured records are legitimate parts of a zone, through the fact that the records were added by the administrator, what about "typos?" Of course, a typo of transposing bits in a AAAA record is something the DNS itself won't know about, but a typo like: $ORIGIN example. @ SOA ... <...> ns1.nic AAAA 3ffe::1 ns1.nic. A 127.0.0.1 The AAAA shown is for ns1.nic.example. and the A is ns1.nic. Is the address record for ns1.nic. in the zone even though this might make a name server refuse to load and serve the zone? This raises the issue - what is in a zone? I see three possible (extreme) answers: 1.) Exactly what the administrator places into the zone. 2.) The subset of #1 excluding typos. 3.) The best data that should be there. If #1 is done perfectly right, then all three are the same. Why not #3? If the nameservers start editing the zone, troubleshooting becomes troublesome. From personal experience, I knew of an erstwhile zone that had many, many lame delegations. Most servers for the zone also served all of the children, meaning it was hard to capture the lame delegations. But one server exposed the lame delegations and that was causing operational problems. Fortunately, as an operator of a slave for the zone I got a copy of the zone via AXFR and was able to debug and alert the admin. It pays to let errors become exposed. Makes debugging easier. Of course, covering over bumps is good - if all the covering is done the same way. In an interoperable world though, nothing is always "done the same way." A comment was made at the mic in the meeting that we should think of a zone "for a particular serial number." And the zone for a particular serial number is "set in stone" when the zone is successfully loaded at the master server. Not by the administrator, and zones that fail to load never get to be that version. This is because only after the master loads the zone will either there be NOTIFYs sent or the slaves will poll and see the incremented serial number. If any name server, especially the master, "edits" the zone (that is loads a subset of what is given), the name server has taken an editing pen to the administrator's work. Why not #2? It isn't clear if typo errors are objectively defined. I haven't thought all the way through but my hunch is that trying to algorithmically decide if a mistake was made is nearly impossible. So that leaves #1, "warts and all." In my opinion, it's the right approach, but then again this is an opinion to be expressed by the working group. But let's assume for now a zone is defined as #1, and press on to the issue of loading a zone (from an AXFR - as AXFR is the topic at hand). If an AXFR will deliver to a name server the contents of a zone according to the criteria of #1 above, the name server ought to do some sanity checking on it. I.e., the zone is not #3, it is not ready for immediate consumption. A name server could parse the zone and decide not to serve it due to errors. A name server has to recognize the "obscured" (or "occluded" I forget the term we want to use) records. Here's an open question. If a name server gets a zone via AXFR (presumably the name server had a reason to ask for it) and decides the zone is bad and returns SERVFAIL to all queries for data in the zone, will the name server still store the zone, send NOTIFYs and serve it as AXFR/IXFR? Is it possible for a name server to hold a cache of zones that failed to load? I mean, one failed load per zone configured, not a running history. Is the decision to transfer a zone different from the decision to load and serve a zone? This is meant to start an open discussion...so maybe this isn't all wrapped up, but I'm seeking comments. Eventually this will be in a section about the differences between AXFR and loading. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 09:11:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595FA3A67DB; Tue, 12 Aug 2008 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_LOW=-1, 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 vxLLI1R7mCrr; Tue, 12 Aug 2008 09:11:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 498A228C178; Tue, 12 Aug 2008 09:11:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSwJu-000G86-PJ for namedroppers-data@psg.com; Tue, 12 Aug 2008 16:02:02 +0000 Received: from [88.198.34.164] (helo=mail.bofh.priv.at) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSwJq-000G7L-HR for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 16:02:00 +0000 Received: from [10.10.0.107] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 31C564D423; Tue, 12 Aug 2008 18:01:54 +0200 (CEST) Message-ID: <48A1B41B.1060707@nic.at> Date: Tue, 12 Aug 2008 18:02:35 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Havard Eidnes CC: namedroppers@ops.ietf.org Subject: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC groupthink versus improving DNS) References: <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> <489C5202.4080405@nic.at> <20080812.164048.246546894.he@uninett.no> In-Reply-To: <20080812.164048.246546894.he@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Havard Eidnes wrote: >> * Are there any open protocol issues which make such a >> "single checkbox" deployment of DNSSEC impossible? > > The need to communicate off-line or at least out-of-protocol with > the parent zone administrator when you need to change/roll-over your > KSKs -- this is probably what you meant by "automatic DS generation > in the parent" in your next item. RFC 5011 offers a way to do key rollover without out-of-protocol interactions, as well as most other common trust anchor operations. The intention of 5011 certainly wasn't "parent to child" but "island to island" secure entry point management. I'm in brainstorming mode, so: Why can't 5011 be used by TLDs instead of extending the Registry/Registrar protocol? That change takes time and puts the Registrar into the critical path for DNSSEC rollout. Yes, this can be 100% automatic: a test-signing of a zone should not automatically result in a signed DS in the parent, which could prove fatal if the zone reverts to being unsigned. But couple it with an email loop "We have detected your key, do you want us to include DS records in the TLD zone? Please click YES or NO" to the domain owner this might be "good enough". > When reading some of the DNSSEC RFCs, I've sometimes come away with the > understanding that the authors think that "zone administrators needs to > sign the zone on an off-line machine to maintain a sufficiently high > level of security". Correct, and that makes a lot of sense for TLDs and domains used for e-commerce. > If I've understood correctly, that's completely at > odds with the goal of having a fully automated feature with a checkbox > for "maintain (generate and periodically roll) ZSKs and KSKs and sign > and re-sign all my zones automatically". My guess is that only TLD and > root zone maintainers would care enough about their zones and keys to > bear the level of pain involved in implementing complete off-line > signing ("zone transfer via sneakernet"). For a simple leaf zone master > name server administrator, is there a good reason he needs to care more > about his DNS private keys than about the protection and host security > on the master name server (which might be "hidden", i.e. not in the NS > set)? (OK, that probably wasn't a protocol issue...) Just look at how people deal with SSL and ssh server keys. I guess less than 5% of the https: sites don't have the key (+passphrase, if any) on the webserver. (Back in my old job, when SSL was new, we had to enter the passphrase on server reboots/restarts. What a hassle. I strongly doubt this is still done in most installations.) ssh server keys? I have yet to see a server that doesn't store them on disk. (IIRC, the sshd server even regenerates temporary server keys every few hours. This completely transparent to the admin and user.) So no, I don't think that your average name server admin will care more about his dnssec keys than the overall security of this servers. For ssh, the "ask on first contact, store and YELL if it changes"-security model seems to be really popular. Phil Zimmerman's zPhone uses the same idea. Can't the same principle work for DNSSEC child->parent provisioning? > Then there's the aspect of having the root signed, which is really > needed in order to alleviate the pain of maintaining the trust > anchors, a pain which is to be felt on all the recursive name servers > who want to get the benefits of DNSSEC. Even if it appears to be a > non-protocol issue does not make it any less important in the view of > deployment. Getting the root signed is, of course, the jackpot. If we can get the registry/registrar interface and the registrar/customer interface out of the critical path, that might make getting TLDs DNSSEC-enabled a lot easier and thus faster. If TLDs get serious with DNSSEC, then the task of secure entry point management for resolvers becomes a *lot* easier. Once again, from a pure protocol point of view, is 5011 enough to cut out the registrar from the DNSSEC provisioning loop? I'm sure there are pitfalls (e.g. how to handle emergency key rollovers). /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 09:46:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA803A69D1; Tue, 12 Aug 2008 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=0.800, 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 fov2fjDT0OIa; Tue, 12 Aug 2008 09:46:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81EB33A68F5; Tue, 12 Aug 2008 09:46:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSwuz-000KFg-EK for namedroppers-data@psg.com; Tue, 12 Aug 2008 16:40:21 +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 ) id 1KSwuu-000KFA-D8 for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 16:40:19 +0000 Received: from [192.168.7.242] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7CGeCrv086753; Tue, 12 Aug 2008 12:40:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200808110118.m7B1If7Z052960@drugs.dv.isc.org> References: <200808110118.m7B1If7Z052960@drugs.dv.isc.org> Date: Tue, 12 Aug 2008 09:40:07 -0700 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:18 +1000 8/11/08, Mark Andrews wrote: > DNS security is required for SMTP security to work. That is why the SIKED (Secure Internet KEy Distribution) BoF failed, 53rd IETF. If SMTP security works because DNS security works, then a DNS security failure means SMTP security fails too. A house of cards. This is what is feared. (see also http://www.potaroo.net/ietf/idref/draft-lewis-siked-dnsargs/) Thanks to Geoff Huston for maintaining that repository. Although I'd call it "Pandora's Box" because of all of the bad ideas documented in there that never mad it to RFC. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 09:52:24 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0613A696D; Tue, 12 Aug 2008 09:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.310, 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 Zb20ZSXV6N+H; Tue, 12 Aug 2008 09:52:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7F8A3A6B12; Tue, 12 Aug 2008 09:52:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSx0f-000Kog-Ct for namedroppers-data@psg.com; Tue, 12 Aug 2008 16:46:13 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSx0a-000Knz-0J for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 16:46:11 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7CGmrBp021115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Aug 2008 09:48:56 -0700 Date: Tue, 12 Aug 2008 12:46:03 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC groupthink versus improving DNS) Message-ID: <20080812164603.GA27562@commandprompt.com> References: <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> <489C5202.4080405@nic.at> <20080812.164048.246546894.he@uninett.no> <48A1B41B.1060707@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48A1B41B.1060707@nic.at> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Tue, 12 Aug 2008 09:48:56 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Tue, Aug 12, 2008 at 06:02:35PM +0200, Otmar Lendl wrote: > I'm in brainstorming mode, so: Why can't 5011 be used by TLDs instead of > extending the Registry/Registrar protocol? That change takes time > and puts the Registrar into the critical path for DNSSEC rollout. In at least some cases, two reasons: 1. The EPP extension for DS management has been ready for ages. So there's very little work to do there anyway. It's in RFC 4310. (Of course, some registries aren't using EPP, so it's not relevant to them.) 2. Many TLDs aren't actually allowed to talk to the party that has administrative control of the domain. In the ICANN world, for instance, registries may only speak to the registrar, and not the registrant. This is admittedly a policy and not a technical reason, but it's a reason anyway. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 09:59:04 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5D43A6BAE; Tue, 12 Aug 2008 09:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 H43AwSBQRgqI; Tue, 12 Aug 2008 09:59:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B83743A6A46; Tue, 12 Aug 2008 09:59:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSx9N-000Lly-FU for namedroppers-data@psg.com; Tue, 12 Aug 2008 16:55:13 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSx9H-000Lk5-E8 for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 16:55:11 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KSx95-0004CJ-2R; Tue, 12 Aug 2008 18:54:55 +0200 Received: from fweimer by bfk.de with local id 1KSx9C-0003zX-BW; Tue, 12 Aug 2008 18:55:02 +0200 To: Tony Finch Cc: Peter Koch , IETF DNSEXT WG Subject: Re: Dealing with the NS RRSet [Re: Why *can* cached DNS replies be overwritten?] References: <20080811190427.GD9082@cgi.jachomes.com> <20080812120923.GB39395@unknown.office.denic.de> From: Florian Weimer Date: Tue, 12 Aug 2008 18:55:02 +0200 In-Reply-To: (Tony Finch's message of "Tue, 12 Aug 2008 14:38:22 +0100") Message-ID: <82fxpa41i1.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Tony Finch: > On Tue, 12 Aug 2008, Peter Koch wrote: >> >> Let's see what different flavors the forged responses can have: Thanks for posting this summary. > Now about > > ;; QUESTION SECTION: > ;345678.example.org. IN A > > ;; ANSWER SECTION: > 345678.example.org. 3600 IN CNAME www.example.org. > www.example.org. 3600 IN A 192.0.2.80 ; evil IIRC, it has been argued that the AA bit only applies to the top-most CNAME (or the record whose name matches the QNAME, forgot whih). Based on that, RFC 2181 rules would prevent a cache override. There are a few more things. First, using RCODE=3D3 to clear the cache: | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39020 |=20 | ;; QUESTION SECTION: | ;www.example.org. IN TYPE1337 ; varies =20 followed by: =20 | ;; QUESTION SECTION: | ;www.example.org. IN A |=20 | ;; ANSWER SECTION: | www.example.org. 3600 IN A 192.0.2.80 ; evil >From a statistical point of view, this is less interesting because it requires spoofing in quick succession. It doesn't work against all implementations, either. I don't think it's covered by RFC 2181. The other approach is: | ;; QUESTION SECTION: | ;www.example.org. IN TYPE1337 ; varies |=20 | ;; ANSWER SECTION: | www.example.org. 3600 IN CNAME evil.example.net. Again, the effectiveness of this trick depends heavily on the cache implementation. Some might have a RTYPE-specific CNAME cache, some might throw away the existing A record once they encounter the CNAME, some may prefer the existing record, until it expires from the cache, when they start using the CNAME. (The wording I suggested for the DNAME draft assumes that the CNAME caching rules are updated to address this.) I think the following has already been mentioned? | ;; QUESTION SECTION: | ;235223.example.org. IN MX |=20 | ;; ANSWER SECTION: | 235223.example.org. 3600 IN MX 10 www.example.org. | | ;; ADDITIONAL SECTION: | www.example.org. 3600 IN A 192.0.2.80 ; evil Again, RFC 2181 should cover this. Anything else with additional section processing is affected in a similar way (and should be treated similarly). --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 10:14:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4331A3A69E3; Tue, 12 Aug 2008 10:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] 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 GW5vEt38ThpW; Tue, 12 Aug 2008 10:14:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6780F3A67FE; Tue, 12 Aug 2008 10:14:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSxM6-000NIv-C4 for namedroppers-data@psg.com; Tue, 12 Aug 2008 17:08:22 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSxM2-000NI9-Qf for namedroppers@psg.com; Tue, 12 Aug 2008 17:08:20 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3B754A1056; Tue, 12 Aug 2008 17:08:15 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Olafur Gudmundsson cc: "Jay R. Ashworth" , namedroppers@psg.com In-Reply-To: Your message of "Mon, 11 Aug 2008 20:32:48 -0400." <200808120032.m7C0WqNc078602@stora.ogud.com> References: <20080811190427.GD9082@cgi.jachomes.com> <200808120032.m7C0WqNc078602@stora.ogud.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Tue, 12 Aug 2008 17:08:15 +0000 Message-ID: <16599.1218560895@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 3B754A1056.B7D09 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Why *can* cached DNS replies be overwritten? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: nonreplacement of rrsets is not a general fix. there are plenty of kaminsky message patterns that rely only on insertion of new data. so while i'm having great fun with just reducing the TTL when a replacement is attempted, especially with NS RRsets, it doesn't make me safe. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 10:15:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E82B3A6B7A; Tue, 12 Aug 2008 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.278 X-Spam-Level: X-Spam-Status: No, score=-4.278 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, 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 PRRs5E40T345; Tue, 12 Aug 2008 10:15:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A34473A69CC; Tue, 12 Aug 2008 10:15:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSxOG-000NYv-4u for namedroppers-data@psg.com; Tue, 12 Aug 2008 17:10:36 +0000 Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSxOC-000NYN-Md for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 17:10:34 +0000 Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KSxOA-0003B1-Nz; Tue, 12 Aug 2008 19:10:30 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 9E6807E6401; Tue, 12 Aug 2008 19:10:24 +0200 (CEST) Date: Tue, 12 Aug 2008 19:10:24 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: Dealing with the NS RRSet [Re: Why *can* cached DNS replies be overwritten?] Message-ID: <20080812171024.GH39395@unknown.office.denic.de> References: <20080811190427.GD9082@cgi.jachomes.com> <20080812120923.GB39395@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Aug 12, 2008 at 02:38:22PM +0100, Tony Finch wrote: > Now about not NS RRSet based, but still ... > ;; QUESTION SECTION: > ;345678.example.org. IN A > > ;; ANSWER SECTION: > 345678.example.org. 3600 IN CNAME www.example.org. > www.example.org. 3600 IN A 192.0.2.80 ; evil Can be mitigated two ways: 1) do not believe anything after the (first) CNAME RR (DNAME with CNAME synthesis needs special consideration) 2) again, do not overwrite anything in the cache, unless the new response is _more_ credible (as opposed to "greater or equal") -Peter -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 11:26:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5173A6839; Tue, 12 Aug 2008 11:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.15 X-Spam-Level: X-Spam-Status: No, score=-4.15 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, 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 XZyyfRn4TKfl; Tue, 12 Aug 2008 11:26:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 466BF3A693D; Tue, 12 Aug 2008 11:26:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSyPL-0004Ur-JV for namedroppers-data@psg.com; Tue, 12 Aug 2008 18:15:47 +0000 Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KSyPG-0004Tv-Fc for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 18:15:45 +0000 Received: from denic.de ([10.122.65.106]) by office.denic.de with esmtp id 1KSyPD-0004rO-QK; Tue, 12 Aug 2008 20:15:39 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id ACE1E7E661B; Tue, 12 Aug 2008 20:15:39 +0200 (CEST) Date: Tue, 12 Aug 2008 20:15:39 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: WGLC summary for draft-ietf-dnsext-forgery-resilience Message-ID: <20080812181539.GJ39395@unknown.office.denic.de> References: <20080718200235.GG73459@commandprompt.com> <20080730192907.GA4703@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080730192907.GA4703@outpost.ds9a.nl> User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jul 30, 2008 at 09:29:07PM +0200, bert hubert wrote: > I've updated chapter 9 as outlined in the posting by Andrew, plus addressed > all nits Peter Koch had open. I've read -06 and the diffs and thank Bert for patiently addressing all these editorial issues. New nit in new section 9.2.1: "DNS ID" isn't consistently used throughout the document; that can be fixed through RFC Editor work, or might not even be ambiguous. > Jinmei. Additionally, Peter Koch told me he sent me an example which would > fit well in the draft, but I can't find it, but I did promise I'd include > it. The example appears as a comment to section 6 in . However, in the light of recent events and also since section 6 addresses a different threat than the rest of teh recommendation, I'm no longer sure it is helpful (although examples in general are ;-) -Peter -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 14:16:10 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F8E3A6913; Tue, 12 Aug 2008 14:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, J_CHICKENPOX_32=0.6, 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 4qXm4kDA9JnS; Tue, 12 Aug 2008 14:16:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEF703A6927; Tue, 12 Aug 2008 14:16:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT122-000LyV-Gn for namedroppers-data@psg.com; Tue, 12 Aug 2008 21:03:54 +0000 Received: from [83.136.33.3] (helo=labs.nic.at) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT11y-000Lxv-NB for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 21:03:52 +0000 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1KT11n-000677-00; Tue, 12 Aug 2008 23:03:39 +0200 Date: Tue, 12 Aug 2008 23:03:39 +0200 From: Otmar Lendl To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC groupthink versus improving DNS) Message-ID: <20080812210339.GA23393@nic.at> References: <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> <489C5202.4080405@nic.at> <20080812.164048.246546894.he@uninett.no> <48A1B41B.1060707@nic.at> <20080812164603.GA27562@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080812164603.GA27562@commandprompt.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 2008/08/12 18:08, Andrew Sullivan wrote: > On Tue, Aug 12, 2008 at 06:02:35PM +0200, Otmar Lendl wrote: > > > I'm in brainstorming mode, so: Why can't 5011 be used by TLDs instead of > > extending the Registry/Registrar protocol? That change takes time > > and puts the Registrar into the critical path for DNSSEC rollout. > > In at least some cases, two reasons: > > 1. The EPP extension for DS management has been ready for ages. So > there's very little work to do there anyway. It's in RFC 4310. (Of > course, some registries aren't using EPP, so it's not relevant to them.) It's not the protocol extension specification, which is the problem. It's getting the registrars to actually implement it and support it in their customer-facing interfaces. Bringing the registrar into the loop also might means legal work: T&Cs, liability questions, ... > 2. Many TLDs aren't actually allowed to talk to the party that has > administrative control of the domain. In the ICANN world, for > instance, registries may only speak to the registrar, and not the > registrant. This is admittedly a policy and not a technical reason, > but it's a reason anyway. Acknowledged, but luckily that doesn't apply to .at. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 15:49:16 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052B63A68E0; Tue, 12 Aug 2008 15:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] 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 6kLMOTlSrhKj; Tue, 12 Aug 2008 15:49:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB92C3A68A4; Tue, 12 Aug 2008 15:49:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT2aH-0004qQ-BG for namedroppers-data@psg.com; Tue, 12 Aug 2008 22:43:21 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT2aC-0004pl-ES for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 22:43:18 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7CMh9tB072871; Wed, 13 Aug 2008 08:43:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808122243.m7CMh9tB072871@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Tue, 12 Aug 2008 09:40:07 MST." Date: Wed, 13 Aug 2008 08:43:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At 11:18 +1000 8/11/08, Mark Andrews wrote: > > > DNS security is required for SMTP security to work. > > That is why the SIKED (Secure Internet KEy Distribution) BoF failed, 53rd IET > F. > > If SMTP security works because DNS security works, then a DNS > security failure means SMTP security fails too. A house of cards. > This is what is feared. Lots of things really depend on DNS working as intended. I'm just sick and tired of all those who think that hop by hop security is enough for the DNS. It isn't and it never has been. It is time to put the little bit of effort into creating DNSKEY's and signing your zones. It really isn't a big operational effort that everyone keeps saying it is without actually attempting to do it. > (see also http://www.potaroo.net/ietf/idref/draft-lewis-siked-dnsargs/) > > Thanks to Geoff Huston for maintaining that repository. Although I'd > call it "Pandora's Box" because of all of the bad ideas documented in > there that never mad it to RFC. ;) > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 15:52:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5823E3A68A4; Tue, 12 Aug 2008 15:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=0.533, 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 cZfEV4AFdEKz; Tue, 12 Aug 2008 15:52:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 123813A67DA; Tue, 12 Aug 2008 15:52:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT2aM-0004r1-Sx for namedroppers-data@psg.com; Tue, 12 Aug 2008 22:43:26 +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 ) id 1KT2aI-0004qW-S2 for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 22:43:24 +0000 Received: from [192.168.7.242] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7CMhHwr089644; Tue, 12 Aug 2008 18:43:18 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Tue, 12 Aug 2008 15:43:15 -0700 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: DNSSEC and alternatives Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I've partly read the threads on the Kaminsky "bug" and how DNSSEC is either the savior or, possibly in alliance with the bug, devil incarnate. First, to those that believe DNSSEC is an ugly pig, an ugly hack, I say you are wrong. DNSSEC was carefully designed to protect the DNS from the threats of cache poisoning, in general, against the spoofing of records between an authoritative server and anything doing the asking. Second to those that are skeptical of deploying DNSSEC, I say you are right. Even if DNSSEC is good technology, that doesn't mean it should be pressed into service. And to those of you who think you can build a "better mousetrap" I encourage you. But is isn't a race against DNSSEC, it's a race against the vulnerabilities in DNS. And remember - if the solution comes to mind easily, someone else before you probably has already thought it and tried it, so don't be disappointed if everyone else is skeptical of the new mousetrap. The problem with DNSSEC is that it has no problems. If it had a defect that prevented its adoption, then there would be something to engineer. The problem with DNSSEC is not it, but that the situation for which it was designed doesn't need it badly enough to employ it. --------------------- Each part of the DNSSEC design was carefully considered. There were many design choices made, many alternate solutions tossed aside. The current definition is the third incarnation of the protocol to be defined in RFCs. In about 2004 there was a push that culminated in the NSEC3 RFC. At that time I posted a message going over the design decisions that gave us the NSEC record. (See http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01406.html) Read that message to see the conscious design decision process. We had to give something up to eliminate zone enumeration to arrive at what is now called NSEC3. DNSSEC is not the problem. It is what it is. It is a solution to the problem of spoofed data. It values completeness in security, compatibility with operations, at the cost of having to maintain a key infrastructure. For those that get hung up on the off-line, air-gapped key, that is a vestige of the time the Security Area managed the development of the protocol (DNSSEC WG days), it really isn't important at all to operations. Personally I think and have always thought it was overkill. DNSSEC has taken time, a long time, to develop. Why is this usually cast as a negative comment? The time spent to generate the extensions is a sign of the careful consideration that went into it. The reason for three iterations is that we workshopped the technology over and over and rethought where it stunk. At least it was never rushed into service. For all the platitudes I am laying at the feet of DNSSEC, my recent presentations have been anti-DNSSEC. There are presentations at APTLD in February and a CENTR meeting floating around which I won't post the URL for here. My anti-DNSSEC sentiment is not about the technology, my anti-ness is about whether the problems it solves are important enough to solve at that cost or whether there is a cheaper (less op-ex) means to attain the same protection. Or, extending the last, cheaper while attaining a sufficient but lesser level (sliding scale) of protection. I've witnessed the DNSSEC deployment process from its beginning (with the publishing of RFC 2065) to now, from the first meeting at IETF 41 where the funding for BIND 9 began to appear. (Doing the math, IETF 72 - IETF 41 = 31, 31/(3/year) = 10.333333333 years. More than a decade now.) I was there when the process consisted of workshops, tutorials, code fixes, protocol fixes, supplemental documentation, tools, more additions, rewrites, etc. All of this succeeded in developing a workable extension to DNS, compatible with the underlying protocol but still a boatload of operational work. Perhaps in order to understand DNSSEC you have to join the "groupthink" mind-meld. And that would be a problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 16:12:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF3328C14B; Tue, 12 Aug 2008 16:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] 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 Z3yFpnz2IFK0; Tue, 12 Aug 2008 16:12:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DE823A694E; Tue, 12 Aug 2008 16:12:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT2vk-0006eM-KX for namedroppers-data@psg.com; Tue, 12 Aug 2008 23:05:32 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT2vf-0006dg-Sv for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 23:05:30 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7CN5NPB073032; Wed, 13 Aug 2008 09:05:23 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808122305.m7CN5NPB073032@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: transfering vs. loading a zone In-reply-to: Your message of "Tue, 12 Aug 2008 08:25:46 MST." Date: Wed, 13 Aug 2008 09:05:23 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > During the DNSEXT meeting at IETF 72 one topic came up regarding the > "AXFR clarify" draft. The topic is "the difference between a zone > transfer and zone load operation." > > The issue begins with the question "what is in a zone?" That > question is what derailed the document a half decade ago. The > question is not that easy to answer. > > There is a statement in the original RFCs about what is in a zone, > and the statement is pretty clear. However, the advent of dynamic > update (with the ability to add a cut point) created a class of > records now called "obscured records" and this class gained > additional importance with the advent of DNAME. > > Obscured records are not the first records which can be classified as > "wrong" but are legitimately tied to a zone, earlier examples of this > are "bad" glue records, i.e., glue record with different address(es) > than the authoritative data they represent. > > Complicating matters, once we recognize that bad glue and obscured > records are legitimate parts of a zone, through the fact that the > records were added by the administrator, what about "typos?" Of > course, a typo of transposing bits in a AAAA record is something the > DNS itself won't know about, but a typo like: > > > $ORIGIN example. > @ SOA ... > <...> > ns1.nic AAAA 3ffe::1 > ns1.nic. A 127.0.0.1 > > The AAAA shown is for ns1.nic.example. and the A is ns1.nic. Is the > address record for ns1.nic. in the zone even though this might make a > name server refuse to load and serve the zone? > > This raises the issue - what is in a zone? I see three possible > (extreme) answers: > > 1.) Exactly what the administrator places into the zone. > 2.) The subset of #1 excluding typos. > 3.) The best data that should be there. What the administrator places into the zone. You can refuse to load it but you can't split it. You get everything or you get nothing. BIND operated for too long with best effort loading. This, in the end, caused lots of problems operational problems. Mark > If #1 is done perfectly right, then all three are the same. > > Why not #3? If the nameservers start editing the zone, > troubleshooting becomes troublesome. From personal experience, I > knew of an erstwhile zone that had many, many lame delegations. Most > servers for the zone also served all of the children, meaning it was > hard to capture the lame delegations. But one server exposed the > lame delegations and that was causing operational problems. > Fortunately, as an operator of a slave for the zone I got a copy of > the zone via AXFR and was able to debug and alert the admin. > > It pays to let errors become exposed. Makes debugging easier. Of > course, covering over bumps is good - if all the covering is done the > same way. In an interoperable world though, nothing is always "done > the same way." > > A comment was made at the mic in the meeting that we should think of > a zone "for a particular serial number." And the zone for a > particular serial number is "set in stone" when the zone is > successfully loaded at the master server. Not by the administrator, > and zones that fail to load never get to be that version. This is > because only after the master loads the zone will either there be > NOTIFYs sent or the slaves will poll and see the incremented serial > number. If any name server, especially the master, "edits" the zone > (that is loads a subset of what is given), the name server has taken > an editing pen to the administrator's work. > > Why not #2? It isn't clear if typo errors are objectively defined. > I haven't thought all the way through but my hunch is that trying to > algorithmically decide if a mistake was made is nearly impossible. > > So that leaves #1, "warts and all." In my opinion, it's the right > approach, but then again this is an opinion to be expressed by the > working group. > > But let's assume for now a zone is defined as #1, and press on to the > issue of loading a zone (from an AXFR - as AXFR is the topic at hand). > > If an AXFR will deliver to a name server the contents of a zone > according to the criteria of #1 above, the name server ought to do > some sanity checking on it. I.e., the zone is not #3, it is not > ready for immediate consumption. > > A name server could parse the zone and decide not to serve it due to > errors. A name server has to recognize the "obscured" (or "occluded" > I forget the term we want to use) records. > > Here's an open question. If a name server gets a zone via AXFR > (presumably the name server had a reason to ask for it) and decides > the zone is bad and returns SERVFAIL to all queries for data in the > zone, will the name server still store the zone, send NOTIFYs and > serve it as AXFR/IXFR? > > Is it possible for a name server to hold a cache of zones that failed > to load? I mean, one failed load per zone configured, not a running > history. > > Is the decision to transfer a zone different from the decision to > load and serve a zone? > > This is meant to start an open discussion...so maybe this isn't all > wrapped up, but I'm seeking comments. Eventually this will be in a > section about the differences between AXFR and loading. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 12 16:34:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBE73A691A; Tue, 12 Aug 2008 16:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 o8D-RS0OST9N; Tue, 12 Aug 2008 16:34:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7A563A6847; Tue, 12 Aug 2008 16:34:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT3Gl-0008L9-3D for namedroppers-data@psg.com; Tue, 12 Aug 2008 23:27:15 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KT3Gb-0008Jq-Tg for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 23:27:09 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7CNQv9u073254; Wed, 13 Aug 2008 09:26:58 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808122326.m7CNQv9u073254@drugs.dv.isc.org> To: Otmar Lendl Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC groupthink versus improving DNS) In-reply-to: Your message of "Tue, 12 Aug 2008 23:03:39 +0200." <20080812210339.GA23393@nic.at> Date: Wed, 13 Aug 2008 09:26:57 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On 2008/08/12 18:08, Andrew Sullivan wrote: > > On Tue, Aug 12, 2008 at 06:02:35PM +0200, Otmar Lendl wrote: > > > > > I'm in brainstorming mode, so: Why can't 5011 be used by TLDs instead of > > > extending the Registry/Registrar protocol? That change takes time > > > and puts the Registrar into the critical path for DNSSEC rollout. > > > > In at least some cases, two reasons: > > > > 1. The EPP extension for DS management has been ready for ages. So > > there's very little work to do there anyway. It's in RFC 4310. (Of > > course, some registries aren't using EPP, so it's not relevant to them.) > > It's not the protocol extension specification, which is the problem. > It's getting the registrars to actually implement it and support it in > their customer-facing interfaces. Bringing the registrar into the loop > also might means legal work: T&Cs, liability questions, ... They are already in the loop. They are already exposed. This happens the moment they attempt to change any record in the parent zone. There is no difference between changing/adding a NS, A or AAAA records and DS records. You can do as much damage with any of them. Do the wrong thing and the zone is not visible or it is handed to a attacker. DS records do not change that exposure in anyway. This is also a strength of DNSSEC. It doesn't change the trust model. The same person that is authorised to change the NS, A and AAAA records is also the same person that changes the DS records. > > 2. Many TLDs aren't actually allowed to talk to the party that has > > administrative control of the domain. In the ICANN world, for > > instance, registries may only speak to the registrar, and not the > > registrant. This is admittedly a policy and not a technical reason, > > but it's a reason anyway. > > Acknowledged, but luckily that doesn't apply to .at. > > /ol > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 > // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H > // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 03:56:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F28B3A6CD5; Wed, 13 Aug 2008 03:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.283 X-Spam-Level: ** X-Spam-Status: No, score=2.283 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 x9s8hTj4X2RN; Wed, 13 Aug 2008 03:56:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 45E2E3A6CEA; Wed, 13 Aug 2008 03:56:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTDsp-000C5T-SS for namedroppers-data@psg.com; Wed, 13 Aug 2008 10:47:15 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTDsl-000C4v-Ki for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 10:47:14 +0000 Received: (qmail 19845 invoked from network); 13 Aug 2008 10:50:39 -0000 Received: from bmdi2217.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (202.221.174.217) by necom830.hpcl.titech.ac.jp with SMTP; 13 Aug 2008 10:50:39 -0000 Message-ID: <48A2BB7D.90408@necom830.hpcl.titech.ac.jp> Date: Wed, 13 Aug 2008 19:46:21 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: transfering vs. loading a zone References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Edward Lewis wrote: > The issue begins with the question "what is in a zone?" That question > is what derailed the document a half decade ago. The question is not > that easy to answer. The issue is vaguely recognized but not addressed in RFC1034 and a solution was given 15 years ago or so in initial versions of IXFR draft. That is, glue As in zone information must be tagged by refferal point, though neither zone file format nor AXFR allows to do so, which is why I tried to fix it with IXFR. The result was that no one else even tried to understand the issue, which now resulted in Kaminsky's variation of ID attack with glue A. > Here's an open question. If a name server gets a zone via AXFR > (presumably the name server had a reason to ask for it) and decides the > zone is bad and returns SERVFAIL to all queries for data in the zone, Hugh? If a name server tries to receive a new version of a zone and fails, it should continue to use an older version of the zone until it expires. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 04:10:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B121E3A6C64; Wed, 13 Aug 2008 04:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 c0YKGCnK-mpM; Wed, 13 Aug 2008 04:10:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B9CD3A6884; Wed, 13 Aug 2008 04:10:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTE7Q-000DLy-Au for namedroppers-data@psg.com; Wed, 13 Aug 2008 11:02:20 +0000 Received: from [131.111.8.134] (helo=ppsw-4.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTE7M-000DLa-KP for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 11:02:18 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49311) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1KTE7J-0007g7-Dd (Exim 4.70) (return-path ); Wed, 13 Aug 2008 12:02:13 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KTE7J-0004Gm-6Z (Exim 4.67) (return-path ); Wed, 13 Aug 2008 12:02:13 +0100 Date: Wed, 13 Aug 2008 12:02:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Florian Weimer cc: Peter Koch , IETF DNSEXT WG Subject: Re: Dealing with the NS RRSet [Re: Why *can* cached DNS replies be overwritten?] In-Reply-To: <82fxpa41i1.fsf@mid.bfk.de> Message-ID: References: <20080811190427.GD9082@cgi.jachomes.com> <20080812120923.GB39395@unknown.office.denic.de> <82fxpa41i1.fsf@mid.bfk.de> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: What if you ask for a subdomain of your target and spoof a referral saying the target name is a zone cut? This doesn't directly overwrite the cache, but when the cached record for www.example.org expires the attacker's nameserver will be asked for an update. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1234 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;345678.www.example.org. IN A ;; AUTHORITY SECTION: www.example.org. 86400 IN NS evil.example.net. ;; ADDITIONAL SECTION: evil.example.net. 86400 IN A 192.0.2.53 Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND PLYMOUTH: SOUTHWESTERLY 7 TO SEVERE GALE 9, DECREASING 5 OR 6 IN WIGHT, PORTLAND AND PLYMOUTH. ROUGH OR VERY ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 04:27:27 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5AC3A6CAF; Wed, 13 Aug 2008 04:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 8KMDlbLY9lQM; Wed, 13 Aug 2008 04:27:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B1ED28C0E1; Wed, 13 Aug 2008 04:27:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTER2-000FB8-Ee for namedroppers-data@psg.com; Wed, 13 Aug 2008 11:22:36 +0000 Received: from [85.17.178.134] (helo=stipula.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTEQx-000FAU-Sr for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 11:22:34 +0000 Received: from localhost (localhost [127.0.0.1]) by stipula.dds.nl (Postfix) with ESMTP id DBA6D795954; Wed, 13 Aug 2008 13:22:30 +0200 (CEST) Received: from [192.168.254.2] (unknown [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stipula.dds.nl (Postfix) with ESMTP id 6854179596F; Wed, 13 Aug 2008 13:22:18 +0200 (CEST) Message-ID: <48A2C3E9.9070000@nlnetlabs.nl> Date: Wed, 13 Aug 2008 13:22:17 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Masataka Ohta CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: transfering vs. loading a zone References: <48A2BB7D.90408@necom830.hpcl.titech.ac.jp> In-Reply-To: <48A2BB7D.90408@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/8024/Wed Aug 13 12:14:07 2008 on stipula X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Agree with Mark, that the server that loads the zone from text file (or whatever the first source) can refuse to send the zone through the ecosystem. It can admit the zone, but then keep it as written by the owner. How to distinguish load from transfer? After a reboot, a transferred zone is loaded from disk. And master or slave configuration may not be a clue either in complicated mesh setups. Masataka Ohta wrote: | Edward Lewis wrote: |> Here's an open question. If a name server gets a zone via AXFR |> (presumably the name server had a reason to ask for it) and decides the |> zone is bad and returns SERVFAIL to all queries for data in the zone, | | Hugh? If a name server tries to receive a new version of a zone and fails, | it should continue to use an older version of the zone until it expires. Yes. Best regards, ~ Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiiw+kACgkQkDLqNwOhpPiIBACfbyT2pUN4QajkDA/2bWyyH1BO Ny0Anj30RayKGWLkL6UAEeP0l/4HHQij =1GgV -----END PGP SIGNATURE----- -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 05:49:23 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D833A69CD; Wed, 13 Aug 2008 05:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.310, 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 1B2u8bCi17Zh; Wed, 13 Aug 2008 05:49:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 204C73A6896; Wed, 13 Aug 2008 05:49:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTFhs-000MvF-Fh for namedroppers-data@psg.com; Wed, 13 Aug 2008 12:44:04 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTFhl-000Mu7-I9 for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 12:43:59 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7DCkiOF016127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Aug 2008 05:46:47 -0700 Date: Wed, 13 Aug 2008 08:43:53 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC groupthink versus improving DNS) Message-ID: <20080813124353.GC39653@commandprompt.com> References: <489B09FE.8050701@e164.org> <49451.1218124457@nsa.vix.com> <489C5202.4080405@nic.at> <20080812.164048.246546894.he@uninett.no> <48A1B41B.1060707@nic.at> <20080812164603.GA27562@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080812164603.GA27562@commandprompt.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Wed, 13 Aug 2008 05:46:47 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Tue, Aug 12, 2008 at 12:46:03PM -0400, Andrew Sullivan wrote: > administrative control of the domain. In the ICANN world, for > instance, registries may only speak to the registrar, and not the > registrant. Someone kindly reminded me that I should have been clearer about scope here: the registries of which I'm speaking there are only the gTLDs. Some ccTLDs have an agreement with ICANN but aren't subject to such rules; also, of course, many (all? I can't think of an exception at the moment) sTLDs have a community arrangement that ensures the registry and registrants have a direct relationship along side the relationship between the registrant and registrar. Sorry for any confusion, A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 06:37:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E803A69E7; Wed, 13 Aug 2008 06:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=-0.472, 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 JD0eGomlJChb; Wed, 13 Aug 2008 06:37:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8BA43A6876; Wed, 13 Aug 2008 06:37:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTGSe-0001nt-Jn for namedroppers-data@psg.com; Wed, 13 Aug 2008 13:32:24 +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 ) id 1KTGSV-0001mV-0c for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 13:32:22 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7DDWCb2096688 for ; Wed, 13 Aug 2008 09:32:12 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m7DDWCuN096687 for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 09:32:12 -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 ) id 1KSzok-000E2d-3P for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 19:46:10 +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 m7CJjwWk020889 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Aug 2008 15:45:59 -0400 Date: Tue, 12 Aug 2008 15:45:57 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: David Conrad cc: "=?ISO-8859-1?Q?Jesper_G._H=F8y?=" , Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: Message-ID: 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: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Mon, 11 Aug 2008, David Conrad wrote: > > > Only SSL can protect you here. > > As Dan Kaminsky points out: "SSL certs themselves are dependent on the > DNS". Kaminsky is wrong. SSL uses DNS to obtain an IP address to connect to a server, and then expects the server to produce a certificate, which the client verifies. Spoofing DNS does not enable the attacker to obtain the private key to the valid certificate. The DNS domain information placed in a certificate merely allows the client to determine before verification if it got the certificate it asked for. However the wrong or fake certificate won't verify unless there is a fault in the Certification Authority (this happened with MS some years ago). But a spoofed DNS name going to a wrong server results in a failure to verify the certificate. So SSL is NOT "dependent on DNS". Of course, if spoofed DNS sends the SSL connection to the wrong server, a DOS attack still results since one didn't get to the correct server. In that sense, everything a user does is dependent on DNS. But it is not the case that your bank information can be stolen by this DNS attack, as Kaminsky seems to have told the mainstream press. --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: From owner-namedroppers@ops.ietf.org Wed Aug 13 06:59:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2A03A6BBF; Wed, 13 Aug 2008 06:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 MWY7aSUK+fun; Wed, 13 Aug 2008 06:59:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DCC23A67AF; Wed, 13 Aug 2008 06:59:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTGoJ-0003sk-IL for namedroppers-data@psg.com; Wed, 13 Aug 2008 13:54:47 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTGoF-0003s1-4D for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 13:54:45 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=Zpbqyvu6gPajd3QwyIskPm6oMJse/dhmGwReq4+PpoMuHxoyHph0dS8O dGS9tXTD3eBbL0hF4Eju01N/nYMoVCXzaqMa0cdqXvNt6fZKOrlHtSzvj 8ZJT8DsrNJCMRFi; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1218635683; x=1250171683; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20How =20do=20we=20get=20the=20whole=20world=20to=20upgrade=20t o=20DNSSEC=20capable=20resolvers?|Date:=20Wed,=2013=20Aug =202008=2014:54:39=20+0100|Message-ID:=20|To:=20Namedroppers=20WG=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20; bh=h0iWLl7IWMNGxKRM/84olT1bfhatGSAeujAvACxkOkU=; b=F8o520cVLfdpQ7BBAUdqRNNc3URDqpu+XIWii3v8APCngA/zpyoS8mzu XMIq8gv7XtGwuzodO/Yx4hnTd3alaEoHMWaXB3aVqztDpZwgfORmD0dK5 KGe7+EChici5HJ5; X-IronPort-AV: E=Sophos;i="4.32,201,1217804400"; d="scan'208";a="5976773" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 13 Aug 2008 14:54:40 +0100 In-Reply-To: References: To: Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 13 Aug 2008 14:54:39 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 13/08/2008 02:54:40 PM, Serialize complete at 13/08/2008 02:54:40 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > But it is not the case that your bank information can be stolen by this > DNS attack, as Kaminsky seems to have told the mainstream press. Unless your bank used a weak cert generated on a Debian system... Ray -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 09:00:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673113A6A66; Wed, 13 Aug 2008 09:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 sMImn8dUSzet; Wed, 13 Aug 2008 09:00:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48A873A67A2; Wed, 13 Aug 2008 09:00:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTIfM-000GOJ-DM for namedroppers-data@psg.com; Wed, 13 Aug 2008 15:53:40 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTIfH-000GNI-3r for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 15:53:38 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=ca.afilias.info; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=KI7gpX/v4v6/H563DApwcGC+mDMqRk0pKTanUhJo4yPk1SiQZ6agnX2jA25UdRt3I9Golpd2WMTmY26+NCvUwBRZ8uyTkQrfyO9+C1M7slYxxwC67wuO05wK8tKHm1Wt; Received: from [216.254.172.187] (helo=[192.168.1.3]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTIe0-0006Kk-5Z; Wed, 13 Aug 2008 15:52:17 +0000 Cc: Namedroppers WG Message-Id: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> From: Joe Abley To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Wed, 13 Aug 2008 11:52:14 -0400 References: X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 13 Aug 2008, at 09:54, Ray.Bellis@nominet.org.uk wrote: >> But it is not the case that your bank information can be stolen by >> this >> DNS attack, as Kaminsky seems to have told the mainstream press. > > Unless your bank used a weak cert generated on a Debian system... Or unless the authentication performed by the CA is easily subverted, leading them to sell a certificate with a to-be-spoofed common name to a third party. (Requests sent on faxed letterheads; e-mail confirmations exchanged with the listed domain contacts; etc.) SSL is only as good as (a) CA signing policies and (b) users reliability in not ignoring certificate warnings. In practice (in my opinion) this makes SSL protection for services quite weak, in general. Joe -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 09:11:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394413A6A31; Wed, 13 Aug 2008 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 93TpTw7A35tT; Wed, 13 Aug 2008 09:11:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4130E3A69C3; Wed, 13 Aug 2008 09:11:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTIsZ-000Hmd-JI for namedroppers-data@psg.com; Wed, 13 Aug 2008 16:07:19 +0000 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTIsS-000Hlz-Of for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 16:07:14 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6E16850846; Wed, 13 Aug 2008 09:17:54 -0700 (PDT) Date: Wed, 13 Aug 2008 09:17:54 -0700 From: Eric Rescorla To: Dean Anderson Cc: David Conrad , "=?ISO-8859-1?Q?Jesper_G._H=F8y?=" , Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080813161754.6E16850846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Tue, 12 Aug 2008 15:45:57 -0400 (EDT), Dean Anderson wrote: > On Mon, 11 Aug 2008, David Conrad wrote: > > > > > Only SSL can protect you here. > > > > As Dan Kaminsky points out: "SSL certs themselves are dependent on the > > DNS". > > Kaminsky is wrong. SSL uses DNS to obtain an IP address to connect to a > server, and then expects the server to produce a certificate, which the > client verifies. Spoofing DNS does not enable the attacker to obtain the > private key to the valid certificate. The DNS domain information placed > in a certificate merely allows the client to determine before > verification if it got the certificate it asked for. However the wrong > or fake certificate won't verify unless there is a fault in the > Certification Authority (this happened with MS some years ago). But a > spoofed DNS name going to a wrong server results in a failure to verify > the certificate. So SSL is NOT "dependent on DNS". Based on my brief skim of Kaminsky's presentation, I think his argument is that because CAs often use e-mail answerback as a certificate validation mechanism, a compromise of DNS can be used to obtain a fake SSL/TLS certificate. Of course, there's nothing stopping CAs from requesting more validation (in fact, I believe that's what EV certificates already do), in which case there would not be a DNS-based threat. That said, it's not clear to me that the situation is significantly better with DNSSEC. Both certificates and signed zone signing keys are attestations that a given public key corresponds to the owner of a given domain name/group of names. The non-cryptographic question is how the signer of the credential determines whether a given candidate public key is correct. But this question is more or less the same for DNS servers and CAs, because in both cases there is generally not a cryptographic credential, but just an authoritative contact point, which often reduces to an email address. -Ekr -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 09:18:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867113A69C3; Wed, 13 Aug 2008 09:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 SYqVRB30M0Y9; Wed, 13 Aug 2008 09:18:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B2F013A6970; Wed, 13 Aug 2008 09:18:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTIxX-000IK7-6k for namedroppers-data@psg.com; Wed, 13 Aug 2008 16:12:27 +0000 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTIxS-000IJQ-T0 for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 16:12:25 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9AA7250846; Wed, 13 Aug 2008 09:23:04 -0700 (PDT) Date: Wed, 13 Aug 2008 09:23:04 -0700 From: Eric Rescorla To: Ray.Bellis@nominet.org.uk Cc: Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080813162304.9AA7250846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 13 Aug 2008 14:54:39 +0100, Ray.Bellis@nominet.org.uk wrote: > > > But it is not the case that your bank information can be stolen by this > > DNS attack, as Kaminsky seems to have told the mainstream press. > > Unless your bank used a weak cert generated on a Debian system... ... And you haven't installed one of the weak key blacklists. -Ekr -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 09:29:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99413A6B41; Wed, 13 Aug 2008 09:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=0.400, 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 Wb3sFxGpHKti; Wed, 13 Aug 2008 09:29:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 846B43A6B0C; Wed, 13 Aug 2008 09:29:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJ9G-000JT0-SV for namedroppers-data@psg.com; Wed, 13 Aug 2008 16:24:34 +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 ) id 1KTJ97-000JRw-Ty for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 16:24:32 +0000 Received: from [204.74.78.201] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7DGKLgM097963; Wed, 13 Aug 2008 12:20:22 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <48A2C3E9.9070000@nlnetlabs.nl> References: <48A2BB7D.90408@necom830.hpcl.titech.ac.jp> <48A2C3E9.9070000@nlnetlabs.nl> Date: Wed, 13 Aug 2008 09:20:17 -0700 To: "W.C.A. Wijngaards" From: Edward Lewis Subject: Re: transfering vs. loading a zone Cc: Masataka Ohta , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Well, this is kind of what I was wondering about. Can a name server receive a zone via AXFR, examine it and decide it's rotten but then turn around and send it as an AXFR server? Would the server then send out NOTIFY messages as if it loaded the zone? (Mind you, this is the AXFR document, but I want to know anyway.) I suppose that having a rotten zone in the server would also complicate IXFR, huh? Perhaps a name server should toss any rotten zones. But, but, but... But what if a subset of authoritative servers decide to load the zone with serial number 9. The admin though sees that serial number 8 is the last everywhere, looks at a log of one of the rejecting machines, edits the zone and tries to load it as 9 again. Now the rejecters will pick this up and serve it as 9, but the ones that loaded the previous 9 will not pick it up (as the serial number didn't increment). Should a server remember the last SOA serial it saw, regardless of the successful loading of the one. I.e., separation of the zone transfer process and loading process. At 13:22 +0200 8/13/08, W.C.A. Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, > >Agree with Mark, that the server that loads the zone from text file (or >whatever the first source) can refuse to send the zone through the >ecosystem. It can admit the zone, but then keep it as written by the owner. > >How to distinguish load from transfer? After a reboot, a transferred >zone is loaded from disk. And master or slave configuration may not be >a clue either in complicated mesh setups. > >Masataka Ohta wrote: >| Edward Lewis wrote: >|> Here's an open question. If a name server gets a zone via AXFR >|> (presumably the name server had a reason to ask for it) and decides the >|> zone is bad and returns SERVFAIL to all queries for data in the zone, >| >| Hugh? If a name server tries to receive a new version of a zone and fails, >| it should continue to use an older version of the zone until it expires. > >Yes. > >Best regards, >~ Wouter >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > >iEYEARECAAYFAkiiw+kACgkQkDLqNwOhpPiIBACfbyT2pUN4QajkDA/2bWyyH1BO >Ny0Anj30RayKGWLkL6UAEeP0l/4HHQij >=1GgV >-----END PGP SIGNATURE----- > >-- >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: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 09:30:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261D23A6B51; Wed, 13 Aug 2008 09:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=1.712, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] 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 93tPKZ-25By6; Wed, 13 Aug 2008 09:30:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 364433A6B2A; Wed, 13 Aug 2008 09:30:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJ8z-000JQy-8r for namedroppers-data@psg.com; Wed, 13 Aug 2008 16:24:17 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJ8v-000JIQ-44 for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 16:24:15 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m7DGMLIP001357; Wed, 13 Aug 2008 16:22:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id m7DGMKs9001356; Wed, 13 Aug 2008 16:22:20 GMT Date: Wed, 13 Aug 2008 16:22:20 +0000 From: bmanning@vacation.karoshi.com To: Joe Abley Cc: Ray.Bellis@nominet.org.uk, Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080813162220.GA1285@vacation.karoshi.com.> References: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Aug 13, 2008 at 11:52:14AM -0400, Joe Abley wrote: > > On 13 Aug 2008, at 09:54, Ray.Bellis@nominet.org.uk wrote: > > >>But it is not the case that your bank information can be stolen by > >>this > >>DNS attack, as Kaminsky seems to have told the mainstream press. > > > >Unless your bank used a weak cert generated on a Debian system... > > Or unless the authentication performed by the CA is easily subverted, > leading them to sell a certificate with a to-be-spoofed common name to > a third party. > > (Requests sent on faxed letterheads; e-mail confirmations exchanged > with the listed domain contacts; etc.) > > SSL is only as good as (a) CA signing policies and (b) users > reliability in not ignoring certificate warnings. In practice (in my > opinion) this makes SSL protection for services quite weak, in general. > > Joe do i have the dance steps right? trap a query/response pair forge the reply - stuff the additional section w/ self-executing code to dump a self-signed cert to a "mimic" bank site into the local browser cache stuff the DNS cache with a "mismatched" name -> address pair, where the address is to the "mimic" site. the browser is none the wiser, SSL is happy. looks like the walz of deception to me. --bill -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 09:44:17 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E673D28C0E7; Wed, 13 Aug 2008 09:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.355 X-Spam-Level: X-Spam-Status: No, score=-4.355 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, 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 Zv6ofU1vNp5H; Wed, 13 Aug 2008 09:44:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6E283A67A8; Wed, 13 Aug 2008 09:44:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJOO-000LCE-6n for namedroppers-data@psg.com; Wed, 13 Aug 2008 16:40:12 +0000 Received: from [204.152.186.148] (helo=hankinsfamily.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJNj-000L7s-52 for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 16:39:34 +0000 Received: from navarre.mercenary.net (c-24-6-53-214.hsd1.ca.comcast.net [24.6.53.214]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id m7DGdUss010750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Aug 2008 09:39:30 -0700 Received: by navarre.mercenary.net (Postfix, from userid 1000) id 0ABCE7E753; Wed, 13 Aug 2008 09:39:36 -0700 (PDT) Date: Wed, 13 Aug 2008 09:39:36 -0700 From: "David W. Hankins" To: namedroppers@ops.ietf.org Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <20080813163936.GA18651@isc.org> References: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Aug 13, 2008 at 11:52:14AM -0400, Joe Abley wrote: > On 13 Aug 2008, at 09:54, Ray.Bellis@nominet.org.uk wrote: >>> But it is not the case that your bank information can be stolen by this >>> DNS attack, as Kaminsky seems to have told the mainstream press. >> >> Unless your bank used a weak cert generated on a Debian system... > > Or unless the authentication performed by the CA is easily subverted, > leading them to sell a certificate with a to-be-spoofed common name to a > third party. Or even Kaminsky-subverting http://www.bank.com/ to point to a host which produces a redirect to https://www.bankfoo.com/, which is under the attacker's full control. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 10:13:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360883A698F; Wed, 13 Aug 2008 10:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 Ti85XI4oLOH0; Wed, 13 Aug 2008 10:13:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 504A83A68B9; Wed, 13 Aug 2008 10:13:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJoj-000Nj5-LB for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:07:25 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJoY-000Nhq-La for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:07:23 +0000 X-IronPort-AV: E=Sophos;i="4.32,202,1217808000"; d="scan'208";a="19875104" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 13 Aug 2008 17:07:13 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m7DH7DFh016748; Wed, 13 Aug 2008 10:07:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7DH7DA2017460; Wed, 13 Aug 2008 17:07:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 10:07:13 -0700 Received: from dhcp-171-71-97-135.cisco.com ([171.71.97.135]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 10:07:13 -0700 Message-ID: <48A314C1.7060907@cisco.com> Date: Wed, 13 Aug 2008 10:07:13 -0700 From: Jim Fenton User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Eric Rescorla CC: Ray.Bellis@nominet.org.uk, Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: <20080813162304.9AA7250846@romeo.rtfm.com> In-Reply-To: <20080813162304.9AA7250846@romeo.rtfm.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2008 17:07:13.0379 (UTC) FILETIME=[07C3CB30:01C8FD67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=562; t=1218647233; x=1219511233; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20 |Subject:=20Re=3A=20How=20do=20we=20get=20the=20whole=20wor ld=20to=20upgrade=20to=20DNSSEC=20capable=20resolvers? |Sender:=20; bh=ppnKhjVw7HtYqIH0rgVvOfT3uemTfM1dbr+prak8ZZs=; b=LiCQFHSowwJVGPb09HCnZhmwGbyMBArNZi9yR6nULzYf8kbKZHtjok90xT Pq1S4p6TNmcWXZWqAXymphtE+5/u12OG/YXyTkGNdxKjwakLs3oznVI9PHxi lPQmWQwMPF; Authentication-Results: sj-dkim-3; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Eric Rescorla wrote: > At Wed, 13 Aug 2008 14:54:39 +0100, > Ray.Bellis@nominet.org.uk wrote: > >>> But it is not the case that your bank information can be stolen by this >>> DNS attack, as Kaminsky seems to have told the mainstream press. >>> >> Unless your bank used a weak cert generated on a Debian system... >> > > ... And you haven't installed one of the weak key blacklists. > The issue here isn't one of us, it's the typical banking customer. Have they installed one of the weak key blacklists? I think not. -Jim -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 10:14:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54183A698F; Wed, 13 Aug 2008 10:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.948, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 d1UxEV32JrH2; Wed, 13 Aug 2008 10:14:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B9D483A68B9; Wed, 13 Aug 2008 10:14:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJsx-000O81-Eq for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:11:47 +0000 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJst-000O7F-4E for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:11:44 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id D89DC50846; Wed, 13 Aug 2008 10:22:24 -0700 (PDT) Date: Wed, 13 Aug 2008 10:22:24 -0700 From: Eric Rescorla To: bmanning@vacation.karoshi.com Cc: Joe Abley , Ray.Bellis@nominet.org.uk, Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: <20080813162220.GA1285@vacation.karoshi.com.> References: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080813172224.D89DC50846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 13 Aug 2008 16:22:20 +0000, bmanning@vacation.karoshi.com wrote: > > On Wed, Aug 13, 2008 at 11:52:14AM -0400, Joe Abley wrote: > > > > On 13 Aug 2008, at 09:54, Ray.Bellis@nominet.org.uk wrote: > > > > >>But it is not the case that your bank information can be stolen by > > >>this > > >>DNS attack, as Kaminsky seems to have told the mainstream press. > > > > > >Unless your bank used a weak cert generated on a Debian system... > > > > Or unless the authentication performed by the CA is easily subverted, > > leading them to sell a certificate with a to-be-spoofed common name to > > a third party. > > > > (Requests sent on faxed letterheads; e-mail confirmations exchanged > > with the listed domain contacts; etc.) > > > > SSL is only as good as (a) CA signing policies and (b) users > > reliability in not ignoring certificate warnings. In practice (in my > > opinion) this makes SSL protection for services quite weak, in general. > > > > Joe > > > do i have the dance steps right? > > trap a query/response pair > > forge the reply - stuff the additional section w/ self-executing code to > dump a self-signed cert to a "mimic" bank site into the local > browser cache This is the step I got lost at. You're assuming that there is some bug in the browser that will allow a malicious DNS response to inject information into the browser certificate cache? It's certainly possible that that's true, but if so, then you've most likely got a generic remote exploit for the browser, so why bother with any fanciness about trapping queries and responses, SSL, etc get the user to dereference *your* domain name (remember that the premise here is that the attacker can get the user to dereference domain names of his choice) stuff the attack payload in the response and subvert the user's computer directly? > stuff the DNS cache with a "mismatched" name -> address pair, where the > address is to the "mimic" site. > > the browser is none the wiser, SSL is happy. > > looks like the walz of deception to me. Again, why other with this stuff? At this point you control the user's computer and can simply passively tap all his communications. -Ekr -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 10:15:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DC128C0E7; Wed, 13 Aug 2008 10:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.682 X-Spam-Level: X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=0.813, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 mPbypmsioFSP; Wed, 13 Aug 2008 10:15:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62D633A68B9; Wed, 13 Aug 2008 10:15:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJoz-000Nk4-4h for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:07:41 +0000 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTJov-000Nje-EI for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:07:39 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id D7B3C50846; Wed, 13 Aug 2008 10:18:16 -0700 (PDT) Date: Wed, 13 Aug 2008 10:18:16 -0700 From: Eric Rescorla To: Joe Abley Cc: Ray.Bellis@nominet.org.uk, Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> References: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080813171816.D7B3C50846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 13 Aug 2008 11:52:14 -0400, Joe Abley wrote: > > > On 13 Aug 2008, at 09:54, Ray.Bellis@nominet.org.uk wrote: > > >> But it is not the case that your bank information can be stolen by > >> this > >> DNS attack, as Kaminsky seems to have told the mainstream press. > > > > Unless your bank used a weak cert generated on a Debian system... > > Or unless the authentication performed by the CA is easily subverted, > leading them to sell a certificate with a to-be-spoofed common name to > a third party. > > (Requests sent on faxed letterheads; e-mail confirmations exchanged > with the listed domain contacts; etc.) > > SSL is only as good as (a) CA signing policies and (b) users > reliability in not ignoring certificate warnings. In practice (in my > opinion) this makes SSL protection for services quite weak, in general. As I should have stated earlier, I'm not offering a general defense of SSL certificates or PKI practices in general. However, exactly these same issues apply to decisions made about DNS domain transfers/ information modification, key signing, etc. The problem here is not PKI or DNSSEC but that we have no good mechanisms in the generic case for determining whether a given individual is authorized to control a given domain. This makes any cryptographic authentication of domain name ownership problematic. -Ekr -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 10:24:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09A33A6C04; Wed, 13 Aug 2008 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.373, 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 6tgEnpS61PF8; Wed, 13 Aug 2008 10:24:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BCBEA3A6AC3; Wed, 13 Aug 2008 10:24:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTK1w-000P3p-T8 for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:21:04 +0000 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTK1s-000P2q-4P for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:21:02 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 3BF4E50846; Wed, 13 Aug 2008 10:31:40 -0700 (PDT) Date: Wed, 13 Aug 2008 10:31:40 -0700 From: Eric Rescorla To: Jim Fenton Cc: Eric Rescorla , Ray.Bellis@nominet.org.uk, Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: <48A314C1.7060907@cisco.com> References: <20080813162304.9AA7250846@romeo.rtfm.com> <48A314C1.7060907@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20080813173140.3BF4E50846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Wed, 13 Aug 2008 10:07:13 -0700, Jim Fenton wrote: >=20 > Eric Rescorla wrote: > > At Wed, 13 Aug 2008 14:54:39 +0100, > > Ray.Bellis@nominet.org.uk wrote: > > =20 > >>> But it is not the case that your bank information can be stolen by th= is > >>> DNS attack, as Kaminsky seems to have told the mainstream press. > >>> =20 > >> Unless your bank used a weak cert generated on a Debian system... > >> =20 > > > > ... And you haven't installed one of the weak key blacklists. > > =20 >=20 > The issue here isn't one of us, it's the typical banking customer. Have = > they installed one of the weak key blacklists? I think not. Yes, I agree that it would be nice if the browsers shipped out of the box with blacklisting.=20 Of course, that depends on the users running the latest version of the browser (see [FDOM08]), but if they're not then presumably they're open to all sorts of non-TLS remote exploits, so why is this one special? -Ekr [FDOM08] S. Frei, T. D=FCbendorfer, G. Ollmann, M. May, "Understanding the = Web browser threat: Examination of vulnerable online Web browser populations and the "insecurity iceberg"", Defcon 2008, August 2008. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 10:24:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B473A6C01; Wed, 13 Aug 2008 10:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 7iUM3TrInTHv; Wed, 13 Aug 2008 10:24:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 746CC28C136; Wed, 13 Aug 2008 10:24:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTK07-000Ore-Im for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:19:11 +0000 Received: from [64.18.2.173] (helo=exprod7og110.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTK03-000Oqt-Vq for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:19:09 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 10:19:03 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id DA5CD1A8208; Wed, 13 Aug 2008 10:19:03 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (66.93.162.128) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 13 Aug 2008 10:19:03 -0700 CC: Namedroppers WG Message-ID: From: Ted Lemon To: Dean Anderson In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Wed, 13 Aug 2008 10:19:00 -0700 References: X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 12, 2008, at 12:45 PM, Dean Anderson wrote: > But it is not the case that your bank information can be stolen by > this > DNS attack, as Kaminsky seems to have told the mainstream press. You are right that SSL would protect the user. However, the Kaminsky vulnerability provides an opportunity for a downgrade attack. If the attacker presents a self-signed cert, some percentage of users will accept it, thus accepting the security downgrade. For those users, the fact that SSL would protect them doesn't help. If we can stop the Kaminsky attack, we can prevent this particular downgrade attack. Security is not just about secure protocols. You have to take into account what the user will do as well. A thousand-dollar safe is no use you don't lock it. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 10:32:08 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0711E3A6C3A; Wed, 13 Aug 2008 10:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.415 X-Spam-Level: X-Spam-Status: No, score=-5.415 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 BbBPkjSWQ+35; Wed, 13 Aug 2008 10:32:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E59C63A69AD; Wed, 13 Aug 2008 10:32:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTK8d-000Pps-Ot for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:27:59 +0000 Received: from [64.18.2.163] (helo=exprod7og105.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTK8U-000Pow-IU for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:27:57 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 13 Aug 2008 10:27:16 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id A41191A8206; Wed, 13 Aug 2008 10:27:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (66.93.162.128) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 13 Aug 2008 10:27:16 -0700 CC: "bmanning@vacation.karoshi.com" , Joe Abley , "Ray.Bellis@nominet.org.uk" , Namedroppers WG Message-ID: From: Ted Lemon To: Eric Rescorla In-Reply-To: <20080813172224.D89DC50846@romeo.rtfm.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Wed, 13 Aug 2008 10:27:14 -0700 References: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> <20080813172224.D89DC50846@romeo.rtfm.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Eric, one other thing to bear in mind with banks is that the typical user goes to http://www.bank.com and types in their password in the login form presented to them. All I (the attacker) have to do to get their password is to arrange for the form with which they are presented to submit the password to an http:// URL instead of the bank's HTTPS:// URL. SSL doesn't happen, so the user is not told about the invalid cert. And chances are they've disabled the "insecure form" warning, because it pops up too often in cases where it doesn't matter. The attacker can then tunnel the rest of the session, presenting the user with the illusion that they have in fact completed a transaction with the bank, leaving them no wiser to the fact that their login information has been compromised. This will work even if the bank has a policy of presenting password forms only on SSL pages, because the average user won't know this, and thus won't be suspicious if they are offered a login on a non-https:// page. So the dance that's involved in phishing the user is really a lot simpler than you think, and the value of subverting the DNS is thus a lot higher. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 10:33:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53023A6990; Wed, 13 Aug 2008 10:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[AWL=0.027, 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 n1+1sY30UrRu; Wed, 13 Aug 2008 10:33:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1C9828C129; Wed, 13 Aug 2008 10:33:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTK8o-000PrR-7E for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:28:10 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTK8k-000Pqg-BI for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:28:08 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 416921F402D; Thu, 14 Aug 2008 03:28:05 +1000 (EST) Message-ID: <48A319A0.20209@e164.org> Date: Thu, 14 Aug 2008 03:28:00 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk, Namedroppers Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ray.Bellis@nominet.org.uk wrote: >> But it is not the case that your bank information can be stolen by this >> DNS attack, as Kaminsky seems to have told the mainstream press. > > Unless your bank used a weak cert generated on a Debian system... US banks are notorious for not using https URIs for the initial form where customers log in to web banking, someone was doing up a name and shame list on banks a while back over this. -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 10:39:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B0A3A6B24; Wed, 13 Aug 2008 10:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599] 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 2krfN6rFMeuq; Wed, 13 Aug 2008 10:39:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49F663A6990; Wed, 13 Aug 2008 10:39:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTKFg-0000f7-JA for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:35:16 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTKFc-0000eG-Vk for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:35:14 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id ADA67A66B0; Wed, 13 Aug 2008 17:35:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "David W. Hankins" cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 13 Aug 2008 09:39:36 MST." <20080813163936.GA18651@isc.org> References: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> <20080813163936.GA18651@isc.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 13 Aug 2008 17:35:01 +0000 Message-ID: <36468.1218648901@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: ADA67A66B0.38B69 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Or even Kaminsky-subverting http://www.bank.com/ to point to a host > which produces a redirect to https://www.bankfoo.com/, which is under > the attacker's full control. no real reason to s/bank/bankfoo/ in that example. once you've got the A RR for www.bank.com you can just not redirect folks to https:. (their bookmark is likely to be for the http: site, as will their search engine exit.) or if the attacker wants to get CRAZY they can redirect to https: quite safely since the majority of endusers will just click "OK" on the resulting X.509 warning, without reading it or understanding it. kaminsky's plan to get a key issued by polluting the caching server of a CA so that one can successfully emulate the desired common-name attribute is harder work than needs doing, and so, i predict the criminals will take an easier way. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 11:02:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3DD3A67F3; Wed, 13 Aug 2008 11:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, 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 sQK6udrUBm0a; Wed, 13 Aug 2008 11:02:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A19DE3A63CB; Wed, 13 Aug 2008 11:02:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTKbD-0002yV-O9 for namedroppers-data@psg.com; Wed, 13 Aug 2008 17:57:31 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTKbA-0002yA-18 for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 17:57:29 +0000 Received: from [10.0.1.199] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 757962D2BF4; Wed, 13 Aug 2008 10:57:26 -0700 (PDT) Cc: Namedroppers WG Message-Id: <6C901653-139A-44BB-A11C-F244712F0362@virtualized.org> From: David Conrad To: Eric Rescorla In-Reply-To: <20080813161754.6E16850846@romeo.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Date: Wed, 13 Aug 2008 10:57:22 -0700 References: <20080813161754.6E16850846@romeo.rtfm.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 13, 2008, at 9:17 AM, Eric Rescorla wrote: > At Tue, 12 Aug 2008 15:45:57 -0400 (EDT), >>>> Only SSL can protect you here. >>> As Dan Kaminsky points out: "SSL certs themselves are dependent on >>> the >>> DNS". >> Kaminsky is wrong. > Based on my brief skim of Kaminsky's presentation, I think his > argument is that because CAs often use e-mail answerback as a > certificate validation mechanism, a compromise of DNS can be used to > obtain a fake SSL/TLS certificate. That is (as I understand) part of it. > Of course, there's nothing stopping > CAs from requesting more validation (in fact, I believe that's what EV > certificates already do), in which case there would not be a DNS-based > threat. Right. And if the CA uses VOIP that does a DNS lookup, or if the databases the CA uses are reached via DNS, or if the CA uses software that does self-updates after looking up the 'phone home' server via DNS, or .... I believe what Dan was pointing out is the DNS is an underlying infrastructure which all sorts of other infrastructure relies upon and if you can crack the DNS infrastructure, lots of other stuff becomes much more "interesting" (in the Ebola virus sense of 'interesting'), sometimes in ways that aren't necessarily obvious. Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 11:15:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DBB3A6C8D; Wed, 13 Aug 2008 11:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.372 X-Spam-Level: X-Spam-Status: No, score=0.372 tagged_above=-999 required=5 tests=[AWL=0.867, 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 fm7phuQbWm5s; Wed, 13 Aug 2008 11:15:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A77F53A6C49; Wed, 13 Aug 2008 11:15:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTKnL-00042Y-Nd for namedroppers-data@psg.com; Wed, 13 Aug 2008 18:10:03 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTKnG-00041H-IL for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 18:10:01 +0000 Received: from [192.168.100.2] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 6CA40C2DA3; Wed, 13 Aug 2008 19:09:54 +0100 (BST) Date: Wed, 13 Aug 2008 19:09:52 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , "David W. Hankins" cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? Message-ID: <12C066D444F4C70CD898C411@Ximines.local> In-Reply-To: <36468.1218648901@nsa.vix.com> References: <764E89A0-32D2-4555-B61C-C8B7D88EB9E1@ca.afilias.info> <20080813163936.GA18651@isc.org> <36468.1218648901@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 13 August 2008 17:35:01 +0000 Paul Vixie wrote: >> Or even Kaminsky-subverting http://www.bank.com/ to point to a host >> which produces a redirect to https://www.bankfoo.com/, which is under >> the attacker's full control. > > no real reason to s/bank/bankfoo/ in that example. once you've got the A > RR for www.bank.com you can just not redirect folks to https:. Perhaps there is no real reason but all 4 of the online banking services I use do this. Alex -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 16:23:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C834F3A6891; Wed, 13 Aug 2008 16:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] 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 hn3lzRtu-JaQ; Wed, 13 Aug 2008 16:23:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD0A63A6874; Wed, 13 Aug 2008 16:22:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTPYh-0004hV-TN for namedroppers-data@psg.com; Wed, 13 Aug 2008 23:15:15 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTPYe-0004gv-3U for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 23:15:13 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7DNEqMU094748; Thu, 14 Aug 2008 09:14:53 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808132314.m7DNEqMU094748@drugs.dv.isc.org> To: Edward Lewis Cc: "W.C.A. Wijngaards" , Masataka Ohta , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: transfering vs. loading a zone In-reply-to: Your message of "Wed, 13 Aug 2008 09:20:17 MST." Date: Thu, 14 Aug 2008 09:14:52 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Well, this is kind of what I was wondering about. > > Can a name server receive a zone via AXFR, examine it and decide it's > rotten but then turn around and send it as an AXFR server? Would the > server then send out NOTIFY messages as if it loaded the zone? (Mind > you, this is the AXFR document, but I want to know anyway.) I > suppose that having a rotten zone in the server would also complicate > IXFR, huh? Ed, if the zone is deemed rotten then the SOA queries will not be answered and the downstream slave will not attempt to AXFR from the upstream slave. IXFR should conceptually be the same. The rotten SOA should not be visible to the IXFR process. All or nothing. Anything else is a problem waiting to happen. > Perhaps a name server should toss any rotten zones. But, but, but... > > But what if a subset of authoritative servers decide to load the zone > with serial number 9. The admin though sees that serial number 8 is > the last everywhere, looks at a log of one of the rejecting machines, > edits the zone and tries to load it as 9 again. Now the rejecters > will pick this up and serve it as 9, but the ones that loaded the > previous 9 will not pick it up (as the serial number didn't > increment). The administrator failed to manage the serial number properly, the results are outside the protocol because the administator failed to follow the protocol. > Should a server remember the last SOA serial it saw, regardless of > the successful loading of the one. I.e., separation of the zone > transfer process and loading process. There is no need for the slave to remember. If the administrator follows the protocol it is not required. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 17:51:17 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709673A680C; Wed, 13 Aug 2008 17:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] 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 J+gc0vScZObq; Wed, 13 Aug 2008 17:51:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 83CFB3A67A8; Wed, 13 Aug 2008 17:51:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTQwd-000BxD-QU for namedroppers-data@psg.com; Thu, 14 Aug 2008 00:44:03 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTQwa-000Bwj-1P for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 00:44:01 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7E0hkbK096439; Thu, 14 Aug 2008 10:43:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808140043.m7E0hkbK096439@drugs.dv.isc.org> To: Eric Rescorla Cc: Joe Abley , Ray.Bellis@nominet.org.uk, Namedroppers WG From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Wed, 13 Aug 2008 10:18:16 MST." <20080813171816.D7B3C50846@romeo.rtfm.com> Date: Thu, 14 Aug 2008 10:43:46 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > The problem here is not PKI or DNSSEC but that we have no good > mechanisms in the generic case for determining whether a given > individual is authorized to control a given domain. This makes any > cryptographic authentication of domain name ownership problematic. Most zones are created when they are bought. The buyer specifies the NS, DS and glue records as part of that transaction. The credentials for future transactions are established as part of that initial transaction. Now when zones are sold there are issues but those issues exist independent of whether DNSSEC is in use or not. If you are authorised to update the delegation information in the parent then you should be authorised to change the DS records in the parent as they are just part of the delegation. Changes to NS, A, AAAA and DS records as part of the delegation are equally dangerous as each other. There is no need to make the parent / child trust relationship more complicated with DNSSEC than it is without DNSSEC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 18:23:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDAE3A6A70; Wed, 13 Aug 2008 18:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=0.249, 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 xnjq6RS0UNDF; Wed, 13 Aug 2008 18:23:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C3D63A694C; Wed, 13 Aug 2008 18:23:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTRS4-000EpE-6n for namedroppers-data@psg.com; Thu, 14 Aug 2008 01:16:32 +0000 Received: from [74.95.2.169] (helo=kilo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTRS0-000Eoe-JQ for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 01:16:30 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 2DAE05369E9; Wed, 13 Aug 2008 18:16:26 -0700 (PDT) Date: Wed, 13 Aug 2008 18:16:25 -0700 From: Eric Rescorla To: Mark Andrews Cc: Eric Rescorla , Joe Abley , Ray.Bellis@nominet.org.uk, Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-Reply-To: <200808140043.m7E0hkbK096439@drugs.dv.isc.org> References: <20080813171816.D7B3C50846@romeo.rtfm.com> <200808140043.m7E0hkbK096439@drugs.dv.isc.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080814011626.2DAE05369E9@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 14 Aug 2008 10:43:46 +1000, Mark Andrews wrote: > > > > The problem here is not PKI or DNSSEC but that we have no good > > mechanisms in the generic case for determining whether a given > > individual is authorized to control a given domain. This makes any > > cryptographic authentication of domain name ownership problematic. > > Most zones are created when they are bought. The buyer > specifies the NS, DS and glue records as part of that > transaction. The credentials for future transactions are > established as part of that initial transaction. > > Now when zones are sold there are issues but those issues > exist independent of whether DNSSEC is in use or not. > > If you are authorised to update the delegation information > in the parent then you should be authorised to change the > DS records in the parent as they are just part of the > delegation. Changes to NS, A, AAAA and DS records as part > of the delegation are equally dangerous as each other. > > There is no need to make the parent / child trust relationship > more complicated with DNSSEC than it is without DNSSEC. Yes, I agree with that. But in many of these cases, the credentials are "here's the email address to contact the technical contact with". This is of course just as problematic as e-mail answerback for certificate authorites. And to the extent to which the registrars/registries have a DNS-independent way of validating the domain owners, the CAs (who in at least some cases are the same people!) could presumably leverage that to determine whether to issue the certs. -Ekr -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 21:38:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5EE3A6834; Wed, 13 Aug 2008 21:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] 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 bjpZZfw0++-o; Wed, 13 Aug 2008 21:38:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8026F3A682A; Wed, 13 Aug 2008 21:38:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTUT9-00020d-P1 for namedroppers-data@psg.com; Thu, 14 Aug 2008 04:29:51 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTUT5-000204-7B for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 04:29:49 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7E4TXeB000543; Thu, 14 Aug 2008 14:29:33 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808140429.m7E4TXeB000543@drugs.dv.isc.org> To: Eric Rescorla Cc: Joe Abley , Ray.Bellis@nominet.org.uk, Namedroppers WG From: Mark Andrews Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? In-reply-to: Your message of "Wed, 13 Aug 2008 18:16:25 MST." <20080814011626.2DAE05369E9@kilo.rtfm.com> Date: Thu, 14 Aug 2008 14:29:33 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > At Thu, 14 Aug 2008 10:43:46 +1000, > Mark Andrews wrote: > > > > > > > The problem here is not PKI or DNSSEC but that we have no good > > > mechanisms in the generic case for determining whether a given > > > individual is authorized to control a given domain. This makes any > > > cryptographic authentication of domain name ownership problematic. > > > > Most zones are created when they are bought. The buyer > > specifies the NS, DS and glue records as part of that > > transaction. The credentials for future transactions are > > established as part of that initial transaction. > > > > Now when zones are sold there are issues but those issues > > exist independent of whether DNSSEC is in use or not. > > > > If you are authorised to update the delegation information > > in the parent then you should be authorised to change the > > DS records in the parent as they are just part of the > > delegation. Changes to NS, A, AAAA and DS records as part > > of the delegation are equally dangerous as each other. > > > > There is no need to make the parent / child trust relationship > > more complicated with DNSSEC than it is without DNSSEC. > > Yes, I agree with that. But in many of these cases, the credentials > are "here's the email address to contact the technical contact with". > This is of course just as problematic as e-mail answerback for > certificate authorites. And how does this change with DNSSEC? DNSSEC doesn't magically make this any more or less important / difficult. This is NOT a DNSSEC issue. It is a delegation management issue and DNSSEC does NOT change the level of care required when managing a delegation. All DNSSEC changes is whether a DS record is recorded at the delegation or not. Labeling this a DNSSEC deployment issue is doing DNSSEC a dis-service. What would help would be for ICANN to list which registrars support DS and/or AAAA records as part of normal operations and which ones don't. By normal operations I mean that you don't have to send special email to get the records added. At the moment it's hard to find a registrar which supports AAAA and/or DS records. > And to the extent to which the registrars/registries have a > DNS-independent way of validating the domain owners, the CAs > (who in at least some cases are the same people!) could > presumably leverage that to determine whether to issue > the certs. > > -Ekr -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 22:19:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F463A6899; Wed, 13 Aug 2008 22:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.796 X-Spam-Level: ** X-Spam-Status: No, score=2.796 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 4F+iDBtefYGh; Wed, 13 Aug 2008 22:19:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E25FE3A63CB; Wed, 13 Aug 2008 22:19:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTVAv-0005LH-AA for namedroppers-data@psg.com; Thu, 14 Aug 2008 05:15:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTVAq-0005KP-8d for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 05:15:02 +0000 Received: (qmail 25003 invoked from network); 14 Aug 2008 05:12:04 -0000 Received: from softbank219001188017.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.17) by necom830.hpcl.titech.ac.jp with SMTP; 14 Aug 2008 05:12:04 -0000 Message-ID: <48A3BDB5.1000200@necom830.hpcl.titech.ac.jp> Date: Thu, 14 Aug 2008 14:08:05 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: "W.C.A. Wijngaards" CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: transfering vs. loading a zone References: <48A2BB7D.90408@necom830.hpcl.titech.ac.jp> <48A2C3E9.9070000@nlnetlabs.nl> In-Reply-To: <48A2C3E9.9070000@nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: W.C.A. Wijngaards wrote: > Agree with Mark, that the server that loads the zone from text file (or > whatever the first source) can refuse to send the zone through the > ecosystem. It can admit the zone, but then keep it as written by the > owner. With AXFR/IXFR, that is an issue only with the primary nameservers. Though RFC1034 does not disallow zone transfer with text files transferred by ftp or e-mail, nameservers receiving text zone should be considered the primary with regrad to AXFR/IXFR discussion. The problem here, however, is that zone contents recognized valid by the primary nameserver may be recognized invalid by secondary nameservers. Such inconsistencies are often caused by violent application of the concept of "bailiwick" to glue As. > | Hugh? If a name server tries to receive a new version of a zone and > fails, > | it should continue to use an older version of the zone until it expires. > > Yes. And, we hope zone administrators take care of inconsistencies between nameservers before or, in practice hopefully, immediately after the zone expiration. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 13 22:40:37 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6A83A6949; Wed, 13 Aug 2008 22:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=0.026, 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 RK3sTJ2WgWzU; Wed, 13 Aug 2008 22:40:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE5FD3A6908; Wed, 13 Aug 2008 22:40:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTVVB-0006tf-7F for namedroppers-data@psg.com; Thu, 14 Aug 2008 05:36:01 +0000 Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTVV7-0006tE-H8 for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 05:35:59 +0000 Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id B0ADDFF26D; Thu, 14 Aug 2008 15:35:58 +1000 (EST) Message-ID: <48A3C436.7090301@e164.org> Date: Thu, 14 Aug 2008 15:35:50 +1000 From: Duane at e164 dot org User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Mark Andrews CC: Eric Rescorla , Joe Abley , Ray.Bellis@nominet.org.uk, Namedroppers WG Subject: Re: How do we get the whole world to upgrade to DNSSEC capable resolvers? References: <200808140429.m7E4TXeB000543@drugs.dv.isc.org> In-Reply-To: <200808140429.m7E4TXeB000543@drugs.dv.isc.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > What would help would be for ICANN to list which registrars > support DS and/or AAAA records as part of normal operations Can't help you with DS records, but as for AAAA records: http://www.sixxs.net/faq/dns/?faq=ipv6glue -- Best regards, Duane -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 14 09:49:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB793A6917; Thu, 14 Aug 2008 09:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.644 X-Spam-Level: X-Spam-Status: No, score=0.644 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 E6Oj5Zh7zz11; Thu, 14 Aug 2008 09:49:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDEDE3A6DAD; Thu, 14 Aug 2008 09:49:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTfoi-000HhJ-Po for namedroppers-data@psg.com; Thu, 14 Aug 2008 16:36:52 +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 ) id 1KTfoT-000HfN-5j for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 16:36:49 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7EGaYSr009934 for ; Thu, 14 Aug 2008 12:36:34 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808141636.m7EGaYSr009934@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Aug 2008 12:36:31 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Re: Working Group Last Call for draft-ietf-dnsext-rfc2672bis-dname-14 In-Reply-To: <20080731173241.GB93159@commandprompt.com> References: <20080731173241.GB93159@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I know everyone is preoccupied with other thoughts for the last few weeks. Please page this draft back into your brain and send comments or at least that you have read it and/or support its advance. Thanks Olafur At 13:32 31/07/2008, Andrew Sullivan wrote: >Dear colleagues, > >This message starts a four week working group last call for "Update to >DNAME Redirection in the DNS". The latest draft, and the history of >the document, can be found at >. >If approved, the document will obsolete RFC 2672. If approved, the >document will update RFC 3363 and RFC 4294. > >Please read the document carefully. Please send any remarks you have >about the draft to the working group mailing list. > >The document process rules for this working group require that five >working group members state that they have read the document, and that >there be consensus that the document be published as a standards track >document with a target status of Proposed Standard. > >The last call ends at 2008-08-28 17:00 EDT. > >Best regards, > >Andrew (for the chairs) > >-- >Andrew Sullivan >ajs@commandprompt.com >+1 503 667 4564 x104 >http://www.commandprompt.com/ > >-- >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: -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 14 14:09:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D397C3A6801; Thu, 14 Aug 2008 14:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.574 X-Spam-Level: X-Spam-Status: No, score=-4.574 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, 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 2l2gwD3rRIas; Thu, 14 Aug 2008 14:09:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD59D3A685C; Thu, 14 Aug 2008 14:09:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTjwm-000K3F-Ej for namedroppers-data@psg.com; Thu, 14 Aug 2008 21:01:28 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTjwi-000K2f-0R for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 21:01:25 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KTjwe-000159-IM; Thu, 14 Aug 2008 17:01:20 -0400 Message-ID: <48A49D20.4040705@ca.afilias.info> Date: Thu, 14 Aug 2008 17:01:20 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Dean Anderson CC: Joe Abley , Andrew Sullivan , DNSEXT WG , iesg@ietf.org Subject: Re: Kaminsky, Cache Poisoning, and Censorship References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dean Anderson wrote: > The assertion of personal attacks is a lie and a deception of the > working group. > > > [ Personal attack on Andrew Sullivan elided for brevity. Any future claim by Mr. Anderson in the regard, should be taken as patently false. ] I can personally attest to both the integrity of Andrew Sullivan, and to the fact that everything said about him was false. I can't recall - is it libel or slander, when someone maligns someone else in writing in a malicious manner? > This abuse has to stop. > > --Dean > > Yes, you are right on this point. Please stop abusing people on IETF mailing lists. Brian P.S. NO ONE ELSE FEED THE TROLL, PLEASE. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 14 14:49:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85FDA3A6ABA; Thu, 14 Aug 2008 14:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 X0apc7T34Xp7; Thu, 14 Aug 2008 14:49:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8808B3A68BF; Thu, 14 Aug 2008 14:49:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTkdG-000OBy-Ul for namedroppers-data@psg.com; Thu, 14 Aug 2008 21:45:22 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTkd5-000OAY-8V for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 21:45:20 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3202C3A6ADD; Thu, 14 Aug 2008 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D Action:draft-ietf-dnsext-forgery-resilience-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080814214502.3202C3A6ADD@core3.amsl.com> Date: Thu, 14 Aug 2008 14:45:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Measures for making DNS more resilient against forged answers Author(s) : B. Hubert, R. Mook Filename : draft-ietf-dnsext-forgery-resilience-07.txt Pages : 25 Date : 2008-08-14 The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-forgery-resilience-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-14143938.I-D@ietf.org> --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 14 15:09:29 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C453A6A8A; Thu, 14 Aug 2008 15:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.467 X-Spam-Level: X-Spam-Status: No, score=0.467 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, 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 j+2JbCp4UGZ7; Thu, 14 Aug 2008 15:09:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FF763A68BF; Thu, 14 Aug 2008 15:09:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTkvW-00008w-EJ for namedroppers-data@psg.com; Thu, 14 Aug 2008 22:04:14 +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 ) id 1KTkvP-000087-QR for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 22:04:12 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KTkvL-0007SX-GY for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 00:04:03 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 01FF13F6C; Fri, 15 Aug 2008 00:04:16 +0200 (CEST) Date: Fri, 15 Aug 2008 00:04:16 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: Re: I-D Action:draft-ietf-dnsext-forgery-resilience-07.txt Message-ID: <20080814220416.GA28813@outpost.ds9a.nl> References: <20080814214502.3202C3A6ADD@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080814214502.3202C3A6ADD@core3.amsl.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 14, 2008 at 02:45:01PM -0700, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. The (almost) full diff between -06 and -07 can be found on http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/35 The remainder is s/July/August/ and s/-06/-07/. All changes are non-normative and solely descriptive. 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: From owner-namedroppers@ops.ietf.org Thu Aug 14 15:48:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68D93A6840; Thu, 14 Aug 2008 15:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.310, 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 r07SDy2lkGDS; Thu, 14 Aug 2008 15:48:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4653F3A681F; Thu, 14 Aug 2008 15:48:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTlXb-0003kh-C7 for namedroppers-data@psg.com; Thu, 14 Aug 2008 22:43:35 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTlXX-0003k1-5N for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 22:43:33 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7EMkIGT003010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Aug 2008 15:46:21 -0700 Date: Thu, 14 Aug 2008 18:43:26 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05 Message-ID: <20080814224325.GD60819@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 14 Aug 2008 15:46:22 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, Although it is one week later than we indicated at the Dublin meeting, this message starts a four week working group last call for "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC". The latest draft, and the history of the document, can be found at . The docment is intended for the standards track, and if adopted will become a Proposed Standard. Please read the document carefully. Please send any remarks you have about the draft to the working group mailing list. The document process rules for this working group require that they have read the document, and that there be consensus that the document be published as a standards track document, with a target status of Proposed Standard. The last call ends at 2008-09-11 17:00 EDT. Best regards, Andrew (for the chairs) -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 14 17:48:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4BB13A68A6; Thu, 14 Aug 2008 17:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599] 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 wbnDp9qIlA1F; Thu, 14 Aug 2008 17:48:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD9113A6359; Thu, 14 Aug 2008 17:48:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTnP0-000CEV-7E for namedroppers-data@psg.com; Fri, 15 Aug 2008 00:42:50 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTnOv-000CE1-UX for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 00:42:48 +0000 Received: from [165.227.249.206] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7F0gIn6079768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Aug 2008 17:42:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080814224325.GD60819@commandprompt.com> References: <20080814224325.GD60819@commandprompt.com> Date: Thu, 14 Aug 2008 17:42:41 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Two minor issues with references: - There is no reason to have the [SCHNEIER-1996] reference: pointing directly to RFC 3447 for "familiarity with RSA" is sufficient. - The reference to RFC 4641 for determining key size should be removed. The problems with the crypto in RFC 4641 is being discussed in the DNSOPS WG, NIST SP 800-57 is still an excellent reference on key sizes. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 14 21:04:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79C2D3A6C68; Thu, 14 Aug 2008 21:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=-0.266, 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 e-KSok3EVdwX; Thu, 14 Aug 2008 21:03:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65D313A6C33; Thu, 14 Aug 2008 21:03:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTqQj-0000pU-GP for namedroppers-data@psg.com; Fri, 15 Aug 2008 03:56:49 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTqQe-0000ow-Ss for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 03:56:47 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7F3xSE6025026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 20:59:31 -0700 Date: Thu, 14 Aug 2008 23:56:36 -0400 From: Andrew Sullivan To: Dean Anderson , namedroppers@ops.ietf.org Subject: A note of apology (Was: Kaminsky, Cache Poisoning, and Censorship) Message-ID: <20080815035635.GI63791@commandprompt.com> References: <48A3C436.7090301@e164.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 14 Aug 2008 20:59:34 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, Dean Anderson has brought an error to my attention: On Thu, Aug 14, 2008 at 04:31:52PM -0400, Dean Anderson wrote: > > > [ Moderators note: Post was moderated, either because it was posted by > > a non-subscriber, or because it was over 20K. > > With the massive amount of spam, it is easy to miss and therefore > > delete relevant posts by non-subscribers. > > Please fix your subscription addresses. ] > > The moderators note is false, and deceives the Working Group. I am a > subscriber, and the post was not over 20K. I wish to apologise to the members of the Working Group, and to Mr Anderson, for my error. Mr Anderson, as many of you may be aware, had his posting privileges revoked [1]. Because of that, Mr Anderson's post was caught in the same trap as non-subscribers' mail. When I approved it, I used an incorrect mechanism. That mechanism added the "Moderator's note" text you see quoted by Mr Anderson. The inserted text is therefore my fault, and I wish to correct the error. Mr Anderson's post was not moderated because of being posted by a non-subscriber, or because of its size. It was moderated because, while Mr Anderson is a subscriber to the mailing list, he is not automatically allowed to post. I should have used a different mechanism to approve his post (one that would not have added only that text). I regret the error. Olafur and I are currently reviewing mailing list administration, but this particular mistake is entirely mine. Best regards, Andrew [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00149.html -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 15 06:38:54 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966123A6DC4; Fri, 15 Aug 2008 06:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=-0.718, 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 8D05OL3xfKkD; Fri, 15 Aug 2008 06:38:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6675A3A6D98; Fri, 15 Aug 2008 06:38:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTzPL-000IJK-1S for namedroppers-data@psg.com; Fri, 15 Aug 2008 13:31:59 +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 ) id 1KTzPF-000IIh-Qd for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 13:31:56 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7FDVqPR019068 for ; Fri, 15 Aug 2008 09:31:52 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m7FDVqUV019067 for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 09:31:52 -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 ) id 1KTqW0-0001DZ-Nu for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 04:02:18 +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 m7F41hYL029243 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Aug 2008 00:01:44 -0400 Date: Fri, 15 Aug 2008 00:01:42 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Brian Dickson cc: Joe Abley , Andrew Sullivan , DNSEXT WG , Subject: Re: Kaminsky, Cache Poisoning, and Censorship In-Reply-To: <48A49D20.4040705@ca.afilias.info> Message-ID: 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: [ Note: Post was moderated. ] On Thu, 14 Aug 2008, Brian Dickson wrote: > Dean Anderson wrote: > > The assertion of personal attacks is a lie and a deception of the > > working group. > I can personally attest to both the integrity of Andrew Sullivan, and to > the fact that everything said about him was false. What personal knowledge do you have of the facts? If you have no personal knowledge of the facts, you can't make any true statement as to the facts. If you have direct personal knowledge and were involved personally, please let me know. > I can't recall - is it libel or slander, when someone maligns someone > else in writing in a malicious manner? Its libel. False reports of misconduct are libel. What I said was true, and what Andrew said about me was false. --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: From owner-namedroppers@ops.ietf.org Fri Aug 15 06:38:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047AE3A6DC0; Fri, 15 Aug 2008 06:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.071 X-Spam-Level: X-Spam-Status: No, score=-104.071 tagged_above=-999 required=5 tests=[AWL=2.229, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 PJCNr-QOfV6l; Fri, 15 Aug 2008 06:38:53 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C19BC3A6DBC; Fri, 15 Aug 2008 06:38:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KTzOf-000IFH-UD for namedroppers-data@psg.com; Fri, 15 Aug 2008 13:31:17 +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 ) id 1KTzOa-000IEc-UC for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 13:31:15 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7FDV7ID019053 for ; Fri, 15 Aug 2008 09:31:07 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m7FDV7KD019052 for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 09:31:07 -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 ) id 1KTjXN-000Hd3-JN for namedroppers@ops.ietf.org; Thu, 14 Aug 2008 20:35:15 +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 m7EKVrSO028525 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Aug 2008 16:31:58 -0400 Date: Thu, 14 Aug 2008 16:31:52 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Ben Laurie , Alex Bligh , David Conrad , bert hubert , Ted Lemon , Mark Andrews , , Brian Dickson , Joe Abley , Jelte Jansen , Andrew Sullivan , Roy Arends , , Stephane Bortzmeyer , Matthijs Mekking , "=?UTF-8?Q?Jesper_G._H=C3=B8y?=" , Danny Mayer , Tony Finch , Edward Lewis , Michael StJohns , , Eric Rescorla , "David W. Hankins" , Duane at e164 dot org , Jim Fenton , Paul Vixie , Masataka Ohta cc: DNSEXT WG , Subject: Kaminsky, Cache Poisoning, and Censorship In-Reply-To: <48A3C436.7090301@e164.org> Message-ID: 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: [ Note: Post was moderated. ] > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] The moderators note is false, and deceives the Working Group. I am a subscriber, and the post was not over 20K. The Chairs have chosen to censor messages which are relevant to WG business, but that are not exclusively technical. The type of messages they have said they will censor includes messages about RFC3979 compliance, messages about financial considerations for drafts, and messages concerning the integrity of the IETF process as described by RFC2026 section 6.5.1. In practice, they have blocked messages that merely oppose the unsubstantiated assertions of the BIND Cartel (ISC, Nomimum, UltraDNS, and Centergate Research) See http://www.av8.net/IETF-watch/DNSEXT/Management.html The assertion of personal attacks is a lie and a deception of the working group. In 2000, messages from Dr. Bernstein regarding DNS cache poisoning attacks was also censored. WG Chair Gudmundsson was involved in the censorship of those messages. WG Chair Olafur Gudmundsson has demanded that I "agree not to engage in personal attacks". Since I (Anderson) have never engaged in personal attacks, this demand is based on an implied fiction. It is known as a 'loaded question' fallacy. His demand is the same as the fallacious question 'have you stopped beating your wife?" As in the wife-beating fallacy, if I answer "no", then it seems as if I intend to continue making personal attacks, implying misconduct. If I answer "yes", it seems as if I concede to some past misconduct, also implying misconduct. WG Chair Gudmundsson was previously involved in the controversial AXFR-clarify draft promoted by the BIND Cartel and was involved in the deception of the DNSEXT WG over 1999-2002 through (at least) the censorship of Dr. Dan Bernstein, who opposed the draft. WG Chair Sullivan has specifically asserted that only technical messages can be posted to DNSEXT, denying that RFC3979 compliance, financial considerations, or discussion of the integrity of the process were appropriate subject matter. Recently appointed, WG Chair Andrew Sullivan has no relevant DNS experience, nor any long IETF experience. Sullivan has been a system administrator at Affilias for a few years, and was a protoge of Joe Abley, former ISC architech of DNS Anycast. Sullivan had also recently taken over the dubious IN-ADDR Required draft on DNSOP, renamed "Considerations for the use of DNS Reverse Mapping", but containing the same discredited claims as the IN-ADDR Required draft. This abuse has to stop. --Dean > On Mon, 11 Aug 2008, David Conrad wrote: > > > > > Only SSL can protect you here. > > > > As Dan Kaminsky points out: "SSL certs themselves are dependent on the > > DNS". > > Kaminsky is wrong. SSL uses DNS to obtain an IP address to connect to a > server, and then expects the server to produce a certificate, which the > client verifies. Spoofing DNS does not enable the attacker to obtain the > private key to the valid certificate. The DNS domain information placed > in a certificate merely allows the client to determine before > verification if it got the certificate it asked for. However the wrong > or fake certificate won't verify unless there is a fault in the > Certification Authority (this happened with MS some years ago). But a > spoofed DNS name going to a wrong server results in a failure to verify > the certificate. So SSL is NOT "dependent on DNS". > > Of course, if spoofed DNS sends the SSL connection to the wrong server, > a DOS attack still results since one didn't get to the correct server. > In that sense, everything a user does is dependent on DNS. > > But it is not the case that your bank information can be stolen by this > DNS attack, as Kaminsky seems to have told the mainstream press. > > --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: From owner-namedroppers@ops.ietf.org Sun Aug 17 13:34:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51773A69A5; Sun, 17 Aug 2008 13:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.203 X-Spam-Level: * X-Spam-Status: No, score=1.203 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_20=-0.74, 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 vlsYpugRtXIm; Sun, 17 Aug 2008 13:34:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3AEC3A6955; Sun, 17 Aug 2008 13:34:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KUoop-0008YQ-SQ for namedroppers-data@psg.com; Sun, 17 Aug 2008 20:25:43 +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 ) id 1KUooj-0008XT-Nl for namedroppers@ops.ietf.org; Sun, 17 Aug 2008 20:25:41 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KUoof-0004eN-Q7 for namedroppers@ops.ietf.org; Sun, 17 Aug 2008 22:25:33 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 0F16D3F6E; Sun, 17 Aug 2008 22:25:47 +0200 (CEST) Date: Sun, 17 Aug 2008 22:25:46 +0200 From: bert hubert To: namedroppers@ops.ietf.org Cc: davidu@everydns.net Subject: EDNS PING first draft uploaded Message-ID: <20080817202546.GA18583@outpost.ds9a.nl> Mail-Followup-To: bert hubert , namedroppers@ops.ietf.org, davidu@everydns.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi everybody, In the spirit of the request at the end of the Dublin meeting, David and I have written a draft which describes a very simple EDNS PING option. An "EDNS PING" is an EDNS option with an opaque payload, which the remote server appends to the RRsets in a response. Please find further details on: http://www.ietf.org/internet-drafts/draft-hubert-ulevitch-edns-ping-00.txt This draft aims to standardise the very bare semantics of EDNS PING, leaving out everything that is not strictly required to implement this EDNS option. This basically means that how people will *use* such PINGs is entirely up to them, but may be the subject of a followup draft. Paul Vixie generalised what needs to be done: add enough bits of entropy to resist spoofing, withoug specifying how such bits might be gained. dns-0x20, EDNS PING, fall back to TCP and repeating queries are all ways to gain bits, and might be used to meet the requirements of such a 'minimum entropy required' document. 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: From owner-namedroppers@ops.ietf.org Mon Aug 18 06:09:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CF528C181; Mon, 18 Aug 2008 06:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.118 X-Spam-Level: X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 nV4ZJB9kQwgH; Mon, 18 Aug 2008 06:09:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D10BE28C17F; Mon, 18 Aug 2008 06:09:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV4IR-000An0-MA for namedroppers-data@psg.com; Mon, 18 Aug 2008 12:57:19 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV4I8-000AkY-Fg for namedroppers@ops.ietf.org; Mon, 18 Aug 2008 12:57:16 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m7ICuYII028061 for ; Mon, 18 Aug 2008 08:56:36 -0400 Message-ID: <48A9718B.1040902@nist.gov> Date: Mon, 18 Aug 2008 08:56:43 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: IETF DNSEXT WG Subject: Text added to DNAME-bis draft Section 3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Based on Florian's comment (seconded by Paul Vixie): I would like to see section 3.4 updated with language like this: "If a recursive caching name server encounters a DNAME RR which contradicts information already in the cache (excluding CNAME records), it SHOULD NOT cache the DNAME RR, but it MAY cache the CNAME record received along with it or synthesized from the DNAME record, subject the rules for CNAME caching." Added to the draft if there are no objections (so far - none). Scott (and Wouter) -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 18 06:19:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742C328C124; Mon, 18 Aug 2008 06:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 UJp-TWYs4e9H; Mon, 18 Aug 2008 06:19:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8037B3A6AE4; Mon, 18 Aug 2008 06:19:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV4UX-000C4F-88 for namedroppers-data@psg.com; Mon, 18 Aug 2008 13:09:49 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV4UI-000C2f-Mj for namedroppers@ops.ietf.org; Mon, 18 Aug 2008 13:09:42 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m7ID92d9023507 for ; Mon, 18 Aug 2008 09:09:02 -0400 Message-ID: <48A9746E.7060101@nist.gov> Date: Mon, 18 Aug 2008 09:09:02 -0400 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05 References: <20080814224325.GD60819@commandprompt.com> In-Reply-To: <20080814224325.GD60819@commandprompt.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote: > Dear colleagues, > > Although it is one week later than we indicated at the Dublin meeting, > this message starts a four week working group last call for "Use of > SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for > DNSSEC". The latest draft, and the history of the document, can be > found at > . > > The docment is intended for the standards track, and if adopted will > become a Proposed Standard. > > Please read the document carefully. Please send any remarks you have > about the draft to the working group mailing list. > I have read the document and I support the draft progressing along the standards track. However, I agree with Paul Hoffman's comment that the reference to RFC 4641 for key sizes should be dropped. Especially considering that DNSOP WG has opened it up for revision. Scott -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 18 08:52:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E389F3A68FF; Mon, 18 Aug 2008 08:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.074 X-Spam-Level: X-Spam-Status: No, score=-100.074 tagged_above=-999 required=5 tests=[AWL=-1.722, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 ZHnGBecOUYcf; Mon, 18 Aug 2008 08:52:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 067CC3A685F; Mon, 18 Aug 2008 08:52:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6xY-00022N-Gm for namedroppers-data@psg.com; Mon, 18 Aug 2008 15:47:56 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV6xT-00021V-ON for namedroppers@ops.ietf.org; Mon, 18 Aug 2008 15:47:54 +0000 Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1748a9ef95; Tue, 19 Aug 2008 00:03:22 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2748a4fc53; Fri, 15 Aug 2008 06:02:18 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 15 Aug 2008 06:02:18 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90F73A6B30; Thu, 14 Aug 2008 14:45:32 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3202C3A6ADD; Thu, 14 Aug 2008 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-dnsext-forgery-resilience-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080814214502.3202C3A6ADD@core3.amsl.com> Date: Thu, 14 Aug 2008 14:45:01 -0700 (PDT) Cc: namedroppers@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Measures for making DNS more resilient against forged answers Author(s) : B. Hubert, R. Mook Filename : draft-ietf-dnsext-forgery-resilience-07.txt Pages : 25 Date : 2008-08-14 The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-forgery-resilience-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-14143938.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 18 10:19:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEED3A695A; Mon, 18 Aug 2008 10:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=-0.807, 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 NhQ+WpsqIa4H; Mon, 18 Aug 2008 10:19:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8D103A694A; Mon, 18 Aug 2008 10:19:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KV8Ek-000AND-So for namedroppers-data@psg.com; Mon, 18 Aug 2008 17:09:46 +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 ) id 1KV8Eg-000AMV-3l for namedroppers@ops.ietf.org; Mon, 18 Aug 2008 17:09:44 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7IH9dRK049344 for ; Mon, 18 Aug 2008 13:09:39 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m7IH9dq4049343 for namedroppers@ops.ietf.org; Mon, 18 Aug 2008 13:09:39 -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 ) id 1KU0YR-0008Ra-Ll for namedroppers@ops.ietf.org; Fri, 15 Aug 2008 14:45:29 +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 m7FEjJZG031044 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Aug 2008 10:45:19 -0400 Date: Fri, 15 Aug 2008 10:45:18 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: A note of apology (Was: Kaminsky, Cache Poisoning, and Censorship) In-Reply-To: <20080815035635.GI63791@commandprompt.com> Message-ID: 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: [ Note: Post was moderated. ] Your apology on the moderation note is accepted. --Dean On Thu, 14 Aug 2008, Andrew Sullivan wrote: > Dear colleagues, > > Dean Anderson has brought an error to my attention: > > On Thu, Aug 14, 2008 at 04:31:52PM -0400, Dean Anderson wrote: > > > > > [ Moderators note: Post was moderated, either because it was posted by > > > a non-subscriber, or because it was over 20K. > > > With the massive amount of spam, it is easy to miss and therefore > > > delete relevant posts by non-subscribers. > > > Please fix your subscription addresses. ] > > > > The moderators note is false, and deceives the Working Group. I am a > > subscriber, and the post was not over 20K. > > I wish to apologise to the members of the Working Group, and to Mr > Anderson, for my error. Mr Anderson, as many of you may be aware, had > his posting privileges revoked [1]. Because of that, Mr Anderson's > post was caught in the same trap as non-subscribers' mail. When I > approved it, I used an incorrect mechanism. That mechanism added the > "Moderator's note" text you see quoted by Mr Anderson. > > The inserted text is therefore my fault, and I wish to correct the > error. Mr Anderson's post was not moderated because of being posted > by a non-subscriber, or because of its size. It was moderated > because, while Mr Anderson is a subscriber to the mailing list, he is > not automatically allowed to post. I should have used a different > mechanism to approve his post (one that would not have added only that > text). > > I regret the error. Olafur and I are currently reviewing mailing list > administration, but this particular mistake is entirely mine. > > Best regards, > > Andrew > > [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00149.html > > -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 19 13:55:37 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5003F3A68E0; Tue, 19 Aug 2008 13:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, 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 VK91bOOBOPj4; Tue, 19 Aug 2008 13:55:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B75C3A6767; Tue, 19 Aug 2008 13:55:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVY14-000JeI-HR for namedroppers-data@psg.com; Tue, 19 Aug 2008 20:41:22 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVY10-000Jdm-49 for namedroppers@ops.ietf.org; Tue, 19 Aug 2008 20:41:20 +0000 Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1KVY0z-0008Dt-FG for namedroppers@ops.ietf.org; Tue, 19 Aug 2008 21:41:17 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KVY0y-0003el-QN for namedroppers@ops.ietf.org; Tue, 19 Aug 2008 21:41:16 +0100 Message-ID: <01c201c9023b$ee1cca40$0302a8c0@localhost> From: "George Barwood" To: Subject: Some observations on dns-0x20 Date: Tue, 19 Aug 2008 21:41:16 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BF_01C90244.4F5964A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_01BF_01C90244.4F5964A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been experimenting with the technique described ( Google for = GbDns if interested ), and have a few observations. (1) A simple way of dealing with case sensitivity when parsing a string = in a DNS requests is to preserve case if and only if the section is the = Question section. For other sections I believe that simply reducing to lower case will not = cause any problems, at least in a recursive context, and is the simplest = and best solution. (2) When checking a response, a good model is to estimate the number of = bits of entropy (random bits) that have been retained from the original = request ( I will refer to this as the Confidence value ). The port number entropy should be discounted if the program may be = behind a NAT device, unless it is known that the device preserves port = randomization. I think this might be mentioned somewhere in the = standard. If unusual responses are detected ( for example incorrect IP, Question = not copied, Question case not preserved ), the response need not be = entirely ignored, rather a suitable discount can be applied in the = entropy computation. (3) A possible implementation technique is to maintain a Confidence = field for each cache entry. When processing a response, the Confidence value computed in (2) can be = added in when an exactly matching cache element ( normally with expired = TTL ) is found. A valid cache entry is thus one which has valid TTL and valid Confidence = value ( say 50 bits ). The resolver loop can iterate until either a valid cache entry is found, = or an iteration occurs in which the cache is not updated ( this includes = updates to TTL or Confidence values ). Non-existence and error conditions can also be cached, with confidence = values. Lastly, I would like to say that I strongly support dns-0x20, and have = communicated a couple of suggested changes privately to Paul, which he = has graciously agreed to make, viz. (a) In section 7.4, to drop the words "by a factor of "several". (b) In section 5.2 to change "MUST" to "SHOULD". George Barwood ------=_NextPart_000_01BF_01C90244.4F5964A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have been experimenting with the = technique=20 described ( Google for GbDns if interested ), and have a few=20 observations.
 
(1) A simple way of dealing with case = sensitivity=20 when parsing a string in a DNS requests is to preserve case if and only = if the=20 section is the Question section.
 
For other sections I believe that = simply reducing=20 to lower case will not cause any problems, at least in a recursive = context, and=20 is the simplest and best solution.
 
(2)  When checking a response, a = good model is=20 to estimate the number of bits of entropy (random bits) that have been = retained=20 from the original request ( I will refer to this as the Confidence value = ).
 
The port number entropy should be = discounted if=20 the program may be behind a NAT device, unless it is known = that the=20 device preserves port randomization. I think this might be = mentioned=20 somewhere in the standard.
 
If unusual responses are detected ( for = example=20 incorrect IP, Question not copied, Question case not preserved ), the = response=20 need not be entirely ignored, rather a suitable discount can be applied = in the=20 entropy computation.
 
(3) A possible implementation = technique=20 is to maintain a Confidence field for each cache entry.
When processing a response, the = Confidence value=20 computed in (2) can be added in when an exactly matching cache element ( = normally with expired TTL ) is found.
 
A valid cache entry is thus one which = has valid TTL=20 and valid Confidence value ( say 50 bits ).
 
The resolver loop can iterate until = either a valid=20 cache entry is found, or an iteration occurs in which the cache is = not=20 updated ( this includes updates to TTL or Confidence values = ).
 
Non-existence and error conditions can = also be=20 cached, with confidence values.
 
Lastly, I would like to say that I = strongly support=20 dns-0x20, and have communicated a couple of suggested changes = privately to=20 Paul, which he has graciously agreed to make, viz.
 
(a) In section 7.4, to drop the words = "by a factor=20 of "several".
(b) In section 5.2 to change "MUST" to=20 "SHOULD".
 
George=20 Barwood
------=_NextPart_000_01BF_01C90244.4F5964A0-- -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 08:42:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D39E3A6C19; Wed, 20 Aug 2008 08:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] 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 MCXaWNX7N5qK; Wed, 20 Aug 2008 08:42:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDFD33A682B; Wed, 20 Aug 2008 08:42:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVphq-0004Lk-Ca for namedroppers-data@psg.com; Wed, 20 Aug 2008 15:34:42 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVphl-0004Kp-4v for namedroppers@ops.ietf.org; Wed, 20 Aug 2008 15:34:40 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B0682A67D0 for ; Wed, 20 Aug 2008 15:27:03 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 20 Aug 2008 17:07:25 +0200." <82bpzn3etu.fsf@mid.bfk.de> References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> <82bpzn3etu.fsf@mid.bfk.de> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 20 Aug 2008 15:27:03 +0000 Message-ID: <81795.1219246023@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: B0682A67D0.8F039 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: i started a thread on dnsop that really belongs on namedroppers. moving it. florian weimer wrote, quoting paul vixie: > [QTYPE=ANY deprecation] > > > so, can you explain what you mean by "breaks", both for sendmail and > > qmail? > > I thought deprecation means that responders (especially resolvers) are > free to discard such queries. At least that's how the binary label > deprecation was interpreted by some folks. I don't see how this would > be different, at least for resolvers. i propose that an empty answer be sent, so that anyone waiting on it would know to move on to their next state. > [QCLASS != IN deprecation] > > > i don't think we should foreclose the possibility that QCLASS != IN > > will be useful to somebody some day. do you know a specific risk > > for QCLASS != IN? > > Reducing the arbitrariness of the DNS header reduces the risk that you > run into a query/response loop with some other service (like chargen > or time). that's not a specific enough risk to warrant outlawing a bit pattern, imho. > >> > RA=1 AND RD=0 > >> > >> By the responder or the initiator? > > > > nonrecursive queries of recursive servers [snip] > > Ahem, my concern was that the RA bit is set by the responder, while > the RD bit is set by the initiator. RA=1 *queries* don't make much > sense, no matter what the RD bit is. As Peter Koch noted, RA=1, RD=0 > responses occur in the wild. So I was confused. so you're OK with my proposal that if a responder has no authority data matching the question and RD=0 that it should send back an empty answer? > [DNS over TCP deprecation] > > >> I strongly oppose this approach. Unsolicited TCP has its place. > > > > are you strongly in favour of amending RFC 1035 4.2.2 to say that > > responders initiate close, or that timeouts of less than two minutes > > are allowed? > > No need to update RFC 1035, RFC 1123 already did that: "A name server > MAY limit the resources it devotes to TCP queries" (section 6.1.3.2). its justification for this is the 512 octet barrier then in force, and so i can see that this text should have been explicitly modified by RFC 2671 since there is now a well defined non-TCP method of crossing that barrier. however, that section also begins as follows: 6.1.3.2 Transport Protocols DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. so, TCP/53 is already optional, which explains why so many people treat it as optional. word on the street is, if you're not answering AXFR and you never set the TC bit in UDP/53, you don't have to implement TCP/53. what i didn't realize until you referenced RFC 1123 6.1.3.2, is that this isn't just the word on the street, it's well supported in the scriptures. anyone who proposes TCP/53 as a fallback during keyhole attacks, take note: it's not required; and if implemented, it's incredibly vulnerable to attack; and in any case it will not scale. > > did RDP (RFC 908, RFC 1151) ever achieve critical mass? > > Not likely, given that the acronym has been reused for something totally > different. I think for reliable datagram transport with some deployment, > you need to use SCTP. I've never seen this RDP in the wild. ok, same question then. is SCTP something we should consider as a way out of our bad choice between IP fragmentation and TCP for messages larger than the MTU? makes it sound safe and wonderful. "man 4 sctp" on FreeBSD looks healthy. as always, my big concern is "what will the middleboxes do?" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 09:59:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1003A6BDF; Wed, 20 Aug 2008 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.205 X-Spam-Level: X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 QQLma5Bwt2+f; Wed, 20 Aug 2008 09:59:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D4C13A6B89; Wed, 20 Aug 2008 09:59:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVqx8-000D5a-BM for namedroppers-data@psg.com; Wed, 20 Aug 2008 16:54:34 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVqwz-000D40-Ae for namedroppers@ops.ietf.org; Wed, 20 Aug 2008 16:54:30 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KVqwn-0008RD-Ju; Wed, 20 Aug 2008 18:54:13 +0200 Received: from fweimer by bfk.de with local id 1KVqwu-0006TQ-L3; Wed, 20 Aug 2008 18:54:21 +0200 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> <82bpzn3etu.fsf@mid.bfk.de> <81795.1219246023@nsa.vix.com> From: Florian Weimer Date: Wed, 20 Aug 2008 18:54:20 +0200 In-Reply-To: <81795.1219246023@nsa.vix.com> (Paul Vixie's message of "Wed, 20 Aug 2008 15:27:03 +0000") Message-ID: <82bpzn1vb7.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > i propose that an empty answer be sent What can stand as an empty answer? REFUSED? As a general rule, I think we shouldn't generate new cases where we don't echo back the question section. > so you're OK with my proposal that if a responder has no authority > data matching the question and RD=3D0 that it should send back an > empty answer? I think this was previously discussed on namedroppers, and there wasn't any consensus back then. (Another option besides REFUSED is referral to the root.) [DNS over TCP] > 6.1.3.2 Transport Protocols > > DNS resolvers and recursive servers MUST support UDP, and > SHOULD support TCP, for sending (non-zone-transfer) queries. > > so, TCP/53 is already optional, which explains why so many people treat > it as optional.=20 According to the quoted sentence, is optional on the initiator, not on the responder. However, operators treat it as if it were optional on the responder. > word on the street is, if you're not answering AXFR and you never > set the TC bit in UDP/53, you don't have to implement TCP/53. Yes, but I think this is wrong. Read on: A name server [...] SHOULD NOT refuse to service a TCP query just because it would have succeeded with UDP. Generally filtering TCP queries is against that recommendation. > what i didn't realize until you referenced RFC 1123 6.1.3.2, is that > this isn't just the word on the street, it's well supported in the > scriptures. I've been beating this drum for years, but there's this bizarre assumption that RFC 1123 is not as normative as RFC 1035. 8-/ > is SCTP something we should consider as a way out No, it's not. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 10:34:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4856B3A691F; Wed, 20 Aug 2008 10:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 xSklgKJHdjO9; Wed, 20 Aug 2008 10:34:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68F723A680A; Wed, 20 Aug 2008 10:34:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVrTg-000HRX-4q for namedroppers-data@psg.com; Wed, 20 Aug 2008 17:28:12 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVrTX-000HQI-Nh for namedroppers@ops.ietf.org; Wed, 20 Aug 2008 17:28:07 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 6E1841C0126; Wed, 20 Aug 2008 19:28:00 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 5EFE51C0117; Wed, 20 Aug 2008 19:28:00 +0200 (CEST) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by relay2.nic.fr (Postfix) with ESMTP id 5CE5D7B0052; Wed, 20 Aug 2008 19:28:00 +0200 (CEST) Received: from kerkenna.nic.fr (localhost [127.0.0.1]) by kerkenna.nic.fr (8.13.8/8.13.8) with ESMTP id m7KHS0KY059293; Wed, 20 Aug 2008 19:28:00 +0200 (CEST) (envelope-from souissi@kerkenna.nic.fr) Received: (from souissi@localhost) by kerkenna.nic.fr (8.13.8/8.13.8/Submit) id m7KHS0gE059292; Wed, 20 Aug 2008 19:28:00 +0200 (CEST) (envelope-from souissi) Date: Wed, 20 Aug 2008 19:28:00 +0200 From: Mohsen Souissi To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR Message-ID: <20080820172800.GF95996@kerkenna.nic.fr> References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> <82bpzn3etu.fsf@mid.bfk.de> <81795.1219246023@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81795.1219246023@nsa.vix.com> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, Please let me comment on the way your note below: On 20 Aug, Paul Vixie wrote: [...] | | > [DNS over TCP deprecation] | > | > >> I strongly oppose this approach. Unsolicited TCP has its place. | > > | > > are you strongly in favour of amending RFC 1035 4.2.2 to say that | > > responders initiate close, or that timeouts of less than two minutes | > > are allowed? | > | > No need to update RFC 1035, RFC 1123 already did that: "A name server | > MAY limit the resources it devotes to TCP queries" (section 6.1.3.2). | | its justification for this is the 512 octet barrier then in force, and so | i can see that this text should have been explicitly modified by RFC 2671 | since there is now a well defined non-TCP method of crossing that barrier. | | however, that section also begins as follows: | | 6.1.3.2 Transport Protocols | | DNS resolvers and recursive servers MUST support UDP, and | SHOULD support TCP, for sending (non-zone-transfer) queries. | | so, TCP/53 is already optional, which explains why so many people treat | it as optional. word on the street is, if you're not answering AXFR and | you never set the TC bit in UDP/53, you don't have to implement TCP/53. | what i didn't realize until you referenced RFC 1123 6.1.3.2, is that this | isn't just the word on the street, it's well supported in the scriptures. | | anyone who proposes TCP/53 as a fallback during keyhole attacks, take note: ^^^^^^^^^ | it's not required; and if implemented, it's incredibly vulnerable to attack; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | and in any case it will not scale. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I agree with you that supporting EDNS0 (RFC 2671) is far much better and scalable than TCP fallback in case od DNS response size exceeding 512 octets. Note that same section 6.1.3.2 says: "However, it is also clear that some new DNS record types defined in the future will contain information exceeding the 512 byte limit that applies to UDP, and hence will require TCP. Thus, resolvers and name ^^^^^^^^^^^ servers should implement TCP services as a backup to UDP today, with the knowledge that they will require the TCP service in the future." ^^^^^^^ As RFC 2671 could have made EDNS0 a MUST and TCP fallback simply deprecated when EDNS0 has taken over (but it actually didn't), I think we have reached today that "future" with IPv6 and DNSSEC each alone or combined (worse!). So unless, all intermediate entities from the stub-resolver to the ADNS are EDNS0-capable, TCP fallback stays the only possible solution to get a valid (complete) DNS response back to the stub-resolver *if* the response size exceeds 512 octets. Shouldn't your warning above at least equally stress the importance of EDNS0 being deployed throughout the DNS resolution chain (including middle-systems like NATs/firewall et al.)? Hence, does this re-wording proposal make sense? "You MUST support EDNS0 on all your DNS components. - If/when you have done it, then you MAY (SHOULD?) stop supporting TCP for non XFR activity (still MUST for XFR), - If you don't support it (for whatever reason), then you SHOULD (MUST?) support TCP as a fallback facility for resolution activity (still MUST for XFR)." So why am I bringing this? 1) I'm simply afraid that some ISPs or other vendors who will read you and who will not support EDNS0 (for whatever reason), will also (continue to) block TCP fallback, thus denying DNS service to their customers should the response size exceed 512 octets. 2) It is directly related to the discussion which took place on dnsext ml while editing dns-protocol-profile: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00037.html (see section 4.2.2). The I-D expired on Jul 22nd, a copy is available here: http://ietfreport.isoc.org/idref/draft-ietf-dnsext-dns-protocol-profile/ This I-D should be recycled in the near future as I understood from last dnsext session @ IETF. And then, the result of the current debate may be helpful for people in charge of editing next version dns-protocol-profile... Mohsen. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 11:30:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6FF3A693D; Wed, 20 Aug 2008 11:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] 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 Gvr6LD2MahXo; Wed, 20 Aug 2008 11:30:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70AAE3A684B; Wed, 20 Aug 2008 11:30:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVsM8-000Oag-6t for namedroppers-data@psg.com; Wed, 20 Aug 2008 18:24:28 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVsM3-000Oa3-Jg for namedroppers@ops.ietf.org; Wed, 20 Aug 2008 18:24:25 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A02EFA66B4; Wed, 20 Aug 2008 18:24:15 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Wed, 20 Aug 2008 18:54:20 +0200." <82bpzn1vb7.fsf@mid.bfk.de> References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> <82bpzn3etu.fsf@mid.bfk.de> <81795.1219246023@nsa.vix.com> <82bpzn1vb7.fsf@mid.bfk.de> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Wed, 20 Aug 2008 18:24:15 +0000 Message-ID: <18912.1219256655@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A02EFA66B4.58705 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > i propose that an empty answer be sent > > What can stand as an empty answer? REFUSED? ANCOUNT=0 > As a general rule, I think we shouldn't generate new cases where we > don't echo back the question section. the question section MUST be present or the answer won't be recognized. > > 6.1.3.2 Transport Protocols > > > > DNS resolvers and recursive servers MUST support UDP, and > > SHOULD support TCP, for sending (non-zone-transfer) queries. > > > > so, TCP/53 is already optional, which explains why so many people treat > > it as optional. > > According to the quoted sentence, is optional on the initiator, not on > the responder. However, operators treat it as if it were optional on > the responder. it says "and servers" and means it. there's a restatement later on: DNS servers MUST be able to service UDP queries and SHOULD be able to service TCP queries. i think the authors showed in this sentence that they knew the difference between SHOULD and MUST, and chose with their eyes wide open. not that we have to grant these authors omniscience, but these are the unambiguous words that have guided the installed base. > > word on the street is, if you're not answering AXFR and you never > > set the TC bit in UDP/53, you don't have to implement TCP/53. > > Yes, but I think this is wrong. Read on: > > A name server [...] SHOULD NOT refuse to service a TCP query just > because it would have succeeded with UDP. > > Generally filtering TCP queries is against that recommendation. while it strongly implies that one's intention to never truncate is not grounds in and of itself to not implement TCP, it still says SHOULD not MUST, leaving it up to the implementors or operators of responders (or their firewalls) to leave out TCP and still be completely compliant with RFC 1123. > > is SCTP something we should consider as a way out > > No, it's not. can you say more? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 13:15:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B703A6859; Wed, 20 Aug 2008 13:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.214 X-Spam-Level: X-Spam-Status: No, score=0.214 tagged_above=-999 required=5 tests=[AWL=0.709, 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 JzFZKUroZ2KU; Wed, 20 Aug 2008 13:15:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C0593A682B; Wed, 20 Aug 2008 13:15:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVtwM-0009xd-TG for namedroppers-data@psg.com; Wed, 20 Aug 2008 20:05:58 +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 ) id 1KVtwI-0009x3-ML for namedroppers@ops.ietf.org; Wed, 20 Aug 2008 20:05:57 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7KK5V9Q074537; Wed, 20 Aug 2008 16:05:31 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808202005.m7KK5V9Q074537@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Aug 2008 16:05:11 -0400 To: Paul Vixie , Florian Weimer From: Olafur Gudmundsson Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR Cc: namedroppers@ops.ietf.org In-Reply-To: <18912.1219256655@nsa.vix.com> References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> <82bpzn3etu.fsf@mid.bfk.de> <81795.1219246023@nsa.vix.com> <82bpzn1vb7.fsf@mid.bfk.de> <18912.1219256655@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:24 20/08/2008, Paul Vixie wrote: > > > i propose that an empty answer be sent > > > > What can stand as an empty answer? REFUSED? > >ANCOUNT=0 RCODE=REFUSED seems to me to be a cleaner solution and as nameserver are allowed to send that back any time it likes, this is not even a hit of protocol change. Someone can just write a short document "QTYPE=ANY considered harmful, just REFUSE them" :-) to document the practice and point the people at that complain. Root referral is UGLY and misleading. > > > is SCTP something we should consider as a way out > > > > No, it's not. > >can you say more? After looking at using SCTP for DNS, I kind of agree with Florian but it would be nice if someone that understands the details of the different transport protocols would tell us why. Olafur -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 14:58:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F6F3A67EA; Wed, 20 Aug 2008 14:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.151 X-Spam-Level: X-Spam-Status: No, score=-4.151 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 qcrzZUNkn85x; Wed, 20 Aug 2008 14:58:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB20D3A67FD; Wed, 20 Aug 2008 14:58:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVvba-000MnD-Kf for namedroppers-data@psg.com; Wed, 20 Aug 2008 21:52:38 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVvbW-000MmK-3V for namedroppers@ops.ietf.org; Wed, 20 Aug 2008 21:52:36 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=P9QiZLAft1ZpsEsLAVoRshdJxPknOJyZ2jvwBR2ZdBEXAE1Yj5QbMdk9 MXymojaxAMxPruxZnbLzu06PnaFBkFY6COiEHC+zv3aW22cF6JAoRAwav sOqkns+1nX7krHh; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1219269154; x=1250805154; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20depre cating=20dangerous=20bit=20patterns=20and=20non-TC=20non- AXFR|Date:=20Wed,=2020=20Aug=202008=2022:52:29=20+0100 |Message-ID:=20|To:=20Mohsen=20Souissi =20|Cc:=20namedroppers@ops.ietf.or g,=0D=0A=09Paul=20Vixie=20|MIME-Version: =201.0|In-Reply-To:=20<20080820172800.GF95996@kerkenna.ni c.fr>; bh=/Yt3hUczSThRlTtN1aei/4Re28rKxRSWzj4RGVU6rf8=; b=db9N7YchxBmhAid5rGqgrjsUJbv8OVjkwhN5RU63bo1N0Nw1tPgSyRoo vS9nZ2IfMXydGS86YCAOxdCDnzlJO/25Bh+lmI+872WwZ2PQm67wLG2RC c8/OqMDdnDs/CMY; X-IronPort-AV: E=Sophos;i="4.32,241,1217804400"; d="scan'208";a="4943615" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 20 Aug 2008 22:52:31 +0100 In-Reply-To: <20080820172800.GF95996@kerkenna.nic.fr> To: Mohsen Souissi Cc: namedroppers@ops.ietf.org, Paul Vixie Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 20 Aug 2008 22:52:29 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 20/08/2008 10:52:31 PM, Serialize complete at 20/08/2008 10:52:31 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Shouldn't your warning above at least equally stress the importance of > EDNS0 being deployed throughout the DNS resolution chain (including > middle-systems like NATs/firewall et al.)? Many SOHO NATs are somewhat broken with respect to EDNS0, at least whenever their built-in ALGs are used (as is normally the case according to default DHCP settings). I'm going to be offline for the next week, but very shortly thereafter the report on DNSSEC compatibility in SOHO CPE that I and another researcher have been working on will be published with all the gory details. I'll also be presenting this at the OARC Workshop on September 24th. Another consideration is that both Bind and Unbound cap their UDP TX packet size to 4096 bytes, regardless of how high the client's OPT RR receive packet size is. That, at least, is easily fixed. Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 16:50:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93B53A67EF; Wed, 20 Aug 2008 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] 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 y6Zzsajc07DK; Wed, 20 Aug 2008 16:50:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4FB43A6AA4; Wed, 20 Aug 2008 16:50:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVxM5-0008m7-TD for namedroppers-data@psg.com; Wed, 20 Aug 2008 23:44:45 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVxLz-0008kw-MM for namedroppers@ops.ietf.org; Wed, 20 Aug 2008 23:44:43 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7KNiJWS029001; Thu, 21 Aug 2008 09:44:19 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808202344.m7KNiJWS029001@drugs.dv.isc.org> To: Paul Vixie Cc: Florian Weimer , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR In-reply-to: Your message of "Wed, 20 Aug 2008 18:24:15 GMT." <18912.1219256655@nsa.vix.com> Date: Thu, 21 Aug 2008 09:44:19 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > > i propose that an empty answer be sent > > > > What can stand as an empty answer? REFUSED? > > ANCOUNT=0 > > > As a general rule, I think we shouldn't generate new cases where we > > don't echo back the question section. > > the question section MUST be present or the answer won't be recognized. > > > > 6.1.3.2 Transport Protocols > > > > > > DNS resolvers and recursive servers MUST support UDP, and > > > SHOULD support TCP, for sending (non-zone-transfer) queries. > > > > > > so, TCP/53 is already optional, which explains why so many people treat > > > it as optional. > > > > According to the quoted sentence, is optional on the initiator, not on > > the responder. However, operators treat it as if it were optional on > > the responder. > > it says "and servers" and means it. there's a restatement later on: > > DNS servers MUST be able to service UDP queries and SHOULD > be able to service TCP queries. > > i think the authors showed in this sentence that they knew the difference > between SHOULD and MUST, and chose with their eyes wide open. not that we > have to grant these authors omniscience, but these are the unambiguous words > that have guided the installed base. > > > > word on the street is, if you're not answering AXFR and you never > > > set the TC bit in UDP/53, you don't have to implement TCP/53. > > > > Yes, but I think this is wrong. Read on: > > > > A name server [...] SHOULD NOT refuse to service a TCP query just > > because it would have succeeded with UDP. > > > > Generally filtering TCP queries is against that recommendation. > > while it strongly implies that one's intention to never truncate is not > grounds in and of itself to not implement TCP, it still says SHOULD not > MUST, leaving it up to the implementors or operators of responders (or > their firewalls) to leave out TCP and still be completely compliant with > RFC 1123. I seriously doubt that most firewall admins that turn off DNS/TCP have put the requisite thought into the process to meet the requirements levels to break a SHOULD. The number of times that it is justified by "TCP is only used for AXFR" make it clear that the care and thought that should have been applied wasn't. > > > is SCTP something we should consider as a way out > > > > No, it's not. > > can you say more? > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 17:27:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214E93A6993; Wed, 20 Aug 2008 17:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] 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 uB44x+5LwVwT; Wed, 20 Aug 2008 17:27:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 87CC83A6927; Wed, 20 Aug 2008 17:27:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVxum-000Dmw-TN for namedroppers-data@psg.com; Thu, 21 Aug 2008 00:20:36 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVxuh-000Dl5-RZ for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 00:20:34 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7L0K3im029621; Thu, 21 Aug 2008 10:20:04 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808210020.m7L0K3im029621@drugs.dv.isc.org> To: Olafur Gudmundsson Cc: Paul Vixie , Florian Weimer , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR In-reply-to: Your message of "Wed, 20 Aug 2008 16:05:11 -0400." <200808202005.m7KK5V9Q074537@stora.ogud.com> Date: Thu, 21 Aug 2008 10:20:03 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > > > At 14:24 20/08/2008, Paul Vixie wrote: > > > > i propose that an empty answer be sent > > > > > > What can stand as an empty answer? REFUSED? > > > >ANCOUNT=0 > > RCODE=REFUSED seems to me to be a cleaner solution and as nameserver > are allowed to send that back any time it likes, this is not even a > hit of protocol change. > Someone can just write a short document > "QTYPE=ANY considered harmful, just REFUSE them" :-) > to document the practice and point the people at that complain. We have load balancers that send REFUSED rather than NOERROR for AAAA queries today. These cause operational problems. > Root referral is UGLY and misleading. > > > > is SCTP something we should consider as a way out > > > > > > No, it's not. > > > >can you say more? > > After looking at using SCTP for DNS, > I kind of agree with Florian but it would be nice if someone that understands > the details of the different transport protocols would tell us why. > > Olafur > > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 20:44:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649253A6889; Wed, 20 Aug 2008 20:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 nm5rPbhVJj8p; Wed, 20 Aug 2008 20:44:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 746863A6832; Wed, 20 Aug 2008 20:44:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW0ui-00089M-Rt for namedroppers-data@psg.com; Thu, 21 Aug 2008 03:32:44 +0000 Received: from [129.9.168.35] (helo=shbmap01.extra.chrysler.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW0uf-000892-7o for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 03:32:43 +0000 X-AuditID: 8109a822-aa881bb000000b82-74-48ace1d68828 Received: from shnavip4-hme0.shdc.chrysler.com (unknown [53.231.141.98]) by shbmap01.extra.chrysler.com (Symantec Mail Security) with SMTP id 5CE214E4002 for ; Wed, 20 Aug 2008 23:32:38 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.98.85]) by shnavip4-hme0.shdc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2008082023323813148 for ; Wed, 20 Aug 2008 23:32:38 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.13.6/8.9.1) with ESMTP id m7L3WcjU024457 for ; Wed, 20 Aug 2008 23:32:38 -0400 (EDT) Message-ID: <48ACE1D6.20708@chrysler.com> Date: Wed, 20 Aug 2008 23:32:38 -0400 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Zone Immortality Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: RFC 1034 states: Each secondary server is required to perform the following operations against the master, but may also optionally perform these operations against other secondary servers. This strategy can improve the transfer process when the primary is unavailable due to host downtime or network problems, or when a secondary server has better network access to an "intermediate" secondary than to the primary. Now, disregarding the obsolete "secondary" language (we now call them "slaves"), and the obviously-incorrect word "following" (which can't possibly be right, since this is the last paragraph of the section -- there is nothing relevant "following"), one notes the blatant ambiguity of "these operations". Which operations? Minimally, checking the serial number and performing a zone transfer if it has increased? I think that much is fairly obvious. What's a little *less* obvious, and the point of my missive, is whether, when and/or how "these operations" might include the following, from a previous paragraph: " If the secondary finds it impossible to perform a serial check for the EXPIRE interval, it must assume that its copy of the zone is obsolete an[sic] discard it." The problem with slaves resetting their EXPIRE timers every time they perform a successful refresh from another slave is that the slaves may be in a reciprocal or circular -- A refreshes from B, B refreshes from C, C refreshes from A -- relationship, so the zone may become "immortal", i.e. even when it is deleted from the primary master, the slaves continue to keep the zone alive indefinitely by constantly refreshing each other. Surely it cannot have been the intent for zones to become "immortal". That would defeat the whole purpose of having EXPIRE in the first place. Yet, having slaves in a reciprocal or circular relationship is a perfectly _valid_ arrangement. It ensures that, if the primary master goes down for an extended period of time (i.e. multiple REFRESH cycles), all slaves in the set eventually converge on the latest-available version of the zone. I would suggest, therefore, that if this language in 1034 cannot or will not be clarified/updated in the foreseeable future, so as to outlaw this "optional" replication topology, that implementors review their refresh/expire logic, and if it doesn't already exist in their implementation, provide a way for administrators to differentiate true "master" replication sources, which reset the EXPIRE timer on each successful refresh, from "peer" sources, which do not. This would allow large enterprises --such as ours -- to build highly robust and available DNS infrastructures without having to struggle with zone-immortality risks/issues. - Kevin -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 21:35:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBC23A6A78; Wed, 20 Aug 2008 21:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] 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 emGQQ4vgdrby; Wed, 20 Aug 2008 21:35:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3652E3A689B; Wed, 20 Aug 2008 21:35:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW1mV-000DPU-RP for namedroppers-data@psg.com; Thu, 21 Aug 2008 04:28:19 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW1mR-000DOu-G1 for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 04:28:17 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7L4S9uL032499; Thu, 21 Aug 2008 14:28:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808210428.m7L4S9uL032499@drugs.dv.isc.org> To: Kevin Darcy Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Zone Immortality In-reply-to: Your message of "Wed, 20 Aug 2008 23:32:38 -0400." <48ACE1D6.20708@chrysler.com> Date: Thu, 21 Aug 2008 14:28:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > RFC 1034 states: > > Each secondary server is required to perform the following operations > against the master, but may also optionally perform these operations > against other secondary servers. This strategy can improve the transfer > process when the primary is unavailable due to host downtime or network > problems, or when a secondary server has better network access to an > "intermediate" secondary than to the primary. > > > > Now, disregarding the obsolete "secondary" language (we now call them > "slaves"), and the obviously-incorrect word "following" (which can't > possibly be right, since this is the last paragraph of the section -- > there is nothing relevant "following"), one notes the blatant ambiguity > of "these operations". Which operations? Minimally, checking the serial > number and performing a zone transfer if it has increased? I think that > much is fairly obvious. > > What's a little *less* obvious, and the point of my missive, is whether, > when and/or how "these operations" might include the following, from a > previous paragraph: " > > If the secondary finds it impossible to perform a serial check for the EXPIRE > interval, it must > assume that its copy of the zone is obsolete an[sic] discard it." > > The problem with slaves resetting their EXPIRE timers every time they > perform a successful refresh from another slave is that the slaves may > be in a reciprocal or circular -- A refreshes from B, B refreshes from > C, C refreshes from A -- relationship, so the zone may become > "immortal", i.e. even when it is deleted from the primary master, the > slaves continue to keep the zone alive indefinitely by constantly > refreshing each other. > > Surely it cannot have been the intent for zones to become "immortal". > That would defeat the whole purpose of having EXPIRE in the first place. > > Yet, having slaves in a reciprocal or circular relationship is a > perfectly _valid_ arrangement. It ensures that, if the primary master > goes down for an extended period of time (i.e. multiple REFRESH cycles), > all slaves in the set eventually converge on the latest-available > version of the zone. > > I would suggest, therefore, that if this language in 1034 cannot or will > not be clarified/updated in the foreseeable future, so as to outlaw this > "optional" replication topology, that implementors review their > refresh/expire logic, and if it doesn't already exist in their > implementation, provide a way for administrators to differentiate true > "master" replication sources, which reset the EXPIRE timer on each > successful refresh, from "peer" sources, which do not. This would allow > large enterprises --such as ours -- to build highly robust and available > DNS infrastructures without having to struggle with zone-immortality > risks/issues. > > > - Kevin There are lots of existing ways to address this. * Outlaw loops. * Don't reset the expire counter on refresh from peers only on transfer from peers. * Use DNSSEC to make data go stale. Extend AXFR/IXFR/SOA to add a expiry counter. The master would always set this to SOA EXPIRE. The slave would report it's current value for that counter. This fits well into EDNS as it is a hop-by-hop value. It would also address the N * expiry problem that currently exists when you have a deep transfer graph. e.g. <4> The slave would add a <0> option to its SOA refresh queries and to IXFR and AXFR queries. The slave would use the maximum of the returned value and it's expire counter on SOA serial matches to refresh queries or IXFR up to date responses to set its expire counter. The slave would use this value rather than the SOA expire field to initialise it's expire counter on IXFR/AXFR which change the zone content. The slave will perform a sanity check to ensure that the returned value is no greater than the SOA expire field. If it is greater then it will use the SOA expire field instead. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 22:11:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FD23A6A0C; Wed, 20 Aug 2008 22:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.638 X-Spam-Level: X-Spam-Status: No, score=-4.638 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, 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 lYZi5he2s06J; Wed, 20 Aug 2008 22:11:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 537F23A68B9; Wed, 20 Aug 2008 22:11:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW2HX-000H5w-Tp for namedroppers-data@psg.com; Thu, 21 Aug 2008 05:00:23 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW2HU-000H4w-8I for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 05:00:22 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KW2HT-0002Av-J7; Thu, 21 Aug 2008 01:00:19 -0400 Message-ID: <48ACF663.5090601@ca.afilias.info> Date: Thu, 21 Aug 2008 01:00:19 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Kevin Darcy CC: namedroppers@ops.ietf.org Subject: Re: Zone Immortality References: <48ACE1D6.20708@chrysler.com> In-Reply-To: <48ACE1D6.20708@chrysler.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Kevin Darcy wrote: > RFC 1034 states: > > Each secondary server is required to perform the following operations > against the master, but may also optionally perform these operations > against other secondary servers. This strategy can improve the > transfer > process when the primary is unavailable due to host downtime or > network > problems, or when a secondary server has better network access to an > "intermediate" secondary than to the primary. > > > Now, disregarding the obsolete "secondary" language (we now call them > "slaves"), and the obviously-incorrect word "following" (which can't > possibly be right, since this is the last paragraph of the section -- > there is nothing relevant "following"), one notes the blatant > ambiguity of "these operations". Which operations? Minimally, checking > the serial number and performing a zone transfer if it has increased? > I think that much is fairly obvious. > > What's a little *less* obvious, and the point of my missive, is > whether, when and/or how "these operations" might include the > following, from a previous paragraph: " > > If the secondary finds it impossible to perform a serial check for the > EXPIRE interval, it must assume that its copy of the zone is obsolete > an[sic] discard it." > > The problem with slaves resetting their EXPIRE timers every time they > perform a successful refresh from another slave is that the slaves may > be in a reciprocal or circular -- A refreshes from B, B refreshes from > C, C refreshes from A -- relationship, so the zone may become > "immortal", i.e. even when it is deleted from the primary master, the > slaves continue to keep the zone alive indefinitely by constantly > refreshing each other. > > Surely it cannot have been the intent for zones to become "immortal". > That would defeat the whole purpose of having EXPIRE in the first place. > > Yet, having slaves in a reciprocal or circular relationship is a > perfectly _valid_ arrangement. It ensures that, if the primary master > goes down for an extended period of time (i.e. multiple REFRESH > cycles), all slaves in the set eventually converge on the > latest-available version of the zone. > > I would suggest, therefore, that if this language in 1034 cannot or > will not be clarified/updated in the foreseeable future, so as to > outlaw this "optional" replication topology, that implementors review > their refresh/expire logic, and if it doesn't already exist in their > implementation, provide a way for administrators to differentiate true > "master" replication sources, which reset the EXPIRE timer on each > successful refresh, from "peer" sources, which do not. This would > allow large enterprises --such as ours -- to build highly robust and > available DNS infrastructures without having to struggle with > zone-immortality risks/issues. It raises an interesting question, if more than one slave transfers the zone with the same serial. Should all subsequent transfers from those slaves necessarily get the same result (i.e. related to EXPIRE timer logic), or perhaps whichever of the slaves transfered the zone *last*, would legitimately have a slightly better value (since its own EXPIRE timer started ticking later)? Here's my suggestion: If a zone is transfered *from* a slave, the values for the TTLs should be modified downwards by the local EXPIRE timer. Only transfers from a zone master should have the original TTL values from the SOA used for timers. This would mean that all recipients of a transfer from a slave would have EXPIRE timers that fire at the same time as the slave - effectively synchronizing the expiry for any slave^n-th that doesn't succeed in doing a refresh from some source with a better SOA SN *or* EXPIRE timer. It basically functions analogously to NTP source "stratum", where stratum is monotonically increasing across peerings... -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 20 22:57:46 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A53B3A6846; Wed, 20 Aug 2008 22:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 9tz3BOCq3VsB; Wed, 20 Aug 2008 22:57:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A3DC3A6821; Wed, 20 Aug 2008 22:57:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW36H-000Mvs-EA for namedroppers-data@psg.com; Thu, 21 Aug 2008 05:52:49 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW36C-000Mv9-DZ for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 05:52:47 +0000 Received: (qmail 87332 invoked from network); 21 Aug 2008 05:58:29 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 21 Aug 2008 05:58:29 -0000 Message-ID: <48AD0280.1030309@necom830.hpcl.titech.ac.jp> Date: Thu, 21 Aug 2008 14:52:00 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Kevin Darcy CC: namedroppers@ops.ietf.org Subject: Re: Zone Immortality References: <48ACE1D6.20708@chrysler.com> In-Reply-To: <48ACE1D6.20708@chrysler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Kevin Darcy wrote: > all slaves in the set eventually converge on the latest-available > version of the zone. A hidden assumption of 1034 is that such convergence will occur within a period much shorter than the expiration period. If not, you have an administrative problem a lot more serious than a small variation of expiraiton period. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 05:40:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49673A6993; Thu, 21 Aug 2008 05:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 tw6pJWpLxCjD; Thu, 21 Aug 2008 05:40:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 266BB3A68A3; Thu, 21 Aug 2008 05:40:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KW9JT-000GhU-9k for namedroppers-data@psg.com; Thu, 21 Aug 2008 12:30:51 +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 ) id 1KW9JI-000GeX-5Z for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 12:30: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 m7LCUcwM082326 for ; Thu, 21 Aug 2008 08:30:38 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m7LCUca1082325 for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 08:30:38 -0400 (EDT) (envelope-from namedroppers) Received: from [208.87.234.190] (helo=cluster-h.mailcontrol.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KVB0H-0005vz-5M for namedroppers@ops.ietf.org; Mon, 18 Aug 2008 20:07:03 +0000 Received: from emsv.co.uk ([84.234.24.63]) by rly13h.srv.mailcontrol.com (MailControl) with SMTP id m7IK6QTn015803 for ; Mon, 18 Aug 2008 21:06:27 +0100 From: "George Barwood" To: Message-ID: <01e601c9016d$e4fa6d10$0302a8c0@localhost> Subject: Some observations on dns-0x20 Date: Mon, 18 Aug 2008 21:06:25 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 MIME-Version: 1.0 Organization: Education and Media Services Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E3_01C90176.4679B5C0" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 X-Scanned-By: MailControl A-08-50-13 (www.mailcontrol.com) on 10.72.0.123 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This is a mime multipart message ------=_NextPart_000_01E3_01C90176.4679B5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been experimenting with the technique described ( Google for GbDns i= f interested ), and have a few observations. (1) A simple way of dealing with case sensitivity when parsing a string in = a DNS requests is to preserve case if and only if the section is the Questi= on section. For other sections I believe that simply reducing to lower case will not ca= use any problems, at least in a recursive context, and is the simplest and = best solution. (2) When checking a response, a good model is to estimate the number of bi= ts of entropy (random bits) that have been retained from the original reque= st ( I will refer to this as the Confidence value ). The port number entropy should be discounted if the program may be behind a= NAT device, unless it is known that the device preserves port randomizatio= n. I think this might be mentioned somewhere in the standard. If unusual responses are detected ( for example incorrect IP, Question not = copied, Question case not preserved ), the response need not be entirely ig= nored, rather a suitable discount can be applied in the entropy computation. (3) A possible implementation technique is to maintain a Confidence field f= or each cache entry. When processing a response, the Confidence value computed in (2) can be add= ed in when an exactly matching cache element ( normally with expired TTL ) = is found. A valid cache entry is thus one which has valid TTL and valid Confidence va= lue ( say 50 bits ). The resolver loop can iterate until either a cache entry is found, or an it= eration occurs in which the cache is not updated ( this includes updates to= TTL or Confidence values ). Non-existence and error conditions can also be cached, with confidence valu= es. Lastly, I would like to say that I strongly support dns-0x20, and have comm= unicated a couple of suggested changes privately to Paul, which he has grac= iously agreed to make, viz. (a) In section 7.4, to drop the words "by a factor of "several". (b) In section 5.2 to change "MUST" to "SHOULD". George Barwood =20 ------=_NextPart_000_01E3_01C90176.4679B5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have been experimenting with the techniq= ue=20 described ( Google for GbDns if interested ), and have a few=20 observations.
 
(1) A simple way of dealing with case sens= itivity=20 when parsing a string in a DNS requests is to preserve case if and only if = the=20 section is the Question section.
 
For other sections I believe that simply r= educing=20 to lower case will not cause any problems, at least in a recursive context,= and=20 is the simplest and best solution.
 
(2)  When checking a response, a good= model is=20 to estimate the number of bits of entropy (random bits) that have been reta= ined=20 from the original request ( I will refer to this as the Confidence value=20 ).
 
The port number entropy should be discount= ed if=20 the program may be behind a NAT device, unless it is known that t= he=20 device preserves port randomization. I think this might be mentioned= =20 somewhere in the standard.
 
If unusual responses are detected ( for ex= ample=20 incorrect IP, Question not copied, Question case not preserved ), the respo= nse=20 need not be entirely ignored, rather a suitable discount can be applied in = the=20 entropy computation.
 
(3) A possible implementation te= chnique=20 is to maintain a Confidence field for each cache entry.
When processing a response, the Confidence= value=20 computed in (2) can be added in when an exactly matching cache element (=20 normally with expired TTL ) is found.
 
A valid cache entry is thus one which has = valid TTL=20 and valid Confidence value ( say 50 bits ).
 
The resolver loop can iterate until either= a cache=20 entry is found, or an iteration occurs in which the cache is not updat= ed (=20 this includes updates to TTL or Confidence values ).
 
Non-existence and error conditions can als= o be=20 cached, with confidence values.
 
Lastly, I would like to say that I strongl= y support=20 dns-0x20, and have communicated a couple of suggested changes privatel= y to=20 Paul, which he has graciously agreed to make, viz.
 
(a) In section 7.4, to drop the words "by = a factor=20 of "several".
(b) In section 5.2 to change "MUST" to=20 "SHOULD".
 
George Barwood


  

------=_NextPart_000_01E3_01C90176.4679B5C0-- -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 08:40:08 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA703A69E6; Thu, 21 Aug 2008 08:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 nVhWZ6XXSlFI; Thu, 21 Aug 2008 08:40:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76C983A6964; Thu, 21 Aug 2008 08:40:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWC9m-000EvT-D8 for namedroppers-data@psg.com; Thu, 21 Aug 2008 15:33:02 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWC9h-000EuD-Ep for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 15:32:59 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m7LFWJKx046469; Thu, 21 Aug 2008 17:32:20 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200808211532.m7LFWJKx046469@givry.fdupont.fr> From: Francis Dupont To: Olafur Gudmundsson cc: Paul Vixie , Florian Weimer , namedroppers@ops.ietf.org Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR In-reply-to: Your message of Wed, 20 Aug 2008 16:05:11 EDT. <200808202005.m7KK5V9Q074537@stora.ogud.com> Date: Thu, 21 Aug 2008 17:32:19 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: >can you say more? After looking at using SCTP for DNS, I kind of agree with Florian but it would be nice if someone that understands the details of the different transport protocols would tell us why. => IMHO DCCP is a better candidate but what we need is a transaction oriented transport... As far as I know the last proposal was T/TCP and nothing serious emerged after even there is a "market" for this. A workshop at the next IETF? Regards Francis.Dupont@fdupont.fr PS: for SCTP none of the nice features of SCTP has an interest for the common DNS (i.e., the part which uses UDP when the payload is not over sized, not AXFR where SCTP makes sense). As these features are not always for free SCTP has no definitive advantage over TCP and clearly can't take the place of UDP (for DNS). -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 09:38:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514913A67EE; Thu, 21 Aug 2008 09:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_75=0.6] 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 eEkyGbWOknjV; Thu, 21 Aug 2008 09:38:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D224A3A6780; Thu, 21 Aug 2008 09:38:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWD5I-000N9q-Rs for namedroppers-data@psg.com; Thu, 21 Aug 2008 16:32:28 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWD56-000N81-QS for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 16:32:19 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 71D6BA6683 for ; Thu, 21 Aug 2008 16:32:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: SCTP (and DCCP) In-Reply-To: Your message of "Thu\, 21 Aug 2008 17\:32\:19 +0200." <200808211532.m7LFWJKx046469@givry.fdupont.fr> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Thu, 21 Aug 2008 16:32:06 +0000 Message-ID: <40391.1219336326@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 71D6BA6683.81440 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --=-=-= Francis Dupont : > Olafur Gudmundsson : > > I kind of agree with Florian but it would be nice if someone that > understands the details of the different transport protocols would > tell us why. > > => IMHO DCCP is a better candidate but what we need is a transaction > oriented transport... As far as I know the last proposal was T/TCP > and nothing serious emerged after even there is a "market" for this. here are two articles on dnsop by bill fumerola in response to this thread there. since sctp is slightly older and is used in ip telephony and is implemented on more systems and allows data transfer on the second round trip (packets 3 and 4), i'm more hopeful for it than i am for DCCP. > A workshop at the next IETF? i'd like to make significant progress by e-mail, open workshops, and concalls, rather than gating progress to thrice-yearly IETF meetings. i know i said that in the MODA proceedings, but i've since then been proved right, but now we've seen a 10-hour attack against the only mitigation we've got. we won't have MODA but we can gather interested parties and get significant work done in between IETF meetings now that we're all motivated. > PS: for SCTP none of the nice features of SCTP has an interest for the > common DNS (i.e., the part which uses UDP when the payload is not over > sized, not AXFR where SCTP makes sense). As these features are not > always for free SCTP has no definitive advantage over TCP and clearly > can't take the place of UDP (for DNS). i see five reasons why SCTP is worth looking at as a primary transport with UDP as its fallback. first, data transfer can take place in the second round trip (packets 3 and 4). second, it has 32-bit ID fields so we could go back to fixed port numbers perhaps even fixed+increment on TXID's. third, we could mandate EDNS, and with it, we could mandate PING. fourth, SCTP has the idea of "passive" sockets which mean nonquadratic socket pool sizes. fifth, association timeout is handled in the stack not the app. i see two gigantic challenges for ANY non-UDP transport: installed base of DNS protocol agents; installed base of firewalls and NATs and middleboxes. here's bill fumerola's text from dnsop. two messages attached: -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=358 Return-Path: X-Original-To: vixie@vix.com Delivered-To: vixie@nsa.vix.com Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.isc.org", Issuer "ISC CA" (not verified)) by nsa.vix.com (Postfix) with ESMTPS id 12565A66AF for ; Wed, 20 Aug 2008 19:20:40 +0000 (UTC) (envelope-from billf@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx.isc.org (Postfix) with ESMTP id 283E711401C for ; Wed, 20 Aug 2008 19:20:27 +0000 (UTC) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id AD50E1A4D80; Wed, 20 Aug 2008 12:20:21 -0700 (PDT) Date: Wed, 20 Aug 2008 12:20:21 -0700 From: bill fumerola To: Paul Vixie Cc: dnsop@ietf.org Subject: tcpm's SADATA Message-ID: <20080820192021.GY29172@elvis.mu.org> References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72546.1219243301@nsa.vix.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 6.3-MUORG-20080227 amd64 X-PGP-DEAD-Key: 1024D/7F868268 X-PGP-DEAD-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-PGP-Key: 1024D/AE9EB579 X-PGP-Fingerprint: 2E51 E3DE 2C52 C84D 750F 8ADE 1F18 67FB AE9E B579 OpenPGP: id=AE9EB579 X-Spam-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4, No X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mx.isc.org X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 12565A66AF.BD1B1 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: billf@elvis.mu.org On Wed, Aug 20, 2008 at 02:41:41PM +0000, Paul Vixie wrote: > with rich stevens gone and nobody to complete or champion T/TCP, we're left > with several bad multipacket protocols including IP fragmentation and TCP for > handling data larger than the MTU. i don't know how to make TCP scale for > this, it's not like TCP/80 where server operators who want to handle a million > simultaneous queries know that they'll need a lot of silicon+power to do it. http://tools.ietf.org/html/draft-agl-tcpm-sadata-01 https://datatracker.ietf.org/drafts/draft-agl-tcpm-sadata/ i'm not advocating for or against this I-D or willing to predict its success, but in the tcpm WG there are discussions about an extension for including a small amount of data in the SYN+ACK payload. there is no payload in the SYN packet, which makes it differ from T/TCP significantly in both opportunities for optimizations and also possibilities for abuse. this could be used to setup elliptic curve cryptography in a DNS exchange quicker than the standard 3-way handshake would allow. it could be used to send a previously established, cached cookie between servers such that only the first connection in a given window incurs the time required by a full handshake (where the 4th packet [<- ACK+data] contains the cookie & and response from the request in the 3rd packet [-> ACK+data]). i haven't given much thought to this, so this is not a formal proposal to go down this road nor have i completely thought out how this could be used to DNS's advantage. it's just food for thought since you brought up T/TCP. it'd be better if the requester would be the one to include a payload earlier, but T/TCP proved the problems within. -- bill [ not speaking for my employer, all just random thoughts ] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=359 Return-Path: X-Original-To: vixie@vix.com Delivered-To: vixie@nsa.vix.com Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.isc.org", Issuer "ISC CA" (not verified)) by nsa.vix.com (Postfix) with ESMTPS id D5755A6683 for ; Wed, 20 Aug 2008 19:21:44 +0000 (UTC) (envelope-from billf@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx.isc.org (Postfix) with ESMTP id 56D5D11401C for ; Wed, 20 Aug 2008 19:21:32 +0000 (UTC) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 59D311A4D80; Wed, 20 Aug 2008 12:21:32 -0700 (PDT) Date: Wed, 20 Aug 2008 12:21:32 -0700 From: bill fumerola To: Paul Vixie Cc: dnsop@ietf.org Subject: DNS over SCTP Message-ID: <20080820192132.GZ29172@elvis.mu.org> References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72546.1219243301@nsa.vix.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 6.3-MUORG-20080227 amd64 X-PGP-DEAD-Key: 1024D/7F868268 X-PGP-DEAD-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 X-PGP-Key: 1024D/AE9EB579 X-PGP-Fingerprint: 2E51 E3DE 2C52 C84D 750F 8ADE 1F18 67FB AE9E B579 OpenPGP: id=AE9EB579 X-Spam-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4, No X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mx.isc.org X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: D5755A6683.22102 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: billf@elvis.mu.org On Wed, Aug 20, 2008 at 02:41:41PM +0000, Paul Vixie wrote: > did RDP (RFC 908, RFC 1151) ever achieve critical mass? using another transport layer altogether is also a possibility, as you hint, i don't believe RDP ever had much traction. however, SCTP could be used to setup a multiplexed connection such that control messages (broadly defined for now) are sent down through one stream and other streams could be used for queries/responses. the advantages of UDP's unordered delivery and message boundaries still can be realized while gaining the advantage's of TCP's reliability, path MTU, and congestion control. additionally, SCTP has multi-homing support (almost SHIM6-like if i understand both correctly) which could address the "tcp anycast is broken" argument by allowing for PA space in addition to PI space to be used to provide reliability in the face of multihomed servers. finally, SCTP already contains methods for authenticating chunks on selected streams using information derived during the setup which can be based on pre-shared keys - possibly by publishing them in the DNS tree itself (TKEY or similar). i don't claim to be an expert on DNS, SCTP, or cryptography. however, from what i read, SCTP certainly fits the bill for the requirements i've seen floating around. stub resolvers could remain as-is and SCTP could be used as transport soley between recursive and authoritative. this work would be the long view while EDNS PING, DNSSEC, and other countermeasures to the problems at hand are deployed. disadvantages to SCTP could include: lack of hardware accelleration in network cards for the transport, the virgin territory of SCTP implementations deployed, the existing problems of using a transport with more state than UDP, lack of familiarity amongst operators of SCTP, and a lack of widespread support for SCTP in both host and routing operating systems. -- bill [ not speaking for my employer, all just random thoughts ] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --=-=-=-- -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 10:11:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0AD3A6950; Thu, 21 Aug 2008 10:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.223 X-Spam-Level: X-Spam-Status: No, score=-4.223 tagged_above=-999 required=5 tests=[AWL=-2.376, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, 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 lb42YHptFaZc; Thu, 21 Aug 2008 10:11:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9D423A68A6; Thu, 21 Aug 2008 10:11:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWDVn-0000mi-Az for namedroppers-data@psg.com; Thu, 21 Aug 2008 16:59:51 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWDVi-0000le-HR for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 16:59:48 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7LGxTnZ014590; Thu, 21 Aug 2008 09:59:30 -0700 (PDT) From: Nicholas Weaver To: George Barwood In-Reply-To: <01e601c9016d$e4fa6d10$0302a8c0@localhost> Subject: Some Observations on Entropy Re: Some observations on dns-0x20 X-Priority: 3 References: <01e601c9016d$e4fa6d10$0302a8c0@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 21 Aug 2008 09:59:28 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: (note, these are taken from some thought I've been writing down in our group blog, http://blog.icir.org/2008/08/entropy-blind-attacks-and-dns.html , comments greatly appreciated). On Aug 18, 2008, at 1:06 PM, George Barwood wrote: > (2) When checking a response, a good model is to estimate the > number of bits of entropy (random bits) that have been retained from > the original request ( I will refer to this as the Confidence value ). > > The port number entropy should be discounted if the program may be > behind a NAT device, unless it is known that the device preserves > port randomization. I think this might be mentioned somewhere in the > standard. The question is, how to KNOW this. We have a test server for a bunch of tests, at a temporary location as part of a larger project. One of the tests, port.{anything}.nettest.icir.org will return the port number in the lower 16 bits of the IP address. My belief is that there should be an official server with this property. Thus resolvers can query the server a few times on startup to know if the port number is preserved. [1] Yes, its a software "phone home", but given how much evil stuff you can hide in code, you have to trust the code for your DNS resolver anyway, so whats so bad about having to trust its phone-home to check for network properties? > (3) A possible implementation technique is to maintain a Confidence > field for each cache entry. > When processing a response, the Confidence value computed in (2) can > be added in when an exactly matching cache element ( normally with > expired TTL ) is found. Here is my thought on entropy based defenses against blind attacks. Pardon if all of this has been hashed out already, but even in that case its probably worth remembering: There are two classes (when viewed from one perspective) of DNS attacks: transactional attacks (where the attacker "wins" if the transaction is corrupted) or cache attacks (where the attacker "wins" if the cache is corrupted.) There are very few blind attack scenarios which are transactional [2], but they do exist, and defenses can vary on how much they protect transactions vs the cache. I don't like the idea of individual confidence, however. I prefer a simpler model of a global entropy budget and a global paranoia level, its far simpler and easier to manage. And for such an entropy budget, 40b is probably sufficient to protect the cache. Here's why. The probability of success, for attacking a resolver with K bits of entropy in the request with N tries is: P = 1 - (1-2^-k)^N (Namely, the probability of ALL failing is (1-2^k)^N, which means the probability of at least one success P = 1- (1-2^k)^N) To put in some concrete numbers: assume an attempt is 100B of data, and the attacker is happy with a roughly 1.5% chance of success. With k = 16 and N = 1000, P = .015 and it took 10 KB of data. Owch. With k = 32 and N = 7e7, P = .016 and it took 7 GB of data. Not bad. With k = 40 and N = 2e10, P = .018 and it took 2 TB of data. HA! And remember, this is a "bear race": The resolver doesn't have to be 100% bulletproof, it just has to be strong enough that it is not economically viable to attack. A botnet which can spew 2 TB of spoofed data is a pretty valuable resource, who wants to waste it for a <2% chance of success? Failed attempts, however, are easily detectible, as many have pointed out: Any response which mismatches on the entropy (EG, to a different port, with a different transaction ID, which doesn't just all-lower or all-upper an 0x20 response, but uses a different captialization) is an unsolicited response, caused by either a buggy server (they exist but are reasonably rare) or an attack. More importantly, it appears plausible to use this property to set a "Maximum P of the cache having a corrupt entry" in practice, and RESPOND to it. Choose a good P, say .0001 (or, put it this way, a .01% chance that there exists one or more bad cache entries), plus your minimum entropy budget for transaction, and maintain a single global count of unsolicited responses. Now if the number of unsolicited responses is enough that P is over your threshold of paranoia, just flush the ENTIRE cache, accept the latency hit and extra traffic until you repopulate, and be happy. For low K (eg 16b), you fail. Don't bother. If k is 16b, you are dead anyway. And for a moderate k, this isn't that good. EG, with P being approx . 0001 (moderately paranoid), With k = 32, N would be roughly 5e5, or 50 MB of data. If your cache has 1M entries, this would require refetching, say, 500 MB of data. So this, when used as a DOS, would be a roughly 10x amplification, not great, but not horrible. How paranoid are you? But with a high k, say 40 bits, it IS good. Lets set P to be approx . 00001 (or a .001% chance of a single bad cache entry, high paranoia). With k = 40, N would be roughly 1e7, or 1 GB of data. So if this is a "DOS", it isn't: there's negative amplification. If an attacker needs to send 1 GB of data at my resolver, to cause it to flush its cache and refetch 500 MB of data, or to have a .001% chance of inserting a bad cache entry, he's welcome to it! Bots are valuable, and the ROI for such an attack can only be described as pathetic. But at the same time, this says "Don't bother trying to get the entropy above 40 bits". 40 bits can leave you such a comfortable margin that you don't need to get above it, even if you are paranoid about flushing the cache when you think you might have been attacked. And 40 bits is easily achiveable without duplication for most queries when not NATed. Random TXID: 16b Random port: 13b Random selection of resolver: 2b Random caps (www.foo.com): 9b ----------------------------------- 40b And you can know when you are generating the query if you meet your entropy budget or not (assuming fallback of rerequest on 0x20 failure as "all lower" or "all upper", and checking for NAT), so you can just look at your entropy budget and decide if you need to do something more. And "something more" being duplication has an interesting property, depending on your behavior, that needs to be remembered. If your policy is "send two queries (same query, different entropy values), return first, cache only on agreement": Ups cache entry by nearly double: the attacker must match both from the same query to succeed in poisoning the cache. So if your initial entropy is K bits, it should make it 2K-1 bits of entropy. Cool beans. For protecting the cache, NATs don't matter if you know you are behind one. REDUCES transactional entropy by 1 bit: the attacker gains a minor birthday advantage, so if your initial entropy is K bits, it makes transactional entropy K-1 bits. Uhhh, how serious do you consider transaction attacks vs cache attacks? It gets down into the question on the footnote 2. But there are some anomalous servers, which for the same repeated query will return different values. With this policy an anomalous server which returns different values for the same query will not be cached yet will be resolved by the client. Cool beans: You punish them with more load, but their results still work. If your policy is "send two queries, return and cache only on agreement": You still get the great increase in cache entropy, you increase transactional entropy (yay), but the anomalous servers don't work anymore at all (boo?). So with duplication to increase entropy, although it works great to protect the cache, you have to decide how you want to protect transactions: Do you want to decrease the transactional entropy slightly, or do you want to not resolve these anomalous servers? (Acknowledgements: This discussion was shaped by a lot of discussions with many individuals, including David Dagon, Robin Sommer, Wouter Wijngaards, Mattias Valintin, Dan Kaminski, and I'm sure I'm forgetting a few others). [1] Although many people consider nat "Malicious", there is no reason for a nat or firewall to special case such a query, so the value can be trusted. Because if a NAT or firewall DID special case such a query, it should be considered an agressive Man-in-the-Middle attacker anyway, and nothing short of DNSSEC works for that. [2] The only scenario I can determine where a blind TRANSACTIONAL attack is useful (vs a blind cache attack) is cookie/authentication credential stealing from a site with insecure cookie handling. Eg, login.yahoo.com holds Yahoo's global session cookie, which is needed to log into yahoo mail. 1) Notify the attacker (by doing a DNS lookup by opening an iframe on a sub-domain of the attacker's control) 2) Open an iFrame to login.yahoo.com, while the attacker simultaneously launches a traditional blind poisoning attack for login.yahoo.akadns.net. 3) Observe that cookie policy is "specific": cookies for login.yahoo.com are returned for 1.login.yahoo.com, 2.login.yahoo.com, etc, so you can open up a gazillion iframes, each for different variants, getting the "run N races and win one" property but for a transactional attack. However, notice that for a blind transactional attack to work against an HTTP site, the site is also trivially vulnerable to Mike Perry's attack using TCP packet injection, so how much protection is really necessary to build into the DNS transaction (vs the cache) for software thats already b0rken? -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 10:15:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C733A69E7; Thu, 21 Aug 2008 10:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, 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 kQ+-7K9yupve; Thu, 21 Aug 2008 10:15:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 026003A68A6; Thu, 21 Aug 2008 10:15:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWDcR-0001gE-2B for namedroppers-data@psg.com; Thu, 21 Aug 2008 17:06:43 +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 ) id 1KWDbP-0001Wr-MU for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 17:05:45 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KWDbI-0007wM-L1 for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 19:05:32 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 0091B4B44C; Thu, 21 Aug 2008 19:05:45 +0200 (CEST) Date: Thu, 21 Aug 2008 19:05:45 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: SCTP (and DCCP) Message-ID: <20080821170545.GB14116@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40391.1219336326@nsa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 21, 2008 at 04:32:06PM +0000, Paul Vixie wrote: > know i said that in the MODA proceedings, but i've since then been proved > right, but now we've seen a 10-hour attack against the only mitigation > we've got. It is not the only mitigation. Even very simple countermeasures foil the '10 hour attack' and turn it into a '100 year attack' (on average), or perhaps even a '500 year attack'. It turns out that detecting a spoofing attempt in progress is easy, and that simple agile behaviour makes attacks infeasible or at least very uninteresting. It is not cool and revolutionary though.. But the upside is that it does not require deprecating DNS over TCP, nor does it require moving DNS to SCTP or DCCP other exciting new protocols. 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 10:22:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD58B3A6A94; Thu, 21 Aug 2008 10:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 ejpVAaFWqFN9; Thu, 21 Aug 2008 10:22:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6462C3A69D1; Thu, 21 Aug 2008 10:22:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWDlt-000310-7d for namedroppers-data@psg.com; Thu, 21 Aug 2008 17:16:29 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWDlo-00030L-UV for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 17:16:27 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id DDD031C0134; Thu, 21 Aug 2008 19:16:21 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D80E41C012F; Thu, 21 Aug 2008 19:16:21 +0200 (CEST) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by relay2.nic.fr (Postfix) with ESMTP id CC8307B0052; Thu, 21 Aug 2008 19:16:21 +0200 (CEST) Received: from kerkenna.nic.fr (localhost [127.0.0.1]) by kerkenna.nic.fr (8.13.8/8.13.8) with ESMTP id m7LHGK87074754; Thu, 21 Aug 2008 19:16:21 +0200 (CEST) (envelope-from souissi@kerkenna.nic.fr) Received: (from souissi@localhost) by kerkenna.nic.fr (8.13.8/8.13.8/Submit) id m7LHGJJW074753; Thu, 21 Aug 2008 19:16:19 +0200 (CEST) (envelope-from souissi) Date: Thu, 21 Aug 2008 19:16:19 +0200 From: Mohsen Souissi To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR Message-ID: <20080821171619.GA68008@kerkenna.nic.fr> References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> <82bpzn3etu.fsf@mid.bfk.de> <81795.1219246023@nsa.vix.com> <20080820172800.GF95996@kerkenna.nic.fr> <56470.1219266519@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56470.1219266519@nsa.vix.com> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 20 Aug, Paul Vixie wrote: | i worry about | and | . i mention the | earlier-than-final draft because its title was "Fragmentation | Considered Very Harmful" which was a play on WRL-87-3 | "Fragmentation Considered Harmful" (Kent and Mogul, DECWRL 1987). | BIND has had to implement all kinds of fallbacks in its EDNS0 | support due to firewalls that don't allow fragments or which do the | wrong thing with them. i am therefore not as convinced today as i | was in RFC 2671 that fragmentation is a reasonable way to expand | the DNS message size beyond 512 octets. ==> Hmm, I can see. Otoh, nobody could imagine at that time (and even 10 years ago) how the network-layer would become complex and its components (often) misbehaving (magic combination of NATs, Firewalls, Load Balancers...). So don't blame yourself ;-) [...] | there is work going on in this WG to make EDNS0 mandatory. that will have | an impact far broader than what we say to eachother in the forum itself. | as you yourself point out: | | > 2) It is directly related to the discussion which took place on dnsext ml | > while editing dns-protocol-profile: | > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00037.html | > (see section 4.2.2). | > | > The I-D expired on Jul 22nd, a copy is available here: | > http://ietfreport.isoc.org/idref/draft-ietf-dnsext-dns-protocol-profile/ | > | > This I-D should be recycled in the near future as I understood from last | > dnsext session @ IETF. And then, the result of the current debate may be | > helpful for people in charge of editing next version | > dns-protocol-profile... | > | > Mohsen. | | it's possible that you (mohsen) should volunteer to the WG chairs to help | edit that document, since i believe its current authors are overcommitted. ==> During IETF@Dublin, Ólafur discussed that matter with the editors (and maybe others). Stéphane Bortzmeyer (a colleague of mine) was among them and committed with some others to taking again that task before next IETF. Hope it will efficiently move forward by then. Mohsen. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 10:37:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA793A67B2; Thu, 21 Aug 2008 10:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] 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 NA6zTK8oIaWp; Thu, 21 Aug 2008 10:37:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 273533A688D; Thu, 21 Aug 2008 10:37:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWDzj-0004jx-0N for namedroppers-data@psg.com; Thu, 21 Aug 2008 17:30:47 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWDzf-0004jS-CL for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 17:30:45 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A82B1A6684; Thu, 21 Aug 2008 17:30:36 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 21 Aug 2008 19:05:45 +0200." <20080821170545.GB14116@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 21 Aug 2008 17:30:36 +0000 Message-ID: <49938.1219339836@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A82B1A6684.6DFB7 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: SCTP (and DCCP) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > It is not the only mitigation. nominum, powerdns, and unbound are probably doing more than port randomization. perhaps you can all three explain what you're doing, in detail, so that the WG can decide whether those are reasonable things to recommend to the rest of the community. (for BIND, ISC explicitly decided not to implement anything experimental, not even dns-0x20, during the six month period during which patches had to be prepared in secrecy. we'd like to do more, but we don't want to get too far ahead of the WG's thinking on this.) > It is not cool and revolutionary though.. But the upside is that it does > not require deprecating DNS over TCP, nor does it require moving DNS to > SCTP or DCCP other exciting new protocols. do tell. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 12:56:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51AA3A6853; Thu, 21 Aug 2008 12:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.036 X-Spam-Level: X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_14=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, 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 rhMLjmasjohN; Thu, 21 Aug 2008 12:56:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 568903A6B48; Thu, 21 Aug 2008 12:56:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWG95-000MMq-3J for namedroppers-data@psg.com; Thu, 21 Aug 2008 19:48:35 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWG8t-000MKy-Nu for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 19:48:28 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7LJluIh008766; Thu, 21 Aug 2008 12:48:01 -0700 (PDT) Cc: Nicholas Weaver , bert hubert , namedroppers@ops.ietf.org Message-Id: <1ABC2F5B-BA77-459E-9178-B589A2347129@icsi.berkeley.edu> From: Nicholas Weaver To: Paul Vixie In-Reply-To: <49938.1219339836@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: SCTP (and DCCP) Date: Thu, 21 Aug 2008 12:47:55 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 21, 2008, at 10:30 AM, Paul Vixie wrote: >> It is not the only mitigation. > > nominum, powerdns, and unbound are probably doing more than port > randomization. perhaps you can all three explain what you're doing, > in > detail, so that the WG can decide whether those are reasonable > things to > recommend to the rest of the community. Note, I'm not a DNS developer. However, I have been looking at these from the IDS viewpoint and attacker viewpoint, and also been corresponding with one of the Unbound developers (so a lot of what I'm going to say is influenced by that discussion as well, full acks in my previous mail). But I believe there are several mitigations, all of them which are very powerful, beyond just increasing entropy, that should at least be considered. So how do you think about mitigating things when you think like the IDS crowd does? First, develop a taxonomy of various properties of attacks. Blind vs Aware attacks: Does the attacker have to guess any entropy or is it known to the attacker? Transparent vs Blocking attacks: Is the attacker unable to squelch the legitimate response or will the legitimate response be blocked? Direct Record vs Glue: The resolver's query is in the form "X is ?". Is the attacker's desire to get "X is EVIL", or is the attacker's desire to get "SOMETHING_ELSE is EVIL" to be accepted (where SOMETHING_EVIL is ANYTHING beyond the direct answer of "X is Y", it could be an additional record, an authority record, something like "X CNAME TARGET,TARGET A EVIL")? Transaction vs Cache: Does the attacker desire that the eventual victim act on the transaction, or is it necessary for the victim's resolver to cache the response? Then look at how attackers fit in the taxonomy. A packet injector is "Aware and transparent", while a MitM is "Aware and blocking". "Aware + blocking" == game over short of crypto. But you know that. In particular, Yahoo cookie hijacking (as described in a previous message) is a blind, direct record, transaction attack, that nonetheless has a "race until win" property, although it takes advantage of interlocking weaknesses (when the browser sends cookies, how Yahoo handles cookies) in order to gain "Run until win". Kaminski attacks are blind, glue, cache attacks: The actual response is meaningless, and it is that they are a glue attack is what enables it to be "Run until Win" rather than "Run every TTL until Win" which doesn't reduce the packet count required but does greatly reduce the time involved. (is there ANY kaminski variant that has "X is Y" as the only response the attacker wants to cache? I don't believe so, because that's old- school cache poisoning.) Blind attacks like this MAY be transparent, or they MAY be enough of a DOS to be blocking. It depends on how much hostility you want to direct at your victim's network. This taxonomy can then guide defenses: Entropy increases (per previous post) (port randomization, dns-0x20, randomly selecting authority (per unbound)) protects against blind attacks with probabilistic bounds. 40 bits of entropy gives you good comfort, even when paranoid like me. Duplication acts to increase entropy for the cache by nearly 2x, but either: a) Decreases it for transactions (by 1 bit) while still resolving anomalous servers b) Increases it for transactions (by nearly 2x) while preventing anomalous servers from resolving. So pick your tradeoff if you need to duplicate to add entropy: do you want to allow blind transactional attacks and anomalous servers, or block blind transaction attacks and anomalous servers. Yet entropy is also a "bear race": bots are valuable resources, so you don't need 100% protection, just enough protection that an attack is economically unfeasible. 40 bits and even paranoid me is happy. Blind attacks can also be trivially detected, both by the IDS and by the DNS resolver: they generate responses that don't match requests, so you can say "I KNOW I am under attack" and "do something", which I BELIEVE allows you to say "the probability of their being one or more poisoned entries in my cache is less than P" by voiding the cache completely when it is greater than P (see the previous discussion on why you should be able to set P really low and not have this enable a DOS if you have sufficient entropy) Transparent attacks can be detected as well. They generate two or more responses for the SAME request but with different values, within the same timeout. A preliminary IDS based study shows that this is VERY rare (1 server seen at ICSI, 30 seen at Ohio State, under a week+ of traffic), so it is a very low false-positive situation. The stateholding to detect such an attack is reasonable but not trivial. Assume 100k active outbound requests/second. With 1KB/ record stateholding, and a 3 second timeout, this is 300MB of stateholding to detect transparent attacks at a massively busy resolver. Transparent transaction attacks can be detected in this manner. And the detection of the attack could be forwarded to the client as well: take the second result, set the TTL to 1s, and forward it to the client to indicate a mismatch, allowing the client to detect the same thing the resolver did (plus packet injectors on the local network). Transparent cache attacks can be mitigated, not just detected. When a transparent attack is detected, either UNDO or INVALIDATE any cache changes caused by the first response. It gets to be a maze of pointers, but I THINK this can be done "cleanly" (constant time/ request for all work). Thus someone able to directly observe all the DNS traffic from the resolver and inject packets is both detectible (transparent transaction attacks are detected) and can only affect the results while in-path (transparent cache attacks are mitigated). Likewise, unless a blind attack generates enough traffic that the legitimate response is blocked, the blind attack can't affect the cache, and is detected for the transaction. The effect on anomalous servers which trigger this (which, as I mentioned, are few) is a: Their results are NEVER cached. b: If the eventual client software is suitably paranoid, transactions won't be conducted. "blind direct cache" attacks (old school cache poisoning) have a "Run every TTL until Win" property, which is good. You make the probability of winning low (through entropy), AND you make it so you can't run often, and you are happy. Lets keep it that way. The only case where a "blind direct cache" attack on a single name is "run until win" is if the legitimate response either doesn't return or returns an error. Thus a question: Should error lookups for name X also have an implicit TTL (of say, 1 minute?) in the resolver. And there APPEARS to be policies on glue which mitigate the glue portion of a "blind glue cache" attack, without increasing the power of an "aware glue cache" attack. (Glue is somewhat "out of bailywick" for me, pun intended, but...) The blind glue attacks gain much of its power from "Run until Win" on the race condition, rather than "Run every TTL until Win". Run until win does not reduce the number of packets required, but greatly reduces the amount of TIME required. If the policy on all the additional garbage (INCLUDING the information about the authoritative nameservers, what all the CNAMEs point to, etc etc etc etc etc. Yes, I mean EVERYTHING other than 'X is Y'!) is to "Never cache, only use for the current transaction. PERIOD.", this completely blocks the "aware glue cache" attacks as far as I know, as I have yet to see a kaminski variant which is: "Cause server to request X, response with 'X is Y'" Simply because the race for any given X can only be run once every TTL (excluding failures, as mentioned previously), so you're back to the defender's happy place of "run every TTL until win". Of course, such a glue policy would cause a huge efficiency hit, as certain things (like who's the authoritative server for .com) never get cached. OOps. However, if the resolver takes all the additional garbage it would have cached and does separate background lookups to validate each piece thats not in the cache "(authority for .com is? A record for a.gtld-servers.net is?, A record for b.gtld-servers.net is? ...)", now all the subsequent lookups will run exactly as we would have expected without this policy change, including cache behavior. Yet at the same time, it should defang all "blind glue cache" attacks, because instead of being "run until win", 'win' becomes simply the start of ANOTHER race that both has an unpredictable start AND can only be "run every TTL until win", because the result gets cached. I also THINK this subsumes all the bailywick checking business which just gives me a headache. And it doesn't increase the power of "aware glue cache" attacks, it just means the attacker must send a few more packets. This should have two effects beyond the attacker. If the authority is b0rken, and doesn't return things like the ns query, it will not be cached but will still be reachable. (ALL the crud is still respected within the context of the current transaction only. It will just never be cached). And it increases overall load on the DNS authorities, by an "I'm not sure how much" level (remember, the stuff being asked for should cache really well). It should be possible, however, to "given a trace piped through Bro, estimate the # of additional queries which would be generated if the authoritative servers aren't b0rken" if those on the list would think it valuable. And there are also projects to revalidate caches as well, eg http://www.onzra.com/cacheaudit.html , which attempts to mitigate the duration of all cache attacks where the auditor is not under the same attack path as the resolver. Thus also, layers of defenses are important. Entropy mitigates blind attacks. Mismatch detection detects (on transaction)/mitigates (on cache) aware attacks, even against packet injectors. "Cache nothing I did not actually ask for, period" looks like it mitigates blind-glue attacks on the cache. Auditing can detect cache attacks. This is why this IDS person believes there are many options for mitigation, far more than just port randomization and 0x20, and they all should at least be considered and understood. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 13:18:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AAD3A6768; Thu, 21 Aug 2008 13:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_05=-1.11, 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 xzXlskbcjcow; Thu, 21 Aug 2008 13:18:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B94F3A659B; Thu, 21 Aug 2008 13:18:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWGWS-000PDT-4h for namedroppers-data@psg.com; Thu, 21 Aug 2008 20:12:44 +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 ) id 1KWGWK-000PCL-9f for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 20:12:38 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KWGWH-0002Jm-Uu for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:12:34 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id DA94F4B44C; Thu, 21 Aug 2008 22:12:46 +0200 (CEST) Date: Thu, 21 Aug 2008 22:12:46 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Agile countermeasures Message-ID: <20080821201246.GE14116@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49938.1219339836@nsa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 21, 2008 at 05:30:36PM +0000, Paul Vixie wrote: > > It is not the only mitigation. > > nominum, powerdns, and unbound are probably doing more than port > randomization. perhaps you can all three explain what you're doing, in > detail, so that the WG can decide whether those are reasonable things to > recommend to the rest of the community. That sounds like a very fine initiative. I've been holding back because 'thinking out loud' between implementors might not be DNSEXT-material. Perhaps it is also something that might benefit from some privacy. The basic ideas are probably good to get out in the open, if only to create some documented prior art. I'd hate for someone to patent an effective countermeasure. Note well indeed. The basic premise is that it is easy to detect any targeted attack, even a 'kaminsky-style' attack, as outlined in http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01213.html The referenced post is light on what to do if an attack on a zone apex is detected. (forgive me my weak DNS terminology, the post outlines what I mean) Some ideas below - these are the things I've researched enough to make statements about, some other ideas are still cooking. A number of things appear to work some of the time: 1) open up a semi-persistent TCP channel and funnel all subsequent queries for that zone apex and that server over it. This incurs syn, synack, ack, fin, finack ack, but as we're on the receiving end of thousands of queries by that time, this overhead is not significant. Keep the channel alive until the responder disconnects, and reopen it. Fails on hosts which don't do TCP. If attempts to outlaw DNS over TCP succeed, this percentage might rise. Conversely, if we reaffirm TCP's first class citizen status for DNS, and "clarify" the timout rules, this option becomes more succesful. 2) Repeat queries n times (fails on a number of important content distribution networks, am in talks with those) 3) DNS-0x20 - although that doesn't protect the vital and scary . and COM records from numerical kaminsky attacks. What always works is: 4) Stop accepting new data for the attacked zone apex and everything beneath it. This has the downside that over time, the TTL of the bonafide data expires, turning a spoof into a DoS. A more advanced way is: 5) Stop accepting new data below the attacked apex, but also stop expiring it. This last option opens up a subtle and expensive DoS opportunity to keep old data alive, and to prevent new data from entering the cache. Some unexpected things that work: 6) Keep track of unresponsive servers, and stop sending them queries. It turns out to be very hard to dose a DoS such that you overwhelm the correct answers, but still allow most of them to get through. My own implementation is lucky in this respect - I never intended this as an anti-spoofing measure, but in my own experiments it is very hard not to trigger this protection, and still maintain adequate spoofing bandwidth. 7) Don't have too much effective bandwidth. It turns out that it does not really matter how much bandwidth an attacker can generate. What matters is how much a receiving nameserver can process. This is limited by its incoming bandwidth, plus the performance of its implementation. What might work in the nearish future: 8) EDNS PING. Currently supported by 2 (two) hosts on the internet. David Ulevitch and I will be releasing patches for BIND 9, NSD and DJBDNS, plus PowerDNS will of course support it. It turns out that you discover the things that work and that don't work by actually implementing the countermeasures and seeing what happens. The naive 'drop back to TCP' for example proved to be an instant DoS on the authentic authoritative servers. >From this came the 'semi-persistent TCP channel', which works very well. The discovery that keeping track of servers that generate timeouts is an effective protection also came out of attempts to spoof PowerDNS. I'm pretty sure that we'll discover ever better techniques as time progresses. For now the best recipe appears to be a mix of 1, 2, 3 and 8 and use 5 if those fail. The best an attacker can then do is keep a limited number of domains (that don't do TCP and that fail the 'try n times'-test) from receiving new data. I realise the agile techniques mentioned above are not very 'clean'. But in the end, it is results that matter. The challenge is to have these countermeasures not turn into new DoS-vectors (as noted by David Conrad), but otherwise all real world engineering has its dirty spots. 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 14:35:46 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD5D3A6A57; Thu, 21 Aug 2008 14:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 cQHhhXBSwcgy; Thu, 21 Aug 2008 14:35:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A72783A6B14; Thu, 21 Aug 2008 14:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWHhu-00081K-Ga for namedroppers-data@psg.com; Thu, 21 Aug 2008 21:28:38 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWHhq-00080v-UL for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 21:28:36 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 8013533C59; Thu, 21 Aug 2008 14:28:34 -0700 (PDT) Date: Thu, 21 Aug 2008 14:28:34 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bert hubert Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: how to spoof . by Kaminsky's method (Re: Agile countermeasures) In-Reply-To: <20080821201246.GE14116@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 21 Aug 2008 22:12:46 +0200, bert hubert wrote: > 3) DNS-0x20 - although that doesn't protect the vital and scary . and COM > records from numerical kaminsky attacks. This is probably an off-topic for this thread and in any case is minor, but it's something I've always been wondering, so please let me ask: how specifically would you spoof . by a "Kaminsky attack"? --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 14:39:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA9A3A69F5; Thu, 21 Aug 2008 14:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 bUbPku9FszY9; Thu, 21 Aug 2008 14:39:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F19E3A694A; Thu, 21 Aug 2008 14:39:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWHn5-0008iz-1A for namedroppers-data@psg.com; Thu, 21 Aug 2008 21:33:59 +0000 Received: from [64.18.2.159] (helo=exprod7og103.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWHn1-0008iR-GR for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 21:33:57 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 14:33:54 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id A414C1A8203 for ; Thu, 21 Aug 2008 14:33:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 21 Aug 2008 14:33:53 -0700 Message-ID: From: Ted Lemon To: Namedroppers WG In-Reply-To: <20080821201246.GE14116@outpost.ds9a.nl> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Agile countermeasures Date: Thu, 21 Aug 2008 14:33:53 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 21, 2008, at 1:12 PM, bert hubert wrote: > That sounds like a very fine initiative. I've been holding back > because > 'thinking out loud' between implementors might not be DNSEXT-material. I think it's namedroppers material, whether or not it's DNSEXT material. > Perhaps it is also something that might benefit from some privacy. If your countermeasures depend on people not knowing how they work, then they don't work. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 14:39:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8F83A694A; Thu, 21 Aug 2008 14:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, 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 9-lK6Encd4pD; Thu, 21 Aug 2008 14:39:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 32A273A66B4; Thu, 21 Aug 2008 14:39:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWHoD-0008vM-1v for namedroppers-data@psg.com; Thu, 21 Aug 2008 21:35:09 +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 ) id 1KWHo7-0008u5-BW for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 21:35:06 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KWHo3-00045I-Da for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 23:34:59 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9108B4B44C; Thu, 21 Aug 2008 23:35:12 +0200 (CEST) Date: Thu, 21 Aug 2008 23:35:12 +0200 From: bert hubert To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) Message-ID: <20080821213512.GF14116@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 21, 2008 at 02:28:34PM -0700, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > 3) DNS-0x20 - although that doesn't protect the vital and scary . and COM > > records from numerical kaminsky attacks. > > This is probably an off-topic for this thread and in any case is > minor, but it's something I've always been wondering, so please let me > ask: how specifically would you spoof . by a "Kaminsky attack"? Jinmei, Perhaps I'm very mistaken. I think I know more about implementing than I know about DNS theory. But this is how I think it works: Send queries for '1.', '2.', '3.', '4.' etc to a resolver. In the meantime, blast it with answers for '1.', '2.' etc with new NS records of your choosing for '.'. Be sure to pick the source address of the nearest root-server. I don't think . is special in any way in this respect. 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 14:59:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D6C3A6852; Thu, 21 Aug 2008 14:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599, 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 ZQUMSmYu+7N8; Thu, 21 Aug 2008 14:59:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4AA33A6856; Thu, 21 Aug 2008 14:59:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWI5C-000BGB-B0 for namedroppers-data@psg.com; Thu, 21 Aug 2008 21:52:42 +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 ) id 1KWI52-000BEe-Ow for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 21:52:40 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KWI50-0004O0-90 for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 23:52:30 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 88B694B44C; Thu, 21 Aug 2008 23:52:43 +0200 (CEST) Date: Thu, 21 Aug 2008 23:52:43 +0200 From: bert hubert To: Ted Lemon Cc: Namedroppers WG Subject: Re: Agile countermeasures Message-ID: <20080821215243.GA19087@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 21, 2008 at 02:33:53PM -0700, Ted Lemon wrote: > >Perhaps it is also something that might benefit from some privacy. > > If your countermeasures depend on people not knowing how they work, > then they don't work. Well - I was basically saying this on behalf of companies that might have a hard time disclosing their (internal) deliberations, or perhaps intellectual property. It is not about keeping things ultimately secret. I wouldn't be able to anyhow - "the source is out there". 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 14:59:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668863A6852; Thu, 21 Aug 2008 14:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.1 X-Spam-Level: X-Spam-Status: No, score=-99.1 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 xA-e+tabMStp; Thu, 21 Aug 2008 14:59:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76EFB3A6881; Thu, 21 Aug 2008 14:59:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWI7f-000Bax-2J for namedroppers-data@psg.com; Thu, 21 Aug 2008 21:55:15 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWI7b-000BaR-G6 for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 21:55:13 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 33EBA33C59; Thu, 21 Aug 2008 14:55:11 -0700 (PDT) Date: Thu, 21 Aug 2008 14:55:11 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bert hubert Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) In-Reply-To: <20080821213512.GF14116@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080821213512.GF14116@outpost.ds9a.nl> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 21 Aug 2008 23:35:12 +0200, bert hubert wrote: > > This is probably an off-topic for this thread and in any case is > > minor, but it's something I've always been wondering, so please let me > > ask: how specifically would you spoof . by a "Kaminsky attack"? > Perhaps I'm very mistaken. I think I know more about implementing than I > know about DNS theory. > > But this is how I think it works: > > Send queries for '1.', '2.', '3.', '4.' etc to a resolver. In the meantime, > blast it with answers for '1.', '2.' etc with new NS records of your choosing > for '.'. Be sure to pick the source address of the nearest root-server. So, do you mean something like this? - the attacker (somehow) force the recursive server to send a query for (e.g.) '1. IN AAAA' - then the attacker sends a forged response as follows: question: 1. IN AAAA authority: . IN NS evil.example. additional: evil.example. AAAA 2001:db8::1 - the recursive server replaces the forged NS RRset with the legitimate one: . IN NS [a-m].root-servers.net. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 15:09:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB333A6AEE; Thu, 21 Aug 2008 15:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.18 X-Spam-Level: X-Spam-Status: No, score=0.18 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, 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 Cpor4Rl39NPT; Thu, 21 Aug 2008 15:09:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0DCD3A6992; Thu, 21 Aug 2008 15:09:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIGc-000DD0-VU for namedroppers-data@psg.com; Thu, 21 Aug 2008 22:04:30 +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 ) id 1KWIGZ-000DCK-2P for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:04:29 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KWIGX-0004cV-2h for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 00:04:25 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 5DA304B44C; Fri, 22 Aug 2008 00:04:38 +0200 (CEST) Date: Fri, 22 Aug 2008 00:04:38 +0200 From: bert hubert To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) Message-ID: <20080821220438.GH14116@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080821213512.GF14116@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 21, 2008 at 02:55:11PM -0700, JINMEI Tatuya / ?$B?@L@C#:H wrote: > - the recursive server replaces the forged NS RRset with the > legitimate one: > . IN NS [a-m].root-servers.net. Well, you could do that - hardcode the list of root-servers. Is that what people do? 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 15:17:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE883A68A9; Thu, 21 Aug 2008 15:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.25 X-Spam-Level: X-Spam-Status: No, score=-99.25 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 IVNKIsJbpq+F; Thu, 21 Aug 2008 15:17:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 495423A6804; Thu, 21 Aug 2008 15:17:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIO4-000Efd-HG for namedroppers-data@psg.com; Thu, 21 Aug 2008 22:12:12 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIO0-000Eec-5w for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:12:10 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id DBF2F33C59; Thu, 21 Aug 2008 15:12:07 -0700 (PDT) Date: Thu, 21 Aug 2008 15:12:07 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bert hubert Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) In-Reply-To: <20080821220438.GH14116@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080821213512.GF14116@outpost.ds9a.nl> <20080821220438.GH14116@outpost.ds9a.nl> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Fri, 22 Aug 2008 00:04:38 +0200, bert hubert wrote: > > - the recursive server replaces the forged NS RRset with the > > legitimate one: > > . IN NS [a-m].root-servers.net. > > Well, you could do that - hardcode the list of root-servers. Is that what > people do? Oops, I meant: - the recursive server replaces the legitimate NS RRset for . (which is normally) . IN NS [a-m].root-servers.net. with the forged NS RRset Is this what you had in your mind? --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 15:21:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624303A6800; Thu, 21 Aug 2008 15:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.423 X-Spam-Level: X-Spam-Status: No, score=-4.423 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 D-qEVlE29H0z; Thu, 21 Aug 2008 15:21:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38C633A6804; Thu, 21 Aug 2008 15:21:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWISd-000Faw-2m for namedroppers-data@psg.com; Thu, 21 Aug 2008 22:16:55 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWISY-000FaR-8F for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:16:52 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7LMGXVq028898; Thu, 21 Aug 2008 15:16:33 -0700 (PDT) Cc: Nicholas Weaver , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <13AD68BF-5F0E-4695-B2F5-4D97F08D3504@icsi.berkeley.edu> From: Nicholas Weaver To: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) Date: Thu, 21 Aug 2008 15:16:33 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 21, 2008, at 2:28 PM, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: > At Thu, 21 Aug 2008 22:12:46 +0200, > bert hubert wrote: > >> 3) DNS-0x20 - although that doesn't protect the vital and scary . =20 >> and COM >> records from numerical kaminsky attacks. > > This is probably an off-topic for this thread and in any case is > minor, but it's something I've always been wondering, so please let me > ask: how specifically would you spoof . by a "Kaminsky attack"? A: Its not off topic. B: Its actually fun to explain. So here goes: When a DNS resolver asks for a mapping of the form "X is WHAT?" and =20 gets a reply back from the authoritative server that "X is SOMETHING", =20= there is a lot of other information returned by the authoritative =20 server, including things like "Y is Z" and "Authorities for mydomain =20 are R, S, T at these IP addreses" and "Oh by the way, =20 adds.mydomain.com is this IP address". These records are all potentially needed to complete the current =20 transaction, but effectively all DNS resolvers will, under some =20 conditions, cache this additional data, so subsequently the resolver =20 will not have to ask, but can just check out what it has already for =20 various purposes. (This is the whole "Bailywick" checking business). This interacts, umm, badly, with the "blind" attack. The classic blind attack is: I cause the DNS resolver to request 'X is =20= WHAT?', and send a bunch of forged replies that look like they are =20 coming from the legitimate authority in the form 'X is MY_EVIL_RESULT'. If I get lucky (and select the same transaction ID, port number, etc), =20= the DNS server caches my response and for now until my TTL expires, =20 the DNS resolver will always believe that "X is MY_EVIL_RESULT", and =20 anyone else who asks it will get 'X is MY_EVIL_RESULT' And its pretty easy to get lucky unless there are randomized ports or =20= other entropy sources, because the transaction ID is 16 bits. Thus =20 for just a single try, if I try 1000 responses, the odds of success =20 are roughly 1.5%. Decent but not great odds. However, if I failed, the DNS resolver got back 'X is GOOD' from the =20 real authority, and will not do another request until the TTL expires, =20= which can be hours (or days). This makes the attacker unhappy. The kaminski attack is a surprisingly minor variant. The attacker =20 causes the DNS resolver to request 'SOMETHING_I_DONT_CARE is WHAT?", =20 and sends a bunch of replies in the form of 'SOMETHING_I_DONT_CARE is =20= WHATEVER, oh, and by the way, X is MY_EVIL_RESULT'. Or any one of a =20 bazillion variants of this form. If the attacker gets lucky, the name server now believes 'X is =20 MY_EVIL_RESULT' Now the attacker, if he fails, can try again immediately by asking for =20= 'SOMETHING_ELSE_I_DONT_CARE_ABOUT', because thats not in the cache and =20= causes the DNS resolver to try again. Thus it changes the threat model from "Try once every X hours" to =20 "Just keep trying until I succeed". So something that might have =20 required days of waiting and 20,000 packets now requires just 20,000 =20 packets, no waiting! -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 15:22:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C923A6B43; Thu, 21 Aug 2008 15:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.337 X-Spam-Level: X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 ftrWYB35IMpG; Thu, 21 Aug 2008 15:22:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D037D3A6B31; Thu, 21 Aug 2008 15:22:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIUI-000Foq-Po for namedroppers-data@psg.com; Thu, 21 Aug 2008 22:18:38 +0000 Received: from [64.18.2.163] (helo=exprod7og105.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIUE-000FoC-7X for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:18:36 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 15:18:31 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id E77F01A8207; Thu, 21 Aug 2008 15:18:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 21 Aug 2008 15:18:30 -0700 CC: Namedroppers WG Message-ID: <773C5C38-44F1-493D-9732-E74EAD43FC35@nominum.com> From: Ted Lemon To: bert hubert In-Reply-To: <20080821215243.GA19087@outpost.ds9a.nl> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Agile countermeasures Date: Thu, 21 Aug 2008 15:18:29 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080821215243.GA19087@outpost.ds9a.nl> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 21, 2008, at 2:52 PM, bert hubert wrote: > Well - I was basically saying this on behalf of companies that might > have a > hard time disclosing their (internal) deliberations, or perhaps > intellectual > property. Understood. But in fact it's probably better that discussions like that not percolate out into the greater IETF community, since they might affect determinations about prior art (speaking as one who has been burned, albeit mildly, by this in the past). -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 15:23:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105C23A6B31; Thu, 21 Aug 2008 15:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.654 X-Spam-Level: X-Spam-Status: No, score=-4.654 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 fOw0er6W2iLK; Thu, 21 Aug 2008 15:23:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA4D43A6781; Thu, 21 Aug 2008 15:23:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIVA-000FvX-PL for namedroppers-data@psg.com; Thu, 21 Aug 2008 22:19:32 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIUy-000FtJ-4D for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:19:29 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7LMJ3B6029362; Thu, 21 Aug 2008 15:19:04 -0700 (PDT) Cc: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <5FCB2395-DED2-465C-91B4-A372103CDC6C@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Nicholas Weaver In-Reply-To: <13AD68BF-5F0E-4695-B2F5-4D97F08D3504@icsi.berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) Date: Thu, 21 Aug 2008 15:19:03 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <13AD68BF-5F0E-4695-B2F5-4D97F08D3504@icsi.berkeley.edu> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > On Aug 21, 2008, at 2:28 PM, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94= =E5=93=89 wrote: > >> At Thu, 21 Aug 2008 22:12:46 +0200, >> bert hubert wrote: >> >>> 3) DNS-0x20 - although that doesn't protect the vital and scary . =20= >>> and COM >>> records from numerical kaminsky attacks. >> >> This is probably an off-topic for this thread and in any case is >> minor, but it's something I've always been wondering, so please let =20= >> me >> ask: how specifically would you spoof . by a "Kaminsky attack"? > > A: Its not off topic. > > B: Its actually fun to explain. So here goes: Err, me bad, missed the fundimental addition of how you spoof . You make your requests for B123.com B124.com B125.com And in the authority field, you give a new authority for .com Now you only have 4 bits of entropy for 0x20. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 15:31:16 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435623A6A91; Thu, 21 Aug 2008 15:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.3 X-Spam-Level: X-Spam-Status: No, score=-99.3 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 FGvjRCLrGDG3; Thu, 21 Aug 2008 15:31:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FBD03A68A9; Thu, 21 Aug 2008 15:31:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIcM-000HZy-KG for namedroppers-data@psg.com; Thu, 21 Aug 2008 22:26:58 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIc9-000HY2-51 for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:26:48 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id DFAA633C59; Thu, 21 Aug 2008 15:26:44 -0700 (PDT) Date: Thu, 21 Aug 2008 15:26:44 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Nicholas Weaver Cc: namedroppers@ops.ietf.org Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) In-Reply-To: <13AD68BF-5F0E-4695-B2F5-4D97F08D3504@icsi.berkeley.edu> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <13AD68BF-5F0E-4695-B2F5-4D97F08D3504@icsi.berkeley.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 21 Aug 2008 15:16:33 -0700, Nicholas Weaver wrote: > > This is probably an off-topic for this thread and in any case is > > minor, but it's something I've always been wondering, so please let me > > ask: how specifically would you spoof . by a "Kaminsky attack"? > > A: Its not off topic. > > B: Its actually fun to explain. So here goes: Thanks for the lecture, but I believe I'm one of the people in the world who know how the Kaminsky attack generally works very well:-) My question was how specifically it works for ".". I'd like to see a specific sequence of question, forged response, resulting poisoned cache entry for this specific target. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 15:46:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3863A69CA; Thu, 21 Aug 2008 15:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.733 X-Spam-Level: X-Spam-Status: No, score=-4.733 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 OiuxmGe-BKiN; Thu, 21 Aug 2008 15:46:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E9F53A695E; Thu, 21 Aug 2008 15:46:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIqL-000KB9-VS for namedroppers-data@psg.com; Thu, 21 Aug 2008 22:41:25 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIqD-000K8V-JK for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:41:23 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7LMeuts002355; Thu, 21 Aug 2008 15:40:56 -0700 (PDT) Cc: =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= , bert hubert , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <61AEC389-CEC7-4569-9B54-4467B46F44B1@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Nicholas Weaver In-Reply-To: <5FCB2395-DED2-465C-91B4-A372103CDC6C@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) Date: Thu, 21 Aug 2008 15:40:56 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <13AD68BF-5F0E-4695-B2F5-4D97F08D3504@icsi.berkeley.edu> <5FCB2395-DED2-465C-91B4-A372103CDC6C@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Again, apologies for my previously stupid reply. However, it makes me wonder: What are the conditions where various DNS resolver implementations will REPLACE a cache entry vs ADD a cache entry based on the reply. EG, the cache has the RRset .com NS is {a-m}.gtld-servers.net living in the cache effectively forever. What conditions in an authoritative reply will cause this to be evicted/replaced with new information? -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 15:50:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5567D3A68B3; Thu, 21 Aug 2008 15:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.325 X-Spam-Level: X-Spam-Status: No, score=-99.325 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 JefDRQKnz5Za; Thu, 21 Aug 2008 15:50:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D617D3A6774; Thu, 21 Aug 2008 15:50:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIvZ-000LE3-Qk for namedroppers-data@psg.com; Thu, 21 Aug 2008 22:46:49 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWIvV-000LDb-Vv for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 22:46:47 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id B557E33C59; Thu, 21 Aug 2008 15:46:45 -0700 (PDT) Date: Thu, 21 Aug 2008 15:46:45 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Nicholas Weaver Cc: namedroppers@ops.ietf.org Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) In-Reply-To: <5FCB2395-DED2-465C-91B4-A372103CDC6C@ICSI.Berkeley.EDU> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <13AD68BF-5F0E-4695-B2F5-4D97F08D3504@icsi.berkeley.edu> <5FCB2395-DED2-465C-91B4-A372103CDC6C@ICSI.Berkeley.EDU> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 21 Aug 2008 15:19:03 -0700, Nicholas Weaver wrote: > Err, me bad, missed the fundimental addition of how you spoof . > > You make your requests for > > B123.com > B124.com > B125.com > > And in the authority field, you give a new authority for .com > > Now you only have 4 bits of entropy for 0x20. I know this works (btw the attacker would even omit 'B', which should also work). I didn't ask that. My question was very specifically about ".". Speaking about "com", I think "doesn't protect" in the following sentence : 3) DNS-0x20 - although that doesn't protect the vital and scary . and COM : records from numerical kaminsky attacks. is not very accurate. 0x20 does provide protection for COM, but only with a small bit of entropy (3 bits). It's of course not sufficient, but my understanding is that 0x20 is not intended to be a single complete counter measure in the first place (i.e. it's expected to be used with other source of entropy), so I'd say even additional 3 bits are a plus if its cost is reasonable (which I also believe is the case). --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 16:05:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BB93A6B2F; Thu, 21 Aug 2008 16:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, 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 W1cI7b4MwK5J; Thu, 21 Aug 2008 16:05:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 339213A6800; Thu, 21 Aug 2008 16:05:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWJ9D-000NVF-OT for namedroppers-data@psg.com; Thu, 21 Aug 2008 23:00:55 +0000 Received: from [62.99.138.242] (helo=amd.co.at) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWJ97-000NUG-Rb for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 23:00:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by amd.co.at (Postfix) with ESMTP id 0DFB319D9C2; Fri, 22 Aug 2008 01:00:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at amd.co.at Received: from amd.co.at ([127.0.0.1]) by localhost (trottelkunde.amd.co.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rsPp7qBCjOe; Fri, 22 Aug 2008 01:00:47 +0200 (CEST) Received: from [192.168.0.129] (unknown [86.59.50.184]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amd.co.at (Postfix) with ESMTP; Fri, 22 Aug 2008 01:00:47 +0200 (CEST) Message-ID: <48ADF39C.20600@amd.co.at> Date: Fri, 22 Aug 2008 01:00:44 +0200 From: Michael Renner User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: SCTP (and DCCP) References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> In-Reply-To: <40391.1219336326@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > i see five reasons why SCTP is worth looking at as a primary transport with > UDP as its fallback. first, data transfer can take place in the second > round trip (packets 3 and 4). second, it has 32-bit ID fields so we could > go back to fixed port numbers perhaps even fixed+increment on TXID's. > third, we could mandate EDNS, and with it, we could mandate PING. fourth, > SCTP has the idea of "passive" sockets which mean nonquadratic socket pool > sizes. fifth, association timeout is handled in the stack not the app. All the things you talk about are engineering problems which are already solved this day. It's no big issue these days to serve thousands of clients, be it TCP or UDP. See [1] for common solutions to the problems, and [2] for benchmarks in this area. Nowadays the amount of clients you can serve in parallel are only limited by the amount of memory you've got for the respective data structures and the performance of the operations which are needed to traverse said data structures. RAM is cheap to come by, and at least since fefe has pointed out outstanding issues in implementations, every major OS should scale fine. If your application isn't designed for such a task it takes a bit of refactoring and a few hours back at the architecture board, but it is feasible. Please do not try to design the protocols around your current implementation but around current engineering standards. There's no need to go back to static source ports, the implementations which are out there work quite fine. You could also mandate (or "SHOULD", in RFC-speak) PING by now with the current UDP/TCP infrastructure, it just needs a common vision and a common goal. If you get the few major DNS vendors out there to support your cause, everything should be fine (tm) in a few years worth (and much earlier for those installations were people actually care about DNS). > i see two gigantic challenges for ANY non-UDP transport: installed base of > DNS protocol agents; installed base of firewalls and NATs and middleboxes. Whereas changes in the TCP direction are much easier to come by than SCTP/DCCP or any different "newfangled" protocol which installed base is tremendeously exceeded by the amount of IPv6 production hosts ;). Michael [1] http://www.kegel.com/c10k.html [2] http://bulk.fefe.de/scalability/ -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 16:49:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B4B3A6A3E; Thu, 21 Aug 2008 16:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, 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 JsReeKj5PwsJ; Thu, 21 Aug 2008 16:49:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36BA93A6929; Thu, 21 Aug 2008 16:49:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWJnM-0004GV-AZ for namedroppers-data@psg.com; Thu, 21 Aug 2008 23:42:24 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWJnI-0004G4-Oc for namedroppers@ops.ietf.org; Thu, 21 Aug 2008 23:42:22 +0000 Received: from [127.0.0.1] (gateway02.sjc.cts.trendmicro.com [216.99.131.196]) by harry.mail-abuse.org (Postfix) with ESMTP id 59DACA9443B; Thu, 21 Aug 2008 23:42:19 +0000 (UTC) Cc: namedroppers@ops.ietf.org Message-Id: From: Douglas Otis To: Paul Vixie In-Reply-To: <40391.1219336326@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: SCTP (and DCCP) Date: Thu, 21 Aug 2008 16:42:19 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 21, 2008, at 9:32 AM, Paul Vixie wrote: >> PS: for SCTP none of the nice features of SCTP has an interest for >> the common DNS (i.e., the part which uses UDP when the payload is >> not over sized, not AXFR where SCTP makes sense). As these features >> are not always for free SCTP has no definitive advantage over TCP >> and clearly can't take the place of UDP (for DNS). > > i see five reasons why SCTP is worth looking at as a primary > transport with UDP as its fallback. first, data transfer can take > place in the second round trip (packets 3 and 4). second, it has 32- > bit ID fields so we could go back to fixed port numbers perhaps even > fixed+increment on TXID's. third, we could mandate EDNS, and with > it, we could mandate PING. fourth, SCTP has the idea of "passive" > sockets which mean nonquadratic socket pool sizes. fifth, > association timeout is handled in the stack not the app. > > i see two gigantic challenges for ANY non-UDP transport: installed > base of DNS protocol agents; installed base of firewalls and NATs > and middleboxes. Agreed. However, there is a fairly sizable install base for SCTP since it handles phone switching traffic (SS7), Diameter, respool, and MEGACO. Both Cisco and Juniper support SCTP, and offer SCTP specific firewall solutions. The CRC32c used by SCTP is the same polynomial used by iSCSI. This polynomial has an increased Hamming distance and provides about the same error detection rate for Jumbo frames (the 9000 byte frames desired by JET which includes Abilene (Internet2), DREN (DOD), ESnet (DOE), NREN (NASA), as does the IEEE 802.3 CRC for its 1518-byte maximum packet size (1500 payload). SCTP also allows faster setup than TCP, and is fairly immune from packet spoofing. A cookie echo in the handshake holds resource state returned by the client attempting to connect. This approach mitigates packet spoofing and is more robust than TCP in dealing with DDoS attack. At some point people will want greater security and reliability, and SCTP offers a solution that also avoids the head of queue blocking and allows zero copy data placement needed with higher bandwidths. Perhaps just rumors of a new DNS on SCTP would help ensure home router vendors update their offering to handle this 8 year old IETF IP protocol. Overcoming the lack of low-end commodity router support seems to be a barrier holding back progress. If not Redmond, perhaps Redwood City? -Doug -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 18:03:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE02D3A6A8C; Thu, 21 Aug 2008 18:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.05 X-Spam-Level: *** X-Spam-Status: No, score=3.05 tagged_above=-999 required=5 tests=[AWL=0.995, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 0J1TcXvN7e9p; Thu, 21 Aug 2008 18:03:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3D863A68A4; Thu, 21 Aug 2008 18:03:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWKx3-000GoY-Av for namedroppers-data@psg.com; Fri, 22 Aug 2008 00:56:29 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWKwy-000Gnl-LF for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 00:56:26 +0000 Received: (qmail 6448 invoked from network); 22 Aug 2008 01:02:21 -0000 Received: from softbank219001188017.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.17) by necom830.hpcl.titech.ac.jp with SMTP; 22 Aug 2008 01:02:21 -0000 Message-ID: <48AE0EA6.5030607@necom830.hpcl.titech.ac.jp> Date: Fri, 22 Aug 2008 09:56:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Mohsen Souissi CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> <82bpzn3etu.fsf@mid.bfk.de> <81795.1219246023@nsa.vix.com> <20080820172800.GF95996@kerkenna.nic.fr> <56470.1219266519@nsa.vix.com> <20080821171619.GA68008@kerkenna.nic.fr> In-Reply-To: <20080821171619.GA68008@kerkenna.nic.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mohsen Souissi wrote: > | i worry about > | and > | . An inappropriate assumption in them is reassembly timeout of 15 second. > ==> Hmm, I can see. Otoh, nobody could imagine at that time (and even > 10 years ago) how the network-layer would become complex and its > components (often) misbehaving (magic combination of NATs, Firewalls, Load > Balancers...). So don't blame yourself ;-) More than 20 years ago when IPv4 was designed, it was considered that packet transit time can be as long as several or tens of seconds. For example, TTL of IPv4 is a transit time upper limit measured in seconds. Then, 15 seconds of reassembly timeout was reasonable. Today, though TTL could be more than 1 second, which is already quite unlikely, jitter of packet transit time is a lot less than 1 second that 0.4~0.2 second of reassembly timeout is enough, which requires several lines of kernel modification. It solves the reassembly problem, at least for the time being. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 18:39:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02C528C14E; Thu, 21 Aug 2008 18:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.284 X-Spam-Level: X-Spam-Status: No, score=-5.284 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 6m+POFCGxnPS; Thu, 21 Aug 2008 18:32:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4CE33A69B5; Thu, 21 Aug 2008 18:32:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWLQA-000MMj-8a for namedroppers-data@psg.com; Fri, 22 Aug 2008 01:26:34 +0000 Received: from [64.18.2.167] (helo=exprod7og107.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWLQ6-000MMF-6y for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 01:26:31 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 18:23:19 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id C39D71A8201; Thu, 21 Aug 2008 18:23:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 21 Aug 2008 18:23:19 -0700 CC: Mohsen Souissi , Paul Vixie , "namedroppers@ops.ietf.org" Message-ID: From: Ted Lemon To: Masataka Ohta In-Reply-To: <48AE0EA6.5030607@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR Date: Thu, 21 Aug 2008 18:23:17 -0700 References: <82myj85dt4.fsf@mid.bfk.de> <72546.1219243301@nsa.vix.com> <82bpzn3etu.fsf@mid.bfk.de> <81795.1219246023@nsa.vix.com> <20080820172800.GF95996@kerkenna.nic.fr> <56470.1219266519@nsa.vix.com> <20080821171619.GA68008@kerkenna.nic.fr> <48AE0EA6.5030607@necom830.hpcl.titech.ac.jp> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 21, 2008, at 5:56 PM, Masataka Ohta wrote: > Today, though TTL could be more than 1 second, which is already > quite unlikely, I measured ping times to my home server at as much as 40 seconds during the most recent IETF meeting. Arguably, we could describe this as an outage. But unfortunately, there exist networks where routers are configured with excessive buffering, or where the layer two erroneously provides reliability. On such networks, when there is congestion, long round trip times are actually quite common. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 19:03:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7DD3A6915; Thu, 21 Aug 2008 19:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] 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 IxkgN7Whw4WV; Thu, 21 Aug 2008 19:03:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A0D73A6886; Thu, 21 Aug 2008 19:03:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWLt9-0001dn-IR for namedroppers-data@psg.com; Fri, 22 Aug 2008 01:56:31 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWLt4-0001dI-Rg for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 01:56:28 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7M1uAtD061344; Fri, 22 Aug 2008 11:56:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808220156.m7M1uAtD061344@drugs.dv.isc.org> To: Ted Lemon Cc: Masataka Ohta , Mohsen Souissi , Paul Vixie , "namedroppers@ops.ietf.org" From: Mark Andrews Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR In-reply-to: Your message of "Thu, 21 Aug 2008 18:23:17 MST." Date: Fri, 22 Aug 2008 11:56:10 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On Aug 21, 2008, at 5:56 PM, Masataka Ohta wrote: > > Today, though TTL could be more than 1 second, which is already > > quite unlikely, > > I measured ping times to my home server at as much as 40 seconds > during the most recent IETF meeting. Arguably, we could describe > this as an outage. But unfortunately, there exist networks where > routers are configured with excessive buffering, or where the layer > two erroneously provides reliability. On such networks, when there > is congestion, long round trip times are actually quite common. As are the inter arrival times for fragments. > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 19:38:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37AD228C1BD; Thu, 21 Aug 2008 19:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.012 X-Spam-Level: *** X-Spam-Status: No, score=3.012 tagged_above=-999 required=5 tests=[AWL=0.957, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 aslRCIVTgYiA; Thu, 21 Aug 2008 19:38:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 563C628C1B5; Thu, 21 Aug 2008 19:38:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWMRt-0007wy-KE for namedroppers-data@psg.com; Fri, 22 Aug 2008 02:32:25 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWMRp-0007w1-Ad for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 02:32:23 +0000 Received: (qmail 11963 invoked from network); 22 Aug 2008 02:38:36 -0000 Received: from softbank219001188017.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.17) by necom830.hpcl.titech.ac.jp with SMTP; 22 Aug 2008 02:38:36 -0000 Message-ID: <48AE2534.8060407@necom830.hpcl.titech.ac.jp> Date: Fri, 22 Aug 2008 11:32:20 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Mark Andrews CC: Ted Lemon , Mohsen Souissi , Paul Vixie , "namedroppers@ops.ietf.org" Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR References: <200808220156.m7M1uAtD061344@drugs.dv.isc.org> In-Reply-To: <200808220156.m7M1uAtD061344@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: >>I measured ping times to my home server at as much as 40 seconds >>during the most recent IETF meeting. Arguably, we could describe >>this as an outage. But unfortunately, there exist networks where >>routers are configured with excessive buffering, or where the layer >>two erroneously provides reliability. On such networks, when there >>is congestion, long round trip times are actually quite common. > As are the inter arrival times for fragments. That they are not even covered by the default reassembly timeout means that we don't have to consider cases with wrongly large buffers. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 20:22:24 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9F283A6921; Thu, 21 Aug 2008 20:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 XKuzWU9iUYSo; Thu, 21 Aug 2008 20:22:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CF123A67F1; Thu, 21 Aug 2008 20:22:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWN8Q-000FZg-G3 for namedroppers-data@psg.com; Fri, 22 Aug 2008 03:16:22 +0000 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWN8M-000FZC-6Z for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 03:16:19 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 21 Aug 2008 20:13:12 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 018DC1A8203; Thu, 21 Aug 2008 20:13:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Thu, 21 Aug 2008 20:13:11 -0700 CC: "namedroppers@ops.ietf.org WG" Message-ID: From: Ted Lemon To: Masataka Ohta In-Reply-To: <48AE2534.8060407@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR Date: Thu, 21 Aug 2008 20:13:09 -0700 References: <200808220156.m7M1uAtD061344@drugs.dv.isc.org> <48AE2534.8060407@necom830.hpcl.titech.ac.jp> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 21, 2008, at 7:32 PM, Masataka Ohta wrote: > That they are not even covered by the default reassembly timeout > means that we don't have to consider cases with wrongly large > buffers. I think here we are speculating from nonexistent or anecdotal data. My general experience has been that where the network is basically working, but somewhat misconfigured, delays of up to 10 seconds are not uncommon. The IETF network in Dublin is the first one I've been on where I've seen a response after 40 seconds. I was quite astonished. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 21 22:59:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F82F3A67D2; Thu, 21 Aug 2008 22:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] 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 7841rq7gQBZz; Thu, 21 Aug 2008 22:59:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31D1B3A6768; Thu, 21 Aug 2008 22:59:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWPZn-000HYH-HP for namedroppers-data@psg.com; Fri, 22 Aug 2008 05:52:47 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWPZf-000HRf-IE for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 05:52:44 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7M5qJBq064879; Fri, 22 Aug 2008 15:52:20 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808220552.m7M5qJBq064879@drugs.dv.isc.org> To: Michael Renner Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: SCTP (and DCCP) In-reply-to: Your message of "Fri, 22 Aug 2008 01:00:44 +0200." <48ADF39C.20600@amd.co.at> Date: Fri, 22 Aug 2008 15:52:19 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Paul Vixie wrote: > > > i see five reasons why SCTP is worth looking at as a primary transport with > > UDP as its fallback. first, data transfer can take place in the second > > round trip (packets 3 and 4). second, it has 32-bit ID fields so we could > > go back to fixed port numbers perhaps even fixed+increment on TXID's. > > third, we could mandate EDNS, and with it, we could mandate PING. fourth, > > SCTP has the idea of "passive" sockets which mean nonquadratic socket pool > > sizes. fifth, association timeout is handled in the stack not the app. > > > All the things you talk about are engineering problems which are already > solved this day. > > > It's no big issue these days to serve thousands of clients, be it TCP or > UDP. See [1] for common solutions to the problems, and [2] for > benchmarks in this area. Nowadays the amount of clients you can serve in > parallel are only limited by the amount of memory you've got for the > respective data structures and the performance of the operations which > are needed to traverse said data structures. RAM is cheap to come by, > and at least since fefe has pointed out outstanding issues in > implementations, every major OS should scale fine. The problem is not so much the server side. It's the client side of the recursive nameserver. You have to deal with running out of local ports especially when you need to lock down the source address. Plain bind() + connect() won't scale. I suppose one could choose a single local source port then set SO_REUSEADDR before binding to the local address and port but then you can only have one socket in this state until you call connect. If you have multiple queries to the same server you have to do one or both of: * choose a new local port that is not being used to talk to the remote server * or multiplex your queries down the one socket > If your application isn't designed for such a task it takes a bit of > refactoring and a few hours back at the architecture board, but it is > feasible. Please do not try to design the protocols around your current > implementation but around current engineering standards. > > > There's no need to go back to static source ports, the implementations > which are out there work quite fine. You could also mandate (or > "SHOULD", in RFC-speak) PING by now with the current UDP/TCP > infrastructure, it just needs a common vision and a common goal. If you > get the few major DNS vendors out there to support your cause, > everything should be fine (tm) in a few years worth (and much earlier > for those installations were people actually care about DNS). > > > > i see two gigantic challenges for ANY non-UDP transport: installed base of > > DNS protocol agents; installed base of firewalls and NATs and middleboxes. > > Whereas changes in the TCP direction are much easier to come by than > SCTP/DCCP or any different "newfangled" protocol which installed base is > tremendeously exceeded by the amount of IPv6 production hosts ;). > > Michael > > [1] http://www.kegel.com/c10k.html > [2] http://bulk.fefe.de/scalability/ > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 00:05:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7AE3A67D2; Fri, 22 Aug 2008 00:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, 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 Z7ylfNBSvpxH; Fri, 22 Aug 2008 00:05:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0437D3A6403; Fri, 22 Aug 2008 00:05:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWQZx-0004UW-2l for namedroppers-data@psg.com; Fri, 22 Aug 2008 06:57:01 +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 ) id 1KWQZs-0004Ty-Jc for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 06:56:59 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KWQZo-0003b6-Sf for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 08:56:52 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 619AF53830; Fri, 22 Aug 2008 08:57:05 +0200 (CEST) Date: Fri, 22 Aug 2008 08:57:04 +0200 From: bert hubert To: Mark Andrews Cc: Michael Renner , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: SCTP (and DCCP) Message-ID: <20080822065704.GJ14116@outpost.ds9a.nl> References: <48ADF39C.20600@amd.co.at> <200808220552.m7M5qJBq064879@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808220552.m7M5qJBq064879@drugs.dv.isc.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 22, 2008 at 03:52:19PM +1000, Mark Andrews wrote: > The problem is not so much the server side. It's the client > side of the recursive nameserver. You have to deal with > running out of local ports especially when you need to lock > down the source address. Plain bind() + connect() won't > scale. Fwiw, both dnscache (djbdns) and powerdns have been working with bound() and connect()ed udp sockets for many years now. So this problem does not appear to be an issue in the real world. 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 01:30:17 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0356C28C0CE; Fri, 22 Aug 2008 01:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 IuTdB9JHtT-S; Fri, 22 Aug 2008 01:30:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13B1F3A6765; Fri, 22 Aug 2008 01:30:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWRvv-000NLF-J2 for namedroppers-data@psg.com; Fri, 22 Aug 2008 08:23:47 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWRvr-000NDE-0y for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 08:23:44 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7M8NM4O066971; Fri, 22 Aug 2008 18:23:23 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808220823.m7M8NM4O066971@drugs.dv.isc.org> To: bert hubert Cc: Michael Renner , Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: SCTP (and DCCP) In-reply-to: Your message of "Fri, 22 Aug 2008 08:57:04 +0200." <20080822065704.GJ14116@outpost.ds9a.nl> Date: Fri, 22 Aug 2008 18:23:22 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On Fri, Aug 22, 2008 at 03:52:19PM +1000, Mark Andrews wrote: > > The problem is not so much the server side. It's the client > > side of the recursive nameserver. You have to deal with > > running out of local ports especially when you need to lock > > down the source address. Plain bind() + connect() won't > > scale. > > Fwiw, both dnscache (djbdns) and powerdns have been working with bound() and > connect()ed udp sockets for many years now. > > So this problem does not appear to be an issue in the real world. > > Bert I've been told unbound only has a maximum of 1000 active sockets and if you get more than that many outstanding recursive queries it stalls the new queries. I havn't looked at how djbdns deals with lots of simultanous queries. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 03:59:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE5C3A67EE; Fri, 22 Aug 2008 03:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 NVy60NfMcJNE; Fri, 22 Aug 2008 03:59:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFBA33A6959; Fri, 22 Aug 2008 03:59:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWUGQ-0001eo-MI for namedroppers-data@psg.com; Fri, 22 Aug 2008 10:53:06 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWUGM-0001eJ-1j for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 10:53:04 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m7MAquEU069713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Aug 2008 12:52:56 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <48AE9A88.5040707@nlnetlabs.nl> Date: Fri, 22 Aug 2008 12:52:56 +0200 From: Wouter Wijngaards User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Namedroppers Subject: Re: SCTP (and DCCP) References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> In-Reply-To: <49938.1219339836@nsa.vix.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 22 Aug 2008 12:52:56 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: > nominum, powerdns, and unbound are probably doing more than port > randomization. perhaps you can all three explain what you're doing, in > detail, so that the WG can decide whether those are reasonable things to > recommend to the rest of the community. I am going to document the countermeasures I envision (in addition to DNSSEC) for Unbound in a draft (as the wg chairs ask). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiumogACgkQkDLqNwOhpPjJ5gCfV8P0lfPFUaQ8VAb119pS8U5w aSEAoI3SHmNu3IjOGB9MMDJSltSB2ZD9 =0hmK -----END PGP SIGNATURE----- -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 09:17:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BFC3A6948; Fri, 22 Aug 2008 09:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] 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 L2b1+wcg70WR; Fri, 22 Aug 2008 09:17:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4730E3A677D; Fri, 22 Aug 2008 09:17:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWZCm-000FOo-Oq for namedroppers-data@psg.com; Fri, 22 Aug 2008 16:09:40 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWZCj-000FOO-0E for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 16:09:38 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7CF5FA6529; Fri, 22 Aug 2008 16:09:32 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Wouter Wijngaards cc: Namedroppers In-Reply-To: Your message of "Fri, 22 Aug 2008 12:52:56 +0200." <48AE9A88.5040707@nlnetlabs.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <48AE9A88.5040707@nlnetlabs.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 22 Aug 2008 16:09:32 +0000 Message-ID: <59927.1219421372@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 7CF5FA6529.8B870 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: SCTP (and DCCP) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > nominum, powerdns, and unbound are probably doing more than port > > randomization. perhaps you can all three explain what you're doing, in > > detail, so that the WG can decide whether those are reasonable things to > > recommend to the rest of the community. > > I am going to document the countermeasures I envision (in addition to > DNSSEC) for Unbound in a draft (as the wg chairs ask). that would be great. it's my view that while implementors should of course innovate, there has to be a documented standard, which is testable for both interoperability and correctness, and which represents an adequate implementation level for what we used to call "forgery resilience". so while i'll be happy to see descriptions of what each implementor is doing, and i agree with ted lemon that any form of "not wanting to discuss it in public" is counterproductive, the end result has to be guidance to future implementors. in that sense, we know that randomizing the DNS-TXID and UDP-SRCPORT isn't good enough, and so we have work to do. beginning that work with a survey of methods now in practice would be good, but the end result has to be a description of either a set of methods which are considered adequate, or a set of attacks which a conformant implementation must be able to resist, or both. it's in that sense that i consider DNSSEC the final solution (since it handles end-to-end attacks whether on- or off-path), and in which i would consider PING, TCP, or SCTP partial solutions (since they only handle off-path attacks). whereas a laundry list of small things which implementors could do and which some implementors are doing, is not a testable standard for new implementors. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 09:18:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57413A682D; Fri, 22 Aug 2008 09:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 rlnU3H1p+4np; Fri, 22 Aug 2008 09:18:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D6663A67E3; Fri, 22 Aug 2008 09:18:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWZGQ-000GPy-Mc for namedroppers-data@psg.com; Fri, 22 Aug 2008 16:13:26 +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 ) id 1KWZGL-000GOx-Uk for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 16:13:24 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7MGDJa8097100 for ; Fri, 22 Aug 2008 12:13:20 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.2/8.14.2/Submit) id m7MGDJbj097099 for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 12:13:19 -0400 (EDT) (envelope-from namedroppers) Received: from [208.87.233.190] (helo=cluster-g.mailcontrol.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWVFT-000Esb-RQ for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 11:56:14 +0000 Received: from emsv.co.uk ([84.234.24.63]) by rly21g.srv.mailcontrol.com (MailControl) with SMTP id m7MBu52E032377 for ; Fri, 22 Aug 2008 12:56:06 +0100 From: "George Barwood" To: Message-ID: <15CBB956E5654625A795DE2D8269A1A1@localhost> Subject: Defending against the Kaminsky attack Date: Fri, 22 Aug 2008 12:55:58 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 MIME-Version: 1.0 Organization: Education and Media Services Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C90456.6C086D80" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 X-Scanned-By: MailControl A-08-50-13 (www.mailcontrol.com) on 10.71.0.131 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This is a mime multipart message ------=_NextPart_000_006B_01C90456.6C086D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was wondering whether the Kaminsky attack can be defeated by methods othe= r than adding more entropy. I think it can. These thoughts are preliminary, came to me in my sleep last= night, so I may be mistaken. o Attack Generate multiple questions type=3DA x1.bigbank.com type=3DA x2.bigbank.com type=3DA x3.bigbank.com .... Cache asks ns1.bigbank.com for each.=20 Bailiwick is bigbank.com. Spoof response is: Question x1.bigbank.com Answers: Empty Authority: NS for bigbank.com is ns1.bigbank.com Additional: Host for ns1.bigbank.com is 10.0.0.99 ( IP address under cont= rol of attacker ) Is this suspicious? Yes. Authority record is not required, Bailiwick =3D LHS of authority rec= ord. LHS of NS record should be properly within Bailiwick, this one isn't, it = is equal. So record is invalid and should be discarded. Ok, what about this: Question x1.bigbank.com Answers: Empty Authority: NS for x1.bigbank.com is ns1.bigbank.com Additional: Host for ns1.bigbank.com is 10.0.0.99* ( attacker's IP addres= s ) Is this suspicious? Authority record is now ok.=20 But glue record is not.=20 Glue records should only be accepted if they LHS matches RHS of valid Aut= hority record that needs glue. An authority record needs glue iff it is of form NS for xxxxx is somethin= g.xxxxx So, resolvers should make these checks. Apologies in advance if this turns out to be nonsense, or is already well k= nown. I have not tested it, and am not sure if there are any implications for sta= ndards. George Barwood= ------=_NextPart_000_006B_01C90456.6C086D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I was wondering whether the Kaminsky attac= k can be=20 defeated by methods other than adding more entropy.
 
I think it can. These thoughts are prelimi= nary,=20 came to me in my sleep last night, so I may be mistaken.
 
o Attack
  Generate multiple=20 questions
  type=3DA x1.bigbank.com
  type=3DA=20 x2.bigbank.com
  type=3DA x3.bigbank.com
  ....
  C= ache=20 asks ns1.bigbank.com for each.
  Bailiwick is bigbank.com.
 = Spoof=20 response is:
  Question x1.bigbank.com
  Answers:=20 Empty
  Authority: NS for bigbank.com is ns1.bigbank.com
 = =20 Additional: Host for ns1.bigbank.com is 10.0.0.99 ( IP address under= =20 control of attacker )
 
  Is this suspicious?
  Yes. = Authority=20 record is not required, Bailiwick =3D LHS of authority record.
  LH= S of NS=20 record should be properly within Bailiwick, this one isn't, it is=20 equal.
  So record is invalid and should be= =20 discarded.
 
  Ok, what about this:
  Ques= tion=20 x1.bigbank.com
  Answers: Empty
  Authority: NS for=20 x1.bigbank.com is ns1.bigbank.com
  Additional: Host for ns1.bigban= k.com=20 is 10.0.0.99* ( attacker's IP address )
 
  Is this suspicious?
  Autho= rity=20 record is now ok.
  But glue record is not.
  Glue record= s=20 should only be accepted if they LHS matches RHS of valid Authority record t= hat=20 needs glue.
  An authority record needs glue iff it is of form NS f= or=20 xxxxx is something.xxxxx
 
So, resolvers should make these=20 checks.
 
Apologies in advance if this turns out to = be=20 nonsense, or is already well known.
 
I have not tested it, and am not sure if t= here are=20 any implications for standards.
 
George=20 Barwood


  

------=_NextPart_000_006B_01C90456.6C086D80-- -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 09:30:54 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78863A67B4; Fri, 22 Aug 2008 09:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 Jn-5P32Qsd9I; Fri, 22 Aug 2008 09:30:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A44083A6768; Fri, 22 Aug 2008 09:30:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWZSK-000IFm-Or for namedroppers-data@psg.com; Fri, 22 Aug 2008 16:25:44 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWZSG-000IF9-Ph for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 16:25:42 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7MGPbqv009827; Fri, 22 Aug 2008 09:25:39 -0700 (PDT) Message-Id: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> From: Nicholas Weaver To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Defining defense levels... Date: Fri, 22 Aug 2008 09:25:37 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: One thought (again, I don't know how much this has been hashed out) is how robust do DNS resolvers REALLY need to be? Any comments on the following? I personally believe that resolvers should be robust to anything short of a man-in-the-middle ("Aware & Blocking"), yet man-in-the-middle is almost irrelevant for purposes of defending DNS. [1] Thus as long as the DNS resolvers are strong to anything short of the man-in-the- middle, its good in practice. At the same time, such robustness must ONLY involve changes to the resolvers: the resolvers should be able to protect themselves, without relying on the authoritative servers making changes (although authoritative servers may suffer more load, especially servers which return some out-of-standard nonsenses.). [2] And probabilistic protection is perfectly good. We don't need perfect protection against blind attacks, we just need to ensure that the attacker resources involved are far better spent elsewhere. My thoughts: Against blind attacks, I believe the following principles should apply: a) No birthday attacks, of course. b) >=20b of entropy for purposes of protecting the transaction [3] c) >=40b of entropy for purposes of protecting the cache [4] d) Detecting when network entropy (port #) is reduced or eliminated by an in-path network device, allowing the resolver to accurately estimate the entropy it is generating in the requests. e) Detect and respond when there is .001% of a chance that a blind attack created one or more corrupt cache entries by either revalidating or voiding the cache. f) NO "race until win" scenarios for ANY given mapping in the cache. ALL blind attacks should be either "Race once per TTL" or "Race until another race until win". Blind attacks should always cost time as well a packets. [5] ALL of the previous principles seem doable using existing techniques (port and 0x20 randomization, duplication, a single global counter to count unsolicited replies, and some seemingly simple data acceptance policies) Against transparent attacks, I believe the following should apply: If a resolver, within its normal transaction timeout, receives a second reply with a differing value but which would have been otherwise accepted (matching on TXID, port, server, 0x20, etc), this must be considered an attack on both the transaction and the cache. [6] If the resolver is an intermediary, it MUST forward the second response back to the original requester, with the TTL for the "new" value set to 1 second. For the resolver's cache, any entry which MAY have been potentially affected by the second reply MUST be treated as corrupted by an attack. Thus, depending on how much information is recorded and available, various cache entries may need to be voided or undone (up to all cache entries for the domain in question, if more precise record keeping is unavailable). Even if this would not be considered an attack, it doesn't actually make sense to cache anything which may have been dependent on this response. For the final client, it is up to the client to determine what to do, but the strong suggestion is to consider this an attack and abort any transaction involving this name. However, if the end client does not treat this as an attack and abort subsequent TCP connections to the final IP, this loss of transaction protection means that the few authorities which trigger this alert through "normal" behavior will simply see their results not cached rather than not accepted by the client. [1] If an attacker can man-in-the-middle the naming stream of a victim, he can probably man-in-the-middle the data stream. If the end protocol desired is weak to a man-in-the-middle, reliable naming does no good. If the end protocol is robust to a man-in-the-middle, it never really trusted the DNS record. [2] This is why I'm not a believer in DNSSEC. It has both bad network effects (both the resolver and authority needs to change behavior, yet the changed behavior only protects the intersection of the two sets, so neither resolvers nor authorities have strong internal incentives to deploy), yet does not actually provide, to my mind, all that much meaningful system security because the other options available to a man-in-the-middle in practice. [3] Blind transaction attacks, when combined with protections that provide "race once per TTL per name", as far as I can tell, only work against some seriously broken protocols. By specifying a different level of protection for transactions and the cache, this allows duplication to protect the cache while still successfully resolving (but NOT caching) sites which return different values on back-to-back queries when duplication is needed to meet the entropy budget. [4] Anyone who wants to launch a TB DOS to poison my cache has better things to do. [5] I believe that the proper policy on accepting data into the cache can provide this, combined with treating a failure to lookup a name as an event with a ~30 second TTL. This property is an important COMPLEMENT to increased entropy, not a substitute. "Race until win" does not reduce the number of packets an attacker requires, only the time period. [6] This will occur with high probability whenever there is a blind attack that doesn't also block the authoritative server or create traffic with a DOS condition. It will ALSO occur with high probability if an attacker is able to directly observe the request to craft a reply, but is not fully in path. More importantly, a preliminary survey survey suggests that only a few authorities actually do return such nonsense. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 11:19:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBFE3A6A8E; Fri, 22 Aug 2008 11:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 cIzC9ckDm7VR; Fri, 22 Aug 2008 11:19:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF6F03A6A8C; Fri, 22 Aug 2008 11:19:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWb9Z-000HPL-RO for namedroppers-data@psg.com; Fri, 22 Aug 2008 18:14:29 +0000 Received: from [64.18.2.171] (helo=exprod7og109.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWb9U-000HGS-UT for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 18:14:27 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 11:14:23 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 81B3B1A8206 for ; Fri, 22 Aug 2008 11:14:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 22 Aug 2008 11:14:23 -0700 Message-ID: From: Ted Lemon To: Namedroppers In-Reply-To: <59927.1219421372@nsa.vix.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Active countermeasures (threat or danger?) Date: Fri, 22 Aug 2008 11:14:21 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <48AE9A88.5040707@nlnetlabs.nl> <59927.1219421372@nsa.vix.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 9:09 AM, Paul Vixie wrote: >> I am going to document the countermeasures I envision (in addition to >> DNSSEC) for Unbound in a draft (as the wg chairs ask). > > that would be great. Dan raised the point on his blog recently that active countermeasures have the problem that they make a great avenue for denial-of-service attacks. Seems like something worth keeping in mind. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 11:27:10 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005BD28C0F1; Fri, 22 Aug 2008 11:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.218 X-Spam-Level: X-Spam-Status: No, score=-5.218 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 CUFBFrGVnfgZ; Fri, 22 Aug 2008 11:27:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D0F128C0EB; Fri, 22 Aug 2008 11:27:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbIF-000JKy-H3 for namedroppers-data@psg.com; Fri, 22 Aug 2008 18:23:27 +0000 Received: from [64.18.2.157] (helo=exprod7og102.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbIC-000JK3-1m for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 18:23:25 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 11:23:22 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id E4D3C1A8203; Fri, 22 Aug 2008 11:23:22 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 22 Aug 2008 11:23:22 -0700 CC: "namedroppers@ops.ietf.org" Message-ID: <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> From: Ted Lemon To: Nicholas Weaver In-Reply-To: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 11:23:22 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 9:25 AM, Nicholas Weaver wrote: > And probabilistic protection is perfectly good. We don't need perfect > protection against blind attacks, we just need to ensure that the > attacker resources involved are far better spent elsewhere. This isn't strictly true, because there are on-path non-cache- poisoning attacks to DNS that are not MitM attacks but that let me reliably MitM your HTTP connections. And these attacks are easily prevented with DNSSEC, and completely unpreventable with, e.g., port randomization. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 11:27:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9EFF28C0F1; Fri, 22 Aug 2008 11:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.04 X-Spam-Level: X-Spam-Status: No, score=-99.04 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 LfTfDemeoTqk; Fri, 22 Aug 2008 11:27:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B59703A6943; Fri, 22 Aug 2008 11:27:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbI1-000JIy-VJ for namedroppers-data@psg.com; Fri, 22 Aug 2008 18:23:13 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbHx-000JIU-SS for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 18:23:11 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 854A133C59; Fri, 22 Aug 2008 11:23:09 -0700 (PDT) Date: Fri, 22 Aug 2008 11:23:09 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bert hubert Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: how to spoof . by Kaminsky's method (Re: Agile countermeasures) In-Reply-To: References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080821213512.GF14116@outpost.ds9a.nl> <20080821220438.GH14116@outpost.ds9a.nl> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 21 Aug 2008 15:12:07 -0700, JINMEI Tatuya wrote: > > > - the recursive server replaces the forged NS RRset with the > > > legitimate one: > > > . IN NS [a-m].root-servers.net. > > > > Well, you could do that - hardcode the list of root-servers. Is that what > > people do? > > Oops, I meant: > > - the recursive server replaces the legitimate NS RRset for . > (which is normally) . IN NS [a-m].root-servers.net. > with the forged NS RRset > > Is this what you had in your mind? I've been hoping someone enlightens me, but there seems to be no luck. So I'll continue speculating... I've missed "answers" in the example given before: : Send queries for '1.', '2.', '3.', '4.' etc to a resolver. In the meantime, : blast it with answers for '1.', '2.' etc with new NS records of your choosing : for '.'. Be sure to pick the source address of the nearest root-server. so the intent is perhaps this one: - the attacker (somehow) force the recursive server to send a query for (e.g.) '1. IN AAAA' - then the attacker sends a forged response as follows: question: 1. IN AAAA answer 1. IN AAAA 2001:db8::1234 authority: . IN NS evil.example. additional: evil.example. AAAA 2001:db8::1 - the recursive server replaces the legitimate NS RRset for . (which is normally) . IN NS [a-m].root-servers.net. with the forged NS RRset, possibly with the additional AAAA RRset (Un)fortunately, this attack succeeds only in a very limited situation as long as the recursive server performs "priming" (as described in draft-koch-dnsop-resolver-priming-00) and follows the data ranking concept described in Section 5.4.1 of RFC2181: the recursive server should have a cached entry of "./NS" at the data rank of "The authoritative data included in the answer section of an authoritative reply" as a result of priming, while the rank of the forged authority section is "Data from the authority section of an authoritative answer". So, the forged response cannot unconditionally replace the existing cache. This is one major difference for "." from any other domains. The attacker could wait for the expiration of the high-rank cache; however, the first query (which may or may not be caused by the attacker) after the expiration will immediately trigger the next priming and the high-rank data is soon cached again, so the possible attackable window is very limited. This is another major difference for "." (+ the notion of priming) from any other names in the context of Kaminsky's attack. Of course, this defense depends on whether implementation diligently performs priming and follows the data ranking rule of RFC2181. One implementation that I know very well behaves that way (I've actually confirmed that by "attacking it" based on the above scenario); as far as I can confirm, that's the only implementation that meets this requirement, though. In any event, this is probably a different attack scenario from what you were thinking when you said this: : 3) DNS-0x20 - although that doesn't protect the vital and scary . and COM : records from numerical kaminsky attacks. I'm very much interested in knowing that (if it's not secret:-). --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 11:42:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C260F3A6876; Fri, 22 Aug 2008 11:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.823 X-Spam-Level: X-Spam-Status: No, score=-4.823 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 g8FS2k7jTZTs; Fri, 22 Aug 2008 11:42:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B16F3A67CC; Fri, 22 Aug 2008 11:42:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbVx-000LqH-Ff for namedroppers-data@psg.com; Fri, 22 Aug 2008 18:37:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbVt-000Lpp-DT for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 18:37:35 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7MIb6t2024020; Fri, 22 Aug 2008 11:37:30 -0700 (PDT) Cc: Nicholas Weaver , "namedroppers@ops.ietf.org" Message-Id: <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Ted Lemon In-Reply-To: <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 11:37:06 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 11:23 AM, Ted Lemon wrote: > On Aug 22, 2008, at 9:25 AM, Nicholas Weaver wrote: >> And probabilistic protection is perfectly good. We don't need >> perfect >> protection against blind attacks, we just need to ensure that the >> attacker resources involved are far better spent elsewhere. > > This isn't strictly true, because there are on-path non-cache- > poisoning attacks to DNS that are not MitM attacks but that let me > reliably MitM your HTTP connections. And these attacks are easily > prevented with DNSSEC, and completely unpreventable with, e.g., port > randomization. Those are "Aware" attackers, NOT blind attackers in the taxonomy I'm pushing, as they know the entropy of the request. See http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01459.html for the taxonomy I'm using. For such an attacker, the question is, are they "Transparent" or "Blocking": able to squelch the legitimate reply? An Aware, Blocking attacker IS almost certainly a man in the middle (or a packet snoop who's also DOSing the authority with enough traffic that the requests fail, who you might as well call a MitM). Such an attacker can just as easily directly MITM your TCP stream in almost all cases, because the path for the naming is almost certainly the path for the data. An Aware, Transparent attacker (eg, a typical packet injector) you CAN detect by looking for mismatched responses: where you get two responses to the same query but with different values. You can also MITIGATE such attack's damage to the cache, and NOTIFY the end client. We used such a technique very successfully to detect injected TCP Reset packets, and if applied to DNS, the number of authoritative servers which return two responses to the same query but with different answers is VERY low. And if the client is suitably paranoid, can treat as an attack in progress. The probability of detecting being just the probability that the legitimate response is returned by the authoritative server. This is why I try to be precise about taxonomy. Or is there some form of attacker who's not blind but doesn't know the entropy of the request? What holes are there in the following two axes of taxonomy: Blind vs Aware: Does the attacker have to guess or does he know the entropy of the request? Transparent vs Blocking: Is the legitimate response processed and returned by the legitimate authority, or is the attacker able to block the legitimate request processing? And which attackers are "Aware" (see the packets, assuming a good server), "Blocking" (able to block the request) other than either a full man-in-the-middle on your DNS flows or someone snooping packets on your DNS flows who's also creating/taking advantage of a DOS situation? -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 11:46:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6979F3A6876; Fri, 22 Aug 2008 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 KtpAThSAFh3g; Fri, 22 Aug 2008 11:46:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 495283A6A1F; Fri, 22 Aug 2008 11:46:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbaU-000Mlf-Nx for namedroppers-data@psg.com; Fri, 22 Aug 2008 18:42:18 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbaQ-000Ml0-IX for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 18:42:16 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7MIg81N024563; Fri, 22 Aug 2008 11:42:08 -0700 (PDT) Cc: Nicholas Weaver , Namedroppers Message-Id: From: Nicholas Weaver To: Ted Lemon In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Active countermeasures (threat or danger?) Date: Fri, 22 Aug 2008 11:42:08 -0700 References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <48AE9A88.5040707@nlnetlabs.nl> <59927.1219421372@nsa.vix.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 11:14 AM, Ted Lemon wrote: > On Aug 22, 2008, at 9:09 AM, Paul Vixie wrote: >>> I am going to document the countermeasures I envision (in addition >>> to >>> DNSSEC) for Unbound in a draft (as the wg chairs ask). >> >> that would be great. > > Dan raised the point on his blog recently that active > countermeasures have the problem that they make a great avenue for > denial-of-service attacks. Seems like something worth keeping in > mind. You can and should bound these. EG, if your active countermeasure is draconian (flush or revalidate the cache) when the attacker has a . 001% chance of putting in one or more bad entries in a blind manner, by maintaning a simple count: For 32b entropy for cached transactions, it doesn't work. With a relatively small number of packets (less than 10,000), you'd cause a cache flush/revalidate. Owch. For 40b entropy for cached transactions, it can work fine. Now the attacker needs 10M packets. If your cache has only 1M entries active that you reload, this hardly seems economical as a DOS attack. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 11:57:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E787E28C168; Fri, 22 Aug 2008 11:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.176 X-Spam-Level: X-Spam-Status: No, score=-5.176 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 kgf3o+EzeLkj; Fri, 22 Aug 2008 11:57:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9A1D28C167; Fri, 22 Aug 2008 11:57:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWblb-000P3A-Dq for namedroppers-data@psg.com; Fri, 22 Aug 2008 18:53:47 +0000 Received: from [64.18.2.171] (helo=exprod7og109.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWblQ-000P15-8u for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 18:53:40 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 11:53:08 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id C6FB11A8207; Fri, 22 Aug 2008 11:53:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 22 Aug 2008 11:53:08 -0700 CC: "namedroppers@ops.ietf.org" Message-ID: From: Ted Lemon To: Nicholas Weaver In-Reply-To: <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 11:53:06 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 11:37 AM, Nicholas Weaver wrote: > An Aware, Transparent attacker (eg, a typical packet injector) you CAN > detect by looking for mismatched responses: where you get two > responses to the same query but with different values. You can also > MITIGATE such attack's damage to the cache, and NOTIFY the end client. This only works if the attacker follows the rules. If the attacker jams the 802.11g network during the time when the response is expected, you'll see a short stutter in the network, and probably not notice it. And since the jamming happened at the link layer, it will just look to the resolver like no packets arrived except the attacker's packets. I suspect that producing a jammer that could be finely controlled in this way would be about a day's work for a knowledgeable practitioner. My point being that this is not at all an expensive attack. It's something I could do on the IETF meeting network and probably completely escape notice. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 12:15:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E963A3A6A6A; Fri, 22 Aug 2008 12:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.873 X-Spam-Level: X-Spam-Status: No, score=-4.873 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 Li7+55qRL18i; Fri, 22 Aug 2008 12:15:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B2E3D3A67B4; Fri, 22 Aug 2008 12:15:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbzt-0001mW-TQ for namedroppers-data@psg.com; Fri, 22 Aug 2008 19:08:33 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWbzp-0001li-LE for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 19:08:31 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7MJ8SEJ027642; Fri, 22 Aug 2008 12:08:28 -0700 (PDT) Cc: Nicholas Weaver , "namedroppers@ops.ietf.org" Message-Id: <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Ted Lemon In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 12:08:27 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 11:53 AM, Ted Lemon wrote: > On Aug 22, 2008, at 11:37 AM, Nicholas Weaver wrote: >> An Aware, Transparent attacker (eg, a typical packet injector) you >> CAN >> detect by looking for mismatched responses: where you get two >> responses to the same query but with different values. You can also >> MITIGATE such attack's damage to the cache, and NOTIFY the end >> client. > > This only works if the attacker follows the rules. If the attacker > jams the 802.11g network during the time when the response is > expected, you'll see a short stutter in the network, and probably > not notice it. And since the jamming happened at the link layer, > it will just look to the resolver like no packets arrived except the > attacker's packets. > > I suspect that producing a jammer that could be finely controlled in > this way would be about a day's work for a knowledgeable > practitioner. My point being that this is not at all an expensive > attack. It's something I could do on the IETF meeting network and > probably completely escape notice. > However, such a jammer can JUST AS EASILY be a MITM on the TCP stream itself! Thats my point. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 12:18:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4FB3A6A1F; Fri, 22 Aug 2008 12:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.159 X-Spam-Level: X-Spam-Status: No, score=-5.159 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 uDfnHykrJP9N; Fri, 22 Aug 2008 12:18:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A00513A68FB; Fri, 22 Aug 2008 12:18:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWc5Q-0003P0-1K for namedroppers-data@psg.com; Fri, 22 Aug 2008 19:14:16 +0000 Received: from [64.18.2.218] (helo=exprod7og116.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWc5I-0003JQ-DK for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 19:14:14 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 12:14:07 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 65DA21A8201; Fri, 22 Aug 2008 12:14:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 22 Aug 2008 12:14:06 -0700 CC: "namedroppers@ops.ietf.org" Message-ID: From: Ted Lemon To: Nicholas Weaver In-Reply-To: <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 12:14:05 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 12:08 PM, Nicholas Weaver wrote: > However, such a jammer can JUST AS EASILY be a MITM on the TCP stream > itself! No, in order to do this you'd have to jam continuously, which would be noticed. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 12:24:41 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFC13A68FB; Fri, 22 Aug 2008 12:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.891 X-Spam-Level: X-Spam-Status: No, score=-4.891 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 m16BRvzI6WVd; Fri, 22 Aug 2008 12:24:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B2713A67B4; Fri, 22 Aug 2008 12:24:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWcBG-0004Tj-Cy for namedroppers-data@psg.com; Fri, 22 Aug 2008 19:20:18 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWcB8-0004Sj-Rz for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 19:20:15 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7MJK9J8028880; Fri, 22 Aug 2008 12:20:09 -0700 (PDT) Cc: Nicholas Weaver , "namedroppers@ops.ietf.org" Message-Id: <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Ted Lemon In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 12:20:09 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 12:14 PM, Ted Lemon wrote: > On Aug 22, 2008, at 12:08 PM, Nicholas Weaver wrote: >> However, such a jammer can JUST AS EASILY be a MITM on the TCP stream >> itself! > > No, in order to do this you'd have to jam continuously, which would > be noticed. > Not really. A: End hosts don't notice currently: airpwn and Cookie Monster work just fine today. Write your own in Click, its easy! B: With the low latency of the local LAN vs remote behavior, I can launch the nice airpwning completely by the time the legit SYN gets back. C: I could just ARP cache poison you and MITM that way... D: I could DHCP poison you when you first connect and MITM that way... etc etc etc. Against an adversary on the local wireless network, you have to assume either full end-to-end crypto on the final application or you are sunk. Period In such a threat model, DNSSEC buys almost nothing. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 12:44:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7FF28C1A1; Fri, 22 Aug 2008 12:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 Wx+v8XcjaJMr; Fri, 22 Aug 2008 12:44:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 799B928C184; Fri, 22 Aug 2008 12:44:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWcV6-0009J0-H6 for namedroppers-data@psg.com; Fri, 22 Aug 2008 19:40:48 +0000 Received: from [64.18.2.171] (helo=exprod7og109.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWcV2-0009Gs-57 for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 19:40:46 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 12:40:36 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 37FDD1A8203; Fri, 22 Aug 2008 12:40:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 22 Aug 2008 12:40:35 -0700 CC: "namedroppers@ops.ietf.org" Message-ID: <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> From: Ted Lemon To: Nicholas Weaver In-Reply-To: <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 12:40:34 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 12:20 PM, Nicholas Weaver wrote: > Against an adversary on the local wireless network, you have to assume > either full end-to-end crypto on the final application or you are > sunk. Period Opportunites to jam DHCP are infrequent. Jamming an entire TCP stream is hard, and you only have to miss once to get caught. Jamming single DNS transactions is easy, and opportunities to do will be frequent. If you miss, you don't get caught - the traffic just goes through. What's nice about DNSSEC is that there's no user in the loop. To jam DNSSEC, you have to actually break the protocol - you can't just convince the user not to use it. It's true that SSL will protect you if you use it correctly, but whether or not you use correctly it depends on the user. I think you're seriously discounting the importance of human factors when you say that the security of the DNS channel doesn't matter. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 13:20:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFCBC3A69B0; Fri, 22 Aug 2008 13:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] 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 yQMxtdeRm83b; Fri, 22 Aug 2008 13:20:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBCB13A68E7; Fri, 22 Aug 2008 13:20:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWd43-000HhA-PK for namedroppers-data@psg.com; Fri, 22 Aug 2008 20:16:55 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWd3z-000HgG-7M for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 20:16:53 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E03B0A6680; Fri, 22 Aug 2008 20:16:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "George Barwood" cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 22 Aug 2008 12:55:58 +0100." <15CBB956E5654625A795DE2D8269A1A1@localhost> References: <15CBB956E5654625A795DE2D8269A1A1@localhost> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 22 Aug 2008 20:16:31 +0000 Message-ID: <2871.1219436191@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: E03B0A6680.2AAF4 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Defending against the Kaminsky attack Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: those are pattern-specific poison avoidances. i'd much rather we focus on not accepting the bad response than on not letting its content hurt us. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 13:21:16 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5FA83A69B0; Fri, 22 Aug 2008 13:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.342 X-Spam-Level: X-Spam-Status: No, score=-103.342 tagged_above=-999 required=5 tests=[AWL=3.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 T0+1XBsAN3QI; Fri, 22 Aug 2008 13:21:16 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 218323A67CC; Fri, 22 Aug 2008 13:21:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWd3L-000HC2-1y for namedroppers-data@psg.com; Fri, 22 Aug 2008 20:16:11 +0000 Received: from [74.95.2.169] (helo=kilo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWd3H-000HBW-63 for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 20:16:09 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 13EEA55089E; Fri, 22 Aug 2008 13:16:05 -0700 (PDT) Date: Fri, 22 Aug 2008 13:16:04 -0700 From: Eric Rescorla To: Ted Lemon Cc: Nicholas Weaver , "namedroppers@ops.ietf.org" Subject: Re: Defining defense levels... In-Reply-To: <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080822201605.13EEA55089E@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Fri, 22 Aug 2008 12:40:34 -0700, Ted Lemon wrote: At Fri, 22 Aug 2008 12:40:34 -0700, Ted Lemon wrote: > > On Aug 22, 2008, at 12:20 PM, Nicholas Weaver wrote: > > Against an adversary on the local wireless network, you have to assume > > either full end-to-end crypto on the final application or you are > > sunk. Period > > Opportunites to jam DHCP are infrequent. Jamming an entire TCP stream > is hard, and you only have to miss once to get caught. Jamming > single DNS transactions is easy, and opportunities to do will be > frequent. If you miss, you don't get caught - the traffic just goes > through. > > What's nice about DNSSEC is that there's no user in the loop. To jam > DNSSEC, you have to actually break the protocol - you can't just > convince the user not to use it. It's true that SSL will protect you > if you use it correctly, but whether or not you use correctly it > depends on the user. > > I think you're seriously discounting the importance of human factors > when you say that the security of the DNS channel doesn't matter. Without getting into some sort of huge SSL vs. DNSSEC debate, I'd be interested in hearing what you think "using it correctly" consists of. Do you mean that the SSL implementations allow the user to override things that look like security errors to the stack. If so, the stack could, of course, refuse to let you do anything it thought was unsafe (indeed, some older browsers did this) but experience indicates that users find this intolerable. If your argument is that DNSSEC is better because you don't get an opportunity to override the stack, I think there's some room for debate about whether that's really an improvement. -Ekr -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 13:39:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427CC3A68E7; Fri, 22 Aug 2008 13:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.23 X-Spam-Level: X-Spam-Status: No, score=-104.23 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 lb-PNSmZB1M2; Fri, 22 Aug 2008 13:39:31 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6EF763A681C; Fri, 22 Aug 2008 13:39:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWdKc-000Lpk-0w for namedroppers-data@psg.com; Fri, 22 Aug 2008 20:34:02 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWdKX-000LjP-Vh for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 20:34:00 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7MKXs1c005618; Fri, 22 Aug 2008 13:33:54 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <197C17EB-DA59-4455-87BF-37EB2CADBDF6@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Ted Lemon In-Reply-To: <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 13:33:53 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 12:40 PM, Ted Lemon wrote: > On Aug 22, 2008, at 12:20 PM, Nicholas Weaver wrote: >> Against an adversary on the local wireless network, you have to >> assume >> either full end-to-end crypto on the final application or you are >> sunk. Period > > Opportunites to jam DHCP are infrequent. Jamming an entire TCP > stream is hard, and you only have to miss once to get caught. > Jamming single DNS transactions is easy, and opportunities to do > will be frequent. If you miss, you don't get caught - the traffic > just goes through. Actually, its easy. You force the user to dissassociate and reassociate, there are attacks for that. Voila. Access point, DHCP, ARP, take your pick. You can spoof em all. And for most TCP attacks, you don't actually need to jam because the recipients aren't looking for mismatches. Spoof the SYN/ACK, chat away, and be happy. It works like a charm! Every time. As a bonus, since apart from the real SYN/ACK (which you CAN jam using your method), most remote systems won't actually send RST packets to these "unsolicited" data packets it sees, and even if they do, as long as you keep the data flowing, any RST will be out of sequence and ignored on the recipient. So you CAN actually MITM TCP, WITH a jamming property, against most systems in practice on the wireless network, because most won't send the RSTs that the packets say in the first place these days, so all you need to jam is the SYN/ACK > What's nice about DNSSEC is that there's no user in the loop. To > jam DNSSEC, you have to actually break the protocol - you can't just > convince the user not to use it. It's true that SSL will protect > you if you use it correctly, but whether or not you use correctly it > depends on the user. But, see the above, even with the fully secured NAME->IP mapping, you are still in the exact same position in your attack scenario: completely h0zed unless the user's actual protocol supports end-to-end crypto right. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 22 14:43:39 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18D93A6A66; Fri, 22 Aug 2008 14:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 sGynZKxaDGEU; Fri, 22 Aug 2008 14:43:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF6B73A6A5A; Fri, 22 Aug 2008 14:43:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWeJg-0009dA-8o for namedroppers-data@psg.com; Fri, 22 Aug 2008 21:37:08 +0000 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWeJc-0009a4-Kw for namedroppers@ops.ietf.org; Fri, 22 Aug 2008 21:37:06 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 22 Aug 2008 14:36:39 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 7750B1A8201; Fri, 22 Aug 2008 14:36:39 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Fri, 22 Aug 2008 14:36:38 -0700 CC: "namedroppers@ops.ietf.org" Message-ID: <5984BFAA-A451-4200-9350-DCB0066E476D@nominum.com> From: Ted Lemon To: Nicholas Weaver In-Reply-To: <197C17EB-DA59-4455-87BF-37EB2CADBDF6@ICSI.Berkeley.EDU> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Fri, 22 Aug 2008 14:36:37 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <197C17EB-DA59-4455-87BF-37EB2CADBDF6@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 22, 2008, at 1:33 PM, Nicholas Weaver wrote: > But, see the above, even with the fully secured NAME->IP mapping, you > are still in the exact same position in your attack scenario: > completely h0zed unless the user's actual protocol supports end-to-end > crypto right. On reflection, I think that I am arguing about the wrong thing. You're right that DNSSEC doesn't stop a MitM attack. A smart attacker would allow DNS to flow freely, and attack elsewhere, if they controlled your link to the rest of the world. To protect against this would require much more careful use of SSL than is common at present, and DNSSEC would not help. However, there's a case that you haven't really covered in your analysis. That's the case where the attacker gains control of the local cache. They don't have control of the path, but because they control the cache, they can convince you to send packets to them instead of to the correct destination. Your detection heuristics would completely fail here, because there's no competition between a blind or transparent attacker and the cache - the attacker *is* the cache. Also, you propose is that we just assume the answer we receive is correct, and abort the transaction if it turns out not to be. But the security handshake is probably finished at this point, and the private data has been leaked to the attacker. And we don't *know* that the data has leaked - we just think it has. So we're potentially going to be exposing the user to false positives that will train them to click through whatever warnings we might present. You could kludge around this a bit by choosing a wait time shorter than the maximum timeout, and not starting the transaction before that. But to get any degree of reliability, I think you'd have to introduce unacceptable delays. Also, you assume that the application designers will get it right. My app has to have a way of receiving an out-of-band notification from the resolver to tell me to abort the transaction, and I have to abort the transaction in a way that is appropriate to the circumstances, up to and including telling the user they need to change their password pronto. In the case of a web app, the engine that would have to make this decision (the browser) doesn't really even know the security model of the web app, so it's really not going to be able to give appropriate advice to the user. This window of opportunity introduces a degree of complexity to trusted apps that I think is unlikely to work in practice, even if it could work in theory. By contrast, if we validate the DNS response before we use it, we close off these windows of opportunity completely. We certainly do not eliminate all avenues of attack, but we do eliminate this one. -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 23 01:42:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7533A69FD; Sat, 23 Aug 2008 01:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, 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 PZ0SEfvlJhiZ; Sat, 23 Aug 2008 01:42:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 936EA3A6934; Sat, 23 Aug 2008 01:42:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWoVd-000PoR-QA for namedroppers-data@psg.com; Sat, 23 Aug 2008 08:30:09 +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 ) id 1KWoVY-000PnA-8g for namedroppers@ops.ietf.org; Sat, 23 Aug 2008 08:30:06 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KWoVT-0002bO-HI for namedroppers@ops.ietf.org; Sat, 23 Aug 2008 10:29:59 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 8CA844B451; Sat, 23 Aug 2008 10:30:09 +0200 (CEST) Date: Sat, 23 Aug 2008 10:30:09 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Agile countermeasures Message-ID: <20080823083008.GH4929@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080821201246.GE14116@outpost.ds9a.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 21, 2008 at 10:12:46PM +0200, bert hubert wrote: > A more advanced way is: > > 5) Stop accepting new data below the attacked apex, but also stop expiring > it. Ok, I've been pondering another one, and I wonder if it will work. While under attack, 5a) become ultra-paranoid and don't accept any data except the first answer record. Ignore new NS records, CNAME chains, additional records etc. This would make the NSSet of the attacked domain expire, but it would be refreshed from the parent zone when that happens. While the attacker could try to target that event as well, it too would be detected. An attacker can then still take over xaaaaaaaaa.ietf.org, but he won't be able to spread this to the NS records. 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: From owner-namedroppers@ops.ietf.org Sat Aug 23 08:26:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9273A6B32; Sat, 23 Aug 2008 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] 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 57xyEzWtwjHU; Sat, 23 Aug 2008 08:26:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F7A73A6811; Sat, 23 Aug 2008 08:26:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWusc-000Pyc-0i for namedroppers-data@psg.com; Sat, 23 Aug 2008 15:18:18 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWusY-000Py4-5M for namedroppers@ops.ietf.org; Sat, 23 Aug 2008 15:18:16 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 825DAA200B; Sat, 23 Aug 2008 15:18:04 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 23 Aug 2008 10:30:09 +0200." <20080823083008.GH4929@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080823083008.GH4929@outpost.ds9a.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 23 Aug 2008 15:18:04 +0000 Message-ID: <69998.1219504684@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 825DAA200B.5382C X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Agile countermeasures Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > ... > While under attack, > ... for the sake of future implementors whom this WG must guide via documents produced in this early part of the kaminsky era, i am still hoping for a non-modal solution. this is because conformance and interoperability testing of protocol implementations is already quite hard, and if we have to test "does it go into the attack mode under the right conditions" as well as "can it in that mode resist the attacks we know of" then it makes a test cost multiplicative that could otherwise have been additive. thus PING, 0x20, DNSSEC, SCTP loom larger for me than detecting attacks and behaving differently during attacks. nick weaver and masataka ohta have each made some non-modal proposals about noncaching of data, and i think the WG should seriously investigate, and prefer, non-modal proposals. if in the end we can't find a solution that doesn't involve adding IDS to DNS, then so be it. but the main thrust of our effort should be non-modal. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 23 08:29:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9CD3A69CF; Sat, 23 Aug 2008 08:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, 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 28mTtd6mCMRN; Sat, 23 Aug 2008 08:29:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 549DD3A6904; Sat, 23 Aug 2008 08:29:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWuz0-0001GR-85 for namedroppers-data@psg.com; Sat, 23 Aug 2008 15:24:54 +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 ) id 1KWuyu-0001A3-Ol for namedroppers@ops.ietf.org; Sat, 23 Aug 2008 15:24:52 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KWuyr-0000Vh-1g for namedroppers@ops.ietf.org; Sat, 23 Aug 2008 17:24:45 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 0A4A73F64; Sat, 23 Aug 2008 17:24:57 +0200 (CEST) Date: Sat, 23 Aug 2008 17:24:57 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Agile countermeasures Message-ID: <20080823152457.GI4929@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080823083008.GH4929@outpost.ds9a.nl> <69998.1219504684@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69998.1219504684@nsa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Aug 23, 2008 at 03:18:04PM +0000, Paul Vixie wrote: > think the WG should seriously investigate, and prefer, non-modal proposals. > if in the end we can't find a solution that doesn't involve adding IDS to > DNS, then so be it. but the main thrust of our effort should be non-modal. If we can find such a solution, it would be wonderful. I've been working on a paranoid rrset acceptance mode today, perhaps it will prove possible to fine-tune it such that it won't hurt (too much) and can be left on all the time. At the expense of some extra queries perhaps. 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: From owner-namedroppers@ops.ietf.org Sat Aug 23 08:39:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4E83A6AA2; Sat, 23 Aug 2008 08:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] 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 fSQdjOVmgDL8; Sat, 23 Aug 2008 08:39:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60E0A3A6A03; Sat, 23 Aug 2008 08:39:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWv4n-0002go-7f for namedroppers-data@psg.com; Sat, 23 Aug 2008 15:30:53 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KWv4j-0002gE-1u for namedroppers@ops.ietf.org; Sat, 23 Aug 2008 15:30:51 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 64BB7A1056; Sat, 23 Aug 2008 15:30:44 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 23 Aug 2008 17:24:57 +0200." <20080823152457.GI4929@outpost.ds9a.nl> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080823083008.GH4929@outpost.ds9a.nl> <69998.1219504684@nsa.vix.com> <20080823152457.GI4929@outpost.ds9a.nl> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sat, 23 Aug 2008 15:30:44 +0000 Message-ID: <71811.1219505444@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 64BB7A1056.AD0DF X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Agile countermeasures Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > ... the WG should seriously investigate, and prefer, non-modal proposals. > > if in the end we can't find a solution that doesn't involve adding IDS to > > DNS, then so be it. but the main thrust of our effort should be non-modal. > > If we can find such a solution, it would be wonderful. are we *all* agreed on this, then? > I've been working on a paranoid rrset acceptance mode today, perhaps it will > prove possible to fine-tune it such that it won't hurt (too much) and can be > left on all the time. > > At the expense of some extra queries perhaps. that's the area nick weaver's also working in. for many values of "some" that don't involve "too much" new state (storage or maintainance) this sounds good to me. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 24 07:25:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8953A6A14; Sun, 24 Aug 2008 07:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 sS8KwpeFeuA3; Sun, 24 Aug 2008 07:25:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13FB73A6CAC; Sun, 24 Aug 2008 07:25:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXGPQ-0009Ua-GT for namedroppers-data@psg.com; Sun, 24 Aug 2008 14:17:36 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXGPJ-0009Tc-EX for namedroppers@ops.ietf.org; Sun, 24 Aug 2008 14:17:31 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m7OEHHeN062022; Sun, 24 Aug 2008 16:17:18 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200808241417.m7OEHHeN062022@givry.fdupont.fr> From: Francis Dupont To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: SCTP (and DCCP) In-reply-to: Your message of Thu, 21 Aug 2008 16:32:06 -0000. <40391.1219336326@nsa.vix.com> Date: Sun, 24 Aug 2008 16:17:17 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: here are two articles on dnsop by bill fumerola in response to this thread there. => this shows the fall of T/TCP has left a hole... since sctp is slightly older and is used in ip telephony and is implemented on more systems and allows data transfer on the second round trip (packets 3 and 4), i'm more hopeful for it than i am for DCCP. => what we want is data transfer on the first round (packets 1 and 2) but it opens the door to fake source (in packet 1) attacks... DCCP is younger but its "market" is far larger. My concern is no new transport can really replace UDP and as a DNS fallback TCP. i see five reasons why SCTP is worth looking at as a primary transport with UDP as its fallback. first, data transfer can take place in the second round trip (packets 3 and 4). second, it has 32-bit ID fields so we could go back to fixed port numbers perhaps even fixed+increment on TXID's. third, we could mandate EDNS, and with it, we could mandate PING. fourth, SCTP has the idea of "passive" sockets which mean nonquadratic socket pool sizes. fifth, association timeout is handled in the stack not the app. => IMHO this only shows SCTP has the pros and cons of a new transport. Thanks Francis.Dupont@fdupont.fr -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 24 08:47:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B365F3A6C04; Sun, 24 Aug 2008 08:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 MLjTSVC13N-A; Sun, 24 Aug 2008 08:47:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F1863A6ACF; Sun, 24 Aug 2008 08:47:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXHir-000MNY-Ih for namedroppers-data@psg.com; Sun, 24 Aug 2008 15:41:45 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXHil-000MKo-Ki for namedroppers@ops.ietf.org; Sun, 24 Aug 2008 15:41:43 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D8B56A66AC; Sun, 24 Aug 2008 15:41:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Francis Dupont cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 24 Aug 2008 16:17:17 +0200." <200808241417.m7OEHHeN062022@givry.fdupont.fr> References: <200808241417.m7OEHHeN062022@givry.fdupont.fr> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 24 Aug 2008 15:41:26 +0000 Message-ID: <71267.1219592486@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: D8B56A66AC.7AF02 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: SCTP (and DCCP) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > since sctp is slightly older and is used in ip telephony and is > implemented on more systems and allows data transfer on the second round > trip (packets 3 and 4), i'm more hopeful for it than i am for DCCP. > > => what we want is data transfer on the first round (packets 1 and 2) > but it opens the door to fake source (in packet 1) attacks... yes, but to get data transfer in the first round trip, requires DNSSEC or PING. so i'm considering the impact of leaving SCTP associations open for some period of time (there's an automatic association timeout handled in the stack rather than in the application). this would allow a "working set" of associations who had already been through their first round trip. it's important to distinguish this from the TCP case where each session requires its own socket descriptor on every stack now known to exist, thus placing a giant burden on the application to do session management. an SCTP app could have tens or hundreds of thousands of associations open on a single "socket". i see that neither DCCP nor SCTP transfers user data in its first round trip. both offer message semantics (like UDP does), so the receiver can know the size of the message without having to encode it into the stream as we do in TCP/53. DCCP relies on ip fragmentation to send messages larger than PMTU, whereas SCTP is like TCP in that it can segment messages into IP packets that are not larger than PMTU. DCCP has no concept of "associations" like SCTP's and cannot multiplex many pseudosessions across a single "socket" or whatever the local stack calls its network endpoints. > DCCP is younger but its "market" is far larger. by "larger" do you mean "number of flows now using it" or something else? the wikipedia pages for DCCP and SCTP show many more implementations of SCTP. > My concern is no new transport can really replace UDP and as a DNS > fallback TCP. this is my concern also. however, speaking from the point of view of RFC 2671, ip fragmentation is a disaster and anything that depends on it will be very difficult to deploy. if the DNS engineering community seriously believes that DNS messages larger than PMTU must become commonplace some day, then we have millions of firewalls and middleboxes and even routers and switches to upgrade or replace. the truth of had not dawned on me at the time RFC 2671 was being prepared, though it's all blazingly clearly true after N years of trying to get RFC 2671 deployed. it's my opinion that the title of the RFC that resulted from this (RFC 4963) does not do justice to the content. ipv6 fragmentation doesn't have these problems, so perhaps if we look to the future we can forget how terrible ipv4 fragmentation really is. > i see five reasons why SCTP is worth looking at as a primary transport > with UDP as its fallback. first, .... second, .... third, .... > fourth, SCTP has the idea of "passive" sockets which mean nonquadratic > socket pool sizes. fifth, association timeout is handled in the stack > not the app. > > => IMHO this only shows SCTP has the pros and cons of a new transport. compared to UDP, TCP, or DCCP, reasons four and five (left intact above) are unique to SCTP. but the fundamental premise that it's likely impossible to insert a new primary transport ahead of UDP/53 is one we all agree with. if i could be sure there would be reliable and instantanenous signalling of the absence or failure of a new transport, and that we would not have to wait for some kind of timeout to tell us that it wasn't going to work, i'd say we should opportunistically deploy. alas, RFC 2671 deployment experience shows that a vast number of failures are inferrable only by timeouts. middleboxes (NATs, ALGs, firewalls) are exactly the bane the end-to-end crowd said they'd be, and now we're hamstrung. HTTP/1.1 with an XML schema for DNS messages would be more likely to succeed, especially if we used TCP/80 and a RESTful API. the internet isn't the web, but enough endpoints are confused about the differences that deployability is now generally higher for new web apps than it is for new internet apps. sad. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 24 16:03:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F203A6822; Sun, 24 Aug 2008 16:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, 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 p94JmXGrMYD3; Sun, 24 Aug 2008 16:03:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F3B93A6774; Sun, 24 Aug 2008 16:03:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXOUi-0006T6-G9 for namedroppers-data@psg.com; Sun, 24 Aug 2008 22:55:36 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXOUe-0006Se-HY for namedroppers@ops.ietf.org; Sun, 24 Aug 2008 22:55:34 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KXOUa-00008Z-W2; Sun, 24 Aug 2008 18:55:29 -0400 Message-ID: <48B1E6E0.4030301@ca.afilias.info> Date: Sun, 24 Aug 2008 18:55:28 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Paul Vixie CC: bert hubert , namedroppers@ops.ietf.org, dns-operations@lists.oarci.net Subject: Re: Agile countermeasures References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080823083008.GH4929@outpost.ds9a.nl> <69998.1219504684@nsa.vix.com> In-Reply-To: <69998.1219504684@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > > nick weaver and masataka ohta > have each made some non-modal proposals about noncaching of data, and i > think the WG should seriously investigate, and prefer, non-modal proposals. I've been giving some thought to some of the underlying vulnerabilities, where the following intersect: - the protocols involved - the strategies of resolvers - the data in the root and TLD *zones* (emphasis on zone vs domain) At the root of the Kaminsky vulnerability is the ability to feed data into a cache, where the data in question is provided in the "Additional" section. If we ignore, for the moment, when/whether/what referrals are provided by servers in "Authority" sections, and consider only the case of "if there *is* an authority section", then: The Question: When is it strictly necessary that Additional section data be provided *and* used (cached)? (Undoubtedly there are cases where it is absolutely necessary, to bridge the gap at a zone cut. If you have "example.com NS ns1.example.com", the only possible way for an empty cache to resolve the address of ns1.example.com, is via glue A/AAAA RR's.) But first, a quick sidebar... Sidebar: namespace congruity and phantom namespace The main axiom of "the Domain Name System", is the "the". (At least, for the public DNS sanctioned by ICANN et al.) There is only one. The name space is hierarchical, and delegations occur at zone cuts. Any legitimate, actual leaf in the name space must be reachable by starting at the root, and possibly crossing one or more zone cuts, reaching a terminal node in the label space of some leaf zone. Depending on the domain names of NS RR's used in delegations (at zone cuts), with attendant glue A/AAAA records, it may be possible to establish "phantom leaf" labels in the name space which are not reachable via top-down tree walking, because one or more parent domains of the NS RR's do not exist. If there were, for example, "example.com NS example.bar" with "example.bar A 10.1.2.3", if the caching resolver accepted that delegation, a new, non-existent TLD, "bar." with one leaf entry, "example.bar", would suddenly exist in the resolver's cache. Obviously, this is not something intentional, nor is it something that should generally be considered acceptable practice. (end of sidebar) If we exclude, axiomatically, the legitimacy of such "phantom" namespace elements, then we can then say the following are true: - every leaf entry in the public DNS exists (and is served authoritatively) in one zone only - every legitimate zone is delegated from its parent zone at a zone cut boundary - every legitimate zone is served by one or more name servers, who serve that zone authoritatively - every legitimate zone is anchored directly or indirectly at the root "." of the public DNS Taking the above together, then, it would be sufficient for resolving anything legitimate in the public DNS, for glue A/AAAA RR's to exist only in the immediate parent's zone. (I can elaborate on this if anyone wants, but I'm trying to keep this short). Thus, The Answer: If the *actual* glue A/AAAA RR's in (at a minimum) the root and all TLD zones met this condition, then the only time a resolver would ever *need* to accept "Additional" data would be in those exact cases, where the "Additional" data were given in the answer to a query for an A/AAAA RR, where the "Question" was for the RHS of a delegation, which was subordinate to (i.e. a child of) the LHS of the delegation. What this means: That the "Additional" section could be ignored in all other cases. And I *think* this would, in turn, result in the "birthday attack" race only being run when the TTL of glue A/AAAA RR's expires. Note also, that there will generally be orders of magnitude more NS entries pointing to the same RHS, and thus many fewer such races being run generally. As a data point, I examined a pretty big TLD (org), and verified that no out-of-zone glue A/AAAA RR's exist - only subordinate A/AAAA glue RR's exist. (If other TLD operators wouldn't mind checking this, and providing similar data points, I think we could possibly consider standardizing the non-use of Additional data.) Brian Dickson P.S. There is an important Corollary to the above: There is nothing in the naming of nameservers (in NS records) that restricts the levels of indirection that can occur, between the names of zones served, and the names of the nameservers serving those zones. As a practical matter, operators of nameservers *SHOULD* make reasonable efforts to limit the actual levels of indirection. And, ideally, nameservers *should*, if possible and practical, be authoritative for their own names. If I have ns1.foo.example.com, and ask it for the A RR for ns1.foo.example.com, life is easier if it gives the answer, and does so authoritatively, *and* is itself listed in the NS RR set for the domain foo.example.com. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 24 19:21:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55B03A6853; Sun, 24 Aug 2008 19:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] 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 UM9sftufEAI3; Sun, 24 Aug 2008 19:21:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A7473A6852; Sun, 24 Aug 2008 19:21:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXRcF-0008eR-Rc for namedroppers-data@psg.com; Mon, 25 Aug 2008 02:15:35 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXRcB-0008dt-NL for namedroppers@ops.ietf.org; Mon, 25 Aug 2008 02:15:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3ABC1A669C for ; Mon, 25 Aug 2008 02:15:17 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 24 Aug 2008 18:55:28 -0400." <48B1E6E0.4030301@ca.afilias.info> References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080823083008.GH4929@outpost.ds9a.nl> <69998.1219504684@nsa.vix.com> <48B1E6E0.4030301@ca.afilias.info> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Mon, 25 Aug 2008 02:15:17 +0000 Message-ID: <59613.1219630517@nsa.vix.com> MIME-Version: 1.0 X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 3ABC1A669C.39946 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Agile countermeasures Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Brian Dickson > To: Paul Vixie > CC: bert hubert , namedroppers@ops.ietf.org, > dns-operations@lists.oarci.net plz don't ever crosspost between namedroppers and dnsops. no possible article is of interest to both audiences. i'm removing dnsops, as well as bert and brian since i know they are on namedroppers. > ... > At the root of the Kaminsky vulnerability is the ability to feed data > into a cache, where the data in question is provided in the "Additional" > section. no. the root of the kaminsky vulnerability is the ability to run a race more than once and with a head start. actual pollution can come in the answer section (cname chains passing through or ending in names one wishes to pollute), the authority section (replacement NS RRs for the baliwick apex, or new subdomains of the baliwick), or the additional section (after kashpureff resistance has been applied there are still many forms of evil given the ability to arbitrarily populate the answer and authority sections.) it's a mistake to focus on any one section or any one form of pollution. the reason i'm enamored (in general, though there are many problems left to solve in the proposals) of the approaches advocated by masataka ohta and nick weaver is that they start from the question, what of all this do we HAVE to believe, and why, and what's the cost of disbelief, and what are our alternative means of acquiring the data, and what are the costs of those alternatives, and furthermore, what does "belief" really mean? in other words, how can we "fail closed". note that there may be other ways to achieve the "kaminsky effect" that do not involve misdirection. if an RDNS fails to implement birthday protection (sends multiple simultaneous upstream queries for a given q-tuple), or fails to cache the result (an rrset, or an nxdomain, or a nodata condition) for a given q-tuple, or if an ADNS deterministically never answers some kinds of questions (like undefined qtypes), or if a middlebox deterministically drops some kinds of questions or some kinds of answers (like qtypes unknown to it) then the "kaminsky effect" might be produced without the "sibling name trick" and in those cases the answer matching the q-type could also be poisonous. so even while my own toy RDNS now refuses to replace NS RRsets, and does not cache any answer RRsets other than the one matching the q-tuple, and fully implements RFC 2181's rrset credibility logic, and fully implements dns-0x20, i do not feel "safe" yet. when i can successfully reason from the starting point "what should i use or keep?" rather than "what shouldn't i use or keep?" then i'll be on a path that could lead to feeling safe. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 04:46:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E6028CAAD; Mon, 25 Aug 2008 04:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 Gx6tvg4H-18a; Mon, 25 Aug 2008 04:46:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 588C128CA9A; Mon, 25 Aug 2008 04:46:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXaPF-000Emx-5X for namedroppers-data@psg.com; Mon, 25 Aug 2008 11:38:45 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXaP7-000Ehk-5N for namedroppers@ops.ietf.org; Mon, 25 Aug 2008 11:38:43 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KXaOs-0000zi-Ej; Mon, 25 Aug 2008 13:38:22 +0200 Received: from fweimer by bfk.de with local id 1KXaP0-0007PI-5a; Mon, 25 Aug 2008 13:38:30 +0200 To: Paul Vixie Cc: bert hubert , namedroppers@ops.ietf.org Subject: Re: Agile countermeasures References: <200808211532.m7LFWJKx046469@givry.fdupont.fr> <40391.1219336326@nsa.vix.com> <20080821170545.GB14116@outpost.ds9a.nl> <49938.1219339836@nsa.vix.com> <20080821201246.GE14116@outpost.ds9a.nl> <20080823083008.GH4929@outpost.ds9a.nl> <69998.1219504684@nsa.vix.com> <20080823152457.GI4929@outpost.ds9a.nl> <71811.1219505444@nsa.vix.com> From: Florian Weimer Date: Mon, 25 Aug 2008 13:38:30 +0200 In-Reply-To: <71811.1219505444@nsa.vix.com> (Paul Vixie's message of "Sat, 23 Aug 2008 15:30:44 +0000") Message-ID: <82abf1e349.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: >> > ... the WG should seriously investigate, and prefer, non-modal proposa= ls. >> > if in the end we can't find a solution that doesn't involve adding IDS= to >> > DNS, then so be it. but the main thrust of our effort should be non-m= odal. >>=20 >> If we can find such a solution, it would be wonderful.=20 > > are we *all* agreed on this, then? I'm not sure---"does not support 0x20" or "does not support PING" as an additional upstream attribute is kind of modal, too. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 04:48:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1709828CB72; Mon, 25 Aug 2008 04:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 v-ChUkkYxxeB; Mon, 25 Aug 2008 04:48:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E551828CB71; Mon, 25 Aug 2008 04:48:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXaSJ-000FIl-Va for namedroppers-data@psg.com; Mon, 25 Aug 2008 11:41:55 +0000 Received: from [85.17.178.134] (helo=stipula.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXaSD-000FHp-3h for namedroppers@ops.ietf.org; Mon, 25 Aug 2008 11:41:53 +0000 Received: from localhost (localhost [127.0.0.1]) by stipula.dds.nl (Postfix) with ESMTP id 76B91795951 for ; Mon, 25 Aug 2008 13:41:48 +0200 (CEST) Received: from [192.168.254.2] (unknown [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stipula.dds.nl (Postfix) with ESMTP id A00FF79594D for ; Mon, 25 Aug 2008 13:41:40 +0200 (CEST) Message-ID: <48B29A74.8020205@nlnetlabs.nl> Date: Mon, 25 Aug 2008 13:41:40 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Namedroppers Subject: resolver side mitigation X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/8085/Mon Aug 25 12:08:16 2008 on stipula X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi, I've submitted a draft with the resolver side mitigations that I envision for Unbound. http://www.ietf.org/internet-drafts/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt Best regards, Wouter -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 05:55:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA3F28C182; Mon, 25 Aug 2008 05:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 9rRVklYpeGGE; Mon, 25 Aug 2008 05:55:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3322428C17E; Mon, 25 Aug 2008 05:55:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXbVq-0000OZ-30 for namedroppers-data@psg.com; Mon, 25 Aug 2008 12:49:38 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXbVj-0000NR-0L for namedroppers@ops.ietf.org; Mon, 25 Aug 2008 12:49:36 +0000 Received: (qmail 22935 invoked from network); 25 Aug 2008 12:56:29 -0000 Received: from softbank219178199025.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.199.25) by necom830.hpcl.titech.ac.jp with SMTP; 25 Aug 2008 12:56:29 -0000 Message-ID: <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> Date: Mon, 25 Aug 2008 21:48:47 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Ted Lemon CC: Nicholas Weaver , "namedroppers@ops.ietf.org" Subject: Re: Defining defense levels... References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> In-Reply-To: <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ted Lemon wrote: > What's nice about DNSSEC is that there's no user in the loop. To jam > DNSSEC, you have to actually break the protocol No. It is enough to break a zone in the loop. > It's true that SSL will protect you > if you use it correctly, but whether or not you use correctly it > depends on the user. Security of SSL, DNS or PKI in general depends both on the user and intermediate administrators. > I think you're seriously discounting the importance of human factors > when you say that the security of the DNS channel doesn't matter. You're seriously discounting the importance of human factors when you say that the security of the DNS channels through zones don't matter. PKI, including but not limited to DNSSEC, is merely weakly secure and is subject to MitM attacks. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 06:54:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF7728C1FD; Mon, 25 Aug 2008 06:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.701 X-Spam-Level: ** X-Spam-Status: No, score=2.701 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 9tpDl0-v9-I0; Mon, 25 Aug 2008 06:54:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD6E528C1E6; Mon, 25 Aug 2008 06:54:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXcQf-000CuG-Ev for namedroppers-data@psg.com; Mon, 25 Aug 2008 13:48:21 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXcQO-000Cs4-5q for namedroppers@ops.ietf.org; Mon, 25 Aug 2008 13:48:10 +0000 Received: (qmail 28831 invoked from network); 25 Aug 2008 13:55:20 -0000 Received: from softbank219178199025.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.199.25) by necom830.hpcl.titech.ac.jp with SMTP; 25 Aug 2008 13:55:20 -0000 Message-ID: <48B2B7F9.8060409@necom830.hpcl.titech.ac.jp> Date: Mon, 25 Aug 2008 22:47:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Mark Andrews CC: Brian Dickson , Paul Vixie , bert hubert , namedroppers@ops.ietf.org, dns-operations@mail.oarc.isc.org Subject: Re: Agile countermeasures References: <200808250028.m7P0SKkZ026299@drugs.dv.isc.org> In-Reply-To: <200808250028.m7P0SKkZ026299@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: > I can create delegations that REQUIRE glue from "DE" for > zones under "COM" and glue in "COM" for zones under "DE" > for the delegations to work. > > e.g. > example.de NS ns1.example.com > example.com NS ns1.example.de > > Back about BIND 4.9.[23] I configured named to stop accepting > glue that wasn't under the parent zone. I did this so I > could chase down bad glue. If there was bad glue I knew > it had to come for a parent, grandparent etc. I also knew > that it would break delegations like the one I'm describing > above but I also knew they were rare. And your false assertions have resulted in BIND vulnerabilities against Kaminsky's variation of ID guessing attacks. Isn't it enough that both "bailiwick" and "PKI" are not secure, not even theoretically. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 09:09:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DAE83A68CC; Mon, 25 Aug 2008 09:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 2PQ8a52OQSOA; Mon, 25 Aug 2008 09:09:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B90BE3A6B66; Mon, 25 Aug 2008 09:01:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXeQI-000Al9-8y for namedroppers-data@psg.com; Mon, 25 Aug 2008 15:56:06 +0000 Received: from [64.18.2.216] (helo=exprod7og115.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXeQB-000Aju-35 for namedroppers@ops.ietf.org; Mon, 25 Aug 2008 15:56:01 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Mon, 25 Aug 2008 08:55:29 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 1563E1A8206; Mon, 25 Aug 2008 08:55:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 25 Aug 2008 08:55:28 -0700 CC: Nicholas Weaver , "namedroppers@ops.ietf.org" Message-ID: <1D346610-B056-4148-B4AF-786311A38613@nominum.com> From: Ted Lemon To: Masataka Ohta In-Reply-To: <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Mon, 25 Aug 2008 08:55:26 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 25, 2008, at 5:48 AM, Masataka Ohta wrote: >> I think you're seriously discounting the importance of human factors >> when you say that the security of the DNS channel doesn't matter. > > You're seriously discounting the importance of human factors > when you say that the security of the DNS channels through zones > don't matter. Ohta-san, the way argument works is that you make a statement, and then you give a reason why it's true. And then if I agree with your reason, and agree that your reason applies, I have to agree with your statement. Just making a statement isn't enough - if we do that, then we wind up just contradicting each other over and over, and never coming to a conclusion. The problem with your thinking here is that it's _always_ true that if the server for a zone is pwned, you can't trust the contents of the zone or subzone of that zone, because the person who pwned the server can arbitrarily modify the data the server serves. With DNSSEC, however, there are two differences. First of all, if the server has not been pwned, then bogus data inserted by a third party will be detected. This is because the zone has been signed, and there exists a validation path that can be used to verify that signature. The second difference is that with DNSSEC, the mere fact that the server has been pwned does not *necessarily* mean that the signing key has been revealed. This is because the administrator has a choice as to where to do zone signing - it need not be done on the same machine that serves the zone. So in the case of DNSSEC, a sufficiently paranoid security policy protects against a vulnerability that PODS simply cannot protect against. There are still ways to forge the contents of a DNS zone. But they all involve getting access to the signing key for that zone. So yes, DNSSEC is not a panacea. If you ever thought that I was arguing that it is, please stop trying to convince me of that - I already realize that that is the case. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 12:03:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D917D3A682F; Mon, 25 Aug 2008 12:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 4dShu6Zbd4UG; Mon, 25 Aug 2008 12:03:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 835053A698C; Mon, 25 Aug 2008 12:03:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXhDS-000I8x-Gq for namedroppers-data@psg.com; Mon, 25 Aug 2008 18:55:02 +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 ) id 1KXhDN-000I83-I1 for namedroppers@ops.ietf.org; Mon, 25 Aug 2008 18:55:00 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7PIsrmu029125; Mon, 25 Aug 2008 14:54:53 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200808251854.m7PIsrmu029125@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Aug 2008 14:54:50 -0400 To: dnsext-ads@tools.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: Publication request for draft-ietf-dnsext-forgery-resilience-07.txt Cc: namedroppers@ops.ietf.org, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark, This is a request to publish the document as Standards Track document, Title : Measures for making DNS more resilient against forged answers Author(s) : A. Hubert, R. van Mook Filename : draft-ietf-dnsext-forgery-resilience-07.txt Date : August 25 2008 Document shepherd: Olafur Gudmundsson ogud@ogud.com 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? There is one nit according to idnits 2.08.10 (via tools.ietf.org). The nit is that Informational RFC 3833 is a normative reference. RFC 3833 is about the DNS threat model, this document addresses one of the treats identified in RFC 3833 and describes techniques to make it harder to exploit that particular threat. We are not sure the reference should be moved between sections or not. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes during last-call this document has been reviewed in depth by a large number of working group members. This particular document and the recent DNS exploits that attempt to poison DNS caches, have brought number of new people to the working group. We have no issue with the extent of reviews. There is strong consensus to advance the document. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? We think this document has had sufficient review. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. The only issues that people brought up are: Standards track vs. BCP. The TCP fallback On the first one most people stated preference to one or the other but at the same time said they could live with the other. The requirement in section 9 that resolvers be capable of using multiple source ports at once is arguably a new requirement, and could have inter operation effects. See: http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00873.html As for the TCP fallback there is some concern in the operating community that extensive use of TCP by resolver may cause problems. The chairs and editors point out that TCP is an allowed transport protocol thus recommending its use in certain situations, in particular when under attack is justified. 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The consensus is strong, on the document as whole. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No one has threatened an appeal. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes but see note #1 above. 8) For Standards Track and BCP documents, the IESG approval announcement includes a write up section with the following sections: - Technical Summary DNS uses UDP for most of its query resolution process, to protect against forged UDP replies DNS has relied on a Query-ID field that is 16 bits long. The size of this field was adequate when network connections were slower than is common today. The document documents measures to extend the effective Query-ID by using all available UDP ports, different source address (when possible) and using different authorative servers. All of the measures documented in the document, have been in use in certain implementations for a long time, and recently been almost universally deployed in all major implementations. - Working Group Summary There is a broad consensus that this important document be published. - Protocol Quality The techniques described in the document have been implemented and are in use use by number of implementations, with no interoperabilty issues. The only issues observed have been related to inability to allocate large number of open ports on certain operating systems, and firewalls/IDS not expecting the use of random ports by DNS resolvers. Olafur & Andrew -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 17:04:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9DC3A68C6; Mon, 25 Aug 2008 17:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.725 X-Spam-Level: ** X-Spam-Status: No, score=2.725 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 RXhvMh3vNp50; Mon, 25 Aug 2008 17:04:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5099B3A685B; Mon, 25 Aug 2008 17:04:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXlvw-000Esr-4d for namedroppers-data@psg.com; Mon, 25 Aug 2008 23:57:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXlvr-000EsG-LG for namedroppers@ops.ietf.org; Mon, 25 Aug 2008 23:57:13 +0000 Received: (qmail 80828 invoked from network); 26 Aug 2008 00:04:15 -0000 Received: from softbank219178199025.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.199.25) by necom830.hpcl.titech.ac.jp with SMTP; 26 Aug 2008 00:04:15 -0000 Message-ID: <48B346A8.1080708@necom830.hpcl.titech.ac.jp> Date: Tue, 26 Aug 2008 08:56:24 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Ted Lemon CC: Nicholas Weaver , "namedroppers@ops.ietf.org" Subject: Re: Defining defense levels... References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> <1D346610-B056-4148-B4AF-786311A38613@nominum.com> In-Reply-To: <1D346610-B056-4148-B4AF-786311A38613@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ted Lemon wrote: > There are still ways to forge the contents of a DNS zone. But they > all involve getting access to the signing key for that zone. Wrong. A forged signature in an ancestor zone of the target zone is enough. The ancestor zone is the place upon where a trivial MitM attack works. > So yes, DNSSEC is not a panacea. For fair evaluation of DNSSEC, let's accept your statement that: >> I think you're seriously discounting the importance of human factors >> when you say that the security of the DNS channel doesn't matter. Now, you can see that human factors of DNSSEC channel through zones does matter. So, we can agree that PKIs, including DNSSEC, is seriously discounting the importance of human factors. With the agreement, the only thing we can do is to accept that human management of DNS, including DNSSEC, is not very secure. Masataka Ohta -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 21:03:54 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F8F3A6861; Mon, 25 Aug 2008 21:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_16=0.6, 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 Z086wO6sr0v2; Mon, 25 Aug 2008 21:03:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A21B3A6765; Mon, 25 Aug 2008 21:03:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXpfb-0003P9-3U for namedroppers-data@psg.com; Tue, 26 Aug 2008 03:56:39 +0000 Received: from [129.9.168.35] (helo=shbmap01.extra.chrysler.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXpfW-0003OV-Eb for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 03:56:37 +0000 X-AuditID: 8109a822-ad887bb000000b82-a3-48b37ef1f19d Received: from odnavip4-hme0.oddc.chrysler.com (unknown [53.231.99.241]) by shbmap01.extra.chrysler.com (Symantec Mail Security) with SMTP id 577BD4E4002 for ; Mon, 25 Aug 2008 23:56:33 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.98.85]) by odnavip4-hme0.oddc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2008082523563227599 for ; Mon, 25 Aug 2008 23:56:32 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.13.6/8.9.1) with ESMTP id m7Q3uX6M005725 for ; Mon, 25 Aug 2008 23:56:33 -0400 (EDT) Message-ID: <48B37EF1.2080206@chrysler.com> Date: Mon, 25 Aug 2008 23:56:33 -0400 From: Kevin Darcy User-Agent: Thunderbird 2.0.0.6 (X11/20070802) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Zone Immortality References: <200808210428.m7L4S9uL032499@drugs.dv.isc.org> In-Reply-To: <200808210428.m7L4S9uL032499@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: >> RFC 1034 states: >> >> Each secondary server is required to perform the following operations >> against the master, but may also optionally perform these operations >> against other secondary servers. This strategy can improve the transfer >> process when the primary is unavailable due to host downtime or network >> problems, or when a secondary server has better network access to an >> "intermediate" secondary than to the primary. >> >> >> >> Now, disregarding the obsolete "secondary" language (we now call them >> "slaves"), and the obviously-incorrect word "following" (which can't >> possibly be right, since this is the last paragraph of the section -- >> there is nothing relevant "following"), one notes the blatant ambiguity >> of "these operations". Which operations? Minimally, checking the serial >> number and performing a zone transfer if it has increased? I think that >> much is fairly obvious. >> >> What's a little *less* obvious, and the point of my missive, is whether, >> when and/or how "these operations" might include the following, from a >> previous paragraph: " >> >> If the secondary finds it impossible to perform a serial check for the EXPIRE >> interval, it must >> assume that its copy of the zone is obsolete an[sic] discard it." >> >> The problem with slaves resetting their EXPIRE timers every time they >> perform a successful refresh from another slave is that the slaves may >> be in a reciprocal or circular -- A refreshes from B, B refreshes from >> C, C refreshes from A -- relationship, so the zone may become >> "immortal", i.e. even when it is deleted from the primary master, the >> slaves continue to keep the zone alive indefinitely by constantly >> refreshing each other. >> >> Surely it cannot have been the intent for zones to become "immortal". >> That would defeat the whole purpose of having EXPIRE in the first place. >> >> Yet, having slaves in a reciprocal or circular relationship is a >> perfectly _valid_ arrangement. It ensures that, if the primary master >> goes down for an extended period of time (i.e. multiple REFRESH cycles), >> all slaves in the set eventually converge on the latest-available >> version of the zone. >> >> I would suggest, therefore, that if this language in 1034 cannot or will >> not be clarified/updated in the foreseeable future, so as to outlaw this >> "optional" replication topology, that implementors review their >> refresh/expire logic, and if it doesn't already exist in their >> implementation, provide a way for administrators to differentiate true >> "master" replication sources, which reset the EXPIRE timer on each >> successful refresh, from "peer" sources, which do not. This would allow >> large enterprises --such as ours -- to build highly robust and available >> DNS infrastructures without having to struggle with zone-immortality >> risks/issues. >> >> >> - Kevin >> > > There are lots of existing ways to address this. > > * Outlaw loops. > * Don't reset the expire counter on refresh from peers only > on transfer from peers. > > * Use DNSSEC to make data go stale. > > Extend AXFR/IXFR/SOA to add a expiry counter. The master would > always set this to SOA EXPIRE. The slave would report it's > current value for that counter. > > This fits well into EDNS as it is a hop-by-hop value. > > It would also address the N * expiry problem that currently > exists when you have a deep transfer graph. > > e.g. <4> > > The slave would add a <0> option to its SOA > refresh queries and to IXFR and AXFR queries. > > The slave would use the maximum of the returned value and > it's expire counter on SOA serial matches to refresh queries > or IXFR up to date responses to set its expire counter. > > The slave would use this value rather than the SOA expire > field to initialise it's expire counter on IXFR/AXFR which > change the zone content. > > The slave will perform a sanity check to ensure that the > returned value is no greater than the SOA expire field. If > it is greater then it will use the SOA expire field instead. > I wasn't really angling to have a new protocol extension added, just pointing out an ambiguity in the spec, cautioning implementors as to the consequences of not carefully dealing with the ambiguity, and putting out one suggestion for how implementors could give administrators a way to avoid the immortality problem. Your option "Don't reset the expire counter on refresh from peers only on transfer from peers" sounds like a slightly-more-fleshed-out version of what I was proposing ("differentiat[ing] true 'master' replication, which reset[s...] from 'peer' sources, which do not"). Thus, I approve :-). However it is formulated, the implementation would need to distinguish "peer" from "master". Option "Outlaw loops" is simplest, in the Draconian sense, but as I think I explained in my original message, can be viewed as suboptimal, since it does not facilitate full convergence of all slaves during an extended outage of the master. Also, there is the question of how "outlaw loops" could be reliably enforced within the implementation, unless an overall management framework is assumed (and if such a framework is assumed, why not just assume, further, that the zone in question will be automatically deleted on all slaves when it is deleted on the master, thus rendering EXPIRE pointless and mooting the problem). I can't comment intelligently on the DNSSEC solution, since, confessedly, I'm still somewhat of a DNSSEC neophyte. But, does the concept of "expire" in DNSSEC run parallel to the usual EXPIRE mechanism of "classical" DNS? Or does it override it? As for the "expiry counter" idea, I like it, but to be perfectly honest, I don't know that either the immortality problem, or the N*EXPIRE issue, or both, can generate enough enthusiasm to get any traction for a protocol extension, at this time (given the other pressing DNS-security concerns at the moment). - Kevin -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 22:05:15 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B49B28B56A; Mon, 25 Aug 2008 22:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.701 X-Spam-Level: ** X-Spam-Status: No, score=2.701 tagged_above=-999 required=5 tests=[AWL=4.700, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] 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 xK4Hw4Q5lY+e; Mon, 25 Aug 2008 22:05:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4AC63A6901; Mon, 25 Aug 2008 22:05:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXqbJ-000F4W-2P for namedroppers-data@psg.com; Tue, 26 Aug 2008 04:56:17 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXqbD-000F3g-Hn for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 04:56:13 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7Q4u5es041632; Tue, 26 Aug 2008 14:56:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808260456.m7Q4u5es041632@drugs.dv.isc.org> To: Kevin Darcy Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Zone Immortality In-reply-to: Your message of "Mon, 25 Aug 2008 23:56:33 -0400." <48B37EF1.2080206@chrysler.com> Date: Tue, 26 Aug 2008 14:56:05 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > As for the "expiry counter" idea, I like it, but to be perfectly honest, > I don't know that either the immortality problem, or the N*EXPIRE issue, > or both, can generate enough enthusiasm to get any traction for a > protocol extension, at this time (given the other pressing DNS-security > concerns at the moment). > > - Kevin The draft to describe this is written and posted. draft-andrews-dnsext-expire-00.txt Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 25 23:27:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE7D3A67C1; Mon, 25 Aug 2008 23:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 CBLfDsk7AGfp; Mon, 25 Aug 2008 23:27:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C4A43A69DD; Mon, 25 Aug 2008 23:26:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXrvP-0002n5-Vv for namedroppers-data@psg.com; Tue, 26 Aug 2008 06:21:07 +0000 Received: from [64.18.2.173] (helo=exprod7og110.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXrvL-0002ix-Cv for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 06:21:05 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 25 Aug 2008 23:17:48 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id A438E1A820C; Mon, 25 Aug 2008 23:17:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 25 Aug 2008 23:17:48 -0700 CC: "namedroppers@ops.ietf.org WG" Message-ID: <163FF68C-E57E-47DD-B805-33E8BA0825C1@nominum.com> From: Ted Lemon To: Masataka Ohta In-Reply-To: <48B346A8.1080708@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Mon, 25 Aug 2008 23:17:46 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> <1D346610-B056-4148-B4AF-786311A38613@nominum.com> <48B346A8.1080708@necom830.hpcl.titech.ac.jp> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 25, 2008, at 4:56 PM, Masataka Ohta wrote: > Ted Lemon wrote: > >> There are still ways to forge the contents of a DNS zone. But they >> all involve getting access to the signing key for that zone. > > Wrong. > > A forged signature in an ancestor zone of the target zone is > enough. > > The ancestor zone is the place upon where a trivial MitM attack > works. Right. If you get the signing key for .com, you can forge anything under .com. If you get the signing key for fugue.com, you can sign anything under fugue.com. And if you get the CA signing key one of the major CAs, you can generate new certs for whatever bank you want to spoof. Right now, there simply isn't any protection against forged DNS information. So DNSSEC is not a panacea, and certainly anybody who is running a zone that acts as a trust anchor for important zones below it should have a security policy that's appropriate for the level of trust being invested in them. But this has nothing to do with the human factors argument I brought up, so I'm not sure why you mention it. I don't think there is anybody on this mailing list at this point who does not understand how zones are signed, or what trust anchors do. My point about human factors is that if you can make it much harder to forge a domain name, then this makes a lot of security downgrade attacks based on human factors (that is, tricks) much harder to carry out. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 07:01:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5A528C17A; Tue, 26 Aug 2008 07:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.701 X-Spam-Level: **** X-Spam-Status: No, score=4.701 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, 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 SePuFm4aSdcu; Tue, 26 Aug 2008 07:01:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B4AD28C1DA; Tue, 26 Aug 2008 07:01:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXywd-000Nuu-9I for namedroppers-data@psg.com; Tue, 26 Aug 2008 13:50:51 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXywU-000Ns0-Co for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 13:50:44 +0000 Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1KXywR-0005r0-R7; Tue, 26 Aug 2008 14:50:39 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KXywR-0004Fd-D0; Tue, 26 Aug 2008 14:50:39 +0100 Message-ID: <2B647646454B4A51958541C4929D14E6@localhost> From: "George Barwood" To: "Nicholas Weaver" Cc: References: <01e601c9016d$e4fa6d10$0302a8c0@localhost> Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 Date: Tue, 26 Aug 2008 14:50:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > My belief is that there should be an official server with this property. > Thus resolvers can query the server a few times on startup to know if the > port number is preserved. [1] My laptop computer can be be connected via different firewalls during the course of the day. The cache can be left running for weeks on end ( I reboot maybe once a month ). I don't know if it is possible for the software to reliably detect that the nature of the connection has changed. > But there are some anomalous servers, which for the same repeated query > will return different values. With this policy an anomalous server which > returns different values for the same query will not be cached yet will > be resolved by the client. Cool beans: You punish them with more load, > but their results still work. Even though different values may be returned, assuming the number of valid results is finite (and not too large) [1], suitable confidence will be obtained. As an example, suppose there are 50 valid IP addresses, and the server returns a random subset of 8 of these on each query. After 7 queries at least one will have been returned twice, after 13 queries at least one will have been returned 3 times etc. There is a problem though : deciding when the process has "converged". The simplest approach is to stop as soon as any result is available with required confidence value. This could result in the client being given just 1 IP address, leading to an unexpected loss of resilience [2]. As an end user, I'm happy to live with this. I am doubtful that these anamolous servers are significant, and the example given seems quite artificial. If anyone knows differently, that would be interesting. For such servers, an alternative would be to divide the 50 servers into groups ( 6 groups of 7 and one of 8 ), and then return a randomly selected group on each query. That ensures that a full set of at least 7 servers will be returned to the clients using a repeated query strategy. I'm also thinking about whether a more robust method of testing for convergence makes sense - for example sending extra queries if the result set shows unusual convergence - normally all confidence values will be equal. It seems to be hard however to distinguish between poor convergence and a possible attack with certainty. [1] This assumption seems entirely reasonable to me. [2] Many applications don't properly use multiple results, so the loss may be not be significant in any case. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 07:01:23 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0248B28C1F3; Tue, 26 Aug 2008 07:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=0.188, 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 1b7ta5rc2an8; Tue, 26 Aug 2008 07:01:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BEC228C1FC; Tue, 26 Aug 2008 07:01:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXz1r-000OZ0-1t for namedroppers-data@psg.com; Tue, 26 Aug 2008 13:56:15 +0000 Received: from [74.95.2.169] (helo=kilo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXz1k-000OY3-92 for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 13:56:10 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id CFC34557787; Tue, 26 Aug 2008 06:56:08 -0700 (PDT) Date: Tue, 26 Aug 2008 06:56:08 -0700 From: Eric Rescorla To: Ted Lemon Cc: Masataka Ohta , "namedroppers@ops.ietf.org WG" Subject: Re: Defining defense levels... In-Reply-To: <163FF68C-E57E-47DD-B805-33E8BA0825C1@nominum.com> References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> <1D346610-B056-4148-B4AF-786311A38613@nominum.com> <48B346A8.1080708@necom830.hpcl.titech.ac.jp> <163FF68C-E57E-47DD-B805-33E8BA0825C1@nominum.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080826135608.CFC34557787@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Mon, 25 Aug 2008 23:17:46 -0700, Ted Lemon wrote: > My point about human factors is that if you can make it much harder to > forge a domain name, then this makes a lot of security downgrade > attacks based on human factors (that is, tricks) much harder to carry > out. I'm sorry but, I still don't understand this argument, since many of the human factors tricks against TLS depend on getting the user to override the mechanical checks. Are you arguing that DNSSEC doesn't permit that kind of override or something else? -Ekr -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 07:33:27 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8493A6B4B; Tue, 26 Aug 2008 07:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.73 X-Spam-Level: * X-Spam-Status: No, score=1.73 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 SKpTU8VZGoxH; Tue, 26 Aug 2008 07:33:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 615BF3A687C; Tue, 26 Aug 2008 07:33:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXzSf-0001nD-U9 for namedroppers-data@psg.com; Tue, 26 Aug 2008 14:23:57 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXzSO-0001ku-CW for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 14:23:55 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KXzSC-0007zo-K7; Tue, 26 Aug 2008 16:23:28 +0200 Received: from fweimer by bfk.de with local id 1KXzSK-0007OS-FK; Tue, 26 Aug 2008 16:23:36 +0200 To: "W.C.A. Wijngaards" Cc: Namedroppers Subject: Re: resolver side mitigation References: <48B29A74.8020205@nlnetlabs.nl> From: Florian Weimer Date: Tue, 26 Aug 2008 16:23:36 +0200 In-Reply-To: <48B29A74.8020205@nlnetlabs.nl> (W. C. A. Wijngaards's message of "Mon, 25 Aug 2008 13:41:40 +0200") Message-ID: <82iqtn6ejb.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * W. C. A. Wijngaards: > I've submitted a draft with the resolver side mitigations that I > envision for Unbound. > > http://www.ietf.org/internet-drafts/draft-wijngaards-dnsext-resolver-side= -mitigation-00.txt I think RTT banding with 200 ms does not work that well if the attacker is less than 200 ms away from the resolver which is attacked: Suppose that NS1 has got a RTT of 20 ms, and NS2 one of 220 ms, and the attacker is very close to the resolver (negligible RTT). The attacker sends a query to the resolver, initially spoofing responses from both resolvers. If no answer is received within 20 ms, it concentrates spoofing on the other resolver. As a result, the necessary attack bandwidth has been reduced, leading to a better attack. In the end, the question whether RTT banding is useful boils down to how we measure attack costs. Without proper cost metrics, it's hard to tell if a countermeasure is a real improvement (and how it interacts with other resolver features like lameness caches). Section 3.3 could mention that these techniques stop query mining attacks on DNSSEC (because an off-path attacker cannot proxy DNSSEC traffic anymore). The downside is that when you detect a failure (even if it's just a timeout), you need to back up, maybe even back to the root, in order to get a fresh version of the data you've just invalidated. (I don't think this should be a priority item, though.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 07:46:20 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D0E3A686C; Tue, 26 Aug 2008 07:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 u-OALB3Xp73u; Tue, 26 Aug 2008 07:46:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16A7D3A685A; Tue, 26 Aug 2008 07:46:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXzkF-00045q-Vq for namedroppers-data@psg.com; Tue, 26 Aug 2008 14:42:07 +0000 Received: from [85.17.178.134] (helo=stipula.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXzk7-00044Z-0r for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 14:42:05 +0000 Received: from localhost (localhost [127.0.0.1]) by stipula.dds.nl (Postfix) with ESMTP id 30FEE7959FC; Tue, 26 Aug 2008 16:41:58 +0200 (CEST) Received: from [192.168.254.2] (unknown [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stipula.dds.nl (Postfix) with ESMTP id 7213179596C; Tue, 26 Aug 2008 16:41:52 +0200 (CEST) Message-ID: <48B4162D.3020303@nlnetlabs.nl> Date: Tue, 26 Aug 2008 16:41:49 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Florian Weimer CC: Namedroppers Subject: Re: resolver side mitigation References: <48B29A74.8020205@nlnetlabs.nl> <82iqtn6ejb.fsf@mid.bfk.de> In-Reply-To: <82iqtn6ejb.fsf@mid.bfk.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.1/8090/Tue Aug 26 12:30:04 2008 on stipula X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Weimer wrote: > In the end, the question whether RTT banding is useful boils down to > how we measure attack costs. Without proper cost metrics, it's hard > to tell if a countermeasure is a real improvement (and how it > interacts with other resolver features like lameness caches). Well, time to infection. Or is bandwidth better? If the attacker does not determine what nameserver is being used, 2x in the case above. If smart, like you describe, about 1.1x (1/10 of the time it has to use double bandwidth). If the resolver sticks to the fastest nameserver: 1x. > Section 3.3 could mention that these techniques stop query mining > attacks on DNSSEC (because an off-path attacker cannot proxy DNSSEC > traffic anymore). The downside is that when you detect a failure > (even if it's just a timeout), you need to back up, maybe even back to > the root, in order to get a fresh version of the data you've just > invalidated. (I don't think this should be a priority item, though.) I do not understand what you mean with query mining. If the NS or nameserver address query fails, simply give up on it. Do not back up to higher servers. When the next query for this bailiwick comes along, you'll get to the same spot again, and try again. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki0Fi0ACgkQkDLqNwOhpPiA5QCeNkCvoW3FunROivVG7pYLC9Qj uCQAnRCzv6dhe92DX30yb4m8cmYOgyzA =5hQg -----END PGP SIGNATURE----- -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 07:58:19 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF6828C1A1; Tue, 26 Aug 2008 07:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 4DKGXeXK336Q; Tue, 26 Aug 2008 07:58:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AE8428C197; Tue, 26 Aug 2008 07:58:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXztD-0005Ei-Um for namedroppers-data@psg.com; Tue, 26 Aug 2008 14:51:23 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KXzt5-0005Da-Gk for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 14:51:21 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KXzsv-0001qe-Os; Tue, 26 Aug 2008 16:51:05 +0200 Received: from fweimer by bfk.de with local id 1KXzt3-0003TR-Ll; Tue, 26 Aug 2008 16:51:13 +0200 To: "W.C.A. Wijngaards" Cc: Namedroppers Subject: Re: resolver side mitigation References: <48B29A74.8020205@nlnetlabs.nl> <82iqtn6ejb.fsf@mid.bfk.de> <48B4162D.3020303@nlnetlabs.nl> From: Florian Weimer Date: Tue, 26 Aug 2008 16:51:13 +0200 In-Reply-To: <48B4162D.3020303@nlnetlabs.nl> (W. C. A. Wijngaards's message of "Tue, 26 Aug 2008 16:41:49 +0200") Message-ID: <824p576d9a.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * W. C. A. Wijngaards: > Florian Weimer wrote: >> In the end, the question whether RTT banding is useful boils down to >> how we measure attack costs. Without proper cost metrics, it's hard >> to tell if a countermeasure is a real improvement (and how it >> interacts with other resolver features like lameness caches). > > Well, time to infection. Or is bandwidth better? Or packet count? Or traffic volume? It's not an easy answer, and there are certainly lots of different trade-offs. >> Section 3.3 could mention that these techniques stop query mining >> attacks on DNSSEC (because an off-path attacker cannot proxy DNSSEC >> traffic anymore). The downside is that when you detect a failure >> (even if it's just a timeout), you need to back up, maybe even back to >> the root, in order to get a fresh version of the data you've just >> invalidated. (I don't think this should be a priority item, though.) > > I do not understand what you mean with query mining. Spoofing the delegation while returning correct data, to get an insight into which DNS data the victim is interested in. > If the NS or nameserver address query fails, simply give up on it. Do > not back up to higher servers. When the next query for this bailiwick > comes along, you'll get to the same spot again, and try again. But this doesn't deal with the situation that you keep querying the wrong name server set, does it? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 08:12:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3253A6920; Tue, 26 Aug 2008 08:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 zEeAHoueeIsa; Tue, 26 Aug 2008 08:12:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 771A63A6903; Tue, 26 Aug 2008 08:12:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY037-0006YN-6a for namedroppers-data@psg.com; Tue, 26 Aug 2008 15:01:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY02z-0006XM-Nt for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 15:01:31 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7QF1BcF024566; Tue, 26 Aug 2008 08:01:11 -0700 (PDT) Cc: Nicholas Weaver , "W.C.A. Wijngaards" , Namedroppers Message-Id: <9446AE97-049F-4157-89C2-D5A74B6B8F3C@icsi.berkeley.edu> From: Nicholas Weaver To: Florian Weimer In-Reply-To: <82iqtn6ejb.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: resolver side mitigation Date: Tue, 26 Aug 2008 08:01:11 -0700 References: <48B29A74.8020205@nlnetlabs.nl> <82iqtn6ejb.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 26, 2008, at 7:23 AM, Florian Weimer wrote: > * W. C. A. Wijngaards: > >> I've submitted a draft with the resolver side mitigations that I >> envision for Unbound. >> >> http://www.ietf.org/internet-drafts/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt > > I think RTT banding with 200 ms does not work that well if the > attacker is less than 200 ms away from the resolver which is attacked: > Suppose that NS1 has got a RTT of 20 ms, and NS2 one of 220 ms, and > the attacker is very close to the resolver (negligible RTT). The > attacker sends a query to the resolver, initially spoofing responses > from both resolvers. If no answer is received within 20 ms, it > concentrates spoofing on the other resolver. As a result, the > necessary attack bandwidth has been reduced, leading to a better > attack. > > In the end, the question whether RTT banding is useful boils down to > how we measure attack costs. Without proper cost metrics, it's hard > to tell if a countermeasure is a real improvement (and how it > interacts with other resolver features like lameness caches). Actually, I think it does up the attacker work, just not by a full bit. During the first 20ms, the attacker is sending as if from the "close" resolver, and then during the remaining 200ms of an epoc, from the "far" resolver.. If the attacker DOES have the feedback loop to know if there is immediate success and is "local" (0ms latency) and observing when the response comes back to determine that an attempt has failed. If the resolver chose the "close" one, for the entire 20ms, none of the traffic is wasted. (no entropy gain), because the attacker starts a new race as soon as he observes the first one having failed. If the resolver chose the "far" one, for the first 20ms, all the traffic is wasted, and for the remaining 200ms, the traffic is fully effective, which is still a gain in entropy but a far lower gain. (a less than 1b entropy gain, but still some gain). If the attacker does NOT have the feedback loop, then it is a big gain in entropy: If the resolver chose the "close" one, 200ms out of 220ms is wasted If the resolver chose the "far" one, 20ms out of 220ms is wasted. Thus I think if the attacker doesn't have the feedback loop, you still get a 1b gain in entropy (but not positive). -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 08:17:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09353A6ADA; Tue, 26 Aug 2008 08:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 pYSFWMHXpefw; Tue, 26 Aug 2008 08:17:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4C9A3A677C; Tue, 26 Aug 2008 08:17:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY0EA-0007iX-VY for namedroppers-data@psg.com; Tue, 26 Aug 2008 15:13:02 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY0E6-0007hv-SO for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 15:13:00 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7QFCuf3025968; Tue, 26 Aug 2008 08:12:56 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: <2B647646454B4A51958541C4929D14E6@localhost> Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 X-Priority: 3 References: <01e601c9016d$e4fa6d10$0302a8c0@localhost> <2B647646454B4A51958541C4929D14E6@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 26 Aug 2008 08:12:56 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 26, 2008, at 6:50 AM, George Barwood wrote: >> My belief is that there should be an official server with this >> property. Thus resolvers can query the server a few times on >> startup to know if the port number is preserved. [1] > > My laptop computer can be be connected via different firewalls > during the course of the day. > The cache can be left running for weeks on end ( I reboot maybe once > a month ). > I don't know if it is possible for the software to reliably detect > that the nature of the connection has changed. When it connects to a new firewall, you have an event where the network connectivity went down and up. I imagine that on most systems this is a detectable event for your stub resolver. (And how fixed are the stub resolvers anyway, vs the caching resolvers, in upping entropy at all?) There are also other heuristics (eg, has the MAC for the gateway changed) which could also be used. Additionally, although the resolving cache on your notebook is moderately important, where the NAT behavior is critical is on the centralized cache: Far too many businesses with many systems put them all behind a NAT to save money and reduce exposure, as a NAT effectively acts as a one-way firewall. It is these resolvers that need to be protected against NATs. >> But there are some anomalous servers, which for the same repeated >> query will return different values. With this policy an anomalous >> server which returns different values for the same query will not >> be cached yet will be resolved by the client. Cool beans: You >> punish them with more load, but their results still work. > > Even though different values may be returned, assuming the number of > valid results is finite (and not too large) [1], suitable confidence > will be obtained. As an example, suppose there are 50 valid IP > addresses, and the server returns a random subset of 8 of these on > each query. After 7 queries at least one will have been returned > twice, after 13 queries at least one will have been returned 3 times > etc. I'd still rather "don't bother": Converging is going to be very long and a lot of traffic, probably far more than "just don't cache" at all for most cases. And this is exactly why I believe in treating transactions vs caches separately: How many cases are there where you have "Race until win" on a transaction attack (vs getting something into the cache. Kaminski attacks are cache attacks)? The only case I can come up with is cookie-hunting for insecure (non SSL-marked) cookies by generating a bunch of subdomains in iframes (bad1.login.yahoo.com, bad2.login.yahoo.com, etc) where the first one which succeeds will return the cookies to the attacker's server. Can someone come up with other cases of blind transaction attacks? -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 08:31:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975F428C1AF; Tue, 26 Aug 2008 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 BdoVLQgXKJFv; Tue, 26 Aug 2008 08:31:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 880D328C1A4; Tue, 26 Aug 2008 08:31:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY0SK-0009jp-Ig for namedroppers-data@psg.com; Tue, 26 Aug 2008 15:27:40 +0000 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY0SD-0009ix-8c for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 15:27:35 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Aug 2008 08:27:31 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 572861A8201; Tue, 26 Aug 2008 08:27:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 26 Aug 2008 08:27:31 -0700 CC: "namedroppers@ops.ietf.org WG" Message-ID: From: Ted Lemon To: Eric Rescorla In-Reply-To: <20080826135608.CFC34557787@kilo.rtfm.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Tue, 26 Aug 2008 08:26:52 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> <1D346610-B056-4148-B4AF-786311A38613@nominum.com> <48B346A8.1080708@necom830.hpcl.titech.ac.jp> <163FF68C-E57E-47DD-B805-33E8BA0825C1@nominum.com> <20080826135608.CFC34557787@kilo.rtfm.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 26, 2008, at 6:56 AM, Eric Rescorla wrote: > I'm sorry but, I still don't understand this argument, since many > of the human factors tricks against TLS depend on getting the > user to override the mechanical checks. Are you arguing that > DNSSEC doesn't permit that kind of override or something else? DNSSEC makes it harder to convince the browser to throw up a form that doesn't submit via SSL, or that submits to a different site via SSL. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 09:08:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5267F3A685A; Tue, 26 Aug 2008 09:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.125, 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 RVzgQuNHIkzi; Tue, 26 Aug 2008 09:07:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A5ED3A6811; Tue, 26 Aug 2008 09:07:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY11t-000Fnw-RP for namedroppers-data@psg.com; Tue, 26 Aug 2008 16:04:25 +0000 Received: from [74.95.2.169] (helo=kilo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY11l-000FmZ-BG for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 16:04:20 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id AF8D5558DB8; Tue, 26 Aug 2008 09:04:15 -0700 (PDT) Date: Tue, 26 Aug 2008 09:04:15 -0700 From: Eric Rescorla To: Ted Lemon Cc: Eric Rescorla , "namedroppers@ops.ietf.org WG" Subject: Re: Defining defense levels... In-Reply-To: References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> <1D346610-B056-4148-B4AF-786311A38613@nominum.com> <48B346A8.1080708@necom830.hpcl.titech.ac.jp> <163FF68C-E57E-47DD-B805-33E8BA0825C1@nominum.com> <20080826135608.CFC34557787@kilo.rtfm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080826160415.AF8D5558DB8@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Tue, 26 Aug 2008 08:26:52 -0700, Ted Lemon wrote: > > On Aug 26, 2008, at 6:56 AM, Eric Rescorla wrote: > > I'm sorry but, I still don't understand this argument, since many > > of the human factors tricks against TLS depend on getting the > > user to override the mechanical checks. Are you arguing that > > DNSSEC doesn't permit that kind of override or something else? > > DNSSEC makes it harder to convince the browser to throw up a form that > doesn't submit via SSL, or that submits to a different site via SSL. Well, I guess this is true, but I think it fixates on a specific attack modality that isn't currently very important (hijacking) while ignoring a modality that is currently very important (phishing). DNSSEC doesn't do anything to stop either of the things you mention when a phishing attack is in play. Obviously, we're talking here about what can be done with DNS, but I would observe that a set of browser mechanisms (e.g., PwdHash) that reduced your risk from inadvertantly or maliciously being directed to the wrong site would provide a significantly higher level of protection against both classes of attack. -Ekr -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 09:08:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF57C3A68C0; Tue, 26 Aug 2008 09:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 BdJXJCNXx35U; Tue, 26 Aug 2008 09:08:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B6E683A685A; Tue, 26 Aug 2008 09:08:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY0zP-000FNj-Db for namedroppers-data@psg.com; Tue, 26 Aug 2008 16:01:51 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY0zA-000FLi-PC for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 16:01:46 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7QG0Z4M004021; Tue, 26 Aug 2008 09:01:21 -0700 (PDT) Cc: Nicholas Weaver , "W.C.A. Wijngaards" , Namedroppers Message-Id: <4D7E2DC7-E366-4BCC-85A9-5D13DC4B876D@icsi.berkeley.edu> From: Nicholas Weaver To: Florian Weimer In-Reply-To: <824p576d9a.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: resolver side mitigation Date: Tue, 26 Aug 2008 09:01:21 -0700 References: <48B29A74.8020205@nlnetlabs.nl> <82iqtn6ejb.fsf@mid.bfk.de> <48B4162D.3020303@nlnetlabs.nl> <824p576d9a.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 26, 2008, at 7:51 AM, Florian Weimer wrote: > * W. C. A. Wijngaards: > >> Florian Weimer wrote: >>> In the end, the question whether RTT banding is useful boils down to >>> how we measure attack costs. Without proper cost metrics, it's hard >>> to tell if a countermeasure is a real improvement (and how it >>> interacts with other resolver features like lameness caches). >> >> Well, time to infection. Or is bandwidth better? > > Or packet count? Or traffic volume? It's not an easy answer, and > there are certainly lots of different trade-offs. Packet counts == traffic volume to rough approximation. And mitigations have different factors. Entropy defenses is all about increasing the packet count required: making the probability of a win per packet being lower. If there are cases, however, where an attacker can "run until win", entropy defenses don't affect time, but time*bandwidth product. If you add one bit to the entropy, you either double the time the attacker needs or double the bandwidth required. Cache policy is all about increasing the time required: If there are no "run until win" cases, the packet count for an attack is not increased, but because of the attacker's inability to run multiple races for the same name within a single TTL, the number of races which can be run per unit time goes down, and with even short TTLs being 60s, by a large amount. Although its still a time*bandwidth problem, if the attacker doubles his bandwidth, the probability of winning any given race goes up, so fewer races need to be run to win, but time ends up dominating if the authority increases the TTL to 60 minutes. Thus TTL is ONLY relevant as a defense if you can eliminate ALL "run until win" cases. So my personal belief is "Packets, Time, and Time*Bandwidth" are all important criteria, and different defenses affect different portions, and we should be precise about which defenses affect which aspects of an attack. >> If the NS or nameserver address query fails, simply give up on it. >> Do >> not back up to higher servers. When the next query for this >> bailiwick >> comes along, you'll get to the same spot again, and try again. > > But this doesn't deal with the situation that you keep querying the > wrong name server set, does it? If you ALSO validate this when you put it in the cache for the first time, as well as anytime it changes, it should actually keep the wrong nameserver set from getting into the cache in the first place. Basically, it works as follows. If the attacker is doing a blind attack against the NS RRset set because its not yet in the cache, thats a "Run once every TTL" attack (conventional blind attack), which requires a LOT of time given the normal TTL on the NS RRset. If instead, the attacker is doing a kaminski attack against the NS RRset, where he's taking advantage of trying to get the resolver to accept a change to the existing NS RRset, now the attacker doesn't have to win one race, he has to win two back-to-back races: one to make the resolver believe that the NS RRset has changed, which is immediately followed by a race where the resolver looks up the NS RRset again to see what the new value should be. Yet at the same time, such a policy allows the NS RRset to legitimately change. This is an example by what I mean about glue policy affecting the "run until win" property of a race: With the policy of validating the NS RRset separately, you've changed the conditions from "Run until Win" to either "Run once every TTL" or "Run until win two races in a row" for attacks on the NS RRset: an exponentially harder problem. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 09:24:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDC03A68DF; Tue, 26 Aug 2008 09:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.701 X-Spam-Level: **** X-Spam-Status: No, score=4.701 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, 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 cIxuyJ5WKrkf; Tue, 26 Aug 2008 09:24:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 35B853A67AB; Tue, 26 Aug 2008 09:24:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY1Gv-000I4j-UN for namedroppers-data@psg.com; Tue, 26 Aug 2008 16:19:57 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY1Gr-000I4C-BL for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 16:19:55 +0000 Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1KY1Gq-00059T-G2; Tue, 26 Aug 2008 17:19:52 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out6.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KY1Gp-0006jR-RN; Tue, 26 Aug 2008 17:19:51 +0100 Message-ID: <61826BD9B4714324BD44270123FAE270@localhost> From: "George Barwood" To: "Nicholas Weaver" Cc: References: <01e601c9016d$e4fa6d10$0302a8c0@localhost> <2B647646454B4A51958541C4929D14E6@localhost> Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 Date: Tue, 26 Aug 2008 17:19:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > There are also other heuristics (eg, has the MAC for the gateway changed) > which could also be used. It all gets rather complex really, and complexity is enemy of security. I might be connected via a mobile phone that keeps changing networks. Or an intermediate local computer that uses multiple NAT connections. Or all sorts of stuff that I have no idea about, or might happen in future. [ Please understand I'm no expert in networking ] > It is these resolvers that need to be protected against NATs. Well there are more than a billion Windows computers, all wide open AFAIK. No port randomization, no checking code, no repeat queries, nothing. I'm not exactly sure how vulnerable they are in practice, but it doesn't feel good to me. > I'd still rather "don't bother": Converging is going to be very long and > a lot of traffic, probably far more than "just don't cache" at all for > most cases. It's no bother really. It's a situation I don't expect in practice, but having something that will work (albeit with a second or two delay) if it ever does happen seems sensible. > And this is exactly why I believe in treating transactions vs caches > separately: How many cases are there where you have "Race until win" on a > transaction attack (vs getting something into the cache. Kaminski > attacks are cache attacks)? I haven't understood this concept. From my point of view being spoofed just once is unacceptable, if it can be defended. Besides, won't not caching opens up attacks? But as I don't understand, maybe it's unwise to comment. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 09:36:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEED63A6B7C; Tue, 26 Aug 2008 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 iCWl8RP7bb5Y; Tue, 26 Aug 2008 09:36:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 039BC3A6AA2; Tue, 26 Aug 2008 09:36:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY1R5-000K28-0I for namedroppers-data@psg.com; Tue, 26 Aug 2008 16:30:27 +0000 Received: from [64.18.2.218] (helo=exprod7og116.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY1R0-000K1S-K6 for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 16:30:24 +0000 Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Aug 2008 09:30:21 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 670451A8201; Tue, 26 Aug 2008 09:30:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.0.252] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 26 Aug 2008 09:30:20 -0700 CC: "namedroppers@ops.ietf.org WG" Message-ID: <7AAB854A-2744-484B-9961-F396C2EBCF25@nominum.com> From: Ted Lemon To: Eric Rescorla In-Reply-To: <20080826160415.AF8D5558DB8@kilo.rtfm.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Defining defense levels... Date: Tue, 26 Aug 2008 09:30:19 -0700 References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> <1D346610-B056-4148-B4AF-786311A38613@nominum.com> <48B346A8.1080708@necom830.hpcl.titech.ac.jp> <163FF68C-E57E-47DD-B805-33E8BA0825C1@nominum.com> <20080826135608.CFC34557787@kilo.rtfm.com> <20080826160415.AF8D5558DB8@kilo.rtfm.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 26, 2008, at 9:04 AM, Eric Rescorla wrote: > Obviously, we're talking here about what can be done with DNS, but I > would observe that a set of browser mechanisms (e.g., PwdHash) that > reduced your risk from inadvertantly or maliciously being directed to > the wrong site would provide a significantly higher level of > protection against both classes of attack. I agree that the main opportunity to improve the situation is in the browser. However, that's a long-term effort. DNSSEC is also a long- term effort, of course, but I have no idea which will bear fruit sooner, so I think it's prudent to work on both. Neither will bear fruit if we just sit on our hands. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 09:42:46 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBD23A6935; Tue, 26 Aug 2008 09:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=0.094, 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 mrUW6KCbiMAN; Tue, 26 Aug 2008 09:42:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 69A5C3A67AB; Tue, 26 Aug 2008 09:42:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY1Wk-000Ksn-83 for namedroppers-data@psg.com; Tue, 26 Aug 2008 16:36:18 +0000 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY1Wf-000Ks2-LJ for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 16:36:15 +0000 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 68E6C50846; Tue, 26 Aug 2008 09:47:24 -0700 (PDT) Date: Tue, 26 Aug 2008 09:47:24 -0700 From: Eric Rescorla To: Ted Lemon Cc: Eric Rescorla , "namedroppers@ops.ietf.org WG" Subject: Re: Defining defense levels... In-Reply-To: <7AAB854A-2744-484B-9961-F396C2EBCF25@nominum.com> References: <61C362F7-2F64-49E6-8207-D586A9E5C101@icsi.berkeley.edu> <7365DD04-80AE-4B92-A7E9-B42D1C5CF649@nominum.com> <605121B6-0D01-4F79-BF07-5C6FA5F2A845@ICSI.Berkeley.EDU> <85BEB333-AD22-4571-9CB9-D1A45B868E38@ICSI.Berkeley.EDU> <3C41C8BE-905A-46BD-9A18-A2186108A612@ICSI.Berkeley.EDU> <2FEBFB9F-43B7-465D-95D8-6E73ACFD64E9@nominum.com> <48B2AA2F.60805@necom830.hpcl.titech.ac.jp> <1D346610-B056-4148-B4AF-786311A38613@nominum.com> <48B346A8.1080708@necom830.hpcl.titech.ac.jp> <163FF68C-E57E-47DD-B805-33E8BA0825C1@nominum.com> <20080826135608.CFC34557787@kilo.rtfm.com> <20080826160415.AF8D5558DB8@kilo.rtfm.com> <7AAB854A-2744-484B-9961-F396C2EBCF25@nominum.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080826164724.68E6C50846@romeo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Tue, 26 Aug 2008 09:30:19 -0700, Ted Lemon wrote: > > On Aug 26, 2008, at 9:04 AM, Eric Rescorla wrote: > > Obviously, we're talking here about what can be done with DNS, but I > > would observe that a set of browser mechanisms (e.g., PwdHash) that > > reduced your risk from inadvertantly or maliciously being directed to > > the wrong site would provide a significantly higher level of > > protection against both classes of attack. > > I agree that the main opportunity to improve the situation is in the > browser. However, that's a long-term effort. DNSSEC is also a long- > term effort, of course, but I have no idea which will bear fruit > sooner, so I think it's prudent to work on both. Neither will bear > fruit if we just sit on our hands. I don't believe I said we should just sit on our hands. I trust you're not suggesting that I did. -Ekr -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 10:18:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0E23A6A27; Tue, 26 Aug 2008 10:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.428 X-Spam-Level: X-Spam-Status: No, score=-4.428 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 EBu1oW2hQmUQ; Tue, 26 Aug 2008 10:18:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F1773A6A53; Tue, 26 Aug 2008 10:18:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY22y-000PoR-TU for namedroppers-data@psg.com; Tue, 26 Aug 2008 17:09:36 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY22u-000PnZ-1A for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 17:09:34 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7QH9Thj016618; Tue, 26 Aug 2008 10:09:29 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: <61826BD9B4714324BD44270123FAE270@localhost> Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 X-Priority: 3 References: <01e601c9016d$e4fa6d10$0302a8c0@localhost> <2B647646454B4A51958541C4929D14E6@localhost> <61826BD9B4714324BD44270123FAE270@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 26 Aug 2008 10:09:29 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 26, 2008, at 9:19 AM, George Barwood wrote: >> There are also other heuristics (eg, has the MAC for the gateway >> changed) which could also be used. > > It all gets rather complex really, and complexity is enemy of > security. > I might be connected via a mobile phone that keeps changing networks. > Or an intermediate local computer that uses multiple NAT connections. > Or all sorts of stuff that I have no idea about, or might happen in > future. > [ Please understand I'm no expert in networking ] There are really two cases: Either you're NATed (between you and the remote resolver/authority) or you aren't. If you are NATed, port number offers NO entropy and NO protection, thus if you need entropy protection, and your default behavior is gaining it through port number, you MUST know if that protection is being stripped away. Fortunately, not only is this easy to check, but (see below) easy to determine if its changed with very VERY high probability. >> It is these resolvers that need to be protected against NATs. > > Well there are more than a billion Windows computers, all wide open > AFAIK. > No port randomization, no checking code, no repeat queries, nothing. > I'm not exactly sure how vulnerable they are in practice, but it > doesn't feel good to me. Well, the stub resolvers can be trivially fixed with regard to cache attacks by simply removing the local cache from the stub resolver (or just setting the max TTL to a minute). But that's cheating, and may have some bad properties. (Note that it loads the recursive resolvers far more than it loads the rest of the infrastructure, as the union of the recursive resolvers' caches is a superset of the stub resolver's cache.). More importantly: if your IP changes, your NAT state may have changed. But if your IP doesn't change, the probability of the NAT state changing is very, VERY low. Thus it is easy for a resolver to both determine if it is behind a NAT and if the status has changed. The only case where this fails is if you move between two NATs that assign you the same IP address, but where the first NAT doesn't rewrite port numbers but the second NAT does, but a secondary heuristic of "If in the private address space, ASSUME I'm natted" is probably safe to trap these few cases. So "Private IP? Assume I'm natted. Otherwise, IP changed? Recheck for NAT" is a heuristic that should work very well for protecting the stub resolvers, and works great for the NATed recursive resolvers (which don't have the mobility issues, so you only need to check for NAT on startup). >> I'd still rather "don't bother": Converging is going to be very >> long and a lot of traffic, probably far more than "just don't >> cache" at all for most cases. > > It's no bother really. It's a situation I don't expect in practice, > but having something that will work (albeit with a second or two > delay) if it ever does happen seems sensible. Unfortunately, it is "common enough" from what I understand, but no evidence for myself. :( >> And this is exactly why I believe in treating transactions vs >> caches separately: How many cases are there where you have "Race >> until win" on a transaction attack (vs getting something into the >> cache. Kaminski attacks are cache attacks)? > > I haven't understood this concept. From my point of view being > spoofed just once is unacceptable, if it can be defended. Besides, > won't not caching opens up attacks? Some observations: 1) In the blind attack, the attacker is the one generating the requests (through some mechanism) as well as the responses. 2) In ALL kaminski variants, and in MOST cases for traditional blind cache poisoning, the attacker really doesn't care about the result being returned, only that the result is CACHED for subsequent lookups, because the attacker generated the lookup in the first place! In fact, it is the process of CACHING that opens up to all the glue poisoning/cache poisoning attacks. If you don't have a cache at all, you can't have cache poisoning! This is why I believe it is critical to separate out the notion of "Transaction" attacks from "cache" attacks. In a blind transaction attack, the attacker ONLY needs to get you to accept the spoofed result for the current transaction. But such cases are rare, because the attacker must trick the victim into making the request AND acting on the request in a way which harms the victim: the only case I can come up with is cookie-stealing from badly secured web-apps, but such webapps are weak to CookieMonster, Sidejacking, and other attacks. In a blind cache attack, the attacker MUST get you to accept the spoofed result into the cache, but in return, the attacker only needs to trick the resolver into making the requests. Thus although I agree that we need to protect both, if, due to circumstances (eg, NAT) where we can only protect one at the cost to the other, it may be a worthwhile tradeoff. > But as I don't understand, maybe it's unwise to comment. a) I never let MY IGNORANCE stop me from commenting. Why should anybody else? b) I believe the position I'm expounding SHOULD be clearly explainable. If it doesn't make sense to you, its not a failure on your part, but a failure on my part! -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 11:02:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6993A6BB6; Tue, 26 Aug 2008 11:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.701 X-Spam-Level: **** X-Spam-Status: No, score=4.701 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, 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 7rQwKYpH+3Gv; Tue, 26 Aug 2008 11:02:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 395D03A6B14; Tue, 26 Aug 2008 11:02:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY2n8-0006a2-QN for namedroppers-data@psg.com; Tue, 26 Aug 2008 17:57:18 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY2n4-0006ZO-3E for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 17:57:16 +0000 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1KY2n3-0006DH-8A for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 18:57:13 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KY2n1-0007sb-V8 for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 18:57:12 +0100 Message-ID: <167184D1BF7447D9A5C8E3A0880FA7FB@localhost> From: "George Barwood" To: Subject: Treatment of Bad IDs in entropy calculation Date: Tue, 26 Aug 2008 18:57:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C907AD.8AFAF910" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C907AD.8AFAF910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just realised that Bad IDs can be neatly fitted into the entropy = discounting mechanism I described earlier ( http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01439.html = ). The idea is to take into account the observed rate at which we are being = attacked. After computing the amount of entropy as before, we subtract Log2( = BadIdCount ), where BadIdCount is the number of incorrect IDs observed = while waiting for a response to the query. For example: ID =3D 16 bits 0x20 =3D 13 bits ( wWw.eXAmPle.Com ) 200 Bad IDs seen =3D 8 bits Effective entropy =3D 16 + 13 - 8 =3D 21 bits. Dos ( denial of service ) can still occur if the attacker is sending = enough spoof packets, so that effective entropy is reduced to zero, but = if he can only spoof at moderate rates ( say a few thousand to the = correct port per second ), resolution can still occur, albeit with extra = requests. Can anyone see a problem with this? It seems quite elegant to me. ------=_NextPart_000_003D_01C907AD.8AFAF910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I just realised that Bad IDs can be = neatly fitted=20 into the entropy discounting mechanism I described earlier
 
( http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01439.= html ).
 
The idea is to take into account = the observed=20 rate at which we are being attacked.
 
After computing the amount of entropy = as before, we=20 subtract Log2( BadIdCount ), where BadIdCount is the number of incorrect = IDs=20 observed while waiting for a response to the query.
 
For example:
 
ID =3D 16 bits
0x20 =3D 13 bits ( wWw.eXAmPle.Com )
200 Bad IDs seen =3D 8 = bits
 
Effective entropy =3D 16 + 13 - 8 = =3D 21=20 bits.
 
Dos ( denial of service ) can still = occur if the=20 attacker is sending enough spoof packets, so that effective entropy is = reduced=20 to zero, but if he can only spoof at moderate rates ( say a few = thousand to=20 the correct port per second ), resolution can still occur, albeit = with=20 extra requests.
 
Can anyone see a problem with this? It = seems quite=20 elegant to me.
 
------=_NextPart_000_003D_01C907AD.8AFAF910-- -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 12:18:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C993A6849; Tue, 26 Aug 2008 12:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 50bvbnwae5gU; Tue, 26 Aug 2008 12:18:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F8AD3A6951; Tue, 26 Aug 2008 12:18:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY3wp-000Gag-9L for namedroppers-data@psg.com; Tue, 26 Aug 2008 19:11:23 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY3we-000GXD-Sw for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 19:11:15 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id DFA9711401C; Tue, 26 Aug 2008 19:11:05 +0000 (UTC) (envelope-from Evan_Hunt@isc.org) Received: by farside.isc.org (Postfix, from userid 10292) id A5776E6069; Tue, 26 Aug 2008 19:11:05 +0000 (UTC) Date: Tue, 26 Aug 2008 19:11:05 +0000 From: Evan Hunt To: George Barwood Cc: namedroppers@ops.ietf.org Subject: Re: Treatment of Bad IDs in entropy calculation Message-ID: <20080826191105.GA82992@isc.org> References: <167184D1BF7447D9A5C8E3A0880FA7FB@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <167184D1BF7447D9A5C8E3A0880FA7FB@localhost> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > After computing the amount of entropy as before, we subtract > Log2( BadIdCount ), where BadIdCount is the number of incorrect IDs > observed while waiting for a response to the query. Interesting thought. Why log2(), exactly? I'm not objecting, just not quite sure I follow your reasoning. I guess it's "we've gotten 256 bad packets, so let's make it 256 times harder to guess"--but why not 512, or 1024, or a million? Are you thinking of BadIdCount as counting incorrect responses for *all* pending queries, or just for race that's currently being run? -- Evan Hunt -- evan_hunt@isc.org Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 13:19:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0BF28C252; Tue, 26 Aug 2008 13:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 RMzJySBKzwhI; Tue, 26 Aug 2008 13:19:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 386E828C206; Tue, 26 Aug 2008 13:19:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY4tk-000PY0-Bu for namedroppers-data@psg.com; Tue, 26 Aug 2008 20:12:16 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY4tZ-000PWd-6K for namedroppers@ops.ietf.org; Tue, 26 Aug 2008 20:12:13 +0000 Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1KY4tH-0004a5-GR; Tue, 26 Aug 2008 21:11:47 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KY4tG-0000Gg-Ux; Tue, 26 Aug 2008 21:11:47 +0100 Message-ID: <0CB44CF261F34FAEB906BC873CFA2200@localhost> From: "George Barwood" To: "Evan Hunt" Cc: References: <167184D1BF7447D9A5C8E3A0880FA7FB@localhost> <20080826191105.GA82992@isc.org> Subject: Re: Treatment of Bad IDs in entropy calculation Date: Tue, 26 Aug 2008 21:11:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >> After computing the amount of entropy as before, we subtract >> Log2( BadIdCount ), where BadIdCount is the number of incorrect IDs >> observed while waiting for a response to the query. > > Interesting thought. Why log2(), exactly? I'm not objecting, just not > quite sure I follow your reasoning. I guess it's "we've gotten 256 bad > packets, so let's make it 256 times harder to guess"--but why not 512, or > 1024, or a million? At a trivial level, it's simply that probabilities are being computed in the log space ( or some similar jargon ). This seems reasonable, as high precision is not required. To try to be more explicit: Suppose I calculate the entropy for a single query / response to be 29 bits. This is intended to mean that an attacker has only a 1 in 2^29 chance of spoofing the response. If the attacker is using multiple guesses, then clearly his odds are improved by that factor. The nice part is that his multiple guesses can be easily seen, and the appropriate adjustment made, so that the calculated effective entropy is still realistic. > Are you thinking of BadIdCount as counting incorrect responses for *all* > pending queries, or just for race that's currently being run? Just for the race that is currently being run. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 17:27:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55453A681D; Tue, 26 Aug 2008 17:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.834 X-Spam-Level: X-Spam-Status: No, score=0.834 tagged_above=-999 required=5 tests=[AWL=3.433, BAYES_00=-2.599] 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 t4EAS9O-dLtC; Tue, 26 Aug 2008 17:27:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB0323A6C48; Tue, 26 Aug 2008 17:27:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY8jj-000ATD-2Q for namedroppers-data@psg.com; Wed, 27 Aug 2008 00:18:11 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KY8jf-000ASn-4D for namedroppers@ops.ietf.org; Wed, 27 Aug 2008 00:18:09 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7R0H5Hd050800; Wed, 27 Aug 2008 10:17:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808270017.m7R0H5Hd050800@drugs.dv.isc.org> To: Nicholas Weaver Cc: "George Barwood" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 In-reply-to: Your message of "Tue, 26 Aug 2008 10:09:29 MST." Date: Wed, 27 Aug 2008 10:17:05 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > On Aug 26, 2008, at 9:19 AM, George Barwood wrote: > > >> There are also other heuristics (eg, has the MAC for the gateway > >> changed) which could also be used. > > > > It all gets rather complex really, and complexity is enemy of > > security. > > I might be connected via a mobile phone that keeps changing networks. > > Or an intermediate local computer that uses multiple NAT connections. > > Or all sorts of stuff that I have no idea about, or might happen in > > future. > > [ Please understand I'm no expert in networking ] > > There are really two cases: Either you're NATed (between you and the > remote resolver/authority) or you aren't. > > If you are NATed, port number offers NO entropy and NO protection, If you are NAT'd the port number MAY offer you no protection. There are NAT's which attempt to preserve port numbers and actually do a pretty good job of doing that. If you are NAT'd the NAT MAY provide protection for nameservers that do not randomize their source ports by randomising the source port as a side effect of the NAT process. There are also NAT's which serialize the ports and NAT's which only emit one port and potentially serialize the qid as well. The only thing you can say about NATs is because there is no standard they can be doing ANYTHING to the queries. This is one of the reasons NAT's are a abomination that people should be working to remove as soon as possible. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 26 19:26:11 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9C828C273; Tue, 26 Aug 2008 19:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, 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 9x770P5gN3jn; Tue, 26 Aug 2008 19:26:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6419128C259; Tue, 26 Aug 2008 19:26:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYAdi-000PGR-AW for namedroppers-data@psg.com; Wed, 27 Aug 2008 02:20:06 +0000 Received: from [143.215.128.120] (helo=fritz.cc.gt.atl.ga.us) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYAdd-000PFO-Hr for namedroppers@ops.ietf.org; Wed, 27 Aug 2008 02:20:04 +0000 Received: from fritz.cc.gt.atl.ga.us (localhost.cc.gt.atl.ga.us [127.0.0.1]) by fritz.cc.gt.atl.ga.us (Postfix) with ESMTP id 16BF245020; Tue, 26 Aug 2008 22:23:32 -0400 (EDT) Received: (from dagon@localhost) by fritz.cc.gt.atl.ga.us (8.13.8/8.13.8/Submit) id m7R2NVbs031633; Tue, 26 Aug 2008 22:23:31 -0400 (EDT) (envelope-from dagon) Date: Tue, 26 Aug 2008 22:23:30 -0400 From: David Dagon To: George Barwood Cc: namedroppers@ops.ietf.org Subject: Re: Treatment of Bad IDs in entropy calculation Message-ID: <20080827022330.GA31154@fritz.cc.gt.atl.ga.us> References: <167184D1BF7447D9A5C8E3A0880FA7FB@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <167184D1BF7447D9A5C8E3A0880FA7FB@localhost> User-Agent: Mutt/1.5.15 (2007-04-06) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Aug 26, 2008 at 06:57:09PM +0100, George Barwood wrote: > I just realised that Bad IDs can be neatly fitted into the entropy discounting mechanism I described earlier > > ( http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01439.html ). > In short: I suspect you are describing a variation of channel capacity, or some measure of signal/noise. (There are many valid security applications of such measurements.) Caveat: I'm still digesting the GbDns source. I'd like to offer some preliminary comments on your minimum entropy calculation, based on your email in this forum. Please correct me if I've missed your point. > The idea is to take into account the observed rate at which we are > being attacked. I think there are two (or more) ways to understand your minimum entropy analysis: a) from a DNS operator's perspective, the minimum entropy is a potential distraction. For some DNS operators, this is not as important as the discrete probability that a forged packet might match the {qid, sport, 0x20, etc.} transaction tuple. Let's use your example to explain: > For example: > > ID = 16 bits > 0x20 = 13 bits ( wWw.eXAmPle.Com ) > 200 Bad IDs seen = 8 bits > > Effective entropy = 16 + 13 - 8 = 21 bits. Generally, if there are 2^{N} possible unique transaction tokens, the naive probability of success is 200/(2^{N}) ... and much, much more if there's a birthday window, of course. Precisely, the failure of such a poisoning attack is: \[ 1-p(n) = \bar{p}(n) = \prod_{k=0}^{n-1} \left(1 - \frac{1}{N-k}\right) \] But most DNS servers have long since implemented duplicate upstream query protection. We can therefore use the simple fraction to emphasize independence: the 200st failure does not make the 201st guess any more likely to (independently) match a transaction ID (again: *assuming* there is no birthday window, which otherwise significantly reduces the transaction integrity.) Another perspective, one I suspect you're considering, is: b) From a channel capacity perspective, the bad guesses are divisive (log 2) of the total keyspace, exactly as you proposed. Attacks are 'noise' compared to 'signal' from messages. Your ratio is not exactly S/N (you did not provide a bandwidth dimension). But otherwise, it's the right idea and (as we say in Georgia) "good enough for government work". Seriously though, this perspective is useful for high-level decisions, such as research monitoring, characterizing DNS poisoning attempts as a "signal/noise" problem, and the mutual information found in large numbers of DNS transactions and poisonings. I.e., one might care about the macro-level performance of DNS messaging as a channel to plan a lower-bound. A simple example: I might not make an embedded device that uses only 16 bits for TX tracking, based on minimum entropy analysis; I might instead consider the benefits of sport randomization (perhaps too expensive on my chosen platform), or 0x20 (variable, depending on the target users[0]), or some other protections. With a bandwidth dimension (not covered in minimum entropy analysis, AFAIK), one can perform this sort of risk analysis. > Can anyone see a problem with this? I think you'll encounter differences of opinion, depending on the operator's perspective. These may be expressed in terms that range from sympathetic/appreciative to unhelpful/cynical. But your general S/N analysis (bandwidth and minimum entropy) is quite useful for lower-bound estimation, I think. Disagreement will depend on values: Local administrators will want assurances that each malicious response has a low discrete probability of being successful. Network architects (particularly those realistic about DNSSEC deployment, or facing hardware barriers for sport adoption), will appreciate a S/N analysis. In some networks, the need for improved security is measurably more urgent, based on your minimum entropy analysis. The solutions may include not only sport randomization, but 0x20 encoding, DNSSEC, stealthy forwarding, rfc 2181 gymnastics/policy, TCP fallback, etc. Each solution has a cost, and may not be acceptable for everyone else, or seen as anti-social if widely deployed. But you've proposed a way to measure the (bandwidth-adjusted) benefit--one needs only compare this to costs. I've not seen that before; that's useful. I don't know if I've described the differences in perspective correctly. I'd recommend reviewing the 'draft-wijngaards-dnsext-resolver-side-mitigation-00' document, which seems to nicely capture much of the conversation Paul Vixie, Nick Weaver and others have offered in this forum re: modality. > It seems quite elegant to me. I agree; just add bandwidth (or point out where I've missed this). I am still looking for a universal solution that satisfies the needs of local admins ("make me secure; at all times; damn your numbers"), and the oft-overlooked realities of large-scale DNS deployments ("locally clued users may be secure; but how can we herd 16M+ cats into upgrading?") [0] We've completed an overview of DNS-0x20, to appear at the CCS08 conference: http://fritz.cc.gt.atl.ga.us/ccs08/ccs202-dagon.pdf We state: we find roughly ~12-16 bits; you found ~12. This is a bias in any measurement, and there is no 'right' number, only densities. Where one stops caring is a cost function, that you seem to propose. -- David Dagon /"\ "When cryptography dagon@cc.gatech.edu \ / ASCII RIBBON CAMPAIGN is outlawed, bayl Ph.D. Student X AGAINST HTML MAIL bhgynjf jvyy unir Georgia Inst. of Tech. / \ cevinpl." -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 27 10:13:29 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A993A682B; Wed, 27 Aug 2008 10:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=0.049, 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 62bAHS8S6GAT; Wed, 27 Aug 2008 10:13:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0A1F3A68E8; Wed, 27 Aug 2008 10:13:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYOVj-000AEU-IS for namedroppers-data@psg.com; Wed, 27 Aug 2008 17:08:47 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYOVO-000A9K-GD for namedroppers@ops.ietf.org; Wed, 27 Aug 2008 17:08:31 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7RHBSQQ013937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Aug 2008 10:11:31 -0700 Date: Wed, 27 Aug 2008 13:08:22 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Protecting caches? Message-ID: <20080827170822.GH18946@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Wed, 27 Aug 2008 10:11:32 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: No hat. Dear colleagues, In the discussion around forgery resilience so far, I've seen some discussion on how to detect cache poisoning attempts, and some discussion on how to foil the attack itself by reducing the ability of the attacker to send bad data to a resolver. (I've also seen the observation, several times, that DNSSEC will solve these problems anyway, so we should concentrate on deploying that; that's an operational problem now, and not on-topic for this list.) Some of the proposals floated entail protocol (or maybe near-protocol -- "operational conventions", to borrow Joe Abley's nice phrase) changes, and so are correctly on-topic for the WG. What I haven't seen much of is discussion of protecting caches _as such_. That is, given that we are going to cache, are there techniques that solve the dangers of a cache other than just preventing the cache from ever having the wrong data in the first place? Best regards, A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 27 10:13:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A113A6BAF; Wed, 27 Aug 2008 10:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] 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 11vlYjSHug+a; Wed, 27 Aug 2008 10:13:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BF573A68E8; Wed, 27 Aug 2008 10:13:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYOSF-0009dX-EP for namedroppers-data@psg.com; Wed, 27 Aug 2008 17:05:11 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYOS7-0009bw-Mp for namedroppers@ops.ietf.org; Wed, 27 Aug 2008 17:05:09 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m7RH4pYG083490; Wed, 27 Aug 2008 19:04:51 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200808271704.m7RH4pYG083490@givry.fdupont.fr> From: Francis Dupont To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: SCTP (and DCCP) In-reply-to: Your message of Sun, 24 Aug 2008 15:41:26 -0000. <71267.1219592486@nsa.vix.com> Date: Wed, 27 Aug 2008 19:04:51 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: > DCCP is younger but its "market" is far larger. by "larger" do you mean "number of flows now using it" or something else? => the potential market: SCTP was designed for SS7 and should replace TCP extremely slowly, DCCP is for VoIP & co. Regards Francis.Dupont@fdupont.fr PS: note I have been a fan of SCTP for many years. I am just old enough to understand SCTP adoption should take at least a decade. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 08:00:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB033A6CA9; Thu, 28 Aug 2008 08:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.046 X-Spam-Level: X-Spam-Status: No, score=-5.046 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 jg9BEoIuWoZ2; Thu, 28 Aug 2008 08:00:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6B113A6CD1; Thu, 28 Aug 2008 08:00:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYikq-00048m-NY for namedroppers-data@psg.com; Thu, 28 Aug 2008 14:45:44 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYikg-00046t-Dm for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 14:45:39 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 8A6741C018C; Thu, 28 Aug 2008 16:45:30 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 840251C0182; Thu, 28 Aug 2008 16:45:30 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7832C6C0001; Thu, 28 Aug 2008 16:45:30 +0200 (CEST) Date: Thu, 28 Aug 2008 16:45:30 +0200 From: Stephane Bortzmeyer To: bert hubert , namedroppers@ops.ietf.org, davidu@everydns.net Subject: Re: EDNS PING first draft uploaded Message-ID: <20080828144530.GA15926@nic.fr> References: <20080817202546.GA18583@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080817202546.GA18583@outpost.ds9a.nl> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Aug 17, 2008 at 10:25:46PM +0200, bert hubert wrote a message of 36 lines which said: > a draft which describes a very simple EDNS PING option. Although you mention the DNS cookies proposal (draft-eastlake-dnsext-cookies), you offer no rationale of why your solution is "better". Unlike draft-reid-dnsext-aleatoric, which follows a different path, EDNS ping seems so close of the cookies that one can wonder why there are two proposals. At first reading, the differences seem to be: - EDNS ping may be simpler to implement - the draft on EDNS ping is quite... drafty and, for instance, does not address downgrade attacks (compare with the use of "soft state" in cookies) -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 08:14:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33FA53A6B6A; Thu, 28 Aug 2008 08:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.988 X-Spam-Level: X-Spam-Status: No, score=-4.988 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 Xax5VNdSVvqd; Thu, 28 Aug 2008 08:14:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43A613A6880; Thu, 28 Aug 2008 08:14:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYj2v-0006ao-Fg for namedroppers-data@psg.com; Thu, 28 Aug 2008 15:04:25 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYj2n-0006ZY-Bb for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 15:04:23 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id EB9B91C015A; Thu, 28 Aug 2008 17:04:15 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E65C21C00F4; Thu, 28 Aug 2008 17:04:15 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id E4A4C6C0001; Thu, 28 Aug 2008 17:04:15 +0200 (CEST) Date: Thu, 28 Aug 2008 17:04:15 +0200 From: Stephane Bortzmeyer To: "W.C.A. Wijngaards" Cc: Namedroppers Subject: Re: resolver side mitigation Message-ID: <20080828150415.GA18080@nic.fr> References: <48B29A74.8020205@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B29A74.8020205@nlnetlabs.nl> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Aug 25, 2008 at 01:41:40PM +0200, W.C.A. Wijngaards wrote a message of 14 lines which said: > I've submitted a draft with the resolver side mitigations that I > envision for Unbound. > > http://www.ietf.org/internet-drafts/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt > o source address randomisation > > If the resolver has multiple public IP addresses these can be used > to randomise with. With IPv4, this would add only one or two bits of entropy. But, with IPv6, there is a huge potential for randomisation, may be 64 bits of entropy if the resolver has a full /64. However, it has implications for the router's Neighbor Discovery cache. Did anyone tried aggressive source address randomisation with IPv6 to see until where the router and/or server OS can go? > Specifically, they must not put the costs of the solution with 3rd > parties. That's a noble goal but it is impossible to follow completely. For instance: > o Authority queries for nameserver addresses, A and AAAA. > > Same idea, like NS query above. You ask for A or AAAA records > directly at the authoritative server. This would increase the load of the authoritative servers and therefore would put a part of the cost (an acceptable one, IMHO) on third parties. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 08:42:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FD73A6CE8; Thu, 28 Aug 2008 08:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.947 X-Spam-Level: X-Spam-Status: No, score=-4.947 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 NoT+tvVE5d4a; Thu, 28 Aug 2008 08:42:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7ACEE3A6880; Thu, 28 Aug 2008 08:42:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjPk-0009ko-Hu for namedroppers-data@psg.com; Thu, 28 Aug 2008 15:28:00 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjPc-0009j5-LU for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 15:27:57 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 6989F1C0170; Thu, 28 Aug 2008 17:27:51 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 649121C016B; Thu, 28 Aug 2008 17:27:51 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 572F7A1D95D; Thu, 28 Aug 2008 17:27:51 +0200 (CEST) Date: Thu, 28 Aug 2008 17:27:51 +0200 From: Stephane Bortzmeyer To: Jim Reid Cc: Namedroppers Subject: Re: Fwd: New Version Notification for draft-reid-dnsext-aleatoric-00 Message-ID: <20080828152751.GA21778@nic.fr> References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Aug 06, 2008 at 05:13:00PM +0100, Jim Reid wrote a message of 38 lines which said: > This idea is probably even uglier than the 0x20 draft. :-) I like it although I'm not sure it is better than cookies: after all, a name server software has to be changed in one way or the other. If we are going to add AL support, why not directly adding cookies? AL seems interesting only if EDNS support is unrealistic (too complicated for the name server software or blocked by a stupid firewall). Is it a sufficient motivation? Also, you do not address downgrade attacks, apparently? How to know if a response without AL comes from an old server, not upgraded, or from an attacker? -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 08:44:31 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28FB328C1AE; Thu, 28 Aug 2008 08:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 exrtwQb4BNGW; Thu, 28 Aug 2008 08:44:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B6C1228C152; Thu, 28 Aug 2008 08:44:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjTD-000AAh-5J for namedroppers-data@psg.com; Thu, 28 Aug 2008 15:31:35 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjT4-000A9X-LR for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 15:31:28 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7SFVPXZ024261; Thu, 28 Aug 2008 08:31:25 -0700 (PDT) Message-Id: <3D5C5CD3-09AB-4555-9312-FB6A11706C38@icsi.berkeley.edu> From: Nicholas Weaver To: Namedroppers Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Stupid questions on stub resolvers... Date: Thu, 28 Aug 2008 08:31:25 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Do people know of any stub resolvers which cache beyond the direct answer when asking a recursive resolver? EG, if the recursive resolver when asked "www.foo.com", also returns an additional record "advertisements.foo.com A 12.34.56.78", will any known stub resolvers cache that additional value? -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 08:56:27 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3023A6CCE; Thu, 28 Aug 2008 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 uxFdO0jM8odt; Thu, 28 Aug 2008 08:56:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58DCD3A6A43; Thu, 28 Aug 2008 08:56:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjhr-000BwU-46 for namedroppers-data@psg.com; Thu, 28 Aug 2008 15:46:43 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjhm-000Bvh-Tp for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 15:46:41 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7SFkJpq026542; Thu, 28 Aug 2008 08:46:24 -0700 (PDT) Cc: Nicholas Weaver , "W.C.A. Wijngaards" , Namedroppers Message-Id: <25165DA5-9B95-45DA-9B38-3D7B67B948D7@icsi.berkeley.edu> From: Nicholas Weaver To: Stephane Bortzmeyer In-Reply-To: <20080828150415.GA18080@nic.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: resolver side mitigation Date: Thu, 28 Aug 2008 08:46:19 -0700 References: <48B29A74.8020205@nlnetlabs.nl> <20080828150415.GA18080@nic.fr> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 28, 2008, at 8:04 AM, Stephane Bortzmeyer wrote: >> o Authority queries for nameserver addresses, A and AAAA. >> >> Same idea, like NS query above. You ask for A or AAAA records >> directly at the authoritative server. > > This would increase the load of the authoritative servers and > therefore would put a part of the cost (an acceptable one, IMHO) on > third parties. I've been looking at this myself, from a trace based viewpoint. Some preliminary suggestion on the traces I have is that the MOST paranoid AND agressive policy (which I believe ends up being roughly equivelent to the new policy for Unbound): + Do not accept ANY data into the cache that was not a direct answer. + Deliberately fetch all data that wasn't a direct answer and isn't already in the cache independently to place in the cache. Thus, eg, for the NS RRSet, it generates both a separate fetch for the NS RRSet, and a fetch for each name in that RRSet. This policy increases the number of queries outbound from the resolvers by about 70-90%, so its less than double. It would not increase the latency of queries however, except in the case of CNAME chains, assuming you are still able to use the glue records in the local context of an individual query. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 09:05:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E493A6CC6; Thu, 28 Aug 2008 09:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553] 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 c2hmvn8TTlJT; Thu, 28 Aug 2008 09:05:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 234E33A67ED; Thu, 28 Aug 2008 09:05:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjpe-000Cw4-DT for namedroppers-data@psg.com; Thu, 28 Aug 2008 15:54:46 +0000 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYjpZ-000Cuz-DU for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 15:54:43 +0000 Received: from [195.54.233.69] (HELO gromit.rfc1035.com) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTP id 342739; Thu, 28 Aug 2008 16:54:40 +0100 Cc: Namedroppers Message-Id: <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> From: Jim Reid To: Stephane Bortzmeyer In-Reply-To: <20080828152751.GA21778@nic.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Date: Thu, 28 Aug 2008 16:54:39 +0100 References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 28 Aug 2008, at 16:27, Stephane Bortzmeyer wrote: > AL seems interesting only if EDNS support is unrealistic (too > complicated > for the name server software or blocked by a stupid firewall). Is it a > sufficient motivation? AL works (for some definition of work) regardless of EDNS support. So I suppose that is some sort of motiovation. Whether it's sufficient motivation is up to this WG to decide. > Also, you do not address downgrade attacks, apparently? How to know if > a response without AL comes from an old server, not upgraded, or from > an attacker? It doesn't handle downgrade attacks. So AL in its current incantation is flawed. OTOH, it does raise the barrier for cache poisoners. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 09:24:35 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E790F3A692B; Thu, 28 Aug 2008 09:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, 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 QLC-2A9rU0Ou; Thu, 28 Aug 2008 09:24:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CD073A67DF; Thu, 28 Aug 2008 09:24:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYk9b-000FVG-1c for namedroppers-data@psg.com; Thu, 28 Aug 2008 16:15:23 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYk9X-000FUf-JJ for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 16:15:21 +0000 Received: from wlan39-077.mdr.icann.org (wlan39-077.mdr.icann.org [192.0.39.77]) by virtualized.org (Postfix) with ESMTP id B2A182F9549; Thu, 28 Aug 2008 09:15:18 -0700 (PDT) Cc: Namedroppers Message-Id: <34C28289-2299-488A-8B42-F32F1B3F4197@virtualized.org> From: David Conrad To: Nicholas Weaver In-Reply-To: <3D5C5CD3-09AB-4555-9312-FB6A11706C38@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Stupid questions on stub resolvers... Date: Thu, 28 Aug 2008 09:15:17 -0700 References: <3D5C5CD3-09AB-4555-9312-FB6A11706C38@icsi.berkeley.edu> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 28, 2008, at 8:31 AM, Nicholas Weaver wrote: > Do people know of any stub resolvers which cache beyond the direct > answer when asking a recursive resolver? If you've installed BIND: % man lwresd Regards, -drc -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 09:25:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467AB3A6963; Thu, 28 Aug 2008 09:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=-0.124, 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 gxgXpUP8WwdN; Thu, 28 Aug 2008 09:25:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2174C3A694E; Thu, 28 Aug 2008 09:25:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYkBV-000Fnj-1x for namedroppers-data@psg.com; Thu, 28 Aug 2008 16:17:21 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYkBM-000Fmf-QN for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 16:17:15 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7SGKFTZ022809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Aug 2008 09:20:19 -0700 Date: Thu, 28 Aug 2008 12:17:08 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: REMINDER: rfc2672bis WGLC expiring! Message-ID: <20080828161708.GR23588@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 28 Aug 2008 09:20:19 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, We posted the WGLC for draft-ietf-dnsext-rfc2672bis-dname-14 on 2008-07-31. The WGLC is due to close at 17:00 EDT today. We have not had anywhere close to the five required reviewers for the document say something about it. (We had two comments on the -14 draft immediately after it was posted, to which the editors responded, and no responses to the WGLC itself. If the two people who responded to the posting of the draft say that, apart from their one request, they otherwise support sending the draft along, that would help, but it would still leave us at least 3 short.) If you have read the document and think it should be sent along for the status of Proposed Standard, please post something to the list to this effect. If you have not read the document, and won't have time to do a review prior to the close of the WGLC today, but _will_ commit to reviewing the document in the near future (say, the next 7 days), please post that to the list. If we have interest in the document, and people just haven't had time due to vacations or whatever, we can certainly extend the LC a little longer. Remember that, if the document does not get adequate review and support, our convention requires that we do not send it along for publication. Thanks, Andrew (for the Chairs) -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 10:01:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700D53A6A43; Thu, 28 Aug 2008 10:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 nHNnSmXMA1pO; Thu, 28 Aug 2008 10:01:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C4343A67AE; Thu, 28 Aug 2008 10:01:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYkiu-000KV3-Lo for namedroppers-data@psg.com; Thu, 28 Aug 2008 16:51:52 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYkip-000KUK-Fp for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 16:51:50 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7SGpG7X006871; Thu, 28 Aug 2008 09:51:41 -0700 (PDT) Cc: Nicholas Weaver , Stephane Bortzmeyer , Namedroppers Message-Id: From: Nicholas Weaver To: Jim Reid In-Reply-To: <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Date: Thu, 28 Aug 2008 09:51:16 -0700 References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The problem I have with this proposal, and any proposal that requires both resolver and authority changes is as follows: DNSSEC's major deployment problem is that it requires double-sided deployment: changes to both the resolver and authority to have an effect, thus in the case of partial deployment, only the intersection of changed-resolvers & changed-authorities sees a benefit. Thus if a proposed mitigation for blind injection requires double- sided changes, why not just do DNSSEC, especially if you make it easy to DO DNSSEC? Perhaps, by following the lead of some of SSH's usability hacks, just make it easy to do in a manner which is insecure to authority compromise. This contrasts greatly with other methods of increasing entropy of cached entries: Port, address, and 0x20 randomization take advantage of how existing authorities work, so it requires only changes to the resolver. Likewise, "duplicate and cache-on-agreement" will result in entropy increases to arbitrary values and the only cases where you fail to cache are ones where you get multiple return values for the same query, and as others have pointed out on the list, you could recurse until you get a converged entry appearing in multiple responses, so again, its a way of increasing entropy (to arbitrary limits, too!) that does not The minor problem I have is there seems to be a discomfort with entropy: if you can get the query entropy to be over 40b for the purposes of caching, you can make blind attacks on the cache completely infeasible with just a single counter of bad responses: 10M packets to have a .001% chance of poisoning a single entry, and if you wipe the cache at that point, well, 10M packets to cause the cache to void 1M entries? Hardly seems a DOS to me. Especially if combined with cache policies on the resolver which eliminate all "Race until win" conditions. And also "void on changed double-response" detection if you are willing to manage the outstanding state. After all, blind attacks on TCP can be done as well: Observe that these days, most systems don't actually respond to unsolicited packets with RSTs, so if the legit packets are received by the destination but the destination doesn't see the sequencing right, they will be ignored. And even if not, if the attacker is closer than the legit destination, the legit RSTs will never be received. Guess the sender's source port (predictible) and sequence number and respond with an appropriate SYN/ACK. Then guess that they will do the DNS request, and send the response with the next in sequence + a FIN. Thus instead of blindly sending individual packets with a random ID, you're sending a blind string of 3 packets (SYN/ACK, data, FIN) where you use random SEQ # and random TXID, with a tiny gap between the SYN/ ACK and the data to give the host time to process. This is 16b entropy for the transaction ID, but 32b of entropy for initial sequence #, making it a 48b of entropy problem. TCP, the "Ultimate fallback" is really just an easy way of adding 32b of entropy to a query: getting the query entropy to 48b. Why isn't this done to attack other protocols? Because attackers have better things to do than bang against the network on a 48b entropy problem. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 10:28:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC90B3A686B; Thu, 28 Aug 2008 10:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553] 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 HgNsO3fDofBT; Thu, 28 Aug 2008 10:28:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E494E3A67E7; Thu, 28 Aug 2008 10:28:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYl9O-000Nvo-8q for namedroppers-data@psg.com; Thu, 28 Aug 2008 17:19:14 +0000 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYl9G-000Nv0-63 for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 17:19:09 +0000 Received: from [195.54.233.69] (HELO gromit.rfc1035.com) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTP id 342755; Thu, 28 Aug 2008 18:19:04 +0100 Cc: Namedroppers Message-Id: <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> From: Jim Reid To: Nicholas Weaver In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Date: Thu, 28 Aug 2008 18:19:04 +0100 References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 28 Aug 2008, at 17:51, Nicholas Weaver wrote: > Thus if a proposed mitigation for blind injection requires double- > sided changes, why not just do DNSSEC, especially if you make it > easy to DO DNSSEC? This is like saying let's solve world hunger by just giving everyone enough food: naive and not particularly helpful. Deployment of DNSSEC is going to take a Long, Long Time, even with much improved tools. So what does the world do until then? Ugly kludges like AL or 0x20 are relatively painless to deploy, so they can buy some breathing space until the root's signed, everyone's got DNSSEC-aware resolvers and there are plenty of decent tools to sign zones, manage keys and debug validation failures. In this context, "deploy" means nothing more than update your DNS software. Even when this isn't straightforward, it's still far easier than all the goop that has to go alongside updating DNS software to accommodate DNSSEC deployment: eg configure and maintain trust anchors, generate keys, change zone management tools/processes to incorporate signing, handle key rollover, etc, etc. It would be wonderful if these things could be reduced to close-to-zero effort. But DNSSEC isn't like that. Sigh. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 10:37:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1546B3A6CA8; Thu, 28 Aug 2008 10:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 NZ6wnIf7Ebqc; Thu, 28 Aug 2008 10:37:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 318613A688F; Thu, 28 Aug 2008 10:37:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYlJn-000P6p-DS for namedroppers-data@psg.com; Thu, 28 Aug 2008 17:29:59 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYlJa-000P59-T7 for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 17:29:57 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 65E1033C59; Thu, 28 Aug 2008 10:29:46 -0700 (PDT) Date: Thu, 28 Aug 2008 10:29:46 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stephane Bortzmeyer Cc: "W.C.A. Wijngaards" , Namedroppers Subject: Re: resolver side mitigation In-Reply-To: <20080828150415.GA18080@nic.fr> References: <48B29A74.8020205@nlnetlabs.nl> <20080828150415.GA18080@nic.fr> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Thu, 28 Aug 2008 17:04:15 +0200, Stephane Bortzmeyer wrote: > > http://www.ietf.org/internet-drafts/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt > > > o source address randomisation > > > > If the resolver has multiple public IP addresses these can be used > > to randomise with. > > With IPv4, this would add only one or two bits of entropy. > > But, with IPv6, there is a huge potential for randomisation, may be 64 > bits of entropy if the resolver has a full /64. > > However, it has implications for the router's Neighbor Discovery > cache. Did anyone tried aggressive source address randomisation with > IPv6 to see until where the router and/or server OS can go? I've not played with this idea yet, but if I were to do it, I would reserve a separate /64 for the server machine, assign any addresses under that prefix on some "loopback" interface (with disabling DAD), and let the server announce the prefix for neighboring routers (and have them accept the route). --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 10:54:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FF628C306; Thu, 28 Aug 2008 10:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.871 X-Spam-Level: X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, 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 LD-9c1amYjCJ; Thu, 28 Aug 2008 10:54:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B8D728C2F9; Thu, 28 Aug 2008 10:54:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYlYT-0000dS-PY for namedroppers-data@psg.com; Thu, 28 Aug 2008 17:45:09 +0000 Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYlYP-0000cp-TH for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 17:45:07 +0000 Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KYlYP-00045m-0p; Thu, 28 Aug 2008 13:45:05 -0400 Message-ID: <48B6E420.6020909@ca.afilias.info> Date: Thu, 28 Aug 2008 13:45:04 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: REMINDER: rfc2672bis WGLC expiring! References: <20080828161708.GR23588@commandprompt.com> In-Reply-To: <20080828161708.GR23588@commandprompt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: briand@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew Sullivan wrote: > Dear colleagues, > > We posted the WGLC for draft-ietf-dnsext-rfc2672bis-dname-14 on > 2008-07-31. > > The WGLC is due to close at 17:00 EDT today. > > We have not had anywhere close to the five required reviewers for the > document say something about it. (We had two comments on the -14 > draft immediately after it was posted, to which the editors responded, > and no responses to the WGLC itself. If the two people who responded > to the posting of the draft say that, apart from their one request, > they otherwise support sending the draft along, that would help, but > it would still leave us at least 3 short.) > > If you have read the document and think it should be sent along for > the status of Proposed Standard, please post something to the list to > this effect. > > I have read the document, and understand it. I am in favour of it advancing to Proposed Standard. Brian Dickson > If you have not read the document, and won't have time to do a review > prior to the close of the WGLC today, but _will_ commit to reviewing > the document in the near future (say, the next 7 days), please post > that to the list. If we have interest in the document, and people > just haven't had time due to vacations or whatever, we can certainly > extend the LC a little longer. > > Remember that, if the document does not get adequate review and > support, our convention requires that we do not send it along for > publication. > > Thanks, > > Andrew (for the Chairs) > > -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 12:34:30 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1B33A6A8D; Thu, 28 Aug 2008 12:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_20=-0.74, J_CHICKENPOX_31=0.6] 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 paetqukcwhpO; Thu, 28 Aug 2008 12:34:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39B143A686B; Thu, 28 Aug 2008 12:34:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYn4b-000C8Z-UB for namedroppers-data@psg.com; Thu, 28 Aug 2008 19:22:25 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYn4V-000C7t-S4 for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 19:22:22 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C6CE6A66AC for ; Thu, 28 Aug 2008 19:22:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: kaminsky resistance, section by section X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 28 Aug 2008 19:22:06 +0000 Message-ID: <2041.1219951326@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: C6CE6A66AC.1F80D X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: the perfect platonic form of kaminsky's observation is that the target of the poison does not have to match the q-tuple. all else is a reflection of that form, including ttl bypasses (ADNS which fails to answer unknown qtype, middleboxes which block or drop unknown qtype, RDNS which fails to cache some qtypes, etc), and no matter what is the form of the non-qtuple-matching poison. i've watched with interest as weaver, ohta, and others have explored ways to protect against each known form of poison or to protect against any form of non-qtuple-matching poison. yesterday leo bicknell of ISC re-raised a proposal that seemed to him related to dns-0x20 but wasn't, and which had seemed to me earlier on to be "too partial" to be worth its deployment cost, but the debates have swirled long enough now that i think there's "meat" here. section by section, then, here's what we could do. the header section is not an issue since it contains only flags and metadata. the question section is not an issue since it can by universal convention only hold one q-tuple and that q-tuple is both well understood and well extended by dns-0x20. of the other three sections there is much to say. note in advance that nothing i'll say removes the need for port randomization or DNSSEC, but i'm starting to be of the opinion that (a) we don't have to live with the ten-hour attack, and (b) we have more we must do while we complete the long march toward DNSSEC. it's nec'y that the result of all transactions be cached, whether that result was NXDOMAIN, NODATA, SERVFAIL, timeout, or live data. failing to cache the result of "this q-tuple from that ADNS", means that a given q-tuple can be serially attacked. it's also nec'y that multiple simultaneous outstanding upstream transactions not be the result of multiple simultanous cache misses from downstream queries, or else any given q-tuple can be attacked in parallel. caches must be deep enough to hold at least several seconds of full rate churn, so that no q-tuple can be attacked multiple times per second. for the answer section it's essential that only records whose owners match the q-tuple be cached or forwarded or consumed. so, full cname chains, or partial cname chains, whether apparently sharing a baliwick with the q-tuple or not, are unusable. it's no longer going to be possible to make an authority server a stealth slave for some common CNAME destination and try to cut down the number of round trips needed to complete a CNAME chain. for the authority section we have the problems of fast flux, of poison, of load balancers, and of legitimate NS RRset changes. we must allow a response to have the effect of changing the cached NS RRset, but we cannot allow the kind of immediate+direct replacement that's been widely implemented to date. one non-immediate non-direct approach (proposed by me and by others) is to reduce the TTL rather than replacing the RRset so as to allow slow legitimate changes to cached NS RRsets but to ensure that changes are validated through the parent zone somehow. leo bicknell's observation yesterday is that at the cost of one extra round trip per delegation discovery we can separate the discovery of the delegation chain from the discovery of the answer. since we can hope that a delegation chain will be used many times before it expires or is replaced, this is a reasonable design cost. therefore for any given q-tuple where we have no specifically associated knowledge of its delegation chain, we can first ask for . and iterate downward along the returned NS RRsets until we receive one that isn't a delegation (indicating that "randomstring" matches a wilecard, or until we receive an NXDOMAIN. since there's no way to be sure that www. and ftp. aren't zone apexes, we'll have to ask for .www. and .ftp. separately, even though we'll normally just learn that only has an NS RRset. this extra cost allows us to commit to a draconian NS RRset replacement strategy: if a response contains an NS RRset which attempts to change the cache, then simply ignore the new one and delete the cached one, and restart iteration. (this policy isn't effective without bicknell's NS RRset discovery modality, since the iteration we'd fall back to today, is predictable and vulnerable.) for the additional section we have quite a lot of protection from RFC 2181 already. kashpureff taught us a lot. but even so we're currently capable of inserting new RRsets into the cache which while "in baliwick" are at least theoretically attached to poisoned MX or SRV or NS records in the answer or authority section. nothing i've said above about protecting the other sections makes it safe to consume, cache, or reuse in-baliwick data contained in the additional section. ohta has long urged that we collapse the data structure to remove the intermediate name (target of MX/SRV/NS, owner of A/AAAA) and just associate addresses directly with the records that need this kind of "glue". weaver has recently made an observation which i find compelling -- if one follows ohta's proposal only for the purpose of making a direct query to that baliwick for the glue record in question, and never let anything in the additional section affect the cache at all ever, then we've closed this window. but i'm only compelled by this proposal in light of bicknell's observation (described earlier), such that the downquery meant to retrieve this glue should begin with a .gluename query in order to complete the delegation chain through to the subzone's apex, after which point a normal query for the gluename against that baliwick, with the normal rules for caching only answers matching the q-tuple and disallowing subsequent NS RRset replacement without first deleting and reaquiring that link in the delegation chain. this description is hard to follow, and frankly it was hard to write. i'm conjoining "things you have to do differently when you decide where to send a query" with "things you have to do differently when you receive an answer" and that makes a lot of people nervous. but as you contemplate the anxiety and complexity in this proposal, note that its approach is to try to decide what CAN be cached, and not to try to decide what CAN'T be cached. i ask that questions of the form "i don't understand" or "this makes no sense" be sent to me personally rather than to the list -- i will then know what i need to improve in the proposal and we can avoid compounded misunderstandings that will make the evaluation of this take even longer than it must. and note, again, that even if successful, this proposal doesn't reduce the need for DNSSEC, since it only seeks to protect against off-path attacks, and we all ought to continue to be very concerned about on-path attacks as well. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 14:12:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C873A6B89; Thu, 28 Aug 2008 14:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 2nuEccKtGaNU; Thu, 28 Aug 2008 14:12:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33D7C3A694E; Thu, 28 Aug 2008 14:12:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYoeP-000Nqb-3L for namedroppers-data@psg.com; Thu, 28 Aug 2008 21:03:29 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYoeK-000Nq7-5Y for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 21:03:26 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Cc:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=lZQ2zts1gtxfCZBGJ7h7EnZlOvSQoiLZ0C9/caplxcZo/B1bQXvE4+VO WEUBhZkRFqBr/b4CpUEHlpG4o/OLhV2N3sZpvMYFzL36HTzFZEuJn8FZE Pq4C9cx7TltPhBA; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1219957404; x=1251493404; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20Some =20Observations=20on=20Entropy=20Re:=20Some=20observation s=20on=20dns-0x20|Date:=20Thu,=2028=20Aug=202008=2022:03: 20=20+0100|Message-ID:=20|To:=20Mark=20A ndrews=20|Cc:=20namedroppers@ops.ie tf.org|MIME-Version:=201.0|In-Reply-To:=20<200808270017.m 7R0H5Hd050800@drugs.dv.isc.org>; bh=iK5nwYGaGiZ3LEZqR32v8Bgenybf979g278dWhLVsT4=; b=mjicHfYHJvXPKYEC+VNoVs8Pvll54Wl5LatT3DLjGKuMtOC6TM2I5Xet bjtIa2BNq3ZUaaurCrgeGXAznPlH/4WqnBi6YHYuRjbz3DWbJC7JuF0SQ bgFICK87LKNXWDv; X-IronPort-AV: E=Sophos;i="4.32,288,1217804400"; d="scan'208";a="5185492" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 28 Aug 2008 22:03:22 +0100 In-Reply-To: <200808270017.m7R0H5Hd050800@drugs.dv.isc.org> To: Mark Andrews Cc: namedroppers@ops.ietf.org Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 28 Aug 2008 22:03:20 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 28/08/2008 10:03:21 PM, Serialize complete at 28/08/2008 10:03:21 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > If you are NAT'd the port number MAY offer you no protection. > There are NAT's which attempt to preserve port numbers and > actually do a pretty good job of doing that. > > If you are NAT'd the NAT MAY provide protection for nameservers > that do not randomize their source ports by randomising the > source port as a side effect of the NAT process. > > There are also NAT's which serialize the ports and NAT's > which only emit one port and potentially serialize the qid > as well. Mark, Can we please make a distinction between plain NATs (which only affect TCP/UDP and IP headers) and proxies (or ALGs) which manipulate the protocol at higher levels? I've never seen a NAT which affects QIDs. I've seen plenty of ALGs that do, though, many of which did indeed pick serial QIDs :( Ray -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 14:25:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3599A3A6BEE; Thu, 28 Aug 2008 14:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599] 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 o9WrkXxSeEmg; Thu, 28 Aug 2008 14:25:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59A823A6B6C; Thu, 28 Aug 2008 14:25:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYorg-000PB5-76 for namedroppers-data@psg.com; Thu, 28 Aug 2008 21:17:12 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYorc-000PAg-M1 for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 21:17:10 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 8EB04A669B; Thu, 28 Aug 2008 21:16:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Jim Reid cc: Nicholas Weaver , Namedroppers In-Reply-To: Your message of "Thu, 28 Aug 2008 18:19:04 +0100." <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 28 Aug 2008 21:16:59 +0000 Message-ID: <26223.1219958219@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 8EB04A669B.DFCA3 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Ugly kludges like AL or 0x20 are relatively painless to deploy, ... don't mention these together, please. 0x20 is a one-side upgrade (RDNS only). -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 16:59:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCBD73A69E9; Thu, 28 Aug 2008 16:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 YzmTlHafgpEw; Thu, 28 Aug 2008 16:59:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F0AC3A67CC; Thu, 28 Aug 2008 16:59:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYrFA-000BZm-Ge for namedroppers-data@psg.com; Thu, 28 Aug 2008 23:49:36 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYrF6-000BZI-B5 for namedroppers@ops.ietf.org; Thu, 28 Aug 2008 23:49:34 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3D13DA6682 for ; Thu, 28 Aug 2008 23:49:22 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 28 Aug 2008 19:22:06 GMT." <2041.1219951326@nsa.vix.com> References: <2041.1219951326@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Thu, 28 Aug 2008 23:49:22 +0000 Message-ID: <53301.1219967362@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 3D13DA6682.34715 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: kaminsky resistance, section by section Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: meaning no disrespect to leo bicknell, a more careful review of my inbox reveals that evan hunt, not leo bicknell, first told the idea of "prepend random label to the qname until you're sure you know the entire delegation chain", so in fairness to evan, i will change this attribution the next iteration of the writeup of this. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 17:15:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16A628C214; Thu, 28 Aug 2008 17:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599] 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 Z4ntix8WVS4u; Thu, 28 Aug 2008 17:15:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17EDF28C20B; Thu, 28 Aug 2008 17:15:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYrU1-000CpK-Qw for namedroppers-data@psg.com; Fri, 29 Aug 2008 00:04:57 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYrTv-000CoT-GR for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 00:04:55 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7T04ifn035828; Fri, 29 Aug 2008 10:04:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808290004.m7T04ifn035828@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 In-reply-to: Your message of "Thu, 28 Aug 2008 22:03:20 +0100." Date: Fri, 29 Aug 2008 10:04:44 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > If you are NAT'd the port number MAY offer you no protection. > > There are NAT's which attempt to preserve port numbers and > > actually do a pretty good job of doing that. > > > > If you are NAT'd the NAT MAY provide protection for nameservers > > that do not randomize their source ports by randomising the > > source port as a side effect of the NAT process. > > > > There are also NAT's which serialize the ports and NAT's > > which only emit one port and potentially serialize the qid > > as well. > > Mark, > > Can we please make a distinction between plain NATs (which only affect > TCP/UDP and IP headers) and proxies (or ALGs) which manipulate the > protocol at higher levels? > > I've never seen a NAT which affects QIDs. I've seen plenty of ALGs that > do, though, many of which did indeed pick serial QIDs :( > > Ray I agree with you that there is a difference. The problem of course is that you often don't know that a ALG is also installed in the NAT box. You generally buy a NAT (router in some markets) and have no idea of what's inside as the vendors don't give you enough details. You are also often not in a position to see the traffic on both sides as the upstream may be a cable/dsl modem and not ethernet. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 18:16:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CE13A67F8; Thu, 28 Aug 2008 18:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.782 X-Spam-Level: X-Spam-Status: No, score=-4.782 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 XJIxCI62yEHH; Thu, 28 Aug 2008 18:16:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D94D3A67CC; Thu, 28 Aug 2008 18:16:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYsSf-000Htb-Ol for namedroppers-data@psg.com; Fri, 29 Aug 2008 01:07:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYsSb-000Ht4-Ip for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 01:07:35 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7T16t1w017050; Thu, 28 Aug 2008 18:07:00 -0700 (PDT) Cc: Nicholas Weaver , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Message-Id: <0F6ADF3E-AB46-4C14-8588-A4D874FF2ADC@icsi.berkeley.edu> From: Nicholas Weaver To: Mark Andrews In-Reply-To: <200808290004.m7T04ifn035828@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 Date: Thu, 28 Aug 2008 18:06:55 -0700 References: <200808290004.m7T04ifn035828@drugs.dv.isc.org> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 28, 2008, at 5:04 PM, Mark Andrews wrote: > > I agree with you that there is a difference. The problem > of course is that you often don't know that a ALG is also > installed in the NAT box. > > You generally buy a NAT (router in some markets) and have > no idea of what's inside as the vendors don't give you > enough details. You are also often not in a position to > see the traffic on both sides as the upstream may be a > cable/dsl modem and not ethernet. However, for purposes of building a DNS resolver, you can probe for the detailed behavior, including port, ID, IP, etc, by querying a properly constructed authority, so you can be in a position to see both sides of the traffic: you just have to ask somebody who will tell you the other side. {port,txid,server}.{anything}.nettest.icir.org is one protoype example. This works in all cases where the NAT/proxy is not malicious (deliberately whitelisting the tests) and who's behavior doesn't change (you can always repoll to check for changed behaviors at a reasonable interval, however). For a malicious proxy in path, you are sunk however, but with a malicious proxy in path, you are sunk period. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 18:25:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743BF28C30D; Thu, 28 Aug 2008 18:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.792, BAYES_00=-2.599] 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 OeN8VAngTF5p; Thu, 28 Aug 2008 18:25:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C54828C307; Thu, 28 Aug 2008 18:25:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYsc8-000IaC-Q7 for namedroppers-data@psg.com; Fri, 29 Aug 2008 01:17:24 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYsc3-000IZa-9t for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 01:17:21 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7T1HAWd037207; Fri, 29 Aug 2008 11:17:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808290117.m7T1HAWd037207@drugs.dv.isc.org> To: Nicholas Weaver Cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 In-reply-to: Your message of "Thu, 28 Aug 2008 18:06:55 MST." <0F6ADF3E-AB46-4C14-8588-A4D874FF2ADC@icsi.berkeley.edu> Date: Fri, 29 Aug 2008 11:17:10 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > On Aug 28, 2008, at 5:04 PM, Mark Andrews wrote: > > > > I agree with you that there is a difference. The problem > > of course is that you often don't know that a ALG is also > > installed in the NAT box. > > > > You generally buy a NAT (router in some markets) and have > > no idea of what's inside as the vendors don't give you > > enough details. You are also often not in a position to > > see the traffic on both sides as the upstream may be a > > cable/dsl modem and not ethernet. > > However, for purposes of building a DNS resolver, you can probe for > the detailed behavior, including port, ID, IP, etc, by querying a > properly constructed authority, so you can be in a position to see > both sides of the traffic: you just have to ask somebody who will tell > you the other side. > > {port,txid,server}.{anything}.nettest.icir.org is one protoype example. > > This works in all cases where the NAT/proxy is not malicious > (deliberately whitelisting the tests) and who's behavior doesn't > change (you can always repoll to check for changed behaviors at a > reasonable interval, however). > > For a malicious proxy in path, you are sunk however, but with a > malicious proxy in path, you are sunk period. And one really wants a solution where you don't need to care about whether the port or txid are being changed or not. You also want one where you can detect a malicious proxy / cache. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 28 19:38:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F1F3A6D27; Thu, 28 Aug 2008 19:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 zbTZiGASvH4a; Thu, 28 Aug 2008 19:38:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2599E3A696C; Thu, 28 Aug 2008 19:38:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYtgx-000Neb-1N for namedroppers-data@psg.com; Fri, 29 Aug 2008 02:26:27 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYtgs-000Ne4-2M for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 02:26:24 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DFB16A66B3; Fri, 29 Aug 2008 02:26:12 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Mark Andrews cc: Nicholas Weaver , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 11:17:10 +1000." <200808290117.m7T1HAWd037207@drugs.dv.isc.org> References: <200808290117.m7T1HAWd037207@drugs.dv.isc.org> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 02:26:12 +0000 Message-ID: <72632.1219976772@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: DFB16A66B3.436E2 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > {port,txid,server}.{anything}.nettest.icir.org is one protoype example. > > > > This works in all cases where the NAT/proxy is not malicious > > (deliberately whitelisting the tests) and who's behavior doesn't > > change (you can always repoll to check for changed behaviors at a > > reasonable interval, however). > > > > For a malicious proxy in path, you are sunk however, but with a > > malicious proxy in path, you are sunk period. > > And one really wants a solution where you don't need to care about > whether the port or txid are being changed or not. You also want > one where you can detect a malicious proxy / cache. > > Mark agreed. testing for this and responding to it adds complexity and doesn't nec'ily buy you anything if the ADNS you're querying is behind their own local NAT-based derandomizer. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 00:03:42 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0D13A69F5; Fri, 29 Aug 2008 00:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.309 X-Spam-Level: * X-Spam-Status: No, score=1.309 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 8MKCu0XjF8Un; Fri, 29 Aug 2008 00:03:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABB2E3A67B5; Fri, 29 Aug 2008 00:03:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYxqJ-000KRe-66 for namedroppers-data@psg.com; Fri, 29 Aug 2008 06:52:23 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYxqC-000KQK-35 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 06:52:21 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KYxpv-0005G8-KJ; Fri, 29 Aug 2008 08:51:59 +0200 Received: from fweimer by bfk.de with local id 1KYxq3-00023o-JY; Fri, 29 Aug 2008 08:52:07 +0200 To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: Protecting caches? References: <20080827170822.GH18946@commandprompt.com> From: Florian Weimer Date: Fri, 29 Aug 2008 08:52:07 +0200 In-Reply-To: <20080827170822.GH18946@commandprompt.com> (Andrew Sullivan's message of "Wed, 27 Aug 2008 13:08:22 -0400") Message-ID: <82wsi0s488.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Andrew Sullivan: > What I haven't seen much of is discussion of protecting caches _as > such_. That is, given that we are going to cache, are there > techniques that solve the dangers of a cache other than just > preventing the cache from ever having the wrong data in the first > place?=20=20 Here's an idea to contain the damage of a bad record by reducing the amplification effect (attack one cache, compromise the network view for thousands of clients): If information enters the cache for the first time, you only use it a fixed number of times before fetching it again from the network (say 10). If the usage count is reached, you fetch the data from the network (even if the TTL has not yet expired). If it is still the same, you double the counter. If it is different, you fail back to the initial value. This will cause additional DNS traffic for those who publish unstable data. It is also reasonable to disable it during the cache warm-up phase, and to keep records past their TTL (to avoid the cold start; this makes sense for DNSSEC as well, were you often can avoid cryptographic operations if the freshly fetched RRSIG matches the stored one). --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 00:21:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE0D3A6898; Fri, 29 Aug 2008 00:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 4-JJF5Q4xowJ; Fri, 29 Aug 2008 00:21:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4DF53A67B3; Fri, 29 Aug 2008 00:21:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYy7Z-000MGc-Vr for namedroppers-data@psg.com; Fri, 29 Aug 2008 07:10:13 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYy7S-000MFf-Lf for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 07:10:11 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=BbjdNs2T29V5gksRp1KsLNr1RpZr/1DFLwyEH0FfYPZtuVtFJ29dl7EC rG3aN/10yUUgRTdo1WMRlrNPGd0maNZpwsCe7HFrcW4A2seme4MAjdE6y swNJjYaaFNLTD+T; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1219993806; x=1251529806; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20Some =20Observations=20on=20Entropy=20Re:=20Some=20observation s=20on=20dns-0x20|Date:=20Fri,=2029=20Aug=202008=2008:10: 03=20+0100|Message-ID:=20|To:=20namedrop pers@ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<200 808290004.m7T04ifn035828@drugs.dv.isc.org>|References:=20 Your=20message=20of=20"Thu,=2028=20Aug=202008=2022:03:20 =20+0100."=20=20=20=20=20=20=20=20=20=20=20=20=20=20<200808290004.m7T04ifn035828@drugs.dv.isc.org >; bh=8kTG6BdkA7tx6i+OHbM0f8yu9jtyogbIGsDCVU9T4Hk=; b=DJ+1S41NF4hyNfMsoj3RFijLMo4O0JaE59g22OytBmAlG8H6Ta1c67HV v+MNz7x6X6ClHmYSTW0ZrvW9+9K5sY2biqwq3JyLfTs8YWdfOFm3sB1Jy 60UKqLoIGLuy8zS; X-IronPort-AV: E=Sophos;i="4.32,291,1217804400"; d="scan'208";a="6542368" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 29 Aug 2008 08:10:04 +0100 In-Reply-To: <200808290004.m7T04ifn035828@drugs.dv.isc.org> References: Your message of "Thu, 28 Aug 2008 22:03:20 +0100." <200808290004.m7T04ifn035828@drugs.dv.isc.org> To: namedroppers@ops.ietf.org Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 29 Aug 2008 08:10:03 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 29/08/2008 08:10:04 AM, Serialize complete at 29/08/2008 08:10:04 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I agree with you that there is a difference. The problem > of course is that you often don't know that a ALG is also > installed in the NAT box. If your (DHCP-derived) DNS server settings point at your router, it has an ALG in it. Ray -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 00:27:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1674128C108; Fri, 29 Aug 2008 00:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6mku9lyFPa-k; Fri, 29 Aug 2008 00:26:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30A0028C155; Fri, 29 Aug 2008 00:26:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYyFa-000N94-Rc for namedroppers-data@psg.com; Fri, 29 Aug 2008 07:18:30 +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 ) id 1KYyFR-000N7T-Uc for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 07:18:28 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KYyFL-00087L-Vj for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 09:18:16 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 268A84B44F; Fri, 29 Aug 2008 09:18:28 +0200 (CEST) Date: Fri, 29 Aug 2008 09:18:27 +0200 From: bert hubert To: Nicholas Weaver Cc: Namedroppers Subject: Re: Stupid questions on stub resolvers... Message-ID: <20080829071827.GB4858@outpost.ds9a.nl> References: <3D5C5CD3-09AB-4555-9312-FB6A11706C38@icsi.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5C5CD3-09AB-4555-9312-FB6A11706C38@icsi.berkeley.edu> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 28, 2008 at 08:31:25AM -0700, Nicholas Weaver wrote: > Do people know of any stub resolvers which cache beyond the direct > answer when asking a recursive resolver? Very little is known (at least, here) about the behaviour of the many different stub resolvers. Some applications (browsers) bring their own dedicated stub resolver, in other cases the "stub resolver" is actually a repeater in a domestic router or modem. I suspect Microsoft Exchange to also have a built-in stub given its unorthodox DNS behaviour at times. This next to the stubs in phones, and the zoo of operating system versions. More study might be in order. > EG, if the recursive resolver when asked "www.foo.com", also returns > an additional record "advertisements.foo.com A 12.34.56.78", will any > known stub resolvers cache that additional value? I expect this behaviour to be very rare. CNAME chain following is about where most stub resolvers end, in my expectaction. 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 00:51:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BD83A67E9; Fri, 29 Aug 2008 00:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 9WKNYQOVcYg9; Fri, 29 Aug 2008 00:51:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B596B3A67E5; Fri, 29 Aug 2008 00:51:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYycZ-000Pun-On for namedroppers-data@psg.com; Fri, 29 Aug 2008 07:42:15 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KYycV-000Pto-RP for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 07:42:14 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 3EA3E1C0177; Fri, 29 Aug 2008 09:42:09 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 3887B1C011C; Fri, 29 Aug 2008 09:42:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 2CB477B0052; Fri, 29 Aug 2008 09:42:09 +0200 (CEST) Date: Fri, 29 Aug 2008 09:42:09 +0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: Jim Reid , Nicholas Weaver , Namedroppers Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Message-ID: <20080829074209.GA15508@nic.fr> References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> <26223.1219958219@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26223.1219958219@nsa.vix.com> X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Aug 28, 2008 at 09:16:59PM +0000, Paul Vixie wrote a message of 8 lines which said: > 0x20 is a one-side upgrade (RDNS only). Only if the aDNS preserves case which is currently NOT mandatory. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 04:33:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BFC3A6994; Fri, 29 Aug 2008 04:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 f5KiSvXGP+Xj; Fri, 29 Aug 2008 04:33:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 638FB3A681D; Fri, 29 Aug 2008 04:33:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ24i-000MUH-PS for namedroppers-data@psg.com; Fri, 29 Aug 2008 11:23:32 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ24e-000MTn-L7 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 11:23:30 +0000 Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1KZ24E-0002uF-GB; Fri, 29 Aug 2008 12:23:02 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KZ24E-0005uU-0n; Fri, 29 Aug 2008 12:23:02 +0100 Message-ID: <20F912BB5A594AA98CD15D379D56CC96@localhost> From: "George Barwood" To: "Paul Vixie" Cc: References: <15CBB956E5654625A795DE2D8269A1A1@localhost> <2871.1219436191@nsa.vix.com> Subject: Re: Defending against the Kaminsky attack Date: Fri, 29 Aug 2008 12:23:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Paul Vixie" To: "George Barwood" Cc: Sent: Friday, August 22, 2008 9:16 PM Subject: Re: Defending against the Kaminsky attack > those are pattern-specific poison avoidances. i'd much rather we focus > on not accepting the bad response than on not letting its content hurt us. [ I replied some days ago, but it seems to have got lost, possibly because I was at the beach so had to use an unsubscribed email address ] I was not very definite on what checks I think are required, but the approach I am advocating ( with some encouragement from Nicholas Weaver via private email ), is completely general. For definiteness, I'm here is the code I am using (see rough English translation below). The checking code is applied after parsing a DNS response, hopefully the meaning is self-evident. Records in each of the sections are initialised to be "Not ok", that is to be discarded. public void Check( int T, String Question, String Bailiwick ) { if ( Answers.Length > 0 ) { for (int i=0;i From owner-namedroppers@ops.ietf.org Fri Aug 29 05:23:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C23D3A695E; Fri, 29 Aug 2008 05:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.816 X-Spam-Level: X-Spam-Status: No, score=-4.816 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 Ti0v9qVxeKx8; Fri, 29 Aug 2008 05:23:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD8FC3A6901; Fri, 29 Aug 2008 05:23:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ2rs-0001Tg-Re for namedroppers-data@psg.com; Fri, 29 Aug 2008 12:14:20 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ2rp-0001TD-D4 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 12:14:19 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7TCDsb0003877; Fri, 29 Aug 2008 05:13:54 -0700 (PDT) Cc: Nicholas Weaver , Paul Vixie , Jim Reid , Namedroppers Message-Id: <2CD5AAC6-0E22-4885-9092-006CFE739FEF@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Stephane Bortzmeyer In-Reply-To: <20080829074209.GA15508@nic.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Date: Fri, 29 Aug 2008 05:13:55 -0700 References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> <26223.1219958219@nsa.vix.com> <20080829074209.GA15508@nic.fr> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 29, 2008, at 12:42 AM, Stephane Bortzmeyer wrote: > On Thu, Aug 28, 2008 at 09:16:59PM +0000, > Paul Vixie wrote > a message of 8 lines which said: > >> 0x20 is a one-side upgrade (RDNS only). > > Only if the aDNS preserves case which is currently NOT mandatory. This is why 0x20, IIRC, has "Duplicate on failure". the aDNS in practice almost always preserves case, and duplication gives you a fallback position when you have insufficient entropy. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 06:10:23 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2109A3A695E; Fri, 29 Aug 2008 06:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, 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 L3UvLMsIik8z; Fri, 29 Aug 2008 06:10:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E709A3A692C; Fri, 29 Aug 2008 06:10:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ3a9-0006Bw-CX for namedroppers-data@psg.com; Fri, 29 Aug 2008 13:00:05 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ3a4-0006AZ-GJ for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 13:00:02 +0000 Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1KZ3a1-00048i-L1 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 13:59:57 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KZ3a1-0003v5-7R for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 13:59:57 +0100 Message-ID: From: "George Barwood" To: Subject: More 0x20 craziness Date: Fri, 29 Aug 2008 13:59:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0190_01C909DF.8565FB60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0190_01C909DF.8565FB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When sending a query to a root or 1st level server, it seems you can = prepend a sufficiently long arbitrary label (say 80 Xs, or 10 random = characters), giving as much entropy as you want either via 0x20, or just = by simply checking the Question in the response. It sounds crazy, but I have just tried it and it seems to work. Or maybe = it is me that has gone crazy. I'm not sure if there are any hidden assumptions here that might need to = be standardised, or whether these random prefixes could cause any = problems for the root / 1st level servers? ------=_NextPart_000_0190_01C909DF.8565FB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When sending a query to a root or 1st = level server,=20 it seems you can prepend a sufficiently long arbitrary label = (say 80=20 Xs, or 10 random characters), giving as much entropy as you want either = via=20 0x20, or just by simply checking the Question in the = response.
 
It sounds crazy, but I have just tried = it and it=20 seems to work. Or maybe it is me that has gone crazy.
 
I'm not sure if there are any = hidden=20 assumptions here that might need to be standardised, or whether these=20 random prefixes could cause any problems for the root / 1st = level=20 servers?
 
------=_NextPart_000_0190_01C909DF.8565FB60-- -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 06:38:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16FBD3A67ED; Fri, 29 Aug 2008 06:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.891 X-Spam-Level: X-Spam-Status: No, score=-4.891 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 1+iyC7F+hkKx; Fri, 29 Aug 2008 06:38:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDFBD3A69AB; Fri, 29 Aug 2008 06:38:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ43Z-0009VA-Lw for namedroppers-data@psg.com; Fri, 29 Aug 2008 13:30:29 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ43U-0009Ud-MG for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 13:30:27 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id A81411C0193; Fri, 29 Aug 2008 15:30:20 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id A32321C0190; Fri, 29 Aug 2008 15:30:20 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 9792EA1DEC8; Fri, 29 Aug 2008 15:30:20 +0200 (CEST) Date: Fri, 29 Aug 2008 15:30:20 +0200 From: Stephane Bortzmeyer To: George Barwood Cc: namedroppers@ops.ietf.org Subject: Re: More 0x20 craziness Message-ID: <20080829133020.GA28455@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 29, 2008 at 01:59:57PM +0100, George Barwood wrote a message of 61 lines which said: > It sounds crazy, Isn't it simply XQID? http://www.jhsoft.com/dns-xqid.htm -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 06:58:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270913A69A7; Fri, 29 Aug 2008 06:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 GvhvbiJjeT3w; Fri, 29 Aug 2008 06:58:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 42A653A6819; Fri, 29 Aug 2008 06:58:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ4Lt-000BVS-Ca for namedroppers-data@psg.com; Fri, 29 Aug 2008 13:49:25 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ4Lp-000BUj-4y for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 13:49:23 +0000 Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1KZ4Ll-0001eM-8U; Fri, 29 Aug 2008 14:49:17 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KZ4Lk-0001E4-PB; Fri, 29 Aug 2008 14:49:16 +0100 Message-ID: <34B0DA07DFA3424D8EAFCCC146D7E78D@localhost> From: "George Barwood" To: "Stephane Bortzmeyer" Cc: References: <20080829133020.GA28455@nic.fr> Subject: Re: More 0x20 craziness Date: Fri, 29 Aug 2008 14:49:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Isn't it simply XQID? But it doesn't need any change in the servers, so can work today. But I'm now looking at what may prove to be a mirage, but appears to be wonderful, a miracle. (1) Find the correct name server(s) (if not in cache). During this phase, prepend a random label to the question, so that there is no lack of entropy, rendering spoofing impossible. Only relies on authoritative servers copying Question back, not 0x20. No repetition needed. (2) Submit the client query to the name server(s). Duing this phase ignore Authority and Additional sections, only accept Answers where LHS matches question. Repeat to gain more entropy if desired. I haven't tried this yet, so may be horribly mistaken! -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 07:04:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FFF3A6819; Fri, 29 Aug 2008 07:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.872 X-Spam-Level: X-Spam-Status: No, score=-4.872 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 BfJcPPxWJHf4; Fri, 29 Aug 2008 07:04:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 842463A6A20; Fri, 29 Aug 2008 07:04:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ4RO-000C7U-Jv for namedroppers-data@psg.com; Fri, 29 Aug 2008 13:55:06 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ4R2-000C4H-Lp for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 13:54:52 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id CB5FA1C0197; Fri, 29 Aug 2008 15:54:40 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id C62791C00F0; Fri, 29 Aug 2008 15:54:40 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id C42E26C0AAF; Fri, 29 Aug 2008 15:54:40 +0200 (CEST) Date: Fri, 29 Aug 2008 15:54:40 +0200 From: Stephane Bortzmeyer To: George Barwood Cc: namedroppers@ops.ietf.org Subject: Re: More 0x20 craziness Message-ID: <20080829135440.GA31481@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 29, 2008 at 01:59:57PM +0100, George Barwood wrote a message of 61 lines which said: > When sending a query to a root or 1st level server, OK, I understand better now your idea and how it is different from XQID. But, then, it seems it will work only with delegation-only zones, no? It is not the case of every TLD... This works, you get the right referral: % dig @a-dns.pl A aNTIForgeRYstuFf-www.google.pl ; <<>> DiG 9.5.0-P2 <<>> @a-dns.pl A aNTIForgeRYstuFf-www.google.pl ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18522 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;aNTIForgeRYstuFf-www.google.pl. IN A ;; AUTHORITY SECTION: google.pl. 86400 IN NS ns1.google.com. google.pl. 86400 IN NS ns2.google.com. But this does not: % dig @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl ; <<>> DiG 9.5.0-P2 <<>> @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4023 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 07:26:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128293A6A2A; Fri, 29 Aug 2008 07:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 HuBZOoTZhZpl; Fri, 29 Aug 2008 07:25:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 309DD3A69A7; Fri, 29 Aug 2008 07:25:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ4mV-000EW9-Q7 for namedroppers-data@psg.com; Fri, 29 Aug 2008 14:16:55 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ4mN-000EUh-Aw for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 14:16:49 +0000 Received: from [192.168.100.2] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id DCE70C2DA7; Fri, 29 Aug 2008 15:16:42 +0100 (BST) Date: Fri, 29 Aug 2008 15:16:40 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Stephane Bortzmeyer , George Barwood cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: More 0x20 craziness Message-ID: In-Reply-To: <20080829135440.GA31481@nic.fr> References: <20080829135440.GA31481@nic.fr> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 August 2008 15:54:40 +0200 Stephane Bortzmeyer wrote: > But this does not: > % dig @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl > > ; <<>> DiG 9.5.0-P2 <<>> @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4023 As I read what George was suggesting, you've addressed that to the wrong server, and the correct query would be: $ dig @a.root-servers.net A ANTiForgeRYstuFF-b-dns.pl ; <<>> DiG 9.4.2-P1 <<>> @a.root-servers.net A ANTiForgeRYstuFF-b-dns.pl ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62848 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 9 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ANTiForgeRYstuFF-b-dns.pl. IN A ;; AUTHORITY SECTION: pl. 172800 IN NS B-DNS.pl. pl. 172800 IN NS G-DNS.pl. pl. 172800 IN NS E-DNS.pl. pl. 172800 IN NS F-DNS.pl. pl. 172800 IN NS H-DNS.pl. pl. 172800 IN NS A-DNS.pl. pl. 172800 IN NS D-DNS.pl. ;; ADDITIONAL SECTION: A-DNS.pl. 172800 IN A 195.187.245.44 B-DNS.pl. 172800 IN A 80.50.50.10 D-DNS.pl. 172800 IN A 213.172.174.70 E-DNS.pl. 172800 IN A 213.218.118.26 F-DNS.pl. 172800 IN A 217.17.46.189 F-DNS.pl. 172800 IN AAAA 2001:1a68:0:10::189 G-DNS.pl. 172800 IN A 149.156.1.6 G-DNS.pl. 172800 IN AAAA 2001:6d8:0:1::a:6 H-DNS.pl. 172800 IN A 194.0.1.2 Alex -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 07:26:59 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FD03A6A34; Fri, 29 Aug 2008 07:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.856 X-Spam-Level: X-Spam-Status: No, score=-4.856 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 RTEgIgqWNIxa; Fri, 29 Aug 2008 07:26:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C52E23A6A2A; Fri, 29 Aug 2008 07:26:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ4oF-000EgX-C2 for namedroppers-data@psg.com; Fri, 29 Aug 2008 14:18:43 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ4oB-000Efn-Dx for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 14:18:41 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0D1101C019E; Fri, 29 Aug 2008 16:18:38 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0764A1C0195; Fri, 29 Aug 2008 16:18:38 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id EF4FF7B0053; Fri, 29 Aug 2008 16:18:37 +0200 (CEST) Date: Fri, 29 Aug 2008 16:18:37 +0200 From: Stephane Bortzmeyer To: Alex Bligh Cc: Stephane Bortzmeyer , George Barwood , namedroppers@ops.ietf.org Subject: Re: More 0x20 craziness Message-ID: <20080829141837.GA2933@nic.fr> References: <20080829135440.GA31481@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux lenny/sid X-Kernel: Linux 2.6.24-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 29, 2008 at 03:16:40PM +0100, Alex Bligh wrote a message of 53 lines which said: > As I read what George was suggesting, you've addressed that to the > wrong server, and the correct query would be: > > $ dig @a.root-servers.net A ANTiForgeRYstuFF-b-dns.pl No, I do not think I was wrong, George mentioned the root servers but also the TLD servers. I we limit his scheme to the root servers, it works *today* (the root is delegation-only) but it is quite limited. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 08:08:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4FA73A68BC; Fri, 29 Aug 2008 08:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MANGLED_PILL=2.3, RCVD_IN_DNSWL_MED=-4, 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 swA2lVP7C+nG; Fri, 29 Aug 2008 08:08:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B61A63A67B0; Fri, 29 Aug 2008 08:08:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5Pp-000JfH-El for namedroppers-data@psg.com; Fri, 29 Aug 2008 14:57:33 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5Ph-000JeO-E6 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 14:57:31 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0207E1C019D for ; Fri, 29 Aug 2008 16:57:24 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id F15A71C00D8 for ; Fri, 29 Aug 2008 16:57:23 +0200 (CEST) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by relay2.nic.fr (Postfix) with ESMTP id EF0E97B0052 for ; Fri, 29 Aug 2008 16:57:23 +0200 (CEST) Received: from kerkenna.nic.fr (localhost [127.0.0.1]) by kerkenna.nic.fr (8.13.8/8.13.8) with ESMTP id m7TEvNYh081050 for ; Fri, 29 Aug 2008 16:57:23 +0200 (CEST) (envelope-from souissi@kerkenna.nic.fr) Received: (from souissi@localhost) by kerkenna.nic.fr (8.13.8/8.13.8/Submit) id m7TEvNfc081049 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 16:57:23 +0200 (CEST) (envelope-from souissi) Date: Fri, 29 Aug 2008 16:57:23 +0200 From: Mohsen Souissi To: namedroppers@ops.ietf.org Subject: Re: More 0x20 craziness Message-ID: <20080829145723.GC79975@kerkenna.nic.fr> References: <20080829135440.GA31481@nic.fr> <20080829141837.GA2933@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080829141837.GA2933@nic.fr> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 29 Aug, Stephane Bortzmeyer wrote: | On Fri, Aug 29, 2008 at 03:16:40PM +0100, | Alex Bligh wrote | a message of 53 lines which said: | | > As I read what George was suggesting, you've addressed that to the | > wrong server, and the correct query would be: | > | > $ dig @a.root-servers.net A ANTiForgeRYstuFF-b-dns.pl | | No, I do not think I was wrong, George mentioned the root servers but | also the TLD servers. | | I we limit his scheme to the root servers, it works *today* (the root | is delegation-only) but it is quite limited. ^^^^^^^^^^^^^^^^^^^ ==> I suspect it is even much more limited than you think, unless I have missed something... While there are no changes on the servers side, I think it is not the case for the stub resolver. As a matter of fact, while it is straigthforward to manually prepend some an extra string to the original QNAME and then submit the new query to root/tld servers by using some special DNS client like "dig", which entity would/should do such prepending for *real DNS traffic* typically originated by applications: - the stub resolver when being invoked by the application, and in that case it would forget about the QNAME, unless it sends two queries (one with prepending and a second one without prepending)? - the recursive name server (rdns) queried by the stub resolver on behalf of the application behind it? And in that case, would the rdns store the original query and send it the second time after the prepended query? So in both cases, I don't think it works *today as is* without hacking either one of the entities above. Mohsen. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 08:10:56 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF1828C0DC; Fri, 29 Aug 2008 08:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Gegr82vjiade; Fri, 29 Aug 2008 08:10:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EDD333A6A3E; Fri, 29 Aug 2008 08:10:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5Tj-000K8i-8y for namedroppers-data@psg.com; Fri, 29 Aug 2008 15:01:35 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5Ta-000K7o-0t for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 15:01:28 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id D5E531140C1; Fri, 29 Aug 2008 15:01:12 +0000 (UTC) (envelope-from Evan_Hunt@isc.org) Received: by farside.isc.org (Postfix, from userid 10292) id BABAEE6067; Fri, 29 Aug 2008 15:01:12 +0000 (UTC) Date: Fri, 29 Aug 2008 15:01:12 +0000 From: Evan Hunt To: Stephane Bortzmeyer Cc: George Barwood , namedroppers@ops.ietf.org Subject: Re: More 0x20 craziness Message-ID: <20080829150112.GA28357@isc.org> References: <20080829135440.GA31481@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080829135440.GA31481@nic.fr> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > But this does not: > > % dig @a-dns.pl A ANTiForgeRYstuFF-b-dns.pl What you want here is ANTiForgRYstuFF.b-dns.pl (dot, not hyphen). That allows you to determine whether b-dns.pl is a zone apex. In this case it isn't, so you get NXDOMAIN and you know the closest enclosing zone is "pl". "foo.pl", on the other hand, is a zone apex and "dig @a-dns.pl A alkjerf.foo.pl" does get you the proper delegation. (I've been playing with the same idea for a few days; Paul Vixie mentioned it here yesterday in the post "kaminsky resistance, section by section".) -- Evan Hunt -- evan_hunt@isc.org Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 08:12:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE123A67B0; Fri, 29 Aug 2008 08:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.606 X-Spam-Level: X-Spam-Status: No, score=-0.606 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 F9JmIWVqGwk4; Fri, 29 Aug 2008 08:12:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D1A43A6A3E; Fri, 29 Aug 2008 08:12:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5Sr-000K3J-5s for namedroppers-data@psg.com; Fri, 29 Aug 2008 15:00:41 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5Sd-000K1d-2F for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 15:00:36 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7TF3Vnx031879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Aug 2008 08:03:34 -0700 Date: Fri, 29 Aug 2008 11:00:22 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: More 0x20 craziness Message-ID: <20080829150022.GE29678@commandprompt.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Fri, 29 Aug 2008 08:03:34 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Fri, Aug 29, 2008 at 01:59:57PM +0100, George Barwood wrote: > When sending a query to a root or 1st level server, it seems you can > prepend a sufficiently long arbitrary label (say 80 Xs, or 10 random > characters), giving as much entropy as you want either via 0x20, or > just by simply checking the Question in the response. Well, that happens to work for your current cases. But how can you possibly know that without asking? A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 08:19:54 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038F83A687C; Fri, 29 Aug 2008 08:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 hWc1c9pG4M5t; Fri, 29 Aug 2008 08:19:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9EC23A67B0; Fri, 29 Aug 2008 08:19:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5bU-000L2S-Ug for namedroppers-data@psg.com; Fri, 29 Aug 2008 15:09:36 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ5bP-000L1i-Fh for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 15:09:34 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=Sy0JI8x+Mxn/HLv/q2UwmPi+63X2JS9GaEofa7DZqNmpPiIIE+rHeaKc plURvlofqwhnfWL8dWtOiJfUkz5zXGxEbG5XkWbOuevbEE5wOUtDY1d74 k3gtJQ8EuzyItXy; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1220022571; x=1251558571; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20More =200x20=20craziness|Date:=20Fri,=2029=20Aug=202008=2016:0 9:28=20+0100|Message-ID:=20|To:=20namedr oppers@ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20|References:=20=20<2008082913544 0.GA31481@nic.fr>=20; bh=90PMJaZol6Uqr3fO52xl0MTYlFgqD/J/RjoDt/fL1RQ=; b=TFXP4TxlpzhAQm5FmUGHNYTFT2XpeWaUgMCwh88Zpj6nRcQuc0Ll4pXf LQKy+V9QVGE5j+kLXhZFVvrs5fUrONkAZ1I5LzmlO7/1FL4xbHCYBcVgC 5EcZmf5zBciat2d; X-IronPort-AV: E=Sophos;i="4.32,293,1217804400"; d="scan'208";a="6553458" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 29 Aug 2008 16:09:29 +0100 In-Reply-To: References: <20080829135440.GA31481@nic.fr> To: namedroppers@ops.ietf.org Subject: Re: More 0x20 craziness MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 29 Aug 2008 16:09:28 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 29/08/2008 04:09:29 PM, Serialize complete at 29/08/2008 04:09:29 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Alex Bligh wrote: > As I read what George was suggesting, you've addressed that to the > wrong server, and the correct query would be: This is essentially the same (if not identical) as Paul was talking about in his "Section by Section" e-mail from last night - adding a random prefix on the front of the QNAME during delegation chain resolution. The hardest part is zone-cuts. For example, if I've got: $ORIGIN example.com www IN NS ns1.example.net and $ORIGIN www.example.com @ IN A 192.168.1.1 - how do we identify those without doing every (final) query twice? Asking for .www.example.com to the root and .com servers will give high entropy queries that get you the delegation chain as far as example.com's nameservers. But if we then only ask those servers the original question we've got no additional entropy on the resulting referral. So (as Paul said) you still have to ask for .www.example.com, and then get the referral, and then finally get NXDOMAIN, and only then can you ask the original question. That appears to mean twice as many queries to the real authoritative servers, for every QNAME, since it's perfectly possible for foo.example.com to have a different final delegation chain to www.example.com. Ray I also came up with this independently earlier this month, but only mentioned it to Roy and Wouter and didn't happen to mention it to Paul. -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 09:01:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11ABF3A68A8; Fri, 29 Aug 2008 09:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599] 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 o0VtmVCkyT6o; Fri, 29 Aug 2008 09:01:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FAC83A677C; Fri, 29 Aug 2008 09:01:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6G0-0000ly-Ep for namedroppers-data@psg.com; Fri, 29 Aug 2008 15:51:28 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6Ft-0000l2-Cn for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 15:51:23 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A5C18A66B3; Fri, 29 Aug 2008 15:50:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Stephane Bortzmeyer cc: Jim Reid , Nicholas Weaver , Namedroppers In-Reply-To: Your message of "Fri, 29 Aug 2008 09:42:09 +0200." <20080829074209.GA15508@nic.fr> References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> <26223.1219958219@nsa.vix.com> <20080829074209.GA15508@nic.fr> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 15:50:59 +0000 Message-ID: <88896.1220025059@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A5C18A66B3.E8B04 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > 0x20 is a one-side upgrade (RDNS only). > > Only if the aDNS preserves case which is currently NOT mandatory. since the draft allows for this situation and explains what to do about it, and since i've implemented it and have run it successfully for six months, and since unbound has implemented it and noone has reported trouble there, i think it's safe to categorize this as "RDNS only". i know there is text in the draft asking that the standard for ADNS be changed to optimize for dns-0x20, but the current proposal is to add "SHOULD preserve qname case" not "MUST preserve qname case." contrast this with PING, XQID, AL, or things which don't work at all until changes are made to the ADNS side. so, i'd like dns-0x20 and AL not to be mentioned in the same breath, please. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 09:10:37 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307503A63D2; Fri, 29 Aug 2008 09:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] 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 4VeWt7-8ese4; Fri, 29 Aug 2008 09:10:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 193E83A690A; Fri, 29 Aug 2008 09:10:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6OV-0001qJ-AS for namedroppers-data@psg.com; Fri, 29 Aug 2008 16:00:15 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6OR-0001pR-0u for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 16:00:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2B0FAA6684; Fri, 29 Aug 2008 16:00:02 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "George Barwood" cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 12:23:02 +0100." <20F912BB5A594AA98CD15D379D56CC96@localhost> References: <15CBB956E5654625A795DE2D8269A1A1@localhost> <2871.1219436191@nsa.vix.com> <20F912BB5A594AA98CD15D379D56CC96@localhost> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 16:00:02 +0000 Message-ID: <90256.1220025602@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 2B0FAA6684.CF69E X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Defending against the Kaminsky attack Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "Paul Vixie" > To: "George Barwood" > Cc: > ... > Rough translation into English: > > If there are answers, ignore everything else. > Accept only answers where LHS matches the question. > If there are no answers, accept only proper referrals. > Glue is accepted only in one very specific case, that seems to be safe. > > At least 3 questions arise: > > (1) Is this code sufficient to successfully resolve names for properly > configured domains? no. because you don't know whether you have an answer until you've looked at the authority section. answers are cacheable facts, not rrsets per se, and the enumeration is at least: authoritative answer, no data for requested type nonauthoritative answer, no data for requested type name does not exist, not even as an empty nonterminal delegation server failure note that the AA bit doesn't help much. it might be set in an answer from some zone who also sent you a delegation to a subzone, in which case the answer isn't authoritative no matter what the AA bit tells you. in any case, 'if there are answers, ignore all else' is bad out the gate. > (2) Does it prevent Kaminsky attacks? > > (3) Is the performance penalty acceptable? > > I believe the answer to all these questions is yes. did you read the proposal i sent out yesterday ("...section by section") ? -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 09:11:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3653A6A59; Fri, 29 Aug 2008 09:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] 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 5EHKq71fIS8f; Fri, 29 Aug 2008 09:11:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 075993A6A3E; Fri, 29 Aug 2008 09:11:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6Qp-00024k-MF for namedroppers-data@psg.com; Fri, 29 Aug 2008 16:02:39 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6Qk-000246-Mo for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 16:02:36 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id AF6DCA6684; Fri, 29 Aug 2008 16:02:23 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "George Barwood" cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 13:59:57 +0100." References: X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 16:02:23 +0000 Message-ID: <90551.1220025743@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: AF6DCA6684.5203F X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: More 0x20 craziness Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > When sending a query to a root or 1st level server, it seems you can = > prepend a sufficiently long arbitrary label (say 80 Xs, or 10 random = > characters), giving as much entropy as you want either via 0x20, or just = > by simply checking the Question in the response. > > It sounds crazy, but I have just tried it and it seems to work. Or maybe = > it is me that has gone crazy. > > I'm not sure if there are any hidden assumptions here that might need to = > be standardised, or whether these random prefixes could cause any = > problems for the root / 1st level servers? aside from the fact that some names are really in those zones and so no rule of the form "if it's a top level or root zone query, behave as follows" can scale, this duplicate some elements of a proposal i sent here yesterday (which lacks this scaling limit) entitled "kaminsky resistance, section by section." -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 09:21:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BB93A68BC; Fri, 29 Aug 2008 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] 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 HEQ48FI7Mp+9; Fri, 29 Aug 2008 09:21:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CEEB3A687C; Fri, 29 Aug 2008 09:21:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6Yq-00037c-TD for namedroppers-data@psg.com; Fri, 29 Aug 2008 16:10:56 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6Yk-00036P-2Y for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 16:10:54 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D5166A669C; Fri, 29 Aug 2008 16:10:39 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Ray.Bellis@nominet.org.uk cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 16:09:28 +0100." References: <20080829135440.GA31481@nic.fr> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 16:10:39 +0000 Message-ID: <91978.1220026239@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: D5166A669C.3DDCC X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: More 0x20 craziness Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > - how do we identify those without doing every (final) query twice? we don't. that's the cost. > That appears to mean twice as many queries to the real authoritative > servers, for every QNAME, since it's perfectly possible for > foo.example.com to have a different final delegation chain to > www.example.com. once per new QNAME per RDNS per TTL. this is a lower number than you'd think. > I also came up with this independently earlier this month, but only > mentioned it to Roy and Wouter and didn't happen to mention it to Paul. i've also seen it mentioned in various non-mailing-list discussions all year during the kaminsky exercises, but it could never overcome its cost:benefit analysis until evan hunt mentioned it yesterday while i was trying to figure out once again a way to delete contested NS RRsets from the cache without immediately getting them poisoned by an attacker who knew i'd be going uphill to refresh them. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 09:43:58 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C413A6811; Fri, 29 Aug 2008 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 jpzYPC6nNNL6; Fri, 29 Aug 2008 09:43:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D45D3A63D2; Fri, 29 Aug 2008 09:43:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6uy-0005xf-Ng for namedroppers-data@psg.com; Fri, 29 Aug 2008 16:33:48 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ6uv-0005xG-5M for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 16:33:46 +0000 Received: from [192.168.100.2] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 1615CC2DB2; Fri, 29 Aug 2008 17:33:38 +0100 (BST) Date: Fri, 29 Aug 2008 17:33:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , Ray.Bellis@nominet.org.uk cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: More 0x20 craziness Message-ID: <46D2AD6CC587EA489E5EEE22@Ximines.local> In-Reply-To: <91978.1220026239@nsa.vix.com> References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 August 2008 16:10:39 +0000 Paul Vixie wrote: >> - how do we identify those without doing every (final) query twice? > > we don't. that's the cost. > >> That appears to mean twice as many queries to the real authoritative >> servers, for every QNAME, since it's perfectly possible for >> foo.example.com to have a different final delegation chain to >> www.example.com. > > once per new QNAME per RDNS per TTL. this is a lower number than you'd > think. If combined with 0x20, could one only make the additional query if (i) the original qname's case was not preserved or (ii) the qname did not itself contain sufficient entropy (e.g. ".", "com." etc.)? Alex -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 09:56:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C183A690A; Fri, 29 Aug 2008 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.197 X-Spam-Level: * X-Spam-Status: No, score=1.197 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 2y2wG4yE5KYG; Fri, 29 Aug 2008 09:56:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 420FB28C10A; Fri, 29 Aug 2008 09:56:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ76d-0007BP-9s for namedroppers-data@psg.com; Fri, 29 Aug 2008 16:45:51 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ76S-00079H-HX for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 16:45:49 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KZ75w-0000e8-AF; Fri, 29 Aug 2008 18:45:08 +0200 Received: from fweimer by bfk.de with local id 1KZ75z-0001dm-Jm; Fri, 29 Aug 2008 18:45:12 +0200 To: Paul Vixie Cc: Stephane Bortzmeyer , Jim Reid , Nicholas Weaver , Namedroppers Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> <26223.1219958219@nsa.vix.com> <20080829074209.GA15508@nic.fr> <88896.1220025059@nsa.vix.com> From: Florian Weimer Date: Fri, 29 Aug 2008 18:45:09 +0200 In-Reply-To: <88896.1220025059@nsa.vix.com> (Paul Vixie's message of "Fri, 29 Aug 2008 15:50:59 +0000") Message-ID: <82hc93py7e.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > since the draft allows for this situation and explains what to do about i= t, > and since i've implemented it and have run it successfully for six months, Your setup is probably not representative (is it mail only?) because it failed to detect initial breakage which other parties have observed subsequently. > and since unbound has implemented it and noone has reported trouble there, > i think it's safe to categorize this as "RDNS only". I suppose that, as far as DNS changes go, 0x20 is relatively risk-free. But it's still a protocol change that affects responders as well. (I would prefer if the authors answered my previous question about potential BCP 79 disclosures, though.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 10:07:08 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7144D3A6A79; Fri, 29 Aug 2008 10:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 IZO35LKdawFM; Fri, 29 Aug 2008 10:07:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAADA3A6A75; Fri, 29 Aug 2008 10:07:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ7Fi-0008TC-Su for namedroppers-data@psg.com; Fri, 29 Aug 2008 16:55:14 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ7Fe-0008Rv-SV for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 16:55:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 10D3DA66CE; Fri, 29 Aug 2008 16:54:51 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Alex Bligh cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 17:33:36 +0100." <46D2AD6CC587EA489E5EEE22@Ximines.local> References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> <46D2AD6CC587EA489E5EEE22@Ximines.local> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 16:54:51 +0000 Message-ID: <98780.1220028891@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 10D3DA66CE.0977C X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: More 0x20 craziness Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > >> - how do we identify those without doing every (final) query twice? > > > > we don't. that's the cost. > > > >> That appears to mean twice as many queries to the real authoritative > >> servers, for every QNAME, since it's perfectly possible for > >> foo.example.com to have a different final delegation chain to > >> www.example.com. > > > > once per new QNAME per RDNS per TTL. this is a lower number than you'd > > think. > > If combined with 0x20, could one only make the additional query if > (i) the original qname's case was not preserved or (ii) the qname > did not itself contain sufficient entropy (e.g. ".", "com." etc.)? > > Alex i love the sound of that, except, there isn't "an" additional query in the sense of "the one at the end that turns out to be one too many, that we'd like to avoid". you literally don't know which one is going to be the one you'd be trying to avoid, until after you've received an answer to it. however, if you changed this proposal to say "if there enough 0x20 bits and if the servers all echo them properly, then it's not nec'y to fully discover the NS RRset chain", then we could get a little further before logjamming on two other issues. issue the first is, the goal of this part of the proposal is to make it possible to be very draconian in the NS RRset replacement strategy, and i'm pretty sure that the number of bits i'd want to be protected by is in the 64-or-so range when i'm about to make a predictable refill query. issue the second is, one never knows if there's a UDP port derandomizer somewhere in the path between an RDNS and an ADNS, so the number of 0x20 bits needed for full confidence is really 48 or so, and that's a very long qname indeed. great thought though. you had me hoping there for a minute. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 10:15:01 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38373A69C5; Fri, 29 Aug 2008 10:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 DrKnTYg1SuoN; Fri, 29 Aug 2008 10:15:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8CAAF28C122; Fri, 29 Aug 2008 10:15:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ7Pt-0009tg-Ju for namedroppers-data@psg.com; Fri, 29 Aug 2008 17:05:45 +0000 Received: from [131.111.8.135] (helo=ppsw-5.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ7Ph-0009rg-UJ for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 17:05:43 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48612) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1KZ7Pa-00076f-HG (Exim 4.70) (return-path ); Fri, 29 Aug 2008 18:05:26 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KZ7Pa-000607-AN (Exim 4.67) (return-path ); Fri, 29 Aug 2008 18:05:26 +0100 Date: Fri, 29 Aug 2008 18:05:26 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: kaminsky resistance, section by section In-Reply-To: <2041.1219951326@nsa.vix.com> Message-ID: References: <2041.1219951326@nsa.vix.com> User-Agent: Alpine 1.10 (LSU 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 28 Aug 2008, Paul Vixie wrote: > for any given q-tuple where we have no specifically associated knowledge > of its delegation chain, we can first ask for . and > iterate downward along the returned NS RRsets until we receive one that > isn't a delegation (indicating that "randomstring" matches a wildcard, > or until we receive an NXDOMAIN. since there's no way to be sure that > www. and ftp. aren't zone apexes, we'll have to ask for > .www. and .ftp. separately, even though > we'll normally just learn that only has an NS RRset. this > extra cost allows us to commit to a draconian NS RRset replacement > strategy: if a response contains an NS RRset which attempts to change > the cache, then simply ignore the new one and delete the cached one, and > restart iteration. Doesn't that make it easy for an attacker to force you to spend all your time rediscovering the victim domain's NS RRset so that you are never able to resolve any victim names? Tony. -- f.anthony.n.finch http://dotat.at/ MALIN HEBRIDES BAILEY: SOUTHWESTERLY 5 OR 6,OCCASIONALLY 7 AT FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR DRIZZLE, FOG PATCHES IN MALIN, SHOWERS IN BAILEY LATER. MODERATE OR GOOD, OCCASIONALLY VERY POOR IN MALIN. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 10:16:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EF028C128; Fri, 29 Aug 2008 10:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] 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 DZD8n+Vcp6aW; Fri, 29 Aug 2008 10:16:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB31128C12D; Fri, 29 Aug 2008 10:15:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ7O7-0009fH-7P for namedroppers-data@psg.com; Fri, 29 Aug 2008 17:03:55 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ7Nt-0009cO-60 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 17:03:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0C8E8A6680; Fri, 29 Aug 2008 17:03:34 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: Stephane Bortzmeyer , Jim Reid , Nicholas Weaver , Namedroppers In-Reply-To: Your message of "Fri, 29 Aug 2008 18:45:09 +0200." <82hc93py7e.fsf@mid.bfk.de> References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> <26223.1219958219@nsa.vix.com> <20080829074209.GA15508@nic.fr> <88896.1220025059@nsa.vix.com> <82hc93py7e.fsf@mid.bfk.de> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 17:03:34 +0000 Message-ID: <617.1220029414@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 0C8E8A6680.50925 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > since the draft allows for this situation and explains what to do about it, > > and since i've implemented it and have run it successfully for six months, > > Your setup is probably not representative (is it mail only?) because > it failed to detect initial breakage which other parties have observed > subsequently. it failed because i had a bug in my syslog() library call arguments and i literally didn't know that it wasn't universally working. i quickly fixed that and found l.google.com and other nameservers, and the second 0x20 draft explained how to get confidence in the presence of a non-copying ADNS. all of this is in the record, and it does not invalidate the dns-0x20 approach. and for the record my setup is far from mail-only. > I suppose that, as far as DNS changes go, 0x20 is relatively risk-free. > But it's still a protocol change that affects responders as well. if it works today and will work whether or not any given ADNS is changed, and if the proposed protocol change is a new SHOULD rather than a new MUST, then i really think it's fair to categorize it as "RDNS only" when being compared to other approaches that don't work at all until some/most/all ADNS are changed. > (I would prefer if the authors answered my previous question about > potential BCP 79 disclosures, though.) ISC holds no patents today and has never applied for a patent. if we were to apply for a patent some day and if it was granted, then our corporate bylaws would mandate that the patent be universally available on an unrestricted royalty free basis with no attribution requirements, similar to the BSD license on our software. david dagon was acting as an ISC no-fee consultant when he came up with the idea of dns-0x20, and i was acting as an ISC employee when i wrote up the draft and did the initial pilot implementation. i hope this clarifies the BCP 79 status of dns-0x20. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 10:32:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F5F3A6A7E; Fri, 29 Aug 2008 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.355 X-Spam-Level: X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=1.244, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 9umPNpKle3w9; Fri, 29 Aug 2008 10:32:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 682723A6A47; Fri, 29 Aug 2008 10:32:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ7hs-000CNI-Qv for namedroppers-data@psg.com; Fri, 29 Aug 2008 17:24:20 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ7hn-000CMJ-7o for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 17:24:18 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 55785A66B3; Fri, 29 Aug 2008 17:24:12 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Tony Finch cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 18:05:26 +0100." References: <2041.1219951326@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 17:24:12 +0000 Message-ID: <3669.1220030652@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 55785A66B3.92B63 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: kaminsky resistance, section by section Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Doesn't that make it easy for an attacker to force you to spend all your > time rediscovering the victim domain's NS RRset so that you are never able > to resolve any victim names? "easy" is in the eye of the beholder. if noone is derandomizing your UDP port numbers then it will take an average of ten hours at multi-hundred-mbit to get you to do this one time. and that's assuming you don't have good 0x20 connectivity, or a private invitation-only VPN that RDNS and ADNS are part of but which attackers are mostly not, or TSIG, or TKEY, or PING, or DNSSEC. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 11:15:04 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220A33A6A59; Fri, 29 Aug 2008 11:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.123 X-Spam-Level: * X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 Sy+uGMbjjpi3; Fri, 29 Aug 2008 11:15:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0261E3A6A3B; Fri, 29 Aug 2008 11:15:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8Kd-000GvC-VG for namedroppers-data@psg.com; Fri, 29 Aug 2008 18:04:23 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8KY-000GuN-Fx for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 18:04:22 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1KZ8Jq-0006aU-M8; Fri, 29 Aug 2008 20:03:34 +0200 Received: from fweimer by bfk.de with local id 1KZ8Jy-0004A5-J5; Fri, 29 Aug 2008 20:03:42 +0200 To: Paul Vixie Cc: Stephane Bortzmeyer , Jim Reid , Nicholas Weaver , Namedroppers Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 References: <20080806144600.1F2E93A6AE8@core3.amsl.com> <5A983252-1BEF-46F2-9BF9-DA65C601C77A@rfc1035.com> <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> <26223.1219958219@nsa.vix.com> <20080829074209.GA15508@nic.fr> <88896.1220025059@nsa.vix.com> <82hc93py7e.fsf@mid.bfk.de> <617.1220029414@nsa.vix.com> From: Florian Weimer Date: Fri, 29 Aug 2008 20:03:42 +0200 In-Reply-To: <617.1220029414@nsa.vix.com> (Paul Vixie's message of "Fri, 29 Aug 2008 17:03:34 +0000") Message-ID: <827i9zpukh.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: >> > since the draft allows for this situation and explains what to do abou= t it, >> > and since i've implemented it and have run it successfully for six mon= ths, >>=20 >> Your setup is probably not representative (is it mail only?) because >> it failed to detect initial breakage which other parties have observed >> subsequently. > > it failed because i had a bug in my syslog() library call arguments and i > literally didn't know that it wasn't universally working. i quickly fixed > that and found l.google.com and other nameservers, Ah, okay. Thanks. >> I suppose that, as far as DNS changes go, 0x20 is relatively risk-free. >> But it's still a protocol change that affects responders as well. > > if it works today and will work whether or not any given ADNS is changed, I don't think your detection logic handles the NXDOMAIN-for-upper-case-but-echo-with-correct-echo case, but this one is violating the RFC and is terminally broken anyway (potential DoS through client query) and it should not be held against 0x20. If we can't label 0x20 as a protocol change for procedural reasons, I'm fine with that. > i hope this clarifies the BCP 79 status of dns-0x20. Yes, thank you very much. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 11:19:27 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F4B3A6A59; Fri, 29 Aug 2008 11:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 rdHj7bd+qeHd; Fri, 29 Aug 2008 11:19:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE5073A6A47; Fri, 29 Aug 2008 11:19:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8Ry-000HjI-TG for namedroppers-data@psg.com; Fri, 29 Aug 2008 18:11:58 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8Ru-000HiM-Vs for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 18:11:57 +0000 Received: from [192.168.100.2] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 03B42C2DA3; Fri, 29 Aug 2008 19:11:49 +0100 (BST) Date: Fri, 29 Aug 2008 19:11:47 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, Alex Bligh Subject: Re: More 0x20 craziness Message-ID: <9C4D168E0DAC744B84113AA5@Ximines.local> In-Reply-To: <98780.1220028891@nsa.vix.com> References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> <46D2AD6CC587EA489E5EEE22@Ximines.local> <98780.1220028891@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 August 2008 16:54:51 +0000 Paul Vixie wrote: > i love the sound of that, except, there isn't "an" additional query in the > sense of "the one at the end that turns out to be one too many, that we'd > like to avoid". you literally don't know which one is going to be the one > you'd be trying to avoid, until after you've received an answer to it. I need to think a bit more about that. I think a query by query illustration of how the "section by section" approach works would help illustrate it to people in general (not just me). > issue the first is, the goal of this part of the proposal is to make it > possible to be very draconian in the NS RRset replacement strategy, and > i'm pretty sure that the number of bits i'd want to be protected by is > in the 64-or-so range when i'm about to make a predictable refill query. > > issue the second is, one never knows if there's a UDP port derandomizer > somewhere in the path between an RDNS and an ADNS, so the number of 0x20 > bits needed for full confidence is really 48 or so, and that's a very > long qname indeed. Is it a reasonable assumption that if "the internet" (perhaps signaled by a couple of test probes) is not behind a port derandomiser, then no nameserver is? IE is discovery that an RDNS is "behind" a derandomiser (NAT / ALG etc.) sufficient to use as a heuristic for needing more entropy in the qname (under 0x20 or some other proposal), or do we also need to consider the case where any arbitrary ADNS might have a derandomiser in front of it? I am thinking that if we could put in the category of "if you run an ADNS like this you deserve to get your domains spoofed more easily", then an RDNS which could detect whether it is behind a NAT through queries to a couple of servers that happened to support a suitable extension could by extension apply (or not apply) that to all servers, and hence require more bits of entropy. A possible nit with approaches that rely on prepending data to the qname is that they risk shortening the maximum 'true' qname length. I think in the real world the heaviest user here is NSEC3 (no comments about DNSSEC and 'real world' in the same sentence please) and one presumes that this isn't a problem. Alex -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 11:19:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798C83A6A27; Fri, 29 Aug 2008 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 gN+MGO3rfv7J; Fri, 29 Aug 2008 11:19:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D61E3A69E9; Fri, 29 Aug 2008 11:19:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8QR-000HXP-5U for namedroppers-data@psg.com; Fri, 29 Aug 2008 18:10:23 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8QK-000HWW-2I for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 18:10:21 +0000 Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1KZ8QI-0002dQ-3i for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:10:14 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KZ8Q7-0007rD-M6 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:10:03 +0100 Message-ID: <3A4D1FF997C84B509F592475348DC99B@localhost> From: "George Barwood" To: References: <20080829135440.GA31481@nic.fr> Subject: Re: More 0x20 craziness Date: Fri, 29 Aug 2008 19:10:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I have now tried it out, and there seems to be a problem in some cases. The akamaiedge.net Bailwick returns Name Error (3) for .E120.G.akamaiedge.net with a SOA record ( and no name servers / referral ). However in stage 2, it generates a referral for the question E120.G.akamaiedge.net [ Client query was www.paypalobjects.com ] It still seems to be a good trick for queries to root and TLD servers, but I still cannot see any way of getting high security for akamaiedge.net ( although of course 0x20 helps a bit ). -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 11:26:45 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088B83A6A3B; Fri, 29 Aug 2008 11:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, 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 LhVlse+95U3N; Fri, 29 Aug 2008 11:26:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDC7E3A6930; Fri, 29 Aug 2008 11:26:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8Xv-000ITE-V2 for namedroppers-data@psg.com; Fri, 29 Aug 2008 18:18:07 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ8XM-000IMb-4f for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 18:17:36 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=U0rONo0Ij6Q312qClnVaEpBtEKXDCbiIgNnafia+A8UTwzTiM4gOXpV1 5BoMLi95q89NltWwJA8MBGBEWXfbdNU2i39cT4k0ZAyL2yUTyBvLeeRyg V+UF4FSUzxoZI6D; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1220033852; x=1251569852; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Roy=20Arends"=20|Subject: =20nonce=20label=20prefix=20(was=20Re:=20More=200x20=20cr aziness)|Date:=20Fri,=2029=20Aug=202008=2020:17:29=20+020 0|Message-ID:=20|To:=20namedroppers@ops. ietf.org|MIME-Version:=201.0|In-Reply-To:=20<91978.122002 6239@nsa.vix.com>|References:=20=20<20080829135440.GA31481@nic.fr>=20< A54877851E19339C3ED02E36@Ximines.local>=20=20=20<91978.1220026239@nsa.vix.com>; bh=Vxr7/2frjJq2kW4hctGY5tBXHrF9JTAPcTzvfbEA2Ws=; b=t2ddXzoeBe0xsfXn5RyvQPwzArn1ynVTYdQPfcALnZCrJ/ZyDR4Sn7Wj 1KWRXMrROMw70F3d8MeDnfCCIbl5m+wrplUV/C0HRSknuKPlSquITlsZj CLcNSF/V3tkppoL; X-IronPort-AV: E=Sophos;i="4.32,293,1217804400"; d="scan'208";a="6557979" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 29 Aug 2008 19:17:30 +0100 In-Reply-To: <91978.1220026239@nsa.vix.com> References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> To: namedroppers@ops.ietf.org Subject: nonce label prefix (was Re: More 0x20 craziness) MIME-Version: 1.0 X-Mailer: Lotus Notes Build VMac_Beta85_20080115_MM2 January 15, 2008 Message-ID: From: "Roy Arends" Date: Fri, 29 Aug 2008 20:17:29 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 29/08/2008 07:17:30 PM, Serialize complete at 29/08/2008 07:17:30 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote on 08/29/2008 06:10:39 PM: > Ray Bellis wrote on 08/29/2008 05:09:28 PM: > > > I also came up with this independently earlier this month, but only > > mentioned it to Roy and Wouter and didn't happen to mention it to Paul. > > i've also seen it mentioned in various non-mailing-list discussions all > year during the kaminsky exercises, but it could never overcome its > cost:benefit analysis until evan hunt mentioned it yesterday while i was > trying to figure out once again a way to delete contested NS RRsets from > the cache without immediately getting them poisoned by an attacker who > knew i'd be going uphill to refresh them. Since I'm mentioned here, I'll respond. Ray Bellis mentioned this idea to me on the 10th of August. I subsequently discussed it with Wouter Wijngaards as a possible scenario to add entropy during resolution of the delegation chain (for implementation in Unbound). I've not seen it mentioned before elsewhere. This is roughly what was discussed at the time: During resolution, prepend a label with a nonce to the query. The query would look like .www.example.com. Each request has a unique nonce, a nonce is never re-used. This continues until an authoritative answer is received (either NXDOMAIN, wildcard, CNAME, DNAME, anything that either terminates or restarts the resolution process). That authoritative answer comes most likely from a server that is authoritative for the www.example.com domain. (most likely, since in theory, the .www.example.com name could be delegated from the www.example.com domain, which is most unlikely, as that would suggest delegation point wildcard NS RRSets). Anyway, we now have an address of a nameserver that is authoritative for www.example.com. We could send it a priming query for the authoritative nameservers (Wouter Wijngaards idea). In any case, we can now send it a query for www.example.com. Regards Roy -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 12:42:43 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615133A6A6F; Fri, 29 Aug 2008 12:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 RcW9v02SFnct; Fri, 29 Aug 2008 12:42:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7AD043A686B; Fri, 29 Aug 2008 12:42:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9gi-00023o-0w for namedroppers-data@psg.com; Fri, 29 Aug 2008 19:31:16 +0000 Received: from [207.173.203.159] (helo=lists.commandprompt.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9ga-000233-1q for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:31:14 +0000 Received: from commandprompt.com (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7TJYCWa020430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Aug 2008 12:34:15 -0700 Date: Fri, 29 Aug 2008 15:31:03 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Possible materials for meeting in Minneapolis? Message-ID: <20080829193103.GK29678@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Fri, 29 Aug 2008 12:34:15 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, The scheduling period for requesting a WG meeting in Minneapolis is now open. Given the current amount of activity going on, it is possible that we will have material to discuss at such a meeting. It would be nice, however, if the Chairs could be confident there will be actual Internet Drafts available for working group consideration. Therefore, if you have or are working on a draft that you plan to ask the WG to adopt, it would be good to hear about that now (while we think about whether we need to schedule a session). Thanks, Andrew (for the Chairs) -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 12:46:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E1528C138; Fri, 29 Aug 2008 12:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] 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 IoV-YuQ5IwZ1; Fri, 29 Aug 2008 12:46:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB2923A686B; Fri, 29 Aug 2008 12:46:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9lo-0002aq-Km for namedroppers-data@psg.com; Fri, 29 Aug 2008 19:36:32 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9lk-0002aL-LN for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:36:30 +0000 Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7TJaNsi039963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 12:36:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080827170822.GH18946@commandprompt.com> References: <20080827170822.GH18946@commandprompt.com> Date: Fri, 29 Aug 2008 12:36:21 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Protecting caches? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 1:08 PM -0400 8/27/08, Andrew Sullivan wrote: >What I haven't seen much of is discussion of protecting caches _as >such_. That is, given that we are going to cache, are there >techniques that solve the dangers of a cache other than just >preventing the cache from ever having the wrong data in the first >place? What I have not seen, even post-Kaminsky, is a good discussion of what we put into a cache. For example, I am still befuddled about why part of the Kaminsky attack works. If I have a record in my cache with days left on the TTL, why should an attacker be able to change that record with bad information when I'm asking about a different record? The advantage of this ("we gave too long of a TTL and now need to move the IP address quickly") seems to be heavily outweighed by the ease of the attack. --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 12:51:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD32B3A6AAD; Fri, 29 Aug 2008 12:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, URI_NOVOWEL=1.62] 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 T+KL1j9-uwUl; Fri, 29 Aug 2008 12:51:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CDEC3A6A6F; Fri, 29 Aug 2008 12:51:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9rQ-0003Dt-0c for namedroppers-data@psg.com; Fri, 29 Aug 2008 19:42:20 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9rD-0003Bz-O5 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:42:09 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 95419A1056; Fri, 29 Aug 2008 19:41:57 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Alex Bligh cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 19:11:47 +0100." <9C4D168E0DAC744B84113AA5@Ximines.local> References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> <46D2AD6CC587EA489E5EEE22@Ximines.local> <98780.1220028891@nsa.vix.com> <9C4D168E0DAC744B84113AA5@Ximines.local> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 19:41:57 +0000 Message-ID: <25009.1220038917@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 95419A1056.54C59 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-SpamScore: s X-Vix-MailScanner-From: vixie@vix.com Subject: Re: More 0x20 craziness Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > i love the sound of that, except, there isn't "an" additional query in the > > sense of "the one at the end that turns out to be one too many, that we'd > > like to avoid". you literally don't know which one is going to be the one > > you'd be trying to avoid, until after you've received an answer to it. > > I need to think a bit more about that. I think a query by query > illustration of how the "section by section" approach works would help > illustrate it to people in general (not just me). you're right of course. > > issue the first is, the goal of this part of the proposal is to make it > > possible to be very draconian in the NS RRset replacement strategy, and > > i'm pretty sure that the number of bits i'd want to be protected by is > > in the 64-or-so range when i'm about to make a predictable refill query. > > > > issue the second is, one never knows if there's a UDP port derandomizer > > somewhere in the path between an RDNS and an ADNS, so the number of 0x20 > > bits needed for full confidence is really 48 or so, and that's a very > > long qname indeed. > > Is it a reasonable assumption that if "the internet" (perhaps signaled by > a couple of test probes) is not behind a port derandomiser, then no > nameserver is? IE is discovery that an RDNS is "behind" a derandomiser > (NAT / ALG etc.) sufficient to use as a heuristic for needing more > entropy in the qname (under 0x20 or some other proposal), ... i'm saying no, because the probes can become a new vulnerability (to either attacks, or implementation errors, or new kinds of middleboxes), and because topology and topography can change. and that's not counting the possibility that an RDNS may be in a multipath topology where some packets get their UDP port numbers derandomized and some do not. there's too much variability, now and in the future, for me to get comfortable with modality of this kind. i'd be a lot more comfortable if we came up with something we "just always do". > A possible nit with approaches that rely on prepending data to the qname > is that they risk shortening the maximum 'true' qname length. I think in > the real world the heaviest user here is NSEC3 (no comments about DNSSEC > and 'real world' in the same sentence please) and one presumes that this > isn't a problem. > > Alex indeed, we're talking about burning some qname length. however, i'm only asking for 64 bits, which using base32 is eleven ASCII characters, which is not a lot to take out of a 256-character quota. --- note that many "nameservers" just don't answer some of the queries i'm saying we should send to protect the authority section. the NS's for www.cnn.com just time out on "dig @dmtns01.turner.com. kjhsdfkjhsdf.www.cnn.com in a". this is clearly not a real name server, it's a dns middlebox of some kind, one of many that does the wrong thing. (i don't mind somebody who doesn't answer NS queries since these are always diagnostic in nature, but someone who won't send a delegation unless they recognize the qname is just evil.) ((thanks to dan kaminsky's blog for pointing out the CNN example, and to robert edmonds who shared it with me.)) -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 12:53:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0123F3A6AAD; Fri, 29 Aug 2008 12:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] 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 WvGCsh2LQZs4; Fri, 29 Aug 2008 12:53:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FA263A6A6F; Fri, 29 Aug 2008 12:53:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9uJ-0003aS-Ra for namedroppers-data@psg.com; Fri, 29 Aug 2008 19:45:19 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZ9u4-0003X2-1y for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:45:09 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 65671A66C9; Fri, 29 Aug 2008 19:44:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "Roy Arends" cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 20:17:29 +0200." References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 19:44:59 +0000 Message-ID: <25745.1220039099@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 65671A66C9.9D19D X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: nonce label prefix (was Re: More 0x20 craziness) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > ... > We could send it a priming query for the authoritative nameservers (Wouter > Wijngaards idea). > ... root name servers have to answer priming queries. noone else has to, and many do not. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 13:01:57 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F1C3A67B7; Fri, 29 Aug 2008 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 IsRAwYJ6cJbF; Fri, 29 Aug 2008 13:01:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CA8B3A67F2; Fri, 29 Aug 2008 13:01:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZA2m-0004eM-8X for namedroppers-data@psg.com; Fri, 29 Aug 2008 19:54:04 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZA2i-0004dL-Jm for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:54:02 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id D0E0A33C59; Fri, 29 Aug 2008 12:53:59 -0700 (PDT) Date: Fri, 29 Aug 2008 12:53:59 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy Arends" Cc: namedroppers@ops.ietf.org Subject: Re: nonce label prefix (was Re: More 0x20 craziness) In-Reply-To: References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Fri, 29 Aug 2008 20:17:29 +0200, "Roy Arends" wrote: > During resolution, prepend a label with a nonce to the query. The query > would look like .www.example.com. Each request has a unique nonce, > a nonce is never re-used. > > This continues until an authoritative answer is received (either NXDOMAIN, > wildcard, CNAME, DNAME, anything that either terminates or restarts the > resolution process). That authoritative answer comes most likely from a > server that is authoritative for the www.example.com domain. (most likely, > since in theory, the .www.example.com name could be delegated from > the www.example.com domain, which is most unlikely, as that would suggest > delegation point wildcard NS RRSets). > > Anyway, we now have an address of a nameserver that is authoritative for > www.example.com. > We could send it a priming query for the authoritative nameservers (Wouter > Wijngaards idea). > In any case, we can now send it a query for www.example.com. One thing I've puzzled about regarding this type of approach is its cost-benefit tradeoff. If we can only use it in identifying intermediate NSes, I thought our 'best current practice' (i.e., randomized QID + source port (+ perhaps source IP address (+ perhaps 'traditional' 0x20))) already provided reasonable security. We could also use this to confirm possible change of already cached NS as seemingly indicated in this thread, but for that purpose we can actually simply fetch the authoritative NS RRset directly; then the trust ranking concept of RFC2181 will protect us from further attacks. Of course, the or makes the transaction even securer, so if we can get it free, that would be wonderful; but it actually comes with a cost, including more queries that are redundant otherwise, handling miscellaneous corner cases or non compliant authoritative servers, run-time cost including getting additional entropy, and of course implementation cost (which is probably minor, though). So far, the tradeoff is not so obvious to me (indeed, it seems to me the known benefit isn't worth the cost), but as no one else seems to have the same doubt, am I missing something fundamental, or does the benefit so obviously outweigh the cost for others? --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 13:02:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94043A6ABB; Fri, 29 Aug 2008 13:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[AWL=-1.740, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, URI_NOVOWEL=1.62] 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 KNGnqf9H24XW; Fri, 29 Aug 2008 13:02:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C76CD28C12B; Fri, 29 Aug 2008 13:02:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZA3m-0004nw-80 for namedroppers-data@psg.com; Fri, 29 Aug 2008 19:55:06 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZA3i-0004mn-PR for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:55:04 +0000 Received: from [192.168.100.2] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id EBBE4C2DA3; Fri, 29 Aug 2008 20:54:56 +0100 (BST) Date: Fri, 29 Aug 2008 20:54:51 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, Alex Bligh Subject: Re: More 0x20 craziness Message-ID: <9E4E05C74E18AAB6B95A2A2E@Ximines.local> In-Reply-To: <25009.1220038917@nsa.vix.com> References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> <46D2AD6CC587EA489E5EEE22@Ximines.local> <98780.1220028891@nsa.vix.com> <9C4D168E0DAC744B84113AA5@Ximines.local> <25009.1220038917@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 August 2008 19:41:57 +0000 Paul Vixie wrote: > note that many "nameservers" just don't answer some of the queries i'm > saying we should send to protect the authority section. the NS's for > www.cnn.com just time out on "dig @dmtns01.turner.com. > kjhsdfkjhsdf.www.cnn.com in a". this is clearly not a real name server, > it's a dns middlebox of some kind, one of many that does the wrong thing. > (i don't mind somebody who doesn't answer NS queries since these are > always diagnostic in nature, but someone who won't send a delegation > unless they recognize the qname is just evil.) ((thanks to dan kaminsky's > blog for pointing out the CNN example, and to robert edmonds who shared > it with me.)) Well, I think breaking resolution for ADNS (or more accurately middlebox infested ADNS) which are clearly and irrefutably non-compliant is an acceptable price given vendors have now some time to fix it, assuming the population isn't that large - after all port randomisation broke many dubious firewall configs and was deemed acceptable, and I suspect the total number of broken DNS middleboxen is far smaller than this. I'm sure cnn.com have a vested interest in making sure cnn.com continues to resolve, and far more ability to make sure it does than your average Joe firewall user. Alex -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 13:02:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D69128C145; Fri, 29 Aug 2008 13:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] 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 h6FZ3z76zfeo; Fri, 29 Aug 2008 13:02:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4653528C12B; Fri, 29 Aug 2008 13:02:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZA27-0004YA-6D for namedroppers-data@psg.com; Fri, 29 Aug 2008 19:53:23 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZA24-0004Xm-05 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:53:21 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4080DA66B7; Fri, 29 Aug 2008 19:53:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Andrew Sullivan cc: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 15:31:03 -0400." <20080829193103.GK29678@commandprompt.com> References: <20080829193103.GK29678@commandprompt.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 19:53:11 +0000 Message-ID: <26899.1220039591@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 4080DA66B7.047F5 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Possible materials for meeting in Minneapolis? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: if dns-0x20 has been adopted, then i'd like to get reviews and comments so i can rev the draft before minneapolis. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 13:03:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35E428C147; Fri, 29 Aug 2008 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] 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 oOw9BfPH456M; Fri, 29 Aug 2008 13:03:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECE1B28C12B; Fri, 29 Aug 2008 13:03:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZA40-0004pY-7k for namedroppers-data@psg.com; Fri, 29 Aug 2008 19:55:20 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZA3x-0004oz-0c for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 19:55:18 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 281C2A66BC; Fri, 29 Aug 2008 19:55:13 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Paul Hoffman cc: Andrew Sullivan , namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 12:36:21 MST." References: <20080827170822.GH18946@commandprompt.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 19:55:13 +0000 Message-ID: <27375.1220039713@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 281C2A66BC.7A00F X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Protecting caches? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > What I have not seen, even post-Kaminsky, is a good discussion of > what we put into a cache. For example, I am still befuddled about why > part of the Kaminsky attack works. If I have a record in my cache > with days left on the TTL, why should an attacker be able to change > that record with bad information when I'm asking about a different > record? The advantage of this ("we gave too long of a TTL and now > need to move the IP address quickly") seems to be heavily outweighed > by the ease of the attack. > > --Paul Hoffman, Director > --VPN Consortium RFC 2181 codified a credibility ranking system which controlled some aspects of cache replacement. it's possible that it should have said more, gone further. however, it's ultimately desireable that a long TTL not lock out same-credibility replacement data. TTL is about expiry not replacement. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 13:28:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B510E28C160; Fri, 29 Aug 2008 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] 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 3nBPUsEvs0pf; Fri, 29 Aug 2008 13:28:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5E4E28C163; Fri, 29 Aug 2008 13:28:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZAQ6-0007qV-Il for namedroppers-data@psg.com; Fri, 29 Aug 2008 20:18:10 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZAQ2-0007q2-3Y for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 20:18:08 +0000 Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7TKI0Z6043237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 13:18:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <27375.1220039713@nsa.vix.com> References: <20080827170822.GH18946@commandprompt.com> <27375.1220039713@nsa.vix.com> Date: Fri, 29 Aug 2008 13:17:58 -0700 To: Paul Vixie From: Paul Hoffman Subject: Re: Protecting caches? Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 7:55 PM +0000 8/29/08, Paul Vixie wrote: > > What I have not seen, even post-Kaminsky, is a good discussion of >> what we put into a cache. For example, I am still befuddled about why >> part of the Kaminsky attack works. If I have a record in my cache >> with days left on the TTL, why should an attacker be able to change >> that record with bad information when I'm asking about a different >> record? The advantage of this ("we gave too long of a TTL and now >> need to move the IP address quickly") seems to be heavily outweighed >> by the ease of the attack. >> >> --Paul Hoffman, Director >> --VPN Consortium > >RFC 2181 codified a credibility ranking system which controlled some >aspects of cache replacement. Right. >it's possible that it should have said >more, gone further. Or that it should be reconsidered in the current light. A small modification to the text might go a long way. For example, it says: Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. Adding "or glue from a primary zone" to the list in the first sentence would eliminate the effects of the Kaminsky attack, would it not? >however, it's ultimately desireable that a long >TTL not lock out same-credibility replacement data. TTL is about >expiry not replacement. That is the crux of the question. It sounds like you disagree with my assessment that the disadvantage of this policy (the Kaminsky attack) is stronger than the advantage (allowing replacement before expiry, even if the replacement is from an attacker). --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 13:35:08 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426BB28C158; Fri, 29 Aug 2008 13:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] 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 tX5ylKVBK7kD; Fri, 29 Aug 2008 13:35:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4621B3A696B; Fri, 29 Aug 2008 13:35:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZAY8-0008lL-Qv for namedroppers-data@psg.com; Fri, 29 Aug 2008 20:26:28 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZAY5-0008kv-00 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 20:26:26 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1DA71A200B; Fri, 29 Aug 2008 20:26:21 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Paul Hoffman cc: Andrew Sullivan , namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 13:17:58 MST." References: <20080827170822.GH18946@commandprompt.com> <27375.1220039713@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 20:26:21 +0000 Message-ID: <31718.1220041581@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 1DA71A200B.52B0D X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Protecting caches? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Adding "or glue from a primary zone" to the list in the first sentence > would eliminate the effects of the Kaminsky attack, would it not? for replacement, but not insertion, yes. > >however, it's ultimately desireable that a long TTL not lock out > >same-credibility replacement data. TTL is about expiry not replacement. > > That is the crux of the question. It sounds like you disagree with my > assessment that the disadvantage of this policy (the Kaminsky attack) is > stronger than the advantage (allowing replacement before expiry, even if > the replacement is from an attacker). i know there are a lot of working configurations which depend on low latency cache replacement and so have long ttl's. we'd be breaking these. i suspect that there are more such currently working configurations than i know about. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 14:54:32 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13A128C155; Fri, 29 Aug 2008 14:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, 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 RaBLLaSURaz9; Fri, 29 Aug 2008 14:54:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B637C28C0E2; Fri, 29 Aug 2008 14:54:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZBm5-000GvX-7D for namedroppers-data@psg.com; Fri, 29 Aug 2008 21:44:57 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZBln-000GsK-Ec for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 21:44:43 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=sbMNdxxSc4MMJN8HczskGEJ/QaJKKm+MpvloprhhzW0dOStU+AInQlyn UxQDGyqztx9MHcSFabPuTGfX/QY/fy24JY0qYB1nGbVX4a7KlXX+eX6OW J/a70odC4Pw/nNL; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1220046279; x=1251582279; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20nonce =20label=20prefix=20(was=20Re:=20More=200x20=20craziness) |Date:=20Fri,=2029=20Aug=202008=2022:44:35=20+0100 |Message-ID:=20|To:=20namedroppers@ops.i etf.org|MIME-Version:=201.0|In-Reply-To:=20; bh=dnPvVb0NMjmDqyNZj/nhUkK36nTzVJXG4v40EiJowg4=; b=NE/guUJjAAWptoUoVruQR/RnhZKU+eKQv23eWQkZWiBa/EW+DOpptH1h aiWgteu2OkThsQ/lCEo1UQ0O2E5Ne6XTVegG3ZUmLaPhMoOJdmCvBs0hZ DBY/c24+gbrUJUj; X-IronPort-AV: E=Sophos;i="4.32,295,1217804400"; d="scan'208";a="6562480" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 29 Aug 2008 22:44:37 +0100 In-Reply-To: To: namedroppers@ops.ietf.org Subject: Re: nonce label prefix (was Re: More 0x20 craziness) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 29 Aug 2008 22:44:35 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 29/08/2008 10:44:37 PM, Serialize complete at 29/08/2008 10:44:37 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > but for that purpose we can actually simply fetch the authoritative > NS RRset directly; then the trust ranking concept of RFC2181 will > protect us from further attacks. The problem as I saw it is that the real authoritative NS RRset (the one that's in the delegated zone) has to be fetched from an IP address which is learnt from DNS requests which are less credible (per RFC2181 rules). Or, to put it another way, you're suggesting that we believe 5th tier information ("glue from a primary zone") to get 3rd tier information ("authoritative data included in the answer section of an authoritative reply"). However, the Kaminksy attack pollutes the cache with spoofed 4th tier data ("data from the authority section of an authoritative answer"). _ So, we've a known attack against tier 4, but we have to _really_ believe the tier 5 data before we can reliably obtain the real tier 3 data. Ray -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 15:32:50 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68383A685B; Fri, 29 Aug 2008 15:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 HGHqG+yr-ANi; Fri, 29 Aug 2008 15:32:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BCB3E3A6803; Fri, 29 Aug 2008 15:32:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZCMn-000KQe-IP for namedroppers-data@psg.com; Fri, 29 Aug 2008 22:22:53 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZCMj-000KQ7-UN for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 22:22:51 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 8EF6433C59; Fri, 29 Aug 2008 15:22:49 -0700 (PDT) Date: Fri, 29 Aug 2008 15:22:49 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ray.Bellis@nominet.org.uk Cc: namedroppers@ops.ietf.org Subject: Re: nonce label prefix (was Re: More 0x20 craziness) In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Fri, 29 Aug 2008 22:44:35 +0100, Ray.Bellis@nominet.org.uk wrote: > > but for that purpose we can actually simply fetch the authoritative > > NS RRset directly; then the trust ranking concept of RFC2181 will > > protect us from further attacks. > > The problem as I saw it is that the real authoritative NS RRset (the one > that's in the delegated zone) has to be fetched from an IP address which > is learnt from DNS requests which are less credible (per RFC2181 rules). > > Or, to put it another way, you're suggesting that we believe 5th tier > information ("glue from a primary zone") to get 3rd tier information > ("authoritative data included in the answer section of an authoritative > reply"). Right, but that part is established by "identifying intermediate NSes" (quoting my previous message) and "I thought our 'best current practice' (i.e., randomized QID + source port (+ perhaps source IP address (+ perhaps 'traditional' 0x20))) already provided reasonable security" (ditto). Note that the available window for the attacker is very limited (generally, just once per TTL) because we'd trigger the confirmation query if we detect an update attempt with different information. Again, I understand the additional nonce makes this process even securer. My question is whether the benefit outweighs its cost. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 15:44:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462113A685B; Fri, 29 Aug 2008 15:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] 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 49-YyuMWHbvJ; Fri, 29 Aug 2008 15:44:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E9033A6827; Fri, 29 Aug 2008 15:44:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZCZk-000LZB-HS for namedroppers-data@psg.com; Fri, 29 Aug 2008 22:36:16 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZCZg-000LYp-Nx for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 22:36:14 +0000 Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7TMa14U051861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 15:36:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <31718.1220041581@nsa.vix.com> References: <20080827170822.GH18946@commandprompt.com> <27375.1220039713@nsa.vix.com> <31718.1220041581@nsa.vix.com> Date: Fri, 29 Aug 2008 15:36:00 -0700 To: Paul Vixie From: Paul Hoffman Subject: Re: Protecting caches? Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 8:26 PM +0000 8/29/08, Paul Vixie wrote: > > Adding "or glue from a primary zone" to the list in the first sentence >> would eliminate the effects of the Kaminsky attack, would it not? > >for replacement, but not insertion, yes. Agree. > > >however, it's ultimately desireable that a long TTL not lock out >> >same-credibility replacement data. TTL is about expiry not replacement. >> >> That is the crux of the question. It sounds like you disagree with my >> assessment that the disadvantage of this policy (the Kaminsky attack) is >> stronger than the advantage (allowing replacement before expiry, even if >> the replacement is from an attacker). > >i know there are a lot of working configurations which depend on low latency >cache replacement and so have long ttl's. we'd be breaking these. i suspect >that there are more such currently working configurations than i know about. Could you (or someone) describe these? What is their reason for a long TTL if they know there is going to be a replacement? --Paul Hoffman, Director --VPN Consortium -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 16:00:26 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC69828C162; Fri, 29 Aug 2008 16:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] 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 yG+DN2dRDyKN; Fri, 29 Aug 2008 16:00:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09D913A6A81; Fri, 29 Aug 2008 16:00:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZCow-000N33-O7 for namedroppers-data@psg.com; Fri, 29 Aug 2008 22:51:58 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZCot-000N2f-7D for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 22:51:56 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7DE3EA66B5; Fri, 29 Aug 2008 22:51:45 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Alex Bligh cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 20:54:51 +0100." <9E4E05C74E18AAB6B95A2A2E@Ximines.local> References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> <46D2AD6CC587EA489E5EEE22@Ximines.local> <98780.1220028891@nsa.vix.com> <9C4D168E0DAC744B84113AA5@Ximines.local> <25009.1220038917@nsa.vix.com> <9E4E05C74E18AAB6B95A2A2E@Ximines.local> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 22:51:45 +0000 Message-ID: <51003.1220050305@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 7DE3EA66B5.1D59D X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: More 0x20 craziness Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Well, I think breaking resolution for ADNS (or more accurately middlebox > infested ADNS) which are clearly and irrefutably non-compliant is an > acceptable price given vendors have now some time to fix it, assuming the > population isn't that large - after all port randomisation broke many > dubious firewall configs and was deemed acceptable, and I suspect the > total number of broken DNS middleboxen is far smaller than this. I'm > sure cnn.com have a vested interest in making sure cnn.com continues to > resolve, and far more ability to make sure it does than your average Joe > firewall user. i'm not sure how successful bind or unbound or nominum would be with a patch that broke www.cnn.com, however. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 16:06:53 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98CD3A6AAB; Fri, 29 Aug 2008 16:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] 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 u1lKA9VfTk3d; Fri, 29 Aug 2008 16:06:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0E603A6A81; Fri, 29 Aug 2008 16:06:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZCtn-000NZe-Vh for namedroppers-data@psg.com; Fri, 29 Aug 2008 22:56:59 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZCtk-000NYm-56 for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 22:56:57 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C97F8A6684; Fri, 29 Aug 2008 22:56:49 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: "Roy Arends" , namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 29 Aug 2008 12:53:59 MST." References: <20080829135440.GA31481@nic.fr> <91978.1220026239@nsa.vix.com> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Fri, 29 Aug 2008 22:56:49 +0000 Message-ID: <51778.1220050609@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: C97F8A6684.8A696 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: nonce label prefix (was Re: More 0x20 craziness) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > So far, the tradeoff is not so obvious to me (indeed, it seems to me > the known benefit isn't worth the cost), but as no one else seems to > have the same doubt, am I missing something fundamental, or does the > benefit so obviously outweigh the cost for others? > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. i am also reconsidering these issues. -- 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: From owner-namedroppers@ops.ietf.org Fri Aug 29 16:53:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BF913A695A; Fri, 29 Aug 2008 16:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599] 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 chAjVLJD03KC; Fri, 29 Aug 2008 16:53:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 226E93A6836; Fri, 29 Aug 2008 16:53:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZDe2-0001wR-Ak for namedroppers-data@psg.com; Fri, 29 Aug 2008 23:44:46 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZDdy-0001vv-ND for namedroppers@ops.ietf.org; Fri, 29 Aug 2008 23:44:44 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7TNiaHh048210; Sat, 30 Aug 2008 09:44:37 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808292344.m7TNiaHh048210@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Possible materials for meeting in Minneapolis? In-reply-to: Your message of "Fri, 29 Aug 2008 15:31:03 -0400." <20080829193103.GK29678@commandprompt.com> Date: Sat, 30 Aug 2008 09:44:36 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: draft-andrews-dnsext-expire-XX -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 01:10:37 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD37D3A6930; Sat, 30 Aug 2008 01:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 88Z2EpoW8K3P; Sat, 30 Aug 2008 01:10:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0B893A691C; Sat, 30 Aug 2008 01:10:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZLMS-000LYr-Bd for namedroppers-data@psg.com; Sat, 30 Aug 2008 07:59:08 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZLMO-000LYS-J3 for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 07:59:06 +0000 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1KZLLy-0005c1-7M; Sat, 30 Aug 2008 08:58:38 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KZLLs-0002jn-Qt; Sat, 30 Aug 2008 08:58:32 +0100 Message-ID: <4ED8ECFCFB454F68953E1B2C6318A624@localhost> From: "George Barwood" To: "Paul Vixie" Cc: References: <15CBB956E5654625A795DE2D8269A1A1@localhost> <2871.1219436191@nsa.vix.com> <20F912BB5A594AA98CD15D379D56CC96@localhost> <90256.1220025602@nsa.vix.com> Subject: Re: Defending against the Kaminsky attack Date: Sat, 30 Aug 2008 08:58:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I now agree that this whole idea ( of performing checks other than the standard Bailiwick check ) is a dead end. It just doesn't work, thanks to Wouter Winjgaards for pointing me to the case of Peter Koch's 'phantom referral', so the only way forward is getting more entropy. I believe there are 3 mechanisms that work. (1) The 0x20 proposal. (2) For Root and TLD queries, prepending a random nonce to the question. (3) Repeating the query, and using a temporary data structure to "converge" the result. Recently expired cache entries can be taken into account so that for TTL refresh operations, repetition is not required. [ I am trying this, and so far it works very nicely at 50 bits of entropy, without random source port ] -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 10:46:44 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B343A69CE; Sat, 30 Aug 2008 10:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 dvyK6+pKQKfw; Sat, 30 Aug 2008 10:46:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EAC83A687D; Sat, 30 Aug 2008 10:46:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZUMJ-0005ZF-U9 for namedroppers-data@psg.com; Sat, 30 Aug 2008 17:35:35 +0000 Received: from [2001:ba8:1f1:f045::2] (helo=weevil.pwns.ms) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZUMB-0005Xa-TT for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 17:35:30 +0000 Received: by weevil.pwns.ms (Postfix, from userid 1000) id 4854BC0DC; Sat, 30 Aug 2008 17:35:23 +0000 (UTC) Date: Sat, 30 Aug 2008 17:35:23 +0000 From: list-namedroppers@pwns.ms To: namedroppers@ops.ietf.org Subject: Re: Some Observations on Entropy Re: Some observations on dns-0x20 Message-ID: <20080830173522.GA4379@pwns.ms> References: <200808290117.m7T1HAWd037207@drugs.dv.isc.org> <72632.1219976772@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72632.1219976772@nsa.vix.com> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > agreed. testing for this and responding to it adds complexity and doesn't > nec'ily buy you anything if the ADNS you're querying is behind their own > local NAT-based derandomizer. The only circumstance I've thought of where that is true is where the attacker is behind that NAT device and is capable of spoofing packets. This is surely a very rare position. MITM attacks are possible in most of those positions; e.g. ARP spoofing the gateway. It's up to the ADNS operator to ensure their network isn't braindead. Furthermore, I think ADNSs are rarely behind NAT devices. -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 12:57:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919A63A68BD; Sat, 30 Aug 2008 12:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NvBvJJ1WudfM; Sat, 30 Aug 2008 12:57:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F2483A67F4; Sat, 30 Aug 2008 12:57:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZWQh-000KeL-9w for namedroppers-data@psg.com; Sat, 30 Aug 2008 19:48:15 +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 ) id 1KZWQZ-000Kd3-QY for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 19:48:13 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KZWQV-0007Cm-54 for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 21:48:03 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 93C3A4B44F; Sat, 30 Aug 2008 21:48:15 +0200 (CEST) Date: Sat, 30 Aug 2008 21:48:15 +0200 From: bert hubert To: Paul Hoffman Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: Protecting caches? Message-ID: <20080830194815.GB25475@outpost.ds9a.nl> References: <20080827170822.GH18946@commandprompt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 29, 2008 at 12:36:21PM -0700, Paul Hoffman wrote: > part of the Kaminsky attack works. If I have a record in my cache > with days left on the TTL, why should an attacker be able to change > that record with bad information when I'm asking about a different > record? The advantage of this ("we gave too long of a TTL and now Most programmers of servers used to act on the assumption that packets (and by extension, questions) were expensive. An answer carrying 'free' data for which the resolver considered it authoritative was more than welcome in this respect. Plus the oft quoted credibility rules of course. I'm moving to having a switch that lets data with an unexpired TTL not be overwritten by newer answers. 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 13:42:06 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED59B3A67FE; Sat, 30 Aug 2008 13:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 62pkL1tpaQ68; Sat, 30 Aug 2008 13:42:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB9013A6889; Sat, 30 Aug 2008 13:42:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZX87-000PJ0-1N for namedroppers-data@psg.com; Sat, 30 Aug 2008 20:33:07 +0000 Received: from [64.158.219.15] (helo=secure.perfectemail.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZX81-000PIR-Qq for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 20:33:04 +0000 Received: (qmail 32759 invoked from network); 30 Aug 2008 20:33:00 -0000 Received: from c-71-202-44-149.hsd1.ca.comcast.net (HELO Zion.local) (71.202.44.149) by secure.perfectemail.net with SMTP; 30 Aug 2008 20:33:00 -0000 Message-ID: <48B9AE7C.4070703@everydns.net> Date: Sat, 30 Aug 2008 13:33:00 -0700 From: David Ulevitch User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "namedroppers@ops.ietf.org" Subject: dnscurve -- new or did I just miss this? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: http://dnscurve.org/ DNSCurve uses high-speed high-security elliptic-curve cryptography to drastically improve every dimension of DNS security: * Confidentiality: DNS requests and responses today are completely unencrypted and are broadcast to any attacker who cares to look. DNSCurve encrypts all DNS packets. * Integrity: DNS today uses "UDP source-port randomization" and "TXID randomization" to create some speed bumps for blind attackers, but patient attackers and sniffing attackers can easily forge DNS records. DNSCurve cryptographically authenticates all DNS responses, eliminating forged DNS packets. * Availability: DNS today has no protection against denial of service. A sniffing attacker can disable all of your DNS lookups by sending just a few forged packets per second. DNSCurve very quickly recognizes and discards forged packets, so attackers have much more trouble preventing DNS data from getting through. Protection is also needed for SMTP, HTTP, HTTPS, etc., but protecting DNS is the first step. Despite its extremely high level of security, DNSCurve is very easy for software authors to implement, and very easy for administrators to deploy. -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 15:04:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8683A694C; Sat, 30 Aug 2008 15:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.227 X-Spam-Level: **** X-Spam-Status: No, score=4.227 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, 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 nCDvjv-6eXFR; Sat, 30 Aug 2008 15:04:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E91E93A6AA8; Sat, 30 Aug 2008 15:04:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZYMs-0007TW-M8 for namedroppers-data@psg.com; Sat, 30 Aug 2008 21:52:26 +0000 Received: from [74.125.78.25] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZYMn-0007RC-Oh for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 21:52:24 +0000 Received: by ey-out-2122.google.com with SMTP id 25so560294eya.65 for ; Sat, 30 Aug 2008 14:52:19 -0700 (PDT) Received: by 10.210.39.2 with SMTP id m2mr3848636ebm.97.1220133139356; Sat, 30 Aug 2008 14:52:19 -0700 (PDT) Received: by 10.210.63.13 with HTTP; Sat, 30 Aug 2008 14:52:19 -0700 (PDT) Message-ID: Date: Sat, 30 Aug 2008 23:52:19 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: "David Ulevitch" Subject: Re: dnscurve -- new or did I just miss this? Cc: "namedroppers@ops.ietf.org" In-Reply-To: <48B9AE7C.4070703@everydns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <48B9AE7C.4070703@everydns.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: PiBkbnNjdXJ2ZSAtLSBuZXcgb3IgZGlkIEkganVzdCBtaXNzIHRoaXM/CgpDcmVhdGVkIE9uOjEw LUF1Zy0yMDA4IDA2OjMyOjU5IFVUQwpMYXN0IFVwZGF0ZWQgT246MjctQXVnLTIwMDggMTM6MTc6 MzkgVVRDClJlZ2lzdHJhbnQgTmFtZTpEYW5pZWwgSi4gQmVybnN0ZWluCgo+IGh0dHA6Ly9kbnNj dXJ2ZS5vcmcvCgpJIGhhdmUgcmVhZCB0aG9zZSBwYWdlcyBhbmQgYXMgSSB1bmRlcnN0YW5kIHRo ZW0gZGpiIHByb3Bvc2VzCmVuY3J5cHRpbmcgRE5TIGNvbW11bmljYXRpb24gKGVuY2Fwc3VsYXRp bmcgaXQgaW50byBUWFQgcXVlcnkKYW5kIHJlc3BvbnNlKSB3aGVuIGl0IHNlZXMgc29tZSBzcGVj aWFsIHN0cmluZyBpbiBkb21haW4KbmFtZSAoJ3V6NScpLgoKQnV0IHNpbmNlIEROU0N1cnZlIGRv ZXNuJ3QgaGF2ZSB0cnVzdCBhbmNob3JzIGl0IGRvZXMgbm90IHByb3RlY3QKeW91IGJlZm9yZSB5 b3UgZ2V0IHRoaXMgbmV3IHNwZWNpYWwgbmFtZSAod2hpY2ggaXMgZGlzdHJpYnV0ZWQKYnkgUE9E UykuICBJIGNhbiBldmVuIHNwb29mIEROU0N1cnZlIG5hbWVzZXJ2ZXIgYW5kIG15ICpldmlsKgpE TlMgc2VydmVyIGNhbiB0YWxrIEROU0N1cnZlIHByb3RvY29sLiAgQmFzaWNhbHkgaXQncyBsaWtl CnNlbGYtc2lnbmVkIGNlcnRpZmljYXRlcy4KCk9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/CgpP bmRyZWouCi0tIAogT25kxZllaiBTdXLDvQogdGVjaG5pY2vDvSDFmWVkaXRlbC9DaGllZiBUZWNo bmljYWwgT2ZmaWNlcgogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K IENaLk5JQywgei5zLnAuby4gLS0gLmN6IGRvbWFpbiByZWdpc3RyeQogQW1lcmlja8OhIDIzLDEy MCAwMCBQcmFoYSAyLEN6ZWNoIFJlcHVibGljCiBtYWlsdG86b25kcmVqLnN1cnlAbmljLmN6IGh0 dHA6Ly9uaWMuY3ovCiBzaXA6b25kcmVqLnN1cnlAbmljLmN6IHRlbDorNDIwLjIyMjc0NTExMAog bW9iOis0MjAuNzM5MDEzNjk5IGZheDorNDIwLjIyMjc0NTExMgogLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 15:48:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DFAB3A6B29; Sat, 30 Aug 2008 15:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 xZOunkl8U+-n; Sat, 30 Aug 2008 15:48:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11DAA3A6AE6; Sat, 30 Aug 2008 15:48:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZZ5i-000CM2-6m for namedroppers-data@psg.com; Sat, 30 Aug 2008 22:38:46 +0000 Received: from [2001:ba8:1f1:f045::2] (helo=weevil.pwns.ms) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZZ5c-000CLY-W3 for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 22:38:43 +0000 Received: by weevil.pwns.ms (Postfix, from userid 1000) id D1261C0DC; Sat, 30 Aug 2008 22:38:39 +0000 (UTC) Date: Sat, 30 Aug 2008 22:38:39 +0000 From: list-namedroppers@pwns.ms To: namedroppers@ops.ietf.org Subject: Re: dnscurve -- new or did I just miss this? Message-ID: <20080830223839.GA15555@pwns.ms> References: <48B9AE7C.4070703@everydns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Created On:10-Aug-2008 06:32:59 UTC > Last Updated On:27-Aug-2008 13:17:39 UTC > Registrant Name:Daniel J. Bernstein > > > http://dnscurve.org/ > > I have read those pages and as I understand them djb proposes > encrypting DNS communication (encapsulating it into TXT query > and response) when it sees some special string in domain > name ('uz5'). > > But since DNSCurve doesn't have trust anchors it does not protect > you before you get this new special name (which is distributed > by PODS). I can even spoof DNSCurve nameserver and my *evil* > DNS server can talk DNSCurve protocol. Basicaly it's like > self-signed certificates. > > Or am I missing something? >From my reading of it, the key is distributed in the domain name; one would need some secure (OOB) method to authenticate the domain names. One could have a trust anchor equivelant by only using pre-configured nameservers for certain domains, perhaps allowing parent nameservers to override it if they were quried using DNSCurve. If this were enabled at the root (I'm sure that would not cause any load issues), then no trust anchor would be needed for verification -- the root server names themselves could be used. -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 16:12:25 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D4B3A6ABF; Sat, 30 Aug 2008 16:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 ttezZBnLawZu; Sat, 30 Aug 2008 16:12:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 859A63A6869; Sat, 30 Aug 2008 16:12:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZZUn-000F5u-Uc for namedroppers-data@psg.com; Sat, 30 Aug 2008 23:04:41 +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 ) id 1KZZUk-000F5Y-66 for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 23:04:40 +0000 Received: from [192.168.163.113] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7UN4RYH007865; Sat, 30 Aug 2008 19:04:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200808210428.m7L4S9uL032499@drugs.dv.isc.org> References: <200808210428.m7L4S9uL032499@drugs.dv.isc.org> Date: Sun, 31 Aug 2008 07:25:23 +1000 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Zone Immortality Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:28 +1000 8/21/08, Mark Andrews wrote: > * Outlaw loops. > * Don't reset the expire counter on refresh from peers only > on transfer from peers. I'd reset the expiry only after the successful transfer of an zone with an incremented serial number. That would take care of loops. > * Use DNSSEC to make data go stale. Don't do that. Don't overload the meaning of the RRSIG temporal fields. They are meant to protect the cryptography, not convey any meaning of the data. At 1:00 -0400 8/21/08, Brian Dickson wrote: >If a zone is transfered *from* a slave, the values for the TTLs should >be modified downwards by the local EXPIRE timer. Only transfers from a >zone master should have the original TTL values from the SOA used for timers. The problem is distinguishing between a master and a slave. At 14:52 +0900 8/21/08, Masataka Ohta wrote: >A hidden assumption of 1034 is that such convergence will occur >within a period much shorter than the expiration period. Many assumptions of that era no longer are valid. ;) >If not, you have an administrative problem a lot more serious >than a small variation of expiraiton period. Not necessarily. There are applications of DNS on disjointed networks such as very remote places (which hardly exist anymore), sea-going vessels, inter-planetary applications. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 16:36:36 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4201F3A6ABF; Sat, 30 Aug 2008 16:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.977 X-Spam-Level: **** X-Spam-Status: No, score=4.977 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_ASCII0=1.5, 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 8VncJdvc0BsW; Sat, 30 Aug 2008 16:36:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0A203A68A1; Sat, 30 Aug 2008 16:36:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZZra-000HfI-Rh for namedroppers-data@psg.com; Sat, 30 Aug 2008 23:28:14 +0000 Received: from [74.125.78.27] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZZrV-000Hcp-Sy for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 23:28:12 +0000 Received: by ey-out-2122.google.com with SMTP id 25so571169eya.65 for ; Sat, 30 Aug 2008 16:28:06 -0700 (PDT) Received: by 10.210.78.16 with SMTP id a16mr3937620ebb.173.1220138885716; Sat, 30 Aug 2008 16:28:05 -0700 (PDT) Received: by 10.210.63.13 with HTTP; Sat, 30 Aug 2008 16:28:05 -0700 (PDT) Message-ID: Date: Sun, 31 Aug 2008 01:28:05 +0200 From: "=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=" To: list-namedroppers@pwns.ms Subject: Re: dnscurve -- new or did I just miss this? Cc: namedroppers@ops.ietf.org In-Reply-To: <20080830223839.GA15555@pwns.ms> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <48B9AE7C.4070703@everydns.net> <20080830223839.GA15555@pwns.ms> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: MjAwOC84LzMxICA8bGlzdC1uYW1lZHJvcHBlcnNAcHducy5tcz46Cj4+IENyZWF0ZWQgT246MTAt QXVnLTIwMDggMDY6MzI6NTkgVVRDCj4+IExhc3QgVXBkYXRlZCBPbjoyNy1BdWctMjAwOCAxMzox NzozOSBVVEMKPj4gUmVnaXN0cmFudCBOYW1lOkRhbmllbCBKLiBCZXJuc3RlaW4KPj4KPj4gPiBo dHRwOi8vZG5zY3VydmUub3JnLwo+Pgo+PiBJIGhhdmUgcmVhZCB0aG9zZSBwYWdlcyBhbmQgYXMg SSB1bmRlcnN0YW5kIHRoZW0gZGpiIHByb3Bvc2VzCj4+IGVuY3J5cHRpbmcgRE5TIGNvbW11bmlj YXRpb24gKGVuY2Fwc3VsYXRpbmcgaXQgaW50byBUWFQgcXVlcnkKPj4gYW5kIHJlc3BvbnNlKSB3 aGVuIGl0IHNlZXMgc29tZSBzcGVjaWFsIHN0cmluZyBpbiBkb21haW4KPj4gbmFtZSAoJ3V6NScp Lgo+Pgo+PiBCdXQgc2luY2UgRE5TQ3VydmUgZG9lc24ndCBoYXZlIHRydXN0IGFuY2hvcnMgaXQg ZG9lcyBub3QgcHJvdGVjdAo+PiB5b3UgYmVmb3JlIHlvdSBnZXQgdGhpcyBuZXcgc3BlY2lhbCBu YW1lICh3aGljaCBpcyBkaXN0cmlidXRlZAo+PiBieSBQT0RTKS4gIEkgY2FuIGV2ZW4gc3Bvb2Yg RE5TQ3VydmUgbmFtZXNlcnZlciBhbmQgbXkgKmV2aWwqCj4+IEROUyBzZXJ2ZXIgY2FuIHRhbGsg RE5TQ3VydmUgcHJvdG9jb2wuICBCYXNpY2FseSBpdCdzIGxpa2UKPj4gc2VsZi1zaWduZWQgY2Vy dGlmaWNhdGVzLgo+Pgo+PiBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPwo+Cj4gRnJvbSBteSBy ZWFkaW5nIG9mIGl0LCB0aGUga2V5IGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBkb21haW4gbmFtZTsg b25lIHdvdWxkIG5lZWQgc29tZSBzZWN1cmUgKE9PQikgbWV0aG9kIHRvIGF1dGhlbnRpY2F0ZSB0 aGUgZG9tYWluIG5hbWVzLiBPbmUgY291bGQgaGF2ZSBhIHRydXN0IGFuY2hvciBlcXVpdmVsYW50 IGJ5IG9ubHkgdXNpbmcgcHJlLWNvbmZpZ3VyZWQgbmFtZXNlcnZlcnMgZm9yIGNlcnRhaW4gZG9t YWlucywgcGVyaGFwcyBhbGxvd2luZyBwYXJlbnQgbmFtZXNlcnZlcnMgdG8gb3ZlcnJpZGUgaXQg aWYgdGhleSB3ZXJlIHF1cmllZCB1c2luZyBETlNDdXJ2ZS4gSWYgdGhpcyB3ZXJlIGVuYWJsZWQg YXQgdGhlIHJvb3QgKDxzYXJjYXNtPkknbSBzdXJlIHRoYXQgd291bGQgbm90IGNhdXNlIGFueSBs b2FkIGlzc3Vlczwvc2FyY2FzbT4pLCB0aGVuIG5vIHRydXN0IGFuY2hvciB3b3VsZCBiZSBuZWVk ZWQgZm9yIHZlcmlmaWNhdGlvbiAtLSB0aGUgcm9vdCBzZXJ2ZXIgbmFtZXMgdGhlbXNlbHZlcyBj b3VsZCBiZSB1c2VkLgoKU3VyZSwgdGhlcmUgYXJlIHdheXMgaG93IHRvIHNvbHZlIGl0LCBidXQg cXVvdGluZyB0aGUgcGFnZToKPiBObyBleHRyYSBjYWNoZSBjb25maWd1cmF0aW9uIGlzIHJlcXVp cmVkOyB0aGUgRE5TIGNhY2hlIHdpbGwgZmlndXJlIG91dCBmb3IgaXRzZWxmIHdoZW4gYSBzZXJ2 ZXIgc3VwcG9ydHMgRE5TQ3VydmUuIE5vIGV4dHJhIGZpcmV3YWxsIGNvbmZpZ3VyYXRpb24gaXMg cmVxdWlyZWQgKGlmIHlvdSBoYXZlIHlvdXIgY2FjaGUgYmVoaW5kIGEgZmlyZXdhbGwpOyBETlND dXJ2ZSByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGFyZSwgZnJvbSBhIGZpcmV3YWxsJ3MgcGVyc3Bl Y3RpdmUsIG5vcm1hbCBETlMgcGFja2V0cy4gTmV0d29yayBiYW5kd2lkdGggcmVtYWlucyBlc3Nl bnRpYWxseSB1bmNoYW5nZWQ7IEROU0N1cnZlIHB1dHMgc29tZSBleHRyYSBpbmZvcm1hdGlvbiBp bnRvIHBhY2tldHMgdG8gRE5TQ3VydmUgc2VydmVycyBidXQgZG9lcyBub3QgdXNlIGV4dHJhIHBh Y2tldHMuCgpBbnl3YXkgLSBsZXQncyBzdXBwb3NlIHRoaXMgaXMgZW5hYmxlZCBpbiByb290IChh bmQgd2Ugc2VlZGVkIG91ciByZG5zCndpdGggcm9vdCdzIEROU0N1cnZlIG5hbWVzZXJ2ZXJzKSAt IHdvdyBub3cgd2UgaGF2ZSBlbmNhcHN1bGF0ZWQgRVZFUlkKRE5TIHBhY2tldCBpbnRvIGVuY3J5 cHRlZCBUWFQgcGFja2V0cy4gIEl0IHJlbWluZHMgbWUgSVAgb3ZlciBETlMKcHJvdG9jb2wuCgpC dXQgaXQgaGFzIHNvbWUgaW50ZXJlc3RpbmcgaWRlYXMuICBJIGFtIG5vdCBhIGNyeXB0byBndXks IHNvIG1heWJlIEkKYW0gd3JvbmcsIGJ1dCBjb3VsZCB3ZSB1c2UgdGhhdCBlbGxpcHRpYyBjdXJ2 ZSBjcnlwdG9ncmFwaHkgaW4gcGxhY2UKb2YgUlNBPwoKT25kcmVqLgotLSAKIE9uZMWZZWogU3Vy w70KIHRlY2huaWNrw70gxZllZGl0ZWwvQ2hpZWYgVGVjaG5pY2FsIE9mZmljZXIKIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBDWi5OSUMsIHoucy5wLm8uIC0tIC5j eiBkb21haW4gcmVnaXN0cnkKIEFtZXJpY2vDoSAyMywxMjAgMDAgUHJhaGEgMixDemVjaCBSZXB1 YmxpYwogbWFpbHRvOm9uZHJlai5zdXJ5QG5pYy5jeiBodHRwOi8vbmljLmN6Lwogc2lwOm9uZHJl ai5zdXJ5QG5pYy5jeiB0ZWw6KzQyMC4yMjI3NDUxMTAKIG1vYjorNDIwLjczOTAxMzY5OSBmYXg6 KzQyMC4yMjI3NDUxMTIKIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cg== -- 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: From owner-namedroppers@ops.ietf.org Sat Aug 30 16:54:13 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02CB3A6B1C; Sat, 30 Aug 2008 16:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Gdyt2mvn-uPs; Sat, 30 Aug 2008 16:54:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 983BE3A6864; Sat, 30 Aug 2008 16:54:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZa68-000JAO-9y for namedroppers-data@psg.com; Sat, 30 Aug 2008 23:43:16 +0000 Received: from [2001:ba8:1f1:f045::2] (helo=weevil.pwns.ms) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZa63-000J9C-Vc for namedroppers@ops.ietf.org; Sat, 30 Aug 2008 23:43:14 +0000 Received: by weevil.pwns.ms (Postfix, from userid 1000) id 170A1C0DC; Sat, 30 Aug 2008 23:43:10 +0000 (UTC) Date: Sat, 30 Aug 2008 23:43:10 +0000 From: list-namedroppers@pwns.ms To: namedroppers@ops.ietf.org Subject: Re: dnscurve -- new or did I just miss this? Message-ID: <20080830234310.GA17717@pwns.ms> References: <48B9AE7C.4070703@everydns.net> <20080830223839.GA15555@pwns.ms> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > But it has some interesting ideas. I am not a crypto guy, so maybe I > am wrong, but could we use that elliptic curve cryptography in place > of RSA? I think so. RFC4034 defines algorithim number 4 for elliptic curves, but I don't see any definition for it's usage. Implementors and cryptographers tend to be unfamiliar with elliptic curves, which is mildly scary. Elliptic curves are well supported by common crypto libraries, but still much less so than RSA - I doubt this would be a problem, though. RSA works, so there is little motivation to moving to elliptic curves. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 00:47:22 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23B93A6881; Sun, 31 Aug 2008 00:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.702 X-Spam-Level: **** X-Spam-Status: No, score=4.702 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, 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 9J0gT0dWd1-6; Sun, 31 Aug 2008 00:47:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33CC53A6891; Sun, 31 Aug 2008 00:47:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZhTm-000DmP-BN for namedroppers-data@psg.com; Sun, 31 Aug 2008 07:36:10 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZhTh-000Dlf-1J for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 07:36:07 +0000 Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1KZhTd-0003be-9R for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 08:36:01 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KZhTc-0002bV-Ac for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 08:36:00 +0100 Message-ID: <8ADBD9246E0A40F28E960FF6F01811FB@localhost> From: "George Barwood" To: Subject: Repeat queries to non-deterministic servers Date: Sun, 31 Aug 2008 08:35:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C90B44.975547C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C90B44.975547C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When sending a repeat request ( to increase entropy ), some name servers = give different replies on each request. Has anyone considered the best way to handle this?=20 My current heuristic is to count Total =3D Total number of distinct records seen. ConfTotal =3D Total number of distinct records confirmed ( total entropy = above threshold of 50 bits ). and to stop when Total > 0 and Total =3D ConfTotal // the normal case for deterministic = servers or ConfTotal > 30 or in any case after 20 queries. An example is found when resolving the host E120.G.AKAMAIEDGE.NET Using the heuristic above, this stops with Total=3D68, ConfTotal=3D31 = after 9 queries ( typically - results vary ). So this seems to work well enough in practice, however it seems somewhat = arbitrary, and thus not entirely satisfactory, leaving open potential = inter-operability problems. The standards aspect is that implementors of authoritative DNS servers = could be warned that non-deterministic responses may cause some = resolvers to make multiple repeat requests, leading to either loss of = performance and increased traffic, or reduced security, if resolvers = decide to accept data below a safe entropy level. It's not entirely clear to me what such servers are trying to achieve, = but I suspect it could be achieved by changing the served data on a = slightly less frequent basis ( for example once a minute rather than on = every request ). An alternative would be to use long names, which allows = extra entropy to be encoded via the 0x20 channel, eliminating the need = for repeat queries, or to implement other proposals for increasing = entropy ( e.g. AL record ). I don't believe such servers are common, so "fixing" them may be = possible. It could be that akamai is the only significant example - = although I certainly don't know this, Has anyone researched this? It is = impossible to update ALL authoritative servers, however updating most of = the significant non-deterministic ones may be feasible in a reasonable = time frame, and that is should be good enough. ------=_NextPart_000_0086_01C90B44.975547C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When sending a repeat request ( to = increase entropy=20 ), some name servers give different replies on each = request.
 
Has anyone considered the best way to = handle this?=20
 
My current heuristic is to = count
 
Total =3D Total number of distinct = records=20 seen.
ConfTotal =3D Total number of distinct = records=20 confirmed ( total entropy above threshold of 50 bits ).
 
and to stop when
 
Total > 0 and Total =3D = ConfTotal // the=20 normal case for deterministic servers
or ConfTotal >=20 30
or in any case after 20 = queries.
 
An example is found when resolving the = host=20 E120.G.AKAMAIEDGE.NET
 
Using the heuristic above, this stops = with=20 Total=3D68, ConfTotal=3D31 after 9 queries ( typically - results vary=20 ).
 
So this seems to work well enough in = practice,=20 however it seems somewhat arbitrary, and thus not entirely satisfactory, = leaving=20 open potential inter-operability problems.
 
The standards aspect is = that implementors of=20 authoritative DNS servers could be warned that non-deterministic = responses may=20 cause some resolvers to make multiple repeat requests, leading to = either=20 loss of performance and increased traffic, or reduced security, if=20 resolvers decide to accept data below a safe entropy = level.
 
It's not entirely clear to me what such = servers are=20 trying to achieve, but I suspect it could be achieved by changing the = served=20 data on a slightly less frequent basis ( for example once a minute = rather than=20 on every request ). An alternative = would=20 be to use long names, which allows extra entropy to be encoded via = the 0x20=20 channel, eliminating the need for repeat queries, or to implement other=20 proposals for increasing entropy ( e.g. AL record ).
 
I don't believe such servers are = common, so=20 "fixing" them may be possible. It could be that akamai is the only=20 significant example - although I certainly don't know this, Has anyone=20 researched this? It is impossible = to update=20 ALL authoritative servers, however updating most of the significant=20 non-deterministic ones may be feasible in a reasonable time frame, and = that=20 is should be good enough.
 
------=_NextPart_000_0086_01C90B44.975547C0-- -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 05:50:28 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4551D3A6A91; Sun, 31 Aug 2008 05:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Qq7OOlYng3HL; Sun, 31 Aug 2008 05:50:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49D7B3A6403; Sun, 31 Aug 2008 05:50:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZmCt-000LND-5Y for namedroppers-data@psg.com; Sun, 31 Aug 2008 12:39:03 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZmCo-000LMc-04 for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 12:39:00 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m7VCcogf003897; Sun, 31 Aug 2008 14:38:50 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200808311238.m7VCcogf003897@givry.fdupont.fr> From: Francis Dupont To: list-namedroppers@pwns.ms cc: namedroppers@ops.ietf.org Subject: Re: dnscurve -- new or did I just miss this? In-reply-to: Your message of Sat, 30 Aug 2008 23:43:10 -0000. <20080830234310.GA17717@pwns.ms> Date: Sun, 31 Aug 2008 14:38:50 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: so there is little motivation to moving to elliptic curves. => I disagree: - ECs are faster than RSA and give smaller keys and signatures - ECs are based on a different mechanism than RSA, it is important to provide a choice between two basic mechanisms in case one of them is discovered far too weak (note this applies too to a EC only solution :-) So IMHO it should be good to investigate about an ECDSA DNSSEC option. Regards Francis.Dupont@fdupont.fr PS: cryptographers I know promote the use of ECs... -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 06:02:48 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA6A3A689E; Sun, 31 Aug 2008 06:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 Boomt7PrFQoJ; Sun, 31 Aug 2008 06:02:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E2783A6B36; Sun, 31 Aug 2008 06:02:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZmO4-000Mab-6Q for namedroppers-data@psg.com; Sun, 31 Aug 2008 12:50:36 +0000 Received: from [143.215.128.120] (helo=fritz.cc.gt.atl.ga.us) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZmNz-000MZf-Uu for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 12:50:34 +0000 Received: from fritz.cc.gt.atl.ga.us (localhost.cc.gt.atl.ga.us [127.0.0.1]) by fritz.cc.gt.atl.ga.us (Postfix) with ESMTP id 68E0B45020; Sun, 31 Aug 2008 08:54:14 -0400 (EDT) Received: (from dagon@localhost) by fritz.cc.gt.atl.ga.us (8.13.8/8.13.8/Submit) id m7VCsBXW067467; Sun, 31 Aug 2008 08:54:11 -0400 (EDT) (envelope-from dagon) Date: Sun, 31 Aug 2008 08:54:11 -0400 From: David Dagon To: Florian Weimer Cc: Paul Vixie , Stephane Bortzmeyer , Jim Reid , Nicholas Weaver , Namedroppers Subject: Re: New Version Notification for draft-reid-dnsext-aleatoric-00 Message-ID: <20080831125411.GB66937@fritz.cc.gt.atl.ga.us> References: <20080828152751.GA21778@nic.fr> <43486DCC-FA35-447B-BF1C-914A20429562@rfc1035.com> <04928188-0DE7-4259-81DB-94469B7CE39F@rfc1035.com> <26223.1219958219@nsa.vix.com> <20080829074209.GA15508@nic.fr> <88896.1220025059@nsa.vix.com> <82hc93py7e.fsf@mid.bfk.de> <617.1220029414@nsa.vix.com> <827i9zpukh.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <827i9zpukh.fsf@mid.bfk.de> User-Agent: Mutt/1.5.15 (2007-04-06) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Aug 29, 2008 at 08:03:42PM +0200, Florian Weimer wrote: > > > i hope this clarifies the BCP 79 status of dns-0x20. > > Yes, thank you very much. Sorry, I overlooked your previous inquiry. I have no intention of patenting or copyrighting DNS-0x20. I have taken numerous steps to resist such efforts. I have written (and will shortly present) a paper on DNS-0x20, which destroys any hopes of international or US-based intellectual property rights. And public talks I give on the topic all note that DNS-0x20 is patent-free. Thus, none of the organizations I work for could make a colorable claim otherwise. I believe I've made it impossible for one to claim patents of copyrights on DNS-0x20. -- David Dagon /"\ "When cryptography dagon@cc.gatech.edu \ / ASCII RIBBON CAMPAIGN is outlawed, bayl Ph.D. Student X AGAINST HTML MAIL bhgynjf jvyy unir Georgia Inst. of Tech. / \ cevinpl." -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 06:47:40 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCDC3A6A91; Sun, 31 Aug 2008 06:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Eb7sEMJeER4N; Sun, 31 Aug 2008 06:47:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9EB3E3A68D2; Sun, 31 Aug 2008 06:47:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZn6p-0002bI-KL for namedroppers-data@psg.com; Sun, 31 Aug 2008 13:36:51 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZn6l-0002aZ-SD for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 13:36:49 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m7VDaj8S004314 for ; Sun, 31 Aug 2008 15:36:45 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200808311336.m7VDaj8S004314@givry.fdupont.fr> From: Francis Dupont To: namedroppers@ops.ietf.org Subject: about EDNS0 PING Date: Sun, 31 Aug 2008 15:36:45 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: draft-hubert-ulevitch-edns-ping-00.txt should mention the PING EDNS0 option is a first class cover channel in its "Security Considerations". Francis.Dupont@fdupont.fr PS: I don't say it is a bad thing... -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 08:14:08 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649573A6B58; Sun, 31 Aug 2008 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.912 X-Spam-Level: X-Spam-Status: No, score=-3.912 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 6Usoknqafk+o; Sun, 31 Aug 2008 08:14:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F8D23A6B4F; Sun, 31 Aug 2008 08:14:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZoUz-000DE6-Gu for namedroppers-data@psg.com; Sun, 31 Aug 2008 15:05:53 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZoUv-000DDV-GS for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 15:05:51 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7VF592k028507; Sun, 31 Aug 2008 08:05:41 -0700 (PDT) Cc: Nicholas Weaver , list-namedroppers@pwns.ms, namedroppers@ops.ietf.org Message-Id: <29378EC7-6FD5-45C5-978B-07C8DCD9C31E@icsi.berkeley.edu> From: Nicholas Weaver To: Francis Dupont In-Reply-To: <200808311238.m7VCcogf003897@givry.fdupont.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: dnscurve -- new or did I just miss this? Date: Sun, 31 Aug 2008 08:05:19 -0700 References: <200808311238.m7VCcogf003897@givry.fdupont.fr> X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 31, 2008, at 5:38 AM, Francis Dupont wrote: > In your previous mail you wrote: > > so there is little motivation to moving to elliptic curves. > > => I disagree: > - ECs are faster than RSA and give smaller keys and signatures This is true. Especially if you want to maintain for, as much as possible, the DNS maximum message size over UDP. > - ECs are based on a different mechanism than RSA, it is important > to provide a choice between two basic mechanisms in case one of > them is discovered far too weak (note this applies too to a EC > only solution :-) This I disagree with. Although the elliptic curve discrete log problem (and the discrete log problem in general) are separate from the factoring problem, every breakthrough in one almost invariably produces a breakthrough in the other. Of special worry is quantum computing, which affects ECC just the same as RSA, and is actually a footnote in the original quantum computing beats factoring paper. Additionaly, there was a big discussion of this very problem at the AES candidate meeting in the "choose 1 algorithm or 2" discussion. In general, the crptographer's consensus is that only a single algorithm should be chosen, as actually specifying two opens up more vulnerabilities than a fallback provision provides. Frankly speaking, the markeplace reason for a competitor to DNSSEC has to arrise from ease-of-use concerns, not choice of crypto. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 08:15:05 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BB73A6B24; Sun, 31 Aug 2008 08:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, 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 YGGkrpSdPV-2; Sun, 31 Aug 2008 08:15:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CED663A69B2; Sun, 31 Aug 2008 08:15:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZoUv-000DDZ-MI for namedroppers-data@psg.com; Sun, 31 Aug 2008 15:05:49 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZoUr-000DCy-4G for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 15:05:47 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m7VF592j028507; Sun, 31 Aug 2008 08:05:40 -0700 (PDT) From: Nicholas Weaver To: George Barwood In-Reply-To: <8ADBD9246E0A40F28E960FF6F01811FB@localhost> Subject: Re: Repeat queries to non-deterministic servers X-Priority: 3 References: <8ADBD9246E0A40F28E960FF6F01811FB@localhost> Message-Id: <96E7F32A-84A6-4481-A6D2-0CB4999C26F5@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Sun, 31 Aug 2008 08:05:13 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.928.1) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 31, 2008, at 12:35 AM, George Barwood wrote: > When sending a repeat request ( to increase entropy ), some name > servers give different replies on each request. > > Has anyone considered the best way to handle this? This is why I advocate treating cache and transaction separately. EG, assume you are behind a NAT, so you only have 0x20, and you're looking for a typical 8 character name. Thus you only have 24 bits of entropy, which is uncomfortably low. If you send two requests and, if they disagree, don't cache the result but do return (a random) result with a TTL of 1 second, the name will have resolved with 23b of entropy, but the cache will be protected with 47b of entropy. This is because blind transaction attacks are really limited: you need to trick the victim into issuing a request and acting on it immediately at the application layer, which is a much smaller window than a cache attack. Thus the consequence: As long as the authority always sends disagreeing results, each result is individually protected by a 23b race. But such races are transactional attacks, which are far less useful than cache attacks. As soon as it returns an agreeing results, it gets cached with 47b of entropy, which means its infeasible for a blind cache attack. > It's not entirely clear to me what such servers are trying to > achieve, but I suspect it could be achieved by changing the served > data on a slightly less frequent basis ( for example once a minute > rather than on every request ). An alternative would be to use long > names, which allows extra entropy to be encoded via the 0x20 > channel, eliminating the need for repeat queries, or to implement > other proposals for increasing entropy ( e.g. AL record ). Since a lot of this is for load-balancing purposes, expect that this volatility will remain. You won't get them to change, but I argue it is SAFE to accept them for transactions as opposed to caching. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 08:43:34 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81303A6784; Sun, 31 Aug 2008 08:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 e+8U9dJL1Tdx; Sun, 31 Aug 2008 08:43:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A62B83A6A01; Sun, 31 Aug 2008 08:43:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZowJ-000GrY-UM for namedroppers-data@psg.com; Sun, 31 Aug 2008 15:34:07 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZowA-000Gpo-AZ for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 15:34:00 +0000 Received: from euphoria.home (pool-71-179-253-225.bltmmd.fios.verizon.net [71.179.253.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id D224F136797; Sun, 31 Aug 2008 11:33:52 -0400 (EDT) Cc: namedroppers@ops.ietf.org Message-Id: <215F9FF8-1BCB-472E-B91F-263510C202EF@verisign.com> From: "Blacka, David" To: list-namedroppers@pwns.ms In-Reply-To: <20080830234310.GA17717@pwns.ms> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: dnscurve -- new or did I just miss this? Date: Sun, 31 Aug 2008 11:33:52 -0400 References: <48B9AE7C.4070703@everydns.net> <20080830223839.GA15555@pwns.ms> <20080830234310.GA17717@pwns.ms> X-Mailer: Apple Mail (2.926) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Aug 30, 2008, at 7:43 PM, list-namedroppers@pwns.ms wrote: >> But it has some interesting ideas. I am not a crypto guy, so maybe I >> am wrong, but could we use that elliptic curve cryptography in place >> of RSA? > > I think so. RFC4034 defines algorithim number 4 for elliptic curves, > but I don't see any definition for it's usage. There isn't one that made it through last call, but there is a proposed definition. See: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key/ There was the thought that this proposal was too wide open and thus too complex. However, no one has (yet) published a DNSKEY proposal for a simpler version, or pushed harder for the existing version to move forward. -- David Blacka Sr. Engineer Platform Product Development -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 09:13:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201F93A6B65; Sun, 31 Aug 2008 09:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] 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 43ELIn6jox7Z; Sun, 31 Aug 2008 09:13:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 193753A6B62; Sun, 31 Aug 2008 09:13:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZpQH-000L3q-Az for namedroppers-data@psg.com; Sun, 31 Aug 2008 16:05:05 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZpQ4-000L1Q-Fj for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 16:04:55 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 28108A6659; Sun, 31 Aug 2008 16:04:47 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Nicholas Weaver cc: George Barwood , namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 31 Aug 2008 08:05:13 MST." <96E7F32A-84A6-4481-A6D2-0CB4999C26F5@icsi.berkeley.edu> References: <8ADBD9246E0A40F28E960FF6F01811FB@localhost> <96E7F32A-84A6-4481-A6D2-0CB4999C26F5@icsi.berkeley.edu> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 31 Aug 2008 16:04:47 +0000 Message-ID: <97567.1220198687@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 28108A6659.416F4 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: Repeat queries to non-deterministic servers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > ... > If you send two requests and, if they disagree, don't cache the result > but do return (a random) result with a TTL of 1 second, the name will > have resolved with 23b of entropy, but the cache will be protected with > 47b of entropy. > ... as also noted privately, a TTL of 0 on the RDNS response is useful in this case since if the response goes to a forwarder rather than to a stub we would not want it reused even for the remainder of that 1 second period. > ... > Thus the consequence: As long as the authority always sends disagreeing > results, each result is individually protected by a 23b race. But such > races are transactional attacks, which are far less useful than cache > attacks. > ... i note with amusement that servers who send disagreeing results usually have very short TTLs (five seconds) and would probably enjoy it if we shortened them still further. these are mostly load balancers who do not benefit from caching in the ramparts. they don't use TTL 0 because it's considered rude when an ADNS does that. but if an RDNS does it, hey, who are they to argue? > As soon as it returns an agreeing results, it gets cached with 47b of > entropy, which means its infeasible for a blind cache attack. this is a very neat solution to the problem i couldn't find a solution for in my "minimum entropy" proposal a month or so ago. > ... I argue it is SAFE to accept them for transactions as opposed to > caching. safety is in the eye of the beholder. if someone is behind a NAT derandomizer and they have 24 bits of entropy then they have a lot less than ten hours between successful keyhole attacks and they ought to worry. in that sense, your proposal makes them safer, and that's worth noting. (of course, stopping the derandomization of source-port would also make them safer.) -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 10:02:12 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C39D3A6B5E; Sun, 31 Aug 2008 10:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.701 X-Spam-Level: **** X-Spam-Status: No, score=4.701 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, 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 1uPC797sgif3; Sun, 31 Aug 2008 10:02:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CA8328C179; Sun, 31 Aug 2008 10:01:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZqAM-0000uW-BA for namedroppers-data@psg.com; Sun, 31 Aug 2008 16:52:42 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZqAH-0000u5-NU for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 16:52:40 +0000 Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1KZqAE-0006ME-Oa; Sun, 31 Aug 2008 17:52:34 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1KZqAE-0006cH-5H; Sun, 31 Aug 2008 17:52:34 +0100 Message-ID: <6EC7CB706EAE42D0A0F7CE1E982D39A6@localhost> From: "George Barwood" To: "Nicholas Weaver" Cc: References: <8ADBD9246E0A40F28E960FF6F01811FB@localhost> <96E7F32A-84A6-4481-A6D2-0CB4999C26F5@icsi.berkeley.edu> Subject: Re: Repeat queries to non-deterministic servers Date: Sun, 31 Aug 2008 17:52:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Thus the consequence: As long as the authority always sends disagreeing > results, each result is individually protected by a 23b race. But such > races are transactional attacks, which are far less useful than cache > attacks. If I can have it, I prefer to have 50 bits everywhere, and a simple design where everything gets cached. > Since a lot of this is for load-balancing purposes, expect that this > volatility will remain. For load balancing, it's not necessary to have complete non-determinism ( albeit this may be the easy option ). > You won't get them to change.... I probably wrongly gave the impression that I NEED them to change. In this case the records involved are NS records with a relatively long TTL ( 30 minutes ), and once established in the cache, can be refreshed with a single query. It all works absolutely fine in practice, and the extra traffic is completely insignificant, so the inefficiency is very theoretical. The A records (which are deterministic) have a TTL of 20 seconds, so these can be expected to dominate the load. If I understand your proposal correctly, each time one of these 20 second TTL A records expire, 2 requests would be needed instead of 1, as the non-deterministic NS record will not have been cached. That would produce a far higher extra load. Another consideration : any genuine operational problems (with the convergence algorithm given) will I think only occur in the context of huge server farms. So if there are problems, I think they will come to light very rapidly. There cannot be too many organisations with networks of hundres/thousands of nameservers, so if Akamai are the largest, I think any problem is likely to be theoretical. Must do some more surfing :) -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 13:33:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DE73A6B59; Sun, 31 Aug 2008 13:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 VbeUUPF-0PfU; Sun, 31 Aug 2008 13:33:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90C0F3A6998; Sun, 31 Aug 2008 13:33:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZtTl-000Net-U3 for namedroppers-data@psg.com; Sun, 31 Aug 2008 20:24:57 +0000 Received: from [71.241.230.133] (helo=secure.antibozo.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZtTe-000Ne2-Df for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 20:24:56 +0000 Received: from [192.168.1.254] (calypso [71.178.203.249]) by secure.antibozo.net (Postfix) with ESMTP id AAD15E2B52; Sun, 31 Aug 2008 20:24:48 +0000 (UTC) Message-ID: <48BAFE0F.6090505@antibozo.net> Date: Sun, 31 Aug 2008 20:24:47 +0000 From: Jefferson Ogata User-Agent: Mozilla/4.0 (compatible;MSIE 5.5; Windows 98) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Outstanding queries vs. source port randomization entropy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [I posted a variation on this message as a comment on Dan Kaminsky's blog earlier today, but I'm skeptical he'll have the time to respond, so I'm throwing it out to a wider audience.] So here's a question. With source port randomization, what prevents the following attack? Attacker sets up a nameserver for example.com that receives queries but sends no responses, with an appropriate delegation. Attacker then asks the victim nameserver ~2^16 distinct queries under example.com in a short time frame. This effectively consumes the entire source port range with outstanding queries. The example.com nameserver observes the source port for each inbound recursive query from the victim nameserver; the one remaining source port that was not observed is the only port left to the victim nameserver for its next query. Attacker then asks victim nameserver for the domain to be poisoned, and forges the poison response targeting the remaining port. I'm presenting an idealized attack here for the purpose of illustration. The principle is to deplete the entropy included in source port randomization by consuming the majority of available ports with outstanding queries. The attack would only be effective against a nameserver that allows close to 2^16 outstanding queries, i.e. high open file descriptor limit, FD_SETSIZE appropriately redefined, etc.; a nameserver that could have only 1024 outstanding requests, for example, would be DoSed before it would lose significant entropy. The outstanding requests could be distributed among many domains and distinct nameservers if necessary, as long as the nameservers coordinate. The attack could be partly mitigated on nameservers that allow ~2^16 outstanding requests if the victim nameserver can reuse randomly chosen, already open sockets for multiple successive requests once ~2^16 ports are bound. The efficacy of this attack depends on the precise algorithm by which the victim uses new ports, and what limits are enforced. I have to wonder how this has been addressed in the various resolvers that implement source port randomization. Where has this scenario been discussed before? It's too obvious not to have been considered earlier, but I've done some Googling and skimmed some list archives and haven't come up with anything. -- Jefferson Ogata : Internetworker, Antibozo -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 13:56:51 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAECD3A6914; Sun, 31 Aug 2008 13:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 X65ZmbGT1fa6; Sun, 31 Aug 2008 13:56:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AAAB3A6878; Sun, 31 Aug 2008 13:56:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZtqP-000PyJ-Vb for namedroppers-data@psg.com; Sun, 31 Aug 2008 20:48:21 +0000 Received: from [217.70.190.232] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZtqK-000Px2-9J for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 20:48:20 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 6492F94812; Sun, 31 Aug 2008 22:48:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 8153D1907DD; Sun, 31 Aug 2008 22:44:29 +0200 (CEST) Date: Sun, 31 Aug 2008 22:44:29 +0200 From: Stephane Bortzmeyer To: "Blacka, David" Cc: list-namedroppers@pwns.ms, namedroppers@ops.ietf.org Subject: Re: dnscurve -- new or did I just miss this? Message-ID: <20080831204429.GA12465@sources.org> References: <48B9AE7C.4070703@everydns.net> <20080830223839.GA15555@pwns.ms> <20080830234310.GA17717@pwns.ms> <215F9FF8-1BCB-472E-B91F-263510C202EF@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <215F9FF8-1BCB-472E-B91F-263510C202EF@verisign.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux lenny/sid User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Aug 31, 2008 at 11:33:52AM -0400, Blacka, David wrote a message of 27 lines which said: > There isn't one that made it through last call, but there is a proposed > definition. See: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key/ Warning, we are deriving into a general discussion on EC cryptography and this thread, IMHO, should stay focused on DNScurve. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 14:21:07 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BE93A683D; Sun, 31 Aug 2008 14:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, 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 h1WfOXwG4kZW; Sun, 31 Aug 2008 14:21:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 750E23A6A06; Sun, 31 Aug 2008 14:21:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZuCg-0002to-6e for namedroppers-data@psg.com; Sun, 31 Aug 2008 21:11:22 +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 ) id 1KZuCa-0002s8-BX for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 21:11:20 +0000 Received: from outpost.ds9a.nl ([85.17.220.215] ident=postfix) by adsl-xs4all.ds9a.nl with esmtp (Exim 4.63) (envelope-from ) id 1KZuCX-0005u2-EL for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 23:11:13 +0200 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A16354B452; Sun, 31 Aug 2008 23:11:25 +0200 (CEST) Date: Sun, 31 Aug 2008 23:11:25 +0200 From: bert hubert To: Stephane Bortzmeyer Cc: "Blacka, David" , list-namedroppers@pwns.ms, namedroppers@ops.ietf.org Subject: Re: dnscurve -- new or did I just miss this? Message-ID: <20080831211125.GC1000@outpost.ds9a.nl> References: <48B9AE7C.4070703@everydns.net> <20080830223839.GA15555@pwns.ms> <20080830234310.GA17717@pwns.ms> <215F9FF8-1BCB-472E-B91F-263510C202EF@verisign.com> <20080831204429.GA12465@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080831204429.GA12465@sources.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Aug 31, 2008 at 10:44:29PM +0200, Stephane Bortzmeyer wrote: > > definition. See: > > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-ecc-key/ > > Warning, we are deriving into a general discussion on EC cryptography > and this thread, IMHO, should stay focused on DNScurve. Ah yes, very good. Ok - about there being no trust anchors, I don't think this is explicit in the design. They just haven't been mentioned yet, but I'm pretty sure they could be added out of band - for people who want to be really sure. 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 15:47:14 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14F43A6813; Sun, 31 Aug 2008 15:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] 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 RBSwSSpUZjtP; Sun, 31 Aug 2008 15:47:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF0CF3A67E6; Sun, 31 Aug 2008 15:47:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZvZQ-000CRs-AT for namedroppers-data@psg.com; Sun, 31 Aug 2008 22:38:56 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZvZM-000CRG-Ro for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 22:38:54 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DC273A66AB for ; Sun, 31 Aug 2008 22:38:43 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sun, 31 Aug 2008 08:05:19 MST." <29378EC7-6FD5-45C5-978B-07C8DCD9C31E@icsi.berkeley.edu> References: <200808311238.m7VCcogf003897@givry.fdupont.fr> <29378EC7-6FD5-45C5-978B-07C8DCD9C31E@icsi.berkeley.edu> X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1 Date: Sun, 31 Aug 2008 22:38:43 +0000 Message-ID: <43481.1220222323@nsa.vix.com> X-Vix-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: DC273A66AB.6A224 X-Vix-MailScanner: Found to be clean X-Vix-MailScanner-From: vixie@vix.com Subject: Re: dnscurve -- new or did I just miss this? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Frankly speaking, the markeplace reason for a competitor to DNSSEC has > to arrise from ease-of-use concerns, not choice of crypto. ease of use being an engineering problem, it seems quite soluble to me. however, if we're going to reconsider "how to secure dns" and are therefore willing to throw away the last 13 or so years of work and ditch the products and vendors in this nascent industry, then i'd like it if masataka ohta's proposal was also considered. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 16:35:18 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB263A67D8; Sun, 31 Aug 2008 16:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_50=0.001] 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 EXFY14xNVdNw; Sun, 31 Aug 2008 16:35:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B79783A6916; Sun, 31 Aug 2008 16:35:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZwJN-000HEn-0q for namedroppers-data@psg.com; Sun, 31 Aug 2008 23:26:25 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZwJG-000HE2-Ty for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 23:26:21 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m7VNQBaA061143; Mon, 1 Sep 2008 09:26:12 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200808312326.m7VNQBaA061143@drugs.dv.isc.org> To: Jefferson Ogata Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Outstanding queries vs. source port randomization entropy In-reply-to: Your message of "Sun, 31 Aug 2008 20:24:47 GMT." <48BAFE0F.6090505@antibozo.net> Date: Mon, 01 Sep 2008 09:26:11 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > [I posted a variation on this message as a comment on Dan Kaminsky's > blog earlier today, but I'm skeptical he'll have the time to respond, so > I'm throwing it out to a wider audience.] > > So here's a question. With source port randomization, what prevents the > following attack? > > Attacker sets up a nameserver for example.com that receives queries but > sends no responses, with an appropriate delegation. Attacker then asks > the victim nameserver ~2^16 distinct queries under example.com in a > short time frame. This effectively consumes the entire source port range > with outstanding queries. The example.com nameserver observes the source > port for each inbound recursive query from the victim nameserver; the > one remaining source port that was not observed is the only port left to > the victim nameserver for its next query. Attacker then asks victim > nameserver for the domain to be poisoned, and forges the poison response > targeting the remaining port. > > I'm presenting an idealized attack here for the purpose of illustration. > The principle is to deplete the entropy included in source port > randomization by consuming the majority of available ports with > outstanding queries. The attack would only be effective against a > nameserver that allows close to 2^16 outstanding queries, i.e. high open > file descriptor limit, FD_SETSIZE appropriately redefined, etc.; a > nameserver that could have only 1024 outstanding requests, for example, > would be DoSed before it would lose significant entropy. The outstanding > requests could be distributed among many domains and distinct > nameservers if necessary, as long as the nameservers coordinate. The > attack could be partly mitigated on nameservers that allow ~2^16 > outstanding requests if the victim nameserver can reuse randomly chosen, > already open sockets for multiple successive requests once ~2^16 ports > are bound. The efficacy of this attack depends on the precise algorithm > by which the victim uses new ports, and what limits are enforced. > > I have to wonder how this has been addressed in the various resolvers > that implement source port randomization. Where has this scenario been > discussed before? It's too obvious not to have been considered earlier, > but I've done some Googling and skimmed some list archives and haven't > come up with anything. > > -- > Jefferson Ogata : Internetworker, Antibozo > > -- > 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: Use connected UDP socket then kernel can also use the source address as a differentiator when delivering replies. You can then support x to an individual destination. You still need to randomly select ports and randomly select txid. When you have a collision you just need to repick one and/or the other. A port collision alone lets you use a existing socket. For queries to another server you just set SO_REUSEADDR when you have a port collision with a port you already have open as the existing one is in a connected state. If it is a port that is not already in use you don't set SO_REUSEADDR so you detect collisions with other applications. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 16:44:49 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D8E3A694D; Sun, 31 Aug 2008 16:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.792 X-Spam-Level: * X-Spam-Status: No, score=1.792 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 OxfETo5eRt5m; Sun, 31 Aug 2008 16:44:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 368BF3A6818; Sun, 31 Aug 2008 16:44:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZwSZ-000ICw-Ho for namedroppers-data@psg.com; Sun, 31 Aug 2008 23:35:55 +0000 Received: from [71.241.230.133] (helo=secure.antibozo.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZwSV-000ICM-8G for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 23:35:53 +0000 Received: from [192.168.1.254] (calypso [71.178.203.249]) by secure.antibozo.net (Postfix) with ESMTP id 16AE3E2B52; Sun, 31 Aug 2008 23:35:50 +0000 (UTC) Message-ID: <48BB2AD5.7090402@antibozo.net> Date: Sun, 31 Aug 2008 23:35:49 +0000 From: Jefferson Ogata User-Agent: Mozilla/4.0 (compatible;MSIE 5.5; Windows 98) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Outstanding queries vs. source port randomization entropy References: <200808312326.m7VNQBaA061143@drugs.dv.isc.org> In-Reply-To: <200808312326.m7VNQBaA061143@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 2008-08-31 23:26, Mark Andrews wrote: > Jefferson Ogata wrote [attribution restored]: >> The >> attack could be partly mitigated on nameservers that allow ~2^16 >> outstanding requests if the victim nameserver can reuse randomly chosen, >> already open sockets for multiple successive requests once ~2^16 ports >> are bound. >> > You still need to randomly select ports and randomly select > txid. When you have a collision you just need to repick > one and/or the other. A port collision alone lets you use > a existing socket. I believe I considered that possibility in the above part of my comment. The question in that case remains: does any existing resolver that supports source port randomization actually do this? > For queries to another server you just set SO_REUSEADDR > when you have a port collision with a port you already have > open as the existing one is in a connected state. If it > is a port that is not already in use you don't set SO_REUSEADDR > so you detect collisions with other applications. I don't see why you need SO_REUSEADDR. Why not simply leave the UDP port unconnected and use sendto in the first place? -- Jefferson Ogata : Internetworker, Antibozo -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 17:08:21 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0AB3A6963; Sun, 31 Aug 2008 17:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.125, 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 qJzspaiuf3Dx; Sun, 31 Aug 2008 17:08:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 573C83A6950; Sun, 31 Aug 2008 17:08:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZwnL-000KYW-5b for namedroppers-data@psg.com; Sun, 31 Aug 2008 23:57:23 +0000 Received: from [74.95.2.169] (helo=kilo.rtfm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZwnF-000KXi-OO for namedroppers@ops.ietf.org; Sun, 31 Aug 2008 23:57:19 +0000 Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 266835C81C7; Sun, 31 Aug 2008 16:57:15 -0700 (PDT) Date: Sun, 31 Aug 2008 16:57:15 -0700 From: Eric Rescorla To: Nicholas Weaver Cc: Francis Dupont , list-namedroppers@pwns.ms, namedroppers@ops.ietf.org Subject: Re: dnscurve -- new or did I just miss this? In-Reply-To: <29378EC7-6FD5-45C5-978B-07C8DCD9C31E@icsi.berkeley.edu> References: <200808311238.m7VCcogf003897@givry.fdupont.fr> <29378EC7-6FD5-45C5-978B-07C8DCD9C31E@icsi.berkeley.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20080831235715.266835C81C7@kilo.rtfm.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Sun, 31 Aug 2008 08:05:19 -0700, Nicholas Weaver wrote: >=20 >=20 > On Aug 31, 2008, at 5:38 AM, Francis Dupont wrote: >=20 > > In your previous mail you wrote: > > > > so there is little motivation to moving to elliptic curves. > > > > =3D> I disagree: > > - ECs are faster than RSA and give smaller keys and signatures >=20 > This is true. Especially if you want to maintain for, as much as =20 > possible, the DNS maximum message size over UDP. It's not clear to me that signing computational performance is a particularly major factor here, since DNSSEC is designed to avoid the need for the signature to be recomputed for each request served, so the only per-transaction overhead is verification. RSA verification is extremely fast. For instance, on my MacBook Air, a single 1024-bit RSA verification takes about 500us. Note that EC verification is actually quite a bit slower than RSA verification up to large key sizes, so this isn't an advantage of EC, really. ISTM that the primary advantage of EC in DNSSEC is compactness of representation: Pubkey Size (bits) Signature Size (bits) RSA 1024* 1024 ECDSA 160** 320** * Assumes that e is fixed, e.g., to F4. Otherwise, you need 1-3 bytes to represent e ** With point compression and a single fixed EC curve. There are other tradeoffs you can make. For instance, if all you care about is signature size, you can do quite a bit better here. BLS [BLS04] is a pairing-based signature scheme that has a 160-bit signature. An additional BLS benefit is that you can aggregate the signatures. I.e., you can produce a single signature that is 160-bits long that combines two signatures by different signers, which lets you compress signature chains. Unfortunately, BLS verification performance is quite a bit slower than RSA verification, probably more like RSA signing (I'm guessing order 25 ms, but I don't have current data). This doesn't seem like a real problem for endhosts, but could certainly be one for recursive resolvers. Also, the public keys are fairly large so it's not clear that the public key + signature size is better than ECDSA. FWIW Looking at dnscurve, it doesn't look like a signature-based syste at all. Rather, the client and server do a DH exchange and use the=20 DH shared secret to authenticate the data. This has a number of obvious drawbacks in the DNS setting, including inability to cache and online vulnerability of the server to private key theft. -Ekr [BLS04] Dan Boneh, Ben Lynn, and Hovav Shacham, "Short Signatures from the Weil Pairing", J. Cryptology, 17(4):297?319, Sep. 2004. -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 17:40:55 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB473A69E0; Sun, 31 Aug 2008 17:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599] 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 1RZTzBvczZ2a; Sun, 31 Aug 2008 17:40:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF6933A67D8; Sun, 31 Aug 2008 17:40:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZxJO-000Oro-Do for namedroppers-data@psg.com; Mon, 01 Sep 2008 00:30:30 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZxJH-000Oqi-Pr for namedroppers@ops.ietf.org; Mon, 01 Sep 2008 00:30:28 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m810UIfb061698; Mon, 1 Sep 2008 10:30:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200809010030.m810UIfb061698@drugs.dv.isc.org> To: Jefferson Ogata Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Outstanding queries vs. source port randomization entropy In-reply-to: Your message of "Sun, 31 Aug 2008 23:35:49 GMT." <48BB2AD5.7090402@antibozo.net> Date: Mon, 01 Sep 2008 10:30:18 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On 2008-08-31 23:26, Mark Andrews wrote: > > Jefferson Ogata wrote [attribution restored]: > >> The > >> attack could be partly mitigated on nameservers that allow ~2^16 > >> outstanding requests if the victim nameserver can reuse randomly chosen, > >> already open sockets for multiple successive requests once ~2^16 ports > >> are bound. > >> > > You still need to randomly select ports and randomly select > > txid. When you have a collision you just need to repick > > one and/or the other. A port collision alone lets you use > > a existing socket. > > I believe I considered that possibility in the above part of my comment. > The question in that case remains: does any existing resolver that > supports source port randomization actually do this? > > > For queries to another server you just set SO_REUSEADDR > > when you have a port collision with a port you already have > > open as the existing one is in a connected state. If it > > is a port that is not already in use you don't set SO_REUSEADDR > > so you detect collisions with other applications. > > I don't see why you need SO_REUSEADDR. Why not simply leave the UDP port > unconnected and use sendto in the first place? Because you really want to have the kernel do the initial filtering of responses. You don't want your recursive server seeing every stray UDP packet being sent to you. With the amount of malware out there that is trying to get in over UDP your recursive server will be getting lots of noise if you randomly choose such a port. Connected sockets don't interfere with other uses of UDP (e.g. traceroute). You can't probe to see what ports are in use by the recursive server without making the server actually make queries to you. Mark > -- > Jefferson Ogata : Internetworker, Antibozo > > -- > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 17:59:52 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3966F3A69D8; Sun, 31 Aug 2008 17:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 aJgp5o0iDDyo; Sun, 31 Aug 2008 17:59:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CDFB3A698D; Sun, 31 Aug 2008 17:59:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZxcT-0001CS-6f for namedroppers-data@psg.com; Mon, 01 Sep 2008 00:50:13 +0000 Received: from [71.241.230.133] (helo=secure.antibozo.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZxcP-0001Bz-3h for namedroppers@ops.ietf.org; Mon, 01 Sep 2008 00:50:11 +0000 Received: from [192.168.1.254] (calypso [71.178.203.249]) by secure.antibozo.net (Postfix) with ESMTP id 23DA8E2B52; Mon, 1 Sep 2008 00:50:08 +0000 (UTC) Message-ID: <48BB3C3F.3030706@antibozo.net> Date: Mon, 01 Sep 2008 00:50:07 +0000 From: Jefferson Ogata User-Agent: Mozilla/4.0 (compatible;MSIE 5.5; Windows 98) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Outstanding queries vs. source port randomization entropy References: <200809010030.m810UIfb061698@drugs.dv.isc.org> In-Reply-To: <200809010030.m810UIfb061698@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 2008-09-01 00:30, Mark Andrews wrote: >> On 2008-08-31 23:26, Mark Andrews wrote: >>> Jefferson Ogata wrote [attribution restored]: >> I don't see why you need SO_REUSEADDR. Why not simply leave the UDP port >> unconnected and use sendto in the first place? > > Because you really want to have the kernel do the initial > filtering of responses. You don't want your recursive > server seeing every stray UDP packet being sent to you. > With the amount of malware out there that is trying to get > in over UDP your recursive server will be getting lots of > noise if you randomly choose such a port. Connected sockets > don't interfere with other uses of UDP (e.g. traceroute). > You can't probe to see what ports are in use by the recursive > server without making the server actually make queries to > you. I see. That clarifies it. So, since you're writing from ISC, does BIND do this, or is it on the roadmap if not? -- Jefferson Ogata : Internetworker, Antibozo -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 18:00:02 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3E93A69E0; Sun, 31 Aug 2008 18:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 XylQHQbYG6la; Sun, 31 Aug 2008 18:00:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF2753A698D; Sun, 31 Aug 2008 18:00:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZxZV-0000rY-91 for namedroppers-data@psg.com; Mon, 01 Sep 2008 00:47:09 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZxZR-0000qu-8q for namedroppers@ops.ietf.org; Mon, 01 Sep 2008 00:47:07 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m810kxR9061903; Mon, 1 Sep 2008 10:47:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200809010047.m810kxR9061903@drugs.dv.isc.org> Cc: Jefferson Ogata , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Outstanding queries vs. source port randomization entropy In-reply-to: Your message of "Mon, 01 Sep 2008 10:30:18 +1000." Date: Mon, 01 Sep 2008 10:46:59 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > > On 2008-08-31 23:26, Mark Andrews wrote: > > > Jefferson Ogata wrote [attribution restored]: > > >> The > > >> attack could be partly mitigated on nameservers that allow ~2^16 > > >> outstanding requests if the victim nameserver can reuse randomly chosen, > > > >> already open sockets for multiple successive requests once ~2^16 ports > > >> are bound. > > >> > > > You still need to randomly select ports and randomly select > > > txid. When you have a collision you just need to repick > > > one and/or the other. A port collision alone lets you use > > > a existing socket. > > > > I believe I considered that possibility in the above part of my comment. > > The question in that case remains: does any existing resolver that > > supports source port randomization actually do this? > > > > > For queries to another server you just set SO_REUSEADDR > > > when you have a port collision with a port you already have > > > open as the existing one is in a connected state. If it > > > is a port that is not already in use you don't set SO_REUSEADDR > > > so you detect collisions with other applications. > > > > I don't see why you need SO_REUSEADDR. Why not simply leave the UDP port > > unconnected and use sendto in the first place? > > Because you really want to have the kernel do the initial > filtering of responses. You don't want your recursive > server seeing every stray UDP packet being sent to you. > With the amount of malware out there that is trying to get > in over UDP your recursive server will be getting lots of > noise if you randomly choose such a port. Connected sockets > don't interfere with other uses of UDP (e.g. traceroute). > You can't probe to see what ports are in use by the recursive > server without making the server actually make queries to > you. > > Mark Additionally with sendto() you will tend to get locked onto a open set of ports as you need to wait for the next response whenever you re-use a port. With connect() each transaction becomes almost completely independent of other transaction. Note all the probability analysis being done assume independent transactions. If you have depenancies between transactions (i.e. re-use of a socket) then all the analyses needs to be redone to factor in that socket re-use. Even without doing such a analysis I can tell you that re-use makes the system weaker not stronger. Mark > > -- > > Jefferson Ogata : Internetworker, Antibozo > > > > -- > > 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: > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 18:11:38 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44CA33A69D8; Sun, 31 Aug 2008 18:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.513 X-Spam-Level: * X-Spam-Status: No, score=1.513 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 ztdBRfiApwTW; Sun, 31 Aug 2008 18:11:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 63F833A696F; Sun, 31 Aug 2008 18:11:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZxou-0002ih-DA for namedroppers-data@psg.com; Mon, 01 Sep 2008 01:03:04 +0000 Received: from [71.241.230.133] (helo=secure.antibozo.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZxoq-0002iH-Tq for namedroppers@ops.ietf.org; Mon, 01 Sep 2008 01:03:02 +0000 Received: from [192.168.1.254] (calypso [71.178.203.249]) by secure.antibozo.net (Postfix) with ESMTP id E5386E2B52; Mon, 1 Sep 2008 01:02:59 +0000 (UTC) Message-ID: <48BB3F42.7030305@antibozo.net> Date: Mon, 01 Sep 2008 01:02:58 +0000 From: Jefferson Ogata User-Agent: Mozilla/4.0 (compatible;MSIE 5.5; Windows 98) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Outstanding queries vs. source port randomization entropy References: <200809010047.m810kxR9061903@drugs.dv.isc.org> In-Reply-To: <200809010047.m810kxR9061903@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 2008-09-01 00:46, Mark Andrews wrote: > Additionally with sendto() you will tend to get locked onto > a open set of ports as you need to wait for the next response > whenever you re-use a port. With connect() each transaction > becomes almost completely independent of other transaction. I don't follow; when you have ~2^16 distinct source ports bound, how can you get locked into a sub-optimal set of ports? Your point about combining connected UDP sockets with SO_REUSEADDR in order to take advantage of kernel filtering and avoid impacting on other uses of UDP is well taken, but a drawback I see is that your file descriptor set has to continue to grow past 2^16 if you don't actually reuse existing sockets. > Note all the probability analysis being done assume > independent transactions. If you have depenancies between > transactions (i.e. re-use of a socket) then all the analyses > needs to be redone to factor in that socket re-use. > > Even without doing such a analysis I can tell you that > re-use makes the system weaker not stronger. I only speculate about reuse of source ports as mitigation against the complete loss of source port entropy once the number of free source ports becomes small. I.e. the source port would continue to be random regardless of the size of the pool of available source ports. I don't see how this makes the system weaker; what am I missing? -- Jefferson Ogata : Internetworker, Antibozo -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 18:39:47 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9153A6A4F; Sun, 31 Aug 2008 18:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.577 X-Spam-Level: ** X-Spam-Status: No, score=2.577 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_57=0.6, 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 Vf4D8qkoxrgX; Sun, 31 Aug 2008 18:39:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 030DE3A6A48; Sun, 31 Aug 2008 18:39:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZyFs-0006M0-Ix for namedroppers-data@psg.com; Mon, 01 Sep 2008 01:30:56 +0000 Received: from [208.218.130.13] (helo=gis.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZyFo-0006LC-Bd for namedroppers@ops.ietf.org; Mon, 01 Sep 2008 01:30:54 +0000 Received: from [127.0.0.1] ([63.209.233.229]) by mx05.gis.net; Sun, 31 Aug 2008 21:30:34 -0400 Message-ID: <48BB45B9.3050803@gis.net> Date: Sun, 31 Aug 2008 21:30:33 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Mark Andrews CC: Olafur Gudmundsson , Paul Vixie , Florian Weimer , namedroppers@ops.ietf.org Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR References: <200808210020.m7L0K3im029621@drugs.dv.isc.org> In-Reply-To: <200808210020.m7L0K3im029621@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark Andrews wrote: >> >> >> At 14:24 20/08/2008, Paul Vixie wrote: >>>>> i propose that an empty answer be sent >>>> What can stand as an empty answer? REFUSED? >>> ANCOUNT=0 >> RCODE=REFUSED seems to me to be a cleaner solution and as nameserver >> are allowed to send that back any time it likes, this is not even a >> hit of protocol change. >> Someone can just write a short document >> "QTYPE=ANY considered harmful, just REFUSE them" :-) >> to document the practice and point the people at that complain. > > We have load balancers that send REFUSED rather than NOERROR > for AAAA queries today. These cause operational problems. > It seems to me that we have the classic problem of responses written for servers based on certain conditions leaving the clients to try and figure out what that response really meant. What is really needed is a document that says the response X will happen under the following list of circumstances, and response Y will happen under these other circumstances. Then it becomes easy to figure out what is the most appropriate response based on some new circumstances. Clients need to understand the meaning of the response within the context of the query. Danny -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 18:54:03 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A773A69E0; Sun, 31 Aug 2008 18:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599] 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 Qg0pdTd5ZcPj; Sun, 31 Aug 2008 18:54:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D9363A69C1; Sun, 31 Aug 2008 18:54:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZyTd-0007nx-0v for namedroppers-data@psg.com; Mon, 01 Sep 2008 01:45:09 +0000 Received: from [2001:470:1f00:820:214:22ff:fed9:fbdc] (helo=drugs.dv.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZyTZ-0007nJ-7h for namedroppers@ops.ietf.org; Mon, 01 Sep 2008 01:45:07 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m811ixZb062367; Mon, 1 Sep 2008 11:45:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200809010145.m811ixZb062367@drugs.dv.isc.org> To: Jefferson Ogata Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Outstanding queries vs. source port randomization entropy In-reply-to: Your message of "Mon, 01 Sep 2008 01:02:58 GMT." <48BB3F42.7030305@antibozo.net> Date: Mon, 01 Sep 2008 11:44:59 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On 2008-09-01 00:46, Mark Andrews wrote: > > Additionally with sendto() you will tend to get locked onto > > a open set of ports as you need to wait for the next response > > whenever you re-use a port. With connect() each transaction > > becomes almost completely independent of other transaction. > > I don't follow; when you have ~2^16 distinct source ports bound, how can > you get locked into a sub-optimal set of ports? Ususally you don't have 2^16 ports in use. > Your point about combining connected UDP sockets with SO_REUSEADDR in > order to take advantage of kernel filtering and avoid impacting on other > uses of UDP is well taken, but a drawback I see is that your file > descriptor set has to continue to grow past 2^16 if you don't actually > reuse existing sockets. Yes. There are tradeoffs everywhere in this space. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 31 20:43:00 2008 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B03A3A688A; Sun, 31 Aug 2008 20:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 7rua1fEI4XSt; Sun, 31 Aug 2008 20:42:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F3983A6830; Sun, 31 Aug 2008 20:42:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ka0AB-000KJV-Uk for namedroppers-data@psg.com; Mon, 01 Sep 2008 03:33:11 +0000 Received: from [71.241.230.133] (helo=secure.antibozo.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ka0A8-000KJ1-0A for namedroppers@ops.ietf.org; Mon, 01 Sep 2008 03:33:10 +0000 Received: from [192.168.1.254] (calypso [71.178.203.249]) by secure.antibozo.net (Postfix) with ESMTP id E17AEE2B52; Mon, 1 Sep 2008 03:33:06 +0000 (UTC) Message-ID: <48BB6271.7060201@antibozo.net> Date: Mon, 01 Sep 2008 03:33:05 +0000 From: Jefferson Ogata User-Agent: Mozilla/4.0 (compatible;MSIE 5.5; Windows 98) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Outstanding queries vs. source port randomization entropy References: <200809010145.m811ixZb062367@drugs.dv.isc.org> In-Reply-To: <200809010145.m811ixZb062367@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 2008-09-01 01:44, Mark Andrews wrote: > Jefferson Ogata wrote [attribution restored, again--dude, you should fix that]: >> On 2008-09-01 00:46, Mark Andrews wrote: >>> Additionally with sendto() you will tend to get locked onto >>> a open set of ports as you need to wait for the next response >>> whenever you re-use a port. With connect() each transaction >>> becomes almost completely independent of other transaction. >> I don't follow; when you have ~2^16 distinct source ports bound, how can >> you get locked into a sub-optimal set of ports? > > Ususally you don't have 2^16 ports in use. Well, yes, in which case, you are just using new ports as usual. Am I being very unclear? Really, the optimal behavior would be to choose the source port for the next query based strictly on your entropy source, and not on availability at all. So once you pass 2^15 outstanding queries, you would be more likely to reuse a source port than not to, if you want to maintain unpredictability of source port numbers. So it seems to me that any implementation that is not designed to reuse source ports, even at a very low rate when there are only a few outstanding queries, is not optimizing the entropy available in source port randomization. -- Jefferson Ogata : Internetworker, Antibozo -- 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: