From owner-namedroppers@ops.ietf.org Sun Aug 1 02:49:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25443 for ; Sun, 1 Aug 2004 02:49:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrA47-000FnT-VZ for namedroppers-data@psg.com; Sun, 01 Aug 2004 06:43:27 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrA3o-000FmR-Oc for namedroppers@ops.ietf.org; Sun, 01 Aug 2004 06:43:09 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id A2E1F55C1D; Sun, 1 Aug 2004 08:35:02 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 799EF55C15 for ; Sun, 1 Aug 2004 08:35:01 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i716Z1x0032394 for ; Sun, 1 Aug 2004 08:35:01 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i716Z1vW015820 for namedroppers@ops.ietf.org; Sun, 1 Aug 2004 08:35:01 +0200 Date: Sun, 1 Aug 2004 08:35:01 +0200 From: Olaf Kolkman Message-Id: <200408010635.i716Z1vW015820@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Status: U 0.497453 / 0.0 / 0.0 / disabled X-RIPE-Signature: b78bf13e513938a5fcce9acc8004d380 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT 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 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' misconfigurations, 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 mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation 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 chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, 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 Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.7 2004/05/17 12:46:38 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Aug 1 10:13:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28889 for <dnsext-archive@lists.ietf.org>; Sun, 1 Aug 2004 10:13:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrGyK-00083I-1W for namedroppers-data@psg.com; Sun, 01 Aug 2004 14:05:56 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrGy9-0007zd-Df for namedroppers@ops.ietf.org; Sun, 01 Aug 2004 14:05:45 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i71E550R014826; Sun, 1 Aug 2004 07:05:14 -0700 (PDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i71E51JR002822; Sun, 1 Aug 2004 16:05:03 +0200 (MEST) Date: Sun, 1 Aug 2004 07:05:26 -0700 (PDT) From: Erik Nordmark <Erik.Nordmark@sun.com> Reply-To: Erik Nordmark <Erik.Nordmark@sun.com> Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface To: Edward Lewis <edlewis@arin.net> Cc: Jun-ichiro itojun Hagino <itojun@itojun.org>, miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu In-Reply-To: "Your message with ID" <a06020401bd2e9c9247c1@[192.136.136.102]> Message-ID: <Roam.SIMC.2.0.6.1091369126.19351.nordmark@bebop.france> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My point is - applications developers ought to rely on DNS at it's > service's face value, not by inferring anything in the ancillary > data. If application developers try to read between the lines, we > muddle the architecture of the Internet and will end up with a "house > of cards." If we started with a blank sheet of paper that might work; but we unfortunaly have to deal with the existing house of cards. When I try to tell application/middleware developpers to stop retaining information returned by getaddrinfo/gethostbyname forever and instead requery every time the information is needed it isn't well received. The perception is that application caching (more or less forever) work in the majority of cases so why is doing something different the app developpers problem. Hence I think we could collectively be more effective in fixing this if we could present an API mechanism by which the application/middleware could find out an upper limit on how long time it should retain the information in its own cache. Whether it is quicker and better to do this by standardizing getrrsetbyname or by extending getaddrinfo is something we can debate once we have an agreement that this is a useful approach. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Aug 1 18:01:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26427 for <dnsext-archive@lists.ietf.org>; Sun, 1 Aug 2004 18:01:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrOH2-0002nu-FL for namedroppers-data@psg.com; Sun, 01 Aug 2004 21:53:44 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrOGr-0002n3-Cl for namedroppers@ops.ietf.org; Sun, 01 Aug 2004 21:53:34 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i71LrJi9029307 for <namedroppers@ops.ietf.org>; Sun, 1 Aug 2004 17:53:19 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i71LrJ9x029306 for namedroppers@ops.ietf.org; Sun, 1 Aug 2004 17:53:19 -0400 (EDT) (envelope-from namedroppers) Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Br6pC-000IVF-Ie for namedroppers@ops.ietf.org; Sun, 01 Aug 2004 03:15:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i713FUu21780; Sun, 1 Aug 2004 06:15:33 +0300 Date: Sun, 1 Aug 2004 06:15:29 +0300 (EEST) From: Pekka Savola <pekkas@netcore.fi> To: Jun-ichiro itojun Hagino <itojun@itojun.org> cc: Erik.Nordmark@sun.com, <miekg@atoom.net>, <namedroppers@ops.ietf.org>, <dnsop@lists.uoregon.edu> Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface In-Reply-To: <20040801001419.2854D1C0C4@coconut.itojun.org> Message-ID: <Pine.LNX.4.44.0408010614440.21586-100000@netcore.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Sun, 1 Aug 2004, Jun-ichiro itojun Hagino wrote: > getaddrinfo() is not a DNS-only function; it can lookup hostname-to > address using /etc/hosts, NIS, LDAP, whatever you have. what value > would you put in to ai_ttl when the lookup is done by non-DNS method? -1, unless something else is provided? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Aug 1 18:11:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27571 for <dnsext-archive@lists.ietf.org>; Sun, 1 Aug 2004 18:11:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrOWF-0004nY-TB for namedroppers-data@psg.com; Sun, 01 Aug 2004 22:09:27 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrOW5-0004mJ-17 for namedroppers@ops.ietf.org; Sun, 01 Aug 2004 22:09:17 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 255251C0BF; Mon, 2 Aug 2004 07:03:01 +0900 (JST) To: Pekka Savola <pekkas@netcore.fi> Cc: Erik.Nordmark@sun.com, miekg@atoom.net, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu In-reply-to: pekkas's message of Sun, 01 Aug 2004 06:15:29 +0300. <Pine.LNX.4.44.0408010614440.21586-100000@netcore.fi> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface From: itojun@iijlab.net Date: Mon, 02 Aug 2004 07:03:01 +0900 Message-Id: <20040801220301.255251C0BF@coconut.itojun.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >On Sun, 1 Aug 2004, Jun-ichiro itojun Hagino wrote: >> getaddrinfo() is not a DNS-only function; it can lookup hostname-to >> address using /etc/hosts, NIS, LDAP, whatever you have. what value >> would you put in to ai_ttl when the lookup is done by non-DNS method? > >-1, unless something else is provided? then what do you expect application to do with the data? when does it expire? any fabricated value (-1, 0, whatever) in ai_ttl is problematical to TTL-aware application, IMHO. what i'm suggesting is to use DNS-only API like getrrrsetbyname() if you want TTL. itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Aug 1 21:56:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08760 for <dnsext-archive@lists.ietf.org>; Sun, 1 Aug 2004 21:56:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrRzm-0001gJ-O5 for namedroppers-data@psg.com; Mon, 02 Aug 2004 01:52:10 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrRzc-0001fH-18 for namedroppers@ops.ietf.org; Mon, 02 Aug 2004 01:52:00 +0000 Received: from [192.168.0.5] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id AA55338F23; Sun, 1 Aug 2004 20:51:57 -0500 (CDT) Message-ID: <410D9E24.6000206@ehsco.com> Date: Sun, 01 Aug 2004 21:51:32 -0400 From: "Eric A. Hall" <ehall@ehsco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: Jun-ichiro itojun Hagino <itojun@itojun.org>, Erik.Nordmark@sun.com, miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface References: <20040801003710.4D95513DE9@sa.vix.com> In-Reply-To: <20040801003710.4D95513DE9@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 7/31/2004 8:37 PM, Paul Vixie wrote: > i don't think expansing getaddrinfo/getnameinfo to return ttl is the > right approach. we need a "getrrsetbyname" for dns-aware applications > that returns ttl, security status, and so on. "rrset" is the right target, too. apps that try to do their own load-balancing and whatnot need to be given the original unordered set, not a random member of the set -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 2 15:42:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29823 for <dnsext-archive@lists.ietf.org>; Mon, 2 Aug 2004 15:42:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BriYH-000E5j-TF for namedroppers-data@psg.com; Mon, 02 Aug 2004 19:32:53 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BriXz-000E4n-9L for namedroppers@ops.ietf.org; Mon, 02 Aug 2004 19:32:35 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i72JWYds009813 for <namedroppers@ops.ietf.org>; Mon, 2 Aug 2004 12:32:34 -0700 Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <P72MVGPN>; Mon, 2 Aug 2004 12:32:34 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BE9EE@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Mon, 2 Aug 2004 12:32:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At blackhat there was a presentation on the ongoing .il vs .ps cyberwar. This began with an attack on various pro-Palestinian groups and was shortly followed by a retaliation on pro-Israeli sites and the entire .il domain. It is pretty clear that whoever is running the .il domain is not going to implement any scheme that makes it easier to walk the domain. With respect to the claim made by Olaf that it is possible to zone walk today, the possibility of a dictionary attack is very different from an enumeration. No dictionary attack is ever going to recover all the addresses in the domain. You may get some proportion of the domains, but you will not get all of them and will probably not even get most of them. Security schemes ultimately come down to complexity arguments. The complexity of an exhaustive dictionary attack is 28^l where l is the length of the domain name. The complexity of an enumeration is n, where n is the number of domains registered. Thus the number of steps required to recover a domain on average is (28^l)/n vs 1. That is quite a big difference in complexity terms. 3E11 harder for an 8 character domain name, which is not all that long. Sure you can cut down the complexity of a dictionary attack somewhat by using phonemes, but you still have a lot of work. 12 character domain names are commonplace. Even with phonemes you still have an exponential. I think that it is pretty clear that what is being asked for here is a mechanism that ensures that the cost of walking a domain remains an exponential function of the length of the domain name. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 2 16:14:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01553 for <dnsext-archive@lists.ietf.org>; Mon, 2 Aug 2004 16:14:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brj94-000IHc-Km for namedroppers-data@psg.com; Mon, 02 Aug 2004 20:10:54 +0000 Received: from [130.129.16.9] (helo=pollux.ietf60.ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brj8t-000IH3-Tu for namedroppers@ops.ietf.org; Mon, 02 Aug 2004 20:10:44 +0000 Received: from [130.129.134.222] (opene-130-129-134-222.ietf60.ietf.org [130.129.134.222]) by pollux.ietf60.ietf.org (8.12.10/8.12.10) with ESMTP id i72KAhaj061294 for <namedroppers@ops.ietf.org>; Mon, 2 Aug 2004 13:10:43 -0700 (PDT) (envelope-from jelte@NLnetLabs.nl) Message-ID: <410EBC46.1000404@NLnetLabs.nl> Date: Mon, 02 Aug 2004 22:12:22 +0000 From: Jelte Jansen <jelte@NLnetLabs.nl> User-Agent: Mozilla Thunderbird 0.6 (X11/20040723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: NSECX proposals Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, do the drafts describing possible NSEC replacements or the requirements/transitions documents say anything about how much (or maybe just if) these proposals add to the complexity of maintaining zones (for example does it make it harder to change anything, or is incremental signing still possible)? If DNSSEC acceptance is an argument for proposing other NSEC schemes, i think that maintainability is a huge factor. Jelte -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 2 19:08:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13308 for <dnsext-archive@lists.ietf.org>; Mon, 2 Aug 2004 19:08:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brlpz-00099t-1u for namedroppers-data@psg.com; Mon, 02 Aug 2004 23:03:23 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brlpn-00098h-VY for namedroppers@ops.ietf.org; Mon, 02 Aug 2004 23:03:12 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i72N37wl003051 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 01:03:07 +0200 (CEST) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i72N35I1023453 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 01:03:05 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i72N35Go023452 for namedroppers@ops.ietf.org; Tue, 3 Aug 2004 01:03:05 +0200 Date: Tue, 3 Aug 2004 01:03:05 +0200 From: Miek Gieben <miekg@atoom.net> To: namedroppers <namedroppers@ops.ietf.org> Subject: whois and zone enumeration Message-ID: <20040802230305.GA23395@atoom.net> Mail-Followup-To: namedroppers <namedroppers@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, I've a simple question. If a TLD would shutdown their whois service, would zone enumeration then still be a problem? (ignoring the fact that you might not want to do this) grtz, --Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 2 19:29:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14251 for <dnsext-archive@lists.ietf.org>; Mon, 2 Aug 2004 19:29:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrmCi-000BVj-EV for namedroppers-data@psg.com; Mon, 02 Aug 2004 23:26:52 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrmCH-000BTM-Ri for namedroppers@ops.ietf.org; Mon, 02 Aug 2004 23:26:26 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i72NQPrc031122 for <namedroppers@ops.ietf.org>; Mon, 2 Aug 2004 23:26:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i72NQPwc031119 for namedroppers@ops.ietf.org; Mon, 2 Aug 2004 23:26:25 GMT Date: Mon, 2 Aug 2004 23:26:25 +0000 From: bmanning@vacation.karoshi.com To: namedroppers <namedroppers@ops.ietf.org> Subject: Re: whois and zone enumeration Message-ID: <20040802232625.GA31086@vacation.karoshi.com.> References: <20040802230305.GA23395@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040802230305.GA23395@atoom.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, OPT_IN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Aug 03, 2004 at 01:03:05AM +0200, Miek Gieben wrote: > Hello, > > I've a simple question. If a TLD would shutdown their whois service, > would zone enumeration then still be a problem? > > (ignoring the fact that you might not want to do this) > > grtz, > --Miek once, many years ago, I ran a TLD and -expressly- did not run a whois server/service for it. if that was still the case, I might still be "grumpy" about zone enumeration simply because the IETF, in an attempt to be "helpful" specified several roll accounts that are expected to be available at each delegation point. put the two together and a "double opt-in" list of freshly harvested email addresses which I can send my scam'o'the-day. so... zone enumeration + IETF BCP'd roll accounts highlights one of the abusive techniques. No whois needed. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 2 19:53:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15690 for <dnsext-archive@lists.ietf.org>; Mon, 2 Aug 2004 19:53:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrmYb-000EA7-GD for namedroppers-data@psg.com; Mon, 02 Aug 2004 23:49:29 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrmWU-000Dpt-Jp for namedroppers@ops.ietf.org; Mon, 02 Aug 2004 23:47:18 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 81978E7EC7; Tue, 3 Aug 2004 00:47:17 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: whois and zone enumeration In-Reply-To: <20040802230305.GA23395@atoom.net> Message-Id: <20040802234717.81978E7EC7@mx1.nominet.org.uk> Date: Tue, 3 Aug 2004 00:47:17 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Miek Gieben <miekg@atoom.net> writes: > I've a simple question. If a TLD would shutdown their whois service, > would zone enumeration then still be a problem? Yes. Elaboration of delegation-only zones is a problem in and of itself. Lists of owner names may be (and, in Nominet's case, have been) employed in combination with RFC 2142 local-parts to create mailing lists that are subsequently used/sold on for for the purpose of UCE. Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 2 21:00:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19622 for <dnsext-archive@lists.ietf.org>; Mon, 2 Aug 2004 21:00:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brnc8-000Ma2-61 for namedroppers-data@psg.com; Tue, 03 Aug 2004 00:57:12 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brnbx-000MXW-IO for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 00:57:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2FC0B13DFB for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 00:57:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: whois and zone enumeration In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Tue, 03 Aug 2004 00:47:17 +0100." <20040802234717.81978E7EC7@mx1.nominet.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 03 Aug 2004 00:57:01 +0000 Message-Id: <20040803005701.2FC0B13DFB@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I've a simple question. If a TLD would shutdown their whois service, > > would zone enumeration then still be a problem? > > Yes. Elaboration of delegation-only zones is a problem in and of > itself. Lists of owner names may be (and, in Nominet's case, have > been) employed in combination with RFC 2142 local-parts to create > mailing lists that are subsequently used/sold on for for the purpose > of UCE. what we have here is a divergence of vision. security is not obscurity, and obscurity is not an intended feature of either "dns classic" or any extension ever made to dns. consider that almost any use made of a domain will subject it to public view, where it can be and will be recorded. consider that many uses of this data are benign or even well intended, like measurements or search engines. consider that every bad use (UCE, etc) can be and will be made whether obscurity is used or not. if you have information you don't want the world to know the name of, then don't put it in dns at all, or use "split dns" to limit the viewability of this data to small trusted population such as your intranet. some say that nsecX is a way to make dns as obscure as pre-dnssec dns was. i say that the asserted obscurity of pre-dnssec dns was illusory, and that our "complexity budget" is best used for actual features. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 2 22:58:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24428 for <dnsext-archive@lists.ietf.org>; Mon, 2 Aug 2004 22:58:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrpQx-0008Fy-1g for namedroppers-data@psg.com; Tue, 03 Aug 2004 02:53:47 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrpQk-0008ES-CZ for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 02:53:34 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i732rXDD026669 for <namedroppers@ops.ietf.org>; Mon, 2 Aug 2004 19:53:33 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <P72RA5NK>; Mon, 2 Aug 2004 19:53:33 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BE9FD@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: namedroppers@ops.ietf.org Subject: RE: whois and zone enumeration Date: Mon, 2 Aug 2004 19:53:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > what we have here is a divergence of vision. security is not > obscurity, and obscurity is not an intended feature of either > "dns classic" or any extension ever made to dns. As a security professional who is engaged as such I can assure you that it is a very bad idea to remove security controls from an existing system unless you understand their effect. The fact that a control is unintended or is rejected on ideological grounds does not mean that it can be dispensed with. I am currently dealling with the consequences of an industry abandoning certain controls that were present in the ATM systems but are not present on the Internet. As a result I spend a great deal of time talking to law enforcement. Removing imperfect security controls without replacing them is one of the main ways that security protocols fail in practice. Before simply repeating the standard security dogmas that you have heard, please understand that they have never been considered absolute maxims in the security world and those who have tried to apply them have mostly produced systems that failed. 'Security through obscurity is false security' has been a discredited dogma in the security world since it was used to delay the introduction of shaddow passwords in UNIX for about three years. It took the arrival of crack to change minds there. 'End to End security' and 'bad security is worse than no security' are also considered obsolete in the real security world. The common sense ideas that preceded the dogmas are still generally accepted. But you are advancing a dogmatic interpretation that is rejected by the field. It certainly has no place in a security design argument. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 03:13:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21148 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 03:13:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrtPL-0008b0-Qo for namedroppers-data@psg.com; Tue, 03 Aug 2004 07:08:23 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrtPB-0008Zp-51 for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 07:08:13 +0000 Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7378CN06929 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 00:08:12 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i73789ZE023950 for namedroppers@ops.ietf.org; Tue, 3 Aug 2004 00:08:09 -0700 Date: Tue, 3 Aug 2004 00:08:09 -0700 From: kent@songbird.com To: namedroppers@ops.ietf.org Subject: What I mumbled at the mike today... Message-ID: <20040803070809.GF16208@raven.songbird.com> Mail-Followup-To: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ...may not have been terribly clear. Here's an attempt to put it in a more coherent form: Roughly speaking, a dictionary attack on a zone costs an attacker the same regardless of the size of the zone -- one query per dictionary word. The cost is a function of the dictionary size, and is independent of the number of entries in the zone under attack. On the other hand, the payoff (number of domain names discovered) is a function of the zone size, as well as the dictionary size. Hence, dictionary attacks on large zones are intrinsically more efficient than attacks on small zones. That is, dictionary attacks on small zones are less efficient, and therefore, attackers who value their time won't waste their it in mass attacks on small zones. We can expect that would change, if there were a convenient and efficient way of getting the contents of small zones. It would be interesting to know how many managers of small zones see value in obscuring the contents of their zones. As an exercise I tried doing zone transfers from the domains in some of the email addresses on this list, but I gave up after a dozen or so -- not a single one allowed axfrs. :-) Regards Kent -- kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 05:20:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26492 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 05:20:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrvOp-000KQQ-PL for namedroppers-data@psg.com; Tue, 03 Aug 2004 09:15:59 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrvOe-000KPQ-Py for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 09:15:48 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id AF55D1FDCB; Tue, 3 Aug 2004 10:15:47 +0100 (BST) Date: Tue, 03 Aug 2004 10:15:44 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: kent@songbird.com, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: What I mumbled at the mike today... Message-ID: <336DEA1A50C9BCD9263BFAFD@[192.168.100.27]> In-Reply-To: <20040803070809.GF16208@raven.songbird.com> References: <20040803070809.GF16208@raven.songbird.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 August 2004 00:08 -0700 kent@songbird.com wrote: > On the other hand, the payoff (number of domain names discovered) is a > function of the zone size, as well as the dictionary size. > > Hence, dictionary attacks on large zones are intrinsically more > efficient than attacks on small zones. That is probably true comparing small to medium zones (I'd never thought of it that way), but I suggest it becomes false at some zone size in the case of TLD (open registration type zones) esp. when the size of zone far exceeds the size of the dictionary. This is because those registering are likely to register words in the dictionary first, and thus subsequent registrations have decreasing probability of dictionary discoverability (or rather increased cost of discoverability). To put it another way, I would expect a dictionary attack of given CPU power to reveal a greater percentage of a randomly selected 1000 names from .org as against .com (approximately 10 times larger). So while discovering "some" names from a larger zone is going to be easy, discovering a substantial large percentage of that zone I would suggest becomes harder at a rate more than linearly related to the size of the zone. There's no mathematically argument here - it's about what is likely to be in zone files. And I have no stats (right now) to prove the point (just as those who claim zones are already in effect enumerable now don't have stats). 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 09:18:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07561 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 09:18:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brz67-000G7S-E8 for namedroppers-data@psg.com; Tue, 03 Aug 2004 13:12:55 +0000 Received: from [192.134.4.10] (helo=mx1.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brz5b-000G5c-Hw for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 13:12:23 +0000 Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id B87639401F; Tue, 3 Aug 2004 15:12:21 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id BE8B594009; Tue, 3 Aug 2004 15:12:20 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i73DCKjI1300049; Tue, 3 Aug 2004 15:12:20 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 8FCC1102C1; Tue, 3 Aug 2004 15:12:20 +0200 (CEST) Date: Tue, 3 Aug 2004 15:12:20 +0200 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: Re: whois and zone enumeration Message-ID: <20040803131220.GB22126@nic.fr> References: <C6DDA43B91BFDA49AA2F1E473732113E010BE9FD@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BE9FD@mou1wnexm05.vcorp.ad.vrsn.com> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Aug 02, 2004 at 07:53:31PM -0700, Hallam-Baker, Phillip <pbaker@verisign.com> wrote a message of 46 lines which said: > 'Security through obscurity is false security' has been a > discredited dogma in the security world Because many people misunderstood it: they thought it meaned "Security through obscurity is false security and thefore everything should be published immediately" while it actually means "Security through obscurity is false security and therefore your security should not disappear completely when the system is known" (defence in depth: I do not assume that zone enumeration is impossible, I have other protections, but it does not mean I post the zone file on an anonymous FTP server). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 09:19:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07596 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 09:19:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brz2o-000Frs-2t for namedroppers-data@psg.com; Tue, 03 Aug 2004 13:09:30 +0000 Received: from [192.134.4.10] (helo=mx1.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brz2S-000FqO-FZ for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 13:09:08 +0000 Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id 8E0199401F; Tue, 3 Aug 2004 15:09:07 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 9F1B394018; Tue, 3 Aug 2004 15:09:06 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i73D96jI1299099; Tue, 3 Aug 2004 15:09:06 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 85321102C1; Tue, 3 Aug 2004 15:09:06 +0200 (CEST) Date: Tue, 3 Aug 2004 15:09:06 +0200 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Message-ID: <20040803130906.GA22126@nic.fr> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4109DA5D.5040706@ripe.net> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jul 30, 2004 at 07:19:25AM +0200, Olaf M. Kolkman <olaf@ripe.net> wrote a message of 40 lines which said: > This working group will need to get the requirements for making informed > decisions on how to design NSEC++. Remember that Rip and Ben have > volunteered to put such a list together. Please send your requirements > to these to friendly volunteers. If you have a threat model in mind, > please document and send to Ben & Rip. Well, I regret it has to be specified but I add a requirment, the "Nightingale requirment": At the very least, DNSsec should not lower security and should not make existing attacks (e.g. zone enumeration) easier. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 09:57:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09133 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 09:57:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Brzje-000K0w-Nx for namedroppers-data@psg.com; Tue, 03 Aug 2004 13:53:46 +0000 Received: from [32.97.182.102] (helo=e2.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrzjT-000JzW-QC for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 13:53:36 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i73DrYmi404774 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 09:53:34 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i73Dsj1Y124378 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 09:54:45 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.10/8.12.11) with ESMTP id i73DrX3I003175 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 09:53:33 -0400 Received: from IBMTC_S30001313.gis.net ([9.22.26.62]) by d01av03.pok.ibm.com (8.12.10/8.12.11) with ESMTP id i73DrVmT003046; Tue, 3 Aug 2004 09:53:32 -0400 Message-Id: <4.3.1.2.20040803094512.02b157f8@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 03 Aug 2004 09:53:21 -0400 To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org From: Danny Mayer <mayer@gis.net> Subject: RE: whois and zone enumeration In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BE9FD@mou1wnexm05.vcorp .ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:53 PM 8/2/2004, Hallam-Baker, Phillip wrote: > > what we have here is a divergence of vision. security is not > > obscurity, and obscurity is not an intended feature of either > > "dns classic" or any extension ever made to dns. > >As a security professional who is engaged as such I can assure >you that it is a very bad idea to remove security controls >from an existing system unless you understand their effect. I agree with Paul. He is not advocating the removal of anything. He's saying that depending on obscurity for security is no security at all. >The fact that a control is unintended or is rejected on >ideological grounds does not mean that it can be dispensed >with. I am currently dealling with the consequences of >an industry abandoning certain controls that were present >in the ATM systems but are not present on the Internet. >As a result I spend a great deal of time talking to >law enforcement. You misread his statement. >Removing imperfect security controls without replacing them >is one of the main ways that security protocols fail in >practice. Where did he advocate removing imperfect security controls? >The common sense ideas that preceded the dogmas are still >generally accepted. But you are advancing a dogmatic interpretation >that is rejected by the field. It certainly has no place in a >security design argument. He's not advancing any dogma. He wants to advance real security. Preventing zone enumeration through DNSSEC records should not give the illusion that thereby you are preventing zone enumeration, just making it more difficult. If the goal is to make it more difficult, then that should be stated up front. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 10:05:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09607 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 10:05:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BrzsR-000LH3-9g for namedroppers-data@psg.com; Tue, 03 Aug 2004 14:02:51 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Brzs8-000LEB-L0 for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 14:02:32 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i73E2Urc000572; Tue, 3 Aug 2004 14:02:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i73E2UiP000569; Tue, 3 Aug 2004 14:02:30 GMT Date: Tue, 3 Aug 2004 14:02:30 +0000 From: bmanning@vacation.karoshi.com To: Stephane Bortzmeyer <bortzmeyer@nic.fr> Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Message-ID: <20040803140230.GA516@vacation.karoshi.com.> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040803130906.GA22126@nic.fr> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Olaf M. Kolkman <olaf@ripe.net> wrote > > This working group will need to get the requirements for making informed > > decisions on how to design NSEC++. Remember that Rip and Ben have > > volunteered to put such a list together. Please send your requirements > > to these to friendly volunteers. If you have a threat model in mind, > > please document and send to Ben & Rip. > > Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote > At the very least, DNSsec should not lower security and should not > make existing attacks (e.g. zone enumeration) easier. Here we enter semantic entanglements. You assert that zone enumeration is an attack on the DNS. I don't see it that way. Zone enumeration is simply a series of legitimate DNS queries. This is not a protocol problem. At some layer -above- the DNS some entity or entities wants to use data collected by/through legitimate DNS protocol transactions in a manner that is offensive to the authorized manager of a particular delegation. At least two problems here: ) this is not a DNS issue, per se ) it is not likely that a single "policy" wrt keeping data "private" will work. if this maddness continues, i expect that we will end up describing a policy grammer and language in addition to methods for enforcing same. but as usual, YMMV. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 10:15:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10985 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 10:15:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs00z-000MRH-Uw for namedroppers-data@psg.com; Tue, 03 Aug 2004 14:11:41 +0000 Received: from [192.134.4.10] (helo=mx1.nic.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs00h-000MPu-9D for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 14:11:23 +0000 Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id A6CE794021; Tue, 3 Aug 2004 16:11:22 +0200 (CEST) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 5DA939400F; Tue, 3 Aug 2004 16:11:21 +0200 (CEST) Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i73EBLjI1307311; Tue, 3 Aug 2004 16:11:21 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 304D1102C1; Tue, 3 Aug 2004 16:11:21 +0200 (CEST) Date: Tue, 3 Aug 2004 16:11:21 +0200 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: bmanning@vacation.karoshi.com Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Message-ID: <20040803141121.GA26712@nic.fr> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> <20040803140230.GA516@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040803140230.GA516@vacation.karoshi.com.> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new at mx1.nic.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Aug 03, 2004 at 02:02:30PM +0000, bmanning@vacation.karoshi.com <bmanning@vacation.karoshi.com> wrote a message of 32 lines which said: > ) it is not likely that a single "policy" wrt keeping data > "private" will work. Yes, it will. At the present time, a ccTLD which does not care about the access to its zone file allows AXFR or posts the zone file on a Web site or anonymous FTP server. A ccTLD which does care disallows AXFR. The ccTLD manager has a choice. The protocol (and implementations: I remember a time where BIND did not allow to disable AXFR) does not dictate a policy. With DNSsec 1, the protocol dictates the policy: you can no longer make zone enumeration difficult, should you wish so. > if this maddness continues, i expect that we will end up > describing a policy grammer and language in addition to methods for > enforcing same. It already exists :-) Caller-ID (rejected by the MARID WG but the current SPF-like language is quite complicated also). Or SAML (http://xml.coverpages.org/saml.html). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 10:28:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12148 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 10:28:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs0E2-000NpW-BO for namedroppers-data@psg.com; Tue, 03 Aug 2004 14:25:10 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs0Dr-000NmV-SO for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 14:24:59 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i73EOwrc000645; Tue, 3 Aug 2004 14:24:58 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i73EOv0x000642; Tue, 3 Aug 2004 14:24:58 GMT Date: Tue, 3 Aug 2004 14:24:57 +0000 From: bmanning@vacation.karoshi.com To: Stephane Bortzmeyer <bortzmeyer@nic.fr> Cc: bmanning@vacation.karoshi.com, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Message-ID: <20040803142457.GA625@vacation.karoshi.com.> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> <20040803140230.GA516@vacation.karoshi.com.> <20040803141121.GA26712@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040803141121.GA26712@nic.fr> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > if this maddness continues, i expect that we will end up > > describing a policy grammer and language in addition to methods for > > enforcing same. > > It already exists :-) Caller-ID (rejected by the MARID WG but the > current SPF-like language is quite complicated also). Or SAML > (http://xml.coverpages.org/saml.html). > those are -not- part of the DNS specification, nor have they been presented as such. I fear that the end game, IF this is determined to be a DNS protocol issue, will be extensions tothe protocol to support a robust policy language and access controls.... which will have the effect of fracturing the namespace. and we will end up - yet again - in the space where local optimizations irrepairably damage the global utility of the system. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 10:41:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12950 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 10:41:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs0Q9-000PFB-Rw for namedroppers-data@psg.com; Tue, 03 Aug 2004 14:37:41 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs0Pz-000PE8-7S for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 14:37:31 +0000 Received: from [192.168.0.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 3A3951FDCB; Tue, 3 Aug 2004 15:37:30 +0100 (BST) Date: Tue, 03 Aug 2004 15:36:51 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: bmanning@vacation.karoshi.com, Stephane Bortzmeyer <bortzmeyer@nic.fr> Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Message-ID: <0A8B1F3B2A6726236C54E339@[192.168.0.5]> In-Reply-To: <20040803140230.GA516@vacation.karoshi.com.> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> <20040803140230.GA516@vacation.karoshi.com.> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 August 2004 14:02 +0000 bmanning@vacation.karoshi.com wrote: > I don't see it that way. Zone enumeration is > simply a series of legitimate DNS queries. I am taking it you are using the word "legitimate" to mean "in conformance with the RFC" else you are rather begging the question. Putting in purely technical terms, zone enumeration may be a series of legitimate DNS queries, but it was not a possible series of legitimate DNS queries prior to DNSSEC. Effectively, DNSSEC allows a database to be searched by another key. For some DNS users, allowing searches by that key is undesirable. I don't believe that a change in the protocol layer should be the determinant of what keys can be used to query a database; that's a policy decision. Therefore retaining having an option to restrict search keys to the previous set seems a reasonable requirement upon a protocol 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 10:45:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13183 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 10:45:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs0Ud-000PnM-Vs for namedroppers-data@psg.com; Tue, 03 Aug 2004 14:42:19 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs0UD-000PjD-BY for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 14:41:53 +0000 Received: from [192.168.0.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id BD8DD1FDCB; Tue, 3 Aug 2004 15:41:52 +0100 (BST) Date: Tue, 03 Aug 2004 15:41:14 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: bmanning@vacation.karoshi.com, Stephane Bortzmeyer <bortzmeyer@nic.fr> Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Message-ID: <3A76255B449F76C90DCE51B4@[192.168.0.5]> In-Reply-To: <20040803142457.GA625@vacation.karoshi.com.> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> <20040803140230.GA516@vacation.karoshi.com.> <20040803141121.GA26712@nic.fr> <20040803142457.GA625@vacation.karoshi.com.> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 August 2004 14:24 +0000 bmanning@vacation.karoshi.com wrote: > a robust policy language and access controls.... > which will have the effect of fracturing the namespace. Noone is asking for more any degree of functionality more than is currently present in BIND et al. - I didn't notice that fracturing the namespace. Noone is asking for policy language and access controls in the protocol standard. They are merely asking for the protocol standard not to be constructed in such a manner that access controls similar to those in existing non-secure DNS applications are not impossible to implement in DNSSEC applications. What is more likely to fracture the namespace is if half the world deploys DNSSEC and half doesn't, which is what we are all (?) trying to avoid, I thought. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 10:51:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13476 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 10:51:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs0aN-0000Vu-Uf for namedroppers-data@psg.com; Tue, 03 Aug 2004 14:48:15 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs0aD-0000UI-Co for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 14:48:05 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i73Em1rc000718; Tue, 3 Aug 2004 14:48:01 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i73ElwrG000715; Tue, 3 Aug 2004 14:47:58 GMT Date: Tue, 3 Aug 2004 14:47:58 +0000 From: bmanning@vacation.karoshi.com To: Alex Bligh <alex@alex.org.uk> Cc: bmanning@vacation.karoshi.com, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Message-ID: <20040803144758.GA676@vacation.karoshi.com.> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> <20040803140230.GA516@vacation.karoshi.com.> <0A8B1F3B2A6726236C54E339@[192.168.0.5]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A8B1F3B2A6726236C54E339@[192.168.0.5]> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Aug 03, 2004 at 03:36:51PM +0100, Alex Bligh wrote: > --On 03 August 2004 14:02 +0000 bmanning@vacation.karoshi.com wrote: > > > I don't see it that way. Zone enumeration is > > simply a series of legitimate DNS queries. > > I am taking it you are using the word "legitimate" to mean "in > conformance with the RFC" else you are rather begging the question. yes... this is a discussion about the DNS protocol > Putting in purely technical terms, zone enumeration may be a series of > legitimate DNS queries, but it was not a possible series of legitimate DNS > queries prior to DNSSEC. again, we dance on the head of a pin. does enumeration infer a 100% complete and accurate listing of all the elements in a set? In my understanding, and based on previous threads, the answer is no. So i would characterise your statement above as misleading or even false. If my presumptions are wrong, then you might be correct. > Effectively, DNSSEC allows a database to be > searched by another key. For some DNS users, allowing searches by that key > is undesirable. I don't believe that a change in the protocol layer should > be the determinant of what keys can be used to query a database; that's a > policy decision. Therefore retaining having an option to restrict search > keys to the previous set seems a reasonable requirement upon a protocol > change. as may be. and that is the discussion underway. I remain convinced that the results of these discussions will cause more harm to the DNS - as a useful system - than good. > Alex --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 11:20:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15049 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 11:20:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs11C-0004Bx-Cg for namedroppers-data@psg.com; Tue, 03 Aug 2004 15:15:58 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs10t-0004Am-PQ for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 15:15:39 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i73FFXrc000784; Tue, 3 Aug 2004 15:15:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i73FFXMi000781; Tue, 3 Aug 2004 15:15:33 GMT Date: Tue, 3 Aug 2004 15:15:33 +0000 From: bmanning@vacation.karoshi.com To: Alex Bligh <alex@alex.org.uk> Cc: bmanning@vacation.karoshi.com, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Message-ID: <20040803151533.GB676@vacation.karoshi.com.> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> <20040803140230.GA516@vacation.karoshi.com.> <20040803141121.GA26712@nic.fr> <20040803142457.GA625@vacation.karoshi.com.> <3A76255B449F76C90DCE51B4@[192.168.0.5]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A76255B449F76C90DCE51B4@[192.168.0.5]> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Aug 03, 2004 at 03:41:14PM +0100, Alex Bligh wrote: > > > --On 03 August 2004 14:24 +0000 bmanning@vacation.karoshi.com wrote: > > > a robust policy language and access controls.... > > which will have the effect of fracturing the namespace. > > Noone is asking for more any degree of functionality more than is > currently present in BIND et al. - I didn't notice that fracturing the > namespace. thats not quite how I see it, and -recognizing BIND is an implementation of the DNS standard with its own, non-standard extentions- .... its already started... :) VIEWs delegation-only > Noone is asking for policy language and access controls in > the protocol standard. They are merely asking for the protocol standard > not to be constructed in such a manner that access controls similar to > those in existing non-secure DNS applications are not impossible to > implement in DNSSEC applications. not yet. they will -if- the DNS is asked to enforce policy. > What is more likely to fracture the namespace is if half the world > deploys DNSSEC and half doesn't, which is what we are all (?) trying > to avoid, I thought. don't think that the existance of a single tree with parts signed and parts not signed is a problem. DNSSEC designers did consider that possibility. :) but... this started out w/ my questioning the assertion that zone enumeration was an attack on the DNS. Nothing I've seen so far has swayed me to belive that zone enumeration is an attack on the DNS. todate, the emphasis is on the attacks launched using data collected through the DNS. protecting the DNS is one thing. preventing people from using the DNS to gather intel is something else. > > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 11:21:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15090 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 11:21:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs138-0004Nz-3T for namedroppers-data@psg.com; Tue, 03 Aug 2004 15:17:58 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs12x-0004Mw-AI for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 15:17:47 +0000 Received: from [192.168.0.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B1E271FDCB; Tue, 3 Aug 2004 16:17:46 +0100 (BST) Date: Tue, 03 Aug 2004 16:17:08 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: bmanning@vacation.karoshi.com Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Message-ID: <14CABD82940B553FC39C449F@[192.168.0.5]> In-Reply-To: <20040803144758.GA676@vacation.karoshi.com.> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> <20040803140230.GA516@vacation.karoshi.com.> <0A8B1F3B2A6726236C54E339@[192.168.0.5]> <20040803144758.GA676@vacation.karoshi.com.> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 August 2004 14:47 +0000 bmanning@vacation.karoshi.com wrote: >> Putting in purely technical terms, zone enumeration may be a series of >> legitimate DNS queries, but it was not a possible series of legitimate >> DNS queries prior to DNSSEC. > > again, we dance on the head of a pin. does enumeration infer a > 100% complete and accurate listing of all the elements in a set? > In my understanding, and based on previous threads, the answer > is no. So i would characterise your statement above as misleading > or even false. If my presumptions are wrong, then you might be > correct. Sorry - I meant the PROTOCOL used to allow applications to prevent enumeration USING ONLY PROTOCOL QUERIES, but DNSSEC as-is removes that ability to prevent enumeration. I think that's uncontentious? The argument as to whether a partial enumeration can be gained through other mechanisms (google, nameserver logs, tendancies to list the similar data in inaddr.arpa, whatever) and the difficulty thereof is a separate question. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 11:26:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15372 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 11:26:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs18K-0004vP-JC for namedroppers-data@psg.com; Tue, 03 Aug 2004 15:23:20 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs189-0004uE-Ri for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 15:23:10 +0000 Received: from [192.168.0.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 3F7161FDCB; Tue, 3 Aug 2004 16:23:09 +0100 (BST) Date: Tue, 03 Aug 2004 16:22:31 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: bmanning@vacation.karoshi.com Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Message-ID: <D3DEE6643E954185C05D9302@[192.168.0.5]> In-Reply-To: <20040803151533.GB676@vacation.karoshi.com.> References: <17057.1091131070@gromit.rfc1035.com> <3D96637F4022B14BE90F2D9E@[192.168.100.27]> <4109DA5D.5040706@ripe.net> <20040803130906.GA22126@nic.fr> <20040803140230.GA516@vacation.karoshi.com.> <20040803141121.GA26712@nic.fr> <20040803142457.GA625@vacation.karoshi.com.> <3A76255B449F76C90DCE51B4@[192.168.0.5]> <20040803151533.GB676@vacation.karoshi.com.> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 August 2004 15:15 +0000 bmanning@vacation.karoshi.com wrote: >> Noone is asking for policy language and access controls in >> the protocol standard. They are merely asking for the protocol standard >> not to be constructed in such a manner that access controls similar to >> those in existing non-secure DNS applications are not impossible to >> implement in DNSSEC applications. > > not yet. they will -if- the DNS is asked to enforce > policy. Don't understand. Are you suggesting it's the same "they" in your sentence as mine? If so, what makes you think those people (presumably including Nominet) will want policy language and access controls in the standard? If they need to be put anywhere, I'd suggest the application. I'm either totally missing your point or this is just FUD. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 12:49:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20652 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 12:49:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs2Ps-000ETD-8r for namedroppers-data@psg.com; Tue, 03 Aug 2004 16:45:32 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs2Pf-000ERq-Ho for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 16:45:19 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id i73GjDds027036; Tue, 3 Aug 2004 09:45:14 -0700 Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <P72MWY3V>; Tue, 3 Aug 2004 09:45:13 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA00@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Danny Mayer'" <mayer@gis.net>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Subject: RE: whois and zone enumeration Date: Tue, 3 Aug 2004 09:45:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I stand by my original statements. Paul is repeating a dogma he does not understand to make an argument that is false. the nsa requested this particular feature five years ago. It made sense then it does now. The split dns model is not sufficient for serious security needs. My clients are concerned about internal threats as well as external. In the age of mydoom the split dns solution is a weak one. In the age of web services and deperimeterization it is nonsense. -----Original Message----- From: Danny Mayer [mailto:mayer@gis.net] Sent: Tue Aug 03 06:53:43 2004 To: Hallam-Baker, Phillip; namedroppers@ops.ietf.org Subject: RE: whois and zone enumeration At 10:53 PM 8/2/2004, Hallam-Baker, Phillip wrote: > > what we have here is a divergence of vision. security is not > > obscurity, and obscurity is not an intended feature of either > > "dns classic" or any extension ever made to dns. > >As a security professional who is engaged as such I can assure >you that it is a very bad idea to remove security controls >from an existing system unless you understand their effect. I agree with Paul. He is not advocating the removal of anything. He's saying that depending on obscurity for security is no security at all. >The fact that a control is unintended or is rejected on >ideological grounds does not mean that it can be dispensed >with. I am currently dealling with the consequences of >an industry abandoning certain controls that were present >in the ATM systems but are not present on the Internet. >As a result I spend a great deal of time talking to >law enforcement. You misread his statement. >Removing imperfect security controls without replacing them >is one of the main ways that security protocols fail in >practice. Where did he advocate removing imperfect security controls? >The common sense ideas that preceded the dogmas are still >generally accepted. But you are advancing a dogmatic interpretation >that is rejected by the field. It certainly has no place in a >security design argument. He's not advancing any dogma. He wants to advance real security. Preventing zone enumeration through DNSSEC records should not give the illusion that thereby you are preventing zone enumeration, just making it more difficult. If the goal is to make it more difficult, then that should be stated up front. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 13:10:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22438 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 13:10:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs2ke-000HpQ-Gu for namedroppers-data@psg.com; Tue, 03 Aug 2004 17:07:00 +0000 Received: from [140.239.227.17] (helo=portal.hamachi.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs2kT-000Ho1-JJ for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 17:06:49 +0000 Received: from portal (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id C4FD717921; Tue, 3 Aug 2004 13:06:48 -0400 (EDT) From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> To: Alex Bligh <alex@alex.org.uk> Cc: bmanning@vacation.karoshi.com, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Tue, 03 Aug 2004 15:41:14 BST." <3A76255B449F76C90DCE51B4@[192.168.0.5]> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 03 Aug 2004 13:06:48 -0400 Message-Id: <20040803170648.C4FD717921@portal.hamachi.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Noone is asking for more any degree of functionality more than is > currently present in BIND et al. The current functionality is, at best, an implementation artifact. We need a clear spec for "how good" any anti-enumeration defenses need to be, in order to avoid wasted effort on a solution which is later ruled not good enough. Given the existence of other mechanisms for partial enumeration, "as good as possible" is a frustrating non-starter. At several different zone sizes, what fraction of the zone must be protected from disclosure? If a partial zone enumeration contains 90% "chaff" entries, is it still considered a successful attack? How about 99%? 99.99%? Is an enumeration which takes months or years (of a zone which is changing on a daily or hourly basis) worth worrying about? - 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 13:36:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24935 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 13:36:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs387-000KPp-S2 for namedroppers-data@psg.com; Tue, 03 Aug 2004 17:31:15 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs37x-000KNb-79 for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 17:31:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i73HSH6E010038 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 13:28:17 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZVa4Kt; Tue, 3 Aug 04 13:28:14 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i73HTcR2024957; Tue, 3 Aug 2004 13:29:40 -0400 (EDT) Date: Tue, 3 Aug 2004 13:29:37 -0400 (EDT) From: Samuel Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: Jelte Jansen <jelte@NLnetLabs.nl> cc: namedroppers@ops.ietf.org Subject: Re: NSECX proposals In-Reply-To: <410EBC46.1000404@NLnetLabs.nl> Message-ID: <Pine.GSO.4.55.0408022255090.19117@filbert> References: <410EBC46.1000404@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > do the drafts describing possible NSEC replacements or the > requirements/transitions documents say anything about how much (or > maybe just if) these proposals add to the complexity of maintaining > zones (for example does it make it harder to change anything, or is > incremental signing still possible)? Without commenting on what the drafts presently say (esp. since they're likely to be revised soon), and with the caveat that the doc editors know their docs better than I... The NSEC2/3 proposals do NOT appear to add complexity. Incremental signing is still possible. Adding names is just as easy[1,2]. Deleting names is just as easy[2]. They could add computational load (esp. with multiple hash iterations, as NSEC2 proposes), but no particular complexity. -- Sam [1] Unless you find a hash collision. There are signifigant differences of opinion about whether we need to worry about hash collisions at all. [2] Except that, with NSEC2, you need to check for the creation of empty non-terminals and create EXIST RRs at those names. This doesn't seem very painful. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 13:52:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26621 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 13:52:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3Nx-000MDg-Ni for namedroppers-data@psg.com; Tue, 03 Aug 2004 17:47:37 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3Nm-000MBY-QK for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 17:47:26 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id C2C4919B8BE; Tue, 3 Aug 2004 13:36:53 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 2538419B3D1; Tue, 3 Aug 2004 13:36:53 -0400 (EDT) Received: from [10.0.2.5] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 72B4FCF394; Tue, 3 Aug 2004 13:46:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602040cbd357666a386@[10.0.2.5]> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEA00@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BEA00@mou1wnexm05.vcorp.ad.vrsn.com> Date: Tue, 3 Aug 2004 10:40:18 -0700 To: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> From: Edward Lewis <edlewis@arin.net> Subject: NXT design choices Cc: ed@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (If I've missed "choices" let me know - I'll update this with any new material.) In an effort to move the discussion away from the reasons why zone enumeration is a problem and the reasons why zone enumeration is not a problem, I'd like to review the design decisions behind the original NXT record. To provide authenticated denial, the first choice made is whether to: 1) Sign a tailored response to the query you are saying No to 2) Pre-compute all of the responses you will give out Choice 1 was ditched because this meant that we needed on-line keys. In the early days of DNSSEC (DNSSEC WG) the emphasis was more security minded than operations minded, the thought of on-line keys was abhorrent. (It seems like this may be coming back in vogue. But the concerns I have are the transfer of the secret material between servers and the role of encrypting it. Back in the first DNSSEC implementations, crypto export controls and patents combined to discourage encryption. This is one reason why BIND's dnssec-keygen leaves the private key file in plaintext. I'm not up to date on crypto-business, so maybe the old concerns are out moded.) Choice 2 breaks down into: 2a) Send one message to deny data in the zone 2b) Send fine-grained messages Choice 2a is basically what we have pre-DNSSEC - sending the SOA (now an option). This was ditched because of the threat of replay attacks. Someone could replay the one negative answer to all queries against the zone and make it "disappear." This replay vulnerability (because DNS does not do time) is the killer here. But, zone enumeration and sorting is not a problem. (Choice 2a won't fly with the DS record either.) Choice 2b requires that the sender reveal to the client what exists at the sender so that the client can deduce it's a negative answer. There are two ways to do this 2b1) Reveal what exists in plaintext 2b2) Reveal what exists in a one-way mapping (hash of names) Both choices assume that the server orders the relevant data in the same way the client would - allowing the client to say "if there's an A followed by a C, and I want B, B doesn't exist because it would be between A and C." Choice 2b1 has the cost of 1) requiring that the server store all names in a canonical order and it makes getting the names in the zone easy (zone enumeration). This choice also has impacts on largely delegated zones with sparse secured delegations (like .com). Choice 2b2 has the cost of creating a new name space (the mapped-onto names), as well as having the same burden on zones like .com. Choice 2b2 has been discarded because the community was happy with the costs of choice 2b1 - not because choice 2b1 was optimal. Choice 2b1 has some variants. One is what NSEC does now, that is reveal the span between all names. The "white lies" proposal is a variant, in which the span is segmented to make it seem like there are more names in the zone, combining this with barriers to asking for NSEC's directly. I personally don't think it's a matter of how important or why zone enumeration is a problem/distasteful. Zone enumeration is not and has never been a desired feature of DNSSEC. It was ignorable by the original designers, so it persists. Looking back - a big cost is the sorting of the data in the authoritative server. "We've" "paid" that by developing BIND 9. (Is BIND 9's perceived slowness a result of storing data in sorted order?) Defending NSEC as it is now is not defending an optimal solution. 2b1 is the least offensive solution, or it was at one time. Today we have Choice 2b1. If we want to avoid zone enumeration, we'll have to give something else up, what will that be? On-line keys? Replay defense? Muddled name space? Even if we combine 2b1 with on-line keys - we need to break an old assumption (no keys on-line). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 13:59:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27301 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 13:59:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3W0-000NRE-SS for namedroppers-data@psg.com; Tue, 03 Aug 2004 17:55:56 +0000 Received: from [192.215.81.75] (helo=relay2.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3Vq-000NPw-6u for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 17:55:46 +0000 Received: from tiger.ben.algroup.co.uk (0127ahost106.starwoodbroadband.com [12.105.246.106]) by relay2.san1.attens.com (8.11.6/8.9.3) with ESMTP id i73Htj019337 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 17:55:45 GMT Received: from [127.0.0.1] (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i73InTYc002326; Tue, 3 Aug 2004 19:49:30 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <410FDE39.9080706@algroup.co.uk> Date: Tue, 03 Aug 2004 19:49:29 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040628 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jelte Jansen <jelte@NLnetLabs.nl> CC: namedroppers@ops.ietf.org Subject: Re: NSECX proposals References: <410EBC46.1000404@NLnetLabs.nl> In-Reply-To: <410EBC46.1000404@NLnetLabs.nl> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jelte Jansen wrote: > Hi, > > do the drafts describing possible NSEC replacements or the > requirements/transitions documents say anything about how much (or maybe > just if) these proposals add to the complexity of maintaining zones (for > example does it make it harder to change anything, or is incremental > signing still possible)? If DNSSEC acceptance is an argument for > proposing other NSEC schemes, i think that maintainability is a huge > factor. Changing the salt will cause you to have to resign all NSEC++ records, but other than that, zone maintenance is roughly the same as NSEC. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 14:04:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27663 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 14:04:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3aL-000O8k-3B for namedroppers-data@psg.com; Tue, 03 Aug 2004 18:00:25 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3Zm-000O0F-7a for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 17:59:50 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i73Hxi30038132 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 13:59:45 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i73Hxiu2038131 for namedroppers@ops.ietf.org; Tue, 3 Aug 2004 13:59:44 -0400 (EDT) (envelope-from namedroppers) Received: from [128.220.13.50] (helo=blaze.cs.jhu.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrzqA-000KyY-Rk for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 14:00:31 +0000 Received: from pelican.cs.jhu.edu (pelican.cs.jhu.edu [128.220.13.57]) by blaze.cs.jhu.edu (8.12.9/8.12.9) with ESMTP id i73E0TuU007412 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 10:00:29 -0400 (EDT) Received: from localhost (crix@localhost) by pelican.cs.jhu.edu (8.11.1/8.11.1) with ESMTP id i73Dx1b04250 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 09:59:02 -0400 (EDT) Date: Tue, 3 Aug 2004 09:59:01 -0400 (EDT) From: Reza Curtmola <crix@cs.jhu.edu> To: <namedroppers@ops.ietf.org> Subject: NXT - authenticated non-existence - design questions Message-ID: <Pine.GSO.4.33.0408030957480.4228-100000@pelican.cs.jhu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] I have posted first on the bind-users mailing lists, but was advised to ask it in namedroppers, since this is where the experts in the area hang out, so here it goes: I am wondering about the design considerations for choosing the NXT record to provide authenticated non-existence, as part of the DNSSEC security extensions (I know, NXT has been changed to NSEC). There are several reasons why this was preferred versus just returning a signed negative answer. Some of these reasons include: 1) too expensive to generate a public-key signature on the spot (also the signing key would have to be online) 2) possibility of a replay attack: if an attacker asks for www.domain.com, and gets back a signed negative answer (that www.domain.com does not exist), then the attacker could later use this signed answer, as long as the signature hasn't expired yet, even if the name www.domain.com has been added meanwhile. I have two questions: 1) Isn't it possible to use the same replay attack also when a NXT record is used? The attacker can return an older NXT record, with a corresponding SIG record which is still valid. This old NXT record might not reflect the new configuration, where www.domain.com had been added meanwhile. 2) what are other reasons why the NXT record was chosen versus simply returning a signed negative answer? Thank you, -Reza -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 14:30:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29871 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 14:30:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs3xG-00016i-TW for namedroppers-data@psg.com; Tue, 03 Aug 2004 18:24:06 +0000 Received: from [192.215.81.75] (helo=relay2.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs3x6-000160-5B for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 18:23:56 +0000 Received: from tiger.ben.algroup.co.uk (0127ahost106.starwoodbroadband.com [12.105.246.106]) by relay2.san1.attens.com (8.11.6/8.9.3) with ESMTP id i73INt003354 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 18:23:55 GMT Received: from [127.0.0.1] (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i73JI9Yc002384 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 20:18:10 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <410FE4F1.9020706@algroup.co.uk> Date: Tue, 03 Aug 2004 20:18:09 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040628 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Updated requirements X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit An updated version of the nonexistence requirements is available: http://www.links.org/dnssec/draft-ietf-dnsext-signed-nonexistence-requirements-00pre1.html http://www.links.org/dnssec/draft-ietf-dnsext-signed-nonexistence-requirements-00pre1.txt Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 15:16:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04791 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 15:16:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs4j0-00079O-II for namedroppers-data@psg.com; Tue, 03 Aug 2004 19:13:26 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs4iR-00074p-O6 for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 19:12:51 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1Bs4iQ-0007cC-Sq; Tue, 03 Aug 2004 21:12:50 +0200 In-Reply-To: <20040802230305.GA23395@atoom.net> To: Miek Gieben <miekg@atoom.net> Cc: namedroppers <namedroppers@ops.ietf.org> Subject: Re: whois and zone enumeration MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic <sanz@denic.de> Message-ID: <OF812391DD.DAD97138-ONC1256EE5.00694322-C1256EE5.00698875@notes.denic.de> Date: Tue, 3 Aug 2004 21:12:42 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 03.08.2004 21:12:50, Serialize complete at 03.08.2004 21:12:50 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Miek, > I've a simple question. If a TLD would shutdown their whois service, > would zone enumeration then still be a problem? As I said in http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00472.html fixing (or shutting down ;-) whois will remove whois from the examples, but won't dispatch the traversal problem for us. Best, Marcos -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 15:19:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05031 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 15:19:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs4mO-0007he-KX for namedroppers-data@psg.com; Tue, 03 Aug 2004 19:16:56 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs4mE-0007g0-59 for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 19:16:46 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E2A6313DF0 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 19:16:45 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Subject: Re: NXT design choices In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Tue, 03 Aug 2004 10:40:18 MST." <a0602040cbd357666a386@[10.0.2.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 03 Aug 2004 19:16:45 +0000 Message-Id: <20040803191645.E2A6313DF0@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > (Is BIND 9's perceived slowness a result of storing data in sorted order?) somewhat. it makes loading slower. once loaded, the queries-per-second limitation is caused by things other than security ordering. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 15:49:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06817 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 15:49:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5CT-000BEI-VD for namedroppers-data@psg.com; Tue, 03 Aug 2004 19:43:53 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5CB-000BCx-DM for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 19:43:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0313413E00 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 19:43:35 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Tue, 03 Aug 2004 10:15:44 +0100." <336DEA1A50C9BCD9263BFAFD@[192.168.100.27]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 03 Aug 2004 19:43:35 +0000 Message-Id: <20040803194335.0313413E00@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So while discovering "some" names from a larger zone is going to be easy, > discovering a substantial large percentage of that zone I would suggest > becomes harder at a rate more than linearly related to the size of the > zone. that's a fine suggestion but dataminers are way smarter than you're giving them credit for. they know how to craft dictionary attacks based on actual name allocation patterns, and they know these patterns are language specific, and they aren't just going to be looking for english words, or native-language words, or combinations of words, or mutations of words. with respect, i'd be a lot more interested in reading about attacks and measured success rates than theoretical predictions, and i'd rather hear about this from others who have been involved in preventing network abuse (datamining, spamming, phishing, etc) for a decade or longer. in other words, trivializing the attackers in order to justify a trivial (but expensive and universal) defense is not the way to win me over. i am particularly struck by the fact that registrants are being held hostage to the concerns of their registries and registrars. domainholders don't want their domainnames kept secret -- they are intended to be made visible. the problems of enumeration are felt by registries and registrars, and the desire of registrants to use dnssec in their own zones are not being given any weight in this debate. small zones are not just hard to enumerate because there's less name-density; they are also harder to enumerate because there are so many of them -- tens of millions of times more of them -- than there are large zones. and the payback for an attacker is much lower. (they can probably just guess "www".) in other words, we're debating whether to add technology to defend against a trivial attack that will only be launched against a small number of zones (the large registry-based ones) but incurring implementation and deployment costs (complexity, time, perhaps money), while the actual nontrivial attacks continue to be "successful enough" to justify their continuation. this is just crazy. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 15:53:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07066 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 15:53:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5I3-000Bsq-LI for namedroppers-data@psg.com; Tue, 03 Aug 2004 19:49:39 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5Hl-000Br9-6a for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 19:49:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EA4F013DF7 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 19:49:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Stephane Bortzmeyer <bortzmeyer@nic.fr> of "Tue, 03 Aug 2004 15:09:06 +0200." <20040803130906.GA22126@nic.fr> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 03 Aug 2004 19:49:20 +0000 Message-Id: <20040803194920.EA4F013DF7@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At the very least, DNSsec should not lower security and should not > make existing attacks (e.g. zone enumeration) easier. i just grepped rfc1034 and rfc1035, and rfc2181, and found no indication that the internet standards community has ever considered the possibility that obscurity was a feature of dns. knowing what i know about the iab, i don't think they'd support this as a feature-goal. but it's worth asking them. arguments of the form "the nonstandard bind hack whereby a certain protocol feature was protected by an ACL no longer has any effect if DNSSEC is deployed" are at worst bizarre and at best nonsequitur. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 15:59:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07478 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 15:59:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5OC-000CwF-2y for namedroppers-data@psg.com; Tue, 03 Aug 2004 19:56:00 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5Nd-000CrU-6M for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 19:55:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E0C3F13DF0 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 19:55:24 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Tue, 03 Aug 2004 15:41:14 +0100." <3A76255B449F76C90DCE51B4@[192.168.0.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 03 Aug 2004 19:55:24 +0000 Message-Id: <20040803195524.E0C3F13DF0@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > What is more likely to fracture the namespace is if half the world > deploys DNSSEC and half doesn't, which is what we are all (?) trying > to avoid, I thought. the longer this debate goes on, the happier i am that something like DLV exists. domainholders want dns security and don't (for the most part) care about enumeration since they can use split-dns or just live safe with the knowledge that their zones are too numerous and too sparse to be worth a dictionary attack. registry operators are very concerned about enumeration, for operational or business (or both) reasons. without something like DLV, i'm convinced that the part of the world who would have the ability to deploy DNSSEC is far smaller than half of it. with something like DLV, i'm convinced that the half of the world who implements DNSSEC will incentivise the other half to get with the programme, "somehow." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 16:07:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08020 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 16:07:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5Ve-000EM8-SQ for namedroppers-data@psg.com; Tue, 03 Aug 2004 20:03:42 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5VM-000EIT-7L for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 20:03:24 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 70F161FDCB; Tue, 3 Aug 2004 21:03:23 +0100 (BST) Date: Tue, 03 Aug 2004 21:03:20 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Edward Lewis <edlewis@arin.net>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Cc: ed@arin.net, Alex Bligh <alex@alex.org.uk> Subject: Re: NXT design choices Message-ID: <EACE981B88D258DE21241A07@[192.168.100.27]> In-Reply-To: <a0602040cbd357666a386@[10.0.2.5]> References: <C6DDA43B91BFDA49AA2F1E473732113E010BEA00@mou1wnexm05.vcorp.ad.v rsn.com> <a0602040cbd357666a386@[10.0.2.5]> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 August 2004 10:40 -0700 Edward Lewis <edlewis@arin.net> wrote: > Choice 2b2 has been discarded because the community was happy with the > costs of choice 2b1 - not because choice 2b1 was optimal. I agree > I personally don't think it's a matter of how important or why zone > enumeration is a problem/distasteful. Zone enumeration is not and has > never been a desired feature of DNSSEC. It was ignorable by the original > designers, so it persists. Looking back - a big cost is the sorting of > the data in the authoritative server. "We've" "paid" that by developing > BIND 9. (Is BIND 9's perceived slowness a result of storing data in > sorted order?) Interesting: Given Ben has done some work (no idea how far he has got) on proof-of-concept NSEC2 in Bind, do we have real-world code that would tell us what the cost 2b2 over 2b1 is? (albeit non-optimized, and on one platform)? 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 16:08:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08097 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 16:08:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5XP-000ElW-3P for namedroppers-data@psg.com; Tue, 03 Aug 2004 20:05:31 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5XE-000Eix-Gg for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 20:05:20 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id AF9CF1FDCB; Tue, 3 Aug 2004 21:05:19 +0100 (BST) Date: Tue, 03 Aug 2004 21:05:16 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: What I mumbled at the mike today... Message-ID: <1204054DEA31C51171828466@[192.168.100.27]> In-Reply-To: <20040803194335.0313413E00@sa.vix.com> References: <20040803194335.0313413E00@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 August 2004 19:43 +0000 Paul Vixie <paul@vix.com> wrote: > i am particularly struck by the fact that registrants are being held > hostage to the concerns of their registries and registrars. domainholders > don't want their domainnames kept secret -- they are intended to be made > visible. This is just not true (based on what we hear from registrants). If you run a domain for email only, you do NOT want everyone and their dog to know how to send you email, because they will. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 16:17:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08599 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 16:16:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5dx-000G5B-O9 for namedroppers-data@psg.com; Tue, 03 Aug 2004 20:12:17 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5df-000G2T-7Y for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 20:11:59 +0000 Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i73KBwN32362 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 13:11:58 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i73KBqIQ015579 for namedroppers@ops.ietf.org; Tue, 3 Aug 2004 13:11:52 -0700 Date: Tue, 3 Aug 2004 13:11:52 -0700 From: kent@songbird.com To: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... Message-ID: <20040803201152.GL16208@raven.songbird.com> Mail-Followup-To: namedroppers@ops.ietf.org References: <336DEA1A50C9BCD9263BFAFD@[192.168.100.27]> <20040803194335.0313413E00@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040803194335.0313413E00@sa.vix.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Aug 03, 2004 at 07:43:35PM +0000, Paul Vixie wrote: [...] > i am particularly struck by the fact that registrants are being held > hostage to the concerns of their registries and registrars. domainholders > don't want their domainnames kept secret -- they are intended to be made > visible. the problems of enumeration are felt by registries and registrars, > and the desire of registrants to use dnssec in their own zones are not > being given any weight in this debate. Realizing the weakness of the methodology, I did a bit more systematic analysis of the domains in use on this list. I pulled 143 domains from my recent archive of the namedroppers list, and checked one nameserver for each of the zones to see if axfr was allowed. Of the 143 nameservers, 51 allow zone transfer, and 92 do not. That is, at least from this sample, your assertion is incorrect -- the evidence suggests that the majority of clueful registrants prefer NOT to make their full zones visible. > small zones are not just hard to enumerate because there's less name-density; > they are also harder to enumerate because there are so many of them -- tens > of millions of times more of them -- than there are large zones. and the > payback for an attacker is much lower. (they can probably just guess "www".) But with easy enumeration, enumerating small zones becomes trivial, and therefor mass enumeration of their millions of zones becomes quite doable. > in other words, we're debating whether to add technology to defend against > a trivial attack that will only be launched against a small number of zones > (the large registry-based ones) The attack will not be only against large zones, it will also be against small zones. -- Kent Crispin kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 16:30:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09466 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 16:30:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5rA-000HrK-Ac for namedroppers-data@psg.com; Tue, 03 Aug 2004 20:25:56 +0000 Received: from [205.150.200.161] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5qz-000HqR-1C for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 20:25:45 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i73KPeA25754 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 3 Aug 2004 16:25:41 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i73KVHs02605 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Tue, 3 Aug 2004 16:31:23 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i73KO04F023399 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 Aug 2004 16:24:00 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i73KNxYH023396; Tue, 3 Aug 2004 16:24:00 -0400 To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... In-Reply-To: Message from Paul Vixie <paul@vix.com> of "Tue, 03 Aug 2004 19:43:35 -0000." <20040803194335.0313413E00@sa.vix.com> References: <20040803194335.0313413E00@sa.vix.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Aug 2004 16:23:59 -0400 Message-ID: <23395.1091564639@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Vixie <paul@vix.com> writes: Paul> in other words, we're debating whether to add technology to Paul> defend against a trivial attack that will only be launched Paul> against a small number of zones (the large registry-based Paul> ones) but incurring implementation and deployment costs Paul> (complexity, time, perhaps money), while the actual nontrivial Paul> attacks continue to be "successful enough" to justify their Paul> continuation. Paul> this is just crazy. What he said. (looking for WG session discussion summary) - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQQ/0XoqHRg3pndX9AQGSJwQAkaxYYBgOIEviBJMv50pUNoze73cQMyYu 4aAEnz70KjIeuVlP7suNmWgd6sKE3SqZx1bV9FYyMsEaOqJWzADsUWUiSRLKFV4i xFOTNdlqrArs3f6+YnnkdFxZCbbzmDqRADxw2QgGKMjVsksiG6M60U7EHNvOk1VV henXeKtOGjA= =7BED -----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 16:32:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09592 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 16:32:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5u5-000I96-DC for namedroppers-data@psg.com; Tue, 03 Aug 2004 20:28:57 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5tu-000I8O-2O for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 20:28:46 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i73KSfqJ025707; Tue, 3 Aug 2004 21:28:41 +0100 (BST) To: Alex Bligh <alex@alex.org.uk> cc: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Tue, 03 Aug 2004 21:05:16 BST." <1204054DEA31C51171828466@[192.168.100.27]> Date: Tue, 03 Aug 2004 21:28:41 +0100 Message-ID: <25706.1091564921@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Alex" == Alex Bligh <alex@alex.org.uk> writes: Alex> This is just not true (based on what we hear from Alex> registrants). If you run a domain for email only, you do NOT Alex> want everyone and their dog to know how to send you email, Alex> because they will. I don't understand this logic or the flawed user expectations behind it. Everyone and his dog will soon find out how to send these people email, with or without zone enumeration. Whether it's done by NSEC walking or some other method. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 16:33:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09716 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 16:33:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs5v5-000IG8-HU for namedroppers-data@psg.com; Tue, 03 Aug 2004 20:29:59 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs5uu-000IEU-Si for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 20:29:48 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9B6B113DF7 for <namedroppers@ops.ietf.org>; Tue, 3 Aug 2004 20:29:48 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... In-Reply-To: Message from kent@songbird.com of "Tue, 03 Aug 2004 13:11:52 MST." <20040803201152.GL16208@raven.songbird.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 03 Aug 2004 20:29:48 +0000 Message-Id: <20040803202948.9B6B113DF7@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Realizing the weakness of the methodology, I did a bit more systematic > analysis of the domains in use on this list. I pulled 143 domains > from my recent archive of the namedroppers list, and checked one > nameserver for each of the zones to see if axfr was allowed. Of the > 143 nameservers, 51 allow zone transfer, and 92 do not. > > That is, at least from this sample, your assertion is incorrect -- the > evidence suggests that the majority of clueful registrants prefer NOT > to make their full zones visible. i still do a fair bit of bind support and nameservice design consulting, and i draw the opposite conclusion -- most people are knee-jerk about this and have a "be as closed as possible" attitude, just as with inetd.conf, but are not specifically concerned about zone data visibility. the ones who are concerned about zone data visibility -- who you call "clueful" -- are running split dns. > But with easy enumeration, enumerating small zones becomes trivial, > and therefor mass enumeration of their millions of zones becomes quite > doable. what's the payback from learning the names of internal dns-named resources? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 16:49:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10893 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 16:49:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs6A4-000KF8-OO for namedroppers-data@psg.com; Tue, 03 Aug 2004 20:45:28 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs69t-000KCu-Lb for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 20:45:17 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Tue, 3 Aug 2004 16:45:08 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004080316450810238 ; Tue, 03 Aug 2004 16:45:08 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <PZ0YDF92>; Tue, 3 Aug 2004 16:45:08 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE105223@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> To: "'Edward Lewis'" <edlewis@arin.net>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Subject: RE: NXT design choices Date: Tue, 3 Aug 2004 16:42:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Halloo Ed-- > To provide authenticated denial, the first choice made is whether to: > > 1) Sign a tailored response to the query you are saying No to > 2) Pre-compute all of the responses you will give out > > Choice 1 was ditched because this meant that we needed on-line keys. > In the early days of DNSSEC (DNSSEC WG) the emphasis was more > security minded than operations minded, the thought of on-line keys > was abhorrent. Choice one was ditched for more reasons, because not only were on-line keys needed but the signing of a tailored response needed to be done in real time. It may be less significant an issue now, but at the time the extra CPU cycles spent for "real time" crypto as compared to "pre-computed" crypto were a major concern. > (It seems like this on line storage of keys? (since your "this" isn't a clear reference) > may be coming back in vogue. But the concerns I > have are the transfer of the secret material between servers and the > role of encrypting it. Back in the first DNSSEC implementations, > crypto export controls and patents combined to discourage encryption. > This is one reason why BIND's dnssec-keygen leaves the private key > file in plaintext. I'm not up to date on crypto-business, so maybe > the old concerns are out moded.) There are a much longer list of issues and concerns that need to be expressed somewhere, some of which are unrelated to the NXT/NSEC design choices (but I'm throwing 'em in anyway): - For zones that want to allow dynamic update of a signed zone, at least the master (or stealth master) server must have a zone-signing key available. With several common usages of SRV records and/or DHCP, I see dynamic updates of signed zones to be extraordinarily likely. - For methods of authenticated denial that involve "real time" crypto, *all* authoritative servers must each have at least one zone-signing key available. That makes life much harder to deal with securely than the dynamic update case above. - Hardware crypto devices may be able to provide both acceptable secure storage and speed (CPU) improvements to allow realistic signing of both zone data and authenticated denial responses in real time. - From my viewpoint, the organizations which are most concerned about zone-enumeration-through-NSEC are also those best able to afford a hardware crypto device to assist with things. - The fact that a hardware crypto device might be useful (and that a DNSSEC-TNG designed around them might be far superior to the current design) does not mean either that further delays in fielding DNSSECbis are acceptable, or that the current DNSSECbis design is broken. [...] > Choice 2b2 has been discarded because the community was happy with > the costs of choice 2b1 - not because choice 2b1 was optimal. Well, I would describe it as "the community accepted the costs of..." since I don't think happy was the best adjective to describe things. [...] > I personally don't think it's a matter of how important or why zone > enumeration is a problem/distasteful. Zone enumeration is not and > has never been a desired feature of DNSSEC. It was ignorable by the > original designers, so it persists. I agree with your statement above about zone enumeration. At the same time, I agree with Paul and others who point out that obscurity of DNS data has never been a designed-in feature of DNS (although it may have been and may remain a desired feature.) [...] > Today we have Choice 2b1. If we want to avoid zone enumeration, > we'll have to give something else up, what will that be? On-line > keys? Replay defense? Muddled name space? Even if we combine 2b1 > with on-line keys - we need to break an old assumption (no keys > on-line). I think that there are solutions that address perceived issues with zone enumeration without requiring on-line keys. If we can find a method that meets "enough" of the requirements and desirements, then I believe it's probably worth doing--but if it requires on-line keys on all the authoritative servers for a zone for real-time crypto then I believe it doesn't meet at least one of *my* requirements. I guess I'd better get with my esteemed co-editor and get that added to the initial requirement/desirement list. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 17:01:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11584 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 17:01:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs6Ll-000MAI-3q for namedroppers-data@psg.com; Tue, 03 Aug 2004 20:57:33 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs6La-000M8H-CW for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 20:57:22 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i73KvMrc001616; Tue, 3 Aug 2004 20:57:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i73KvL6j001613; Tue, 3 Aug 2004 20:57:21 GMT Date: Tue, 3 Aug 2004 20:57:21 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie <paul@vix.com> Cc: namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Message-ID: <20040803205721.GA1530@vacation.karoshi.com.> References: <3A76255B449F76C90DCE51B4@[192.168.0.5]> <20040803195524.E0C3F13DF0@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040803195524.E0C3F13DF0@sa.vix.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i was asked to make some sort of comment wrt DLV in public and this seems like as good an opening as any. Like Paul, I am happy that DLV exists, is documented in some, albeit currently restrictive, forms. His rational and mine are perhaps polar opposites. I am all in favor of interesting and novel ideas being developed, documented, and perhaps even being implemented as/in proof of concept ways. The business case(s) for deploying stop-gap techniques always seem compelling and are almost always more costly in the long run. Actually putting a DLV registry into play requires someone to be convinced that the costs for doing so will be (nominally) recovered as a bare minimum. Many/Most orgs tend to have minimum ROI targets on investment. So while public benefit is a fine platitude (and in some cases is much more than that), I think that if we (as DNSSEC potential users) are pushed/prodded into depending on DLV deployment, we are going to have a much longer transition cycle with attendent cost/confusion/troubleshooting as the tradeoff for "rapid" start times for signed/validating zones. as usual, YMMV. --bill On Tue, Aug 03, 2004 at 07:55:24PM +0000, Paul Vixie wrote: > > What is more likely to fracture the namespace is if half the world > > deploys DNSSEC and half doesn't, which is what we are all (?) trying > > to avoid, I thought. > > the longer this debate goes on, the happier i am that something like DLV > exists. domainholders want dns security and don't (for the most part) > care about enumeration since they can use split-dns or just live safe > with the knowledge that their zones are too numerous and too sparse to > be worth a dictionary attack. registry operators are very concerned > about enumeration, for operational or business (or both) reasons. without > something like DLV, i'm convinced that the part of the world who would > have the ability to deploy DNSSEC is far smaller than half of it. with > something like DLV, i'm convinced that the half of the world who implements > DNSSEC will incentivise the other half to get with the programme, "somehow." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 17:22:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13185 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 17:22:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs6dL-000Otd-Es for namedroppers-data@psg.com; Tue, 03 Aug 2004 21:15:43 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs6dA-000Ory-9B for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 21:15:32 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 9410519B3F7; Tue, 3 Aug 2004 17:05:41 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id D302519B82C; Tue, 3 Aug 2004 17:05:39 -0400 (EDT) Received: from [10.0.2.5] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 6C3B4CF394; Tue, 3 Aug 2004 17:15:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020416bd35ad4b5b21@[10.0.2.5]> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE105223@US-Columbia-CIST.mail.saic.com> References: <4E25ECBBC03F874CBAD03399254ADFDE105223@US-Columbia-CIST.mail.saic.com> Date: Tue, 3 Aug 2004 14:15:25 -0700 To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> From: Edward Lewis <edlewis@arin.net> Subject: RE: NXT design choices Cc: "'Edward Lewis'" <edlewis@arin.net>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:42 -0400 8/3/04, Loomis, Rip wrote: >Halloo Ed-- (I was told you weren't in San Diego because you were on vacation. ;) Either you've blown your alibi or you need to get back to the pool.) >Choice one was ditched for more reasons, because not only were >on-line keys needed but the signing of a tailored response needed >to be done in real time. It may be less significant an issue now, >but at the time the extra CPU cycles spent for "real time" crypto >as compared to "pre-computed" crypto were a major concern. Yeah, speed too. I forgot about that when I was composing the message. >> (It seems like this >on line storage of keys? (since your "this" isn't a clear reference) Yes - a verbal mention of this a few times around the IETF meeting rooms. (I realize now that this idea hasn't been expressed on the mailing list.) >> may be coming back in vogue. But the concerns I >> have are the transfer of the secret material between servers and the >> role of encrypting it. Back in the first DNSSEC implementations, >> crypto export controls and patents combined to discourage encryption. >> This is one reason why BIND's dnssec-keygen leaves the private key >> file in plaintext. I'm not up to date on crypto-business, so maybe >> the old concerns are out moded.) > >There are a much longer list of issues and concerns that need to >be expressed somewhere... Yeah (I deleted your list for brevity only)... >I agree with your statement above about zone enumeration. At the same >time, I agree with Paul and others who point out that obscurity of >DNS data has never been a designed-in feature of DNS (although it >may have been and may remain a desired feature.) I'm happy, err, content with zone enumeration myself because it's not a goal of DNS to "hide" data. On the other hand, ARIN servers don't permit AXFR. On yet the other hand, our data is rather easy to enumerate. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 17:38:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14244 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 17:38:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs6uv-00012y-Sf for namedroppers-data@psg.com; Tue, 03 Aug 2004 21:33:53 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs6ul-000121-6g for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 21:33:43 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.10/) with ESMTP id i73LXgmM007829; Tue, 3 Aug 2004 14:33:42 -0700 Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <QGRGP0N8>; Tue, 3 Aug 2004 14:33:42 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA02@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Paul Vixie'" <paul@vix.com>, "'namedroppers'" <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Date: Tue, 3 Aug 2004 14:33:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Why not persuade people to 'get with the program' by meeting their perfectly reasonable security goals? Seems a better plan to me than trying to persuade them that you understand their security requirements batter than they do. -----Original Message----- From: Paul Vixie [mailto:paul@vix.com] Sent: Tue Aug 03 12:59:38 2004 To: namedroppers Subject: Re: dictionary attack on nameservers > What is more likely to fracture the namespace is if half the world > deploys DNSSEC and half doesn't, which is what we are all (?) trying > to avoid, I thought. the longer this debate goes on, the happier i am that something like DLV exists. domainholders want dns security and don't (for the most part) care about enumeration since they can use split-dns or just live safe with the knowledge that their zones are too numerous and too sparse to be worth a dictionary attack. registry operators are very concerned about enumeration, for operational or business (or both) reasons. without something like DLV, i'm convinced that the part of the world who would have the ability to deploy DNSSEC is far smaller than half of it. with something like DLV, i'm convinced that the half of the world who implements DNSSEC will incentivise the other half to get with the programme, "somehow." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 18:33:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18507 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 18:33:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs7n1-0007nf-DI for namedroppers-data@psg.com; Tue, 03 Aug 2004 22:29:47 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs7mi-0007mR-R1 for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 22:29:29 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i73MTOrc001841; Tue, 3 Aug 2004 22:29:24 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i73MTOZU001838; Tue, 3 Aug 2004 22:29:24 GMT Date: Tue, 3 Aug 2004 22:29:24 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis <edlewis@arin.net> Cc: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Subject: Re: NXT design choices Message-ID: <20040803222924.GA1823@vacation.karoshi.com.> References: <4E25ECBBC03F874CBAD03399254ADFDE105223@US-Columbia-CIST.mail.saic.com> <a06020416bd35ad4b5b21@[10.0.2.5]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <a06020416bd35ad4b5b21@[10.0.2.5]> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm happy, err, content with zone enumeration myself because it's not > a goal of DNS to "hide" data. On the other hand, ARIN servers don't > permit AXFR. On yet the other hand, our data is rather easy to > enumerate. the data is available other ways tho. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 19:53:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23085 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 19:53:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs8zz-000Hf7-Jr for namedroppers-data@psg.com; Tue, 03 Aug 2004 23:47:15 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs8zo-000Haa-Uh for namedroppers@ops.ietf.org; Tue, 03 Aug 2004 23:47:05 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E126B19B8F3; Tue, 3 Aug 2004 19:37:12 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 5BEAA19B8F3; Tue, 3 Aug 2004 19:37:12 -0400 (EDT) Received: from [10.0.2.5] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id BD686CF394; Tue, 3 Aug 2004 19:47:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602041abd35d2b19e8f@[10.0.2.5]> In-Reply-To: <Roam.SIMC.2.0.6.1091369126.19351.nordmark@bebop.france> References: <Roam.SIMC.2.0.6.1091369126.19351.nordmark@bebop.france> Date: Tue, 3 Aug 2004 16:47:03 -0700 To: Erik Nordmark <Erik.Nordmark@sun.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface Cc: Edward Lewis <edlewis@arin.net>, Jun-ichiro itojun Hagino <itojun@itojun.org>, miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:05 -0700 8/1/04, Erik Nordmark wrote: >Hence I think we could collectively be more effective in fixing this >if we could present an API mechanism by which the application/middleware >could find out an upper limit on how long time it should retain >the information in its own cache. I've thought about replying to this for some time. I can see that the DNS TTL would be an appropriate measure of time that an application can "refer to" an answer it got from a DNS lookup - in essence the application is acting like a DNS cache and the TTL applies. But, that's the limit of how an application ought to make use of the TTL. The TTL isn't a necessarily a measure of the volatility of the data - e.g., it's not an indication of the "mean time to next change," say before the next dynamic update. Another example, the TTL isn't a measure of the useful life of the data - just the amount of time that a cache holding of it is "wise." DNS can offer up the following times - TTL, end of the signature validity (under DNSSEC), zone expiration. Signature validity can be a measure of the validity of the data's signature or the measure of the validity of the union of the entire chain. (I.e., just the RRSIG for the A record you want, or the "sum" of the times for the root's KEY, TLD's DS and KEY, ..., and the A's validity.) DNS does not have a "next scheduled change" (like there is in things like X.509 CRLs), which would probably far more interesting to an application. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 20:26:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25188 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 20:26:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs9Xe-000MqG-Dw for namedroppers-data@psg.com; Wed, 04 Aug 2004 00:22:02 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs9XT-000MpD-Ke for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 00:21:51 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i740Lfil013758; Tue, 3 Aug 2004 18:21:41 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i740LbJR027553; Wed, 4 Aug 2004 02:21:38 +0200 (MEST) Date: Tue, 3 Aug 2004 17:22:03 -0700 (PDT) From: Erik Nordmark <Erik.Nordmark@sun.com> Reply-To: Erik Nordmark <Erik.Nordmark@sun.com> Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface To: Edward Lewis <edlewis@arin.net> Cc: Erik Nordmark <Erik.Nordmark@sun.com>, Jun-ichiro itojun Hagino <itojun@itojun.org>, miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu In-Reply-To: "Your message with ID" <a0602041abd35d2b19e8f@[10.0.2.5]> Message-ID: <Roam.SIMC.2.0.6.1091578923.13038.nordmark@bebop.france> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I can see that the DNS TTL would be an appropriate measure of time > that an application can "refer to" an answer it got from a DNS lookup > - in essence the application is acting like a DNS cache and the TTL > applies. > > But, that's the limit of how an application ought to make use of the > TTL. Agree fully. And AFAIK this is what the applications do. For whatever reason they think gethostbyname/getaddrinfo is slow so the application contains a local cache of the results. > The TTL isn't a necessarily a measure of the volatility of the > data - e.g., it's not an indication of the "mean time to next > change," say before the next dynamic update. Another example, the > TTL isn't a measure of the useful life of the data - just the amount > of time that a cache holding of it is "wise." Agree. Do you have example of where an application would actually believe that the data would change after the TTL expires? Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 20:54:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27489 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 20:54:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs9zR-0000cj-UO for namedroppers-data@psg.com; Wed, 04 Aug 2004 00:50:45 +0000 Received: from [192.215.81.74] (helo=relay1.san2.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs9z8-0000YJ-Ri for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 00:50:27 +0000 Received: from tiger.ben.algroup.co.uk (0127ahost106.starwoodbroadband.com [12.105.246.106]) by relay1.san2.attens.com (8.11.6/8.9.3) with ESMTP id i740oPB23549 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 00:50:25 GMT Received: from [127.0.0.1] (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i741ilxU001923; Wed, 4 Aug 2004 02:44:48 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <41103F8F.5060506@algroup.co.uk> Date: Wed, 04 Aug 2004 02:44:47 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040628 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> CC: "'Edward Lewis'" <edlewis@arin.net>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Subject: Re: NXT design choices References: <4E25ECBBC03F874CBAD03399254ADFDE105223@US-Columbia-CIST.mail.saic.com> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE105223@US-Columbia-CIST.mail.saic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Loomis, Rip wrote: > - For methods of authenticated denial that involve "real time" > crypto, *all* authoritative servers must each have at least > one zone-signing key available. That makes life much harder > to deal with securely than the dynamic update case above. Not necessarily - they could relay the response (or the request) to a server that has the key (note that I'm not necessarily advocating this, just pointing out that it is possible). >>Today we have Choice 2b1. If we want to avoid zone enumeration, >>we'll have to give something else up, what will that be? On-line >>keys? Replay defense? Muddled name space? Even if we combine 2b1 >>with on-line keys - we need to break an old assumption (no keys >>on-line). > > > I think that there are solutions that address perceived issues with > zone enumeration without requiring on-line keys. If we can find > a method that meets "enough" of the requirements and desirements, > then I believe it's probably worth doing--but if it requires on-line > keys on all the authoritative servers for a zone for real-time > crypto then I believe it doesn't meet at least one of *my* > requirements. I guess I'd better get with my esteemed co-editor > and get that added to the initial requirement/desirement list. In fact it has already been added - it was in Nominet's list (that wasn't copied to you, unfortunately). Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 21:03:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28000 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 21:03:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsA9Y-0002eH-Ob for namedroppers-data@psg.com; Wed, 04 Aug 2004 01:01:12 +0000 Received: from [192.215.81.77] (helo=relay4.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsA9O-0002YO-63 for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 01:01:02 +0000 Received: from tiger.ben.algroup.co.uk (0127ahost106.starwoodbroadband.com [12.105.246.106]) by relay4.san1.attens.com (8.11.6/8.9.3) with ESMTP id i74111104371 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 01:01:01 GMT Received: from [127.0.0.1] (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i741tQxU001940 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 02:55:27 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <4110420E.7040106@algroup.co.uk> Date: Wed, 04 Aug 2004 02:55:26 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040628 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org> Subject: rollling salt/iterations/hash Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sam suggested during the WG meeting that there might be an issue with rolling salt, iterations or hash in NSEC++, namely that the zone might be unprotected during such a roll. I don't understand why he thinks this, but let me say I don't believe it is correct. Since each NSEC++ record contains the parameters used to generate it, when a client receives one as a negative response, it has everything it needs to check that the interval contains the hash of the request, regardless of whether it gets the "pre-roll" or "post-roll" version of the record (of course, they will almost certainly correspond to completely different records in the zone, but this is unimportant). Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 21:09:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28290 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 21:09:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsAEC-0003Nn-Lq for namedroppers-data@psg.com; Wed, 04 Aug 2004 01:06:00 +0000 Received: from [192.215.81.77] (helo=relay4.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsAE1-0003MU-Ur for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 01:05:50 +0000 Received: from mobile666 (0127ahost114.starwoodbroadband.com [12.105.246.114]) by relay4.san1.attens.com (8.11.6/8.9.3) with ESMTP id i7415O107176; Wed, 4 Aug 2004 01:05:25 GMT Message-ID: <002f01c479bf$21eb4e00$72f6690c@mobile666> From: "Roy Arends" <roy@dnss.ec> To: "Ben Laurie" <ben@algroup.co.uk>, "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Cc: "'Edward Lewis'" <edlewis@arin.net>, <namedroppers@ops.ietf.org> References: <4E25ECBBC03F874CBAD03399254ADFDE105223@US-Columbia-CIST.mail.saic.com> <41103F8F.5060506@algroup.co.uk> Subject: Re: NXT design choices Date: Wed, 4 Aug 2004 03:05:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Ben Laurie" <ben@algroup.co.uk> To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Cc: "'Edward Lewis'" <edlewis@arin.net>; <namedroppers@ops.ietf.org> Sent: Wednesday, August 04, 2004 3:44 AM Subject: Re: NXT design choices > Loomis, Rip wrote: > > - For methods of authenticated denial that involve "real time" > > crypto, *all* authoritative servers must each have at least > > one zone-signing key available. That makes life much harder > > to deal with securely than the dynamic update case above. > > Not necessarily - they could relay the response (or the request) to a > server that has the key (note that I'm not necessarily advocating > this, just pointing out that it is possible). Or, as an alternative: each authoritative nameserver generates a keypair within timeframe X, and uses secure-dynamic update to the primary to update their specific zone-key to the primary, followed by an incremental zonetransfer. If configured correctly, the incremental zonetransfer follows automatically, since the primary increases SOA and notifies secondaries. This method does not require oob key propagation. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 21:18:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28880 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 21:18:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsAMS-0004tA-HW for namedroppers-data@psg.com; Wed, 04 Aug 2004 01:14:32 +0000 Received: from [192.215.81.77] (helo=relay4.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsAMH-0004rH-U1 for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 01:14:22 +0000 Received: from tiger.ben.algroup.co.uk (0127ahost106.starwoodbroadband.com [12.105.246.106]) by relay4.san1.attens.com (8.11.6/8.9.3) with ESMTP id i741EK111628 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 01:14:20 GMT Received: from [127.0.0.1] (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i7428hxU002243; Wed, 4 Aug 2004 03:08:44 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <4110452B.5040100@algroup.co.uk> Date: Wed, 04 Aug 2004 03:08:43 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040628 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> CC: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: NSEC2 01 References: <ANECIHCPCBDLLEJLCOPGAECACNAA.scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGAECACNAA.scottr@nist.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: >>-----Original Message----- >>From: owner-namedroppers@ops.ietf.org >>[mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Samuel Weiler >> >>I'm not convinced that the wildcard discussion/example is correct. >>Perhaps Ed Lewis or Bob Halley can comment? >> > > > The draft authors would be better able to answer, but from my take- > > I'm guessing it's the part about response construction. In the example, I > don't know why 2) non-existance of b.c.d.e. is there. Shouldn't the EXIST > RR and subsequent NSEC2 RR show who the closest encloser is? That's how the > current DNSSECbis spec does it. Actually not - the canonical ordering subtly demonstrates the nonexistence of b.c.d.e at the same time as the nonexistence of a.b.c.d.e - suppose the previous record is c.e, then the relevant NSEC would look like this: c.e. NSEC c.d.e. if c.d.e exists. If it is an ENT, caused by, say, a.c.d.e, then: c.e. NSEC a.c.d.e. Both of these show that both a.b.c.d.e and b.c.d.e do not exist, and, in fact, you can always show everything needed with just two NSEC records. Unfortunately, obfuscation removes this elegance. > The server only needs to provide: > > 1. proof that the exact name doesn't exist > 2. proof that there isn't a wildcard at the closest encloser. One that > could have been expanded to provide a postive response. > > In this case, there is a EXIST RR to show the closest encloser. In some > cases, that isn't necessary, as there will be RRs at the closest encloser. The EXIST RR doesn't _prove_ the closest encloser unless you also prove there is no closer one. Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 21:22:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29134 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 21:22:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsART-0005gE-Sa for namedroppers-data@psg.com; Wed, 04 Aug 2004 01:19:43 +0000 Received: from [192.215.81.75] (helo=relay2.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsARJ-0005fP-7r for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 01:19:33 +0000 Received: from mobile666 (0127ahost114.starwoodbroadband.com [12.105.246.114]) by relay2.san1.attens.com (8.11.6/8.9.3) with ESMTP id i741IU001666; Wed, 4 Aug 2004 01:18:30 GMT Message-ID: <004c01c479c0$f5f0b090$72f6690c@mobile666> From: "Roy Arends" <roy@dnss.ec> To: "Ben Laurie" <ben@algroup.co.uk>, <namedroppers@ops.ietf.org> References: <4110420E.7040106@algroup.co.uk> Subject: Re: rollling salt/iterations/hash Date: Wed, 4 Aug 2004 03:18:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Ben Laurie" <ben@algroup.co.uk> To: <namedroppers@ops.ietf.org> Sent: Wednesday, August 04, 2004 3:55 AM Subject: rollling salt/iterations/hash > Sam suggested during the WG meeting that there might be an issue with > rolling salt, iterations or hash in NSEC++, namely that the zone might > be unprotected during such a roll. I don't understand why he thinks > this, but let me say I don't believe it is correct. Since each NSEC++ > record contains the parameters used to generate it, when a client > receives one as a negative response, it has everything it needs to check > that the interval contains the hash of the request, regardless of > whether it gets the "pre-roll" or "post-roll" version of the record (of > course, they will almost certainly correspond to completely different > records in the zone, but this is unimportant). What I explained to Sam is that NSECX records (with different salts) may collide wrt rolling salt. It is an attack vector, since an adversary is able to deny existing, signed records (which have a post-roll NSECX) using a pre-roll NSECX. Changing the salt alters the 'denial span'. To avoid this, salts should (must?) only be rolled at RRSIG experation boundaries. This is a fairly complex corner-case, since rolling the salt means resigning as well. You definitly do not want to sign and publish records at expiration time, but preferable a multiple TTL lifetimes before. Note that any change in salt or iterations changes the hash for a single name. Any changed hash introduces possible collisions between pre- and post- roll. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 3 21:30:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29505 for <dnsext-archive@lists.ietf.org>; Tue, 3 Aug 2004 21:30:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsAZC-0006nU-PY for namedroppers-data@psg.com; Wed, 04 Aug 2004 01:27:42 +0000 Received: from [192.215.81.76] (helo=relay3.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsAZ1-0006mP-PT for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 01:27:32 +0000 Received: from tiger.ben.algroup.co.uk (0127ahost106.starwoodbroadband.com [12.105.246.106]) by relay3.san1.attens.com (8.11.6/8.9.3) with ESMTP id i741RVE16212 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 01:27:31 GMT Received: from [127.0.0.1] (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i742LsxU002264; Wed, 4 Aug 2004 03:21:55 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <41104842.6010803@algroup.co.uk> Date: Wed, 04 Aug 2004 03:21:54 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040628 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> CC: namedroppers@ops.ietf.org Subject: Re: rollling salt/iterations/hash References: <4110420E.7040106@algroup.co.uk> <004c01c479c0$f5f0b090$72f6690c@mobile666> In-Reply-To: <004c01c479c0$f5f0b090$72f6690c@mobile666> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > From: "Ben Laurie" <ben@algroup.co.uk> > To: <namedroppers@ops.ietf.org> > Sent: Wednesday, August 04, 2004 3:55 AM > Subject: rollling salt/iterations/hash > > > >>Sam suggested during the WG meeting that there might be an issue with >>rolling salt, iterations or hash in NSEC++, namely that the zone might >>be unprotected during such a roll. I don't understand why he thinks >>this, but let me say I don't believe it is correct. Since each NSEC++ >>record contains the parameters used to generate it, when a client >>receives one as a negative response, it has everything it needs to check >>that the interval contains the hash of the request, regardless of >>whether it gets the "pre-roll" or "post-roll" version of the record (of >>course, they will almost certainly correspond to completely different >>records in the zone, but this is unimportant). > > > What I explained to Sam is that NSECX records (with different salts) may > collide wrt rolling salt. It is an attack vector, since an adversary is able > to deny existing, signed records (which have a post-roll NSECX) using a > pre-roll NSECX. Changing the salt alters the 'denial span'. This is not to do with salts, since the same would be true with NSEC records (i.e. an unexpired NSEC can be used to deny a now existing record). > To avoid this, salts should (must?) only be rolled at RRSIG experation > boundaries. This is a fairly complex corner-case, since rolling the salt > means resigning as well. You definitly do not want to sign and publish > records at expiration time, but preferable a multiple TTL lifetimes before. > > Note that any change in salt or iterations changes the hash for a single > name. Any changed hash introduces possible collisions between pre- and post- > roll. I don't see why that would be an issue, since the recipient of a record always knows what the hash parameters are - the fact that two sets of parameters give the same hash for different names doesn't seem important - what am I missing? (Of course, its astronomically unlikely this will happen unless we choose a stupid hash). Cheers, Ben. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 4 01:08:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11466 for <dnsext-archive@lists.ietf.org>; Wed, 4 Aug 2004 01:08:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsDv6-0008NM-Pr for namedroppers-data@psg.com; Wed, 04 Aug 2004 05:02:32 +0000 Received: from [192.215.81.75] (helo=relay2.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsDun-0008L8-Sa for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 05:02:14 +0000 Received: from mobile666 (0127ahost114.starwoodbroadband.com [12.105.246.114]) by relay2.san1.attens.com (8.11.6/8.9.3) with ESMTP id i7450v008746; Wed, 4 Aug 2004 05:00:59 GMT Message-ID: <000701c479e0$0c63aa70$72f6690c@mobile666> From: "Roy Arends" <roy@dnss.ec> To: "Ben Laurie" <ben@algroup.co.uk> Cc: <namedroppers@ops.ietf.org> References: <4110420E.7040106@algroup.co.uk> <004c01c479c0$f5f0b090$72f6690c@mobile666> <41104842.6010803@algroup.co.uk> Subject: Re: rollling salt/iterations/hash Date: Wed, 4 Aug 2004 04:01:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Ben Laurie" <ben@algroup.co.uk> To: "Roy Arends" <roy@dnss.ec> Cc: <namedroppers@ops.ietf.org> Sent: Wednesday, August 04, 2004 4:21 AM Subject: Re: rollling salt/iterations/hash > Roy Arends wrote: > > From: "Ben Laurie" <ben@algroup.co.uk> > > To: <namedroppers@ops.ietf.org> > > Sent: Wednesday, August 04, 2004 3:55 AM > > Subject: rollling salt/iterations/hash > > > > > > > >>Sam suggested during the WG meeting that there might be an issue with > >>rolling salt, iterations or hash in NSEC++, namely that the zone might > >>be unprotected during such a roll. I don't understand why he thinks > >>this, but let me say I don't believe it is correct. Since each NSEC++ > >>record contains the parameters used to generate it, when a client > >>receives one as a negative response, it has everything it needs to check > >>that the interval contains the hash of the request, regardless of > >>whether it gets the "pre-roll" or "post-roll" version of the record (of > >>course, they will almost certainly correspond to completely different > >>records in the zone, but this is unimportant). > > > > > > What I explained to Sam is that NSECX records (with different salts) may > > collide wrt rolling salt. It is an attack vector, since an adversary is able > > to deny existing, signed records (which have a post-roll NSECX) using a > > pre-roll NSECX. Changing the salt alters the 'denial span'. > > This is not to do with salts, since the same would be true with NSEC > records (i.e. an unexpired NSEC can be used to deny a now existing record). Yes, it is the same. > > To avoid this, salts should (must?) only be rolled at RRSIG experation > > boundaries. This is a fairly complex corner-case, since rolling the salt > > means resigning as well. You definitly do not want to sign and publish > > records at expiration time, but preferable a multiple TTL lifetimes before. > > > > Note that any change in salt or iterations changes the hash for a single > > name. Any changed hash introduces possible collisions between pre- and post- > > roll. > > I don't see why that would be an issue, since the recipient of a record > always knows what the hash parameters are - the fact that two sets of > parameters give the same hash for different names doesn't seem important > - what am I missing? (Of course, its astronomically unlikely this will > happen unless we choose a stupid hash). I'm NOT talking hash collisions. I'm talking about a collision between a post-roll hash and a span between two canonically ordered pre-roll hashes. This collision is VERY probable. But, as you said, it is essentially the same attack vector as with newly added records and unexpired NSEC records. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 4 05:26:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22836 for <dnsext-archive@lists.ietf.org>; Wed, 4 Aug 2004 05:26:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsHvl-000ETX-Gu for namedroppers-data@psg.com; Wed, 04 Aug 2004 09:19:29 +0000 Received: from [192.215.81.76] (helo=relay3.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsHvK-000EOd-P4 for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 09:19:02 +0000 Received: from mobile666 (0127ahost114.starwoodbroadband.com [12.105.246.114]) by relay3.san1.attens.com (8.11.6/8.9.3) with ESMTP id i749J0E05646 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 09:19:01 GMT Message-ID: <001e01c47a04$163052a0$72f6690c@mobile666> From: "Roy Arends" <roy@dnss.ec> To: <namedroppers@ops.ietf.org> Subject: NSECX: changing salt and incremental zone signing Date: Wed, 4 Aug 2004 11:18:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Very large zones will probably use incremental zone-signing. Since it is required to have a single salt value for the entire zone, changing the salt on every NSECX must be followed by a full zone-signing (not incremental). This is an operational consideration for very large zones. Not a biggie, just something that needs to be said in the draft somewhere. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 4 11:19:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11199 for <dnsext-archive@lists.ietf.org>; Wed, 4 Aug 2004 11:19:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsNQq-000BfF-C9 for namedroppers-data@psg.com; Wed, 04 Aug 2004 15:11:56 +0000 Received: from [192.215.81.76] (helo=relay3.san1.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsNQf-000Bco-JA for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 15:11:45 +0000 Received: from tiger.ben.algroup.co.uk (0127ahost106.starwoodbroadband.com [12.105.246.106]) by relay3.san1.attens.com (8.11.6/8.9.3) with ESMTP id i74FBhE02522 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 15:11:44 GMT Received: from [127.0.0.1] (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i742CFxU002252; Wed, 4 Aug 2004 03:12:15 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <411045FF.1020706@algroup.co.uk> Date: Wed, 04 Aug 2004 03:12:15 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040628 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh <alex@alex.org.uk> CC: Edward Lewis <edlewis@arin.net>, "'namedroppers@ops.ietf.org'" <namedroppers@ops.ietf.org>, ed@arin.net Subject: Re: NXT design choices References: <C6DDA43B91BFDA49AA2F1E473732113E010BEA00@mou1wnexm05.vcorp.ad.v rsn.com> <a0602040cbd357666a386@[10.0.2.5]> <EACE981B88D258DE21241A07@[192.168.100.27]> In-Reply-To: <EACE981B88D258DE21241A07@[192.168.100.27]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > Interesting: Given Ben has done some work (no idea how far he has got) "about half-way" - I can generate and sign the zone. I do not currently have a working resolver or responder. > on > proof-of-concept NSEC2 in Bind, do we have real-world code that would tell > us what the cost 2b2 over 2b1 is? (albeit non-optimized, and on one > platform)? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 4 12:07:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14195 for <dnsext-archive@lists.ietf.org>; Wed, 4 Aug 2004 12:07:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsOEZ-000Oar-UF for namedroppers-data@psg.com; Wed, 04 Aug 2004 16:03:19 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsOEP-000ORL-3O for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 16:03:09 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 4E5EE19B595; Wed, 4 Aug 2004 11:53:05 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id DE7F619B332; Wed, 4 Aug 2004 11:53:04 -0400 (EDT) Received: from [10.0.2.5] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id E1E66CF394; Wed, 4 Aug 2004 12:03:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602041ebd36b2ea2882@[10.0.2.5]> In-Reply-To: <Roam.SIMC.2.0.6.1091578923.13038.nordmark@bebop.france> References: <Roam.SIMC.2.0.6.1091578923.13038.nordmark@bebop.france> Date: Wed, 4 Aug 2004 08:40:39 -0700 To: Erik Nordmark <Erik.Nordmark@sun.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface Cc: Edward Lewis <edlewis@arin.net>, Erik Nordmark <Erik.Nordmark@sun.com>, Jun-ichiro itojun Hagino <itojun@itojun.org>, miekg@atoom.net, pekkas@netcore.fi, namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:22 -0700 8/3/04, Erik Nordmark wrote: >Do you have example of where an application would actually believe that the >data would change after the TTL expires? No, I don't. I was just imagining the worst-case scenario of an application developers "wild imagination." ;) The last time I did any work myself in this area, it was the 80's and I didn't have a TTL but did have changing data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 4 12:58:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18712 for <dnsext-archive@lists.ietf.org>; Wed, 4 Aug 2004 12:58:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsP2U-000C5k-F0 for namedroppers-data@psg.com; Wed, 04 Aug 2004 16:54:54 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsP2J-000C3I-O6 for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 16:54:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3907513DFB; Wed, 4 Aug 2004 16:54:43 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface In-Reply-To: Message from Erik Nordmark <Erik.Nordmark@sun.com> of "Tue, 03 Aug 2004 17:22:03 MST." <Roam.SIMC.2.0.6.1091578923.13038.nordmark@bebop.france> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 04 Aug 2004 16:54:43 +0000 Message-Id: <20040804165443.3907513DFB@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (i'm not sure how this thread got started on both namedroppers and dnsop, or whether it's wise for any thread to ever be in both places, but i'm not going to be the one to remove either list from the distribution here.) > > The TTL isn't a necessarily a measure of the volatility of the > > data - e.g., it's not an indication of the "mean time to next > > change," say before the next dynamic update. Another example, the > > TTL isn't a measure of the useful life of the data - just the amount > > of time that a cache holding of it is "wise." > > Agree. me too. > Do you have example of where an application would actually believe that the > data would change after the TTL expires? when rsalz first wrote INN he complained that a server administrator would have to say "innctl reload hosts" whenever his cached dns data became unavailable. he asked me for an extension to gethostbyname()'s "struct hostent" to show ttl, but i considered this unwise since there was no reasonable default for the case where the hostent had come from YP/NIS or /etc/hosts. i can only assume that web browser developers would also like to know how long it was safe to reuse a hostname->address translation before going "back out to the wire" to see if it had changed. right now i suspect that they have a hardwired time threshold measured in minutes, which would be nonrespectful toward the loadbalancing people who use violently short TTL's. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 4 13:19:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20369 for <dnsext-archive@lists.ietf.org>; Wed, 4 Aug 2004 13:19:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsPLg-000HNd-Rr for namedroppers-data@psg.com; Wed, 04 Aug 2004 17:14:44 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsPLW-000HMl-0c for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 17:14:34 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i74HEqQa098600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 17:14:58 GMT (envelope-from roy+dated+1094231666.bddb88@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i74HEQt2082934 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 18:14:26 +0100 (BST) (envelope-from roy+dated+1094231666.bddb88@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i74HEQZW082933 for namedroppers@ops.ietf.org; Wed, 4 Aug 2004 18:14:26 +0100 (BST) (envelope-from roy+dated+1094231666.bddb88@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 04 Aug 2004 18:14:26 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16657.6513.921542.127131@giles.gnomon.org.uk> Date: Wed, 4 Aug 2004 18:14:25 +0100 To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface In-Reply-To: <20040804165443.3907513DFB@sa.vix.com> References: <Erik.Nordmark@sun.com> <Roam.SIMC.2.0.6.1091578923.13038.nordmark@bebop.france> <20040804165443.3907513DFB@sa.vix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Paul" == Paul Vixie <paul@vix.com> writes: Paul> i can only assume that web browser developers would also Paul> like to know how long it was safe to reuse a Paul> hostname->address translation before going "back out to the Paul> wire" to see if it had changed. FWIW, I believe that the squid web proxy uses the TTL in this way. -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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 4 17:08:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08276 for <dnsext-archive@lists.ietf.org>; Wed, 4 Aug 2004 17:08:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsSrc-0007gE-Qf for namedroppers-data@psg.com; Wed, 04 Aug 2004 20:59:56 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsSrR-0007ej-28 for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 20:59:45 +0000 Received: from opene-130-129-132-223.ietf60.ietf.org (opene-130-129-132-223.ietf60.ietf.org [130.129.132.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 0471D5A06 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 22:59:42 +0200 (CEST) Date: Wed, 4 Aug 2004 13:59:36 -0700 (PDT) From: Jakob Schlyter <jakob@rfc.se> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: rfc 3267 interoperability report Message-ID: <Pine.OSX.4.61.0408041356200.1733@forastero.dynamic.schlyter.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This memo (not yet submitted to the internet drafts editor) documents the result from the RFC 3267 (Handling of Unknown DNS Resource Record Types) interoperability testing. I will also present the results of the tests at the DNSEXT meeting tomorrow. jakob DNS Extensions Working Group J. Schlyter Internet-Draft August 2, 2004 Expires: January 31, 2005 RFC 3267 Interoperability Report draft-ietf-dnsext-interop3597-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 31, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo documents the result from the RFC 3267 (Handling of Unknown DNS Resource Record Types) interoperability testing. Schlyter Expires January 31, 2005 [Page 1] Internet-Draft RFC 3267 Interoperability Report August 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3 3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Normative References . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . 6 Schlyter Expires January 31, 2005 [Page 2] Internet-Draft RFC 3267 Interoperability Report August 2004 1. Introduction This memo documents the result from the RFC 3267 (Handling of Unknown DNS Resource Record Types) interoperability testing. The test was performed during June and July 2004 by request of the IETF DNS Extensions Working Group. 2. Implementations The following is a list, in alphabetic order, of implementations for compliance of RFC 3597: DNSJava 1.6.4 ISC BIND 8.4.5rc4 ISC BIND 9.3.0rc2 NSD 2.1.1 Net::DNS 0.47 patchlevel 1 Nominum ANS 2.2.1.0.d These implementations covers the following functions (number of implementations tested for each function in paranthesis): Authoritative Name Servers (4) Full Recursive Resolver (2) Stub Resolver (4) DNSSEC Zone Signers (2) 3. Tests 3.1 Authoritative Primary Name Server The test zone data (Appendix A) was loaded into the name server implementation and the server was queried for the loaded information. 3.2 Authoritative Secondary Name Server The test zone data (Appendix A) was transferred using AXFR from another name server implementation and the server was queried for the transferred information. 3.3 Full Recursive Resolver A recursive resolver was queried for resource records from a domain with the test zone data (Appendix A). 3.4 Stub Resolver A stub resolver was used to query resource records from a domain with Schlyter Expires January 31, 2005 [Page 3] Internet-Draft RFC 3267 Interoperability Report August 2004 the test zone data (Appendix A). 3.5 DNSSEC Signer A DNSSEC signer was used to sign a zone with test zone data (Appendix A). 4. Problems found Two implementations had problems with text presentation of zero length RDATA. One implementation had problems with text presentation of RR type code and classes >= 4096. Bug reports were filed for problems found. 5. Summary Unknown type codes works in the tested authoritative servers, recursive resolvers and stub clients. No changes are needed to advance RFC 3597 to draft standard. Normative References [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. Author's Address Jakob Schlyter EMail: jakob@rfc.se Schlyter Expires January 31, 2005 [Page 4] Internet-Draft RFC 3267 Interoperability Report August 2004 Appendix A. Test zone data ; A-record encoded as TYPE1 a TYPE1 \# 4 7f000001 a TYPE1 192.0.2.1 a A \# 4 7f000002 ; draft-ietf-secsh-dns-05.txt sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e ; bogus test record (from RFC 3597) type731 TYPE731 \# 6 abcd ( ef 01 23 45 ) ; zero length RDATA (from RFC 3597) type62347 TYPE62347 \# 0 Schlyter Expires January 31, 2005 [Page 5] Internet-Draft RFC 3267 Interoperability Report August 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schlyter Expires January 31, 2005 [Page 6] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 4 23:38:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03806 for <dnsext-archive@lists.ietf.org>; Wed, 4 Aug 2004 23:38:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsYyi-000L8K-9U for namedroppers-data@psg.com; Thu, 05 Aug 2004 03:31:40 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsYyX-000L7C-6T for namedroppers@ops.ietf.org; Thu, 05 Aug 2004 03:31:29 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i753VJGK044991 for <namedroppers@ops.ietf.org>; Wed, 4 Aug 2004 23:31:19 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i753VJm2044990 for namedroppers@ops.ietf.org; Wed, 4 Aug 2004 23:31:19 -0400 (EDT) (envelope-from namedroppers) Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsTdA-000I1y-IY for namedroppers@ops.ietf.org; Wed, 04 Aug 2004 21:49:04 +0000 Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i74Ln4N11992; Wed, 4 Aug 2004 14:49:04 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i74Lmrbd020872; Wed, 4 Aug 2004 14:48:53 -0700 Date: Wed, 4 Aug 2004 14:48:53 -0700 From: kent crispin <kent@icann.org> To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... Message-ID: <20040804214853.GA16208@raven.songbird.com> Mail-Followup-To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org References: <20040803201152.GL16208@raven.songbird.com> <20040803202948.9B6B113DF7@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040803202948.9B6B113DF7@sa.vix.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Tue, Aug 03, 2004 at 08:29:48PM +0000, Paul Vixie wrote: > > nameserver for each of the zones to see if axfr was allowed. Of the > > 143 nameservers, 51 allow zone transfer, and 92 do not. > > > > That is, at least from this sample, your assertion is incorrect -- the > > evidence suggests that the majority of clueful registrants prefer NOT > > to make their full zones visible. > > i still do a fair bit of bind support and nameservice design consulting, > and i draw the opposite conclusion -- most people are knee-jerk about this > and have a "be as closed as possible" attitude, just as with inetd.conf, > but are not specifically concerned about zone data visibility. I would not call this an "opposite conclusion". Whether or not they are "specifically" concerned about zone data visibility, they certainly have some level of concern about it, and there's no point in haggling about the level. Also, whether one wants to call it "knee-jerk" or "bitter experience" depends on how one wants to spin it. > the ones > who are concerned about zone data visibility -- who you call "clueful" -- > are running split dns. That is, we can assume a higher level of concern on the part of those who use split dns, since split dns is more work to configure and maintain. The very existence of split dns, BTW, is particularly strong evidence that concern about zone data visibility is considered a reasonable thing; in fact one could go so far as to say that the "view" implementation in bind is an endorsement by the bind authors of the proposition that concern about visibility of zone data is a reasonable thing. > > But with easy enumeration, enumerating small zones becomes trivial, > > and therefor mass enumeration of their millions of zones becomes quite > > doable. > > what's the payback from learning the names of internal dns-named > resources? >From my perspective the most worrying payback is in how efficient one can be in conducting attacks. The information contained in a zone file can be quite helpful in mapping someone else's network -- for example, an enterprise network can span multiple address ranges in multiple locations, including completely private connections using rfc1918 space, and a complete listing of a zone will likely contain a great deal of information about these internal network connections that would be quite hard to gain otherwise. You are arguing that the "clueful" way to do this is to use split dns. But at the same time, you agree that in practice, only the very large zones are subject to attacks that can collect the contents of the zone, and even in that case there is question about how successful you can be. The conclusion, therefore, is that denying transfers has in practice been a successful way for the average registrant to accomplish the same privacy, without requiring the same level of "clue". And, independent of "clue", there is simply more work in maintaining split dns. Regards Kent -- kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Aug 5 12:57:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29829 for <dnsext-archive@lists.ietf.org>; Thu, 5 Aug 2004 12:57:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BslQa-000Lg1-Ae for namedroppers-data@psg.com; Thu, 05 Aug 2004 16:49:16 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BslQP-000Lf1-KN for namedroppers@ops.ietf.org; Thu, 05 Aug 2004 16:49:05 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A11AD19B99C; Thu, 5 Aug 2004 12:38:43 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 446F519B99C; Thu, 5 Aug 2004 12:38:43 -0400 (EDT) Received: from [130.129.135.107] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id EF3F5CF394; Thu, 5 Aug 2004 12:49:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020402bd381425ef78@[130.129.135.107]> Date: Thu, 5 Aug 2004 09:48:52 -0700 To: Suzanne Woolf <Suzanne_Woolf@isc.org> From: Edward Lewis <edlewis@arin.net> Subject: server-id Cc: edlewis@arin.net, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Two requirements for the "identity" in the answer 1) The server can have a different (a specific) identity based on "how" the server answers the client. E.g., a different identity for each view in BIND. 2) The server identifies the identities it will claim in some non-DNS manner to the administrator. E.g., listed in the logs. Other opinions - the identity need not be understandable to the client. But, when reporting bugs with the identity in the report, the client ought to have a clue as to whom the reported identity is meaningful. (Perhaps this comes from the IP address of the response, etc.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Aug 5 14:20:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04160 for <dnsext-archive@lists.ietf.org>; Thu, 5 Aug 2004 14:20:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bsmiw-0007wZ-3d for namedroppers-data@psg.com; Thu, 05 Aug 2004 18:12:18 +0000 Received: from [192.215.81.74] (helo=relay1.san2.attens.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bsmil-0007vR-A6 for namedroppers@ops.ietf.org; Thu, 05 Aug 2004 18:12:07 +0000 Received: from tiger.ben.algroup.co.uk (0127ahost68.starwoodbroadband.com [12.105.246.68]) by relay1.san2.attens.com (8.11.6/8.9.3) with ESMTP id i75IC5B25691 for <namedroppers@ops.ietf.org>; Thu, 5 Aug 2004 18:12:06 GMT Received: from [127.0.0.1] (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i75ImFUn001960; Thu, 5 Aug 2004 19:48:18 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <41126CE1.5040502@algroup.co.uk> Date: Thu, 05 Aug 2004 18:22:41 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7) Gecko/20040628 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> CC: namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers References: <200407290749.i6T7nX910804@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200407290749.i6T7nX910804@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Koch wrote: > Miek Gieben <miekg@atoom.net> wrote: > > >>The main point of my post is that I can enumerate (for +/- 90%) a zone >>in 24 hours, even if AXFR is blocked. > > > thanks for this effort, hard data is a Good Thing. It is, but this is not hard data. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 6 15:44:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21109 for <dnsext-archive@lists.ietf.org>; Fri, 6 Aug 2004 15:44:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BtAVf-000N47-KI for namedroppers-data@psg.com; Fri, 06 Aug 2004 19:36:11 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BtAVU-000N36-Uf for namedroppers@ops.ietf.org; Fri, 06 Aug 2004 19:36:01 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i76JZqHD025725; Fri, 6 Aug 2004 12:35:52 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <Q25QGQV1>; Fri, 6 Aug 2004 12:35:52 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA13@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Ben Laurie'" <ben@algroup.co.uk>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Cc: namedroppers <namedroppers@ops.ietf.org> Subject: RE: dictionary attack on nameservers Date: Fri, 6 Aug 2004 12:35:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Ben Laurie > Peter Koch wrote: > > Miek Gieben <miekg@atoom.net> wrote: > > > > > >>The main point of my post is that I can enumerate (for +/- > 90%) a zone > >>in 24 hours, even if AXFR is blocked. > > > > > > thanks for this effort, hard data is a Good Thing. > > It is, but this is not hard data. Actually Ben, it would appear that it is hard data, a dictionary of the 220,000 most common words in the English and Dutch languages only has 5% effectiveness. I would have expected a much higher success rate. This data is hard evidence that a dictionary attack is not a serious risk. That is much worse than password dictionary attacks where a much smaller dictionary tends to be effective unless there are symbol restrictions in place. The effectiveness against second level domains is in any case not relevant to the issue of third level domains which is where I believe the problem is very significant. Split DNS is completely ineffective when you are dealling with Web Services security issues since the whole point is to establish interactions across enterprise perimeters. The issue that concerns ME is not signing .com as signing verisign.com. There are many external resources I don't want to reveal the existence of. Until the launch at the beginning of the month I would not want the existence of the servers for the anti-phishing and anti-spam servers to be found and published and reported on in the Yahoo stock bulletin boards. The problem with NXT is that it breaks the expectations of the administrator - expectations that it is sheer arrogance to call ignorance. If I create a node ab12ye.example.com it is not currently visible to the external world through the DNS. NXT changes that situation for reasons that are neither obvious nor necessary. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 6 18:16:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29537 for <dnsext-archive@lists.ietf.org>; Fri, 6 Aug 2004 18:16:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BtCvv-000EjH-6U for namedroppers-data@psg.com; Fri, 06 Aug 2004 22:11:27 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BtCvb-000EiN-RO for namedroppers@ops.ietf.org; Fri, 06 Aug 2004 22:11:08 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i76MAtqJ001661; Fri, 6 Aug 2004 23:11:00 +0100 (BST) To: "Hallam-Baker, Phillip" <pbaker@verisign.com> cc: "'Ben Laurie'" <ben@algroup.co.uk>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers In-Reply-To: Message from "Hallam-Baker, Phillip" <pbaker@verisign.com> of "Fri, 06 Aug 2004 12:35:52 PDT." <C6DDA43B91BFDA49AA2F1E473732113E010BEA13@mou1wnexm05.vcorp.ad.vrsn.com> Date: Fri, 06 Aug 2004 23:10:55 +0100 Message-ID: <1660.1091830255@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "phb" == Hallam-Baker, Phillip <pbaker@verisign.com> writes: phb> The issue that concerns ME is not signing .com as signing phb> verisign.com. There are many external resources I don't want phb> to reveal the existence of. Fine. So don't put them in a public database in the expectation nobody will ever find them there. Or go looking for them. You wouldn't hide a spare front door key under the mat and hope a burglar would never think of looking for it there, would you? phb> If I create a node ab12ye.example.com it is not currently phb> visible to the external world through the DNS. Rubbish! As soon as that node is in the public DNS tree, it is public. The very fact that you created the node in a public tree indicates your acceptance that the name is public. You've published it. Sure, the name may not be readily visible -- though someone could figure that out easily enough from mail and web server logs or whatever. And in the context of new services/ventures from your employer, enough information about that will have leaked for someone to guess what the likely domain names for them may be. If ab12ye.example.com isn't meant to be visible, don't put it in the public DNS. Your kidding yourself if you think that names in the public DNS can be hidden from the Bad People you don't want to see those names. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Aug 7 06:00:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17421 for <dnsext-archive@lists.ietf.org>; Sat, 7 Aug 2004 06:00:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BtNuP-000GPP-3N for namedroppers-data@psg.com; Sat, 07 Aug 2004 09:54:37 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BtNu6-000GLL-8H for namedroppers@ops.ietf.org; Sat, 07 Aug 2004 09:54:18 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 4F335C2E06; Sat, 7 Aug 2004 10:54:17 +0100 (BST) Date: Sat, 07 Aug 2004 10:54:10 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'Ben Laurie'" <ben@algroup.co.uk>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Cc: namedroppers <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: RE: dictionary attack on nameservers Message-ID: <E586E6C1F9BE071118A81BB3@[192.168.100.27]> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEA13@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BEA13@mou1wnexm05.vcorp.ad.v rsn.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 06 August 2004 12:35 -0700 "Hallam-Baker, Phillip" <pbaker@verisign.com> wrote: > The issue that concerns ME is not signing .com as signing > verisign.com. If there is an enterprise requirement for non-enumerability it would be useful if this was more widely understood as this has previously been seen as an issue for (some) TLDs. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Aug 7 06:01:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17450 for <dnsext-archive@lists.ietf.org>; Sat, 7 Aug 2004 06:01:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BtNwz-000GmF-GP for namedroppers-data@psg.com; Sat, 07 Aug 2004 09:57:17 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BtNwo-000Gkt-6t for namedroppers@ops.ietf.org; Sat, 07 Aug 2004 09:57:06 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 72458C2E06; Sat, 7 Aug 2004 10:57:05 +0100 (BST) Date: Sat, 07 Aug 2004 10:56:58 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Jim Reid <jim@rfc1035.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: "'Ben Laurie'" <ben@algroup.co.uk>, Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Message-ID: <D5AFBDF8804838BABBD2AE64@[192.168.100.27]> In-Reply-To: <1660.1091830255@gromit.rfc1035.com> References: <1660.1091830255@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 06 August 2004 23:10 +0100 Jim Reid <jim@rfc1035.com> wrote: > Rubbish! As soon as that node is in the public DNS tree, it is public. > The very fact that you created the node in a public tree indicates > your acceptance that the name is public. You've published it. Seems to me there is a qualitative difference between publishing the node (with RRs), which is expected behaviour, and publishing an index of all nodes (which has not historically been expected behaviour for those disabling AXFR). I don't claim to be qualified to pontificate as to whether that affects enterprise security, but the two seem to me to be different things, and hence I can see why they might have different results. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Aug 8 22:19:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08197 for <dnsext-archive@lists.ietf.org>; Sun, 8 Aug 2004 22:19:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BtzbZ-0007SN-M1 for namedroppers-data@psg.com; Mon, 09 Aug 2004 02:09:41 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BtzbP-0007Qr-1c for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 02:09:31 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5DC7813E07 for <namedroppers@ops.ietf.org>; Mon, 9 Aug 2004 02:09:30 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... In-Reply-To: Message from Andrew Brown <atatat@atatdot.net> of "Sun, 08 Aug 2004 03:03:41 -0400." <20040808030341.A23461@noc.untraceable.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 09 Aug 2004 02:09:30 +0000 Message-Id: <20040809020930.5DC7813E07@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >what's the payback from learning the names of internal dns-named resources? > > speaking from the point of view of one trying to break in, it > establishes a priori targets before entry is gained. simply put, > names that don't need to be exposed should not be exposed. the people who agree with you and are serious about such, are already using split-view dns. outsiders don't see things that they shouldn't see. therefore, the people who are serious about attacking are using nmap, not axfr, to locate vulnerable systems. can we please not complicate a design having global implementation costs when the maximum payback for doing so won't have any effect on the trivial attacks? > the simple defense against this is to run with a much smaller piece of > the zone in question visible from the internet. this used to incur > running two name servers on a given machine, but the views that bind9 > offers make it easy easier to run one instance for two...well...views > of the same zone. > > of course, views don't solve everything... :) they're a better solution than NSECxx for the needs now under discussion. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Aug 8 22:57:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11539 for <dnsext-archive@lists.ietf.org>; Sun, 8 Aug 2004 22:57:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bu0J9-000CFo-GN for namedroppers-data@psg.com; Mon, 09 Aug 2004 02:54:43 +0000 Received: from [202.12.29.59] (helo=apnic.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bu0Ia-000CCc-7d for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 02:54:08 +0000 Received: from apnic.net (durian.apnic.net [202.12.29.252]) by apnic.net (8.12.8/8.12.8) with SMTP id i792s6uU002946 for <namedroppers@ops.ietf.org>; Mon, 9 Aug 2004 12:54:06 +1000 Date: Mon, 9 Aug 2004 12:54:06 +1000 From: George Michaelson <ggm@apnic.net> To: namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers Message-Id: <20040809125406.5f9b3b4d@garlic.apnic.net> In-Reply-To: <D5AFBDF8804838BABBD2AE64@[192.168.100.27]> References: <1660.1091830255@gromit.rfc1035.com> <D5AFBDF8804838BABBD2AE64@[192.168.100.27]> Organization: APNIC Pty Ltd X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AP-Spam-Status: No, hits=-100.001 required=6 X-AP-Spam-Score: -100.001 (notspam) BAYES_44,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I found the presentation on the dictionary attack very useful to stimulate thinking about the implications. If the 'pre DNSSEC' baseline is as high as 10-20% available by simple attack, then it does bring into question the benefit of limiting the walk. Thats a significant weakness in the current deployed base. You can take the other side, and say there is potential for a benefit in deploying DNSSEC of course, but the view right now is 'at least do no more harm' and I would say, when 20%+ is visible at a low cost then the protection cost may be higher than the benefit. (I am assuming that more clever attacks will emerge, so the high end counts get higher) In reverse of course, we have such a deterministic namespace that there is no meaningful protection against 'reverse IP dictionary attack' except perhaps in V6. -And I suspect this also provides significant entrypoints into the forward namespaces, since names in reverse can act as dictionary-attack pump-priming values to feed into the forward space. cheers -George -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 11:22:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05732 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 11:22:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuBsf-000Djj-Cz for namedroppers-data@psg.com; Mon, 09 Aug 2004 15:16:09 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuBsS-000DiS-2I for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 15:15:56 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i79FFo7O063169 for <namedroppers@ops.ietf.org>; Mon, 9 Aug 2004 11:15:50 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i79FFo8v063168 for namedroppers@ops.ietf.org; Mon, 9 Aug 2004 11:15:50 -0400 (EDT) (envelope-from namedroppers) Received: from [166.84.189.65] (helo=noc.untraceable.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BthiZ-000317-Eo for namedroppers@ops.ietf.org; Sun, 08 Aug 2004 07:03:43 +0000 Received: from noc.untraceable.net (localhost [127.0.0.1]) by noc.untraceable.net (8.13.1/8.13.1/bonk!) with ESMTP id i7873gfL023755; Sun, 8 Aug 2004 03:03:42 -0400 (EDT) Received: (from andrew@localhost) by noc.untraceable.net (8.13.1/8.13.1) id i7873f8n023754; Sun, 8 Aug 2004 03:03:41 -0400 (EDT) Date: Sun, 8 Aug 2004 03:03:41 -0400 From: Andrew Brown <atatat@atatdot.net> To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... Message-ID: <20040808030341.A23461@noc.untraceable.net> References: <20040803201152.GL16208@raven.songbird.com> <20040803202948.9B6B113DF7@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040803202948.9B6B113DF7@sa.vix.com>; from paul@vix.com on Tue, Aug 03, 2004 at 08:29:48PM +0000 X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :) X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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-subsrcibers. Please fix your subscription addresses. ] On Tue, Aug 03, 2004 at 08:29:48PM +0000, Paul Vixie wrote: >> But with easy enumeration, enumerating small zones becomes trivial, >> and therefor mass enumeration of their millions of zones becomes quite >> doable. > >what's the payback from learning the names of internal dns-named resources? speaking from the point of view of one trying to break in, it establishes a priori targets before entry is gained. simply put, names that don't need to be exposed should not be exposed. the simple defense against this is to run with a much smaller piece of the zone in question visible from the internet. this used to incur running two name servers on a given machine, but the views that bind9 offers make it easy easier to run one instance for two...well...views of the same zone. of course, views don't solve everything... :) -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" werdna@squooshy.com * "information is power -- share the wealth." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 13:56:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19493 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 13:56:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuEHe-0006Iv-Gw for namedroppers-data@psg.com; Mon, 09 Aug 2004 17:50:06 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuEHT-0006Gn-Ss for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 17:49:55 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i79Hnslw006736; Mon, 9 Aug 2004 10:49:54 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <QJDCYX0G>; Mon, 9 Aug 2004 10:49:54 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA21@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org Subject: RE: What I mumbled at the mike today... Date: Mon, 9 Aug 2004 10:49:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > speaking from the point of view of one trying to break in, it > > establishes a priori targets before entry is gained. simply put, > > names that don't need to be exposed should not be exposed. > > the people who agree with you and are serious about such, are already > using split-view dns. outsiders don't see things that they shouldn't > see. Split DNS has absolutely no viability in a Web Services extranet application. None Nada Zip Zero The UDDI services used to advertise an connect the services is protected using SSL and access control. If it is not possible to store names securely in DNS then either that function will have to be served in UDDI or we will have to develop a suitable DNS security fix in another forum. The ratio of useful discussion on technical issues to trying to talk down real world requirements in this list is very very low. I would estimate about 1:20 or less. If a significant constituency declares that an issue is a showstopper then further discussion of the issue is pointless. There is no argument that the European registries are not a significant constituency. The DNS is nowhere near so pretty that it needs preservation as a national treasure. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 14:17:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23090 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 14:17:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuEe8-0009cp-LS for namedroppers-data@psg.com; Mon, 09 Aug 2004 18:13:20 +0000 Received: from [64.158.219.12] (helo=secure.perfectemail.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BuEdx-0009bg-Vl for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 18:13:10 +0000 Received: (qmail 9891 invoked by uid 114); 9 Aug 2004 18:13:07 -0000 Received: from davidu@everydns.net by fiona by uid 106 with qmail-scanner-1.22 (clamscan: 0.72. spamassassin: 2.63. Clear:RC:1(127.0.0.1):. Processed in 0.01721 secs); 09 Aug 2004 18:13:07 -0000 X-Qmail-Scanner-Mail-From: davidu@everydns.net via fiona X-Qmail-Scanner: 1.22 (Clear:RC:1(127.0.0.1):. Processed in 0.01721 secs) Received: from localhost (HELO secure.perfectemail.net) (127.0.0.1) by secure.perfectemail.net with SMTP; 9 Aug 2004 18:13:07 -0000 Received: from 24.5.40.13 (PerfectEmail authenticated user davidu@everydns.net); by secure.perfectemail.net via HTTPS; Mon, 9 Aug 2004 11:13:07 -0700 (PDT) Message-ID: <63204.24.5.40.13.1092075187.davidu@everydns.net> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEA21@mou1wnexm05.vcorp.ad.vrsn.co m> References: <C6DDA43B91BFDA49AA2F1E473732113E010BEA21@mou1wnexm05.vcorp.ad.vrsn.com> Date: Mon, 9 Aug 2004 11:13:07 -0700 (PDT) Subject: RE: What I mumbled at the mike today... From: "David A. Ulevitch" <davidu@everydns.net> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org User-Agent: PerfectMail/1.4.4 X-Mailer: PerfectMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit <quote who="Hallam-Baker, Phillip"> >> the people who agree with you and are serious about such, are already >> using split-view dns. outsiders don't see things that they shouldn't >> see. > > Split DNS has absolutely no viability in a Web Services extranet > application. Okay, so don't use it there. Split DNS, by definition, would be considered tangential to an extranet. ie, the extranet is on one side of the split and doesn't know about the other. If your extranet needs a peek inside, I suggest evaluating a VPN or alternate solution. > > The UDDI services used to advertise an connect the services is protected > using SSL and access control. ...unrelated...? > > If it is not possible to store names securely in DNS then either that > function will have to be served in UDDI or we will have to develop > a suitable DNS security fix in another forum. define "store names securely" -- the machine can be secured, the split horizons (or views) can be secure. the network can be secure. what part of secure do you really want? The ability for it to not be enumerated? I thought this discussion was over. -davidu ---------------------------------------------------- David A. Ulevitch - Founder, EveryDNS.Net http://david.ulevitch.com -- http://everydns.net ---------------------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 14:40:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25804 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 14:40:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuEzb-000CCM-Pk for namedroppers-data@psg.com; Mon, 09 Aug 2004 18:35:31 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuEyO-000Bzx-JF for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 18:34:16 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 6E764C2DA6; Mon, 9 Aug 2004 19:34:13 +0100 (BST) Date: Mon, 09 Aug 2004 19:34:03 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: RE: What I mumbled at the mike today... Message-ID: <6F9A027152A5249F5448E8E2@[192.168.100.27]> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEA21@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BEA21@mou1wnexm05.vcorp.ad.v rsn.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 09 August 2004 10:49 -0700 "Hallam-Baker, Phillip" <pbaker@verisign.com> wrote: > Split DNS has absolutely no viability in a Web Services extranet > application. ... > The UDDI services used to advertise an connect the services is protected > using SSL and access control. > > If it is not possible to store names securely in DNS then either that > function will have to be served in UDDI or we will have to develop > a suitable DNS security fix in another forum. Seems to me the above argument is equally applicable, mutatis mutandis, to interorganization SIP & SIP URIs. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 14:56:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27223 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 14:56:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuFG5-000EJB-Te for namedroppers-data@psg.com; Mon, 09 Aug 2004 18:52:33 +0000 Received: from [149.8.64.32] (helo=mclmx2.mail.saic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuFFu-000EHl-W0 for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 18:52:23 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx2.mail.saic.com; Mon, 9 Aug 2004 14:52:15 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004080914521500773 ; Mon, 09 Aug 2004 14:52:15 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <QSRFSMSH>; Mon, 9 Aug 2004 14:52:15 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE105254@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> To: "'Hallam-Baker, Phillip'" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: RE: What I mumbled at the mike today... Date: Mon, 9 Aug 2004 14:49:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > speaking from the point of view of one trying to break in, it > > > establishes a priori targets before entry is gained. simply put, > > > names that don't need to be exposed should not be exposed. > > > > the people who agree with you and are serious about such, > > are already using split-view dns. outsiders don't see things > > that they shouldn't see. > > Split DNS has absolutely no viability in a Web Services extranet > application. I think that you're still saying that zone enumeration is a security issue and not a privacy issue. Am I correct? If you think that by not having a world-accessible DNS entry for a network-connected system you significantly improve its security posture, then I strongly disagree. I've done penetration testing for many years and I also monitor IDS devices. The simple facts today are that - If a system is connected to a network and it is vulnerable, then it will eventually be attacked. - The systems that are most likely to be attacked manually may be those most easily found in (DNS, Google, etc.) but the vast majority of attacks (both those being stopped and those successful) are automated. - If you have a system that is significantly appealing for someone to find it and target it specifically (for example by its name found in an enumerated zone file) then that system needs a very good set of safeguards and perhaps a name less appealing to attackers. DNS data is only one of the inputs to the target selection process for network-based attacks and it's a minor one. I don't expect that zone enumeration is going to suddenly change that, based on personal experience. I'm not saying that I want every outsider to have a perfect map of the internals of an enterprise network--but spending a lot of time preventing zone enumeration will also not keep bad guys from mapping networks or provide a useful improvement in security posture. For my part, though, I do believe (as I have for several years) that there are reasons why we should make a more conscious choice about the trade-offs with allowing/preventing zone enumeration (and I won't be sorry if we can eliminate it.) I think that perhaps your statements about DNS in the context of a "Web Services extranet application" need a little more explanation. You say there's "no viability" but provide no hard data. > If a significant constituency declares that an issue is a showstopper > then further discussion of the issue is pointless. Strongly disagree. Declaring something as fact does not make it fact. Providing a real list of requirements each with a basis would be more reasonable than saying "can't live with/without it". I'm one of the folks tasked to collect the requirements and bases and I believe that there are "significant constituencies" who have desirements that they would like to make requirements. If there are conflicting requirements, though, then we will all have a choice. It sure would help if we made sure that we all understood the real basis for each requirement--and when different TLDs look at the same privacy laws and have interpretations that are 179 degrees out of phase it makes things interesting. That's assuming that we're looking at zone enumeration as a privacy issue (which I think it is) and not a security issue (which to me it is not.) > > The DNS is nowhere near so pretty that it needs preservation as a > national treasure. Agreed. Simultaneously, the DNS is already ugly enough that continuing to add features and capabilities without considering all the impacts may be hazardous. --Rip (still looking for more inputs on the requirements related to zone enumeration, NSEC, and DNSSEC in general, BTW) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 15:05:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28190 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 15:05:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuFPN-000Fv0-B5 for namedroppers-data@psg.com; Mon, 09 Aug 2004 19:02:09 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuFP4-000Fqe-HU for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 19:01:50 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i79J1j4c013023; Mon, 9 Aug 2004 12:01:45 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <QJDCY0Q3>; Mon, 9 Aug 2004 12:01:45 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA22@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'David A. Ulevitch'" <davidu@everydns.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: RE: What I mumbled at the mike today... Date: Mon, 9 Aug 2004 12:01:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Okay, so don't use it there. Split DNS, by definition, would be > considered tangential to an extranet. ie, the extranet is on > one side of > the split and doesn't know about the other. If your extranet > needs a peek > inside, I suggest evaluating a VPN or alternate solution. Without meaning disrespect here, I don't think you appreciate the scale of this issue. We are not talking about trivial numbers of participants here. Think infrastructure to support merchants using RFID applications. We are talking about very large, deperimeterized networks here. And no, deperimeterization does not mean throwing away your firewall as many in the IETF seem to think, an idea considered so kooky in the real security world that it took me several minutes to convince some of the folk in the deperimeterization movement that there are serious advocates. I can't have a VPN that includes every manufacturer in north america. IPSEC is still not up to the task - in part because DNSSEC is not there. If you make DNSSEC dependent on IPSEC for deployment then you have just created a dependency cycle. Ben knows what he is doing here. From a security point of view the requirement is absolutely sound. > > The UDDI services used to advertise an connect the services > is protected > > using SSL and access control. > > ...unrelated...? No, the point is that the directory mechanism does not leak DNS names. > > > > If it is not possible to store names securely in DNS then > either that > > function will have to be served in UDDI or we will have to develop > > a suitable DNS security fix in another forum. > > define "store names securely" -- the machine can be secured, the split > horizons (or views) can be secure. It is possible to publish a name in DNS without alerting an attacker to the existence of the node. > the network can be secure. what part > of secure do you really want? The ability for it to not be > enumerated? I thought this discussion was over. So did I, but folk seem to keep re-opening it and trying to kill the requirement. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 15:14:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29727 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 15:14:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuFXm-000HN1-LT for namedroppers-data@psg.com; Mon, 09 Aug 2004 19:10:50 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuFXc-000HLy-3f for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 19:10:40 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i79JAdmG013776; Mon, 9 Aug 2004 12:10:39 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <QJDB1G0Z>; Mon, 9 Aug 2004 12:10:39 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA23@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Loomis, Rip'" <GILBERT.R.LOOMIS@saic.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: RE: What I mumbled at the mike today... Date: Mon, 9 Aug 2004 12:10:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think that you're still saying that zone enumeration is a > security issue and not a privacy issue. Am I correct? Yes > If you think that by not having a world-accessible DNS entry for a > network-connected system you significantly improve its security > posture, then I strongly disagree. I've done penetration testing > for many years and I also monitor IDS devices. The simple facts > today are that How many Web Services devices have you managed? > DNS data is only one of the inputs to the target selection > process for network-based attacks and it's a minor one. I > don't expect that zone enumeration is going to suddenly > change that, based on personal experience. If your model of the Internet is limited to today's applications. > I'm not saying that I want every outsider to have a perfect map > of the internals of an enterprise network--but spending a lot of > time preventing zone enumeration will also not keep bad guys from > mapping networks or provide a useful improvement in security > posture. the effort required to fix this issue is a trivial fraction of the effort trying to argue that it does not exist. > Strongly disagree. Declaring something as fact does not make > it fact. It is a fact that DNSSEC affects the visibility of data in the DNS in ways that have significant security consequences. The subjective issues are in the evaluation of those security consequences. > > The DNS is nowhere near so pretty that it needs preservation as a > > national treasure. > > Agreed. Simultaneously, the DNS is already ugly enough that > continuing to add features and capabilities without considering > all the impacts may be hazardous. So why not do the job properly this time round instead of arguing to do yet another half baked job? > --Rip (still looking for more inputs on the requirements > related to zone enumeration, NSEC, and DNSSEC in general, BTW) Fix wildcards so that mid point wildcards 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 15:24:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01478 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 15:24:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuFhM-000IkF-1P for namedroppers-data@psg.com; Mon, 09 Aug 2004 19:20:44 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuFhB-000Iiv-Ce for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 19:20:33 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 53C93C2DA6; Mon, 9 Aug 2004 20:20:32 +0100 (BST) Date: Mon, 09 Aug 2004 20:20:23 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'David A. Ulevitch'" <davidu@everydns.net> Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> Subject: RE: What I mumbled at the mike today... Message-ID: <C463CD55381862A658E938B1@[192.168.100.27]> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEA22@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E010BEA22@mou1wnexm05.vcorp.ad.v rsn.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 09 August 2004 12:01 -0700 "Hallam-Baker, Phillip" <pbaker@verisign.com> wrote: > I can't have a VPN that includes every manufacturer in north > america. IPSEC is still not up to the task - in part because > DNSSEC is not there Equally the suggestion to introduce a VPN when the underlying data is already SSL encrypted, merely to prevent the leak of information from DNS seems a bit bizarre. AIUI (going back to Rip's request to collect inputs for the requirements), your concern, Phillip, is that enumeration does not leak (potential) names. You are thus presumably not concerned (here) about wire-tap / man-in-the-middle type attacks where queries (and answers) get recorded by third parties - IE it is not a requirement in your book to (for instance) encrypt the query and/or response? 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 15:53:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05512 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 15:53:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuG8I-000MC9-1e for namedroppers-data@psg.com; Mon, 09 Aug 2004 19:48:34 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuG87-000MB3-DY for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 19:48:23 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id D7F1219BA34; Mon, 9 Aug 2004 15:36:48 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 77C7219B84D; Mon, 9 Aug 2004 15:36:48 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id E74E2CF39A; Mon, 9 Aug 2004 15:48:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020410bd3d82bb9a94@[192.168.1.100]> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE105254@US-Columbia-CIST.mail.saic.com> References: <4E25ECBBC03F874CBAD03399254ADFDE105254@US-Columbia-CIST.mail.saic.com> Date: Mon, 9 Aug 2004 15:48:21 -0400 To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> From: Edward Lewis <edlewis@arin.net> Subject: RE: What I mumbled at the mike today... Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:49 -0400 8/9/04, Loomis, Rip wrote: > --Rip (still looking for more inputs on the requirements > related to zone enumeration, NSEC, and DNSSEC in general, BTW) I'm at the same train station. But I'll settle for reqt's on zone enumeration and NSEC. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 15:53:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05549 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 15:53:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuG85-000MAu-LQ for namedroppers-data@psg.com; Mon, 09 Aug 2004 19:48:21 +0000 Received: from [149.8.64.32] (helo=mclmx2.mail.saic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuG78-000M4D-Nx for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 19:47:23 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx2.mail.saic.com; Mon, 9 Aug 2004 15:47:11 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004080915471010330 ; Mon, 09 Aug 2004 15:47:10 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <QMLWX2F2>; Mon, 9 Aug 2004 15:47:11 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE105257@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> To: "'Hallam-Baker, Phillip'" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: RE: What I mumbled at the mike today... Date: Mon, 9 Aug 2004 15:44:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dr. Hallam-Baker-- > How many Web Services devices have you managed? Apparently not enough to participate in a discussion of DNS Security in an IETF context. Funny, I didn't see that on the "required qualification" list. > > DNS data is only one of the inputs to the target selection > > process for network-based attacks and it's a minor one. I > > don't expect that zone enumeration is going to suddenly > > change that, based on personal experience. > > If your model of the Internet is limited to today's applications. My model of the future foundation of the Internet is unfortunately limited to incremental improvements (to the existing foundation) ideally while not screwing things up. I'm still not clear how XML-based "web services" are such a fundamental change to the way Things Get Done that current security principles and practices no longer apply. > > I'm not saying that I want every outsider to have a perfect map > > of the internals of an enterprise network--but spending a lot of > > time preventing zone enumeration will also not keep bad guys from > > mapping networks or provide a useful improvement in security > > posture. > > the effort required to fix this issue is a trivial fraction of > the effort trying to argue that it does not exist. The effort required to fix this issue correctly once-and-for-all is a non-trivial fraction of the available resources and may cause further delays in widespread DNSSEC usage without producing a significant benefity to many users. With all due respect, I believe you're still handwaving. I share your impatience with some IETF processes, but they are the constraints within which we're working. > > > Strongly disagree. Declaring something as fact does not make > > it fact. > > It is a fact that DNSSEC affects the visibility of data in the DNS > in ways that have significant security consequences. > > The subjective issues are in the evaluation of those security > consequences. It is a fact that DNSSECbis (through NSEC) affects the visibility of data in the DNS in ways that have been well-known and well- documented since RFC 2065 gave us the NXT RR in 1997. I wasn't happy about it then, but I decided I could live with it as did many others--based on a realistic evaluation of the risks involved. The subjective issues are in the evaluation of the potential consequences (security, privacy, or otherwise) of the effects, resulting security risks (if any), and in the decision as to what to do now. I *still* don't understand why this discussion got into security issues, and I need to understand things in order that the requirements document is complete and comprehensible (unless Ben can give me a Vulcan mind-meld or something, assuming he does understand the issues to your satisfaction.) > > --Rip (still looking for more inputs on the requirements > > related to zone enumeration, NSEC, and DNSSEC in general, BTW) > > Fix wildcards so that mid point wildcards work. Wow--I agree that mid-point wildcards would be very useful in some contexts but I see them as very painful and/or a Bad Idea in others. I'm afraid that may also be beyond the immediate scope of requirements that Ben and I were asked to compile, but I do think it needs to be discussed at least once more-- and very soon since it needs to be taken into account as part of the DNSSEC-what-now discussions. Okay, who's doing wildcard requirements? --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 16:33:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13061 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 16:33:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuGl2-0001eM-9m for namedroppers-data@psg.com; Mon, 09 Aug 2004 20:28:36 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuGkr-0001dB-G7 for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 20:28:25 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i79KSOYt027253; Mon, 9 Aug 2004 13:28:24 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <QJDFVCQR>; Mon, 9 Aug 2004 13:28:24 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA24@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Loomis, Rip'" <GILBERT.R.LOOMIS@saic.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: namedroppers@ops.ietf.org Subject: RE: What I mumbled at the mike today... Date: Mon, 9 Aug 2004 13:28:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > How many Web Services devices have you managed? > Apparently not enough to participate in a discussion > of DNS Security in an IETF context. Funny, I didn't > see that on the "required qualification" list. It would seem to be a useful qualification if you are going to argue the security requirements thereof. > > > DNS data is only one of the inputs to the target selection > > > process for network-based attacks and it's a minor one. I > > > don't expect that zone enumeration is going to suddenly > > > change that, based on personal experience. > > > > If your model of the Internet is limited to today's applications. > > My model of the future foundation of the Internet is unfortunately > limited to incremental improvements (to the existing foundation) > ideally while not screwing things up. I'm still not clear > how XML-based "web services" are such a fundamental change to > the way Things Get Done that current security principles and > practices no longer apply. Actually what I am saying here is that the security principles considered in the Internet security field DO apply. What I reject are the superstitious nonsense and pseudo-security doctrines that pass for security arguments here. > The effort required to fix this issue correctly once-and-for-all > is a non-trivial fraction of the available resources and may > cause further delays in widespread DNSSEC usage without producing > a significant benefity to many users. It will cause no delays whatsoever. You are so far from being deployed in the real world that it is just not funny. > > Fix wildcards so that mid point wildcards work. > > Wow--I agree that mid-point wildcards would be very useful in > some contexts but I see them as very painful and/or a Bad Idea > in others. Wildcards ARE a really bad idea. But they are also used. And since SRV appeared there are significant problems with the way they are used. Having been subjected to endless arguments about why wildcards make\ it impossible to use prefixes in the context of SPF I think we should fix 'em. I can draw up some requirements next week. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Aug 9 16:39:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14339 for <dnsext-archive@lists.ietf.org>; Mon, 9 Aug 2004 16:39:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuGsT-0002hi-55 for namedroppers-data@psg.com; Mon, 09 Aug 2004 20:36:17 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuGsI-0002gJ-6W for namedroppers@ops.ietf.org; Mon, 09 Aug 2004 20:36:06 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i79Ka0CV020247; Mon, 9 Aug 2004 13:36:00 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <QJDB13FG>; Mon, 9 Aug 2004 13:36:00 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E010BEA25@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Alex Bligh'" <alex@alex.org.uk>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'David A. Ulevitch'" <davidu@everydns.net> Cc: namedroppers@ops.ietf.org Subject: RE: What I mumbled at the mike today... Date: Mon, 9 Aug 2004 13:35:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > You are thus presumably not concerned (here) about wire-tap / > man-in-the-middle type attacks where queries (and answers) > get recorded > by third parties - IE it is not a requirement in your book to (for > instance) encrypt the query and/or response? Actually I do have real concerns here, but confidentiality is not something that can be addressed in an end to end protocol in the context of DNS while authenticity is. Encrypting DNS is something like issue number 37 on my list of urgent fixes to Internet security protocols. It will not be relevant until a whole host of other stuff is fixed first and there will be no viable way to address it until there is DNS authentication security. Basically my approach would be to perform point to point encryption using session keys generated through an ephemeral key exchange. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Aug 10 08:00:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17890 for <dnsext-archive@lists.ietf.org>; Tue, 10 Aug 2004 08:00:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuV9s-000F3e-IE for namedroppers-data@psg.com; Tue, 10 Aug 2004 11:51:12 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuV9Z-000EzF-PE for namedroppers@ops.ietf.org; Tue, 10 Aug 2004 11:50:53 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BuV9U-0001jd-Nz; Tue, 10 Aug 2004 13:50:48 +0200 In-Reply-To: <20040808030341.A23461@noc.untraceable.net> To: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic <sanz@denic.de> Message-ID: <OF55B9F1B6.36EDD417-ONC1256EEC.0040B6CC-C1256EEC.004110F4@notes.denic.de> Date: Tue, 10 Aug 2004 13:50:41 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 10.08.2004 13:50:48, Serialize complete at 10.08.2004 13:50:48 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > what's the payback from learning the names of internal dns-named resources? The attack described in Bellovin's Paper http://www.research.att.com/~smb/papers/dnshack.ps starts by assuming that the names of the target machines are known to the attacker. Best, Marcos Sanz -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 11 15:30:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01802 for <dnsext-archive@lists.ietf.org>; Wed, 11 Aug 2004 15:30:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Buyf9-000Gn8-DD for namedroppers-data@psg.com; Wed, 11 Aug 2004 19:21:27 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Buyey-000Gm0-Jh for namedroppers@ops.ietf.org; Wed, 11 Aug 2004 19:21:16 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00605; Wed, 11 Aug 2004 15:21:14 -0400 (EDT) Message-Id: <200408111921.PAA00605@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-34.txt Date: Wed, 11 Aug 2004 15:21:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-34.txt Pages : 26 Date : 2004-8-11 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-34.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-34.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-34.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-11152534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-34.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-34.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-11152534.I-D@ietf.org> --OtherAccess-- --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 11 15:30:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01830 for <dnsext-archive@lists.ietf.org>; Wed, 11 Aug 2004 15:30:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuyfL-000GoO-VH for namedroppers-data@psg.com; Wed, 11 Aug 2004 19:21:39 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Buyf3-000Gmo-7u for namedroppers@ops.ietf.org; Wed, 11 Aug 2004 19:21:21 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00619; Wed, 11 Aug 2004 15:21:18 -0400 (EDT) Message-Id: <200408111921.PAA00619@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2539bis-dhk-04.txt Date: Wed, 11 Aug 2004 15:21:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 : Storage of Diffie-Hellman Keying Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2539bis-dhk-04.txt Pages : 10 Date : 2004-8-11 The standard method for encoding Diffie-Hellman keys in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2539bis-dhk-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-11152543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2539bis-dhk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-11152543.I-D@ietf.org> --OtherAccess-- --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 11 16:07:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06717 for <dnsext-archive@lists.ietf.org>; Wed, 11 Aug 2004 16:07:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BuzIi-000Led-3A for namedroppers-data@psg.com; Wed, 11 Aug 2004 20:02:20 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BuzIP-000Lc1-85 for namedroppers@ops.ietf.org; Wed, 11 Aug 2004 20:02:01 +0000 Received: from mcl-its-ieg02.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Wed, 11 Aug 2004 16:01:56 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg02.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004081116024126026 for <namedroppers@ops.ietf.org>; Wed, 11 Aug 2004 16:02:41 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id <QSRF4J9Z>; Wed, 11 Aug 2004 16:01:55 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE105267@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> To: namedroppers@ops.ietf.org Subject: Zone enumeration, requirements, and security Date: Wed, 11 Aug 2004 15:59:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk First, although nothing on-list has really convinced me that zone enumeration is a security issue, I was convinced off-list that it *is*. In a postulated future (hopefully not too far-fetched) world, zone enumeration could definitely help an attacker to find IPv6-aware targets given the lower expected density of IPv6 nodes. (This assumes that either reverse-lookup records are not configured for an IPv6 zone, or that they are configured but not useful in target selection--and is separate from the concerns of delegation-centric zones which I believe are still privacy/licensing related rather than truly security relevant.) The biggest reason why DNS is a minor input to the current target selection process for attackers is that it's already a target- rich environment--and IPv6 may be expected to shift that balance. Secondly, I do believe I understand the concern with zone enumeration making it easy for an attacker to collect RRs. I'm still not convinced that having those RRs revealed is a security concern, but I'll accept that preventing zone enumeration will reduce risk by some amount (however small) *and* that allowing zone enumeration is a change to an expected/current behavior of DNS (which can be considered as designed-in even though it was not required by any protocol spec). This is, I believe, the argument being made by Dr. Phill Hallam-Baker. So although the existence of a capability for zone enumeration does not directly make systems more vulnerable, it does increase the probability of a successful attack. As a result I now believe we have at least one and probably two separate bases for a security requirement: Restricting the ability of attackers to enumerate zones produces a security benefit. Could anyone out there who disagrees please clearly (re-)state their disagreement and basis for it? If no one does then we'll try to reflect those concerns as best we can. And could anyone with any remaining requirements related to zone enumeration, NSEC, and any *other* thing they don't like about DNSSEC please state them now? (yeah, I still want an effective means of key revocation but I don't see it happening at this rate--and it's outside the scope of my little piece right now.) As soon as my co-editor and I can synch back up I'd really like to get an updated draft of the requirements collection doc out for WG review so that we can all move forward into the verification and prioritization of requirements. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Aug 11 18:39:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27605 for <dnsext-archive@lists.ietf.org>; Wed, 11 Aug 2004 18:39:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bv1g2-000I1y-4E for namedroppers-data@psg.com; Wed, 11 Aug 2004 22:34:34 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bv1fr-000I0f-10 for namedroppers@ops.ietf.org; Wed, 11 Aug 2004 22:34:23 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i7BMY84e001638; Wed, 11 Aug 2004 18:34:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040811182748.042f7ec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Wed, 11 Aug 2004 18:34:09 -0400 To: Thomas Narten <narten@us.ibm.com>, Margaret Wasserman <margaret@thingmagic.com> From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Publication Requested: LLMNR document (MDNS-34) Cc: iesg-secretary@ietf.org, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thomas and Margaret Please advance LLMNR on standards track to proposed standard: (http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-33.txt). 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? Yes, we have read this document and it has been extensively reviewed and revised. For the last 2 years an issue tracker has been used to track open issues and their resolution. 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, key members of DNSEXT a have read this document. As the document crosses multiple working groups expertise we are happy to report that there are number of reviewers from these working groups. We have no concern about the quality of the reviews. 3. Do you have concerns that the document needs more review from a particular (broader) perspective? The only review that this document may need is from architectural point of view. This is one of at least two proposed mechanisms to provide name resolution via multicast in server-less environment. Another one is documented in: http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-04.txt 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. No concerns with the document. 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 working group consensus is "rough" there is number of people that support the alternate proposal, the working group tried hard to get the two camps to agree on a single specification. We where unable to get some fundamental technical differences resolved. The other issue has to do layering, mDNS-33 documents a simple name resolution protocol without any usage model (only when to use this mechanism vs DNS) the other proposal has number of optimizations and usage assumptions. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No one has threatened appeal, as stated before there are two camps that consider each other "heretics". See answer to #5. 7. Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes, the document passes all nits. 8. Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? References are split, and all normative references are RFCs. 9. For Standards Track and BCP documents, the IESG approval announcement includes a write up section with the following sections: Technical Summary: Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. Working Group Summary The document being advanced is a cumulation of a long process to specify a DNS like mechanism to use on a local link. This document has gone through large number of changes in its progress and got better over time. There is rough consensus in the WG to advance the document. There are some issues that are in conflict with the wishes of some reviewers. Some of these issues are within the core expertise of the working group (DNS) but related to Transport (TTL=?). The current consensus to use TTL=1 and TCP as much as possible is to prevent implementations of this protocol to become DDoS amplifiers. Protocol Quality: This protocol document has gone through number of revisions and been greatly simplified from original specification. The protocol is clearly expressed and more importantly clearly documented when the use of this protocol is applicable. This is a complicated protocol but it inherits most of the complexity from DNS, packet format, Resource Records, Return Codes etc. We judge this protocol description to be of high quality. There exists at least one implementation of the protocol. Olafur & Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Aug 12 15:38:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26457 for <dnsext-archive@lists.ietf.org>; Thu, 12 Aug 2004 15:38:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvLHL-0008Lo-1T for namedroppers-data@psg.com; Thu, 12 Aug 2004 19:30:23 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvLH2-0008Ic-2f for namedroppers@ops.ietf.org; Thu, 12 Aug 2004 19:30:04 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25878; Thu, 12 Aug 2004 15:30:01 -0400 (EDT) Message-Id: <200408121930.PAA25878@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2536bis-dsa-04.txt Date: Thu, 12 Aug 2004 15:30:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 : DSA Keying and Signature Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-04.txt Pages : 8 Date : 2004-8-12 The standard method of encoding US Government Digital Signature Algorithm keying and signature information for use in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2536bis-dsa-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-12143757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2536bis-dsa-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-12143757.I-D@ietf.org> --OtherAccess-- --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 03:23:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24492 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 03:23:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvWJL-000NJL-ST for namedroppers-data@psg.com; Fri, 13 Aug 2004 07:17:11 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvWJB-000NId-5V for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 07:17:01 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BvWJ9-0004NN-Tm; Fri, 13 Aug 2004 09:16:59 +0200 To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic <sanz@denic.de> Message-ID: <OFBAAC5169.30C38128-ONC1256EEF.00268204-C1256EEF.0028017A@notes.denic.de> Date: Fri, 13 Aug 2004 09:16:58 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 13.08.2004 09:16:59, Serialize complete at 13.08.2004 09:16:59 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On the heels of Miek's communication about the success of a dictionary attack on the nl-zone (size ca 1 million), I replicated the attack on the de-zone (size ca 8 millions). Thanks to Miek for the scripts. Based on a combined German-English dictionary with more than 100,000 words and feeding John the Ripper with it to produce a wider attack base, I was only able to recover 80,000 domains, accounting to 1% of the total zone. I guess it could be postulated that, by means of a dictionary attack, the amount of the domains that can be recovered from a zone remains constant, and that its effectivity diminishes inversely proportional to the growing size of the zone. Best regards, Marcos -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 05:17:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29582 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 05:17:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvY7g-000Cfz-C3 for namedroppers-data@psg.com; Fri, 13 Aug 2004 09:13:16 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvY7F-000Cdk-FJ for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 09:12:49 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 4C094C2DA4; Fri, 13 Aug 2004 10:12:48 +0100 (BST) Date: Fri, 13 Aug 2004 10:12:35 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: "Marcos Sanz/Denic" <sanz@denic.de>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Message-ID: <519C89440182C16FD2EAF9CC@[192.168.2.11]> In-Reply-To: <OFBAAC5169.30C38128-ONC1256EEF.00268204-C1256EEF.0028017A@notes.denic.de> References: <OFBAAC5169.30C38128-ONC1256EEF.00268204-C1256EEF.0028017A@notes .denic.de> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 August 2004 09:16 +0200 "Marcos Sanz/Denic" <sanz@denic.de> wrote: > Based on a combined German-English dictionary with more than 100,000 > words and feeding John the Ripper with it to produce a wider attack > base, I was only able to recover 80,000 domains, accounting to 1% of the > total zone. Interesting - is that after a full run? IE you didn't stop because you got bored. Anyone have an obvious large source of in-addr.arpa PTR records that we could do use to extract .de names and get the percentage of the total .de zone size that yields (even with false positives)? 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 05:26:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29979 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 05:26:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvYHN-000DpX-77 for namedroppers-data@psg.com; Fri, 13 Aug 2004 09:23:17 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvYHB-000DnO-SH for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 09:23:06 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i7D9N4ZB014724 for <namedroppers@ops.ietf.org>; Fri, 13 Aug 2004 11:23:04 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i7D9N4429693 for <namedroppers@ops.ietf.org>; Fri, 13 Aug 2004 11:23:04 +0200 (MEST) Message-Id: <200408130923.i7D9N4429693@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-reply-to: Your message of "Fri, 13 Aug 2004 10:12:35 BST." <519C89440182C16FD2EAF9CC@[192.168.2.11]> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29688.1092388982.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Fri, 13 Aug 2004 11:23:03 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh <alex@alex.org.uk> wrote: > Anyone have an obvious large source of in-addr.arpa PTR > records that we could do use to extract .de names and get the percentage of > the total .de zone size that yields (even with false positives)? given that a very large fraction of the names/zones within DE points to a relatively small number of IP addresses (which has been a result of the various hostcounts during recent years), and, in turn, most of the PTR RR targets then differ only at the third, fourth, fifth level, I'd be surprised if this approach would change the result dramatically. -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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 05:47:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01179 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 05:47:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvYbf-000GZx-1u for namedroppers-data@psg.com; Fri, 13 Aug 2004 09:44:15 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvYbU-000GZM-Fp for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 09:44:04 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BvYbT-0006OV-Iu; Fri, 13 Aug 2004 11:44:03 +0200 In-Reply-To: <519C89440182C16FD2EAF9CC@[192.168.2.11]> To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic <sanz@denic.de> Message-ID: <OFA15C25D7.CC4E68DE-ONC1256EEF.0034D704-C1256EEF.00357821@notes.denic.de> Date: Fri, 13 Aug 2004 11:44:01 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 13.08.2004 11:44:03, Serialize complete at 13.08.2004 11:44:03 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Interesting - is that after a full run? IE you didn't stop because you > got bored. That was a full run. It didn't require much patience because the attack was performed directly over the zone file and not via DNS queries. Regards, Marcos -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 06:13:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02991 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 06:13:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvZ0r-000KgZ-JP for namedroppers-data@psg.com; Fri, 13 Aug 2004 10:10:17 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvYz8-000KPc-O1 for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 10:08:30 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id F2545C2DA4; Fri, 13 Aug 2004 11:08:29 +0100 (BST) Date: Fri, 13 Aug 2004 11:08:29 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Message-ID: <E3170ABA91578D0AB1674367@[192.168.100.27]> In-Reply-To: <200408130923.i7D9N4429693@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200408130923.i7D9N4429693@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 August 2004 11:23 +0200 Peter Koch <pk@TechFak.Uni-Bielefeld.DE> wrote: > given that a very large fraction of the names/zones within DE points to a > relatively small number of IP addresses (which has been a result of the > various hostcounts during recent years), and, in turn, most of the PTR RR > targets then differ only at the third, fourth, fifth level, I'd be > surprised if this approach would change the result dramatically. My guess would be the same. But some people here whose knowledge re DNS we should respect have asserted that if in-addr.arpa (for instance) could equally be used as an attack to enumerate a zone file. So if we want to show that actually, no, zones like .de are not enumerable to a great extent now (which is what I believe as well), it would be good if we had some hard data to show it. I suspect most zones have nothing but www and MX records. In which case iterating through .de and reporting the number of unique www and MX IP addresses would set an upper bound on the number of records discoverable through in-addr.arpa attack (operating on the assumption there are not a large number of IP addresses with forwards in other zones, or no forwards, that have reverses that resolve to .de addresses, which I think is fair). 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 06:26:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04110 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 06:26:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvZCV-000MDd-KO for namedroppers-data@psg.com; Fri, 13 Aug 2004 10:22:19 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvZBg-000M5x-Cu for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 10:21:28 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i7DALNqJ013425; Fri, 13 Aug 2004 11:21:25 +0100 (BST) To: Marcos Sanz/Denic <sanz@denic.de> cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Marcos Sanz/Denic <sanz@denic.de> of "Fri, 13 Aug 2004 09:16:58 +0200." <OFBAAC5169.30C38128-ONC1256EEF.00268204-C1256EEF.0028017A@notes.denic.de> Date: Fri, 13 Aug 2004 11:21:23 +0100 Message-ID: <13424.1092392483@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic <sanz@denic.de> writes: Marcos> Based on a combined German-English dictionary with more Marcos> than 100,000 words and feeding John the Ripper with it to Marcos> produce a wider attack base, I was only able to recover Marcos> 80,000 domains, accounting to 1% of the total zone. Thanks to you and Miek for doing this. Another way of looking at the result is 80% of your dictionary got a successful hit in .de. Which shouldn't be a surprise. I wonder what the success rate would be with a bigger dictionary: ie <word>-<digit>, <plural-word>-<digit>, <word><word>, <word>-<word>? Marcos> I guess it could be postulated that, by means of a Marcos> dictionary attack, the amount of the domains that can be Marcos> recovered from a zone remains constant, and that its Marcos> effectivity diminishes inversely proportional to the Marcos> growing size of the zone. I'm not sure if a statistician would draw that conclusion from a sample of two (attacks and zones). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 07:07:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06222 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 07:07:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvZqx-0002ok-6D for namedroppers-data@psg.com; Fri, 13 Aug 2004 11:04:07 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvZqe-0002mo-6B for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 11:03:48 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 7DB62107BD4; Fri, 13 Aug 2004 11:03:47 +0000 (GMT) Message-ID: <411CA013.1050308@algroup.co.uk> Date: Fri, 13 Aug 2004 12:03:47 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers <namedroppers@ops.ietf.org> Subject: Re: dictionary attack on nameservers References: <C6DDA43B91BFDA49AA2F1E473732113E010BEA13@mou1wnexm05.vcorp.ad.vrsn.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E010BEA13@mou1wnexm05.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: >>From: owner-namedroppers@ops.ietf.org >>[mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Ben Laurie >>Peter Koch wrote: >> >>>Miek Gieben <miekg@atoom.net> wrote: >>> >>> >>> >>>>The main point of my post is that I can enumerate (for +/- >> >>90%) a zone >> >>>>in 24 hours, even if AXFR is blocked. >>> >>> >>>thanks for this effort, hard data is a Good Thing. >> >>It is, but this is not hard data. > > > Actually Ben, it would appear that it is hard data, a dictionary of > the 220,000 most common words in the English and Dutch languages > only has 5% effectiveness. I would have expected a much higher > success rate. This data is hard evidence that a dictionary attack is > not a serious risk. That is, indeed, hard data - but it is not what I was responding to. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 07:51:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08587 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 07:51:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvaWa-0008Gu-Rs for namedroppers-data@psg.com; Fri, 13 Aug 2004 11:47:08 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvaWP-0008Fw-NU for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 11:46:58 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 40439AC8B; Fri, 13 Aug 2004 13:46:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 340A4AC8A; Fri, 13 Aug 2004 13:46:56 +0200 (CEST) Date: Fri, 13 Aug 2004 13:46:56 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Marcos Sanz/Denic <sanz@denic.de> Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <OFBAAC5169.30C38128-ONC1256EEF.00268204-C1256EEF.0028017A@notes.denic.de> Message-ID: <Pine.BSO.4.56.0408131240250.951@trinitario.schlyter.se> References: <OFBAAC5169.30C38128-ONC1256EEF.00268204-C1256EEF.0028017A@notes.denic.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 13 Aug 2004, Marcos Sanz/Denic wrote: > On the heels of Miek's communication about the success of a dictionary > attack on the nl-zone (size ca 1 million), I replicated the attack on the > de-zone (size ca 8 millions). Thanks to Miek for the scripts. > > Based on a combined German-English dictionary with more than 100,000 words > and feeding John the Ripper with it to produce a wider attack base, I was > only able to recover 80,000 domains, accounting to 1% of the total zone. > > I guess it could be postulated that, by means of a dictionary attack, the > amount of the domains that can be recovered from a zone remains constant, > and that its effectivity diminishes inversely proportional to the growing > size of the zone. Another interesting test would be to hash the entire .de zone, and do a 7 character wide (ie. 37^7) bruteforce on the hashes (since it is trivial to enumerate hashes using NSEC++ ). My cpu is capable of about 300000 h/s. So an entire OFFLINE bruteforce takes about 37^7/300000/86400 = 3 days, 16 hrs. To optimise, given that changing salt is costly, a dictionary of truncated, non colliding hashes(bruteforce/salt) can be built, which is 89 Gbyte (or 3Gbyte using rainbow tables), after which lookups are trivial. This is just to show that hashing does not do wonders. Marcos, could you share with us the percentage of the .de zone which have labels < 8 characters ? Thanks, Roy Arends -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 09:14:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13662 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 09:14:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvboO-000KTY-9V for namedroppers-data@psg.com; Fri, 13 Aug 2004 13:09:36 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvboD-000KRs-NR for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 13:09:25 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BvboC-0004x3-N3; Fri, 13 Aug 2004 15:09:24 +0200 In-Reply-To: <Pine.BSO.4.56.0408131240250.951@trinitario.schlyter.se> To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic <sanz@denic.de> Message-ID: <OFC1DC192F.25196DC0-ONC1256EEF.0047E20D-C1256EEF.0048454D@notes.denic.de> Date: Fri, 13 Aug 2004 15:09:23 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 13.08.2004 15:09:24, Serialize complete at 13.08.2004 15:09:24 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Marcos, could you share with us the percentage of the .de zone which have > labels < 8 characters ? Sure. That brute force on the hashes would deliver 13% of the zone. Best, Marcos -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 09:23:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14277 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 09:23:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvbxV-000LWO-Mw for namedroppers-data@psg.com; Fri, 13 Aug 2004 13:19:01 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvbxL-000LVO-43 for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 13:18:51 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 35C78AC8B; Fri, 13 Aug 2004 15:18:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 284B1AC8A; Fri, 13 Aug 2004 15:18:50 +0200 (CEST) Date: Fri, 13 Aug 2004 15:18:50 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Marcos Sanz/Denic <sanz@denic.de> Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <OFC1DC192F.25196DC0-ONC1256EEF.0047E20D-C1256EEF.0048454D@notes.denic.de> Message-ID: <Pine.BSO.4.56.0408131517590.951@trinitario.schlyter.se> References: <OFC1DC192F.25196DC0-ONC1256EEF.0047E20D-C1256EEF.0048454D@notes.denic.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 13 Aug 2004, Marcos Sanz/Denic wrote: > > Marcos, could you share with us the percentage of the .de zone which > have > > labels < 8 characters ? > > Sure. That brute force on the hashes would deliver 13% of the zone. Okay, Not a big vector, 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 09:38:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15241 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 09:38:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvcCp-000NfZ-4G for namedroppers-data@psg.com; Fri, 13 Aug 2004 13:34:51 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvcCe-000Nf0-Jq for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 13:34:40 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BvcCd-0000pc-PW; Fri, 13 Aug 2004 15:34:39 +0200 In-Reply-To: <Pine.BSO.4.56.0408131517590.951@trinitario.schlyter.se> To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic <sanz@denic.de> Message-ID: <OFF4868CDE.4E6A34F9-ONC1256EEF.00493978-C1256EEF.004A9529@notes.denic.de> Date: Fri, 13 Aug 2004 15:34:38 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.5.2|June 01, 2004) at 13.08.2004 15:34:39, Serialize complete at 13.08.2004 15:34:39 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Sure. That brute force on the hashes would deliver 13% of the zone. > > Not a big vector, What had you expected? German words aren't precisely well-known for their information density.. :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 10:15:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18343 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 10:15:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvcl4-0003FT-I5 for namedroppers-data@psg.com; Fri, 13 Aug 2004 14:10:14 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bvckt-0003DR-VT for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 14:10:04 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id BBF5AAC8B; Fri, 13 Aug 2004 16:10:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 79982AC8A; Fri, 13 Aug 2004 16:10:01 +0200 (CEST) Date: Fri, 13 Aug 2004 16:10:01 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Marcos Sanz/Denic <sanz@denic.de> Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <OFF4868CDE.4E6A34F9-ONC1256EEF.00493978-C1256EEF.004A9529@notes.denic.de> Message-ID: <Pine.BSO.4.56.0408131608060.951@trinitario.schlyter.se> References: <OFF4868CDE.4E6A34F9-ONC1256EEF.00493978-C1256EEF.004A9529@notes.denic.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,TRACKER_ID autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 13 Aug 2004, Marcos Sanz/Denic wrote: > > > Sure. That brute force on the hashes would deliver 13% of the zone. > > > > Not a big vector, > > What had you expected? German words aren't precisely well-known for their > information density.. :-) Heh, I still remember the german word for computer: datenverarbeitungsmachine :-) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 11:56:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24690 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 11:56:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BveLa-000IDe-Hh for namedroppers-data@psg.com; Fri, 13 Aug 2004 15:52:02 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BveLP-000ICl-RS for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 15:51:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9719013E11 for <namedroppers@ops.ietf.org>; Fri, 13 Aug 2004 15:51:51 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Fri, 13 Aug 2004 11:08:29 +0100." <E3170ABA91578D0AB1674367@[192.168.100.27]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 13 Aug 2004 15:51:51 +0000 Message-Id: <20040813155151.9719013E11@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... So if we want to show that actually, no, zones like .de are not > enumerable to a great extent now (which is what I believe as well), it > would be good if we had some hard data to show it. you'll have to think like a datamining spammer rather than like a computer science researcher if you want to show what's possible. use a number of sources (inaddr, dictionaries, web crawls, buying lists) and a lot of patience. my own experience in trying to protect our privacy from these people and their methods has given me some respect for their powers, and no respect for "turn off AXFR" as a way to thwart them. they aren't children. they're mean criminal bastards and they fight dirty. but the most important issue to me in this discussion is still "who has a reasonable expectation of privacy?" domainholders do not intend to keep their domains secret -- they have domains so they can use them in public. there is no reasonable expectation of privacy on the part of a domainholder. so, what about the registry? for reasons of competition and scam-attacks against the registry business itself, privacy seems to be desirable at the "compilation" level. dnssec's walkability clearly hurts the business interests of registries. registries clearly have an expectation of privacy. but how reasonable is that expectation? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 12:03:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25114 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 12:03:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BveTK-000JmC-Eo for namedroppers-data@psg.com; Fri, 13 Aug 2004 16:00:02 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BveT9-000Jjh-S3 for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 15:59:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AB49513951 for <namedroppers@ops.ietf.org>; Fri, 13 Aug 2004 15:59:51 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Roy Arends <roy@dnss.ec> of "Fri, 13 Aug 2004 13:46:56 +0200." <Pine.BSO.4.56.0408131240250.951@trinitario.schlyter.se> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 13 Aug 2004 15:59:51 +0000 Message-Id: <20040813155951.AB49513951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Marcos, could you share with us the percentage of the .de zone which have > labels < 8 characters ? <http://www.netsys.com/ietf/1995/3167.html> bears on this somewhat. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 12:40:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27626 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 12:40:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvf1y-000P4J-9A for namedroppers-data@psg.com; Fri, 13 Aug 2004 16:35:50 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bvf0V-000Ot8-IX for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 16:34:19 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C3962C2DA4; Fri, 13 Aug 2004 17:34:18 +0100 (BST) Date: Fri, 13 Aug 2004 17:34:17 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: dictionary attack on nameservers Message-ID: <B52E35B64406E40BD8766354@[192.168.100.27]> In-Reply-To: <20040813155951.AB49513951@sa.vix.com> References: <20040813155951.AB49513951@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 August 2004 15:59 +0000 Paul Vixie <paul@vix.com> wrote: > <http://www.netsys.com/ietf/1995/3167.html> bears on this somewhat. Great quotations. Paul wrote: > There are ~140,000 .COM names today ... > I call .COM "full" because it takes eight (8) characters of typing > before a user has narrowed her possibilities to under 10% of the > total. circa 30m subsequent registrants (now) disagree :-) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 12:40:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27627 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 12:40:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvf3c-000PIr-SU for namedroppers-data@psg.com; Fri, 13 Aug 2004 16:37:32 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bvf34-000PCc-7s for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 16:36:58 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0AC6013E11 for <namedroppers@ops.ietf.org>; Fri, 13 Aug 2004 16:36:58 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Fri, 13 Aug 2004 17:34:17 +0100." <B52E35B64406E40BD8766354@[192.168.100.27]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 13 Aug 2004 16:36:58 +0000 Message-Id: <20040813163658.0AC6013E11@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > <http://www.netsys.com/ietf/1995/3167.html> bears on this somewhat. > > Great quotations. Paul wrote: > > There are ~140,000 .COM names today > ... > > I call .COM "full" because it takes eight (8) characters of typing > > before a user has narrowed her possibilities to under 10% of the > > total. > > circa 30m subsequent registrants (now) disagree :-) i don't think they disagree. i think we gave them no choice. but it's very interesting to study the numbers. this article was not considered controversial at the time it was published. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 12:53:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28581 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 12:53:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvfGZ-0001X6-JC for namedroppers-data@psg.com; Fri, 13 Aug 2004 16:50:55 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvfGO-0001VT-24 for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 16:50:44 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i7DGogFO025934 for <namedroppers@ops.ietf.org>; Fri, 13 Aug 2004 18:50:42 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i7DGogn01638 for <namedroppers@ops.ietf.org>; Fri, 13 Aug 2004 18:50:42 +0200 (MEST) Message-Id: <200408131650.i7DGogn01638@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-reply-to: Paul Vixie's message of "Fri, 13 Aug 2004 15:51:51 -0000." <20040813155151.9719013E11@sa.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1633.1092415839.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Fri, 13 Aug 2004 18:50:42 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > a reasonable expectation of privacy?" domainholders do not intend to > keep their domains secret -- they have domains so they can use them in > public. there is no reasonable expectation of privacy on the part of a There's a difference between "keeping the registration secret" and "not wanting the fact of registration/modification instantly visible". The first may be arguable while the second seems reasonable to me. I'm not sure 'privacy' is the best term to cover this. The 'requirement' then would be that any 'diff' of the zone be not made easier by DNSSEC than it was computable without DNSSEC (whether or not non DNS methods were used or contributed to the collection). -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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 15:23:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08569 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 15:23:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BvhYZ-000O4E-88 for namedroppers-data@psg.com; Fri, 13 Aug 2004 19:17:39 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BvhYN-000O2l-S3 for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 19:17:28 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08078; Fri, 13 Aug 2004 15:17:23 -0400 (EDT) Message-Id: <200408131917.PAA08078@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-05.txt Date: Fri, 13 Aug 2004 15:17:23 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-05.txt Pages : 14 Date : 2004-8-13 A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ecc-key-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ecc-key-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-13153123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-13153123.I-D@ietf.org> --OtherAccess-- --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Aug 13 17:47:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19931 for <dnsext-archive@lists.ietf.org>; Fri, 13 Aug 2004 17:47:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bvjno-000L3L-7U for namedroppers-data@psg.com; Fri, 13 Aug 2004 21:41:32 +0000 Received: from [32.97.182.101] (helo=e1.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bvjnd-000KzI-EW for namedroppers@ops.ietf.org; Fri, 13 Aug 2004 21:41:21 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i7DLfJOZ346916; Fri, 13 Aug 2004 17:41:19 -0400 Received: from IBMTC_S30001313.gis.net (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7DLgUWn119370; Fri, 13 Aug 2004 17:42:31 -0400 Message-Id: <4.3.1.2.20040813173919.02a1a4c8@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 13 Aug 2004 17:40:50 -0400 To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org From: Danny Mayer <mayer@gis.net> Subject: Re: dictionary attack on nameservers In-Reply-To: <20040813155951.AB49513951@sa.vix.com> References: <Message from Roy Arends <roy@dnss.ec> <Pine.BSO.4.56.0408131240250.951@trinitario.schlyter.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:59 AM 8/13/2004, Paul Vixie wrote: > > Marcos, could you share with us the percentage of the .de zone which have > > labels < 8 characters ? > ><http://www.netsys.com/ietf/1995/3167.html> bears on this somewhat. It would be interesting and useful to rerun your perl script on today's .com domain and see the new numbers based on the length of the domain name. 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: <http://ops.ietf.org/lists/namedroppers/> From nv33134@yahoo.com Mon Aug 16 04:28:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17263; Mon, 16 Aug 2004 04:28:09 -0400 (EDT) Date: Mon, 16 Aug 2004 04:28:09 -0400 (EDT) Message-Id: <200408160828.EAA17263@ietf.org> Received: from [218.12.34.234] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bwcw9-0004Tu-2U; Mon, 16 Aug 2004 04:34:08 -0400 Reply-To: "Atualidade Brasileira" <atualidadebrasileira2004@yahoo.com.br> From: "Atualidade Brasileira" <nv33134@yahoo.com> To: AmigosAtualidadeBrasileira@ietf.org Subject: Assistência social e capitalismo: abraço da paz! X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html X-Spam-Score: 31.3 (+++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <TITLE>c0408lind10CapMail

EnCastellano -- FreeAutomaticTranslator

Bom dia, amigos! Assistência social e capitalismo, inimigos ou aliados? Um tema sem dúvida polêmico, abordado por Adolpho Lindenberg. Para enviar sua valiosa opinião, participando de nosso debate, veja os links no final. Atenciosamente, Sergio Lopes, ConstruNews.

Série Temas Patrulhados (10)

Assistência Social e Capitalismo não precisam estar em guerra: podem dar o abraço da paz

A concorrência e a procura do lucro, se contrapõem aos atos caritativos, à justiça social e à benquerença entre os homens? É essa a temática abordada por Adolpho Lindenberg em artigo da Série Temas Patrulhados

A procura do lucro, se contrapõe aos atos caritativos?

* Quando os "progressistas", sempre dispostos a satanizar o sistema de propriedade e livre iniciativa, acusam o capitalismo de ser um sistema baseado no egoísmo e na voracidade do lucro, desinteressado pela sorte dos carentes, vem à mente a figura do banqueiro ou executivo de multinacionais, aferrado aos balanços, mas surdo aos pedidos de socorro dos necessitados...

* Até que ponto este quadro é verdadeiro? A procura do lucro, as leis severas da concorrência, as transações financeiras rigorosas, se contrapõem aos atos caritativos, à justiça social e à benquerença entre os homens? É essa a temática abordada por Adolpho Lindenberg em recente artigo da Série Temas Patrulhados.

"Patrulhamento"

* Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza, "patrulha" ou encobre com um manto de silêncio as opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

Ser solidário, tarefa do capitalista e não do capitalismo

* Para analisar o capitalismo com isenção de ânimo convém lembrar que a função específica de um sistema econômico é produzir riquezas; e com elas, gerar lucros, pagar salários e impostos. Nisso não existe demérito algum.

* A assistência social, tarefa indispensável numa sociedade bem organizada e próspera, não deve ser de responsabilidade dos produtores, enquanto produtores, mas enquanto homens compassivos ou cristãos, obedientes aos conselhos evangélicos de socorrer o próximo.

Distinguir entre produzir e distribuir

* Lindenberg acrescenta que é preciso distinguir entre o ato de produzir e o de distribuir. Não podem ser confundidos, são de natureza diversa, cada um deles obedece a princípios morais próprios. Mais precisamente, a ênfase é diferente. A ética dos homens, enquanto produtores e comerciantes, prescreve que eles sejam diligentes, temperantes, honestos e respeitosos dos direitos de seus clientes e competidores. Nisso, aliás, agem segundo o bem comum.

* Não procede, por conseguinte, a critica de que o capitalismo e solidariedade humana são incompatíveis, ambos podem se somar harmoniosamente!

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em:

EnviarEsteArtigoCompletoGratuitamente(No.10)

Outros temas abordados no artigo:

* "Progressistas" sempre dispostos a satanizar o capitalismo

* Magnanimidade versus prepotência

* A reta procura pelo lucro nada tem de pecaminoso

* Mais capitalismo, mais assistência social

* Ser solidário, tarefa do capitalista e não do capitalismo

* Distinguir entre produzir e distribuir

* Descristianização da sociedade, a grande causa da indiferença para com os pobres

* Solidariedade entre filhos do mesmo Deus

Links de opinião:

Gostaríamos muito de receber seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião (seguem 10 opções):

* Lindenberg:Discrepo - OpiniãoReacionária

* Lindenberg:Concordo - OpiniãoDeBomSenso -

* Lindenberg:EmTermos - PrecisoPensar

Links gratuitos (e-Book e outros artigos):

EnviarEsteArtigoCompletoGratuitamente(No.10)

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Lindenberg:ProximosArtigos

Outros links:

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

From owner-namedroppers@ops.ietf.org Mon Aug 16 08:09:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29509 for ; Mon, 16 Aug 2004 08:09:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwg9S-0002MD-6k for namedroppers-data@psg.com; Mon, 16 Aug 2004 11:59:46 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwg8t-0002GR-6A for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 11:59:11 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id i7GBwxwV014913 for ; Mon, 16 Aug 2004 13:59:01 +0200 (CEST) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) with ESMTP id i7GBwwps029321 for ; Mon, 16 Aug 2004 13:58:58 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-5) id i7GBwvaB029320 for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 13:58:57 +0200 Date: Mon, 16 Aug 2004 13:58:57 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-ID: <20040816115856.GA28679@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 13 Aug, @09:16, Marcos wrote in "Re: dictionary attack on names ..."] > On the heels of Miek's communication about the success of a dictionary just for the curious, I've just done the following: What is the best dictionary on the planet to attack a zone file? Indeed, the .com and .net zone files. So that's what I did, I tried to see how much of .com/.net is in the .nl zone. Note: I did an OFFLINE attack, which took a few hours. (This can be optimized, the script I use is lame) The results: .com contains about 29 million names. After some time I got 495913 names out of the 1187008 names in the NL zone. This is 41.77 percent of the NL zone .net contains 4861825 names. After some time I got 285674 names. That is 24.06 percent of the NL zone. If I combine .com and .net (taking into account some overlap) I get 504758 out of 1187008 names. This is 42.52 percent of NL zone. grtz Miek -- to unsubscribe send a message to namedroppers-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 16 08:55:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01820 for ; Mon, 16 Aug 2004 08:55:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwgyU-0007pZ-AO for namedroppers-data@psg.com; Mon, 16 Aug 2004 12:52:30 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwgyH-0007o9-9I for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 12:52:17 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BwgyG-0000So-00 for ; Mon, 16 Aug 2004 14:52:16 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Aug 2004 14:52:16 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Aug 2004 14:52:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: dictionary attack on nameservers Date: Mon, 16 Aug 2004 14:52:12 +0200 Lines: 24 Message-ID: References: <20040816115856.GA28679@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Sb0feA5QKCpuGqWsswIikltqqKE= X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,COMPARE_RATES autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Miek Gieben writes: > What is the best dictionary on the planet to attack a zone file? > Indeed, the .com and .net zone files. So that's what I did, I tried > to see how much of .com/.net is in the .nl zone. ... > If I combine .com and .net (taking into account some overlap) I get > 504758 out of 1187008 names. This is 42.52 percent of NL zone. Care to repeat this for, e.g., josefsson.org? The zone walking issue is not limited to the zones that are best suitable for dictionary attacks. I believe enumerating small zones is more difficult. Further, it may be more useful to be able to enumerate small zones, compare: Steven M. Bellovin, "Using the Domain Name System for System Break-Ins", in Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT, June, 1995. http://www.research.att.com/~smb/papers/dnshack.pdf Btw, AXFR is permitted for josefsson.org, if you want to compare success rate of a dictionary attack. Thanks, Simon -- to unsubscribe send a message to namedroppers-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 16 14:41:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21288 for ; Mon, 16 Aug 2004 14:41:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwmJY-000JCd-5v for namedroppers-data@psg.com; Mon, 16 Aug 2004 18:34:36 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwmJN-000JBf-J7 for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 18:34:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 65B2413DFF for ; Mon, 16 Aug 2004 18:34:24 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Miek Gieben of "Mon, 16 Aug 2004 13:58:57 +0200." <20040816115856.GA28679@atoom.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 16 Aug 2004 18:34:24 +0000 Message-Id: <20040816183424.65B2413DFF@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > What is the best dictionary on the planet to attack a zone file? > Indeed, the .com and .net zone files. So that's what I did, I tried > to see how much of .com/.net is in the .nl zone. > ... i expect that an ambitious and committed data miner would buy spammer cdroms, run their own web crawlers, buy the ISC Domain Survey (see www.isc.org/ops/ds/) and add both local- and international-language common word dictionaries, along with combinations (with and without hyphens) and abbreviations and misspellings and all kinds of suffixes and prefixes (like number-strings). the hard part of proving this is that to do a proper job, one would have to have the same kind of monetary incentive that a true data miner would have. but that monetary incentive invariably comes with a disincentive to publish one's results and methods. so, unless we can sponsor some kind of contest for creatively minded people (sort of like "capture the flag" or the international programming olympics), the best we'll see published from the academic / research / commercial sector will be derivatives ("i can prove that data miners are using the following methods because there's no other way information X could have been learned and used") or approximations ("i got 20% without even half trying") or guesses ("all useful enumerations are already possible.") -- to unsubscribe send a message to namedroppers-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 16 15:03:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22706 for ; Mon, 16 Aug 2004 15:03:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwmgh-000MJA-DY for namedroppers-data@psg.com; Mon, 16 Aug 2004 18:58:31 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwmgW-000MHy-KJ for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 18:58:20 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (mailer5.verisign.com [65.205.251.54]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7GIwFw5004721; Mon, 16 Aug 2004 11:58:15 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Aug 2004 11:58:15 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Mon, 16 Aug 2004 11:58:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > the hard part of proving this is that to do a proper job, one > would have to have the same kind of monetary incentive that a > true data miner would have. but that monetary incentive > invariably comes with a disincentive to publish one's results > and methods. That is precisely the point. In the real world raising the cost of an attack to the point where it is greater than the expected rewards is a very effective way of discouraging organized crime. The fact that such information is not available today without cost is a demonstration that the existing controls do have an effect. You can design a secure protocol here or you can insist on sticking to a misunderstanding of a 20 year old dogma. The point about the security through obscurity argument was that it applied to discussions of *architecture* not specific configurations. At the time there were people who did not want any discussion of computer security at all at any level. Today we discuss architecture, but nobody openly discusses configuration data and applying the security through obscurity argument at that level is invalid. Phill -- to unsubscribe send a message to namedroppers-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 16 15:32:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25586 for ; Mon, 16 Aug 2004 15:32:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwnAE-000050-Pe for namedroppers-data@psg.com; Mon, 16 Aug 2004 19:29:02 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwnA3-00003Z-Ra for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 19:28:52 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 16 Aug 2004 15:28:49 -0400 id 002F4005.41210AF1.00005794 From: David Blacka Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Date: Mon, 16 Aug 2004 15:28:30 -0400 User-Agent: KMail/1.6.2 References: <20040816183424.65B2413DFF@sa.vix.com> In-Reply-To: <20040816183424.65B2413DFF@sa.vix.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200408161528.30555.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 16 August 2004 2:34 pm, Paul Vixie wrote: > i expect that an ambitious and committed data miner would buy spammer > cdroms, run their own web crawlers, buy the ISC Domain Survey (see > www.isc.org/ops/ds/) and add both local- and international-language > common word dictionaries, along with combinations (with and without > hyphens) and abbreviations and misspellings and all kinds of suffixes > and prefixes (like number-strings). > > the hard part of proving this is that to do a proper job, one would have > to have the same kind of monetary incentive that a true data miner would > have. but that monetary incentive invariably comes with a disincentive > to publish one's results and methods. What are we trying to prove, again? It seems to me that all we need to prove is that for a dictionary attack to be "successful", it requires a non-trivial amount of effort. A point which you seem to already concede, and we seem to be slowly showing. I could be wrong, but it seems to me that the folks arguing for protection against zone enumeration are just asking that zone enumeration not be made worse. So, if it takes a significant amount of effort to enumerate a zone without DNSSEC, and a similarly significant amount of effort to do so with DNSSEC, I think they would all be satisfied. This argument that because a sufficiently creative and determined data miner might be able to enumerate a zone today, we should have no problem making it trivially easy with NSEC chain walking seems either obtuse or disingenuous to me. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-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 16 15:59:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00641 for ; Mon, 16 Aug 2004 15:59:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwnZD-00037c-QI for namedroppers-data@psg.com; Mon, 16 Aug 2004 19:54:51 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwnZ3-00036c-1o for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 19:54:41 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D2FEA13951 for ; Mon, 16 Aug 2004 19:54:40 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from David Blacka of "Mon, 16 Aug 2004 15:28:30 -0400." <200408161528.30555.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 16 Aug 2004 19:54:40 +0000 Message-Id: <20040816195440.D2FEA13951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... > > the hard part of proving this is that to do a proper job, one would have > > to have the same kind of monetary incentive that a true data miner would > > have. but that monetary incentive invariably comes with a disincentive > > to publish one's results and methods. > > What are we trying to prove, again? It seems to me that all we need > to prove is that for a dictionary attack to be "successful", it > requires a non-trivial amount of effort. A point which you seem to > already concede, and we seem to be slowly showing. actually, i don't find "triviality" to be a relevant standard for this. what i want to know (or even prove or disprove) is whether it's already being commonly done and whether putting more effort into avoiding "zone walking" is an instance of the general principle called "closing the barn door after the animals have already escaped." for "triviality" to be a relevant standard, we would have to agree that committed dataminers are less of a privacy threat than uncommitted ones (and i won't agree that this is true) and also agree that committed data- miners aren't going to make a market in domain names by offering them to less committed dataminers (and i won't agree that this is true, either.) > I could be wrong, but it seems to me that the folks arguing for protection > against zone enumeration are just asking that zone enumeration not be made > worse. you're not wrong. but "they" could be looking at this the wrong way. if zone enumeration is already possible, then what exactly are we hoping to "buy" by spending global design and implementation costs "preventing" it? does the incremental benefit outweigh the incremental cost? are you sure? > So, if it takes a significant amount of effort to enumerate a zone > without DNSSEC, and a similarly significant amount of effort to do so > with DNSSEC, I think they would all be satisfied. perhaps. but i would not be satisfied. knowing that it's going to happen either way, and knowing that the entities most affected by it will be a small number of registries and registrars, not domainholders, and knowing that the incremental costs are dramatically huge, makes me want a better cost:benefit analysis than has yet been presented here. > This argument that because a sufficiently creative and determined data > miner might be able to enumerate a zone today, we should have no > problem making it trivially easy with NSEC chain walking seems either > obtuse or disingenuous to me. see above. -- to unsubscribe send a message to namedroppers-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 16 16:18:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03931 for ; Mon, 16 Aug 2004 16:18:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwnrx-0005vl-B0 for namedroppers-data@psg.com; Mon, 16 Aug 2004 20:14:13 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwnre-0005to-JN for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 20:13:54 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 4FD6F144006; Mon, 16 Aug 2004 16:00:29 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id D551914401A; Mon, 16 Aug 2004 16:00:27 -0400 (EDT) Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id C895FCF39A; Mon, 16 Aug 2004 15:55:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200408161528.30555.davidb@verisignlabs.com> References: <20040816183424.65B2413DFF@sa.vix.com> <200408161528.30555.davidb@verisignlabs.com> Date: Mon, 16 Aug 2004 15:55:21 -0400 To: David Blacka From: Edward Lewis Subject: Re: dictionary attack on nameservers Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:28 -0400 8/16/04, David Blacka wrote: >What are we trying to prove, again? It seems to me that all we need to prove >is that for a dictionary attack to be "successful", it requires a non-trivial >amount of effort. A point which you seem to already concede, and we seem to >be slowly showing. Not to argue, but to demonstrate the confusion over this, it's not clear to me that: 'for a dictionary attack to be "successful", it requires a non-trivial amount of effort.' I stress that I don't know...but I've heard that in these days of rooted machines on cable modem networks, "trivial" isn't the issue. (I used to think the solution to spam was simple - make it more expensive to send mail. But if the sender is just 'stealing' machines, such a solution is pointless at best.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 16 17:59:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13678 for ; Mon, 16 Aug 2004 17:59:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwpS7-000HMS-Oe for namedroppers-data@psg.com; Mon, 16 Aug 2004 21:55:39 +0000 Received: from [32.97.182.106] (helo=e6.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwpRw-000HLT-Td for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 21:55:29 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i7GLtRnt340972 for ; Mon, 16 Aug 2004 17:55:27 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i7GLudba045598 for ; Mon, 16 Aug 2004 17:56:39 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.10/8.12.11) with ESMTP id i7GLtQEC021930 for ; Mon, 16 Aug 2004 17:55:26 -0400 Received: from IBMTC_S30001313.gis.net ([9.22.26.62]) by d01av01.pok.ibm.com (8.12.10/8.12.11) with ESMTP id i7GLtPja021904; Mon, 16 Aug 2004 17:55:26 -0400 Message-Id: <4.3.1.2.20040816171200.00bc35a0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 16 Aug 2004 17:54:47 -0400 To: Paul Vixie , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: dictionary attack on nameservers In-Reply-To: <20040816195440.D2FEA13951@sa.vix.com> References: <200408161528.30555.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:54 PM 8/16/2004, Paul Vixie wrote: > > So, if it takes a significant amount of effort to enumerate a zone > > without DNSSEC, and a similarly significant amount of effort to do so > > with DNSSEC, I think they would all be satisfied. > >perhaps. but i would not be satisfied. knowing that it's going to >happen either way, and knowing that the entities most affected by it >will be a small number of registries and registrars, not domainholders, >and knowing that the incremental costs are dramatically huge, makes me >want a better cost:benefit analysis than has yet been presented here. All of this is true, but also remember that the cost/benefit picture is constantly changing as costs of equipment go down, CPU, network speeds go up, domain names increase and the cost and complexity of deploying DNSSEC goes up as this gets discussed. More to the point, what benefit do these people have in getting all these names/addresses? What do they do with it? 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 Mon Aug 16 19:04:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19542 for ; Mon, 16 Aug 2004 19:04:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwqRa-000Owl-3B for namedroppers-data@psg.com; Mon, 16 Aug 2004 22:59:10 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwqRP-000Ovr-6m for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 22:58:59 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 16 Aug 2004 18:58:58 -0400 id 002DC93D.41213C32.000077CE From: David Blacka Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Date: Mon, 16 Aug 2004 18:58:39 -0400 User-Agent: KMail/1.6.2 References: <20040816195440.D2FEA13951@sa.vix.com> In-Reply-To: <20040816195440.D2FEA13951@sa.vix.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200408161858.39761.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 16 August 2004 3:54 pm, Paul Vixie wrote: > > > ... > > > the hard part of proving this is that to do a proper job, one would > > > have to have the same kind of monetary incentive that a true data miner > > > would have. but that monetary incentive invariably comes with a > > > disincentive to publish one's results and methods. > > > > What are we trying to prove, again? It seems to me that all we need > > to prove is that for a dictionary attack to be "successful", it > > requires a non-trivial amount of effort. A point which you seem to > > already concede, and we seem to be slowly showing. > > actually, i don't find "triviality" to be a relevant standard for this. > what i want to know (or even prove or disprove) is whether it's already > being commonly done and whether putting more effort into avoiding "zone > walking" is an instance of the general principle called "closing the barn > door after the animals have already escaped." How do we move this conversation along? From your previous comments, it seems that it is nearly impossible for this group to prove (show) or disprove that successful data mining already occurs. It seems like you are saying: * in order to work on this we must demonstrate A * it is impossible to demonstrate A Am I wrong? If not, where do we go from here? > for "triviality" to be a relevant standard, we would have to agree that > committed dataminers are less of a privacy threat than uncommitted ones > (and i won't agree that this is true) and also agree that committed data- > miners aren't going to make a market in domain names by offering them to > less committed dataminers (and i won't agree that this is true, either.) Valid points. In your mind there is no difference between a world were a few determined folks can get maybe 90% of a zone with effort, and a world where anyone can get 100% of a zone with virtually no effort? Note that I, personally, do not feel very strongly about this issue either way. I was just feeling that the current discussion wasn't all that productive and was hoping (futilely, probably) to redirect it to a more productive path. > you're not wrong. but "they" could be looking at this the wrong way. if > zone enumeration is already possible, then what exactly are we hoping to > "buy" by spending global design and implementation costs "preventing" it? > does the incremental benefit outweigh the incremental cost? are you sure? Trying to find the disconnect here: clearly folks who are worried about zone enumeration do not believe that zone enumeration via data mining is currently successful (for some definition of successful), and they clearly think there is a substantial difference between getting some fraction of a zone and the whole thing. > > So, if it takes a significant amount of effort to enumerate a zone > > without DNSSEC, and a similarly significant amount of effort to do so > > with DNSSEC, I think they would all be satisfied. > > perhaps. but i would not be satisfied. knowing that it's going to > happen either way, and knowing that the entities most affected by it > will be a small number of registries and registrars, not domainholders, > and knowing that the incremental costs are dramatically huge, makes me > want a better cost:benefit analysis than has yet been presented here. I would think that a cost/benefit analysis would be useful, but I've also seen both side fail to agree on either the costs or the benefits. I also think that there are somewhat compelling arguments that this *isn't* just a problem for a small number of registries and registrars. It is clear that you, as a domainholder, don't care, but can you speak for all of the other domainholders? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-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 16 19:09:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19690 for ; Mon, 16 Aug 2004 19:09:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwqYV-00004y-Mn for namedroppers-data@psg.com; Mon, 16 Aug 2004 23:06:19 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwqYL-00002b-6C for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 23:06:09 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 16 Aug 2004 19:06:08 -0400 id 002DC93D.41213DE0.00007919 From: David Blacka Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Date: Mon, 16 Aug 2004 19:05:49 -0400 User-Agent: KMail/1.6.2 References: <20040816183424.65B2413DFF@sa.vix.com> <200408161528.30555.davidb@verisignlabs.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408161905.49461.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 16 August 2004 3:55 pm, Edward Lewis wrote: > At 15:28 -0400 8/16/04, David Blacka wrote: > >What are we trying to prove, again? It seems to me that all we need to > > prove is that for a dictionary attack to be "successful", it requires a > > non-trivial amount of effort. A point which you seem to already concede, > > and we seem to be slowly showing. > > Not to argue, but to demonstrate the confusion over this, it's not > clear to me that: > > 'for a dictionary attack to be "successful", it requires a non-trivial > amount of effort.' > > I stress that I don't know...but I've heard that in these days of > rooted machines on cable modem networks, "trivial" isn't the issue. I guess "trivial" isn't a precise enough term ;) But the cost of doing something is always relevant, even now when some malefactors can marshall an army of zombies. > (I used to think the solution to spam was simple - make it more > expensive to send mail. But if the sender is just 'stealing' > machines, such a solution is pointless at best.) -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-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 16 19:48:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22530 for ; Mon, 16 Aug 2004 19:48:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwr9i-0003yf-B0 for namedroppers-data@psg.com; Mon, 16 Aug 2004 23:44:46 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwr91-0003u7-Gw for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 23:44:03 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2E3A513951 for ; Mon, 16 Aug 2004 23:44:03 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from David Blacka of "Mon, 16 Aug 2004 18:58:39 -0400." <200408161858.39761.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 16 Aug 2004 23:44:03 +0000 Message-Id: <20040816234403.2E3A513951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > How do we move this conversation along? From your previous comments, > it seems that it is nearly impossible for this group to prove (show) > or disprove that successful data mining already occurs. > > It seems like you are saying: > * in order to work on this we must demonstrate A > * it is impossible to demonstrate A > > Am I wrong? If not, where do we go from here? i'm not sure. i'm one of those to whom "A" (in this example) is trivially observable and a well known and well documented fact. but i am afraid that it's not as trivially observable by others as it is by "the antispam crowd", and that _objective_ proof might be hard to come by. i keep hoping that we will somehow reach agreement, or find a different basis on which to close the gap. see my separate post today about a possible "datamining olympiad". > ... In your mind there is no difference between a world were a few > determined folks can get maybe 90% of a zone with effort, and a world > where anyone can get 100% of a zone with virtually no effort? there is some difference, but it's smaller than the difference in cost between "the 10-year dnssec" and "the 15-year dnssec". > Trying to find the disconnect here: clearly folks who are worried > about zone enumeration do not believe that zone enumeration via data > mining is currently successful (for some definition of successful), > and they clearly think there is a substantial difference between > getting some fraction of a zone and the whole thing. yes. or they think there's a whole subpopulation of chickenboner dataminers who don't have the fortitude to gather the data using pre-dnssec methods, who will jump on the bandwagon once the bar is lowered (to "zone walking"), and they somehow think the number and kind of attacks they're getting now is more refined and more deliberate than the kind of attacks they'll get once the chickenboners are allowed to play. there may be merit in that, but i don't expect to see arguments about these "shades of gray". (in public.) > I also think that there are somewhat compelling arguments that this > *isn't* just a problem for a small number of registries and > registrars. It is clear that you, as a domainholder, don't care, but > can you speak for all of the other domainholders? well, let's open up the ol' archives and take a look-see on that topic. in message <20040526143417.71CEC13E48@sa.vix.com> on 26-may-2004, i wrote: | in my day job, i'm in touch with a lot of enterprise dns users, and | they universally tell me that the data and/or names they consider | sensitive enough to worry about axfr or zonewalking, would also be | dangerous for queries, and so they run "split dns" so that only | internal hosts can see the data. they've turned off external axfr | because it's unnecessary, not because it would expose data they care | deeply about keeping private. the data they care deeply about keeping | private is only available "internally." (i also proposed a survey and offered to run it, but received no words of encouragement or even acknowledgement that these issues mattered, so i've done nothing more on this thread to date.) then later on (3-aug-2004) i wrote: | consider that almost any use made of a domain will subject it to | public view, where it can be and will be recorded. consider that many | uses of this data are benign or even well intended, like measurements | or search engines. consider that every bad use (UCE, etc) can be and | will be made whether obscurity is used or not. | | if you have information you don't want the world to know the name of, | then don't put it in dns at all, or use "split dns" to limit the | viewability of this data to small trusted population such as your | intranet. so, i'm not sure whether i speak for all domainholders, but certainly "many" and i'm still willing to help discover "how many" if there's encouragement and if it begins to seem that this is generally relevant "design data". -- to unsubscribe send a message to namedroppers-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 16 20:04:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23646 for ; Mon, 16 Aug 2004 20:04:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwrO6-00061o-5c for namedroppers-data@psg.com; Mon, 16 Aug 2004 23:59:38 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwrNv-00060L-Fj for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 23:59:27 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7GNxQJT017680; Mon, 16 Aug 2004 16:59:26 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Aug 2004 16:59:26 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Mon, 16 Aug 2004 16:59:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk y concede, and we seem to be slowly showing. > > actually, i don't find "triviality" to be a relevant standard > for this. > what i want to know (or even prove or disprove) is whether > it's already > being commonly done and whether putting more effort into > avoiding "zone > walking" is an instance of the general principle called > "closing the barn > door after the animals have already escaped." We know that it is not currently happening at the level of the delegated domains. Deploying DNSSEC in the TLDs is kinda pointless unless the security concious delegated domains want to join in. I don't intend to waste my time as an advocate for a system that provides an intangible long term benefit at the cost of an obvious and solvable near term benefit. And I don't think that many other security specialists will either. One of the reasons I am arguing about the topic here is that it is obvious to me as a security specialist that this issue is going to be solved sooner or later. Ergo it is obvious that the spec will not be finished until this happens. As Karl Marx put it: The philosophers have only interpreted the world in various ways; the point, however, is to change 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 Mon Aug 16 20:11:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23928 for ; Mon, 16 Aug 2004 20:11:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwrW1-0007Nl-Jw for namedroppers-data@psg.com; Tue, 17 Aug 2004 00:07:49 +0000 Received: from [217.77.131.3] (helo=universe.dnssec.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwrVq-0007LL-Lc for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 00:07:38 +0000 Received: by universe.dnssec.net (universe.dnssec.net, from userid 1001) id 80C8D6E708; Tue, 17 Aug 2004 02:07:37 +0200 (CEST) Date: Tue, 17 Aug 2004 02:07:37 +0200 From: Jacco Tunnissen To: namedroppers@ops.ietf.org Subject: Status of DNSSEC.net website Message-ID: <20040817000737.GB18051@universe.dnssec.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, For a few years already, DNSSEC.net is an independent starting point referring all major DNSSEC publications, presentations, articles, theses, tools/software, RFCs and drafts. Since the start, I've added a lot of material to the resources: material from the DNSEXT participants, articles from the press, all drafts, and more. In fact so much info, that new categories were necessary to streamline the information. These new categories are now there. During the coming months, some new categories with "quick reference" material for DNS administrators will be added. They'll include practical steps, hints and tips for implementing DNSSEC in the ISP and business environment (targeted mainly at people having some knowledge of DNS already). As always, I'm open to suggestions from the DNSEXT community for further improvement of the website. So continue to let me know if you have new material for one of the categories. Thanks, Jacco Tunnissen -- DNSSEC - http://www.dnssec.net/ Securing the Domain Name System -- to unsubscribe send a message to namedroppers-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 16 21:06:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26188 for ; Mon, 16 Aug 2004 21:06:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwsNb-000DTn-FM for namedroppers-data@psg.com; Tue, 17 Aug 2004 01:03:11 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwsNA-000DPx-Nq for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 01:02:44 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7H12eJw021753; Mon, 16 Aug 2004 18:02:40 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Aug 2004 18:02:39 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Danny Mayer'" , Paul Vixie , namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Mon, 16 Aug 2004 18:02:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > More to the point, what benefit do these people have in > getting all these > names/addresses? What do they do with it? In the case of a business operating split DNS as example.com they discover the names and addresses of all the machines that are externally accessible. If the gang is a DDoS extortion racket they can then DDoS the systems that perform the business processes of example.com until such time as the company pays over $50,000 by making money transfers to a bank in Eastern Europe where the cash is then picked up by co-conspirators. If I am doing Web Services and a machine is DDoS attacked my first recourse is likely to be to change the IP address and DNS name of the service and update the Web Service description in the UDDI directory which is an access controlled resource. If the DDoS returns I am then going to look at the UDDI directory logs to see which parties retreived the new location. At that point I respond to attacks by introducing multiple names on different IP addresses and keep changing arround until the sources of the attack have been isolated. I can defend against this attack in the real world, but not if the DNS zone example.com is trivially enumerable. -- to unsubscribe send a message to namedroppers-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 16 23:18:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03292 for ; Mon, 16 Aug 2004 23:18:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwuON-0003lw-UE for namedroppers-data@psg.com; Tue, 17 Aug 2004 03:12:07 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwuOD-0003lI-CU for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 03:11:57 +0000 Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7H3Buj29049 for ; Mon, 16 Aug 2004 20:11:56 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i7H3BuQI027873 for namedroppers@ops.ietf.org; Mon, 16 Aug 2004 20:11:56 -0700 Date: Mon, 16 Aug 2004 20:11:56 -0700 From: kent@songbird.com To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-ID: <20040817031155.GD8786@raven.songbird.com> Mail-Followup-To: namedroppers@ops.ietf.org References: <200408161858.39761.davidb@verisignlabs.com> <20040816234403.2E3A513951@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040816234403.2E3A513951@sa.vix.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Aug 16, 2004 at 11:44:03PM +0000, Paul Vixie wrote: > in message <20040526143417.71CEC13E48@sa.vix.com> on 26-may-2004, i wrote: > > | in my day job, i'm in touch with a lot of enterprise dns users, and ******************** Unfortunately, this doesn't tell us anything about "non-enterprise dns users" -- which I will defins as smaller organizations/businesses that are big enough to run their own dns, but not big enough to keep heavy duty dns gurus on their staff. [...] > | if you have information you don't want the world to know the name of, > | then don't put it in dns at all, or use "split dns" to limit the > | viewability of this data to small trusted population such as your > | intranet. In my experience, "split dns" most frequently accompanies firewalling of some kind, and thus there are subtantial other considerations in addition to simply hiding names. Presuming that there is no firewalling going on, and that a finer granularity than "insider vs outsider" is not desired, how is split dns superior to simply denying axfers? > so, i'm not sure whether i speak for all domainholders, but certainly "many" > and i'm still willing to help discover "how many" if there's encouragement > and if it begins to seem that this is generally relevant "design data". How would you survey the registrants described above, the "non-enterprise dns users"? Regards Kent -- kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.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 16 23:36:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04156 for ; Mon, 16 Aug 2004 23:36:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwuij-00062C-37 for namedroppers-data@psg.com; Tue, 17 Aug 2004 03:33:09 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwuiI-0005yQ-Dz for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 03:32:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3D67413E11 for ; Tue, 17 Aug 2004 03:32:42 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from kent@songbird.com of "Mon, 16 Aug 2004 20:11:56 MST." <20040817031155.GD8786@raven.songbird.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 17 Aug 2004 03:32:42 +0000 Message-Id: <20040817033242.3D67413E11@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > | in my day job, i'm in touch with a lot of enterprise dns users, and > ******************** > > Unfortunately, this doesn't tell us anything about "non-enterprise dns > users" -- which I will defins as smaller organizations/businesses that > are big enough to run their own dns, but not big enough to keep heavy > duty dns gurus on their staff. your definition is entirely local to you, in that case. since i brought it up, let me explain what i meant. "non-isp's who run their own name servers". they don't have to be using bind and they don't have to be large. they could be home/hobby users. i never realized how many of these folks would exist when i first starting fixing bind bugs in ~1989. but in the time since then, through consulting, rfc writing, private and public e-mail, usenet, and now isc's paid support programme, i've met a l-l-lotta these folks. i hope i've even met a representative sample of them. > > so, i'm not sure whether i speak for all domainholders, but > > certainly "many" and i'm still willing to help discover "how many" > > if there's encouragement and if it begins to seem that this is > > generally relevant "design data". > > How would you survey the registrants described above, the > "non-enterprise dns users"? given your somewhat localized definition of "non-enterprise", which is neither similar to nor compatible with my own, i have no freaking idea. but assuming that we're just interested in an objective study, we'd have to agree on what the survey questions should be, find someone to run the survey who we think is above suspicion of data-tampering, write the survey, and then publicize it far and wide. to all the usual internet mailing lists and usenet newsgroups; through vendors to their customer lists; through the ITU to their members. pretty much the only publicity i'd say is nonnegotiably "off the table" would be spamming it. we'd want to get a few thousand responses and we'd want to have some comfort that we didn't leave anybody out. such a survey might take three months. -- to unsubscribe send a message to namedroppers-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 17 02:13:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20054 for ; Tue, 17 Aug 2004 02:13:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwx8y-0000Ul-Jn for namedroppers-data@psg.com; Tue, 17 Aug 2004 06:08:24 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwx8n-0000TQ-N0 for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 06:08:13 +0000 Received: from 192.168.1.10 ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 17 Aug 2004 02:08:10 -0400 id 002F402F.4121A0CA.000035EB From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Date: Tue, 17 Aug 2004 02:08:04 -0400 User-Agent: KMail/1.5.4 References: <20040816234403.2E3A513951@sa.vix.com> In-Reply-To: <20040816234403.2E3A513951@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200408170208.04644.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 16 August 2004 7:44 pm, Paul Vixie wrote: > > How do we move this conversation along? From your previous comments, > > it seems that it is nearly impossible for this group to prove (show) > > or disprove that successful data mining already occurs. > > > > It seems like you are saying: > > * in order to work on this we must demonstrate A > > * it is impossible to demonstrate A > > > > Am I wrong? If not, where do we go from here? > > i'm not sure. i'm one of those to whom "A" (in this example) is trivially > observable and a well known and well documented fact. but i am afraid that > it's not as trivially observable by others as it is by "the antispam > crowd", and that _objective_ proof might be hard to come by. i keep hoping > that we will somehow reach agreement, or find a different basis on which to > close the gap. see my separate post today about a possible "datamining > olympiad". At this point, I am concerned that what you are talking about and what they are talking about does not seem to be the same thing. (or maybe you are and I've just read more into some folks postings than I should've.) What I hear you (and some others) saying is: There is obviously datamining and attacks stemming from that datamining now. Partial (or total?) zone enumeration is possible today using such techniques, so: zone enumeration via DNSSECbis will not substantially change the threat model present on the Internet. Thus, it is not worth the engineering pain to try and stop it. What I hear the folks concerned about datamining at the registry/rar level saying is: There may be datamining, but we don't want to be part of the problem. DNSSECbis forces us to be part of the problem. At some level, I see this argument as: * group A says: we have this policy against zone enumeration. We cannot deploy DNSSECbis because of it. * group B says: your policy is stupid, change it. Either we need to convince group A that their policy is, in fact, stupid, or we need to solve the problem. Or just leave them behind. > > Trying to find the disconnect here: clearly folks who are worried > > about zone enumeration do not believe that zone enumeration via data > > mining is currently successful (for some definition of successful), > > and they clearly think there is a substantial difference between > > getting some fraction of a zone and the whole thing. Just to press down a bit further: do you see no substantial difference between being able to get 100% of a zone vs. getting perhaps 80% via datamining? This is, I think, a major disconnect. I know that in my own experience I've seen malefactors using readily available TLD zone files to find newly registered domain to make their own activities more efficient. > > I also think that there are somewhat compelling arguments that this > > *isn't* just a problem for a small number of registries and > > registrars. It is clear that you, as a domainholder, don't care, but > > can you speak for all of the other domainholders? > so, i'm not sure whether i speak for all domainholders, but certainly > "many" and i'm still willing to help discover "how many" if there's > encouragement and if it begins to seem that this is generally relevant > "design data". I don't know how relevant it is. At this point, it is mostly just part of your argument, and this part of the argument would be more compelling if it were less anecdotal. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-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 17 03:46:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28036 for ; Tue, 17 Aug 2004 03:46:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwybT-000Bud-6G for namedroppers-data@psg.com; Tue, 17 Aug 2004 07:41:55 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwybI-000Bt0-8z for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 07:41:44 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 08792C2DFC; Tue, 17 Aug 2004 08:41:43 +0100 (BST) Date: Tue, 17 Aug 2004 08:41:37 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <4A09E2E9CEDAD298DD45B654@[192.168.100.27]> In-Reply-To: <20040816234403.2E3A513951@sa.vix.com> References: <20040816234403.2E3A513951@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 16 August 2004 23:44 +0000 Paul Vixie wrote: >> It seems like you are saying: >> * in order to work on this we must demonstrate A >> * it is impossible to demonstrate A >> >> Am I wrong? If not, where do we go from here? > > i'm not sure. i'm one of those to whom "A" (in this example) is trivially > observable Let me get this straight: you are saying a dictionary attack (or some other enumeration attack) on say .de (or .uk or .nl) is "trivially observable", but despite its triviality, you haven't posted any data to support it? Can you post the exact methodology and how many names from (say) .de can you recover using this method? I am prepared to accept David Blacka's contention (if I understand it) that it is impossible to either prove that an effective attack either can or cannot currently occur (or rather that it's difficult so to prove/disprove) but if your position is that it is possible to prove it by trivial example, let's see it. If David is right, then at the most generous, DNSSEC enumerability turns a risk of effective enumerability into a certainty. 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 17 04:17:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29830 for ; Tue, 17 Aug 2004 04:16:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwz6B-000GMW-KY for namedroppers-data@psg.com; Tue, 17 Aug 2004 08:13:39 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwz60-000GLS-9l for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 08:13:28 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id i7H8DLfV055363 for ; Tue, 17 Aug 2004 10:13:21 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.13.1/8.13.1/Submit) id i7H8DLUZ055362 for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 10:13:21 +0200 (CEST) (envelope-from ted) Message-Id: <200408170813.i7H8DLUZ055362@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Tue, 17 Aug 2004 10:13:20 +0200 In-Reply-To: "David Blacka's message as of Aug 17, 8:14" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting David Blacka, on Aug 17, 8:14, in "Re: dictionary attac ..."] > At some level, I see this argument as: > * group A says: we have this policy against zone enumeration. We cannot > deploy DNSSECbis because of it. > * group B says: your policy is stupid, change it. > > Either we need to convince group A that their policy is, in fact, stupid, or > we need to solve the problem. Or just leave them behind. I think your analysis is correct. A small addition: when left behind, the group A-TLDs will later get questions from their domainholders like "why can't we have secure domainnames?". I am interested whether their domainholders will understand and be happy with an answer like "we can not deploy domainname security, because the zonefile then gets enumerable". > Just to press down a bit further: do you see no substantial difference between > being able to get 100% of a zone vs. getting perhaps 80% via datamining? My personal opinion (based on having been ISP from 1983 to 1999, one of the founders of the current .nl registry, and still being involved in DNS) is that there will be no substantial difference. What we see is: 1. Spammers They are interested in e-mail addresses. Both the quality and quantity of acquired e-mail addresses from domainname-mining (i.e. hostmasters via whois, etc.) is low compared to other means of acquiring e-mail addresses in bulk. 2. Domainname traders They are not interested in a complete list, they are only interested in when an "interesting" domainname is released.. To know this as soon as possible (i.e. before their competition), they probe their list of names at short intervals (clearly visible in the nameserver traces). And we indeed see them register those released names immediately after being (negatively) probed. Fully automated... 3. Attackers, being script kiddy's and others. These gals and guys usually probe ranges of IP-adresses, not domainnames. For the three threats above, enumerability or non-enumerability makes no difference. I am still quite interested in the threatmodel of group A above, and the exact requirements to defeat those threats (including their estimated effectiveness), because I am perhaps missing something. Regards, -- ted -- to unsubscribe send a message to namedroppers-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 17 04:49:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01509 for ; Tue, 17 Aug 2004 04:49:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bwzay-000KBS-3G for namedroppers-data@psg.com; Tue, 17 Aug 2004 08:45:28 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwzam-000KAj-Bz for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 08:45:16 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i7H8jDqJ019973; Tue, 17 Aug 2004 09:45:13 +0100 (BST) To: Alex Bligh cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh of "Tue, 17 Aug 2004 08:41:37 BST." <4A09E2E9CEDAD298DD45B654@[192.168.100.27]> Date: Tue, 17 Aug 2004 09:45:13 +0100 Message-ID: <19972.1092732313@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Alex" == Alex Bligh writes: Alex> DNSSEC enumerability turns a risk of effective enumerability Alex> into a certainty. So get over it :-) Zone enumeration is already a fact of life. The quick and dirty dictionary attacks mounted by Marcos and Miek have been fairly effective. A more concerted effort would yield even more of the TLD. And a dictionary attack -- comparable to brute-forcing a DES key in its crudeness -- isn't the only way of enumerating a TLD. Most of those other techniques don't care either way about NSEC and won't go away if NSEC gets superseded with some flavour if NSEC++. To get things back on-track, the WG needs to answer these two questions: [1] Does the inevitability of NSEC walking create technical or protocol problems? [Sure, it creates a deployment problem for some TLDs but for policy, not technical, reasons.] [2] Is it worth the time and effort to "fix" NSEC walking -- and no doubt hold up the deployment of a Secure DNS for maybe another 5 years -- when this issue only creates *policy* difficulties for a small number of admittedly very significant corner cases? IMO the answer to both questions is no. It would also be interesting to find out from the owners of domain names in .de and .uk what they'd prefer: securing the DNS for their zones or preventing Bad People from generating a copy of the TLD. -- to unsubscribe send a message to namedroppers-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 17 07:29:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08204 for ; Tue, 17 Aug 2004 07:29:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx249-000EiO-AN for namedroppers-data@psg.com; Tue, 17 Aug 2004 11:23:45 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx23y-000EhR-LB for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 11:23:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i7HBNSnw021962; Tue, 17 Aug 2004 11:23:28 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i7HBNS58021961; Tue, 17 Aug 2004 11:23:28 GMT Date: Tue, 17 Aug 2004 11:23:28 +0000 From: bmanning@vacation.karoshi.com To: Alex Bligh Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: dictionary attacks Message-ID: <20040817112328.GA21889@vacation.karoshi.com.> References: <20040816234403.2E3A513951@sa.vix.com> <4A09E2E9CEDAD298DD45B654@[192.168.100.27]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A09E2E9CEDAD298DD45B654@[192.168.100.27]> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I am prepared to accept David Blacka's contention (if I understand it) that > it is impossible to either prove that an effective attack either can or _________ Alex, you/we apparently do not share a common view of what is "effective" and I expect that Paul's "blackhat" community has the same problem. Effective is in the eye of the user. 2% successful enumeration may be effective for some while 95% enumeration is not successful for others. Then there are the other, obliquely mentioned factors that must be considered: ) zone size. 2% of a 70million entry zone might be ok, while 2% of a zone of 10 entries might be less useful. ) zone "churn". the persistance of zone entries is a trigger for how effective "slow-scan" enumeration is. If I can be assured that data I collected in 1997 is still going to be in the zone, I can focus on enumerating the parts of the zone that are more dynamic. mitigation of enumeration capability isa slippery slope. where are the boundaries? AXFR may be one end - normal queries at the other. before spending excessive time on designing a technical solution, can folks pick a defenseable point on the slope? (blocking AXFR has a defensable point, but only for very large zones. keeping TCP sessions open for hours to move a 70m entry zone is likely a bad idea, esp when the zone changes every 15 minutes. This is a reason to block AXFRs) > Alex --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 Tue Aug 17 10:11:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17339 for ; Tue, 17 Aug 2004 10:11:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx4Z3-000A3U-FT for namedroppers-data@psg.com; Tue, 17 Aug 2004 14:03:49 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx4Ys-000A1i-Ok for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 14:03:38 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7HE3bVa022366 for ; Tue, 17 Aug 2004 07:03:38 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Aug 2004 07:03:37 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Tue, 17 Aug 2004 07:03:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 3. Attackers, being script kiddy's and others. These gals and > guys usually probe ranges of IP-adresses, not domainnames. Please, you are five years out of date here. The Juvenile delinquents of the 1990s have grown up and some of them are supporting their family through crime. The problem today is NOT script kiddies. The problem is comming from organized crime gangs in Eastern Europe, Russia, West Africa and Boca Raton Florida. These people have long criminal histories and they have brought age old frauds to the net. DDoS extortion is simply an updated form of protection racket. Advance fee fraud dates back to the crusades. Phill -- to unsubscribe send a message to namedroppers-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 17 10:50:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20622 for ; Tue, 17 Aug 2004 10:50:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx5Dj-000F71-N6 for namedroppers-data@psg.com; Tue, 17 Aug 2004 14:45:51 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx5DY-000F5K-U8 for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 14:45:41 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id i7HEjabf069722; Tue, 17 Aug 2004 16:45:36 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.13.1/8.13.1/Submit) id i7HEjZhc069721; Tue, 17 Aug 2004 16:45:35 +0200 (CEST) (envelope-from ted) Message-Id: <200408171445.i7HEjZhc069721@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Tue, 17 Aug 2004 16:45:35 +0200 In-Reply-To: ""Hallam-Baker, Phillip"'s message as of Aug 17, 16:15" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting "Hallam-Baker, Phillip", on Aug 17, 16:15, in "RE: dictionary attac ..."] > > > 3. Attackers, being script kiddy's and others. These gals and > > guys usually probe ranges of IP-adresses, not domainnames. > > Please, you are five years out of date here. The Juvenile delinquents > of the 1990s have grown up and some of them are supporting their > family through crime. > > The problem today is NOT script kiddies. The problem is comming from > organized crime gangs in Eastern Europe, Russia, West Africa and > Boca Raton Florida. > > These people have long criminal histories and they have brought age > old frauds to the net. DDoS extortion is simply an updated form of > protection racket. Advance fee fraud dates back to the crusades. Phillip, I'm affraid that I don't understand what link you see between "organized crime gangs in Eastern Europe, Russia, West Africa and Boca Raton Florida" and the difference between 20, 50, 80, 90, 99, or 100% enumerability of zonefiles (which is what the discussion is or was about, I thought). If new requirements for DNS and/or DNSSEC are needed to cope with these new forms of criminality, please specify those requirements. Only if those requirements are expected to be effective and cost-worthy, we should start planning on further definition, implementation and deployment. Sofar, it looks like very costly ghost-hunting. -- ted -- to unsubscribe send a message to namedroppers-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 17 11:02:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21588 for ; Tue, 17 Aug 2004 11:02:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx5Pt-000GvU-69 for namedroppers-data@psg.com; Tue, 17 Aug 2004 14:58:25 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx5Pi-000Gtf-EQ for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 14:58:14 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 17 Aug 2004 10:58:13 -0400 id 002F400D.41221D05.0000145A From: David Blacka Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Date: Tue, 17 Aug 2004 10:57:54 -0400 User-Agent: KMail/1.6.2 References: <19972.1092732313@gromit.rfc1035.com> In-Reply-To: <19972.1092732313@gromit.rfc1035.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200408171057.54235.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 17 August 2004 4:45 am, Jim Reid wrote: > To get things back on-track, the WG needs to answer these two > questions: > > [1] Does the inevitability of NSEC walking create technical or > protocol problems? [Sure, it creates a deployment problem for some > TLDs but for policy, not technical, reasons.] I disagree. I think the WG has answered this question: No. This is why we advanced the DNSSECbis documents. The real question here is: Does the NSEC walking issue create a significant deployment problem? Granted, this question is much harder to answer. > [2] Is it worth the time and effort to "fix" NSEC walking -- and no > doubt hold up the deployment of a Secure DNS for maybe another 5 years > -- when this issue only creates *policy* difficulties for a small > number of admittedly very significant corner cases? Whose time and effort? Yours? No one can force you to work on the problem. But the way the question is phrased make me wonder if the causality is backwards. The question says that working on the zone enumeration will hold up DNSSEC deployment. Maybe, instead, people want to work on the problem because the problem will hold up DNSSEC deployment. > IMO the answer to both questions is no. > > It would also be interesting to find out from the owners of domain > names in .de and .uk what they'd prefer: securing the DNS for their > zones or preventing Bad People from generating a copy of the TLD. Don't we know this answer, too? Clearly, they would rather not make that choice, but what I hear co.uk saying is that for now they would prefer to prevent zone enumeration. Not solving this problem makes everyone make this choice. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-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 17 11:16:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22355 for ; Tue, 17 Aug 2004 11:16:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx5dK-000Ivr-1T for namedroppers-data@psg.com; Tue, 17 Aug 2004 15:12:18 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx5cN-000Io8-9c for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 15:11:19 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7HFB7oJ026676; Tue, 17 Aug 2004 08:11:10 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Aug 2004 08:11:07 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'ted@NLnetLabs.nl'" , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Tue, 17 Aug 2004 08:11:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm affraid that I don't understand what link you see between > "organized crime gangs in Eastern Europe, Russia, West Africa and > Boca Raton Florida" and the difference between 20, 50, 80, 90, 99, > or 100% enumerability of zonefiles (which is what the discussion > is or was about, I thought). You asserted that the issue was script kiddies. This is an out of date assesment of Internet crime, the problem today is from organized crime. I don't think that any of the people claiming that enumeration is not an issue have an understanding of todays internet use and todays internet threats. Pauls blithe assertions that because he has people to run a web server for enterprises he knows everything about everything does not impress me. When a Fortune 50 company is going to discuss its security concerns they do not call in a dns specialist, they call in a security specialist. There is an easy way we could settle this argument, lets call up some F50 security specialists and ask them for their opinion. > If new requirements for DNS and/or DNSSEC are needed to cope with > these new forms of criminality, please specify those requirements. > Only if those requirements are expected to be effective and > cost-worthy, we should start planning on further definition, > implementation and deployment. Sofar, it looks like very costly > ghost-hunting. The attacks that are common from organized crime target specific infrastructures with the objective of making money for the attackers. With guaranteed 100% enumerability an attacker can easily map out the entire configuration of the target site DMZ in a matter of minutes. The DMZ machines have to maintain externally visible DNS links, it is essential for their function. Split DNS is not an option here. -- to unsubscribe send a message to namedroppers-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 17 12:07:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25520 for ; Tue, 17 Aug 2004 12:07:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx6RB-000PTz-8Z for namedroppers-data@psg.com; Tue, 17 Aug 2004 16:03:49 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx6Qs-000PN2-Gr for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 16:03:30 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id C3FC71438FC; Tue, 17 Aug 2004 11:49:51 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id 33F611438F0; Tue, 17 Aug 2004 11:49:51 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 03099CF39A; Tue, 17 Aug 2004 12:03:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 17 Aug 2004 12:03:27 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: hopefully was RE: dictionary attack on nameservers Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As a bystander to this thread, my reaction has been largely "so what?" As a protocol analyst, I don't care how motivated or how efficient the attacker is. All I care to do is see if I can remove the offending feature. My question remains: Is there a way to prove the non-existence of a name without - exposing any of the contents of the zone? - muddying up the name space with fake names or data sets? - on-line cryptographic operations? - being vulnerable to replay attacks of the negative answer? If there were a way to avoid all four, that'd be the answer. NSEC avoids 3 of 4 of them (that's better than Meatloaf's declaration "2 out of 3 ain't bad"). Other approaches avoid a different 3 of 4. Note that "- a change to the protocol" isn't on my list. That's important too, but it's an institutional issue (IETF) not a physics (protocol) issue. If we can't get the physics right, we ain't going to get the institution right. (I suppose I should wait until the requirements come out before asking if there's a 4 of 4 solution. But, once the requirements do - that's what I'll be looking for.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 17 12:47:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28701 for ; Tue, 17 Aug 2004 12:47:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx72J-0003wC-Dp for namedroppers-data@psg.com; Tue, 17 Aug 2004 16:42:11 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx728-0003us-4U for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 16:42:00 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i7HGfwqJ020351; Tue, 17 Aug 2004 17:41:58 +0100 (BST) To: David Blacka cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from David Blacka of "Tue, 17 Aug 2004 10:57:54 EDT." <200408171057.54235.davidb@verisignlabs.com> Date: Tue, 17 Aug 2004 17:41:58 +0100 Message-ID: <20350.1092760918@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "David" == David Blacka writes: >> [2] Is it worth the time and effort to "fix" NSEC walking -- >> and no doubt hold up the deployment of a Secure DNS for maybe >> another 5 years -- when this issue only creates *policy* >> difficulties for a small number of admittedly very significant >> corner cases? David> Whose time and effort? Yours? No one can force you to David> work on the problem. That's certainly true. Not that I could contribute much anyway. But this is beside the point. We have a DNS infrastructure that's not secure. The longer we delay the deployment of DNSSEC (for some definition of "deployment" and "DNSSEC"), the more likely it is Something Very Bad will happen. It's only a question of time before the script kiddies start to attack the DNS. The current drafts are good enough IMO and it's time the WG took an engineering decision to stop tinkering with the protocol and got down to work on the deployment and migration issues. David> But the way the question is phrased make me wonder if the David> causality is backwards. The question says that working on David> the zone enumeration will hold up DNSSEC deployment. David> Maybe, instead, people want to work on the problem because David> the problem will hold up DNSSEC deployment. Hmm: is the glass half-empty or half-full? I suppose it depends where someone is looking from. >> It would also be interesting to find out from the owners of >> domain names in .de and .uk what they'd prefer: securing the >> DNS for their zones or preventing Bad People from generating a >> copy of the TLD. David> Don't we know this answer, too? Clearly, they would rather David> not make that choice, but what I hear co.uk saying is that David> for now they would prefer to prevent zone enumeration. The co.uk policy committee is saying this. Which is not necessarily the same thing as the punters who have registered domain names under co.uk. I wonder how many of them will be content that their zones remain unsecured because the policy committee believes preventing zone enumeration by NSEC traversal is more important than getting the co.uk zone signed? "It's a pity you lost millions and alienated your customers because somebody spoofed the DNS data for BigBank.co.uk. But don't worry. Spammers can't get a copy of co.uk by walking the NSECs. That'll make you feel better." -- to unsubscribe send a message to namedroppers-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 17 13:28:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01609 for ; Tue, 17 Aug 2004 13:28:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx7gO-0009Fj-Bv for namedroppers-data@psg.com; Tue, 17 Aug 2004 17:23:36 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx7gD-0009EV-Nt for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 17:23:25 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7HHNOpK005439; Tue, 17 Aug 2004 10:23:25 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Aug 2004 10:23:24 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Jim Reid'" , David Blacka Cc: namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Tue, 17 Aug 2004 10:23:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > That's certainly true. Not that I could contribute much anyway. But > this is beside the point. We have a DNS infrastructure that's not > secure. The longer we delay the deployment of DNSSEC (for some > definition of "deployment" and "DNSSEC"), the more likely it is > Something Very Bad will happen. It's only a question of time before > the script kiddies start to attack the DNS. Then the sooner we have a DNSSEC specification that is ready for deployment the better. That means fixing security issues, not burrying your head in the sand claiming that they do not exist. The sooner the enumeration issue is fixed, the sooner we can start on deployment. Until the enumeration issue is fixed to the satisfaction of security specialists the spec is not going to be ready for deployment. We have a security need, we have a simple solution, the only thing that stops deployment is the fact that some people claim that the problem does not exist according to a failled 20 year old dogma that they do not understand. Every argument raised on this list was raised fifteen years ago when I was arguing the need for shaddow passwords in UNIX. It was several years before crack came out and made it impossible for folk to hide their heads in the sand. -- to unsubscribe send a message to namedroppers-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 17 13:59:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03731 for ; Tue, 17 Aug 2004 13:59:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx8AP-000D3K-C9 for namedroppers-data@psg.com; Tue, 17 Aug 2004 17:54:37 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx8AE-000D25-LT for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 17:54:26 +0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i7HHsPBw029670; Tue, 17 Aug 2004 13:54:25 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i7HHsOJV025152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Aug 2004 13:54:25 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i7HHsO61026691; Tue, 17 Aug 2004 13:54:24 -0400 Subject: RE: dictionary attack on nameservers From: Greg Hudson To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092765264.21170.83.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 17 Aug 2004 13:54:24 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_RELAY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2004-08-17 at 13:23, Hallam-Baker, Phillip wrote: > We have a security need, we have a simple solution, We do? It seems like hashed nsec records aren't going to stop organized crime families. Only online signing of negative responses would really prevent someone from enumerating a zone, and online signing is a vector for DOSing DNS itself. > Every argument raised on this list was raised fifteen years ago when > I was arguing the need for shaddow passwords in UNIX. Really? People said passwords are supposed to be public? People said there were other easy ways of figuring out most users' passwords? Fascinating. -- to unsubscribe send a message to namedroppers-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 17 14:17:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04604 for ; Tue, 17 Aug 2004 14:17:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx8Ra-000FqH-WB for namedroppers-data@psg.com; Tue, 17 Aug 2004 18:12:23 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx8RQ-000FpG-8q for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 18:12:12 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i7HICBnw023142; Tue, 17 Aug 2004 18:12:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i7HICB6p023141; Tue, 17 Aug 2004 18:12:11 GMT Date: Tue, 17 Aug 2004 18:12:11 +0000 From: bmanning@vacation.karoshi.com To: "Hallam-Baker, Phillip" Cc: "'Jim Reid'" , David Blacka , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-ID: <20040817181211.GC22961@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The sooner the enumeration issue is fixed, the sooner we can start > on deployment. Until the enumeration issue is fixed to the satisfaction > of security specialists the spec is not going to be ready for > deployment. the enumeration issue? I am confused here. are you asserting that enumeration is not currently possible or that it should be made impossible? For me, enumeration is a fact of life in the DNS. Normal queries give me effective enumeration. The debate here seems to revolve around the "degree" of enumeration that is considered an acceptable risk. now not to pick on the security specialists, but the last time they controlled the development of the DNSSEC protocol, we ended up with something that was emperically proven to be a non-starter. Operationally flawed. Unworkable in the real world. So, like most security issues, this is a series of tradeoffs. I dont expect your arguments about DNSSEC deployment not being ready until the unnamed cadre of "security specialists" agree, will hold much credability. (ask 3 security folks a question and get 7 answers) what is of interest/importance to some of us is the ability to mitigate known problems in a timely fashion. we recognise that evolution is an iterative process and that waiting for the one true pedultimate solution is counter productive. The specs - as written - are "good enough" for many of the concerns that are out there. > We have a security need, we have a simple solution, the only thing > that stops deployment is the fact that some people claim that the > problem does not exist according to a failled 20 year old dogma that > they do not understand. what is the "need"? and what is the solution to this "need"? (I find it tangentially interesting that "a failled 20 year old dogma" has made many companies profitable, pays the salaries of good engineers, security specialists, and operators, and allows us to have the debate. Clearly your definition of failure is radically distinct from mine. :) --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 Tue Aug 17 14:24:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04836 for ; Tue, 17 Aug 2004 14:24:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx8ZZ-000GtJ-Ai for namedroppers-data@psg.com; Tue, 17 Aug 2004 18:20:37 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx8Z8-000GqF-Mo for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 18:20:10 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 99ECAC2DFD; Tue, 17 Aug 2004 19:20:09 +0100 (BST) Date: Tue, 17 Aug 2004 19:20:04 +0100 From: Alex Bligh Reply-To: Alex Bligh To: David Blacka , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <7E6FD60A45D55EB1BECD64A4@[192.168.100.27]> In-Reply-To: <200408171057.54235.davidb@verisignlabs.com> References: <19972.1092732313@gromit.rfc1035.com> <200408171057.54235.davidb@verisignlabs.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 17 August 2004 10:57 -0400 David Blacka wrote: >> [2] Is it worth the time and effort to "fix" NSEC walking -- and no >> doubt hold up the deployment of a Secure DNS for maybe another 5 years >> -- when this issue only creates *policy* difficulties for a small >> number of admittedly very significant corner cases? > > Whose time and effort? Yours? No one can force you to work on the > problem. Not only that, but we (Nominet) have offered contributions / funding to fix it. The point is we /want/ to see it deployed and are prepared to help make it deployable (according to our definition of deployable). I do not see how working to solve zone enumeration is going to delay deployability, as if those who think it isn't a problem are correct (and we are wrong), then it will get deployed notwithstanding our views. 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 17 15:34:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10533 for ; Tue, 17 Aug 2004 15:34:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx9cc-000Pfu-SW for namedroppers-data@psg.com; Tue, 17 Aug 2004 19:27:50 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx9cS-000Ped-2I for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 19:27:40 +0000 Received: from [192.168.0.2] (cable0-stm-219.gmpexpress.net [63.147.50.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id F0DB661800; Tue, 17 Aug 2004 14:27:38 -0500 (CDT) Message-ID: <41225BF0.2070007@ehsco.com> Date: Tue, 17 Aug 2004 15:26:40 -0400 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Cc: "'Jim Reid'" , David Blacka , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 8/17/2004 1:23 PM, Hallam-Baker, Phillip wrote: > The sooner the enumeration issue is fixed, the sooner we can start > on deployment. If dictionary attacks are a problem in general, then a generalized fix is as easy as defining an RCODE for "refused due to policy" -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-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 17 15:43:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11161 for ; Tue, 17 Aug 2004 15:43:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx9pD-0001M2-Rv for namedroppers-data@psg.com; Tue, 17 Aug 2004 19:40:51 +0000 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx9p3-0001IU-0z for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 19:40:41 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (mailer4.verisign.com [65.205.251.53]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id i7HJebgR026871; Tue, 17 Aug 2004 12:40:37 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Aug 2004 12:40:37 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Edward Lewis'" , namedroppers@ops.ietf.org Subject: RE: hopefully was RE: dictionary attack on nameservers Date: Tue, 17 Aug 2004 12:40:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My question remains: > Is there a way to prove the non-existence of a name without > A - exposing any of the contents of the zone? > B - muddying up the name space with fake names or data sets? > C - on-line cryptographic operations? > D - being vulnerable to replay attacks of the negative answer? OK, lets look at B vs C. Let xyz.example.com be the query. There are two basic approaches: 1) The client asks for xyz, the server calculates H(xyz) and returns a signed entry saying that there is no entry between x & y where x < H(xyz) < y. 2) The client calculates H(xyz) and makes a request for that record, the server returns a record for x, stating that the next record is y. The difference here is that in (1) the client performs the hash function, in (2) the server performs the hash function. Remember that we are talking about a hash function here, not a signature. These are realtively fast. We could imagine performing TSIG on each record. This is the same type of issue. There is an issue of asymmetric computational requirements. The attacker can force the server to perform a disproportionate amount of work. What we could do is to create a query that was for the NSEC record but always returned an additional record response from the apex. Ie. to ask for xyz, the server sends a query asking for: A-(xyz.example.com) NSEC2 -(H(xyz).example.com) The response is: xyz.example.com - NotExist example.com - NSEC2 (x,y) So there is no node _x.example.com or _y.example.com and in this scheme the client is required to do the crypto. The server does not do any crypto, nor does the server contain any additional nodes. You do however need to ensure that the response to the query for NSEC2 -(H(xyz).example.com) makes it back and the DNS server needs to be able to understand the NSEC2 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 Tue Aug 17 16:22:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12903 for ; Tue, 17 Aug 2004 16:22:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxAQq-0006iH-Tr for namedroppers-data@psg.com; Tue, 17 Aug 2004 20:19:44 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxAQg-0006hO-2F for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 20:19:34 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7HKJV4w016999; Tue, 17 Aug 2004 13:19:31 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 17 Aug 2004 13:19:31 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Greg Hudson'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Tue, 17 Aug 2004 13:19:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Every argument raised on this list was raised fifteen years ago when > > I was arguing the need for shaddow passwords in UNIX. > > Really? People said passwords are supposed to be public? People said > there were other easy ways of figuring out most users' passwords? > Fascinating. People demanded that the encrypted password file be world readable. The creation of shadow password files was very contentious at the time. Turning on shaddow passwords was claimed as a security vulnerability. Proposals that UNIX introduce a means of using ACLs to control acess to the password file was met by exactly the same response that has appeared on this list. Namely derision, claims that it is security through obscurity, claims that the architecture of UNIX is inviolate, claims that the additional complexity is unwarranted, claims that the solution is for users to get a clue, etc. etc. Of course the shaddow password schemes on many unix clusters are still useless because they don't have a real distributed auth scheme and they simply ship arround the one way encrypted password file so the systems are compromise one, compromise all. But at least it is now possible to secure a UNIX cluster if you know what you are doing without having to rewrite the O/S or patch it. Phill -- to unsubscribe send a message to namedroppers-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 17 16:47:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13976 for ; Tue, 17 Aug 2004 16:47:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxAof-0009qv-Qb for namedroppers-data@psg.com; Tue, 17 Aug 2004 20:44:21 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxAoU-0009qJ-V6 for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 20:44:11 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 67B36143927; Tue, 17 Aug 2004 16:30:28 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id 85554143915; Tue, 17 Aug 2004 16:30:27 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 720CECF39A; Tue, 17 Aug 2004 16:44:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 17 Aug 2004 16:44:08 -0400 To: "Hallam-Baker, Phillip" From: Edward Lewis Subject: RE: hopefully was RE: dictionary attack on nameservers Cc: "'Edward Lewis'" , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:40 -0700 8/17/04, Hallam-Baker, Phillip wrote: >> My question remains: >> Is there a way to prove the non-existence of a name without >> A - exposing any of the contents of the zone? >> B - muddying up the name space with fake names or data sets? >> C - on-line cryptographic operations? >> D - being vulnerable to replay attacks of the negative answer? > >OK, lets look at B vs C. > >Let xyz.example.com be the query. There are two basic approaches: A DNS query consists of (name, type, class). You can't query for just a name. A petty point this may be, but really, the type is needed in any example. (We've wasted much time before when we didn't consider the type in the query.) >1) The client asks for xyz, the server calculates H(xyz) and returns a >signed entry saying that there is no entry between x & y where x < H(xyz) < >y. > >2) The client calculates H(xyz) and makes a request for that record, the >server returns a record for x, stating that the next record is y. I don't understand why the client would request anything related to the hash of the desired name. Is client assuming the data it wants isn't there? >The difference here is that in (1) the client performs the hash function, in >(2) the server performs the hash function. Is this backwards? In (1) you mention "server calculates" and here you say "client performs." >Remember that we are talking about a hash function here, not a signature. >These are realtively fast. We could imagine performing TSIG on each record. >This is the same type of issue. I really don't think the issue is the computation of the hash. Does anyone think it's the issue? (There's an issue with generating the public key signature record with 'C' above.) > >There is an issue of asymmetric computational requirements. The attacker can >force the server to perform a disproportionate amount of work. > > >What we could do is to create a query that was for the NSEC record but >always returned an additional record response from the apex. > >Ie. to ask for xyz, the server sends a query asking for: > >A-(xyz.example.com) NSEC2 -(H(xyz).example.com) "Server sends a query" has me confused, and then what is the next line? It looks like your "query" has RDATA. > >The response is: > >xyz.example.com - NotExist example.com - NSEC2 (x,y) Totally confused by that. What is the RRTYPE? Is NotExist a new RCODE? >So there is no node _x.example.com or _y.example.com and in this scheme the >client is required to do the crypto. The server does not do any crypto, nor >does the server contain any additional nodes. > >You do however need to ensure that the response to the query for NSEC2 >-(H(xyz).example.com) makes it back and the DNS server needs to be able to >understand the NSEC2 query I though you were comparing B and C. Are you saying that extra names is more/equal/less palatable than on-server cryptography? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 17 18:06:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17936 for ; Tue, 17 Aug 2004 18:06:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxC0w-000IyY-QT for namedroppers-data@psg.com; Tue, 17 Aug 2004 22:01:06 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxC0l-000IwP-Jw for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 22:00:56 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i7HM0qqJ020634; Tue, 17 Aug 2004 23:00:52 +0100 (BST) To: Alex Bligh cc: David Blacka , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh of "Tue, 17 Aug 2004 19:20:04 BST." <7E6FD60A45D55EB1BECD64A4@[192.168.100.27]> Date: Tue, 17 Aug 2004 23:00:52 +0100 Message-ID: <20633.1092780052@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Alex" == Alex Bligh writes: Alex> Not only that, but we (Nominet) have offered contributions / Alex> funding to fix it. The point is we /want/ to see it deployed Alex> and are prepared to help make it deployable (according to Alex> our definition of deployable). One the one hand, this is good. Nominet is putting its money where its mouth is and taking a constructive approach. Excellent! OTOH, this is bad because the end goal of that effort is to meet your (somehwat vague) definition of deployable. What happens the next time someone decides to move the goalposts? Does the protocol get tweaked forever until everyone's definition of deployable gets met? Alex> I do not see how working to solve zone enumeration is going Alex> to delay deployability, as if those who think it isn't a Alex> problem are correct (and we are wrong), then it will get Alex> deployed notwithstanding our views. Can you say opt-in? That was the last big controversial issue in the DNSSEC protocol development effort. It took ~2 years for the WG to kill that idea. Expect at least the same amount of time and effort being expended by the WG on some flavour of NSEC++. Plus the same again as the WG debates a type code change and/or version bit for compatibility with the drafts that have just gone to IESG. And let's not forget the interoperability and backwards compatibility problems this will create with DNSSECbis either. It's also possible IESG won't endorse the current drafts because the WG is working on a fix for zone enumeration. As for deployment, sure, some TLDs can and will deploy DNSSECbis assuming it gets blessed by IESG. But if there's uncertainty about the protocol -- because the WG is working on a fix for zone enumeration -- this creates a major headache for applications developers and vendors. Do they ship code for the current spec or hold off until the next version of the protocol is done? Whenever that may be... What do they do about embedded devices -- say 3G mobile phones -- that can't be easily upgraded once they're in the field? That's undoubtedly going to delay deployment and getting a meaningful installed base of DNSSEC-aware devices used in anger. End users are likely to face the same dilemma: do harassed and overworked zone administrators get up to speed with the current spec and deploy it or else wait for the next version? Or the one after that? Hint: some of these people are still running BIND4. Meanwhile, large chunks of the name space continue to be unsecured. -- to unsubscribe send a message to namedroppers-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 17 19:03:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21988 for ; Tue, 17 Aug 2004 19:03:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxCwD-0000Ns-HL for namedroppers-data@psg.com; Tue, 17 Aug 2004 23:00:17 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxCvf-0000FA-0N for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 22:59:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C759513E11 for ; Tue, 17 Aug 2004 22:59:42 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from David Blacka of "Tue, 17 Aug 2004 02:08:04 -0400." <200408170208.04644.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 17 Aug 2004 22:59:42 +0000 Message-Id: <20040817225942.C759513E11@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Just to press down a bit further: do you see no substantial difference > between being able to get 100% of a zone vs. getting perhaps 80% via > datamining? This is, I think, a major disconnect. difference to whom? to a dataminer, 100% is better than 80%. to a registry, 100% is worse than 80%. to a domainholder, it matters whether you're in the 20% or in the 80%, but not very much. > I know that in my own experience I've seen malefactors using readily > available TLD zone files to find newly registered domain to make their > own activities more efficient. yes, i saw some correlation between COM/NET/ORG AXFR's on f-root (back when AXFR from f-root was the only way to get this data) and bad acts by bad folks. but as we've all seen, making it harder isn't the same as stopping bad acts, or even slowing them down. (sure does cost the good guys more, though.) -- to unsubscribe send a message to namedroppers-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 17 19:05:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22081 for ; Tue, 17 Aug 2004 19:05:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxCyY-0000hX-MK for namedroppers-data@psg.com; Tue, 17 Aug 2004 23:02:42 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxCyO-0000gE-7O for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 23:02:32 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id F327613DFF for ; Tue, 17 Aug 2004 23:02:31 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh of "Tue, 17 Aug 2004 08:41:37 +0100." <4A09E2E9CEDAD298DD45B654@[192.168.100.27]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 17 Aug 2004 23:02:31 +0000 Message-Id: <20040817230231.F327613DFF@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> It seems like you are saying: > >> * in order to work on this we must demonstrate A > >> * it is impossible to demonstrate A > > > > ... i'm one of those to whom "A" (in this example) is trivially observable > > Let me get this straight: you are saying a dictionary attack (or some other > enumeration attack) on say .de (or .uk or .nl) is "trivially observable"... no. what's trivially observable is that the names are not remaining secret, and that the abuse seen by domainholders today is indistinguishable from the abuse that would be seen if full enumeration were simple, by AXFR or FTP or zone walking. -- to unsubscribe send a message to namedroppers-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 17 19:12:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22286 for ; Tue, 17 Aug 2004 19:12:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxD4q-0001cy-Gt for namedroppers-data@psg.com; Tue, 17 Aug 2004 23:09:12 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxD4g-0001Zh-1M for namedroppers@ops.ietf.org; Tue, 17 Aug 2004 23:09:02 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CCA5513DFF for ; Tue, 17 Aug 2004 23:09:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh of "Tue, 17 Aug 2004 19:20:04 +0100." <7E6FD60A45D55EB1BECD64A4@[192.168.100.27]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 17 Aug 2004 23:09:01 +0000 Message-Id: <20040817230901.CCA5513DFF@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... No one can force you to work on the problem. > > Not only that, but we (Nominet) have offered contributions / funding > to fix it. The point is we /want/ to see it deployed and are prepared > to help make it deployable (according to our definition of > deployable). I do not see how working to solve zone enumeration is > going to delay deployability, as if those who think it isn't a problem > are correct (and we are wrong), then it will get deployed > notwithstanding our views. the current spec will absolutely be deployed. (the wg already advanced it, and i know of enough deployment-related efforts to be confident that dnssec-bis as more-or-less currently specified will see rubber meet road.) working to solve zone enumeration in a subsequent spec and then migrating from dnssec-bis to that spec is a workable approach. and for all my rants about the non-utility of the approach, i know that isc is committed to implementing whatever the community decides upon, even if it's something i'd previously ranted against on a personal level. i'm not sure why this debate is even occurring. everything's been decided. -- to unsubscribe send a message to namedroppers-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 17 20:24:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24703 for ; Tue, 17 Aug 2004 20:24:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxEBr-000Acu-Bq for namedroppers-data@psg.com; Wed, 18 Aug 2004 00:20:31 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxEBA-000AVD-ID for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 00:19:48 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i7I0INJ03864; Tue, 17 Aug 2004 17:18:23 -0700 (PDT) Message-Id: <200408180018.i7I0INJ03864@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 3845 on DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 17 Aug 2004 17:18:23 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-18.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3845 Title: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format Author(s): J. Schlyter, Ed. Status: Standards Track Date: August 2004 Mailbox: jakob@nic.se Pages: 7 Characters: 14793 Updates: 3755, 2535 I-D Tag: draft-ietf-dnsext-nsec-rdata-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3845.txt This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040817171625.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3845 --OtherAccess Content-Type: Message/External-body; name="rfc3845.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040817171625.RFC@RFC-EDITOR.ORG> --OtherAccess-- --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 Wed Aug 18 03:50:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15920 for ; Wed, 18 Aug 2004 03:50:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxL7q-000BlK-4S for namedroppers-data@psg.com; Wed, 18 Aug 2004 07:44:50 +0000 Received: from [216.148.222.61] (helo=mail35-red-R.bigfish.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxL7f-000Bjz-4H for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 07:44:39 +0000 Received: from mail35-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail35-red-R.bigfish.com (Postfix) with ESMTP id C902E301388; Wed, 18 Aug 2004 07:44:36 +0000 (UCT) X-BigFish: VPC Received: by mail35-red.bigfish.com (MessageSwitch) id 1092815076725914_13208; Wed, 18 Aug 2004 07:44:36 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail35-red.bigfish.com (Postfix) with ESMTP id 7FFCE30026C; Wed, 18 Aug 2004 07:44:36 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id i7I7iaaY002512; Wed, 18 Aug 2004 02:44:36 -0500 (CDT) Received: from PKDWG01A.ad.sprint.com (PKDWG01A.corp.sprint.com [10.185.12.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I7iZ414407; Wed, 18 Aug 2004 02:44:35 -0500 (CDT) Received: from PDAWG01A.corp.sprint.com ([10.184.134.78]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Aug 2004 02:44:06 -0500 Received: from mail pickup service by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC; Wed, 18 Aug 2004 02:44:05 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.56]) by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Aug 2004 21:09:23 -0500 Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7I0Qpm09336 for ; Tue, 17 Aug 2004 19:26:51 -0500 (CDT) Received: from mail22-res-R.bigfish.com (mail-res.bigfish.com [63.161.60.61]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id i7I0QoUm025205 for ; Tue, 17 Aug 2004 19:26:50 -0500 (CDT) Received: from mail22-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail22-res-R.bigfish.com (Postfix) with ESMTP id 7D765333FB3 for ; Wed, 18 Aug 2004 00:26:50 +0000 (UCT) Received: by mail22-res (MessageSwitch) id 1092788807727584_32733; Wed, 18 Aug 2004 00:26:47 +0000 (UCT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail22-res.bigfish.com (Postfix) with ESMTP id 9B67B334384; Wed, 18 Aug 2004 00:26:47 +0000 (UCT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxEBn-0001Fs-TE; Tue, 17 Aug 2004 20:20:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxEB9-00018w-OW for ietf-announce@megatron.ietf.org; Tue, 17 Aug 2004 20:19:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24338 for ; Tue, 17 Aug 2004 20:19:46 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxEHG-0007Ve-Bt for ietf-announce@ietf.org; Tue, 17 Aug 2004 20:26:06 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i7I0INJ03864; Tue, 17 Aug 2004 17:18:23 -0700 (PDT) Message-Id: <200408180018.i7I0INJ03864@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 17 Aug 2004 17:18:23 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: namedroppers@ops.ietf.org, rfc-editor@rfc-editor.org Subject: RFC 3845 on DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-OriginalArrivalTime: 18 Aug 2004 02:09:23.0773 (UTC) FILETIME=[61863ED0:01C484C8] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-10.7 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3845 Title: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format Author(s): J. Schlyter, Ed. Status: Standards Track Date: August 2004 Mailbox: jakob@nic.se Pages: 7 Characters: 14793 Updates: 3755, 2535 I-D Tag: draft-ietf-dnsext-nsec-rdata-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3845.txt This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040817171625.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3845 --OtherAccess Content-Type: Message/External-body; name="rfc3845.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040817171625.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --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 Wed Aug 18 05:25:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20840 for ; Wed, 18 Aug 2004 05:25:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxMcz-000Mtq-UQ for namedroppers-data@psg.com; Wed, 18 Aug 2004 09:21:05 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxMcp-000MtA-3J for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 09:20:55 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 011B4C2DA4; Wed, 18 Aug 2004 10:20:53 +0100 (BST) Date: Wed, 18 Aug 2004 10:20:48 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jim Reid Cc: David Blacka , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <820FE17B43529A721EE12548@[192.168.100.27]> In-Reply-To: <20633.1092780052@gromit.rfc1035.com> References: <20633.1092780052@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 17 August 2004 23:00 +0100 Jim Reid wrote: > Alex> I do not see how working to solve zone enumeration is going > Alex> to delay deployability, as if those who think it isn't a > Alex> problem are correct (and we are wrong), then it will get > Alex> deployed notwithstanding our views. > > Can you say opt-in? That was the last big controversial issue in the > DNSSEC protocol development effort. It took ~2 years for the WG to > kill that idea. That was /before/ DNSSEC-bis was sent to the IESG. I thought the point of sending it to the IESG was that people in general felt it was deployable now (as do I, in certain circumstances, and indeed DLV widens those circumstances considerably). I thought the whole point of the debate as to whether the w/g should reach consensus to send DNSSEC-bis to the IETF was so as not to delay deployment whilst the w/g worked on the question of whether to / how to solve some additional issues that had been raised, primarily enumerability. If you thought enumerability was going to delay deployment, notwithstanding DNSSEC-bis having been sent to the IESG without any fix, why send it? 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 18 05:28:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20990 for ; Wed, 18 Aug 2004 05:28:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxMhp-000NPT-Mb for namedroppers-data@psg.com; Wed, 18 Aug 2004 09:26:05 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxMhX-000NLq-3H for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 09:25:47 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 77077C2DA4; Wed, 18 Aug 2004 10:25:46 +0100 (BST) Date: Wed, 18 Aug 2004 10:25:40 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: In-Reply-To: <20040817230901.CCA5513DFF@sa.vix.com> References: <20040817230901.CCA5513DFF@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 17 August 2004 23:09 +0000 Paul Vixie wrote: > the current spec will absolutely be deployed. (the wg already advanced > it, and i know of enough deployment-related efforts to be confident that > dnssec-bis as more-or-less currently specified will see rubber meet road.) > > working to solve zone enumeration in a subsequent spec and then migrating > from dnssec-bis to that spec is a workable approach. and for all my rants > about the non-utility of the approach, i know that isc is committed to > implementing whatever the community decides upon, even if it's something > i'd previously ranted against on a personal level. Agree & your final sentence is appreciated. > i'm not sure why this debate is even occurring. everything's been > decided. I think because every time someone tries to gather requirements to address the enumerability problem, the question of whether or not it needs to be addressed at all gets brought up. I think straight answer is "it is a requirement for a significant community, and not for others". I suspect we are never going to get consensus on whether or not it should be a requirement, and we will generate heat but not light from further discussion. If it is sufficiently significant, IMHO it should be addressed, and if it is expensive (especially but not exclusively server side) it should be optional in its implementation. 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 18 10:36:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09933 for ; Wed, 18 Aug 2004 10:36:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxRPg-0006F3-Sa for namedroppers-data@psg.com; Wed, 18 Aug 2004 14:27:40 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxRNp-0005zN-Gj for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 14:25:45 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BxRNm-0007KV-M6; Wed, 18 Aug 2004 16:25:42 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BxRNk-0002ZL-Se; Wed, 18 Aug 2004 16:25:40 +0200 To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: From: Florian Weimer Date: Wed, 18 Aug 2004 16:25:40 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 2 Aug 2004 12:32:33 -0700") Message-ID: <87oel8bk0r.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Phillip Hallam-Baker: > At blackhat there was a presentation on the ongoing .il vs .ps cyberwar. > This began with an attack on various pro-Palestinian groups and was shortly > followed by a retaliation on pro-Israeli sites and the entire .il domain. > > It is pretty clear that whoever is running the .il domain is not going to > implement any scheme that makes it easier to walk the domain. Can you be more specific about the kind of attacks? Most of the attacks I know do not benefit from the knowledge of domain names. -- to unsubscribe send a message to namedroppers-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 18 10:42:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10422 for ; Wed, 18 Aug 2004 10:42:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxRbP-0007XC-80 for namedroppers-data@psg.com; Wed, 18 Aug 2004 14:39:47 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxRbE-0007Vw-HG for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 14:39:36 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BxRbD-0007Xr-3w; Wed, 18 Aug 2004 16:39:35 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BxRbB-0002bG-Fo; Wed, 18 Aug 2004 16:39:33 +0200 To: Roy Badami Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <200407291030.i6TAUGjH033734@open.nlnetlabs.nl> <873c39sn8x.fsf@deneb.enyo.de> <16650.18749.440814.95094@giles.gnomon.org.uk> <6AFE81C9A3C54027AE038325@[192.168.100.27]> <87llh1jiz2.fsf@deneb.enyo.de> <16650.53872.23799.459475@giles.gnomon.org.uk> From: Florian Weimer Date: Wed, 18 Aug 2004 16:39:33 +0200 In-Reply-To: <16650.53872.23799.459475@giles.gnomon.org.uk> (Roy Badami's message of "Fri, 30 Jul 2004 23:57:52 +0100") Message-ID: <87k6vwbjdm.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Roy Badami: >>>>>> "Florian" == Florian Weimer writes: > > Florian> If the data were privacy-sensitive, it couldn't be shared > Florian> at all without explicit consent from the domain name > Florian> owner (at least according to most EU law). > > That's an oversimplistic view of data protection legislation. One of > the principles in the UK implementation is that personal data can only > be used for the purposes for which it was collected. Yes, of course. This means that if NS RRs (or other TLD zone contents) were personal data, .COM/.NET registrars would have to disclose what happens with this data (that is, VeriSign republishes it in bulk, without any privacy safeguards). However, hardly any registrar does this right now. For TLD owners, there might be other contractual obligations not to publish the zone contents in bulk. In this case, these obligations should be named. I've got a huch that privacy is not the real issue. And if it's not privacy but simply the business interest of a few (certainly not all) TLD operators, it might make sense to refrain from adding baroque features to DNSSEC just to please them. In the meantime, the discussion whether domain names are comparable to phone numbers and deserve equal protection has resurfaced in Germany. If something goes wrong, domain names might be considered personal data rather soonish. 8-( -- to unsubscribe send a message to namedroppers-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 18 10:52:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10972 for ; Wed, 18 Aug 2004 10:52:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxRjC-0008dI-VM for namedroppers-data@psg.com; Wed, 18 Aug 2004 14:47:50 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxRiu-0008bp-4X for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 14:47:32 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 142E4AC8B; Wed, 18 Aug 2004 16:47:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 05D70AC8A; Wed, 18 Aug 2004 16:47:30 +0200 (CEST) Date: Wed, 18 Aug 2004 16:47:30 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Florian Weimer Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <87oel8bk0r.fsf@deneb.enyo.de> Message-ID: References: <87oel8bk0r.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Aug 2004, Florian Weimer wrote: > * Phillip Hallam-Baker: > > > At blackhat there was a presentation on the ongoing .il vs .ps cyberwar. > > This began with an attack on various pro-Palestinian groups and was shortly > > followed by a retaliation on pro-Israeli sites and the entire .il domain. > > > > It is pretty clear that whoever is running the .il domain is not going to > > implement any scheme that makes it easier to walk the domain. > > Can you be more specific about the kind of attacks? > > Most of the attacks I know do not benefit from the knowledge of domain > names. Err, most of the attacks I know involves a target. If the target is the .de domain, the attack would benefit from the knowledge of zones under the .de domain. However, if .il has a problem with enumeration, they might as well demand a restriction on XFR's ;) 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 Wed Aug 18 11:03:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11686 for ; Wed, 18 Aug 2004 11:03:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxRvj-000AW1-Et for namedroppers-data@psg.com; Wed, 18 Aug 2004 15:00:47 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxRvY-000AUf-R1 for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 15:00:36 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7IF0UCL007933; Wed, 18 Aug 2004 08:00:32 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 08:00:30 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Florian Weimer'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Wed, 18 Aug 2004 08:00:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > It is pretty clear that whoever is running the .il domain > is not going to > > implement any scheme that makes it easier to walk the domain. > > Can you be more specific about the kind of attacks? > > Most of the attacks I know do not benefit from the knowledge of domain > names. The Israeli-Palestinian cyberwar went roughly thus: Israeli hacker attacks sites operated by Hammas, Hezbollah Palestinians retaliate Israeli retaliate Palestinians retaliate Israeli hackers attempt retaliation, discover that there are no targets left Palestinians attack every site that they know of which is in the .il domain. There is a lot of stuff on this on the net. The Israeli hackers seem to have been a bunch of teenage hackers who did not know what they were starting, or maybe they did since they now have a really big line selling security consultancy to the sites being attacked in retaliation for the sites they attacked. The bottom line is that any site that comes up in the .il domain is going to be attacked as soon as it becomes known. There are a bunch of other similar events. The incident in 2001 when the US and China got into a standoff over a spy plane led to a small scale cyberwar but it never got very far before the situation was resolved. -- to unsubscribe send a message to namedroppers-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 18 11:12:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12313 for ; Wed, 18 Aug 2004 11:12:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxS4n-000C9P-6x for namedroppers-data@psg.com; Wed, 18 Aug 2004 15:10:09 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxS4c-000C5q-F7 for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 15:09:58 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BxS4Z-00089j-JW; Wed, 18 Aug 2004 17:09:55 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BxS4X-0002h2-RY; Wed, 18 Aug 2004 17:09:53 +0200 To: Roy Arends Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <87oel8bk0r.fsf@deneb.enyo.de> From: Florian Weimer Date: Wed, 18 Aug 2004 17:09:53 +0200 In-Reply-To: (Roy Arends's message of "Wed, 18 Aug 2004 16:47:30 +0200 (CEST)") Message-ID: <87brh8bhz2.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Roy Arends: > Err, most of the attacks I know involves a target. If the target is the > .de domain, the attack would benefit from the knowledge of zones under the > .de domain. How so? I need a list of the name servers for .DE, and detailed routing information is also desirable (including the router vendors/software versions that are involved). -- to unsubscribe send a message to namedroppers-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 18 11:18:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12734 for ; Wed, 18 Aug 2004 11:18:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxS9o-000Cou-Ay for namedroppers-data@psg.com; Wed, 18 Aug 2004 15:15:20 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxS9V-000Cl9-Mj for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 15:15:01 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id C67EFAC8B; Wed, 18 Aug 2004 17:15:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id C0AF0AC8A; Wed, 18 Aug 2004 17:15:00 +0200 (CEST) Date: Wed, 18 Aug 2004 17:15:00 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Florian Weimer Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <87brh8bhz2.fsf@deneb.enyo.de> Message-ID: References: <87oel8bk0r.fsf@deneb.enyo.de> <87brh8bhz2.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Aug 2004, Florian Weimer wrote: > * Roy Arends: > > > Err, most of the attacks I know involves a target. If the target is the > > .de domain, the attack would benefit from the knowledge of zones under the > > .de domain. > > How so? I need a list of the name servers for .DE, and detailed > routing information is also desirable (including the router > vendors/software versions that are involved). I don't, I'd enumerate them thru nsec. Call me lazy. 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 Wed Aug 18 12:01:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16751 for ; Wed, 18 Aug 2004 12:00:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxSoL-000IHr-IZ for namedroppers-data@psg.com; Wed, 18 Aug 2004 15:57:13 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxSoA-000IGq-AG for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 15:57:02 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id B2C594FFDE; Wed, 18 Aug 2004 17:57:01 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 4845E4FFBD for ; Wed, 18 Aug 2004 17:57:01 +0200 (CEST) Received: from x53.ripe.net (x53.ripe.net [193.0.1.53]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i7IFv1W8006666 for ; Wed, 18 Aug 2004 17:57:01 +0200 Date: Wed, 18 Aug 2004 17:57:01 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x53.ripe.net To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message-ID: References: <87oel8bk0r.fsf@deneb.enyo.de> <87brh8bhz2.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.021343 / 0.0 / 0.0 / disabled X-RIPE-Signature: e306d80f9e0aea241e747e80c74d22ed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Aug 2004, Roy Arends wrote: > I don't, I'd enumerate them thru nsec. Call me lazy. It won't be too long before some Registry coddles up a nameserver that detects nsec/other-based enumuration query trends, and starts dynamically inserting bogus records to lead the attacker through a twisted trail of normally-non-existent domains (ala web page scripts that provide lots of bogus email addresses to fill a scrapper's database with crap). Has all sorts of connotations ala sitefinder, but as a next escalation path, it'd work. --==-- Bruce. -- to unsubscribe send a message to namedroppers-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 18 12:13:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18398 for ; Wed, 18 Aug 2004 12:13:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxT1w-000KFU-Ix for namedroppers-data@psg.com; Wed, 18 Aug 2004 16:11:16 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxT1V-000KBf-Qk for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 16:10:50 +0000 Received: (debugging) helo=deneb.enyo.de ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp id 1BxT1U-00011t-LC; Wed, 18 Aug 2004 18:10:48 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.34) id 1BxT1S-0002rz-Nf; Wed, 18 Aug 2004 18:10:46 +0200 To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: From: Florian Weimer Date: Wed, 18 Aug 2004 18:10:46 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 18 Aug 2004 08:00:23 -0700") Message-ID: <87hdr077g9.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Phillip Hallam-Baker: > The bottom line is that any site that comes up in the .il > domain is going to be attacked as soon as it becomes known. And .ps and .il have completely segregated backbone infrastructure, so that you can safely tell an attack of a .ps site from an attack on an .il site? In this case, wouldn't it be easier to go for the infrastructure itself, and not for specific sites? Or are we talking about attacks on the application layer? (I'm a bit surprised because it's hard to imagine for me that the infrastructure is so clearly separated. Unfortunately, I haven't got enough data on .ps and .il to provide some evidence with respect to shared hosting.) -- to unsubscribe send a message to namedroppers-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 18 12:54:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21255 for ; Wed, 18 Aug 2004 12:54:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxTeR-000OPD-24 for namedroppers-data@psg.com; Wed, 18 Aug 2004 16:51:03 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxTeG-000OM0-C0 for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 16:50:52 +0000 Received: from MOU1WNEXC04.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7IGon12014994; Wed, 18 Aug 2004 09:50:49 -0700 (PDT) Received: by mou1wnexc04.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 18 Aug 2004 09:50:49 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Florian Weimer'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Wed, 18 Aug 2004 09:50:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > And .ps and .il have completely segregated backbone infrastructure, so > that you can safely tell an attack of a .ps site from an attack on an > .il site? Actually no, the palestinian ISPs are all controlled by Israel. But the point is that companies with .il or .ps domains do not have to use domestic ISPs. Most of the Palestinian sites are in .com and are hosted outside the country but there are not very many of them. > In this case, wouldn't it be easier to go for the infrastructure > itself, and not for specific sites? Or are we talking about attacks > on the application layer? It is application layer attacks. You take a .il site, crack it, then bring up some propaganda pictures on the hacked site. > (I'm a bit surprised because it's hard to imagine for me that the > infrastructure is so clearly separated. Unfortunately, I haven't got > enough data on .ps and .il to provide some evidence with respect to > shared hosting.) It isn't really, but the hackers don't much care about collateral damage. -- to unsubscribe send a message to namedroppers-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 18 13:02:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21943 for ; Wed, 18 Aug 2004 13:01:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxTlR-000PVP-QD for namedroppers-data@psg.com; Wed, 18 Aug 2004 16:58:17 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxTlH-000PTp-7C for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 16:58:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 069BB13DFF for ; Wed, 18 Aug 2004 16:58:07 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Florian Weimer of "Wed, 18 Aug 2004 17:09:53 +0200." <87brh8bhz2.fsf@deneb.enyo.de> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 18 Aug 2004 16:58:07 +0000 Message-Id: <20040818165807.069BB13DFF@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > How so? I need a list of the name servers for .DE, and detailed > routing information is also desirable (including the router > vendors/software versions that are involved). without doing any AXFR's, we (www.isc.org/ops/ds) found 3421455 hosts whose names ended in .DE, under 131905 different second-level domains. for details. -- to unsubscribe send a message to namedroppers-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 18 13:04:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22153 for ; Wed, 18 Aug 2004 13:04:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxTpZ-0000Cy-6j for namedroppers-data@psg.com; Wed, 18 Aug 2004 17:02:33 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxTpO-0000Bo-Nu for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 17:02:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8C30513951 for ; Wed, 18 Aug 2004 17:02:22 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Bruce Campbell of "Wed, 18 Aug 2004 17:57:01 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 18 Aug 2004 17:02:22 +0000 Message-Id: <20040818170222.8C30513951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It won't be too long before some Registry coddles up a nameserver that > detects nsec/other-based enumuration query trends, and starts dynamically > inserting bogus records to lead the attacker through a twisted trail of > normally-non-existent domains (ala web page scripts that provide lots of > bogus email addresses to fill a scrapper's database with crap). > > Has all sorts of connotations ala sitefinder, but as a next escalation > path, it'd work. not only that, when i consider how much easier it'll be for robotic telemarketers to reach me by SIP, i think it's going to be necessary even without NSEC. (the ip6.arpa and e164.arpa zones are easy to enumerate since their names are so predictable.) so, you can probably expect isc to solicit funding for a bind9 feature that does what you're describing, within a short year or two. -- to unsubscribe send a message to namedroppers-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 18 13:27:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23697 for ; Wed, 18 Aug 2004 13:27:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxUBE-0003I3-9C for namedroppers-data@psg.com; Wed, 18 Aug 2004 17:24:56 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxUAn-0003DI-Jp for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 17:24:29 +0000 Received: from [192.168.0.8] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id EA3C5C2DA4; Wed, 18 Aug 2004 18:24:28 +0100 (BST) Date: Wed, 18 Aug 2004 18:23:39 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <4E05AF71C6EC8843DD2BE170@[192.168.0.8]> In-Reply-To: <20040818165807.069BB13DFF@sa.vix.com> References: <20040818165807.069BB13DFF@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 18 August 2004 16:58 +0000 Paul Vixie wrote: > without doing any AXFR's, we (www.isc.org/ops/ds) found 3421455 hosts > whose names ended in .DE, under 131905 different second-level domains. So somewhere around 3% of the zonefile (as .de's are registered at the second level). 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 18 14:55:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28991 for ; Wed, 18 Aug 2004 14:55:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxVKU-000CaY-UD for namedroppers-data@psg.com; Wed, 18 Aug 2004 18:38:34 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxVKI-000CTD-BO for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 18:38:24 +0000 Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7IIb1j30441 for ; Wed, 18 Aug 2004 11:37:02 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i7IIb1mC022672 for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 11:37:01 -0700 Date: Wed, 18 Aug 2004 11:37:01 -0700 From: kent crispin To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-ID: <20040818183701.GQ6165@raven.songbird.com> Mail-Followup-To: namedroppers@ops.ietf.org References: <87oel8bk0r.fsf@deneb.enyo.de> <87brh8bhz2.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87brh8bhz2.fsf@deneb.enyo.de> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Aug 18, 2004 at 05:09:53PM +0200, Florian Weimer wrote: > * Roy Arends: > > > Err, most of the attacks I know involves a target. If the target is the > > .de domain, the attack would benefit from the knowledge of zones under the > > .de domain. > > How so? I need a list of the name servers for .DE, and detailed > routing information is also desirable (including the router > vendors/software versions that are involved). Some real-world router/switch names: 500.Serial3-7.GW6.LAX9.ALTER.NET POS7-0.BR2.LAX9.ALTER.NET so-6-0-0.mpr4.sjc2.us.above.net bb1-hou-P1-0.atdn.net pop1-atl-P4-0.atdn.net so-10-0.hsa1.Raleigh1.Level3.net so-0-3-0.bbr1.LosAngeles1.Level3.net eth2.dist1-1.sr.sonic.net sl-gw19-rly-9-0.sprintlink.net sl-bb27-rly-12-0.sprintlink.net tbr1-cl2.dlstx.ip.att.net Note that there is real information encoded in those names. The ability to completely list of all the domain names under, for example, Level3.net, would give a tremendous amount of information about the structure of their network. One could gather the same information using thousands of traceroutes, or perhaps by a very carefully crafted dictionary attack, but the amount of work involved would be orders of magnitude greater. Regards Kent -- Kent Crispin kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.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 18 15:21:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01047 for ; Wed, 18 Aug 2004 15:20:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxVqD-000HzV-Ny for namedroppers-data@psg.com; Wed, 18 Aug 2004 19:11:21 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxVq3-000HvG-0E for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 19:11:11 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CFC2113951 for ; Wed, 18 Aug 2004 19:11:10 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from kent crispin of "Wed, 18 Aug 2004 11:37:01 MST." <20040818183701.GQ6165@raven.songbird.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 18 Aug 2004 19:11:10 +0000 Message-Id: <20040818191110.CFC2113951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > so-10-0.hsa1.Raleigh1.Level3.net > so-0-3-0.bbr1.LosAngeles1.Level3.net > ... > Note that there is real information encoded in those names. > > The ability to completely list of all the domain names under, for > example, Level3.net, would give a tremendous amount of information > about the structure of their network. One could gather the same > information using thousands of traceroutes, or perhaps by a very > carefully crafted dictionary attack, but the amount of work involved > would be orders of magnitude greater. no, it wouldn't be more work. those names are all trivially discoverable using PTR lookups of every possible IPv4 address's "inaddr name" given only a list of level(3) netblocks. no NSEC is needed. NSEC would be harder. observation: we're just hurling pies, 3-stooges-style, until a survey is made. can we talk about doing a survey rather than trying to create facts out of air? -- to unsubscribe send a message to namedroppers-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 18 16:46:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14467 for ; Wed, 18 Aug 2004 16:46:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxXEq-0006UG-CJ for namedroppers-data@psg.com; Wed, 18 Aug 2004 20:40:52 +0000 Received: from [140.239.227.17] (helo=portal.hamachi.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxXEf-0006Qh-4G for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 20:40:41 +0000 Received: from portal (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 58B8417921; Wed, 18 Aug 2004 16:40:40 -0400 (EDT) From: Bill Sommerfeld To: Bruce Campbell Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Bruce Campbell of "Wed, 18 Aug 2004 17:57:01 +0200." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Wed, 18 Aug 2004 16:40:40 -0400 Message-Id: <20040818204040.58B8417921@portal.hamachi.org> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It won't be too long before some Registry coddles up a nameserver that > detects nsec/other-based enumuration query trends, and starts dynamically > inserting bogus records to lead the attacker through a twisted trail of > normally-non-existent domains (ala web page scripts that provide lots of > bogus email addresses to fill a scrapper's database with crap). Indeed. Chain walking should involve detectably different access patterns from normal DNS operation.. Filesystems have done this sort of access pattern detection for years; the difference here is that filesystems usually want to deliver *improved* QoS for sequential access :-) Outline of an algorithm: With only one replica of a zone, it's easy -- if you hit a "green" name, the next name gets painted "yellow"; if you hit an "yellow" name, the reply spends some time in a penalty box and the next name gets painted "red"; if you hit a "red" name, the server gets creative; colors decay back to green over time. To generalize to multiple replicas, paint multiple subsequent names rather than just one; with a large enough window, with queries spread across N replicas, at least one replica must see an in-window value and the sequential-access detector will fire, derailing the scan on that server.. Sensitivity to attack rate and false-positive rate can be adjusted by tweaking the window size, the color count and the decay timer.. Popular names can be locked green permanently -- the walk-detector will fire quickly enough once you get into dustier parts of the zone. - 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 18 17:06:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16891 for ; Wed, 18 Aug 2004 17:06:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxXZl-000ApP-7E for namedroppers-data@psg.com; Wed, 18 Aug 2004 21:02:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxXZa-000AnN-Kd for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 21:02:18 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6794D13E13 for ; Wed, 18 Aug 2004 21:02:18 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Bill Sommerfeld of "Wed, 18 Aug 2004 16:40:40 -0400." <20040818204040.58B8417921@portal.hamachi.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 18 Aug 2004 21:02:18 +0000 Message-Id: <20040818210218.6794D13E13@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > Sensitivity to attack rate and false-positive rate can be adjusted by > tweaking the window size, the color count and the decay timer.. > > Popular names can be locked green permanently -- the walk-detector > will fire quickly enough once you get into dustier parts of the zone. i love this plan. it's simple and elegant. but it won't help me prevent telemarketers from finding out the name and address of my voip/sip server (along with every other such server in "+1") and assigning robots to try to get me to change my vote, buy their product, answer a survey, change my long distance provider, or etc. got anything that will help the non-dnssec case, where queries need neither be sequential nor sole-sourced in order to effectively enumerate zones with well understood allocation schemes? -- to unsubscribe send a message to namedroppers-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 18 17:25:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20609 for ; Wed, 18 Aug 2004 17:25:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxXsY-000DxY-H3 for namedroppers-data@psg.com; Wed, 18 Aug 2004 21:21:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxXsN-000Duz-PM for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 21:21:44 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i7ILLVtx032067 for ; Wed, 18 Aug 2004 17:21:31 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i7ILLVV4032066 for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 17:21:31 -0400 (EDT) (envelope-from namedroppers) Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxJiT-0002eo-NW for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 06:14:33 +0000 Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7I6EWj13712; Tue, 17 Aug 2004 23:14:33 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i7I6EWje001850; Tue, 17 Aug 2004 23:14:32 -0700 Date: Tue, 17 Aug 2004 23:14:32 -0700 From: kent crispin To: Ted Lindgreen Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-ID: <20040818061431.GM6165@raven.songbird.com> Mail-Followup-To: Ted Lindgreen , namedroppers@ops.ietf.org References: <200408170813.i7H8DLUZ055362@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408170813.i7H8DLUZ055362@open.nlnetlabs.nl> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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-subsrcibers. Please fix your subscription addresses. ] On Tue, Aug 17, 2004 at 10:13:20AM +0200, Ted Lindgreen wrote: > 3. Attackers, being script kiddy's and others. These gals and guys usually > probe ranges of IP-adresses, not domainnames. Whether script kiddies or organized crime, they probe ranges of IP addresses *precisely* because ranges of IP addressess are trivially enumerable. If domain names become trivially enumerable, then they will probe domain names, which will be more efficient than probing ranges of IP addresses, plus giving out information that can't be gleaned from probing IP addresses. Regards Kent -- kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.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 18 17:36:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22073 for ; Wed, 18 Aug 2004 17:36:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxY3l-000G70-NN for namedroppers-data@psg.com; Wed, 18 Aug 2004 21:33:29 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxY3Z-000G5R-N4 for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 21:33:19 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7ILYPcv002237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Aug 2004 21:34:31 GMT (envelope-from roy+dated+1095456790.ac3ddf@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7ILXAhF077646 for ; Wed, 18 Aug 2004 22:33:10 +0100 (BST) (envelope-from roy+dated+1095456790.ac3ddf@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7ILXAU0077645 for namedroppers@ops.ietf.org; Wed, 18 Aug 2004 22:33:10 +0100 (BST) (envelope-from roy+dated+1095456790.ac3ddf@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 18 Aug 2004 22:33:09 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16675.51989.29809.273081@giles.gnomon.org.uk> Date: Wed, 18 Aug 2004 22:33:09 +0100 To: sommerfeld@orchard.arlington.ma.us Cc: Bruce Campbell , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <20040818204040.58B8417921@portal.hamachi.org> References: <20040818204040.58B8417921@portal.hamachi.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Bill" == Bill Sommerfeld writes: Bill> Outline of an algorithm: Very neat. So lets think of what countercountermeasures at attacker might take. Assume for sake of argument a single client performing the scan. Instead of performing a single scan, it performs many scans in parallel, round robbining between them. eg do 1000 scans in parallel, each staring at different points in the namespace. So now each of my scans is 1000 times slower, to give the names time to decay back to green. You increase your decay timeout in response; I respond by increasing the number of parallel scans. Who will win? I fear you may hit the limit of how large you can set the decay timeout without seriously impacting name resolution performance long before I hit the implementation limits of this approach, although it's not clear. Of course, in reality scans by the bad guys are going to be done not by a single machine, but by armies of zombies each scanning a small portion of the namespace. But I don't think that makes much difference to the analysis; each machine is scanning a portion of the namespace, and it can split that portion into 1000 subportions and round-robin between them. -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 19 03:12:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07441 for ; Thu, 19 Aug 2004 03:12:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxh1I-000372-95 for namedroppers-data@psg.com; Thu, 19 Aug 2004 07:07:32 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxh17-00035b-Bn for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 07:07:21 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 25DC5AC8D; Thu, 19 Aug 2004 09:07:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 247EAAC8A; Thu, 19 Aug 2004 09:07:19 +0200 (CEST) Date: Thu, 19 Aug 2004 09:07:19 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Roy Badami Cc: sommerfeld@orchard.arlington.ma.us, Bruce Campbell , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <16675.51989.29809.273081@giles.gnomon.org.uk> Message-ID: References: <20040818204040.58B8417921@portal.hamachi.org> <16675.51989.29809.273081@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Aug 2004, Roy Badami wrote: > >>>>> "Bill" == Bill Sommerfeld writes: > > Bill> Outline of an algorithm: > > Very neat. So lets think of what countercountermeasures at attacker > might take. > > Assume for sake of argument a single client performing the scan. > > Instead of performing a single scan, it performs many scans in > parallel, round robbining between them. eg do 1000 scans in parallel, > each staring at different points in the namespace. So now each of my > scans is 1000 times slower, to give the names time to decay back to > green. > > You increase your decay timeout in response; I respond by increasing > the number of parallel scans. Who will win? I fear you may hit the > limit of how large you can set the decay timeout without seriously > impacting name resolution performance long before I hit the > implementation limits of this approach, although it's not clear. > > Of course, in reality scans by the bad guys are going to be done not > by a single machine, but by armies of zombies each scanning a small > portion of the namespace. But I don't think that makes much > difference to the analysis; each machine is scanning a portion of the > namespace, and it can split that portion into 1000 subportions and > round-robin between them. Oh boy, this is fun, how about this one: setup a zone, say gotcha.example.com, create a nameserver, delegate your targets as cnames under gotcha.example.com. Quickly scan a class B for resolvers, take the bulk (say 2000), and ask them for stuff under gotcha.example.com. Ofcourse, depending on the result of one query, you'd enter the target name (as cname) under gotcha. If 2000 is not enough, scan class A. If example.com becomes to visible, buy some new. So, as a defense, why not try to prevent before trying to setup detection ? 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 19 03:33:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08670 for ; Thu, 19 Aug 2004 03:33:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxhNU-0006GH-Rj for namedroppers-data@psg.com; Thu, 19 Aug 2004 07:30:28 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxhNK-0006FD-6c for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 07:30:18 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id A5F114EF7A; Thu, 19 Aug 2004 09:30:17 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5767E4EDBD for ; Thu, 19 Aug 2004 09:30:17 +0200 (CEST) Received: from x53.ripe.net (x53.ripe.net [193.0.1.53]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i7J7UHW8030208 for ; Thu, 19 Aug 2004 09:30:17 +0200 Date: Thu, 19 Aug 2004 09:30:17 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x53.ripe.net To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <20040818210218.6794D13E13@sa.vix.com> Message-ID: References: <20040818210218.6794D13E13@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.124752 / 0.0 / 0.0 / disabled X-RIPE-Signature: f8becf2e446cbf79c2258c14d01e4ec0 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Sensitivity to attack rate and false-positive rate can be adjusted by > > tweaking the window size, the color count and the decay timer.. > > > > Popular names can be locked green permanently -- the walk-detector > > will fire quickly enough once you get into dustier parts of the zone. > > i love this plan. it's simple and elegant. Also preseed the domain with certain effectively-only-reachable-via-NSEC-walk names, and you're done. > got anything that will help the non-dnssec case, where queries need neither > be sequential nor sole-sourced in order to effectively enumerate zones with > well understood allocation schemes? No. By their very nature, domains with a 'tight' naming scheme (any of the so-called 'reverse' zones, including enum) are extremely susceptible to enumeration. You can solve this for a small number of clients walking through by doing real-time analysis of query patterns (assuming you control all the authoritative servers), but you cannot solve it in cases where the attacker has patience and/or an extreme number of sources. Proposed solutions to enumeration problems should be limited to domains with 'loose' naming schemes (ie, the forward zones). --==-- Bruce. -- to unsubscribe send a message to namedroppers-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 19 04:07:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11177 for ; Thu, 19 Aug 2004 04:07:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxhur-000CXb-Pd for namedroppers-data@psg.com; Thu, 19 Aug 2004 08:04:57 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxhug-000CTJ-Ef for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 08:04:47 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i7J84eqJ023414; Thu, 19 Aug 2004 09:04:45 +0100 (BST) To: Bruce Campbell cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Bruce Campbell of "Thu, 19 Aug 2004 09:30:17 +0200." Date: Thu, 19 Aug 2004 09:04:40 +0100 Message-ID: <23413.1092902680@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Bruce" == Bruce Campbell writes: Bruce> Proposed solutions to enumeration problems should be Bruce> limited to domains with 'loose' naming schemes (ie, the Bruce> forward zones). If the WG finds a solution to zone enumeration for these sorts of zones -- and that's a very big if -- I fear someone else will then pop out of the woodwork and insist the WG finds a solution that works for e164.arpa or ip6.arpa, etc, etc. -- to unsubscribe send a message to namedroppers-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 19 04:54:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13741 for ; Thu, 19 Aug 2004 04:54:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxie4-000MBf-2M for namedroppers-data@psg.com; Thu, 19 Aug 2004 08:51:40 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxidl-000M7i-B1 for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 08:51:21 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 757B0C2DA7; Thu, 19 Aug 2004 09:51:20 +0100 (BST) Date: Thu, 19 Aug 2004 09:51:13 +0100 From: Alex Bligh Reply-To: Alex Bligh To: sommerfeld@orchard.arlington.ma.us, Bruce Campbell Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: <5A8B18346F2921C827B88C0C@[192.168.100.27]> In-Reply-To: <20040818204040.58B8417921@portal.hamachi.org> References: <20040818204040.58B8417921@portal.hamachi.org> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 18 August 2004 16:40 -0400 Bill Sommerfeld wrote: > Outline of an algorithm: > > With only one replica of a zone, it's easy -- if you hit a "green" > name, the next name gets painted "yellow"; if you hit an "yellow" > name, the reply spends some time in a penalty box and the next name > gets painted "red"; if you hit a "red" name, the server gets creative; > colors decay back to green over time. Do you propose that the colour state be a per-querier per-name attribute (in which case it's going to be defeated by a distributed attack) or simply a per-name attribute? One thing I can't quite understand is what "get creative" means in this context. Delay a reply? (in which case just say add a "-" to the name and retry), or start leading the querier "down the garden path" by fabricating names within the appropriate interval (in which case at face value you need online signing, though admittedly this can be rate-limited). 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 Thu Aug 19 05:09:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14300 for ; Thu, 19 Aug 2004 05:09:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxis7-000PP0-F4 for namedroppers-data@psg.com; Thu, 19 Aug 2004 09:06:11 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxirw-000PN1-Ik for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 09:06:00 +0000 Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i7J95rJB019497; Thu, 19 Aug 2004 05:05:54 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i7J95quv023773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Aug 2004 05:05:53 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i7J95ppO015073; Thu, 19 Aug 2004 05:05:51 -0400 Subject: Re: dictionary attack on nameservers From: Greg Hudson To: Alex Bligh Cc: namedroppers@ops.ietf.org In-Reply-To: <5A8B18346F2921C827B88C0C@[192.168.100.27]> References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1092906351.21170.175.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 19 Aug 2004 05:05:51 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_RELAY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2004-08-19 at 04:51, Alex Bligh wrote: > Do you propose that the colour state be a per-querier per-name attribute > (in which case it's going to be defeated by a distributed attack) I'm not dead-set against NSEC[23], but I'm seeing an inconsistency between two different lines of argument for hashed nsec records: "DNSSEC makes enumeration too easy. We need hashed nsec records." "But hashed nsec records won't make it that much harder to enumerate." "That's okay; security is all about raising the bar for attackers." "DNSSEC makes enumeration too easy. We need hashed nsec records." "But you can make DNSSEC enumeration harder through clever tricks." "Oh, no, that will never work; people will just use armies of zombies to conduct their enumeration." Perhaps it could be argued that hashed nsec records raise the bar much higher than implementation-specific defenses can, but I'm not wholly convinced that's true. (I continue to believe that the most practical way to deal with the enumeration problem is to allow domains to punt on authenticated denial. But that idea doesn't seem very popular.) -- to unsubscribe send a message to namedroppers-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 19 05:42:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16143 for ; Thu, 19 Aug 2004 05:42:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxjOz-0004Wv-Mc for namedroppers-data@psg.com; Thu, 19 Aug 2004 09:40:09 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxjOo-0004SC-Mh for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 09:39:58 +0000 Received: from [192.168.100.27] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id CB6E8C2DA7; Thu, 19 Aug 2004 10:39:57 +0100 (BST) Date: Thu, 19 Aug 2004 10:39:57 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Greg Hudson Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: dictionary attack on nameservers Message-ID: In-Reply-To: <1092906351.21170.175.camel@egyptian-gods.mit.edu> References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > "DNSSEC makes enumeration too easy. We need hashed nsec records." > "But you can make DNSSEC enumeration harder through clever tricks." > "Oh, no, that will never work; people will just use armies of zombies > to conduct their enumeration." I can see your point but a) armies of zombies isn't a clever trick - that's how whois mining is currently done - they need to do it ANYWAY to prevent traceability. b) As far as I can tell, Bill's proposal worked equally well (indeed in terms of minimizing required state to be held better) without the "per querier" stuff - I was just checking what he meant. > Perhaps it could be argued that hashed nsec records raise the bar much > higher than implementation-specific defenses can, but I'm not wholly > convinced that's true. I think if it could be shown there were anti-abuse mechanisms (Bill's or others) that raised the bar a comparable amount to hashed NSECs, didn't cause excess breakage, and didn't require large amounts of CPU (i.e. came at comparable expense) we'd be all ears - it would seem rather easier than changing the protocol. However, it seems to me hashed NSEC actually does raise the bar quite high (meaning that for an anti-abuse mechanism to be comparible, it also has to be pretty good). That's because right now (non-DNSSEC) the bar is (it seems to me) pretty high (Paul's in-addr.arpa attack yielded approx 3% of .de I think), it's very low with NSEC (100%), and the most effective attack on the hashed NSEC approach appears to be the brute force attack, and that gave results on .de that (IIRC) a) gave only a small % of the zone file (again see .de data) b) refined the attack dictionary poorly - i.e. the malefactor was not much better after the attack than they would be had they just used the 37^7 possibilities available before the attack. 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 Thu Aug 19 08:12:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25555 for ; Thu, 19 Aug 2004 08:12:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxlgf-0000l4-00 for namedroppers-data@psg.com; Thu, 19 Aug 2004 12:06:33 +0000 Received: from [203.217.30.81] (helo=shitei.mindrot.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxlgT-0000jq-DV for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 12:06:22 +0000 Received: from baragon.mindrot.org (unknown [IPv6:3ffe:8001:22:1:209:5bff:fe0d:f577]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id 7DA0A27C187; Thu, 19 Aug 2004 22:03:37 +1000 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id E98C81BAC87; Thu, 19 Aug 2004 22:06:16 +1000 (EST) Message-ID: <412497B8.1060500@mindrot.org> Date: Thu, 19 Aug 2004 22:06:16 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040808) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh Cc: Greg Hudson , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: >> "DNSSEC makes enumeration too easy. We need hashed nsec records." >> "But you can make DNSSEC enumeration harder through clever tricks." >> "Oh, no, that will never work; people will just use armies of zombies >>to conduct their enumeration." > > > I can see your point but > a) armies of zombies isn't a clever trick - that's how whois mining is > currently done - they need to do it ANYWAY to prevent traceability. > b) As far as I can tell, Bill's proposal worked equally well (indeed > in terms of minimizing required state to be held better) without > the "per querier" stuff - I was just checking what he meant. I don't really see how defining a window of "coloured" nsec records would work for anything but the largest zones. I'd expect most 3rd+ level domains to have very few records, so the window would need to be so small as to risk penalising valid queries. -d -- to unsubscribe send a message to namedroppers-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 19 08:48:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28164 for ; Thu, 19 Aug 2004 08:48:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxmEa-0004tC-Lu for namedroppers-data@psg.com; Thu, 19 Aug 2004 12:41:36 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxmEP-0004r7-HT for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 12:41:25 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id D8ADB143D69; Thu, 19 Aug 2004 08:27:16 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id 22195143D69; Thu, 19 Aug 2004 08:27:16 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 1A63FCF39E; Thu, 19 Aug 2004 08:41:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20040818204040.58B8417921@portal.hamachi.org> References: <20040818204040.58B8417921@portal.hamachi.org> Date: Thu, 19 Aug 2004 08:40:40 -0400 To: sommerfeld@orchard.arlington.ma.us From: Edward Lewis Subject: Re: dictionary attack on nameservers Cc: Bruce Campbell , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:40 -0400 8/18/04, Bill Sommerfeld wrote: >With only one replica of a zone, it's easy -- if you hit a "green" >name, the next name gets painted "yellow"; if you hit an "yellow" >name, the reply spends some time in a penalty box and the next name >gets painted "red"; if you hit a "red" name, the server gets creative; >colors decay back to green over time. > >To generalize to multiple replicas, paint multiple subsequent names >rather than just one; with a large enough window, with queries spread >across N replicas, at least one replica must see an in-window value >and the sequential-access detector will fire, derailing the scan on >that server.. > >Sensitivity to attack rate and false-positive rate can be adjusted by >tweaking the window size, the color count and the decay timer.. While I admire the art of this, it grates against the spirit of what I think DNS should be. That is a lightweight, core, etc., lookup service. What concerns me the most is that to do this the server has to maintain a query history. History is another word for state - building up state is a problem for DOS defense. Building and maintaining state is a lot of work - not at all light weight. My other concern is that I've had bad experience with infrastructure systems that try to guess the intent of the data stream. Especially with DNS, where everything you put in the zone is meant to be accessed. How do you detect the difference between a sudden external event (like emergency response to a natural disaster) versus malicious mining? What happens if you prevent first responders from getting needed data? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 19 08:48:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28182 for ; Thu, 19 Aug 2004 08:48:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxmF1-0004w9-LQ for namedroppers-data@psg.com; Thu, 19 Aug 2004 12:42:03 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxmEL-0004qX-2Z for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 12:41:21 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 63405143D69; Thu, 19 Aug 2004 08:27:12 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id E1651143D69; Thu, 19 Aug 2004 08:27:11 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 6948FCF39E; Thu, 19 Aug 2004 08:41:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <20040818210218.6794D13E13@sa.vix.com> Date: Thu, 19 Aug 2004 08:25:00 -0400 To: Bruce Campbell From: Edward Lewis Subject: Re: dictionary attack on nameservers Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:30 +0200 8/19/04, Bruce Campbell wrote: >Proposed solutions to enumeration problems should be limited to domains >with 'loose' naming schemes (ie, the forward zones). This is not consistent with the history of the development of the DNS protocol. The protocol should be independent of the data it carries. Basic infrastructure must remain neutral to its use. The consequences are - complexity of the protocol (having to branch in the control plane based on the contents of the data plane) and built-in limitations of how the protocol can be extended into the future. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 19 09:08:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29754 for ; Thu, 19 Aug 2004 09:08:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxmbG-0008N3-2d for namedroppers-data@psg.com; Thu, 19 Aug 2004 13:05:02 +0000 Received: from [131.111.8.20] (helo=virgo.cus.cam.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxmb5-0008IH-70 for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 13:04:51 +0000 Received: from cet1 by virgo.cus.cam.ac.uk with local (Exim 4.41) id 1Bxmb4-0006LS-Ks for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 14:04:50 +0100 Subject: Re: dictionary attack on nameservers To: namedroppers@ops.ietf.org Date: Thu, 19 Aug 2004 14:04:50 +0100 (BST) In-Reply-To: <20040818204040.58B8417921@portal.hamachi.org> from "Bill Sommerfeld" at Aug 18, 4 04:40:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: ... > Outline of an algorithm: > > With only one replica of a zone, it's easy -- if you hit a "green" > name, the next name gets painted "yellow"; if you hit an "yellow" > name, the reply spends some time in a penalty box and the next name > gets painted "red"; if you hit a "red" name, the server gets creative; > colors decay back to green over time. It seems to me that this algorithm, and the more elaborate ones along the same lines, defend only only against zone enumeration which proceeds sequentially through the name space. There is another sort of enumeration using NSEC records that doesn't work like that: . at any point, I have a number of NSEC records in hand, describing intervals free of names (and endpoints that putatively do have RRsets) . pick a name (pseudo-)randomly from the set of uncovered intervals and look it up . this gives me another NSEC record to add to my set (or possibly a known RRset, although I can make that last possibility pretty unlikely if I want) . eventually I will get a set of NSEC records covering the whole name space This isn't quite as trivial to program as the sequential walk, but it seems to me to be very nearly as efficent. Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. -- to unsubscribe send a message to namedroppers-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 19 12:21:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14019 for ; Thu, 19 Aug 2004 12:21:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxpY9-0007u1-Vx for namedroppers-data@psg.com; Thu, 19 Aug 2004 16:14:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxpXz-0007rO-FK for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 16:13:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 19E3C13E14 for ; Thu, 19 Aug 2004 16:13:51 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Jim Reid of "Thu, 19 Aug 2004 09:04:40 +0100." <23413.1092902680@gromit.rfc1035.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 19 Aug 2004 16:13:51 +0000 Message-Id: <20040819161351.19E3C13E14@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Bruce> Proposed solutions to enumeration problems should be > Bruce> limited to domains with 'loose' naming schemes (ie, the > Bruce> forward zones). > > If the WG finds a solution to zone enumeration for these sorts of > zones -- and that's a very big if -- I fear someone else will then pop > out of the woodwork and insist the WG finds a solution that works for > e164.arpa or ip6.arpa, etc, etc. i'm sure the WG's (or the IAB's) answer in that case would be "DNS does not offer privacy, if there's something you don't want publically searchable, then don't put it in DNS." (oops.) -- to unsubscribe send a message to namedroppers-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 19 15:17:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26151 for ; Thu, 19 Aug 2004 15:17:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxsLA-0005sC-Ia for namedroppers-data@psg.com; Thu, 19 Aug 2004 19:12:48 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxsKT-0005nY-QK for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 19:12:06 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i7JJBxEG036610 for ; Thu, 19 Aug 2004 15:12:00 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i7JJBx8U036609 for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 15:11:59 -0400 (EDT) (envelope-from namedroppers) Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxj6I-0001EK-AN for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 09:20:50 +0000 Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i7J9Knj25082 for ; Thu, 19 Aug 2004 02:20:49 -0700 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i7J9KnMp013326 for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 02:20:49 -0700 Date: Thu, 19 Aug 2004 02:20:49 -0700 From: kent crispin To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers Message-ID: <20040819092049.GZ6165@raven.songbird.com> Mail-Followup-To: namedroppers@ops.ietf.org References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A8B18346F2921C827B88C0C@[192.168.100.27]> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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-subsrcibers. Please fix your subscription addresses. ] On Thu, Aug 19, 2004 at 09:51:13AM +0100, Alex Bligh wrote: > >gets painted "red"; if you hit a "red" name, the server gets creative; > >colors decay back to green over time. > > Do you propose that the colour state be a per-querier per-name attribute > (in which case it's going to be defeated by a distributed attack) or simply > a per-name attribute? In which case, of course, it provides an avenue for trivial DOS attacks. -- Kent Crispin kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.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 19 15:18:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26241 for ; Thu, 19 Aug 2004 15:18:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxsLL-0005tg-7t for namedroppers-data@psg.com; Thu, 19 Aug 2004 19:12:59 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxsKF-0005k3-SD for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 19:11:52 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id i7JJBiVH036605 for ; Thu, 19 Aug 2004 15:11:44 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id i7JJBitR036604 for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 15:11:44 -0400 (EDT) (envelope-from namedroppers) Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxnVn-000GRd-1h for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 14:03:27 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i7JE376G035552; Thu, 19 Aug 2004 10:03:08 -0400 (EDT) (envelope-from ogud+dnsext@ogud.com) Message-Id: <6.1.0.6.2.20040819092046.02d2dec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Thu, 19 Aug 2004 09:39:27 -0400 To: Thomas Narten , Margaret Wasserman From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Advancement Request: DNSEXT RFC3597 to Draft Standard Cc: iesg-secretary@ietf.org, "Olaf M. Kolkman" , ogud+dnsext@ogud.com, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_691781449==_" X-Scanned-By: MIMEDefang 2.44 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ 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-subsrcibers. Please fix your subscription addresses. ] --=====================_691781449==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Thomas and Margaret The DNSEXT working group has conducted interoperabilty testing of RFC3597 and concluded that it can be advanced without changes from Proposed Standard to Draft Standard. The interoperabilty report is attached to this message. Multiple implementations where tested and minor bugs where found all of which where programmer errors, none where documentation issues. Olafur --=====================_691781449==_ Content-Type: text/plain; name="interop.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="interop.txt" Content-Transfer-Encoding: base64 RE5TIEV4dGVuc2lvbnMgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEouIFNjaGx5dGVyCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBdWd1c3QgMiwgMjAwNApFeHBpcmVzOiBKYW51YXJ5IDMxLCAyMDA1 CgoKICAgICAgICAgICAgICAgICAgICBSRkMgMzI2NyBJbnRlcm9wZXJhYmlsaXR5IFJlcG9ydAog ICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWRuc2V4dC1pbnRlcm9wMzU5Ny0wMC50eHQKClN0 YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwg SSBjZXJ0aWZ5IHRoYXQgYW55IGFwcGxpY2FibGUKICAgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFp bXMgb2Ygd2hpY2ggSSBhbSBhd2FyZSBoYXZlIGJlZW4gZGlzY2xvc2VkLAogICBhbmQgYW55IG9m IHdoaWNoIEkgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdp dGgKICAgUkZDIDM2NjcuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgb3RoZXIKICAgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLgoK ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29s ZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhlIGxpc3Qg b2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IGh0dHA6Ly8KICAg d3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICBUaGUgbGlzdCBvZiBJbnRl cm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg ZXhwaXJlIG9uIEphbnVhcnkgMzEsIDIwMDUuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmln aHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4K CkFic3RyYWN0CgogICBUaGlzIG1lbW8gZG9jdW1lbnRzIHRoZSByZXN1bHQgZnJvbSB0aGUgUkZD IDMyNjcgKEhhbmRsaW5nIG9mIFVua25vd24KICAgRE5TIFJlc291cmNlIFJlY29yZCBUeXBlcykg aW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nLgoKCgoKCgoKCgoKCgpTY2hseXRlciAgICAgICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgMzEsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMV0KCklu dGVybmV0LURyYWZ0ICAgICAgUkZDIDMyNjcgSW50ZXJvcGVyYWJpbGl0eSBSZXBvcnQgICAgICAg ICBBdWd1c3QgMjAwNAoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgMi4g IEltcGxlbWVudGF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzCiAgIDMuICBUZXN0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAzLjEgQXV0aG9yaXRhdGl2ZSBQcmltYXJ5IE5h bWUgU2VydmVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgMy4yIEF1dGhvcml0 YXRpdmUgU2Vjb25kYXJ5IE5hbWUgU2VydmVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAz CiAgIDMuMyBGdWxsIFJlY3Vyc2l2ZSBSZXNvbHZlciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMwogICAzLjQgU3R1YiBSZXNvbHZlciAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgMy41IEROU1NFQyBTaWduZXIgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDQuICBQ cm9ibGVtcyBmb3VuZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNAogICA1LiAgU3VtbWFyeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAgICBBdXRob3IncyBB ZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAog ICBBLiAgVGVzdCB6b25lIGRhdGEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDUKICAgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0 IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuICA2CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKU2NobHl0ZXIgICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDMxLCAyMDA1 ICAgICAgICAgICAgICAgIFtQYWdlIDJdCgpJbnRlcm5ldC1EcmFmdCAgICAgIFJGQyAzMjY3IElu dGVyb3BlcmFiaWxpdHkgUmVwb3J0ICAgICAgICAgQXVndXN0IDIwMDQKCgoxLiBJbnRyb2R1Y3Rp b24KCiAgIFRoaXMgbWVtbyBkb2N1bWVudHMgdGhlIHJlc3VsdCBmcm9tIHRoZSBSRkMgMzI2NyAo SGFuZGxpbmcgb2YgVW5rbm93bgogICBETlMgUmVzb3VyY2UgUmVjb3JkIFR5cGVzKSBpbnRlcm9w ZXJhYmlsaXR5IHRlc3RpbmcuICBUaGUgdGVzdCB3YXMKICAgcGVyZm9ybWVkIGR1cmluZyBKdW5l IGFuZCBKdWx5IDIwMDQgYnkgcmVxdWVzdCBvZiB0aGUgSUVURiBETlMKICAgRXh0ZW5zaW9ucyBX b3JraW5nIEdyb3VwLgoKMi4gSW1wbGVtZW50YXRpb25zCgogICBUaGUgZm9sbG93aW5nIGlzIGEg bGlzdCwgaW4gYWxwaGFiZXRpYyBvcmRlciwgb2YgaW1wbGVtZW50YXRpb25zIGZvcgogICBjb21w bGlhbmNlIG9mIFJGQyAzNTk3OgoKICAgICAgRE5TSmF2YSAxLjYuNAogICAgICBJU0MgQklORCA4 LjQuNXJjNAogICAgICBJU0MgQklORCA5LjMuMHJjMgogICAgICBOU0QgMi4xLjEKICAgICAgTmV0 OjpETlMgMC40NyBwYXRjaGxldmVsIDEKICAgICAgTm9taW51bSBBTlMgMi4yLjEuMC5kCgogICBU aGVzZSBpbXBsZW1lbnRhdGlvbnMgY292ZXJzIHRoZSBmb2xsb3dpbmcgZnVuY3Rpb25zIChudW1i ZXIgb2YKICAgaW1wbGVtZW50YXRpb25zIHRlc3RlZCBmb3IgZWFjaCBmdW5jdGlvbiBpbiBwYXJh bnRoZXNpcyk6CgogICAgICBBdXRob3JpdGF0aXZlIE5hbWUgU2VydmVycyAoNCkKICAgICAgRnVs bCBSZWN1cnNpdmUgUmVzb2x2ZXIgKDIpCiAgICAgIFN0dWIgUmVzb2x2ZXIgKDQpCiAgICAgIERO U1NFQyBab25lIFNpZ25lcnMgKDIpCgozLiBUZXN0cwoKMy4xIEF1dGhvcml0YXRpdmUgUHJpbWFy eSBOYW1lIFNlcnZlcgoKICAgVGhlIHRlc3Qgem9uZSBkYXRhIChBcHBlbmRpeCBBKSB3YXMgbG9h ZGVkIGludG8gdGhlIG5hbWUgc2VydmVyCiAgIGltcGxlbWVudGF0aW9uIGFuZCB0aGUgc2VydmVy IHdhcyBxdWVyaWVkIGZvciB0aGUgbG9hZGVkIGluZm9ybWF0aW9uLgoKMy4yIEF1dGhvcml0YXRp dmUgU2Vjb25kYXJ5IE5hbWUgU2VydmVyCgogICBUaGUgdGVzdCB6b25lIGRhdGEgKEFwcGVuZGl4 IEEpIHdhcyB0cmFuc2ZlcnJlZCB1c2luZyBBWEZSIGZyb20KICAgYW5vdGhlciBuYW1lIHNlcnZl ciBpbXBsZW1lbnRhdGlvbiBhbmQgdGhlIHNlcnZlciB3YXMgcXVlcmllZCBmb3IgdGhlCiAgIHRy YW5zZmVycmVkIGluZm9ybWF0aW9uLgoKMy4zIEZ1bGwgUmVjdXJzaXZlIFJlc29sdmVyCgogICBB IHJlY3Vyc2l2ZSByZXNvbHZlciB3YXMgcXVlcmllZCBmb3IgcmVzb3VyY2UgcmVjb3JkcyBmcm9t IGEgZG9tYWluCiAgIHdpdGggdGhlIHRlc3Qgem9uZSBkYXRhIChBcHBlbmRpeCBBKS4KCjMuNCBT dHViIFJlc29sdmVyCgogICBBIHN0dWIgcmVzb2x2ZXIgd2FzIHVzZWQgdG8gcXVlcnkgcmVzb3Vy Y2UgcmVjb3JkcyBmcm9tIGEgZG9tYWluIHdpdGgKCgoKU2NobHl0ZXIgICAgICAgICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDMxLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDNdCgpJbnRlcm5l dC1EcmFmdCAgICAgIFJGQyAzMjY3IEludGVyb3BlcmFiaWxpdHkgUmVwb3J0ICAgICAgICAgQXVn dXN0IDIwMDQKCgogICB0aGUgdGVzdCB6b25lIGRhdGEgKEFwcGVuZGl4IEEpLgoKMy41IEROU1NF QyBTaWduZXIKCiAgIEEgRE5TU0VDIHNpZ25lciB3YXMgdXNlZCB0byBzaWduIGEgem9uZSB3aXRo IHRlc3Qgem9uZSBkYXRhIChBcHBlbmRpeAogICBBKS4KCjQuIFByb2JsZW1zIGZvdW5kCgogICBU d28gaW1wbGVtZW50YXRpb25zIGhhZCBwcm9ibGVtcyB3aXRoIHRleHQgcHJlc2VudGF0aW9uIG9m IHplcm8KICAgbGVuZ3RoIFJEQVRBLgoKICAgT25lIGltcGxlbWVudGF0aW9uIGhhZCBwcm9ibGVt cyB3aXRoIHRleHQgcHJlc2VudGF0aW9uIG9mIFJSIHR5cGUKICAgY29kZSBhbmQgY2xhc3NlcyA+ PSA0MDk2LgoKICAgQnVnIHJlcG9ydHMgd2VyZSBmaWxlZCBmb3IgcHJvYmxlbXMgZm91bmQuCgo1 LiBTdW1tYXJ5CgogICBVbmtub3duIHR5cGUgY29kZXMgd29ya3MgaW4gdGhlIHRlc3RlZCBhdXRo b3JpdGF0aXZlIHNlcnZlcnMsCiAgIHJlY3Vyc2l2ZSByZXNvbHZlcnMgYW5kIHN0dWIgY2xpZW50 cy4KCiAgIE5vIGNoYW5nZXMgYXJlIG5lZWRlZCB0byBhZHZhbmNlIFJGQyAzNTk3IHRvIGRyYWZ0 IHN0YW5kYXJkLgoKTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFsxXSAgR3VzdGFmc3NvbiwgQS4s ICJIYW5kbGluZyBvZiBVbmtub3duIEROUyBSZXNvdXJjZSBSZWNvcmQgKFJSKQogICAgICAgIFR5 cGVzIiwgUkZDIDM1OTcsIFNlcHRlbWJlciAyMDAzLgoKCkF1dGhvcidzIEFkZHJlc3MKCiAgIEph a29iIFNjaGx5dGVyCgogICBFTWFpbDogamFrb2JAcmZjLnNlCgoKCgoKCgoKCgoKCgoKCgpTY2hs eXRlciAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMzEsIDIwMDUgICAgICAgICAgICAg ICAgW1BhZ2UgNF0KCkludGVybmV0LURyYWZ0ICAgICAgUkZDIDMyNjcgSW50ZXJvcGVyYWJpbGl0 eSBSZXBvcnQgICAgICAgICBBdWd1c3QgMjAwNAoKCkFwcGVuZGl4IEEuIFRlc3Qgem9uZSBkYXRh CgogICA7IEEtcmVjb3JkIGVuY29kZWQgYXMgVFlQRTEKICAgYSAgVFlQRTEgIFwjIDQgN2YwMDAw MDEKICAgYSAgVFlQRTEgIDE5Mi4wLjIuMQogICBhICBBICAgICAgXCMgNCA3ZjAwMDAwMgoKICAg OyBkcmFmdC1pZXRmLXNlY3NoLWRucy0wNS50eHQKICAgc3NoZnAgIFRZUEU0NCAgXCMgMjIgMDEg MDEgYzY5MWU5MDcxNGExNjI5ZDE2N2RlOGU1ZWUwMDIxZjEyYTdlYWExZQoKICAgOyBib2d1cyB0 ZXN0IHJlY29yZCAoZnJvbSBSRkMgMzU5NykKICAgdHlwZTczMSAgICBUWVBFNzMxICAgIFwjIDYg YWJjZCAoCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVmIDAxIDIzIDQ1ICkKCiAgIDsg emVybyBsZW5ndGggUkRBVEEgKGZyb20gUkZDIDM1OTcpCiAgIHR5cGU2MjM0NyAgVFlQRTYyMzQ3 ICBcIyAwCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKU2NobHl0ZXIgICAgICAg ICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDMxLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDVd CgpJbnRlcm5ldC1EcmFmdCAgICAgIFJGQyAzMjY3IEludGVyb3BlcmFiaWxpdHkgUmVwb3J0ICAg ICAgICAgQXVndXN0IDIwMDQKCgpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50CgogICBU aGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3Bl IG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0 aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24g b3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRvY3VtZW50IG9y IHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMKICAgbWln aHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQg aXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3Vj aCByaWdodHMuIEluZm9ybWF0aW9uCiAgIG9uIHRoZSBJRVRGJ3MgcHJvY2VkdXJlcyB3aXRoIHJl c3BlY3QgdG8gcmlnaHRzIGluIElFVEYgRG9jdW1lbnRzIGNhbgogICBiZSBmb3VuZCBpbiBCQ1Ag NzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUg SUVURiBTZWNyZXRhcmlhdCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9i dGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1 Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAg IHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIg cmVwb3NpdG9yeSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGlu dml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkK ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw cm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBi ZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gUGxlYXNlIGFkZHJlc3Mg dGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoKCkRp c2NsYWltZXIgb2YgVmFsaWRpdHkKCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbgogICAiQVMgSVMiIGJhc2lzIGFu ZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMKICAg T1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhF IElOVEVSTkVUCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJ RVMsIEVYUFJFU1MgT1IgSU1QTElFRCwKICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBB TlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lM TCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRAogICBXQVJSQU5USUVTIE9G IE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4KCgpD b3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5 ICgyMDA0KS4gVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0CiAgIHRvIHRoZSByaWdodHMsIGxpY2Vu c2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kCiAgIGV4Y2VwdCBh cyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMu CgoKQWNrbm93bGVkZ21lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9u IGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUKICAgSW50ZXJuZXQgU29jaWV0eS4KCgoKClNj aGx5dGVyICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAzMSwgMjAwNSAgICAgICAgICAg ICAgICBbUGFnZSA2XQo= --=====================_691781449==_-- -- to unsubscribe send a message to namedroppers-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 19 15:25:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27193 for ; Thu, 19 Aug 2004 15:25:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxsUC-00076r-N9 for namedroppers-data@psg.com; Thu, 19 Aug 2004 19:22:08 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxsTt-00073H-UA for namedroppers@ops.ietf.org; Thu, 19 Aug 2004 19:21:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26726; Thu, 19 Aug 2004 15:21:47 -0400 (EDT) Message-Id: <200408191921.PAA26726@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tsig-sha-00.txt Date: Thu, 19 Aug 2004 15:21:47 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 : HMAC SHA TSIG Algorithm Identifiers Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tsig-sha-00.txt Pages : 8 Date : 2004-8-19 Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document standardizes identifiers for additional HMAC SHA TSIG algorithms and standardizes how to specify the truncation of HMAC values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-tsig-sha-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-19152244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tsig-sha-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-19152244.I-D@ietf.org> --OtherAccess-- --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 Fri Aug 20 10:15:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15418 for ; Fri, 20 Aug 2004 10:15:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByA3X-000JsH-Uv for namedroppers-data@psg.com; Fri, 20 Aug 2004 14:07:47 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByA3M-000Jqo-W7 for namedroppers@ops.ietf.org; Fri, 20 Aug 2004 14:07:37 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 47D1AAC92; Fri, 20 Aug 2004 16:07:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 46BC5AC8C for ; Fri, 20 Aug 2004 16:07:34 +0200 (CEST) Date: Fri, 20 Aug 2004 16:07:34 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: <20040819161351.19E3C13E14@sa.vix.com> Message-ID: References: <20040819161351.19E3C13E14@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 19 Aug 2004, Paul Vixie wrote: > i'm sure the WG's (or the IAB's) answer in that case would be "DNS does > not offer privacy, if there's something you don't want publically > searchable, then don't put it in DNS." DNS is a public lookup, not a public search mechanism. DNSSEC introduces this search capability into the protocol. Ofcourse this search capability is already available for adversaries (and honest uses) by using google, reverse space, or available through ISC's domain survey, and yet, folks want to make it even more easier by not fixing NSEC. So, just for fun and profit: How about a front end for dnssec enabled zones. The cost for the most recent dataset if $2500 per TLD. An anual subscription is available for $7250. ;) (oops.) -- to unsubscribe send a message to namedroppers-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 21 11:54:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18925 for ; Sat, 21 Aug 2004 11:54:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByY4W-000H1b-3n for namedroppers-data@psg.com; Sat, 21 Aug 2004 15:46:24 +0000 Received: from [140.239.227.17] (helo=portal.hamachi.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByY4K-000Gzx-Ur for namedroppers@ops.ietf.org; Sat, 21 Aug 2004 15:46:13 +0000 Received: from portal (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 996A317921; Sat, 21 Aug 2004 11:46:11 -0400 (EDT) From: Bill Sommerfeld To: Alex Bligh Cc: sommerfeld@orchard.arlington.ma.us, Bruce Campbell , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Alex Bligh of "Thu, 19 Aug 2004 09:51:13 BST." <5A8B18346F2921C827B88C0C@[192.168.100.27]> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Sat, 21 Aug 2004 11:46:11 -0400 Message-Id: <20040821154611.996A317921@portal.hamachi.org> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Do you propose that the colour state be a per-querier per-name attribute > (in which case it's going to be defeated by a distributed attack) or simply > a per-name attribute? The intent was a per-name attribute; my assumption is that all attacks will be distributed. > One thing I can't quite understand is what "get creative" means in this > context. Delay a reply? (in which case just say add a "-" to the name and > retry), or start leading the querier "down the garden path" by fabricating > names within the appropriate interval (in which case at face value you need > online signing, though admittedly this can be rate-limited). My focus was on scan detection under the assumption that Someone Else could think up appropriate countermeasures once a scan was detected. I didn't consider the possibility of Chris Thompson's divide-and-conquer random-order scan, so this is likely moot. - 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 Sun Aug 22 07:17:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19058 for ; Sun, 22 Aug 2004 07:17:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByqHp-0002h0-2P for namedroppers-data@psg.com; Sun, 22 Aug 2004 11:13:21 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByqHd-0002g1-SX for namedroppers@ops.ietf.org; Sun, 22 Aug 2004 11:13:10 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 8C89F107C26; Sun, 22 Aug 2004 11:13:08 +0000 (GMT) Message-ID: <41287FC3.1090905@algroup.co.uk> Date: Sun, 22 Aug 2004 12:13:07 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Campbell Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <87oel8bk0r.fsf@deneb.enyo.de> <87brh8bhz2.fsf@deneb.enyo.de> In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bruce Campbell wrote: > On Wed, 18 Aug 2004, Roy Arends wrote: > > >>I don't, I'd enumerate them thru nsec. Call me lazy. > > > It won't be too long before some Registry coddles up a nameserver that > detects nsec/other-based enumuration query trends, and starts dynamically > inserting bogus records to lead the attacker through a twisted trail of > normally-non-existent domains (ala web page scripts that provide lots of > bogus email addresses to fill a scrapper's database with crap). Dynamic insertion of records would require a signing key to be available to all nameservers. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 22 07:54:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20366 for ; Sun, 22 Aug 2004 07:54:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByqtX-00083w-3p for namedroppers-data@psg.com; Sun, 22 Aug 2004 11:52:19 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByqtM-00082o-3v for namedroppers@ops.ietf.org; Sun, 22 Aug 2004 11:52:08 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 41CD5107D23; Sun, 22 Aug 2004 11:52:07 +0000 (GMT) Message-ID: <412888E6.3020906@algroup.co.uk> Date: Sun, 22 Aug 2004 12:52:06 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: hopefully was RE: dictionary attack on nameservers References: In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > As a bystander to this thread, my reaction has been largely "so what?" > As a protocol analyst, I don't care how motivated or how efficient the > attacker is. All I care to do is see if I can remove the offending > feature. > > My question remains: > Is there a way to prove the non-existence of a name without > - exposing any of the contents of the zone? > - muddying up the name space with fake names or data sets? > - on-line cryptographic operations? > - being vulnerable to replay attacks of the negative answer? > > If there were a way to avoid all four, that'd be the answer. NSEC > avoids 3 of 4 of them (that's better than Meatloaf's declaration "2 out > of 3 ain't bad"). Other approaches avoid a different 3 of 4. I presume you're suggesting that NSEC2 fails on "muddying up the name space" - if so, I don't really understand why, and if not, where does it fail? > Note that "- a change to the protocol" isn't on my list. That's > important too, but it's an institutional issue (IETF) not a physics > (protocol) issue. If we can't get the physics right, we ain't going to > get the institution right. > > (I suppose I should wait until the requirements come out before asking > if there's a 4 of 4 solution. But, once the requirements do - that's > what I'll be looking for.) Absolutely. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 22 07:57:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20478 for ; Sun, 22 Aug 2004 07:57:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Byqwi-0008ae-TV for namedroppers-data@psg.com; Sun, 22 Aug 2004 11:55:36 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByqwY-0008YN-73 for namedroppers@ops.ietf.org; Sun, 22 Aug 2004 11:55:26 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 57DE4107D0F; Sun, 22 Aug 2004 11:55:25 +0000 (GMT) Message-ID: <412889AC.2080709@algroup.co.uk> Date: Sun, 22 Aug 2004 12:55:24 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <1092765264.21170.83.camel@egyptian-gods.mit.edu> In-Reply-To: <1092765264.21170.83.camel@egyptian-gods.mit.edu> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Hudson wrote: > On Tue, 2004-08-17 at 13:23, Hallam-Baker, Phillip wrote: > >>We have a security need, we have a simple solution, > > > We do? It seems like hashed nsec records aren't going to stop organized > crime families. Only online signing of negative responses would really > prevent someone from enumerating a zone, and online signing is a vector > for DOSing DNS itself. Surely online signing is no more effective than hashing (i.e. they are both susceptible to dictionary attacks)? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 22 10:24:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29577 for ; Sun, 22 Aug 2004 10:24:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BytD9-000PqG-LN for namedroppers-data@psg.com; Sun, 22 Aug 2004 14:20:43 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BytCy-000Pmo-Q1 for namedroppers@ops.ietf.org; Sun, 22 Aug 2004 14:20:32 +0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i7MEKQdq024418; Sun, 22 Aug 2004 10:20:26 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i7MEKPJV027420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Aug 2004 10:20:26 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i7MEKOSj023915; Sun, 22 Aug 2004 10:20:24 -0400 Subject: Re: dictionary attack on nameservers From: Greg Hudson To: Ben Laurie Cc: namedroppers@ops.ietf.org In-Reply-To: <412889AC.2080709@algroup.co.uk> References: <1092765264.21170.83.camel@egyptian-gods.mit.edu> <412889AC.2080709@algroup.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1093184424.1632.25.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 22 Aug 2004 10:20:24 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_RELAY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2004-08-22 at 07:55, Ben Laurie wrote: > Surely online signing is no more effective than hashing (i.e. they are > both susceptible to dictionary attacks)? Well, an offline dictionary attack is much, muhc faster than an online one. (Particularly if the server has to perform online signing for each iteration of the online one.) It's possible that I've overestimated how effective an offline dictionary attack can be, in which case perhaps hashed nsec records really do raise the bar high enough. -- to unsubscribe send a message to namedroppers-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 22 11:40:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03209 for ; Sun, 22 Aug 2004 11:40:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByuOG-000CQq-5M for namedroppers-data@psg.com; Sun, 22 Aug 2004 15:36:16 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByuNx-000CNR-Cc for namedroppers@ops.ietf.org; Sun, 22 Aug 2004 15:35:57 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 31B1D107C51; Sun, 22 Aug 2004 15:35:56 +0000 (GMT) Message-ID: <4128BD5B.60903@algroup.co.uk> Date: Sun, 22 Aug 2004 16:35:55 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <1092765264.21170.83.camel@egyptian-gods.mit.edu> <412889AC.2080709@algroup.co.uk> <1093184424.1632.25.camel@egyptian-gods.mit.edu> In-Reply-To: <1093184424.1632.25.camel@egyptian-gods.mit.edu> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Hudson wrote: > On Sun, 2004-08-22 at 07:55, Ben Laurie wrote: > >>Surely online signing is no more effective than hashing (i.e. they are >>both susceptible to dictionary attacks)? > > > Well, an offline dictionary attack is much, muhc faster than an online > one. (Particularly if the server has to perform online signing for each > iteration of the online one.) > > It's possible that I've overestimated how effective an offline > dictionary attack can be, in which case perhaps hashed nsec records > really do raise the bar high enough. The idea was to make the cost similar to an online attack - this is why there is an iterations field. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 22 13:01:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06942 for ; Sun, 22 Aug 2004 13:01:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Byvex-000P95-2N for namedroppers-data@psg.com; Sun, 22 Aug 2004 16:57:35 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Byvem-000P7s-IJ for namedroppers@ops.ietf.org; Sun, 22 Aug 2004 16:57:24 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 570EB13E12 for ; Sun, 22 Aug 2004 16:57:24 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Ben Laurie of "Sun, 22 Aug 2004 12:13:07 +0100." <41287FC3.1090905@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 22 Aug 2004 16:57:24 +0000 Message-Id: <20040822165724.570EB13E12@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > It won't be too long before some Registry coddles up a nameserver > > that detects nsec/other-based enumuration query trends, and starts > > dynamically inserting bogus records to lead the attacker through a > > twisted trail of normally-non-existent domains (ala web page scripts > > that provide lots of bogus email addresses to fill a scrapper's > > database with crap). > > Dynamic insertion of records would require a signing key to be > available to all nameservers. i don't think that's true. the DNS I-N-D model is that updates are applied at the master server and then trickle down to the slave servers. in the BIND9 case, only the master server for a secure zone needs the signing key, and the zone would be incrementally re-signed after each UPDATE, and the changes would be NOTIFY'd and IXFR'd out to the slaves. and as far as i know, BIND9 follows/respects all the relevant standards. so, if dynamic bogus name insertion were used as a defense against an "enumeration attack", then only the master server would need an online signing key. of course, i don't think this would be a good "defense", or even that enumeration constitutes an "attack". but i wanted to set the record straight about the DNS I-N-D model as it applies to dynamic secure zones. -- to unsubscribe send a message to namedroppers-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 22 17:15:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19284 for ; Sun, 22 Aug 2004 17:15:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Byzb8-0001O4-SG for namedroppers-data@psg.com; Sun, 22 Aug 2004 21:09:54 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Byzax-0001My-SX for namedroppers@ops.ietf.org; Sun, 22 Aug 2004 21:09:44 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 6084A107C51; Sun, 22 Aug 2004 21:09:42 +0000 (GMT) Message-ID: <41290B95.5080309@algroup.co.uk> Date: Sun, 22 Aug 2004 22:09:41 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <20040822165724.570EB13E12@sa.vix.com> In-Reply-To: <20040822165724.570EB13E12@sa.vix.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>It won't be too long before some Registry coddles up a nameserver >>>that detects nsec/other-based enumuration query trends, and starts >>>dynamically inserting bogus records to lead the attacker through a >>>twisted trail of normally-non-existent domains (ala web page scripts >>>that provide lots of bogus email addresses to fill a scrapper's >>>database with crap). >> >>Dynamic insertion of records would require a signing key to be >>available to all nameservers. > > i don't think that's true. the DNS I-N-D model is that updates are > applied at the master server and then trickle down to the slave servers. > > in the BIND9 case, only the master server for a secure zone needs the > signing key, and the zone would be incrementally re-signed after each > UPDATE, and the changes would be NOTIFY'd and IXFR'd out to the slaves. > > and as far as i know, BIND9 follows/respects all the relevant standards. > > so, if dynamic bogus name insertion were used as a defense against an > "enumeration attack", then only the master server would need an online > signing key. This would require secondaries to notify the primary of attacks so it could start generating the bogus records, then. Probably this would be required to detect them, otherwise the attacker would distribute over the secondaries. So, OK, I agree - but it would be horribly slow. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 22 19:45:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26755 for ; Sun, 22 Aug 2004 19:45:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bz1z5-000GIL-85 for namedroppers-data@psg.com; Sun, 22 Aug 2004 23:42:47 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bz1yu-000GFe-Mk for namedroppers@ops.ietf.org; Sun, 22 Aug 2004 23:42:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5B4CC13DFF for ; Sun, 22 Aug 2004 23:42:36 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers In-Reply-To: Message from Ben Laurie of "Sun, 22 Aug 2004 22:09:41 +0100." <41290B95.5080309@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 22 Aug 2004 23:42:36 +0000 Message-Id: <20040822234236.5B4CC13DFF@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... > > so, if dynamic bogus name insertion were used as a defense against an > > "enumeration attack", then only the master server would need an online > > signing key. > > This would require secondaries to notify the primary of attacks so it > could start generating the bogus records, then. no. you're still not seeing the full model. the slave server who detected the attack would start generating dynamic updates toward the master server, who would apply them, incrementally resign the zone, and do NOTIFY/IXFR to propagate these changes back out to all of the slave servers for the zone. > Probably this would be required to detect them, otherwise the attacker > would distribute over the secondaries. So, OK, I agree - but it would > be horribly slow. the fact that you would have to know the query streams at all of a zone's servers, in real time, in order to detect an enumeration attack, is not the result of the I-N-D model. interestingly, this need for universal knowledge means that almost no ratelimit-based defense is practical, unless the zone is served by a single (gigantic?) server, which is also impractical. -- to unsubscribe send a message to namedroppers-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 23 08:24:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03502 for ; Mon, 23 Aug 2004 08:24:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzDlf-000B9b-7H for namedroppers-data@psg.com; Mon, 23 Aug 2004 12:17:43 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzDlE-000B8L-H5 for namedroppers@ops.ietf.org; Mon, 23 Aug 2004 12:17:16 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 4B5FB107BEF; Mon, 23 Aug 2004 12:17:15 +0000 (GMT) Message-ID: <4129E04B.2020108@algroup.co.uk> Date: Mon, 23 Aug 2004 13:17:15 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <20040822234236.5B4CC13DFF@sa.vix.com> In-Reply-To: <20040822234236.5B4CC13DFF@sa.vix.com> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>... >>>so, if dynamic bogus name insertion were used as a defense against an >>>"enumeration attack", then only the master server would need an online >>>signing key. >> >>This would require secondaries to notify the primary of attacks so it >>could start generating the bogus records, then. > > > no. you're still not seeing the full model. the slave server who detected > the attack would start generating dynamic updates toward the master server, > who would apply them, incrementally resign the zone, and do NOTIFY/IXFR to > propagate these changes back out to all of the slave servers for the zone. Ah, I see. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Mon Aug 23 09:08:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06572 for ; Mon, 23 Aug 2004 09:08:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzEV3-000GTo-Jc for namedroppers-data@psg.com; Mon, 23 Aug 2004 13:04:37 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzEUs-000GSA-Tp for namedroppers@ops.ietf.org; Mon, 23 Aug 2004 13:04:27 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 80308144134; Mon, 23 Aug 2004 08:49:13 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id 03ED414411C; Mon, 23 Aug 2004 08:49:13 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id CCC15CF39E; Mon, 23 Aug 2004 09:04:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <412888E6.3020906@algroup.co.uk> References: <412888E6.3020906@algroup.co.uk> Date: Mon, 23 Aug 2004 08:43:41 -0400 To: Ben Laurie From: Edward Lewis Subject: Re: hopefully was RE: dictionary attack on nameservers Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:52 +0100 8/22/04, Ben Laurie wrote: >I presume you're suggesting that NSEC2 fails on "muddying up the name space" - >if so, I don't really understand why, and if not, where does it fail? Yes, for one NSEC2 removes "empty non-terminals" from the lexicon via the EXIST record. I need to go back to my notes on NSEC2 to check something out[0]...but I'm a bit reluctant to go forward until we have requirements on the table. I have yet another approach in mind, but it's not worth discussing approaches unless it's clear what we are solving. [0] - Yeah, that's a case of the old "hollow threat." Does NSEC2 really hide names given that to answer negatively, I need to reveal there's no applicable wild card record? The issue is that to show that if there's no wild card, I have to reveal where it would have been - usually at the already obvious apex, but sometimes at another name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 23 11:46:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17542 for ; Mon, 23 Aug 2004 11:46:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzGxq-0009Ql-Ss for namedroppers-data@psg.com; Mon, 23 Aug 2004 15:42:30 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzGxf-0009Pi-PX for namedroppers@ops.ietf.org; Mon, 23 Aug 2004 15:42:20 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 94016107BFD; Mon, 23 Aug 2004 15:42:18 +0000 (GMT) Message-ID: <412A105A.8040401@algroup.co.uk> Date: Mon, 23 Aug 2004 16:42:18 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: hopefully was RE: dictionary attack on nameservers References: <412888E6.3020906@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 12:52 +0100 8/22/04, Ben Laurie wrote: > >> I presume you're suggesting that NSEC2 fails on "muddying up the name >> space" - >> if so, I don't really understand why, and if not, where does it fail? > > > Yes, for one NSEC2 removes "empty non-terminals" from the lexicon via > the EXIST record. > > I need to go back to my notes on NSEC2 to check something out[0]...but > I'm a bit reluctant to go forward until we have requirements on the > table. I have yet another approach in mind, but it's not worth > discussing approaches unless it's clear what we are solving. > > [0] - Yeah, that's a case of the old "hollow threat." Does NSEC2 really > hide names given that to answer negatively, I need to reveal there's no > applicable wild card record? The issue is that to show that if there's > no wild card, I have to reveal where it would have been - usually at the > already obvious apex, but sometimes at another name. Sure, but if I have queried for a.b.c.d, then you have to reveal b.c.d - which I could have checked with a single extra query, or in general with a small number of extra queries (one per component), so this isn't really a massive hole. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 Mon Aug 23 15:25:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04016 for ; Mon, 23 Aug 2004 15:25:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzKMk-0009Bv-A7 for namedroppers-data@psg.com; Mon, 23 Aug 2004 19:20:26 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzKMZ-0009Aw-Ed for namedroppers@ops.ietf.org; Mon, 23 Aug 2004 19:20:15 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03462; Mon, 23 Aug 2004 15:20:09 -0400 (EDT) Message-Id: <200408231920.PAA03462@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-interop3597-00.txt Date: Mon, 23 Aug 2004 15:20:09 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 : RFC 3267 Interoperability Report Author(s) : J. Schlyter Filename : draft-ietf-dnsext-interop3597-00.txt Pages : 6 Date : 2004-8-23 This memo documents the result from the RFC 3267 (Handling of Unknown DNS Resource Record Types) interoperability testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-interop3597-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-interop3597-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-interop3597-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-23142606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-interop3597-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-interop3597-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-23142606.I-D@ietf.org> --OtherAccess-- --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 23 17:27:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16300 for ; Mon, 23 Aug 2004 17:27:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzMFh-000OVG-Eb for namedroppers-data@psg.com; Mon, 23 Aug 2004 21:21:17 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzMFW-000OU6-O1 for namedroppers@ops.ietf.org; Mon, 23 Aug 2004 21:21:06 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id C33D4144073; Mon, 23 Aug 2004 17:05:47 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id 4D3D5144047; Mon, 23 Aug 2004 17:05:47 -0400 (EDT) Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 94FBCCF39E; Mon, 23 Aug 2004 17:21:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <412A105A.8040401@algroup.co.uk> References: <412888E6.3020906@algroup.co.uk> <412A105A.8040401@algroup.co.uk> Date: Mon, 23 Aug 2004 17:21:03 -0400 To: Ben Laurie From: Edward Lewis Subject: Re: hopefully was RE: dictionary attack on nameservers Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:42 +0100 8/23/04, Ben Laurie wrote: >Sure, but if I have queried for a.b.c.d, then you have to reveal b.c.d - which >I could have checked with a single extra query, or in general with a small >number of extra queries (one per component), so this isn't really a massive >hole. This is an example of what needs to be explained in a requirements document. I know that at one time I wrote that in order to securely deny that there is an answer to a query, you must (as in "have to") reveal the closest enclosing name of the query's name. (Rationale - you must prove the name desired is absent as well as the *.closest encloser.) So, apparently leaking the closest encloser is not part of the zone enumeration problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 23 17:27:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16326 for ; Mon, 23 Aug 2004 17:27:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzMGg-000Oc5-Jb for namedroppers-data@psg.com; Mon, 23 Aug 2004 21:22:18 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzMGW-000ObK-1n for namedroppers@ops.ietf.org; Mon, 23 Aug 2004 21:22:08 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 25967144073; Mon, 23 Aug 2004 17:06:49 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id ADA6E144047; Mon, 23 Aug 2004 17:06:48 -0400 (EDT) Received: from [192.136.136.102] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id DCEACCF39E; Mon, 23 Aug 2004 17:22:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <412888E6.3020906@algroup.co.uk> <412A105A.8040401@algroup.co.uk> Date: Mon, 23 Aug 2004 17:22:04 -0400 To: Edward Lewis From: Edward Lewis Subject: Re: hopefully was RE: dictionary attack on nameservers Cc: Ben Laurie , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:21 -0400 8/23/04, Edward Lewis wrote: >So, apparently leaking the closest encloser is not part of the zone >enumeration problem. Yes, I know I owe the wild card clarify draft, which will define "closest encloser." ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 24 11:37:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15403 for ; Tue, 24 Aug 2004 11:37:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzdCN-0003eR-9R for namedroppers-data@psg.com; Tue, 24 Aug 2004 15:26:59 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzdCC-0003bj-Ln for namedroppers@ops.ietf.org; Tue, 24 Aug 2004 15:26:48 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 726D313E11 for ; Tue, 24 Aug 2004 15:26:48 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: do implementations discard the response when TC is set? [Re: handling of additional data (fwd)] In-Reply-To: Message from Pekka Savola of "Tue, 24 Aug 2004 16:14:19 +0300." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 24 Aug 2004 15:26:48 +0000 Message-Id: <20040824152648.726D313E11@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > When Paul said, "doesn't cache it", it could be read two ways: the > resolver will use it locally (as long as it's not cached), or it won't > be used at all (i.e., it's discarded). > > Which is it? in the case of BIND, TCP retry is done. BIND8 will cache nonempty sections other than the last one, on the assumption that those sections were not truncated. (so, TC indicates end-first truncation, not best-fit.) -- to unsubscribe send a message to namedroppers-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 24 20:05:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25509 for ; Tue, 24 Aug 2004 20:05:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzlBW-000KXD-HS for namedroppers-data@psg.com; Tue, 24 Aug 2004 23:58:38 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzlBL-000KUw-M0 for namedroppers@ops.ietf.org; Tue, 24 Aug 2004 23:58:27 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i7ONvdJ19126; Tue, 24 Aug 2004 16:57:39 -0700 (PDT) Message-Id: <200408242357.i7ONvdJ19126@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 3833 on Threat Analysis of the Domain Name System (DNS) Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 24 Aug 2004 16:57:39 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-17.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3833 Title: Threat Analysis of the Domain Name System (DNS) Author(s): D. Atkins, R. Austein Status: Informational Date: August 2004 Mailbox: derek@ihtfp.com, sra@isc.org Pages: 16 Characters: 39303 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-dns-threats-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3833.txt Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This document is a product of the DNS Extensions Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040824165633.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3833 --OtherAccess Content-Type: Message/External-body; name="rfc3833.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040824165633.RFC@RFC-EDITOR.ORG> --OtherAccess-- --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 Wed Aug 25 16:21:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16724 for ; Wed, 25 Aug 2004 16:21:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C04Ai-000GxA-2A for namedroppers-data@psg.com; Wed, 25 Aug 2004 20:15:04 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C04AH-000GqY-8K for namedroppers@ops.ietf.org; Wed, 25 Aug 2004 20:14:37 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16334; Wed, 25 Aug 2004 16:14:32 -0400 (EDT) Message-Id: <200408252014.QAA16334@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-interop3597-01.txt Date: Wed, 25 Aug 2004 16:14:31 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 : RFC 3267 Interoperability Report Author(s) : J. Schlyter Filename : draft-ietf-dnsext-interop3597-01.txt Pages : 6 Date : 2004-8-25 This memo documents the result from the RFC 3267 (Handling of Unknown DNS Resource Record Types) interoperability testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-interop3597-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-interop3597-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-interop3597-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-8-25145459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-interop3597-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-interop3597-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-25145459.I-D@ietf.org> --OtherAccess-- --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 26 01:59:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25282 for ; Thu, 26 Aug 2004 01:59:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0DD2-000JcN-MZ for namedroppers-data@psg.com; Thu, 26 Aug 2004 05:54:04 +0000 Received: from [203.69.237.46] (helo=delta.noi.kre.to) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0DCq-000JZ6-UE for namedroppers@ops.ietf.org; Thu, 26 Aug 2004 05:53:53 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7Q5kxx8007805; Thu, 26 Aug 2004 12:46:59 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: Pekka Savola , namedroppers@ops.ietf.org, dnsop@lists.uoregon.edu Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Aug 2004 12:46:59 +0700 Message-ID: <1836.1093499219@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 29 Jul 2004 21:15:36 -0400 From: Edward Lewis Message-ID: Sorry I'm coming to this very very late, but I looked quite a bit ahead in the list, and didn't see a reply like the one I'd like to make (though I don't claim an exhaustive search - I still am > 200 messages behind). | At 0:42 +0300 7/30/04, Pekka Savola wrote: | >Rather, it's "the minimum how long the DNS server asserts that this | >address corresponding to the name I asked will be valid". | | This is what I am afraid of. ;) Pekka used the wrong word. "valid" isn't what he really meant, "consistent" was. | A DNS server makes no assurance of the accuracy, etc., of the data it | serves. This is all 100% irrelevant to the point at hand (though perhaps justified by the use of the word "valid" in the earlier message). What matters here is that if I get an answer with a TTL of N, I can reasonably expect that the answer will be consistent for the next N seconds - technically I can even demand it, but almost no DNS operators bother to use the TTL correctly enough for that (neither do they mostly care that for a period the end users are getting old answers). An application that gets an answer that says TTL=N and queries again for the same query within the next N seconds is just imposing needless work on the network - whether anyone cares or not is a different question, most people don't - but it is also imposing needless costs and delays on the application, and an application that is aiming for snappy response is going to want to minimise that. Note that unless the application is bypassing DNS caching (and has a way to achieve that reliably, in the presence of devices that redirect packets aimed at certain ports to other than the address in the packet) asking again within the TTL period is pointless - even if the auth server has changed the data in the intervening period, the cache has no way to know that, and is simply going to return the same answers again. The TTL is just as vital a part of the DNS answer as the RDATA, and should have always been exposed to the end applications - the only thing that prevented that from happening was the way that the the API was shoe-horned into the old gethostbyname() and struct hostinfo which fetched its data from HOSTS.TXT (via /etc/hosts) and for which there was no TTL concept. If it hadn't been for that, the TTL would almost certainly have been exposed from the beginning. That it remains unexposed after we have invented new APIs is a travesty. | Although DNS is quite capable of carrying changing information | (thanks to dynamic update), I don't think any application would be | wise to rely on polling DNS to discover changed data. I disagree with that as well. The DNS is how the clients find the address to connect to. If the server is supposed to be providing a service for name N, and the DNS says that name N translates into address X, then the server must answer to address X. If the DNS changes the address mapping from X to Y, then at that point, and only at that point, the server needs to be listening on Y (doesn't hurt to have started earlier, but achieves nothing very useful). | This entire thread is from my reacting to the desire to expose the | TTL from the resolver to application. My message is mostly one of | concern - that applications need to understand what the TTL means. Absolutely, I agree with that. But it isn't that hard. The problem with treating the DNS data as "timeless" as an earlier message from you claimed, is that most people treat timeless as meaning "eternal" or "forever" - where I suspect that you probably really meant "no time values supplied". Providing an explicit time to live should at least get applications to stop treating the data as if it came from /etc/hosts, and could really never change (or not without a local human to cause it, who can also touch the applications at the same time). | From my experience (going back in time), I'd try to avoid the TTL as | a meaningful interface element - perhaps just from the principle of | network layering. If you view the application as a layer above DNS, | then using DNS internal data (the TTL) is a "layering violation." This is simply nonsense - both as a concept ("layering" applies to models, which are anaylsis tools, and should be left to that realm) and in particular in this case, the TTL is part of the answer - separated from the RDATA to make it easier for fairly dumb caches. | Remember - TTL's don't account for the rapidity of dynamic updates - | and I think that's more important in the example you've described. No, they don't - but nor do caches, unless the TTLs are set so as to cause that to happen - and it is the caches that give the vast majority of the answers, not the auth servers (auth servers spend most of their effort giving negative answers, not positive ones). kre -- to unsubscribe send a message to namedroppers-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 26 03:54:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13977 for ; Thu, 26 Aug 2004 03:54:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0Eza-000AKB-VQ for namedroppers-data@psg.com; Thu, 26 Aug 2004 07:48:18 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0EzP-000AJS-Oz for namedroppers@ops.ietf.org; Thu, 26 Aug 2004 07:48:08 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 069E05DCAF; Thu, 26 Aug 2004 09:47:29 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 66B0E5DCA6 for ; Thu, 26 Aug 2004 09:47:28 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i7Q7lPDI032410 for ; Thu, 26 Aug 2004 09:47:25 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i7Q7lPeR022144 for namedroppers@ops.ietf.org; Thu, 26 Aug 2004 09:47:25 +0200 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bzb8h-000Doa-5I for namedroppers@ops.ietf.org; Tue, 24 Aug 2004 13:15:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7ODEJt26918; Tue, 24 Aug 2004 16:14:23 +0300 Date: Tue, 24 Aug 2004 16:14:19 +0300 (EEST) From: Pekka Savola To: Paul Vixie Cc: Andreas Gustafsson , Robert Elz , Masataka Ohta , Subject: do implementations discard the response when TC is set? [Re: handling of additional data (fwd)] In-Reply-To: <20040507014924.3B34413CDF@sa.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.004633 / 0.0 / 0.0 / disabled X-RIPE-Signature: 230ff329d8af3a64bcebe6a367ea7f47 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either because it was posted by a non-subscriber or because it contained to many characters (> 20000). With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please fix your subscription addresses or shorten your postings by adding links instead of attachments ] Hi, I'm getting back to this very old message to verify one thing... inline.. On Fri, 7 May 2004, Paul Vixie wrote: > > While do I agree with your recommendation (for the specific case of > > glue), I'm unable to find the RFC1035 text you refer to. There's also > > the following text in RFC2181 section 9 which seems to contradict it: > > oops. you're right. > > > Where TC is set, the partial RRSet that would not completely > > fit may be left in the response. > > which is why, if TC was set, BIND assumes that the last nonempty section > has a partial rrset inside it therefore doesn't cache it. sorry to confuse. When Paul said, "doesn't cache it", it could be read two ways: the resolver will use it locally (as long as it's not cached), or it won't be used at all (i.e., it's discarded). Which is it? Note that by RFC2181 section 9 any results which have been received with TC bit set must be completely ignored: Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. In other words, I'm interested whether that is operationally the case in the implementations. (I could think of cases where the implementation might ignore this rule and use the result given in the UDP response, if there's useful information there, if e.g., the TCP retry fails..) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 26 04:28:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15102 for ; Thu, 26 Aug 2004 04:28:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0FXp-000FTI-2h for namedroppers-data@psg.com; Thu, 26 Aug 2004 08:23:41 +0000 Received: from [203.69.237.46] (helo=delta.noi.kre.to) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0FXe-000FRT-8V for namedroppers@ops.ietf.org; Thu, 26 Aug 2004 08:23:30 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i7Q8K7x8009265; Thu, 26 Aug 2004 15:20:07 +0700 (ICT) From: Robert Elz To: kent@songbird.com cc: namedroppers@ops.ietf.org Subject: Re: What I mumbled at the mike today... In-Reply-To: <20040803201152.GL16208@raven.songbird.com> References: <20040803201152.GL16208@raven.songbird.com> <336DEA1A50C9BCD9263BFAFD@[192.168.100.27]> <20040803194335.0313413E00@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Aug 2004 15:20:07 +0700 Message-ID: <8885.1093508407@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 3 Aug 2004 13:11:52 -0700 From: kent@songbird.com Message-ID: <20040803201152.GL16208@raven.songbird.com> Another very delayed reply (apologies again...) | That is, at least from this sample, your assertion is incorrect -- the | evidence suggests that the majority of clueful registrants prefer NOT | to make their full zones visible. I'm probably one of the addresses of the "majority" - you can't AXFR the oz.au domain (or not from my servers anyway) - but the reason has nothing whatever to do with any desire to control zone visibility, it is because AXFR is TCP, and using TCP for a transaction service simply costs too much, it simply doesn't scale at all - so I don't allow it except from those few hosts where it is needed, I don't want everyone in the universe doing AXFRs. If they want to get the data via NSEC (once DNSSEC gets deployed here) I couldn't care in the least, in fact, I'd prefer than dictionary type attempts, which cannot be prevented in any reasonable way (regardless of how successful you define them to be). kre ps: apologies if this issue is long dead - one would hope it would be, but from a quick glance at the subjects at the end of the list of my pending namedroppers messages suggests that it is still dragging on... -- to unsubscribe send a message to namedroppers-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 28 01:57:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10246 for ; Sat, 28 Aug 2004 01:57:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C0w7V-0009sM-Jd for namedroppers-data@psg.com; Sat, 28 Aug 2004 05:51:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0w7K-0009oA-8u for namedroppers@ops.ietf.org; Sat, 28 Aug 2004 05:51:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7S5p8J02945 for ; Sat, 28 Aug 2004 08:51:08 +0300 Date: Sat, 28 Aug 2004 08:51:08 +0300 (EEST) From: Pekka Savola To: namedroppers@ops.ietf.org Subject: Re: do implementations discard the response when TC is set? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul, you leave a lot unstated, so I must query again ;-). [Pekka Savola:] >> When Paul said, "doesn't cache it", it could be read two ways: the >> resolver will use it locally (as long as it's not cached), or it >> won't be used at all (i.e., it's discarded). >> >> Which is it? > >[Paul] >in the case of BIND, TCP retry is done. BIND8 will cache nonempty >sections other than the last one, on the assumption that those >sections were not truncated. (so, TC indicates end-first truncation, >not best-fit.) Does your latter sentence imply that BIND4 and BIND9 will discard non-empty sections other than the last one (as specified as "should" in RFC2181 section 9)? Or if not, what is done? Are there plans to change the behaviour, or are there specific good reasons to do so? This has some implications as it may lead to inconsistent data which cannot be retrieved in any other (when used for particular type of glue) way getting into the caches. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 28 11:46:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22189 for ; Sat, 28 Aug 2004 11:46:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C15Jn-000Pww-Uc for namedroppers-data@psg.com; Sat, 28 Aug 2004 15:40:39 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C15Jc-000PuU-Oe for namedroppers@ops.ietf.org; Sat, 28 Aug 2004 15:40:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 803B213E12 for ; Sat, 28 Aug 2004 15:40:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: do implementations discard the response when TC is set? In-Reply-To: Message from Pekka Savola of "Sat, 28 Aug 2004 08:51:08 +0300." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 28 Aug 2004 15:40:28 +0000 Message-Id: <20040828154028.803B213E12@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul, you leave a lot unstated, so I must query again ;-). Fine by me. These are topics that "DNS Clarifications" might have covered. > >in the case of BIND, TCP retry is done. BIND8 will cache nonempty > >sections other than the last one, on the assumption that those > >sections were not truncated. (so, TC indicates end-first truncation, > >not best-fit.) > > Does your latter sentence imply that BIND4 and BIND9 will discard > non-empty sections other than the last one (as specified as "should" > in RFC2181 section 9)? Or if not, what is done? BIND4's behaviour changed a lot. 4.9 and later certainly do the same thing as I described for BIND8 above. 4.8 and earlier was berzerk -- it cached and reused everything, without regard for RRset boundaries. For example, if there was deviance in the TTL across RRs within an RRset, then each RR would expire separately, and BIND4.8 would continue sending the shortened cached RRset in new answer/authority/additional sections until finally the last RR expired at which point the RRset would be re-fetched. And the TC bit didn't affect caching at all -- everything in a response went into a cache, without regard for what possible RRset-truncation may have occurred. And when experienced truncation while building an answer, it would set TC but possibly leave a truncated RRset in the truncated section. What a complete disaster. I have no knowledge of BIND9's behaviour. I suspect that it's the same as what I describe for BIND8. But I mostly stopped writing code a few years ago, and the reason I didn't describe BIND9's behaviour above is not that it's known by me to be different, but because I don't know it. > Are there plans to change the behaviour, or are there specific good > reasons to do so? ISC's position is that we'll track the RFC's. The current behaviour is our interpretation of what the current RFC's tell, or imply, us to do. If a new RFC comes along, or if someone argues convincingly that our interpretation is wrong, then BIND will be changed. (Note that DJB's arguments that we misinterpreted the AXFR spec weren't very convincing, so anyone who was thinking of using that as a counterexample, shouldn't.) > This has some implications as it may lead to inconsistent data which > cannot be retrieved in any other (when used for particular type of > glue) way getting into the caches. Please explain. This is a strong area of interest for me, since BIND4's berzerkness about caching is what caused me to have to start working on it in the first place. (I didn't always know what was wrong, but I knew what I didn't like.) -- to unsubscribe send a message to namedroppers-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 28 22:25:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25560 for ; Sat, 28 Aug 2004 22:25:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1FJO-000Jm3-S3 for namedroppers-data@psg.com; Sun, 29 Aug 2004 02:20:54 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C1FJE-000Jkw-4z for namedroppers@ops.ietf.org; Sun, 29 Aug 2004 02:20:44 +0000 Received: (qmail 60638 invoked by uid 1016); 29 Aug 2004 02:20:58 -0000 Date: 29 Aug 2004 02:20:58 -0000 Message-ID: <20040829022058.60637.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: do implementations discard the response when TC is set? References: <20040828154028.803B213E12@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The deployed AXFR protocol allows servers to repeat records. Clients are responsible for removing duplicates. BIND 8 repeats records. BIND 9 doesn't. (My software doesn't.) Both behaviors are permitted by the protocol. Vixie claims that I said BIND 9 ``misinterpreted the AXFR spec.'' Vixie says he didn't find my ``argument'' very ``convincing.'' But I never said anything of the sort. BIND 9's behavior is permitted by the existing protocol. Interoperability doesn't demand either behavior. It's up to the implementor to consider database format, speed, etc. The problem was with the BIND company's AXFR ``clarifications'' (e.g., axfr-clarify-02), which said that each record ``MUST be transmitted exactly once.'' That's not a ``clarification''; it's not a codification of ``existing practice''; it's not a description of ``the fielded DNS server software.'' It's BIND 9's private implementation decision being misrepresented as an Internet protocol. It violates Section 6 of RFC 2119. It is not necessary for interoperability. This is just one example of the problems in the AXFR ``clarifications''; see http://cr.yp.to/djbdns/axfr-clarify.html. People interested in how AXFR actually works should read http://cr.yp.to/djbdns/axfr-notes.html. Vixie says that BIND 9 will ``track the RFC's.'' Well, gee: when the BIND company sits around publishing RFCs that say ``All DNS software must make these implementation choices, because we've made these choices for BIND 9,'' is it a surprise that BIND 9 is tracking the RFCs? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-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 28 22:36:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25918 for ; Sat, 28 Aug 2004 22:36:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1FWY-000MAp-Bx for namedroppers-data@psg.com; Sun, 29 Aug 2004 02:34:30 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C1FWN-000M6m-Eb for namedroppers@ops.ietf.org; Sun, 29 Aug 2004 02:34:19 +0000 Received: (qmail 70780 invoked by uid 1016); 29 Aug 2004 02:34:33 -0000 Date: 29 Aug 2004 02:34:33 -0000 Message-ID: <20040829023433.70779.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: do implementations discard the response when TC is set? [Re: handling of additional data (fwd)] References: <20040507014924.3B34413CDF@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Pekka Savola writes: > In other words, I'm interested whether that is operationally the case > in the implementations. To truncate a packet, I set TC and discard all records in the packet. (Originally I set TC and truncated the packet at 512 bytes. This is the most obvious interpretation of ``longer messages [than 512 bytes] are truncated'' in RFC 1035. Unfortunately, the Squid cache---at least at the time---died if it received a packet truncated between records.) On the client side, if I see a TC, I discard the packet and try again through TCP. This happens almost immediately after packet receipt. The records in the packet aren't even read, let alone used in any way. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-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 28 23:13:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27073 for ; Sat, 28 Aug 2004 23:13:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1G5w-0002Bh-Nv for namedroppers-data@psg.com; Sun, 29 Aug 2004 03:11:04 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C1G5V-000280-Pp for namedroppers@ops.ietf.org; Sun, 29 Aug 2004 03:10:37 +0000 Received: (qmail 98840 invoked by uid 1016); 29 Aug 2004 03:10:52 -0000 Date: 29 Aug 2004 03:10:52 -0000 Message-ID: <20040829031052.98839.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Greg Hudson writes: > I continue to believe that the most practical way to deal with the > enumeration problem is to allow domains to punt on authenticated > denial. But that idea doesn't seem very popular. A client looks up _goofy._tcp.your.dom. You say, without authentication, that you don't have any such domain. What should the client do? * Take your word for it and use your A record instead? Bzzzt. That would allow attakers to forge denials for _goofy._tcp domains that really do exist, thus sending _goofy._tcp to the wrong IP address. * Discard your packet and wait for an authenticated denial? Well, yes, this is required for security, but it's never going to work, because you don't support authenticated denial. Client gives up. You could say that we should stop deploying things like _goofy._tcp, but some people will insist that certain names of this type are already being used and have to be supported. This doesn't mean that you need to respond to any.random.name.your.dom. A good security protocol would allow signing the nonexistence of some selected names without revealing anything about other names. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-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 28 23:35:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27730 for ; Sat, 28 Aug 2004 23:35:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1GQb-0005aA-SR for namedroppers-data@psg.com; Sun, 29 Aug 2004 03:32:25 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C1GQR-0005XW-1n for namedroppers@ops.ietf.org; Sun, 29 Aug 2004 03:32:15 +0000 Received: (qmail 14838 invoked by uid 1016); 29 Aug 2004 03:32:29 -0000 Date: 29 Aug 2004 03:32:29 -0000 Message-ID: <20040829033229.14837.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: dictionary attack on nameservers References: <20040818204040.58B8417921@portal.hamachi.org> <16675.51989.29809.273081@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > Quickly scan a class B for resolvers, take the bulk (say 2000), and > ask them for stuff under gotcha.example.com. Why does the IETF condone promiscuous DNS caching? I'm reminded of the situation in 1996, when qmail (version 0.91) became one of the first MTAs to prohibit relaying by default. People at the time didn't realize that relaying was going to be massively abused. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-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 28 23:57:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28667 for ; Sat, 28 Aug 2004 23:57:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1Gn6-0009Qp-DV for namedroppers-data@psg.com; Sun, 29 Aug 2004 03:55:40 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C1Gmv-0009Ov-LG for namedroppers@ops.ietf.org; Sun, 29 Aug 2004 03:55:29 +0000 Received: (qmail 31349 invoked by uid 1016); 29 Aug 2004 03:55:43 -0000 Date: 29 Aug 2004 03:55:43 -0000 Message-ID: <20040829035543.31348.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: a challenge for privacy violators References: <4A09E2E9CEDAD298DD45B654@[192.168.100.27]> <20040817230231.F327613DFF@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > what's trivially observable is that the names are not remaining secret, Here's an interesting picture of a tree: 53145ddd853407645babda07a9dd2b63.pictures.cr.yp.to Right now there are 1488 other pictures available from the same server. You claim that the names aren't secret. Show us the pictures! ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-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 29 04:47:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25080 for ; Sun, 29 Aug 2004 04:47:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1LGh-0003vu-Hr for namedroppers-data@psg.com; Sun, 29 Aug 2004 08:42:31 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1LGG-0003pJ-FK for namedroppers@ops.ietf.org; Sun, 29 Aug 2004 08:42:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i7T8frc00488; Sun, 29 Aug 2004 11:41:56 +0300 Date: Sun, 29 Aug 2004 11:41:53 +0300 (EEST) From: Pekka Savola To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: do implementations discard the response when TC is set? In-Reply-To: <20040828154028.803B213E12@sa.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 28 Aug 2004, Paul Vixie wrote: > I have no knowledge of BIND9's behaviour. I suspect that it's the same > as what I describe for BIND8. But I mostly stopped writing code a few > years ago, and the reason I didn't describe BIND9's behaviour above is > not that it's known by me to be different, but because I don't know it. OK, thanks for acking that. Let's hear if those responsible will comment. > > Are there plans to change the behaviour, or are there specific good > > reasons to do so? > > ISC's position is that we'll track the RFC's. The current behaviour is > our interpretation of what the current RFC's tell, or imply, us to do. > If a new RFC comes along, or if someone argues convincingly that our > interpretation is wrong, then BIND will be changed. It's already in the RFC. RFC 2181 section 9 second paragraph says (second sentence): Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. i.e., ignoring the response is a "should". > > This has some implications as it may lead to inconsistent data which > > cannot be retrieved in any other (when used for particular type of > > glue) way getting into the caches. > > Please explain. This is a strong area of interest for me, since BIND4's > berzerkness about caching is what caused me to have to start working on it > in the first place. (I didn't always know what was wrong, but I knew what > I didn't like.) I have tried to explain this in draft-ietf-dnsop-ipv6-issues-09.txt, section 4.4, but it still requires revision to spell it out properly. The problem is that there is glue which may not be otherwise retrievable. If only part of that is told and cached (due to truncation, and not discarded and fetched in entirety w/ TCP), it might be that the caches include incomplete or inconsistent information about glue. And if you consider that the incomplete glue could be missing v4 records and v6 is unreachable, or missing v6 records and v4 is unreachable, it would be possible to get to the situation where you will not be able to reach the authoritative resolvers because some of the cached incomplete records do not work (for some resolvers at least), but if you had the complete information, it would work. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-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 29 09:41:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07468 for ; Sun, 29 Aug 2004 09:41:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1Pqq-000LF1-3D for namedroppers-data@psg.com; Sun, 29 Aug 2004 13:36:08 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1Pqf-000LDd-C2 for namedroppers@ops.ietf.org; Sun, 29 Aug 2004 13:35:57 +0000 Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i7TDZulX000375; Sun, 29 Aug 2004 09:35:56 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i7TDZsuv011026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Aug 2004 09:35:55 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i7TDZr4g024899; Sun, 29 Aug 2004 09:35:53 -0400 Subject: Re: dictionary attack on nameservers From: Greg Hudson To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org In-Reply-To: <20040829031052.98839.qmail@cr.yp.to> References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> <20040829031052.98839.qmail@cr.yp.to> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1093786553.2799.9.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 29 Aug 2004 09:35:53 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_RELAY autolearn=no version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2004-08-28 at 23:10, D. J. Bernstein wrote: > Greg Hudson writes: > > I continue to believe that the most practical way to deal with the > > enumeration problem is to allow domains to punt on authenticated > > denial. But that idea doesn't seem very popular. > A client looks up _goofy._tcp.your.dom. You say, without authentication, > that you don't have any such domain. What should the client do? > * Take your word for it and use your A record instead? Bzzzt. That > would allow attakers to forge denials for _goofy._tcp domains that > really do exist, thus sending _goofy._tcp to the wrong IP address. Well, yes, this would be a risk. But the attacker couldn't redirect traffic to an IP address of his choice, so for practical purposes, the attack would probably be limited to a denial of service. And the whole idea of punting on authenticated denial is that you accept the denial of service risk in return for preventing the enumeration risk. > * Discard your packet and wait for an authenticated denial? There would be a signed indication that your.dom punts on authenticated denial, so there would be no ambiguity to the client. (One idea which would work with today's DNSSEC implementations is to create a signed nsec record spanning the entire domain. But people were--perhaps rightly--concerned that such a record might be cached and used in response to other queries, leading to accidental denial of service. So to do this right, we would probably need a DNSSEC extension. As I said, though, the idea doesn't seem to be very popular here, so there isn't necessarily much sense in pursuing 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 Mon Aug 30 13:32:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11111 for ; Mon, 30 Aug 2004 13:32:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1pt4-000ETN-FR for namedroppers-data@psg.com; Mon, 30 Aug 2004 17:24:10 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1pst-000ESV-Qs for namedroppers@ops.ietf.org; Mon, 30 Aug 2004 17:23:59 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id i7UHNxIw019592 for ; Mon, 30 Aug 2004 10:23:59 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 30 Aug 2004 10:23:59 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: RE: dictionary attack on nameservers Date: Mon, 30 Aug 2004 10:23:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Roy Arends writes: > > Quickly scan a class B for resolvers, take the bulk (say 2000), and > > ask them for stuff under gotcha.example.com. > > Why does the IETF condone promiscuous DNS caching? > > I'm reminded of the situation in 1996, when qmail (version > 0.91) became > one of the first MTAs to prohibit relaying by default. People at the > time didn't realize that relaying was going to be massively abused. People seem to get very wound up about security, demanding all or nothing, then being surprised when they end up with nothing. How much of the protection against DNS spoofing would be provided by a simple transport layer challenge-response mechanism? The client sends an authenticatable nonce en-clair along with the request. The server returns both the nonce and an HMAC signature of the response. If you can work out a way to know with certainty whether a DNS server supports the protocol you have a very robust authentication scheme that can only be defeated by a man in the middle attack. Phill -- to unsubscribe send a message to namedroppers-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 30 14:12:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14063 for ; Mon, 30 Aug 2004 14:12:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1qYh-000Jaq-HO for namedroppers-data@psg.com; Mon, 30 Aug 2004 18:07:11 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1qYW-000JZY-Iw for namedroppers@ops.ietf.org; Mon, 30 Aug 2004 18:07:00 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id F36C0144DF4; Mon, 30 Aug 2004 13:49:50 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id 5C769144D82; Mon, 30 Aug 2004 13:49:50 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id 606CFCF3A8; Mon, 30 Aug 2004 14:06:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 30 Aug 2004 14:06:56 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: the dictionary attack thread Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have spoken against this thread a few times already. Not against either "side" of the debate, but against the thought that this is a useful thread. It's educational, but my point is, "so what." My position is that "if someone wants to drive a solution to the question 'how do we provide authenticated denial without exposing other information' so be it. More power to them." In fact, I admit I'd like to see a solution. (But first requirements![0].) Dan Bernstein said: >A good security protocol would allow signing the nonexistence of some >selected names without revealing anything about other names. He hit the nail on the head there. That's a good requirement to put into the document on this. I'm not saying NSEC is a bad protocol, but it's at best an acceptable one to many of the participants of the WG. It even has passed the test of "consensus." Those who postulate that they will never run DNSSEC with NSEC's zone enumeration have every right to avoid deploying what's in the DNSSECbis documents. There are legitimate reasons to have objections to zone enumeration, stemming from local operating conditions. In "arguing" over the reasons, let's keep in mind that this is a list on the DNS protocol, not registry operations. Let's not get into the details of how to defend zone enumeration within DNS, let's just stick to deciding that if someone has a new solution to the problem - whether the problem is "good" or at least better than what we have now. I don't think that anyone against (say) NSEC has ever thrown up a road block to the DNSSECbis documents. Comments against, sure, commentary is always permitted, even if it may not be seen as welcomed. Commentary is an essential element in producing refereed engineering documents. My pointing this out is because I am somewhat surprised that there is a strong resistance by some to "permit" the search for a solution that does not have zone enumeration. If you are of the camp that thinks NSEC is the best solution out there (maybe rightfully so, I am not challenging that), to quote some wise sage of the IETF, "let a thousand flowers bloom." [0] - Yes, wild card clarify ... yea, yea... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-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 30 19:04:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12158 for ; Mon, 30 Aug 2004 19:04:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1v7U-00025m-VP for namedroppers-data@psg.com; Mon, 30 Aug 2004 22:59:24 +0000 Received: from [192.114.22.3] (helo=odyssey.isoc.org.il) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1v7J-00024T-BI for namedroppers@ops.ietf.org; Mon, 30 Aug 2004 22:59:13 +0000 Received: from [127.0.0.1] (barvaz.cc.biu.ac.il [132.70.10.1]) by odyssey.isoc.org.il (8.12.11/8.12.6) with ESMTP id i7UMxAVc005552 for ; Tue, 31 Aug 2004 01:59:11 +0300 Message-ID: <4133B14C.7050600@isoc.org.il> Date: Tue, 31 Aug 2004 01:59:24 +0300 From: Doron Shikmoni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers Subject: Re: dictionary attack on nameservers References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> <20040829031052.98839.qmail@cr.yp.to> <1093786553.2799.9.camel@egyptian-gods.mit.edu> In-Reply-To: <1093786553.2799.9.camel@egyptian-gods.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [I've been lurking on this list for a long while, though hardly ever posted; by way of introduction, relevant part is I'm a security guy / networking guy / TLD operator (25+ / 25+ / 8+ yrs, resp), and also a member of ICANN SSAC, so my interest in DNSSEC is kind of multi-faceted]. Greg Hudson wrote: >On Sat, 2004-08-28 at 23:10, D. J. Bernstein wrote: > >>Greg Hudson writes: >> >>>I continue to believe that the most practical way to deal with the >>>enumeration problem is to allow domains to punt on authenticated >>>denial. But that idea doesn't seem very popular. >>> It indeed doesn't seem very popular. For my own $.0002, I believe it would be a good solution to the problem (a problem which I perceive to be very real). >>A client looks up _goofy._tcp.your.dom. You say, without authentication, >>that you don't have any such domain. What should the client do? >> > >> * Take your word for it and use your A record instead? Bzzzt. That >> would allow attakers to forge denials for _goofy._tcp domains that >> really do exist, thus sending _goofy._tcp to the wrong IP address. >> > >Well, yes, this would be a risk. But the attacker couldn't redirect >traffic to an IP address of his choice, so for practical purposes, the >attack would probably be limited to a denial of service. And the whole >idea of punting on authenticated denial is that you accept the denial of >service risk in return for preventing the enumeration risk. > > >> * Discard your packet and wait for an authenticated denial? >> > >There would be a signed indication that your.dom punts on authenticated >denial, so there would be no ambiguity to the client. > This concern may be addressed if a DNSSEC extenstion is introduced, with a way to assert that _this_zone_allows_unsigned_denials_. It would be a signed assertion, which will be sent along with rcode 3 responses. In a sense, it would address a part of the first concern as well, or at least "match the expectations" of the zone owner, in terms of threat (because unsigned NXDOMAINs will be accepted by security-aware resolvers only if the zone owner permitted them). Obviously it introduces a security tradeoff (not completely unlike that of opt-in), and places the choice with the zone owner. In fact, I sketched something to that effect a few months ago. Is there interest in discussing such an approach? >(One idea which would work with today's DNSSEC implementations is to >create a signed nsec record spanning the entire domain. But people >were--perhaps rightly--concerned that such a record might be cached and >used in response to other queries, leading to accidental denial of >service. So to do this right, we would probably need a DNSSEC >extension. As I said, though, the idea doesn't seem to be very popular >here, so there isn't necessarily much sense in pursuing it.) > Is there? Cheers, Doron -- to unsubscribe send a message to namedroppers-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 30 19:46:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14936 for ; Mon, 30 Aug 2004 19:46:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1vn7-0006rQ-Ob for namedroppers-data@psg.com; Mon, 30 Aug 2004 23:42:25 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1vmv-0006qq-Oi for namedroppers@ops.ietf.org; Mon, 30 Aug 2004 23:42:15 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7UNkcv4019823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Aug 2004 23:46:44 GMT (envelope-from roy+dated+1096501326.87327c@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.13.0/8.13.0) with ESMTP id i7UNg61i017374 for ; Tue, 31 Aug 2004 00:42:06 +0100 (BST) (envelope-from roy+dated+1096501326.87327c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.13.0/8.13.0/Submit) id i7UNg6BM017373 for namedroppers@ops.ietf.org; Tue, 31 Aug 2004 00:42:06 +0100 (BST) (envelope-from roy+dated+1096501326.87327c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 31 Aug 2004 00:42:05 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16691.47949.214645.559794@giles.gnomon.org.uk> Date: Tue, 31 Aug 2004 00:42:05 +0100 To: Doron Shikmoni Cc: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: <4133B14C.7050600@isoc.org.il> References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> <20040829031052.98839.qmail@cr.yp.to> <1093786553.2799.9.camel@egyptian-gods.mit.edu> <4133B14C.7050600@isoc.org.il> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Virus-Scanned: clamd / ClamAV version 0.73, clamav-milter version 0.73a on spike.gnomon.org.uk X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Doron" == Doron Shikmoni writes: >> Well, yes, this would be a risk. But the attacker couldn't >> redirect traffic to an IP address of his choice, so for >> practical purposes, the attack would probably be limited to a >> denial of service. And the whole idea of punting on >> authenticated denial is that you accept the denial of service >> risk in return for preventing the enumeration risk. Different 'you' though, given that most of this discussion revolves around TLDs, which hence contain lots of zone cuts. If (hypothetically) Nominet decides not to implement authenicated denial in .org.uk, then I have to worry about the fact that even a security aware resolver might be tricked into believing that names under my domain, gnomon.org.uk, don't exist. So, from my point there'd still be benefit in using some other mechanism (such as DLV) to declare to the world that my domain exists and is secure. -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 Mon Aug 30 19:50:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15190 for ; Mon, 30 Aug 2004 19:50:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C1vrV-0007Sf-5N for namedroppers-data@psg.com; Mon, 30 Aug 2004 23:46:57 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1vrK-0007R3-3n for namedroppers@ops.ietf.org; Mon, 30 Aug 2004 23:46:46 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7UNka1i029777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 16:46:37 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i7UNkYWk007750; Mon, 30 Aug 2004 16:46:35 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <4133B14C.7050600@isoc.org.il> References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> <20040829031052.98839.qmail@cr.yp.to> <1093786553.2799.9.camel@egyptian-gods.mit.edu> <4133B14C.7050600@isoc.org.il> Date: Mon, 30 Aug 2004 16:46:33 -0700 To: Doron Shikmoni , namedroppers From: Ted Hardie Subject: Re: dictionary attack on nameservers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:59 AM +0300 8/31/04, Doron Shikmoni wrote: >[I've been lurking on this list for a long while, though hardly ever >posted; by way of introduction, relevant part is I'm a security guy / >networking guy / TLD operator (25+ / 25+ / 8+ yrs, resp), and also >a member of ICANN SSAC, so my interest in DNSSEC is kind of multi-faceted]. > >Greg Hudson wrote: > >>On Sat, 2004-08-28 at 23:10, D. J. Bernstein wrote: >> >>>Greg Hudson writes: >>> >>>>I continue to believe that the most practical way to deal with the >>>>enumeration problem is to allow domains to punt on authenticated >>>>denial. But that idea doesn't seem very popular. >>>> > >It indeed doesn't seem very popular. For my own $.0002, I believe it would >be a good solution to the problem (a problem which I perceive to be >very real). It is indeed very unpopular with applications folks. >>>A client looks up _goofy._tcp.your.dom. You say, without authentication, >>>that you don't have any such domain. What should the client do? >>> >> >>> * Take your word for it and use your A record instead? Bzzzt. That >>> would allow attakers to forge denials for _goofy._tcp domains that >>> really do exist, thus sending _goofy._tcp to the wrong IP address. >>> >> >>Well, yes, this would be a risk. But the attacker couldn't redirect >>traffic to an IP address of his choice, so for practical purposes, the >>attack would probably be limited to a denial of service. And the whole >>idea of punting on authenticated denial is that you accept the denial of >>service risk in return for preventing the enumeration risk. >> >>> * Discard your packet and wait for an authenticated denial? >>> >> >>There would be a signed indication that your.dom punts on authenticated >>denial, so there would be no ambiguity to the client. >> > >This concern may be addressed if a DNSSEC extenstion is introduced, with >a way to assert that _this_zone_allows_unsigned_denials_. It would be >a signed assertion, which will be sent along with rcode 3 responses. Let's imagine I say "The zone example.com allows unsigned denials". An application gets back an unsigned denial for www.example.com. Possibly example.com doesn't have web traffic or use this convention for its web traffic; possibly an attacker was able to insert a denial for www.example.com. The application doesn't know which. Had example.com not chosen to allow unsigned denials for example.com, the application _would_ know which. Several folks have argued that it is up to the zone maintainer to make this choice, and that the applications will simply have to live with this ambiguity. We will already have to live with this ambiguity, after all, for zones who choose not to deploy DNSSEC at all. While I understand the impetus, I believe it's the wrong engineering trade-off to make. Having the application have a clear sense of what level of data integrity to expect from the DNS is a major benefit to the applications. The muddier the water, the higher the likelihood that the application will get the security story wrong. Given that user behavior depends on this (do I send my credit card details in the face of a warning that something that should be assured by a digital signature was not? how about if it is not and I'm not sure it should be? how about if it is not and I'm sure it should not be?), it is in our best interests to get this to be as clear as possible. Having half measures where bits of the data are integrity-protected and bits are not just seems like it invites problems far worse that enumeration. To put it another way: authenticated denial is a key part of data integrity for a lookup system. Leaving it out means the system does not provide data integrity. To be honest, I think the security story pre-DNSSEC is clear and that it will be a long while before it is clear again. Of course, the story is: you are at constant risk. Getting past that to some level of data integrity requires going through a phase where some zones' data are protected against tampering and some are not; that's going to muddy the security waters a bit, like it or not (since we have no Internet Police out there forcing people to use DNSSEC as it is deployed). I'd love it if we could get to a security story that is just as clear: data coming from the DNS is integrity protected. It's going to be a long road to get there, but if we don't start walking sometime, we'll never get there at all. To quote Jim Reid: "Meanwhile, large chunks of the name space continue to be unsecured." Can we start walking? regards, Ted Hardie >In a sense, it would address a part of the first concern as well, or >at least "match the expectations" of the zone owner, in terms of threat >(because unsigned NXDOMAINs will be accepted by security-aware resolvers >only if the zone owner permitted them). >Obviously it introduces a security tradeoff (not completely unlike that >of opt-in), and places the choice with the zone owner. > >In fact, I sketched something to that effect a few months ago. Is there >interest in discussing such an approach? > >>(One idea which would work with today's DNSSEC implementations is to >>create a signed nsec record spanning the entire domain. But people >>were--perhaps rightly--concerned that such a record might be cached and >>used in response to other queries, leading to accidental denial of >>service. So to do this right, we would probably need a DNSSEC >>extension. As I said, though, the idea doesn't seem to be very popular >>here, so there isn't necessarily much sense in pursuing it.) >> >Is there? > >Cheers, >Doron > > >-- >to 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 Tue Aug 31 04:25:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28525 for ; Tue, 31 Aug 2004 04:25:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C23s5-00026t-Ls for namedroppers-data@psg.com; Tue, 31 Aug 2004 08:20:05 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C23rm-00020U-My for namedroppers@ops.ietf.org; Tue, 31 Aug 2004 08:19:46 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id ED4A4AC8C; Tue, 31 Aug 2004 10:19:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id EBECBAC8B; Tue, 31 Aug 2004 10:19:44 +0200 (CEST) Date: Tue, 31 Aug 2004 10:19:44 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: Doron Shikmoni Cc: namedroppers Subject: Re: dictionary attack on nameservers In-Reply-To: <4133B14C.7050600@isoc.org.il> Message-ID: References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> <20040829031052.98839.qmail@cr.yp.to> <1093786553.2799.9.camel@egyptian-gods.mit.edu> <4133B14C.7050600@isoc.org.il> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 31 Aug 2004, Doron Shikmoni wrote: > [I've been lurking on this list for a long while, though hardly ever > posted; by way of introduction, relevant part is I'm a security guy / > networking guy / TLD operator (25+ / 25+ / 8+ yrs, resp), and also > a member of ICANN SSAC, so my interest in DNSSEC is kind of multi-faceted]. > > Greg Hudson wrote: > > >On Sat, 2004-08-28 at 23:10, D. J. Bernstein wrote: > > > >>Greg Hudson writes: > >> > >>>I continue to believe that the most practical way to deal with the > >>>enumeration problem is to allow domains to punt on authenticated > >>>denial. But that idea doesn't seem very popular. > >>> > > It indeed doesn't seem very popular. For my own $.0002, I believe it would > be a good solution to the problem (a problem which I perceive to be very > real). Please keep in mind that authenticated denial is also used for proof of absence of wildcards, or absence of matching names when wildcards exists. Punting on authenticated denial is not that straightforward. 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 Tue Aug 31 08:10:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11287 for ; Tue, 31 Aug 2004 08:10:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C27PA-0009I0-FY for namedroppers-data@psg.com; Tue, 31 Aug 2004 12:06:28 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C27Oz-0009G0-G4 for namedroppers@ops.ietf.org; Tue, 31 Aug 2004 12:06:17 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 910CF143B0C; Tue, 31 Aug 2004 07:48:55 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp1.arin.net (Postfix) with ESMTP id 01B11143B03; Tue, 31 Aug 2004 07:48:55 -0400 (EDT) Received: from [192.168.1.100] (mercury.arin.net [127.0.0.1]) by mercury.arin.net (Postfix) with ESMTP id E4253CF3A8; Tue, 31 Aug 2004 08:06:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <4133B14C.7050600@isoc.org.il> References: <20040818204040.58B8417921@portal.hamachi.org> <5A8B18346F2921C827B88C0C@[192.168.100.27]> <1092906351.21170.175.camel@egyptian-gods.mit.edu> <20040829031052.98839.qmail@cr.yp.to> <1093786553.2799.9.camel@egyptian-gods.mit.edu> <4133B14C.7050600@isoc.org.il> Date: Tue, 31 Aug 2004 08:06:03 -0400 To: Doron Shikmoni From: Edward Lewis Subject: Re: dictionary attack on nameservers Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:59 +0300 8/31/04, Doron Shikmoni wrote: >[I've been lurking on this list for a long while, though hardly ever >posted; by way of introduction, relevant part is I'm a security guy / >networking guy / TLD operator (25+ / 25+ / 8+ yrs, resp), and also >a member of ICANN SSAC, so my interest in DNSSEC is kind of multi-faceted]. > >Greg Hudson wrote: > >>On Sat, 2004-08-28 at 23:10, D. J. Bernstein wrote: >> >>>Greg Hudson writes: >>> >>>>I continue to believe that the most practical way to deal with the >>>>enumeration problem is to allow domains to punt on authenticated >>>>denial. But that idea doesn't seem very popular. >>>> > >It indeed doesn't seem very popular. For my own $.0002, I believe it would >be a good solution to the problem (a problem which I perceive to be >very real). Along with Ted Hardie's answer, another point is that I think once DNSSEC added the DS RR, authenticated denial became essential. It used to be that a secured parent zone would indicate that a child was insecure by adding a signed NULL KEY RR to the referral. If there was no NULL KEY RR, then the validator would assume the child was secured. In the face of a stripping attack (or a cache's failure to include the KEY RR), the validator would fallback to expecting the child to be secure. As DNSSEC was never out to defend against denial of service, this was the "safe choice." Now, the DS RR is used to tell the validator the child is secure. Without it, the child is insecure. With the same stripping attack (or omission), validators would fallback to insecurity for zones. I don't think that this is very desirable. So I think that once we added the DS RR and removed the NULL KEY RR, authenticated denial became essential. If we added the ANTI-DS RR, then we go back to not needing authenticated denial for DNSSEC's sake. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: