From owner-namedroppers@ops.ietf.org Wed May 5 11:17: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 LAA20262 for ; Wed, 5 May 2004 11:17:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLNzk-00020k-Ir for namedroppers-data@psg.com; Wed, 05 May 2004 15:07:36 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLNze-0001zu-9K for namedroppers@ops.ietf.org; Wed, 05 May 2004 15:07:30 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i45F6NVZ090934 for ; Wed, 5 May 2004 11:06:23 -0400 (EDT) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i45F6Mbl090933 for namedroppers@ops.ietf.org; Wed, 5 May 2004 11:06:22 -0400 (EDT) Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLEWi-0000v0-Kp for namedroppers@ops.ietf.org; Wed, 05 May 2004 05:01:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4550wu16155 for ; Wed, 5 May 2004 08:00:58 +0300 Date: Wed, 5 May 2004 08:00:58 +0300 (EEST) From: Pekka Savola To: namedroppers@ops.ietf.org Subject: handling of additional data (fwd) Message-ID: 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.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. ] FYI, This issue was raised in DNSOP, but I was advised to also solicit opinions from here. (I'm not subscribed so please keep in Cc:) ---------- Forwarded message ---------- Date: Tue, 4 May 2004 12:24:15 +0300 (EEST) From: Pekka Savola To: dnsop@lists.uoregon.edu Subject: handling of additional data [Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt] Hi, Let's take an issue separately from the rest. Me and Jinmei discussed this, but were OK with as it is. However, if WG has clear opinions, now might be time for modifying the text and/or recommiding changes to the additional data processing. As described by ipv6-dns-issues, section 4.4, there are two kinds of additional data: 1. "critical" additional data; this must be included (all the possible RRsets) in all scenarios, and 2. "courtesy" additional data; this could be sent in full, with only a few RRsets, or with no RRsets, and can be fetched separately as well, but which could lead to non-optimal results. [[ see examples of each in the draft.]] Imagine the event where the additional data section would include both A and AAAA RRsets and would be too large, but omitting one RRset would make it small enough. Now, the questions are: A) Is there consensus that it's better to set TC bit than to return only some RRsets of critical additional data? B) Is it better to omit all the courtesy addional data, rather than omit some RRsets? C) (This is relevant if you answered "no" to B) Is it better to set TC bit rather than return only some RRsets with courtesy additional data? Opinions? Discussion? Etc.? As for my personal preference: A) probably yes (not sure). B) yes, omit everything. C) possibly yes, not sure. (Doesn't matter if "yes" to B) -- 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 May 6 08:02: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 IAA08178 for ; Thu, 6 May 2004 08:02:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLhVL-0005LR-3G for namedroppers-data@psg.com; Thu, 06 May 2004 11:57:31 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLhVG-0005Kw-Fg for namedroppers@ops.ietf.org; Thu, 06 May 2004 11:57:26 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46BvL026624; Thu, 6 May 2004 18:57:22 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i46BvA0Y019157; Thu, 6 May 2004 18:57:12 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 May 2004 18:57:10 +0700 Message-ID: <10945.1083844630@munnari.OZ.AU> 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 Date: Wed, 5 May 2004 08:00:58 +0300 (EEST) From: Pekka Savola Message-ID: | A) Is there consensus that it's better to set TC bit than to return | only some RRsets of critical additional data? I have no idea if there's consensus or not (consensus among whom?), but assuming the question intended there was really "Is it better..." (as in questions B & C) then I think the answer is probably yes, but I am not certain that is necessarily true - it is certainly better to set TC than to send no "critical" additional data, but if some is sent, and even better, if which of it is sent can vary from one response to another, then I am not certain that just sending it, without TC isn't the better solution (I'd really like to see some performance measurements with things done both ways). | B) Is it better to omit all the courtesy addional data, rather than | omit some RRsets? No. Provided that only complete RRsets are omitted, not just parts of RRsets, if a complete "courtesy" RRset will fit, and the server wants to send it (ie: my answer isn't a demand upon servers to include such data), include it, regardless of how many others won't fit (again, better if the implementation doesn't have a fixation on which of the available RRsets it should include when they won't all fit, but allows that to vary). | C) (This is relevant if you answered "no" to B) Is it better to set | TC bit rather than return only some RRsets with courtesy | additional data? No. You should also be asking those who said yes to B whether it is better to set TC rather than dropping all the RRsets. 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 May 6 17:13: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 RAA19952 for ; Thu, 6 May 2004 17:13:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLq5i-000ARm-E7 for namedroppers-data@psg.com; Thu, 06 May 2004 21:07:38 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BLq5g-000AQx-So for namedroppers@ops.ietf.org; Thu, 06 May 2004 21:07:37 +0000 Received: (qmail 89010 invoked from network); 6 May 2004 21:08:52 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 6 May 2004 21:08:52 -0000 Message-ID: <409AAA01.5000607@necom830.hpcl.titech.ac.jp> Date: Fri, 07 May 2004 06:11:29 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Robert Elz CC: Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) References: <10945.1083844630@munnari.OZ.AU> In-Reply-To: <10945.1083844630@munnari.OZ.AU> 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 Kre; > then I am > not certain that just sending it, without TC isn't the better solution The problem is that glues can be provided only with referral and there is no way to separately ask glues. By definition, glues are things which can not be asked without the glues itself. Worse, there is no way for the resolver know that some glues are missing, unless glues are under the zone cut, which is not always the case, even in which case, separate asking causes the same referral still with missing glues. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 6 19:28: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 TAA27185 for ; Thu, 6 May 2004 19:28:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLsB0-000Gnw-AI for namedroppers-data@psg.com; Thu, 06 May 2004 23:21:14 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLsAy-000GnK-Tz for namedroppers@ops.ietf.org; Thu, 06 May 2004 23:21:13 +0000 Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46NKs016225; Fri, 7 May 2004 06:20:55 +0700 (ICT) Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i46NKrDB019159; Fri, 7 May 2004 06:20:53 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i46NKp98023547; Fri, 7 May 2004 06:20:52 +0700 (ICT) From: Robert Elz To: Masataka Ohta cc: Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: <409AAA01.5000607@necom830.hpcl.titech.ac.jp> References: <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <10945.1083844630@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 May 2004 06:20:51 +0700 Message-ID: <21729.1083885651@munnari.OZ.AU> 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 Date: Fri, 07 May 2004 06:11:29 +0900 From: Masataka Ohta Message-ID: <409AAA01.5000607@necom830.hpcl.titech.ac.jp> | The problem is that glues can be provided only with referral | and there is no way to separately ask glues. Yes, true, but there should never be a need to ask specifically for glue, asking for the data should return the same thing - if the glue has been made different than the authoritative data, and something is depending upon that, then I don't much care what happens. | By definition, glues are things which can not be asked without | the glues itself. I'm not sure I quite agree with that definition, but nothing depends upon it here, so it doesn't matter. | Worse, there is no way for the resolver know that some glues | are missing, True, but does it really matter? If all the glue is omitted, then, of course, there's a problem - that's why I said ... it is certainly better to set TC than to send no "critical" additional data, but if some glue is included, then the resolver has a path to the next set of servers. It doesn't have all the information, and may not be able to reach all of the servers, but it should be able to reach at least one. If it desires it can start A/AAAA queries to look for any missing data that may exist. Now I'm not saying this is necessarily better than having the resolver try again with TCP after receiving a TC reply - what I'm saying is that I don't know, and I don't know (perhaps just due to my ignorance) of anyone who has done any kind of experimentation to find out which is the better approach. I'd be hesitant about claiming that one is necessarily better than the other based upon no more than superstition and guesswork. 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 May 6 20:53: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 UAA01319 for ; Thu, 6 May 2004 20:53:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLtWJ-00099s-D6 for namedroppers-data@psg.com; Fri, 07 May 2004 00:47:19 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLtWG-00099K-An for namedroppers@ops.ietf.org; Fri, 07 May 2004 00:47:16 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6D64C139A3; Fri, 7 May 2004 00:47:15 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Robert Elz Cc: Masataka Ohta , Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: Message from Robert Elz of "Fri, 07 May 2004 06:20:51 +0700." <21729.1083885651@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 07 May 2004 00:47:15 +0000 Message-Id: <20040507004715.6D64C139A3@sa.vix.com> 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'd be hesitant about claiming that one is necessarily better than the other > based upon no more than superstition and guesswork. same here. the definition of "helpful" vs. "necessary" glue is at best subjective. please just set TC if anything does not fit, and that you truncate on rrset boundaries, just like 1035 recommends. -- to unsubscribe send a message to namedroppers-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 May 6 21:18: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 VAA02469 for ; Thu, 6 May 2004 21:18:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLttI-000Efd-St for namedroppers-data@psg.com; Fri, 07 May 2004 01:11:04 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BLttH-000Ef9-Mj for namedroppers@ops.ietf.org; Fri, 07 May 2004 01:11:03 +0000 Received: (qmail 90074 invoked from network); 7 May 2004 01:12:21 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 7 May 2004 01:12:21 -0000 Message-ID: <409AE311.5040001@necom830.hpcl.titech.ac.jp> Date: Fri, 07 May 2004 10:14:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie CC: Robert Elz , Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) References: <20040507004715.6D64C139A3@sa.vix.com> In-Reply-To: <20040507004715.6D64C139A3@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.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 Paul; > the definition of "helpful" vs. "necessary" glue is at best > subjective. It is a problem of the definition of the draft. However, "glue" is necessary while other additionals are merely helpful. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 6 21:33: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 VAA03212 for ; Thu, 6 May 2004 21:33:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLuBK-000Hx1-45 for namedroppers-data@psg.com; Fri, 07 May 2004 01:29:42 +0000 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLuBJ-000Hwn-4t for namedroppers@ops.ietf.org; Fri, 07 May 2004 01:29:41 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.10/8.12.9) with ESMTP id i471TIaF000367; Thu, 6 May 2004 18:29:18 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id i471TIfc015781; Thu, 6 May 2004 18:29:18 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.10/8.12.6/Submit) id i471THJj015893; Thu, 6 May 2004 18:29:17 -0700 (PDT) Date: Thu, 6 May 2004 18:29:17 -0700 (PDT) Message-Id: <200405070129.i471THJj015893@guava.araneus.fi> To: Paul Vixie Cc: Robert Elz , Masataka Ohta , Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: <20040507004715.6D64C139A3@sa.vix.com> References: <21729.1083885651@munnari.OZ.AU> <20040507004715.6D64C139A3@sa.vix.com> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) 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_RFCI autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > same here. the definition of "helpful" vs. "necessary" glue is at best > subjective. please just set TC if anything does not fit, and that you > truncate on rrset boundaries, just like 1035 recommends. 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: Where TC is set, the partial RRSet that would not completely fit may be left in the response. -- Andreas Gustafsson, gson@nominum.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 May 6 21:34: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 VAA03278 for ; Thu, 6 May 2004 21:34:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLuCA-000I4s-77 for namedroppers-data@psg.com; Fri, 07 May 2004 01:30:34 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BLuC9-000I4U-1f for namedroppers@ops.ietf.org; Fri, 07 May 2004 01:30:33 +0000 Received: (qmail 90186 invoked from network); 7 May 2004 01:31:52 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 7 May 2004 01:31:52 -0000 Message-ID: <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> Date: Fri, 07 May 2004 10:34:26 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Robert Elz CC: Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) References: <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <10945.1083844630@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> In-Reply-To: <21729.1083885651@munnari.OZ.AU> 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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit kre; > | Worse, there is no way for the resolver know that some glues > | are missing, > > True, but does it really matter? > > If all the glue is omitted, then, of course, there's a problem - that's > why I said ... > > it is certainly better to set TC than > to send no "critical" additional data, > > but if some glue is included, then the resolver has a path to the next set > of servers. It doesn't have all the information, and may not be able to > reach all of the servers, but it should be able to reach at least one. Say "fault tolerance". It is required that each zone has at least two name servers. Moreover, administrators of a zone with more than three name servers are doing so with *REASONS* that addresses of all of them should be tried by the client. So, it is still OK if a reply includes "at least one" address of name servers chosen randomly for every query and clients retry original query. However, they are new requirements. Worse, because of cached referral, clients will continue to receive the same answer and are helpless if the received addresses are not useful. > If it desires it can start A/AAAA queries to look for any missing data > that may exist. As we agreed: > | The problem is that glues can be provided only with referral > | and there is no way to separately ask glues. > > Yes, true, it is impossible to separately ask glue informaion unless you have glue information. > Now I'm not saying this is necessarily better than having the resolver try > again with TCP after receiving a TC reply - what I'm saying is that I don't > know, and I don't know (perhaps just due to my ignorance) of anyone who has > done any kind of experimentation to find out which is the better approach. I'm saying I do know larger message size (over UDP or TCP) is the only way, if glues cause message size overflow. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 6 21:54: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 VAA04055 for ; Thu, 6 May 2004 21:54:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BLuUT-000MdL-FG for namedroppers-data@psg.com; Fri, 07 May 2004 01:49:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BLuUO-000McU-Il for namedroppers@ops.ietf.org; Fri, 07 May 2004 01:49:24 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3B34413CDF; Fri, 7 May 2004 01:49:24 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: gson@nominum.com (Andreas Gustafsson) Cc: Robert Elz , Masataka Ohta , Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: Message from gson@nominum.com (Andreas Gustafsson) of "Thu, 06 May 2004 18:29:17 MST." <200405070129.i471THJj015893@guava.araneus.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 07 May 2004 01:49:24 +0000 Message-Id: <20040507014924.3B34413CDF@sa.vix.com> 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 > 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. -- to unsubscribe send a message to namedroppers-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 May 7 14:26:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10484 for ; Fri, 7 May 2004 14:26:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BM9w4-0001mc-9N for namedroppers-data@psg.com; Fri, 07 May 2004 18:19:00 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BM9w2-0001mE-RF for namedroppers@ops.ietf.org; Fri, 07 May 2004 18:18:58 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id i47IIrop015676; Fri, 7 May 2004 14:18:53 -0400 (EDT) Received: from chinook (chinook.corppc.vrsn.com [10.131.31.52]) by VSVAPOSTALGW1.vcorp.ad.vrsn.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KNPNXJ4Z; Fri, 7 May 2004 14:18:47 -0400 Received: by chinook (Postfix, from userid 500) id 8B7A6212FC4; Fri, 7 May 2004 14:18:47 -0400 (EDT) Date: Fri, 7 May 2004 14:18:47 -0400 From: Matt Larson To: Paul Vixie Cc: Robert Elz , Masataka Ohta , Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) Message-ID: <20040507181847.GT31336@chinook.corppc.vrsn.com> References: <21729.1083885651@munnari.OZ.AU> <20040507004715.6D64C139A3@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040507004715.6D64C139A3@sa.vix.com> User-Agent: Mutt/1.5.6i 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 Fri, 07 May 2004, Paul Vixie wrote: > the definition of "helpful" vs. "necessary" glue is at best > subjective. There are two issues lurking here. The first is the definition of "glue". The second is whether there is any ambiguity surrounding including a name server's A record in the additional section of a response. First, to the definition of glue. The end of Section 4.2.1 of RFC 1034 appears to make it clear that glue RRs are always A records corresponding the RDATA of an NS record, and that these records are required to solve the circular dependency problem when the name of the name server is at or below the zone cut created by the NS record. Here's the exact text: To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response. Using this definition, not all A records in the additional section of a message corresponding to NS RDATA are glue: only those meeting the at-or-below-a-zone-cut criterion above. But lest terminology disagreements get in the way of the second issue, I don't understand the subjectivity you refer to, Paul. A name server's A record would appear to be able to be classified as "helpful" or "necessary" simply by its name relative to the zone in question using the RFC 1034 definition of glue. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 7 15: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 PAA13969 for ; Fri, 7 May 2004 15:09:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMAfZ-000FEE-Fp for namedroppers-data@psg.com; Fri, 07 May 2004 19:06:01 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMAfW-000FDK-DZ for namedroppers@ops.ietf.org; Fri, 07 May 2004 19:05:58 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2A7DF42B2 for ; Fri, 7 May 2004 15:05:57 -0400 (EDT) Date: Fri, 07 May 2004 15:05:57 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: <20040507181847.GT31336@chinook.corppc.vrsn.com> References: <21729.1083885651@munnari.OZ.AU> <20040507004715.6D64C139A3@sa.vix.com> <20040507181847.GT31336@chinook.corppc.vrsn.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040507190557.2A7DF42B2@thrintun.hactrn.net> 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 Fri, 7 May 2004 14:18:47 -0400, Matt Larson wrote: > ... > Using this definition, not all A records in the additional section of > a message corresponding to NS RDATA are glue: only those meeting the > at-or-below-a-zone-cut criterion above. Right, with the obvious change that these days we'd be talking about all of the address types (AAAA and A), not just A. > But lest terminology disagreements get in the way of the second issue, > I don't understand the subjectivity you refer to, Paul. A name > server's A record would appear to be able to be classified as > "helpful" or "necessary" simply by its name relative to the zone in > question using the RFC 1034 definition of glue. Paul can of course speak for himself, but one way of looking at this is that if all addresses were equally useful, we wouldn't need so many addresses. That is: part of the point of providing redundant servers (and the whole point of providing redundant addresses) is that stuff happens (routing problems, backhoe induced deep fade, whatever), and when stuff happens, some addresses may be better than others. So, completely punting on additional data that's just an optimization and concentrating on glue as defined above: if there's more glue than will fit in the response message, the name server doesn't really know which glue will be most useful to the resolver. It can, in theory, attempt to guess, using arbitrarily complex (and fragile) criteria, but it can't know. -- to unsubscribe send a message to namedroppers-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 May 7 15:13: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 PAA14461 for ; Fri, 7 May 2004 15:13:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMAjC-000Fz0-93 for namedroppers-data@psg.com; Fri, 07 May 2004 19:09:46 +0000 Received: from [192.150.250.67] (helo=delta.noi.kre.to) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMAie-000Fqu-JS for namedroppers@ops.ietf.org; Fri, 07 May 2004 19:09:44 +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 i47J0NXi028492; Sat, 8 May 2004 02:00:23 +0700 (ICT) From: Robert Elz To: Masataka Ohta cc: Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> References: <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <10945.1083844630@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 May 2004 02:00:23 +0700 Message-ID: <24905.1083956423@munnari.OZ.AU> 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 Date: Fri, 07 May 2004 10:34:26 +0900 From: Masataka Ohta Message-ID: <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> | Say "fault tolerance". Otha-san - consider the context here please. We're not concerned with zones with 2 (or 3) nameservers, each with a couple of addresses - those things just don't cause packet overflow (even with AAAA records, SIG records, and the 512 byte limit) in a referral or NS query (perhaps when the NS is just in the auth or additional section as extra info, but those cases don't matter). To overflow the limits there are either going to be a large number of NS records or the servers are going to have lots of addresses. Even with some of the data missing, there is going to be plenty of fault tolerance - maybe not all the zone admin had hoped for, but perhaps enough (once again, all I am saying here is that I don't know, and I haven't seen any data that would convince me one way or the other). | Moreover, administrators of a zone with more than three name | servers are doing so with *REASONS* that addresses of all of | them should be tried by the client. The admin also knows how big a referral packet containing their NS list can get - they can plan to avoid the problem in the first place. The question is how best for the software to deal with cases where the admin has no idea what is good, and makes a mess. After all this, I still don't know which practice will result in the optimal behaviour for any of the server, the resolver, or the net as a whole - nor do I know that the practices optimising those three are necessarily all the same, and if they're not, I also have no idea just which one someone is attempting to specify, or why that one rather than the others. But that may be because I haven't been following the dnsops WG for a while now, all might be quite clear over there. 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 Fri May 7 16:02: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 QAA17113 for ; Fri, 7 May 2004 16:02:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMBTc-0005AA-DG for namedroppers-data@psg.com; Fri, 07 May 2004 19:57:44 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMBTb-00059W-C5 for namedroppers@ops.ietf.org; Fri, 07 May 2004 19:57:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 21E43139A3 for ; Fri, 7 May 2004 19:57:43 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: Message from Matt Larson of "Fri, 07 May 2004 14:18:47 -0400." <20040507181847.GT31336@chinook.corppc.vrsn.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 07 May 2004 19:57:43 +0000 Message-Id: <20040507195743.21E43139A3@sa.vix.com> 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 > But lest terminology disagreements get in the way of the second issue, > I don't understand the subjectivity you refer to, Paul. A name > server's A record would appear to be able to be classified as > "helpful" or "necessary" simply by its name relative to the zone in > question using the RFC 1034 definition of glue. by that definition, i agree, and if the rule change being considered is just "if necessary glue won't fit, truncate; if helpful glue won't fit, omit it" then i'd agree with that also. -- to unsubscribe send a message to namedroppers-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 May 7 16:59: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 QAA20235 for ; Fri, 7 May 2004 16:59:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMCM7-000NFk-S0 for namedroppers-data@psg.com; Fri, 07 May 2004 20:54:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BMCM5-000NFJ-W3 for namedroppers@ops.ietf.org; Fri, 07 May 2004 20:54:03 +0000 Received: (qmail 95379 invoked from network); 7 May 2004 20:55:35 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 7 May 2004 20:55:35 -0000 Message-ID: <409BF853.7010908@necom830.hpcl.titech.ac.jp> Date: Sat, 08 May 2004 05:57:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Matt Larson CC: Paul Vixie , Robert Elz , Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) References: <21729.1083885651@munnari.OZ.AU> <20040507004715.6D64C139A3@sa.vix.com> <20040507181847.GT31336@chinook.corppc.vrsn.com> In-Reply-To: <20040507181847.GT31336@chinook.corppc.vrsn.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=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Matt Larson; > Using this definition, not all A records in the additional section of > a message corresponding to NS RDATA are glue: only those meeting the > at-or-below-a-zone-cut criterion above. A problem is that " at-or-below-a-zone-cut" is wrong that circular dependency occurs, for example, by a "org" zone served by a server in a "edu" zone and the "edu" zone served by a server in the "org" zone. That is, 1034 is not self-consistent. However, the problem above does not affect the current problem as authoritative servers have full knowledge on what is "glue". Paul's confusion is to have assumed "helpful glue". There is no such thing as "helpful glue" that name servers should simply put all the "glue" in response, even if it causes truncation. Resolvers may try addresses in truncated referral. But, it should never be cached and if all of them fails, it should get untruncated referral with longer messages. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 7 17:20: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 RAA21532 for ; Fri, 7 May 2004 17:20:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMCgv-00030B-RA for namedroppers-data@psg.com; Fri, 07 May 2004 21:15:33 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BMCgu-0002zN-DT for namedroppers@ops.ietf.org; Fri, 07 May 2004 21:15:32 +0000 Received: (qmail 95486 invoked from network); 7 May 2004 21:17:06 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 7 May 2004 21:17:06 -0000 Message-ID: <409BFD5E.8090707@necom830.hpcl.titech.ac.jp> Date: Sat, 08 May 2004 06:19:26 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Robert Elz CC: Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) References: <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <10945.1083844630@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> <24905.1083956423@munnari.OZ.AU> In-Reply-To: <24905.1083956423@munnari.OZ.AU> 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=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit kre; Things can get a little more complicated. Consider, for example, scalable (w.r.t. global routing table size) multihoming where sites receives multiple prefixes each from its upstream ISPs, whichi is considered in multi6 WG. Then, a name server connected to three LANs of a triply homed site has 9 addresses. If there are three such servers, there will be 27 addresses, which is too many to fit in 512B with AAAA. > Even with some of the data missing, there is going to be plenty of > fault tolerance - maybe not all the zone admin had hoped for, but > perhaps enough (once again, all I am saying here is that I don't know, > and I haven't seen any data that would convince me one way or the other). As "enough" is primarily judged by the zone admin, if the admin hoped for more, it is not "enough" or the admin is too greedy. See above for an example how difficult to say an admin is "greedy" as merely 3 servers can cause overflow. Things can get even more complicated if some of the servers are in other sites (it is important for fault tolerance) operated by other admins. > | Moreover, administrators of a zone with more than three name > | servers are doing so with *REASONS* that addresses of all of > | them should be tried by the client. > > The admin also knows how big a referral packet containing their NS > list can get - they can plan to avoid the problem in the first place. > The question is how best for the software to deal with cases where > the admin has no idea what is good, and makes a mess. If we have a broken protocol and fix is impossible, then, let admins avoid the problem. If we are designing a protocol or revising it in backward compatible way, never assume admins are intelligent. Admins already have a lot of things to consider. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 7 19:19: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 TAA27858 for ; Fri, 7 May 2004 19:19:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMEXy-000GPr-Os for namedroppers-data@psg.com; Fri, 07 May 2004 23:14:26 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMEXw-000GOO-5n for namedroppers@ops.ietf.org; Fri, 07 May 2004 23:14:24 +0000 Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i47NE2023106; Sat, 8 May 2004 06:14:02 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i47NE1DB011852; Sat, 8 May 2004 06:14:01 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i47N5YEO013555; Sat, 8 May 2004 06:05:37 +0700 (ICT) From: Robert Elz To: Masataka Ohta cc: Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: <409BFD5E.8090707@necom830.hpcl.titech.ac.jp> References: <409BFD5E.8090707@necom830.hpcl.titech.ac.jp> <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <10945.1083844630@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> <24905.1083956423@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 May 2004 06:05:34 +0700 Message-ID: <11924.1083971134@munnari.OZ.AU> 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 Date: Sat, 08 May 2004 06:19:26 +0900 From: Masataka Ohta Message-ID: <409BFD5E.8090707@necom830.hpcl.titech.ac.jp> | Then, a name server connected to three LANs of a triply | homed site has 9 addresses. Yes, it would. But that the addresses exist doesn't mean they have to all be listed in the AAAA records of the name that is listed in the NS record. Listing one address (perhaps one from a different LAN) from each ISP's prefix is sufficient, more than that just adds more useless retries in the common failure case where the problem is that the nameserver (or its host) is down. We should be encouraging better use of resources, not just "stick it all in because that's the thoughtless way" - especially in docs from dnsops. | Things can get even more complicated if some of the servers are | in other sites (it is important for fault tolerance) operated by | other admins. The server can be in another site, in my NS records however, I decide what I will call it, and if I give it a name from my space, I also decide what addresses it will have. 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 Fri May 7 23:02: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 XAA06552 for ; Fri, 7 May 2004 23:02:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BMI0z-000LOX-Re for namedroppers-data@psg.com; Sat, 08 May 2004 02:56:37 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMI0y-000LOI-3i for namedroppers@ops.ietf.org; Sat, 08 May 2004 02:56:36 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i482t8VZ012099 for ; Fri, 7 May 2004 22:55:08 -0400 (EDT) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i482t8At012098 for namedroppers@ops.ietf.org; Fri, 7 May 2004 22:55:08 -0400 (EDT) Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BMEBP-0007Rx-4e for namedroppers@ops.ietf.org; Fri, 07 May 2004 22:51:07 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 12ACAA86F for ; Fri, 7 May 2004 22:51:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i47MoUPT066287; Sat, 8 May 2004 08:50:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200405072250.i47MoUPT066287@drugs.dv.isc.org> To: Masataka Ohta Cc: Matt Larson , Paul Vixie , Robert Elz , Pekka Savola , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: handling of additional data (fwd) In-reply-to: Your message of "Sat, 08 May 2004 05:57:55 +0900." <409BF853.7010908@necom830.hpcl.titech.ac.jp> Date: Sat, 08 May 2004 08:50:30 +1000 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. ] > Matt Larson; > > > Using this definition, not all A records in the additional section of > > a message corresponding to NS RDATA are glue: only those meeting the > > at-or-below-a-zone-cut criterion above. > > A problem is that " at-or-below-a-zone-cut" is wrong that > circular dependency occurs, for example, by a "org" zone served > by a server in a "edu" zone and the "edu" zone served by a server > in the "org" zone. > > That is, 1034 is not self-consistent. Sure there can be circular dependancies. We don't however have to support them if it makes management of the DNS in the whole impossible. We tried it and is was a failure. Stricter rules were needed. Can anyone else here remember when NS.UU.NET has 26 different addresses for it floating around in the DNS? In reality it only had one address and it had been changed since it was initially assigned. Only accepting glue when it was below the top of zone when loading/transfering zones and rejecting additional data when it was not below the currrent query domain basically fixed the problem. It took a few years for nameservers which did this to get to be deployed on all the servers which served zones that were also served by NS.UU.NET but in the end the bogus records were removed. We don't have that problem today because nameservers actually enforce a heirachical glue acceptance rules. Yes they prevent configurations with circular dependancies but they make the DNS managable. > However, the problem above does not affect the current problem as > authoritative servers have full knowledge on what is "glue". > > Paul's confusion is to have assumed "helpful glue". > > There is no such thing as "helpful glue" that name servers should > simply put all the "glue" in response, even if it causes > truncation. > > Resolvers may try addresses in truncated referral. But, it should > never be cached and if all of them fails, it should get untruncated > referral with longer messages. > > Masataka Ohta > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From ubk_press@mail.com Sat May 8 03:06:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17451 for ; Sat, 8 May 2004 03:06:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMLus-0001dF-C5 for dnsext-archive@ietf.org; Sat, 08 May 2004 03:06:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMLtz-0001Do-00 for dnsext-archive@ietf.org; Sat, 08 May 2004 03:05:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMLtC-0000o4-00; Sat, 08 May 2004 03:04:51 -0400 Received: from [61.157.95.251] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BMLsp-00048e-NI; Sat, 08 May 2004 03:04:36 -0400 From: "Brasil 2004: . wvb" To: discuss@ietf.org Subject: A propriedade, em vias de extinção? cf.: hzr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 08 May 2004 03:04:36 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.9 required=5.0 tests=AWL,HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 0.0 AWL AWL: Auto-whitelist adjustment

(ref.:asc) Aos caros amigos, atenciosamente, Ferreira Passos/ConstruNews.

Lindenberg:EnEspañol - Lindenberg:InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (6)

Brasil 2004: direito de propriedade, em vias de extinção?

Caso não houver uma reação, em poucos anos a propriedade terá se transformado numa reminiscência histórica, e o velho sonho marxista se realizado na apatia e indiferença da chamada "burguesia", adverte Lindenberg

"Patrulhas", mordaça, anestesia

* Adolpho 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 ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas populares" inspiradas na teologia da libertação e nos Fóruns Sociais Mundiais. Assim, os meios de comunicação e a sociedade brasileira estão sendo "patrulhados", amordaçados, anestesiados.

Duas ameaças

* Em seu recente artigo "O direito de propriedade, instituição em vias de extinção?", da Série Temas Patrulhados, Lindenberg afirma que o direito de propriedade, no Brasil, está sendo vítima de duas ameaças implacáveis: o aumento da carga tributária - uma das mais altas do mundo - e os movimentos dos sem-terra e sem-teto, inspirados na teologia da libertação e no modelo cubano de produção de miséria.

"Burguesia": sem reação?

* Citando testemunhas de especialistas, o autor constata que se todos os projetos de majoração de impostos que estão sendo discutidos no Congresso forem aprovados, em poucos anos o direito de propriedade terá se transformado numa reminiscência histórica . O velho sonho marxista teria se realizado assim sem grandes reações por parte da "burguesia", anestesiada.

* No entanto, para as pessoas de bom senso, em geral, e para os católicos, em particular, essa escalada contra a propriedade constitui uma flagrante desobediência da lei divina e da lei natural, sem falar que caracterizará um golpe a mais na já combalida instituição familiar.

Reta ordem socioeconômica

* No artigo "O direito de propriedade, instituição em vias de extinção?" se lembra com abundante argumentação que a propriedade constitui pedra de ângulo da estrutura econômica e um dos princípios fundamentais de uma reta ordem socioeconômica. E não só por razões econômicas, perfeitamente válidas, mas também e principalmente por razões de ordem moral e religiosa.

Outros itens

* Outros itens desenvolvidos no artigo de Lindenberg, que oferecemos gratuitamente, por e-mail, junto com a Introdução do livro "Os católicos e a economia de mercado":

- Família e propriedade

- Propriedade e princípio ontológico

- Propriedade, autonomia, personalidad

- Bolo, fatias e solução

- Economias socializadas versus bom senso

Link gratuito:

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

Outros links gratuitos (e-Book e outros artigos):

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:ArtigosAnteriores

Lindenberg:ProximosArtigos

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:EmTermos

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder 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 May 10 15:47: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 PAA28945 for ; Mon, 10 May 2004 15:47:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNGdd-000DZW-4G for namedroppers-data@psg.com; Mon, 10 May 2004 19:40:33 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BNGdb-000DZD-39 for namedroppers@ops.ietf.org; Mon, 10 May 2004 19:40:31 +0000 Received: (qmail 13728 invoked from network); 10 May 2004 19:42:56 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 10 May 2004 19:42:56 -0000 Message-ID: <409FDB9D.4010609@necom830.hpcl.titech.ac.jp> Date: Tue, 11 May 2004 04:44:29 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Robert Elz CC: Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) References: <409BFD5E.8090707@necom830.hpcl.titech.ac.jp> <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <10945.1083844630@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> <24905.1083956423@munnari.OZ.AU> <11924.1083971134@munnari.OZ.AU> In-Reply-To: <11924.1083971134@munnari.OZ.AU> 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=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit kre; > | Then, a name server connected to three LANs of a triply > | homed site has 9 addresses. > > Yes, it would. But that the addresses exist doesn't mean they have to > all be listed in the AAAA records of the name that is listed in the NS > record. Listing one address (perhaps one from a different LAN) from > each ISP's prefix is sufficient, more than that just adds more useless > retries in the common failure case where the problem is that the nameserver > (or its host) is down. The problem is that the situation will be common that you can't expect much on operators there. > The server can be in another site, in my NS records however, I decide > what I will call it, and if I give it a name from my space, I also > decide what addresses it will have. Not all the operators are like you. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 10 15:58: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 PAA29792 for ; Mon, 10 May 2004 15:58:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNGsd-000ICr-Aw for namedroppers-data@psg.com; Mon, 10 May 2004 19:56:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BNGsc-000I9X-3C for namedroppers@ops.ietf.org; Mon, 10 May 2004 19:56:02 +0000 Received: (qmail 13785 invoked from network); 10 May 2004 19:58:28 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 10 May 2004 19:58:28 -0000 Message-ID: <409FDF40.2000102@necom830.hpcl.titech.ac.jp> Date: Tue, 11 May 2004 05:00:00 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mark Andrews CC: Matt Larson , Paul Vixie , Robert Elz , Pekka Savola , namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) References: <200405072250.i47MoUPT066287@drugs.dv.isc.org> In-Reply-To: <200405072250.i47MoUPT066287@drugs.dv.isc.org> 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=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Andrews; > Sure there can be circular dependancies. We don't however > have to support them if it makes management of the DNS in > the whole impossible. We tried it and is was a failure. That "we tried" means others will try. > Stricter rules were needed. It certainly is a solution. > Can anyone else here remember when NS.UU.NET has 26 different > addresses for it floating around in the DNS? In reality > it only had one address and it had been changed since it > was initially assigned. Only accepting glue when it was below > the top of zone when loading/transfering zones and rejecting > additional data when it was not below the currrent query domain > basically fixed the problem. What is the problem? Those who buy service from UUNET and their peers suffer that it is a problem of UUNET, doesn't it? > It took a few years for nameservers > which did this to get to be deployed on all the servers which > served zones that were also served by NS.UU.NET but in the > end the bogus records were removed. Are you saying we should modify protocols/operations, merely because of a stupid act of an ISP harming its own business? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 10 21:19: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 VAA20752 for ; Mon, 10 May 2004 21:19:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNLrU-0002g1-41 for namedroppers-data@psg.com; Tue, 11 May 2004 01:15:12 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNLrN-0002ei-QJ for namedroppers@ops.ietf.org; Tue, 11 May 2004 01:15:05 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id AFB4FA864 for ; Tue, 11 May 2004 01:15:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i4B1F2PT089545 for ; Tue, 11 May 2004 11:15:02 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: handling of additional data (fwd) In-reply-to: Your message of "Tue, 11 May 2004 05:00:00 +0900." <409FDF40.2000102@necom830.hpcl.titech.ac.jp> Date: Tue, 11 May 2004 11:15:02 +1000 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 > Mark Andrews; > > > Sure there can be circular dependancies. We don't however > > have to support them if it makes management of the DNS in > > the whole impossible. We tried it and is was a failure. > > That "we tried" means others will try. It means that older nameservers didn't have restrictions and it ended up being a management nightmare. Been there, done that, don't want to go there again. > > Stricter rules were needed. > > It certainly is a solution. > > > Can anyone else here remember when NS.UU.NET has 26 different > > addresses for it floating around in the DNS? In reality > > it only had one address and it had been changed since it > > was initially assigned. Only accepting glue when it was below > > the top of zone when loading/transfering zones and rejecting > > additional data when it was not below the currrent query domain > > basically fixed the problem. > > What is the problem? Those who buy service from UUNET and their > peers suffer that it is a problem of UUNET, doesn't it? No *everyone* suffered. It wasn't just UUNET. UUNET was a example of what when wrong. It happened to lots of ISP's, basically anyone who wasn't serving their own zones. UUNET was just a prime example of the problem. It was a matter of "there is bad data out there, where is it coming from". The answer to that used to be "anyone of several thousand servers for NS.UU.NET" and the servers could "learn" the bad addresses after or as a side of checking them. Today you look at the parent servers for the zone. We can do this because modern servers reject "out of zone" glue. > > It took a few years for nameservers > > which did this to get to be deployed on all the servers which > > served zones that were also served by NS.UU.NET but in the > > end the bogus records were removed. > > Are you saying we should modify protocols/operations, merely > because of a stupid act of an ISP harming its own business? No. The protocol didn't scale on the management side. Placing constraints on glue restored the ability to manage the DNS. > Masataka Ohta > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 10 22:49: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 WAA25991 for ; Mon, 10 May 2004 22:49:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNNHk-000OGy-LA for namedroppers-data@psg.com; Tue, 11 May 2004 02:46:24 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BNNHj-000OGa-7D for namedroppers@ops.ietf.org; Tue, 11 May 2004 02:46:23 +0000 Received: (qmail 15533 invoked from network); 11 May 2004 02:48:53 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 11 May 2004 02:48:53 -0000 Message-ID: <40A03F6E.8010304@necom830.hpcl.titech.ac.jp> Date: Tue, 11 May 2004 11:50:22 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mark Andrews CC: namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) References: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> In-Reply-To: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> 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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Andrews; > It means that older nameservers didn't have restrictions > and it ended up being a management nightmare. Been there, > done that, don't want to go there again. That is a wrong analysis. >>What is the problem? Those who buy service from UUNET and their >>peers suffer that it is a problem of UUNET, doesn't it? > No *everyone* suffered. It wasn't just UUNET. UUNET was > a example of what when wrong. It happened to lots of ISP's, > basically anyone who wasn't serving their own zones. UUNET > was just a prime example of the problem. So, only those who buy service from stuppid ISPs and their peers suffered that it is a problem of stupid ISPs. It is not a problem for the rest of the world and to be solved automatically as bankrupcies of stupid ISPs. > No. The protocol didn't scale on the management side. It is merely a problem of mismanagements. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 11 09: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 JAA26272 for ; Tue, 11 May 2004 09:52:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BNXc7-000G5z-Np for namedroppers-data@psg.com; Tue, 11 May 2004 13:48:07 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNXc1-000Fsu-9N for namedroppers@ops.ietf.org; Tue, 11 May 2004 13:48:01 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i4BDk3VZ030210 for ; Tue, 11 May 2004 09:46:03 -0400 (EDT) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i4BDk315030209 for namedroppers@ops.ietf.org; Tue, 11 May 2004 09:46:03 -0400 (EDT) Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNRpy-000OVv-SP for namedroppers@ops.ietf.org; Tue, 11 May 2004 07:38:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4B7aVD16535; Tue, 11 May 2004 10:36:31 +0300 Date: Tue, 11 May 2004 10:36:31 +0300 (EEST) From: Pekka Savola To: dnsop@lists.uoregon.edu cc: namedroppers@ops.ietf.org Subject: handling of additional data [Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt] (fwd) Message-ID: 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.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. ] Hi, DNSOP WGLC on draft-ietf-dnsop-ipv6-dns-issues-06.txt is ending in a day or two, and I hope to be able to submit the revision then. With my draft-ietf-dnsop-ipv6-dns-issues editor hat on, I haven't seen much convergence on this issue (and this isn't a show-stopper for this document), so unless there are specific suggestions for changing the section 4.4 of the document, I'll only try to clarify the terminology a bit. See: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-07pre.txt http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-07pre-diff.html Suggestions, etc. of course welcome.. ---------- Forwarded message ---------- Date: Tue, 4 May 2004 12:24:15 +0300 (EEST) From: Pekka Savola To: dnsop@lists.uoregon.edu Subject: handling of additional data [Re: [dnsop] WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt] Hi, Let's take an issue separately from the rest. Me and Jinmei discussed this, but were OK with as it is. However, if WG has clear opinions, now might be time for modifying the text and/or recommiding changes to the additional data processing. As described by ipv6-dns-issues, section 4.4, there are two kinds of additional data: 1. "critical" additional data; this must be included (all the possible RRsets) in all scenarios, and 2. "courtesy" additional data; this could be sent in full, with only a few RRsets, or with no RRsets, and can be fetched separately as well, but which could lead to non-optimal results. [[ see examples of each in the draft.]] Imagine the event where the additional data section would include both A and AAAA RRsets and would be too large, but omitting one RRset would make it small enough. Now, the questions are: A) Is there consensus that it's better to set TC bit than to return only some RRsets of critical additional data? B) Is it better to omit all the courtesy addional data, rather than omit some RRsets? C) (This is relevant if you answered "no" to B) Is it better to set TC bit rather than return only some RRsets with courtesy additional data? Opinions? Discussion? Etc.? As for my personal preference: A) probably yes (not sure). B) yes, omit everything. C) possibly yes, not sure. (Doesn't matter if "yes" to B) -- 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 May 13 10:56: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 KAA17334 for ; Thu, 13 May 2004 10:56:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOHX0-0009rm-QX for namedroppers-data@psg.com; Thu, 13 May 2004 14:49:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOHWo-0009oY-Vs for namedroppers@ops.ietf.org; Thu, 13 May 2004 14:49:43 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i4DElWVZ041671 for ; Thu, 13 May 2004 10:47:32 -0400 (EDT) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i4DElWve041670 for namedroppers@ops.ietf.org; Thu, 13 May 2004 10:47:32 -0400 (EDT) Received: from [207.217.120.228] (helo=mynah.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNvA2-00089F-De for namedroppers@ops.ietf.org; Wed, 12 May 2004 14:56:42 +0000 Received: from pcp09494185pcs.nrockv01.md.comcast.net ([69.140.199.22] helo=STJOHNS-LAPTOP2.mindspring.com) by mynah.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.36 #4) id 1BNvA2-0007sZ-00 for namedroppers@ops.ietf.org; Wed, 12 May 2004 07:56:42 -0700 Message-Id: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 12 May 2004 10:56:48 -0400 To: namedroppers@ops.ietf.org From: Michael StJohns Subject: Fwd: I-D ACTION:draft-stjohns-dnssec-trustupdate-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d5c98dd8862b09390b8d8cc457a57f330350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 [ 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. ] FYI. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Automated Updates of DNSSEC Trust Anchors > Author(s) : M. StJohns > Filename : draft-stjohns-dnssec-trustupdate-00.txt > Pages : 13 > Date : 2004-5-11 > >This document describes a means for automated, authenticated and > authorized updating of DNSSEC "trust anchors". The method provides > protection against single key compromise of a key in the trust point > key set. Based on the trust established by the presence of a current > anchor, other anchors may be added at the same place in the > hierarchy, and, ultimately, supplant the existing anchor. > > This mechanism, if adopted, will require changes to resolver > management behavior (but not resolver resolution behavior), and the > addition of a single flag bit to the DNSKEY record. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-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-stjohns-dnssec-trustupdate-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-stjohns-dnssec-trustupdate-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. >Content-Type: text/plain >Content-ID: <2004-5-12093901.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-stjohns-dnssec-trustupdate-00.txt > > -- to unsubscribe send a message to namedroppers-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 May 13 14:23: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 OAA02540 for ; Thu, 13 May 2004 14:23:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOKll-000KOt-Qq for namedroppers-data@psg.com; Thu, 13 May 2004 18:17:21 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOKlk-000KOX-61 for namedroppers@ops.ietf.org; Thu, 13 May 2004 18:17:20 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 7D27819B480; Thu, 13 May 2004 14:17:17 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id DA8CE19B48D; Thu, 13 May 2004 14:17:10 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1638747; Thu, 13 May 2004 14:14:46 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> References: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> Date: Thu, 13 May 2004 14:14:48 -0400 To: Mark Andrews From: Edward Lewis Subject: Re: handling of additional data (fwd) 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 11:15 +1000 5/11/04, Mark Andrews wrote: >> > Sure there can be circular dependancies. We don't however >> > have to support them if it makes management of the DNS in >> > the whole impossible. We tried it and is was a failure. ... > It means that older nameservers didn't have restrictions > and it ended up being a management nightmare. Been there, > done that, don't want to go there again. Was there ever documentation of that? >> > Stricter rules were needed. Did any of these ever get put into a document? I don't doubt your words, I just want to know if the lessons have been recorded. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 13 15:41: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 PAA08873 for ; Thu, 13 May 2004 15:41:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOM0O-0004lz-5P for namedroppers-data@psg.com; Thu, 13 May 2004 19:36:32 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOM0N-0004lg-81 for namedroppers@ops.ietf.org; Thu, 13 May 2004 19:36:31 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6B0FA13DF0 for ; Thu, 13 May 2004 19:36:30 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: handling of additional data (fwd) In-Reply-To: Message from Edward Lewis of "Thu, 13 May 2004 14:14:48 -0400." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 13 May 2004 19:36:30 +0000 Message-Id: <20040513193630.6B0FA13DF0@sa.vix.com> 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 > > It means that older nameservers didn't have restrictions > > and it ended up being a management nightmare. Been there, > > done that, don't want to go there again. > > Was there ever documentation of that? not in the form of an FYI or BCP, and it appears to have been left out of 2181/2182 as well, but it was discussed on the old dns-security@TIS mailing list back in april of 1994. > >> > Stricter rules were needed. > > Did any of these ever get put into a document? > > I don't doubt your words, I just want to know if the lessons have been > recorded. here you go: -------- From: vixie@vix.com (Paul A Vixie) Newsgroups: local.mail.dns.security Subject: Re: DNS security draft Date: 20 Apr 94 14:47:20 Organization: Vixie Enterprises Lines: 27 Distribution: local Message-ID: References: <9404201528.AA09926@munin.fnal.gov> NNTP-Posting-Host: office.home.vix.com In-reply-to: crawdad@munin.fnal.gov's message of 20 Apr 1994 10:03:42 -0700 >What it boils down to seems to be this. Any resolver or server which >preserves the distinction between authoritative and non-authoritative >(example: glue) data better than BIND does will break the proposed >scheme of cross-authentication of zones. > >[...] BIND as of 4.9 preserves the distinction between authoritative and nonauthoritative data; a future (post-4.9.3) version will probably answer with a NOERROR/referral if a query arrives without RD for a name with non-authoritative matching RR's. as of 4.9 we are already deleting all previous data in a node when more-authoritative info comes in. credibility levels are, in increasing order: additional or authority data nonauthoritative answer authoritative answer authoritative local zone (pri or sec) more details wouldn't be relevant to this thread. i just wanted to keep everybody from believing the BIND is still as brain-dead as it used to be. -- Paul Vixie Redwood City, CA decwrl!vixie!paul -------- -- to unsubscribe send a message to namedroppers-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 May 14 04:02: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 EAA05370 for ; Fri, 14 May 2004 04:02:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOXZc-0009Es-Nv for namedroppers-data@psg.com; Fri, 14 May 2004 07:57:40 +0000 Received: from [131.254.130.26] (helo=smtp.irisa.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOXZb-0009EK-Ap for namedroppers@ops.ietf.org; Fri, 14 May 2004 07:57:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 42DFAFB63; Fri, 14 May 2004 09:57:38 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.130.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23389-10; Fri, 14 May 2004 09:57:37 +0200 (CEST) Received: from irisa.fr (medoc.irisa.fr [131.254.70.2]) by smtp.irisa.fr (Postfix) with ESMTP id BD5C5FB30; Fri, 14 May 2004 09:57:37 +0200 (CEST) Message-ID: <40A47BF1.3030104@irisa.fr> Date: Fri, 14 May 2004 09:57:37 +0200 From: Gilles Guette Organization: Irisa/Inria - Rennes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: fr, en MIME-Version: 1.0 To: Michael StJohns Cc: namedroppers@ops.ietf.org Subject: Comments on draft-stjohns-dnssec-trustupdate-00.txt References: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> In-Reply-To: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at irisa.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 Content-Transfer-Encoding: 7bit Hello, in your draft you say that when a key has the REVOKED bit sets, this key MUST NOT be use as a trust anchor except validating the RRSIG for revocation. And revocation is immediate. In the section 2.2 you say that "The resolver MUST NOT treat a new key as a trust anchor until the hold-down time expires AND it has retrieved the..." So consider the following scenario: A zone with one SEP (SEP1) decides to add a new SEP (SEP2) and revoked the old one. The zone owner sets the revoked bit on SEP1. Your resolver revoked immediatly SEP1 but must not use SEP2 as trust anchor. At this time your resolver has not trust anchor anymore for this zone. Did I miss something? In the last paragraph of section 2.2, you say that "an attacker who holds one compromised key could keep a single resolver from realizing that a key had been compromised by intercepting real data..." But when you compromise a key, you can generate "cryptographically valid" data and pollute caching servers with it. Then there is no need to intercept real trafic. But maybe it is out of scope here. In section 2.4.3 you say that a resolver MUST be able to manage at least five SEP per trust point. Is there a particular reason for this ? I am not sure that many zones have more than two or three SEP. Regards Michael StJohns wrote: > > [ 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. ] > > FYI. > > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Automated Updates of DNSSEC Trust Anchors >> Author(s) : M. StJohns >> Filename : draft-stjohns-dnssec-trustupdate-00.txt >> Pages : 13 >> Date : 2004-5-11 >> >> This document describes a means for automated, authenticated and >> authorized updating of DNSSEC "trust anchors". The method provides >> protection against single key compromise of a key in the trust point >> key set. Based on the trust established by the presence of a current >> anchor, other anchors may be added at the same place in the >> hierarchy, and, ultimately, supplant the existing anchor. >> >> This mechanism, if adopted, will require changes to resolver >> management behavior (but not resolver resolution behavior), and the >> addition of a single flag bit to the DNSKEY record. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-00.txt -- Gilles Guette ARMOR team IRISA/INRIA Rennes France -- to unsubscribe send a message to namedroppers-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 May 14 08:36: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 IAA18231 for ; Fri, 14 May 2004 08:36:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BObrz-000Gqk-QQ for namedroppers-data@psg.com; Fri, 14 May 2004 12:32:55 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BObrw-000Gpb-9o for namedroppers@ops.ietf.org; Fri, 14 May 2004 12:32:52 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i4ECWVkZ021362; Fri, 14 May 2004 08:32:31 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i4ECWK4A026796; Fri, 14 May 2004 08:32:21 -0400 (EDT) From: "Scott Rose" To: "Michael StJohns" Cc: Subject: RE: Comments on draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 08:32:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <40A47BF1.3030104@irisa.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Gilles Guette > So consider the following scenario: > > A zone with one SEP (SEP1) decides to add a new SEP (SEP2) and revoked > the old one. > > The zone owner sets the revoked bit on SEP1. > Your resolver revoked immediatly SEP1 but must not use SEP2 as trust > anchor. At this time your resolver has not trust anchor anymore for this > zone. > > Did I miss something? > I believe both the SEP1 and SEP2 keys are supposed to be active for a time. The overlap allows resolvers (validators) to learn and validate the new SEP key before installing it as a trust anchor. That is the impression I got. I have some comments of my own: meta comment - The DNSSECbis docs have seperated the "resolver" and "validator" roles. Adding some complexity to avoid confusion :) The resolver would learn of the new SEP key, but the validator would be the one that would rollover the trust anchor. Section 2.4.2 "This ensures that at least two DNSKEY RRSets MUST be seen by the resolver..." 2 RRsets? Isn't it one set, with some keys having different flags set? Section 5.1 Should the zone signing key be set at generation time as well? Or is there a specific time that is set? Is there a time when the REVOKE bit is set and the ZSK is cleared (and RRSIGs removed)? Section 6.1 "...decision whether to accept a replacement trust anchor key based on trust for a current trust anchor key..." Sounds confusing, but don't know how to rephrase to make it sound more clear. second para: Why only manual updates? Could that include some automatic method out of band for DNS? I think this is a good draft for consideration on key rollover. It does require allocation of a new bit in the DNSKEY flag field, but that is easy since there is plenty of room. Scott -- to unsubscribe send a message to namedroppers-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 May 14 09:34: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 JAA21943 for ; Fri, 14 May 2004 09:34:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOcls-0007X7-PV for namedroppers-data@psg.com; Fri, 14 May 2004 13:30:40 +0000 Received: from [131.254.130.26] (helo=smtp.irisa.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOclr-0007WS-7q for namedroppers@ops.ietf.org; Fri, 14 May 2004 13:30:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 110C7FC18; Fri, 14 May 2004 15:30:36 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.130.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14026-02; Fri, 14 May 2004 15:30:35 +0200 (CEST) Received: from irisa.fr (medoc.irisa.fr [131.254.70.2]) by smtp.irisa.fr (Postfix) with ESMTP id 8BFCBFB17; Fri, 14 May 2004 15:30:35 +0200 (CEST) Message-ID: <40A4C9FB.9030704@irisa.fr> Date: Fri, 14 May 2004 15:30:35 +0200 From: Gilles Guette Organization: Irisa/Inria - Rennes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: fr, en MIME-Version: 1.0 To: Scott Rose Cc: Michael StJohns , namedroppers@ops.ietf.org Subject: Re: Comments on draft-stjohns-dnssec-trustupdate-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at irisa.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 Content-Transfer-Encoding: 7bit Scott Rose wrote: > >>-----Original Message----- >>From: owner-namedroppers@ops.ietf.org >>[mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Gilles Guette >>So consider the following scenario: >> >>A zone with one SEP (SEP1) decides to add a new SEP (SEP2) and revoked >>the old one. >> >>The zone owner sets the revoked bit on SEP1. >>Your resolver revoked immediatly SEP1 but must not use SEP2 as trust >>anchor. At this time your resolver has not trust anchor anymore for this >>zone. >> >>Did I miss something? >> > > > I believe both the SEP1 and SEP2 keys are supposed to be active for a time. > The overlap allows resolvers (validators) to learn and validate the new SEP > key before installing it as a trust anchor. That is the impression I got. In this case, I think that this model is not suitable for zone files having only one SEP, because if a zone has one SEP and want to change it, the owner of the zone must first create a new SEP and wait 30 days and after revoke the old SEP. In the same way if a zone has 2 SEP (SEP1 and SEP2) and want to change one. The zone owner revoked SEP1 and create SEP3, it is OK but during the next 30 days this zone can not change SEP2 because of the same problem. -- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 14 10:56: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 KAA26544 for ; Fri, 14 May 2004 10:56:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOe2R-0001jn-IB for namedroppers-data@psg.com; Fri, 14 May 2004 14:51:51 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOe2Q-0001jF-8e for namedroppers@ops.ietf.org; Fri, 14 May 2004 14:51:50 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 4481556854; Fri, 14 May 2004 07:51:49 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.0.1.1.2.20040514104439.035c9ec0@pop.mindspring.com> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 14 May 2004 10:51:57 -0400 To: Gilles Guette From: Mike StJohns Subject: Re: Comments on draft-stjohns-dnssec-trustupdate-00.txt Cc: namedroppers@ops.ietf.org In-Reply-To: <40A47BF1.3030104@irisa.fr> References: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> <40A47BF1.3030104@irisa.fr> 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 03:57 AM 5/14/2004, Gilles Guette wrote: >Hello, >in your draft you say that when a key has the REVOKED bit sets, this key >MUST NOT be use as a trust anchor except validating the RRSIG for >revocation. And revocation is immediate. > >In the section 2.2 you say that "The resolver MUST NOT treat a new key as >a trust anchor until the hold-down time expires AND it has retrieved the..." > > >So consider the following scenario: > >A zone with one SEP (SEP1) decides to add a new SEP (SEP2) and revoked the >old one. > >The zone owner sets the revoked bit on SEP1. >Your resolver revoked immediatly SEP1 but must not use SEP2 as trust >anchor. At this time your resolver has not trust anchor anymore for this zone. > >Did I miss something? Nope. You've just wiped out the trust anchors for the zone. That's why the recommendation is for one active, one stand by key. >In the last paragraph of section 2.2, you say that "an attacker who holds >one compromised key could keep a single resolver from realizing that a key >had been compromised by intercepting real data..." > >But when you compromise a key, you can generate "cryptographically valid" >data and pollute caching servers with it. Then there is no need to >intercept real trafic. But maybe it is out of scope here. I think I understand what you're saying. My assumption is that the data in the zone can normally get to the resolvers, but a determined attacker who has managed to compromise a trust anchor key can block and replace traffic headed for only a small set of resolvers (obviously this assumes the attacker hasn't ALSO broken into the zone servers). The design of this mechanism is such that the attacker would need to do this for EVERY transaction during the hold-down time (30 days) to permanently corrupt the one specific server. The moment the resolver sees the revoked key all of that cryptographically valid data goes away. >In section 2.4.3 you say that a resolver MUST be able to manage at least >five SEP per trust point. Is there a particular reason for this ? >I am not sure that many zones have more than two or three SEP. There needed to be some minimum, this one seemed to be reasonable. There needs to be at least three - (revoked, active, standby), having 5 gives you some leeway. -- to unsubscribe send a message to namedroppers-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 May 14 11:22: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 LAA27522 for ; Fri, 14 May 2004 11:22:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOeTZ-0009Ai-Q7 for namedroppers-data@psg.com; Fri, 14 May 2004 15:19:53 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOeTY-0009A0-RS for namedroppers@ops.ietf.org; Fri, 14 May 2004 15:19:52 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id D3D1E56838; Fri, 14 May 2004 08:19:51 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.0.1.1.2.20040514111939.035c9ec0@pop.mindspring.com> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 14 May 2004 11:20:00 -0400 To: Gilles Guette From: Mike StJohns Subject: Re: Comments on draft-stjohns-dnssec-trustupdate-00.txt Cc: namedroppers@ops.ietf.org 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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Resending from a subscribed address.. At 09:30 AM 5/14/2004, Gilles Guette wrote: >>>Did I miss something? >> >>I believe both the SEP1 and SEP2 keys are supposed to be active for a time. >>The overlap allows resolvers (validators) to learn and validate the new SEP >>key before installing it as a trust anchor. That is the impression I got. Yes. Without the add hold down, there's an interesting attack if one of the keys is compromised.. So the zone owner needs to do some preparation by having multiple trust anchors. >In this case, I think that this model is not suitable for zone files >having only one SEP, because if a zone has one SEP and want to change it, >the owner of the zone must first create a new SEP and wait 30 days and >after revoke the old SEP. > >In the same way if a zone has 2 SEP (SEP1 and SEP2) and want to change >one. The zone owner revoked SEP1 and create SEP3, it is OK but during the >next 30 days this zone can not change SEP2 because of the same problem. Correct. Again, the zone owner has to do some prep. You asked in a previous email about the number of keys. For critical zones you may want to have three trust anchors - an active and two stand by (A, B, C). Say C is compromised you can do (A, B, REVOKE(C), D) sign(A,C). The new key set will be A, B, D with A continuing to be the active signer. If A is then compromised before the hold down expires, you do (REVOKE(A), B, REVOKE(C), D, E) sign (A,B,C). At that point you're stuck for at least 30 days until D and E are accepted as trust anchors, but you were able to manage the multiple compromises. (Note that the timer on accepting D was reset once the resolver saw the (REVOKE(A))sign(a)). Later, Mike -- to unsubscribe send a message to namedroppers-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 May 14 11:22: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 LAA27541 for ; Fri, 14 May 2004 11:22:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOeSw-0008wr-F7 for namedroppers-data@psg.com; Fri, 14 May 2004 15:19:14 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOeSv-0008w8-CI for namedroppers@ops.ietf.org; Fri, 14 May 2004 15:19:13 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 6E74156838; Fri, 14 May 2004 08:19:12 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.0.1.1.2.20040514111901.035b6dc8@pop.mindspring.com> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 14 May 2004 11:19:20 -0400 To: "Scott Rose" From: Mike StJohns Subject: RE: Comments on draft-stjohns-dnssec-trustupdate-00.txt Cc: 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 Resending from a subscribed email address... At 08:32 AM 5/14/2004, Scott Rose wrote: >I have some comments of my own: > >meta comment - The DNSSECbis docs have seperated the "resolver" and >"validator" roles. Adding some complexity to avoid confusion :) The >resolver would learn of the new SEP key, but the validator would be the one >that would rollover the trust anchor. I think that's implementation detail. The validator can still get data from the resolver. Is there something specific that should be said? >Section 2.4.2 >"This ensures that at least two DNSKEY RRSets MUST be seen by the >resolver..." 2 RRsets? Isn't it one set, with some keys having different >flags set? Hmm... badly worded. What I meant was that the resolver has to see the new DNSKEY in the RRSet twice - and at least one of those had to be after the expiration of the TTL in which the DNSKEY first appeared. E.g. the resolver has to fetch the DNSKEY RRSet at least twice at different times from the zone servers. >Section 5.1 >Should the zone signing key be set at generation time as well? Or is there >a specific time that is set? Is there a time when the REVOKE bit is set and >the ZSK is cleared (and RRSIGs removed)? My reading of the documents may be confused, but I thought the ZSK was necessary to validate a signature, but there's no requirement that there be associated signatures for any key In any event if the ZSK needs to be set for the SEP bit to be set then I can note that here. >Section 6.1 >"...decision whether to accept a replacement trust anchor key based on trust >for a current trust anchor key..." Sounds confusing, but don't know how to >rephrase to make it sound more clear. I'll look at it again. >second para: >Why only manual updates? Could that include some automatic method out of >band for DNS? Let me change "manual" to "out of band" to correct this. >I think this is a good draft for consideration on key rollover. It does >require allocation of a new bit in the DNSKEY flag field, but that is easy >since there is plenty of room. Thanks. And thanks for the excellent on-the-point comments. Mike -- to unsubscribe send a message to namedroppers-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 May 14 11:42: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 LAA28351 for ; Fri, 14 May 2004 11:42:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOemL-000E6X-Cu for namedroppers-data@psg.com; Fri, 14 May 2004 15:39:17 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOemK-000E6J-FD for namedroppers@ops.ietf.org; Fri, 14 May 2004 15:39:16 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 986B456849; Fri, 14 May 2004 08:39:15 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.0.1.1.2.20040514112017.0340cea8@pop.mindspring.com> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 14 May 2004 11:39:23 -0400 To: Gilles Guette From: Mike StJohns Subject: Re: Fwd: I-D ACTION:draft-stjohns-dnssec-trustupdate-00.txt Cc: namedroppers@ops.ietf.org In-Reply-To: <40A48157.6000606@irisa.fr> References: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> <40A48157.6000606@irisa.fr> 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 04:20 AM 5/14/2004, Gilles Guette wrote: >I think another point should be explain in the draft (maybe only few lines): > >If a zone changes its trusted anchor and your resolver does not querried >this zone during the change. After the change, your resolver is unable to >validate a new trusted anchor and the change must be made manually. Not exactly. Assume two anchors, an active anchor A and a standby anchor B. Assume you're doing a normal rollover (e.g. out with the old, in with the new). At time T you do (A, B, C) sign(A,B). At time T+30 days you do (REVOKE(A),B,C)sign(A,B), at time T+60 or more days you do (B,C)sign(B). At time T+1year its time to rollover B. As long as the resolver has queried the zone at least once during the year its been able to install C as a standby anchor. That actual worry is that you don't query the zone during the time the REVOKE(A) is present and leave A around as an anchor. For zones like the root, it shouldn't be a problem - if you don't query the root in a month you may have other problems. For zones like wildostriches.com it will be more of a problem. OTOH - if you really need wildostriches.com validated you're probably connecting to them fairly often. I'll expand the security consideration section to cover more of this discussion. Thanks - Mike It is possible for a zone owner to totally and completely screw up the trust anchors, but its also as possible for him/her to screw up the signatures. -- to unsubscribe send a message to namedroppers-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 May 14 15:42: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 PAA18197 for ; Fri, 14 May 2004 15:42:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOiWG-00063D-Rd for namedroppers-data@psg.com; Fri, 14 May 2004 19:38:56 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOiWF-00062X-Ef for namedroppers@ops.ietf.org; Fri, 14 May 2004 19:38:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17863; Fri, 14 May 2004 15:38:52 -0400 (EDT) Message-Id: <200405141938.PAA17863@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-nsec-rdata-06.txt Date: Fri, 14 May 2004 15:38:52 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (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.63 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 : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-06.txt Pages : 9 Date : 2004-5-14 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-06.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-nsec-rdata-06.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-nsec-rdata-06.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-5-14154929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-14154929.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 May 14 16:41: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 QAA24060 for ; Fri, 14 May 2004 16:41:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOjSP-000HEs-TK for namedroppers-data@psg.com; Fri, 14 May 2004 20:39:01 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOjSO-000HE5-L3 for namedroppers@ops.ietf.org; Fri, 14 May 2004 20:39:00 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i4EKafVZ048039 for ; Fri, 14 May 2004 16:36:41 -0400 (EDT) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i4EKafIc048038 for namedroppers@ops.ietf.org; Fri, 14 May 2004 16:36:41 -0400 (EDT) Received: from [207.217.120.228] (helo=mynah.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOeG9-0005R6-IY for namedroppers@ops.ietf.org; Fri, 14 May 2004 15:06:01 +0000 Received: from pcp09494185pcs.nrockv01.md.comcast.net ([69.140.199.22] helo=STJOHNS-LAPTOP2.mindspring.com) by mynah.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.36 #4) id 1BOeG4-0000nq-00; Fri, 14 May 2004 08:05:56 -0700 Message-Id: <6.0.1.1.2.20040514105236.03806ec0@pop.mindspring.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 14 May 2004 11:06:02 -0400 To: "Scott Rose" From: Michael StJohns Subject: RE: Comments on draft-stjohns-dnssec-trustupdate-00.txt Cc: In-Reply-To: References: <40A47BF1.3030104@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d2df48f642af5373372467d7732ef2be2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 [ 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. ] At 08:32 AM 5/14/2004, Scott Rose wrote: >I have some comments of my own: > >meta comment - The DNSSECbis docs have seperated the "resolver" and >"validator" roles. Adding some complexity to avoid confusion :) The >resolver would learn of the new SEP key, but the validator would be the one >that would rollover the trust anchor. I think that's implementation detail. The validator can still get data from the resolver. Is there something specific that should be said? >Section 2.4.2 >"This ensures that at least two DNSKEY RRSets MUST be seen by the >resolver..." 2 RRsets? Isn't it one set, with some keys having different >flags set? Hmm... badly worded. What I meant was that the resolver has to see the new DNSKEY in the RRSet twice - and at least one of those had to be after the expiration of the TTL in which the DNSKEY first appeared. E.g. the resolver has to fetch the DNSKEY RRSet at least twice at different times from the zone servers. >Section 5.1 >Should the zone signing key be set at generation time as well? Or is there >a specific time that is set? Is there a time when the REVOKE bit is set and >the ZSK is cleared (and RRSIGs removed)? My reading of the documents may be confused, but I thought the ZSK was necessary to validate a signature, but there's no requirement that there be associated signatures for any key In any event if the ZSK needs to be set for the SEP bit to be set then I can note that here. >Section 6.1 >"...decision whether to accept a replacement trust anchor key based on trust >for a current trust anchor key..." Sounds confusing, but don't know how to >rephrase to make it sound more clear. I'll look at it again. >second para: >Why only manual updates? Could that include some automatic method out of >band for DNS? Let me change "manual" to "out of band" to correct this. >I think this is a good draft for consideration on key rollover. It does >require allocation of a new bit in the DNSKEY flag field, but that is easy >since there is plenty of room. Thanks. And thanks for the excellent on-the-point comments. Mike -- to unsubscribe send a message to namedroppers-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 May 14 17:27: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 QAA24061 for ; Fri, 14 May 2004 16:41:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BOjRy-000H9e-Ud for namedroppers-data@psg.com; Fri, 14 May 2004 20:38:34 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOjRw-000H5E-1V for namedroppers@ops.ietf.org; Fri, 14 May 2004 20:38:32 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i4EKaCVZ048031 for ; Fri, 14 May 2004 16:36:12 -0400 (EDT) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i4EKaCFx048030 for namedroppers@ops.ietf.org; Fri, 14 May 2004 16:36:12 -0400 (EDT) Received: from [207.217.120.228] (helo=mynah.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOeG9-0005R6-IY for namedroppers@ops.ietf.org; Fri, 14 May 2004 15:06:01 +0000 Received: from pcp09494185pcs.nrockv01.md.comcast.net ([69.140.199.22] helo=STJOHNS-LAPTOP2.mindspring.com) by mynah.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.36 #4) id 1BOeG4-0000nq-00; Fri, 14 May 2004 08:05:56 -0700 Message-Id: <6.0.1.1.2.20040514105236.03806ec0@pop.mindspring.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 14 May 2004 11:06:02 -0400 To: "Scott Rose" From: Michael StJohns Subject: RE: Comments on draft-stjohns-dnssec-trustupdate-00.txt Cc: In-Reply-To: References: <40A47BF1.3030104@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d2df48f642af5373372467d7732ef2be2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 [ 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. ] At 08:32 AM 5/14/2004, Scott Rose wrote: >I have some comments of my own: > >meta comment - The DNSSECbis docs have seperated the "resolver" and >"validator" roles. Adding some complexity to avoid confusion :) The >resolver would learn of the new SEP key, but the validator would be the one >that would rollover the trust anchor. I think that's implementation detail. The validator can still get data from the resolver. Is there something specific that should be said? >Section 2.4.2 >"This ensures that at least two DNSKEY RRSets MUST be seen by the >resolver..." 2 RRsets? Isn't it one set, with some keys having different >flags set? Hmm... badly worded. What I meant was that the resolver has to see the new DNSKEY in the RRSet twice - and at least one of those had to be after the expiration of the TTL in which the DNSKEY first appeared. E.g. the resolver has to fetch the DNSKEY RRSet at least twice at different times from the zone servers. >Section 5.1 >Should the zone signing key be set at generation time as well? Or is there >a specific time that is set? Is there a time when the REVOKE bit is set and >the ZSK is cleared (and RRSIGs removed)? My reading of the documents may be confused, but I thought the ZSK was necessary to validate a signature, but there's no requirement that there be associated signatures for any key In any event if the ZSK needs to be set for the SEP bit to be set then I can note that here. >Section 6.1 >"...decision whether to accept a replacement trust anchor key based on trust >for a current trust anchor key..." Sounds confusing, but don't know how to >rephrase to make it sound more clear. I'll look at it again. >second para: >Why only manual updates? Could that include some automatic method out of >band for DNS? Let me change "manual" to "out of band" to correct this. >I think this is a good draft for consideration on key rollover. It does >require allocation of a new bit in the DNSKEY flag field, but that is easy >since there is plenty of room. Thanks. And thanks for the excellent on-the-point comments. Mike -- to unsubscribe send a message to namedroppers-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 May 17 03:20: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 DAA03732 for ; Mon, 17 May 2004 03:20:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BPcIT-000Kie-Nm for namedroppers-data@psg.com; Mon, 17 May 2004 07:12:25 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPcIS-000KiK-My for namedroppers@ops.ietf.org; Mon, 17 May 2004 07:12:24 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id B700242B2 for ; Mon, 17 May 2004 03:12:23 -0400 (EDT) Date: Mon, 17 May 2004 03:12:23 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: New versions of DNSSECbis drafts posted User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040517071223.B700242B2@thrintun.hactrn.net> 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 New versions of the DNSSECbis drafts have just been sent off to the Internet-Drafts coordinator. Copies (and htmlwdiff output) are also available on the web at: http://www.hactrn.net/ietf/dns/dnssec-editors/ We (the editors) -think- we've dealt with all the outstanding substantive issues, including the extensive comments we received from the RIPE "Last Call Workshop" several months ago. Special thanks to Sam Weiler and Jakob Schlyter for helping the editors decypher the portions of the RIPE workshop notes that Mark Andrews hadn't already sorted out for us. As always, please send minor comments to dnssec-editors@east.isi.edu, substantive issues to namedroppers. --Rob (on behalf of your friendly neighborhood DNSSEC editors) -- to unsubscribe send a message to namedroppers-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 May 17 15:41: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 PAA18987 for ; Mon, 17 May 2004 15:41:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BPnvb-00019n-0d for namedroppers-data@psg.com; Mon, 17 May 2004 19:37:35 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPnvZ-00019J-8s for namedroppers@ops.ietf.org; Mon, 17 May 2004 19:37:33 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18771; Mon, 17 May 2004 15:37:31 -0400 (EDT) Message-Id: <200405171937.PAA18771@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-dnssec-protocol-06.txt Date: Mon, 17 May 2004 15:37:30 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (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.63 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 : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-protocol-06.txt Pages : 58 Date : 2004-5-17 This document is part of a family of documents which describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications which add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-06.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-dnssec-protocol-06.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-dnssec-protocol-06.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-5-17155712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-17155712.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 May 17 15:42: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 PAA19130 for ; Mon, 17 May 2004 15:42:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BPnv0-00013h-BX for namedroppers-data@psg.com; Mon, 17 May 2004 19:36:58 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPnuy-00013B-BQ for namedroppers@ops.ietf.org; Mon, 17 May 2004 19:36:56 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18742; Mon, 17 May 2004 15:36:54 -0400 (EDT) Message-Id: <200405171936.PAA18742@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-dnssec-intro-10.txt Date: Mon, 17 May 2004 15:36:54 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (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.63 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 : DNS Security Introduction and Requirements Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-intro-10.txt Pages : 27 Date : 2004-5-17 The Domain Name System Security Extensions (DNSSEC) adds data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-10.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-dnssec-intro-10.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-dnssec-intro-10.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-5-17155659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-17155659.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 May 17 16:27: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 PAA18986 for ; Mon, 17 May 2004 15:41:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BPnw3-0001Fh-Ru for namedroppers-data@psg.com; Mon, 17 May 2004 19:38:03 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPnw1-0001Ep-R6 for namedroppers@ops.ietf.org; Mon, 17 May 2004 19:38:01 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18781; Mon, 17 May 2004 15:37:59 -0400 (EDT) Message-Id: <200405171937.PAA18781@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-dnssec-records-08.txt Date: Mon, 17 May 2004 15:37:59 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (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.63 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 : Resource Records for the DNS Security Extensions Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-records-08.txt Pages : 35 Date : 2004-5-17 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-08.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-dnssec-records-08.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-dnssec-records-08.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-5-17155723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-17155723.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 Tue May 18 02:53: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 CAA18865 for ; Tue, 18 May 2004 02:53:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BPyOp-000Cn0-7A for namedroppers-data@psg.com; Tue, 18 May 2004 06:48:27 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BPyOo-000Cme-3x for namedroppers@ops.ietf.org; Tue, 18 May 2004 06:48:26 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 3D4E54FC2F; Tue, 18 May 2004 08:48:25 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 88A934ECBA for ; Tue, 18 May 2004 08:48:24 +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 SMTP id i4I6mOlT011010 for ; Tue, 18 May 2004 08:48:24 +0200 Date: Tue, 18 May 2004 08:48:24 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: WG Last Call: DNSSEC bis documents Message-Id: <20040518084824.4181bd4d.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.090585 / 0.0 / 0.0 / disabled X-RIPE-Signature: e4e1dd016e64d0ee8803d70c5feee406 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 Dear Colleagues, This message starts the WG last call for the DNSSEC-bis document set. draft-ietf-dnsext-dnssec-intro-10.txt draft-ietf-dnsext-dnssec-proto-06.txt and draft-ietf-dnsext-dnssec-records-08.txt The WG last call will complete June 1 2004. silence will be interpreted as support for forwarding this document set, explicit support of the document set is appreciated. Please report editorial nits directly to . Any protocol issues, not previously addressed, should be brought to the list. Issues that where previously addressed and concluded are out of scope. If this last call does not open new protocol issues we plan to do - if needed - a last round of pure editorial corrections and push the document set to the IESG shortly after. The "html-wdiff" between these and the previous versions of the documents are available on: http://www.hactrn.net/ietf/dns/dnssec-editors/ We would like to extend our gratitude to all those that contributed and to the editors team for doing the thorough job of compiling and introducing the WG input into the docs. Olaf and Olafur DNSEXT WG chairs ------------------------------ Differences from last version and open issues This release covers all 'formal' questions raised on the mailing list and a number of editorial comments that where received both on and off list. At the risk of not being complete we would like to draw your attention to the most significant changes with respect to the previous versions of the documents. The changes are paraphrased, please refer to the text in the I-Ds for the details. Intro: The term 'trust-anchor' has been defined in section 2. It is used throughout the document set, it leaves the choice of a trust anchor being a key or the hash of the key to implementors. A section called "Scope of the DNSSEC Document Set and Last Hop Issues" is introduced (section 5). It explains that the current specifications has its limits in communicating results of the validation process, that further work needs to be done, and that that further work is out of the scope of the document set. Records: The requirements for setting the bitmap for the NSEC RR above a delegation point were not specified. This has been fixed (section 4.1.2 and in proto see above) Proto: The requirements for setting the bitmap for the NSEC RR above a delegation point were not specified. This has been fixed in section 2.3 last paragraph. It has been made explicit that there are no special requirements on servers that receive queries for security RR types which match the content of more than one zone that it serves (section 3) The purpose and use of AD and CD has been clarified (CD bit is in section 3.2.2 and AD is in 3.2.3) It is required that security aware servers and resolvers that implement DNSSEC also implement DNAME processing (section 3.1, 3.2.4 and 4.8). Determining security status was updated to reflect the different states. (section 4.4 matches section 5 of intro) The concept of "Bad Cache" to counter DOS attacks was expanded (section 4.7) -------------------------- message end -------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 18 12:00: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 MAA24543 for ; Tue, 18 May 2004 12:00:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQ6vF-000Osg-6C for namedroppers-data@psg.com; Tue, 18 May 2004 15:54:29 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQ6v8-000Orr-0N for namedroppers@ops.ietf.org; Tue, 18 May 2004 15:54:22 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BQ6v6-00047j-00 for ; Tue, 18 May 2004 17:54:21 +0200 Received: from magenta01.nada.kth.se ([130.237.226.51]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 May 2004 17:54:20 +0200 Received: from jas by magenta01.nada.kth.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 May 2004 17:54:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: WG Last Call: DNSSEC bis documents Date: Tue, 18 May 2004 15:54:17 +0000 (UTC) Lines: 39 Message-ID: References: <20040518084824.4181bd4d.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 130.237.226.51 (Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701) 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 Olaf M. Kolkman ripe.net> writes: > This message starts the WG last call for the DNSSEC-bis document set. > > draft-ietf-dnsext-dnssec-intro-10.txt Quoting the security considerations: DNSSEC introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in sequence to obtain all the names in a zone. While not an attack on the DNS itself, this could allow an attacker to map network hosts or other resources by enumerating the contents of a zone. There are non-DNS protocol means of detecting and limiting this attack beyond the scope of this document set. What are those "non-DNS protocol means of detecting and limiting the attack"? I believe there are no viable means to prevent the attack in reasonable scenarios where DNSSEC is used on the public Internet. If my assessment is correct, I don't think there should be text implying the problem can be taken care of by non-DNS means. If the statement refer to rate limiting and/or counting the number of queries from a certain IP, that is so trivially defeated that I doubt that anyone will go thru the trouble of implementing those precautions for NSEC abuse alone. It may generate more problems than it solve: false positives in the detection logic may disable DNSSEC functionality at end nodes. If the text refer to those precautions, and the text is kept, in fairness a warning that the precaution may cause failures should be added. I believe it would be more honest to simply state that DNSSEC introduce this security vulnerability, full stop. I.e., drop the last sentence. 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 Tue May 18 14:12: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 OAA02691 for ; Tue, 18 May 2004 14:12:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQ90Y-000Ey6-Pz for namedroppers-data@psg.com; Tue, 18 May 2004 18:08:06 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQ90L-000EwD-Ll for namedroppers@ops.ietf.org; Tue, 18 May 2004 18:07:53 +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 i4II7ird008278; Tue, 18 May 2004 19:07:47 +0100 (BST) To: Simon Josefsson cc: namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents In-Reply-To: Message from Simon Josefsson of "Tue, 18 May 2004 15:54:17 -0000." Date: Tue, 18 May 2004 19:07:44 +0100 Message-ID: <8277.1084903664@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Simon" == Simon Josefsson writes: >> DNSSEC introduces the ability for a hostile party to >> enumerate all the names in a zone by following the NSEC >> chain. NSEC RRs assert which names do not exist in a zone >> by linking from existing name to existing name along a >> canonical ordering of all the names within a zone. Thus, an >> attacker can query these NSEC RRs in sequence to obtain all >> the names in a zone. While not an attack on the DNS itself, >> this could allow an attacker to map network hosts or other >> resources by enumerating the contents of a zone. There are >> non-DNS protocol means of detecting and limiting this >> attack beyond the scope of this document set. Simon> I believe there are no viable means to prevent the attack Simon> in reasonable scenarios where DNSSEC is used on the public Simon> Internet. If my assessment is correct, I don't think there Simon> should be text implying the problem can be taken care of by Simon> non-DNS means. The original text should stand IMO. Rate limiting and intelligent firewall filtering can reduce the exposure to NSEC traversal. It should be fairly straightforward to train a name server implementation to detect these attacks too. Sure, these defences might not be much help against a well-disguised attack. But they do provide some level of protection. So there are some non-DNS means of detecting and limiting NSEC traversals that are outwith the scope of the draft. -- to unsubscribe send a message to namedroppers-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 May 18 14:44: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 OAA04758 for ; Tue, 18 May 2004 14:44:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQ9Vr-000JRL-0g for namedroppers-data@psg.com; Tue, 18 May 2004 18:40:27 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQ9Vo-000JQp-3s for namedroppers@ops.ietf.org; Tue, 18 May 2004 18:40:24 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id CA7761078D4; Tue, 18 May 2004 18:40:22 +0000 (GMT) Message-ID: <40AA581F.6070201@algroup.co.uk> Date: Tue, 18 May 2004 19:38:23 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid Cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents References: <8277.1084903664@gromit.rfc1035.com> In-Reply-To: <8277.1084903664@gromit.rfc1035.com> X-Enigmail-Version: 0.83.6.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 Jim Reid wrote: >>>>>>"Simon" == Simon Josefsson writes: > > > >> DNSSEC introduces the ability for a hostile party to > >> enumerate all the names in a zone by following the NSEC > >> chain. NSEC RRs assert which names do not exist in a zone > >> by linking from existing name to existing name along a > >> canonical ordering of all the names within a zone. Thus, an > >> attacker can query these NSEC RRs in sequence to obtain all > >> the names in a zone. While not an attack on the DNS itself, > >> this could allow an attacker to map network hosts or other > >> resources by enumerating the contents of a zone. There are > >> non-DNS protocol means of detecting and limiting this > >> attack beyond the scope of this document set. > > Simon> I believe there are no viable means to prevent the attack > Simon> in reasonable scenarios where DNSSEC is used on the public > Simon> Internet. If my assessment is correct, I don't think there > Simon> should be text implying the problem can be taken care of by > Simon> non-DNS means. > > The original text should stand IMO. > > Rate limiting and intelligent firewall filtering can reduce the > exposure to NSEC traversal. It should be fairly straightforward to > train a name server implementation to detect these attacks too. Sure, > these defences might not be much help against a well-disguised > attack. But they do provide some level of protection. So there are > some non-DNS means of detecting and limiting NSEC traversals that are > outwith the scope of the draft. I believe experience tells us that the people interested in these attacks are highly capable of disguising them well. 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 Tue May 18 15:11: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 PAA07082 for ; Tue, 18 May 2004 15:11:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQ9x4-000NfD-Fn for namedroppers-data@psg.com; Tue, 18 May 2004 19:08:34 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQ9x2-000NeZ-20 for namedroppers@ops.ietf.org; Tue, 18 May 2004 19:08:32 +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 i4IJ8Ord008584; Tue, 18 May 2004 20:08:24 +0100 (BST) To: Ben Laurie cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents In-Reply-To: Message from Ben Laurie of "Tue, 18 May 2004 19:38:23 BST." <40AA581F.6070201@algroup.co.uk> Date: Tue, 18 May 2004 20:08:24 +0100 Message-ID: <8583.1084907304@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ben" == Ben Laurie writes: >> Rate limiting and intelligent firewall filtering can reduce the >> exposure to NSEC traversal. It should be fairly straightforward >> to train a name server implementation to detect these attacks >> too. Sure, these defences might not be much help against a >> well-disguised attack. But they do provide some level of >> protection. So there are some non-DNS means of detecting and >> limiting NSEC traversals that are outwith the scope of the >> draft. Ben> I believe experience tells us that the people interested in Ben> these attacks are highly capable of disguising them well. So what? That doesn't make the original text any less valid. It shouldn't come as a surprise to anyone that there are Bad People on the internet and some of them are remarkably good at covering their tracks. -- to unsubscribe send a message to namedroppers-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 May 18 16:27: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 QAA14076 for ; Tue, 18 May 2004 16:27:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQB5T-0007Gy-Lq for namedroppers-data@psg.com; Tue, 18 May 2004 20:21:19 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQB5S-0007Gg-Cf for namedroppers@ops.ietf.org; Tue, 18 May 2004 20:21:18 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 13:21:13 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 May 2004 13:21:22 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 May 2004 13:21:13 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 13:21:18 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 May 2004 13:20:26 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 May 2004 13:21:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: DNSSEC bis documents Date: Tue, 18 May 2004 13:21:01 -0700 Message-ID: Thread-Topic: WG Last Call: DNSSEC bis documents thread-index: AcQ9DHW9JFuAlY5YT4iFYO1CF9cGywACHIcw From: "Christian Huitema" To: "Jim Reid" , "Ben Laurie" Cc: "Simon Josefsson" , X-OriginalArrivalTime: 18 May 2004 20:21:41.0872 (UTC) FILETIME=[BB458700:01C43D15] 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: quoted-printable > >> Rate limiting and intelligent firewall filtering can reduce the > >> exposure to NSEC traversal. It should be fairly straightforward > >> to train a name server implementation to detect these attacks > >> too. Sure, these defences might not be much help against a > >> well-disguised attack. But they do provide some level of > >> protection. So there are some non-DNS means of detecting and > >> limiting NSEC traversals that are outwith the scope of the > >> draft. >=20 > Ben> I believe experience tells us that the people interested in > Ben> these attacks are highly capable of disguising them well. >=20 > So what? That doesn't make the original text any less valid. Ben is right. Rate limiting is trivially defeated by exploring the domain slowly. The slow-down can be easily compensated by performing several searches in parallel, or by distributing the load among several machines. These techniques are commonly used to scan subnets and ports today.=20 Similarly, firewall filtering is hard to apply if the server intends to publish the information in the first place. -- Christian Huitema -- to unsubscribe send a message to namedroppers-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 May 19 03:52: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 DAA19541 for ; Wed, 19 May 2004 03:52:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQLmn-000Iwq-BJ for namedroppers-data@psg.com; Wed, 19 May 2004 07:46:45 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQLml-000Ivj-Oq for namedroppers@ops.ietf.org; Wed, 19 May 2004 07:46:43 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BQLmk-0004jR-3G; Wed, 19 May 2004 09:46:42 +0200 In-Reply-To: To: "Ben Laurie" , "Simon Josefsson" Cc: namedroppers@ops.ietf.org Subject: RE: WG Last Call: DNSSEC bis documents MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 19 May 2004 09:46:32 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 19.05.2004 09:46:42, Serialize complete at 19.05.2004 09:46:42 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 I concur with Simon and would feel more confortable when dropping the statement "there are non-DNS protocol means [...]". Why "are"? Have we seen some implementation of it? Do we know how practicable it is or how well the problem gets addressed? One could say "there could be non-DNS protocol means..", but that is a non-statement. The problem is there. There is no real solution today. Let's face it. 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: From owner-namedroppers@ops.ietf.org Wed May 19 04:12: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 EAA20635 for ; Wed, 19 May 2004 04:12:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQM9R-000KwM-V6 for namedroppers-data@psg.com; Wed, 19 May 2004 08:10:09 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQM9Q-000Kw4-Ha for namedroppers@ops.ietf.org; Wed, 19 May 2004 08:10:08 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i4J8A5gG010879 for ; Wed, 19 May 2004 10:10:05 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i4J8A5EO010878 for namedroppers@ops.ietf.org; Wed, 19 May 2004 10:10:05 +0200 (CEST) (envelope-from ted) Message-Id: <200405190810.i4J8A5EO010878@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 19 May 2004 10:10:05 +0200 In-Reply-To: "Marcos Sanz/Denic's message as of May 19, 9:53" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: RE: WG Last Call: DNSSEC bis documents X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Marcos Sanz/Denic, on May 19, 9:53, in "RE: WG Last Call: DN ..."] > I concur with Simon and would feel more confortable when dropping the > statement "there are non-DNS protocol means [...]". > > Why "are"? Have we seen some implementation of it? Do we know how > practicable it is or how well the problem gets addressed? One could say > "there could be non-DNS protocol means..", but that is a non-statement. There _are_ implementations to reduce the (privacy-) problems that are aggrevated by zone walking, and there are people actively working on this issue, both from the legal and technical perspective. I think the current text is as good as it gets and propose to keep it as it is now. 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 Wed May 19 04:38: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 EAA21665 for ; Wed, 19 May 2004 04:38:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQMYT-000Mx1-L1 for namedroppers-data@psg.com; Wed, 19 May 2004 08:36:01 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQMYS-000Mwo-Mf for namedroppers@ops.ietf.org; Wed, 19 May 2004 08:36:00 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BQMYR-0005h2-Tx; Wed, 19 May 2004 10:35:59 +0200 In-Reply-To: To: namedroppers@ops.ietf.org Subject: RE: WG Last Call: DNSSEC bis documents MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 19 May 2004 10:35:57 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 19.05.2004 10:35:59, Serialize complete at 19.05.2004 10:35:59 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 > There _are_ implementations to reduce the (privacy-) problems that > are aggrevated by zone walking, Then I am sorry for divulging FUD. Can somebody send a pointer to these existing solutions? 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: From owner-namedroppers@ops.ietf.org Wed May 19 04:47: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 EAA21943 for ; Wed, 19 May 2004 04:47:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQMhx-000NuN-5R for namedroppers-data@psg.com; Wed, 19 May 2004 08:45:49 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQMhw-000Nu7-3c for namedroppers@ops.ietf.org; Wed, 19 May 2004 08:45:48 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i4J8jiTT011237; Wed, 19 May 2004 10:45:44 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i4J8jhdT011236; Wed, 19 May 2004 10:45:43 +0200 (CEST) (envelope-from ted) Message-Id: <200405190845.i4J8jhdT011236@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 19 May 2004 10:45:43 +0200 In-Reply-To: "Marcos Sanz/Denic's message as of May 19, 10:39" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Marcos Sanz/Denic , namedroppers@ops.ietf.org Subject: RE: WG Last Call: DNSSEC bis documents X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Marcos Sanz/Denic, on May 19, 10:39, in "RE: WG Last Call: DN ..."] > > There _are_ implementations to reduce the (privacy-) problems that > > are aggrevated by zone walking, > > Then I am sorry for divulging FUD. Can somebody send a pointer to these > existing solutions? You must have missed my answer to you directly, so I'll repeat it on the list. --- Forwarded mail from ted@NLnetLabs.nl (Ted Lindgreen) >From ted@open.nlnetlabs.nl Wed May 19 10:41:29 2004 Date: Wed, 19 May 2004 10:41:27 +0200 In-Reply-To: "Marcos Sanz/Denic's message as of May 19, 10:19" To: Marcos Sanz/Denic , ted@NLnetLabs.nl (Ted Lindgreen) Subject: RE: WG Last Call: DNSSEC bis documents [Quoting Marcos Sanz/Denic, on May 19, 10:19, in "RE: WG Last Call: DN ..."] > > There _are_ implementations to reduce the (privacy-) problems that > > are aggrevated by zone walking, > > Excuse my ignorance, Ted: can you send me a pointer? I haven't read about > that anytime in namedroppers. Probably right: I don't think it is a protocol issue anyway. As for a pointer, see f.i. the presentation from Bart Boswinkel (CEO of SIDN/.nl) in: http://www.sdl.sri.com/other/dnssec/DNSSEC04MayNL-Info.html As for work done: the main problem is that zonewalking facilitates extracting whois info (zonewalking as such can not be expected to have big legal implications, as DNS-info is intentionally made public; however, whois-info is sensitive in terms of the European privacy legislation, therefore the combination is dangerous). SIDN has put significant effort to make the internet community (in the broad sense) aware of the problem and to work to consensus how to deal with it. Regards, -- ted --- End of forwarded message from ted@NLnetLabs.nl (Ted Lindgreen) -- to unsubscribe send a message to namedroppers-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 May 19 05:07: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 FAA22697 for ; Wed, 19 May 2004 05:07:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQN02-000PeJ-6K for namedroppers-data@psg.com; Wed, 19 May 2004 09:04:30 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQN01-000Pdz-7Z for namedroppers@ops.ietf.org; Wed, 19 May 2004 09:04:29 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BQMzy-0003vn-IX; Wed, 19 May 2004 11:04:27 +0200 In-Reply-To: <200405190845.i4J8jhdT011236@open.nlnetlabs.nl> To: ted@NLnetLabs.nl (Ted Lindgreen) Cc: namedroppers@ops.ietf.org Subject: RE: WG Last Call: DNSSEC bis documents MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 19 May 2004 11:04:23 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 19.05.2004 11:04:26, Serialize complete at 19.05.2004 11:04:26 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 Ted, > As for a pointer, see f.i. the presentation from Bart Boswinkel > (CEO of SIDN/.nl) in: > http://www.sdl.sri.com/other/dnssec/DNSSEC04MayNL-Info.html The presentation is interesting, but I couldn't find any existing technical solution to the NSEC traversal problem there. This was what I was looking for when I asked for a pointer of "non-DNS protocol means of detecting and limitting this attack". > As for work done: the main problem is that zonewalking facilitates > extracting whois info If there is a problem with whois, whois should be fixed. I personally agree with you. But the problem is "a zone can be traversed" and the policy of many registries doesn't allow zone transfer. There, I was looking for a solution. > SIDN has put significant effort to make the internet community > (in the broad sense) aware of the problem and to work to consensus > how to deal with it. No criticism at all on SIDN's work. I am for dropping the sentence. 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: From owner-namedroppers@ops.ietf.org Wed May 19 05:54: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 FAA26248 for ; Wed, 19 May 2004 05:54:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQNit-0003aA-VT for namedroppers-data@psg.com; Wed, 19 May 2004 09:50:51 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQNiq-0003Zu-T8 for namedroppers@ops.ietf.org; Wed, 19 May 2004 09:50:49 +0000 Received: from yxa.extundo.com (localhost.localdomain [127.0.0.1]) by yxa.extundo.com (8.12.11/8.12.11) with ESMTP id i4J9olsq013551 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 May 2004 11:50:48 +0200 Received: (from apache@localhost) by yxa.extundo.com (8.12.11/8.12.1/Submit) id i4J9olvE013550; Wed, 19 May 2004 11:50:47 +0200 X-Authentication-Warning: yxa.extundo.com: apache set sender to jas@extundo.com using -f Received: from 130.237.226.19 (SquirrelMail authenticated user jas); by yxa.extundo.com with HTTP; Wed, 19 May 2004 11:50:47 +0200 (CEST) Message-ID: <33503.130.237.226.19.1084960247.squirrel@130.237.226.19> In-Reply-To: <8277.1084903664@gromit.rfc1035.com> References: Message from Simon Josefsson of "Tue, 18 May 2004 15:54:17 -0000." <8277.1084903664@gromit.rfc1035.com> Date: Wed, 19 May 2004 11:50:47 +0200 (CEST) Subject: Re: WG Last Call: DNSSEC bis documents From: "Simon Josefsson" To: "Jim Reid" Cc: namedroppers@ops.ietf.org User-Agent: SquirrelMail/1.5.1 [CVS] 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.0 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > Rate limiting and intelligent firewall filtering can reduce the > exposure to NSEC traversal. It should be fairly straightforward to > train a name server implementation to detect these attacks too. Sure, > these defences might not be much help against a well-disguised > attack. But they do provide some level of protection. So there are > some non-DNS means of detecting and limiting NSEC traversals that are > outwith the scope of the draft. Then inform the reader that any precautions do not remove the need to worry about the issue, and any such precautions introduce new denial-of-service considerations. Just consider sending spoofed DNS requests from a certain IP address, to trigger the NSEC traversal detection logic, to disable DNSSEC functionality for a specific host. The host could be a DNS cache for a big ISP, thereby disabling DNSSEC functionality for many users. The last sentence of the current paragraph imply the problem can be sufficiently solved by non-DNS means, and I have seen no indication that this is true in general. Until a solution has been fleshed out, I continue to believe that removing the last sentence, that refer to experimental and incomplete precautions, would be preferrable. Second to that, I'd suggest appending the following text, to give the reader some perspective on the effectiveness of those non-DNS means: Note that these non-DNS means do not remove the need to worry about this issue, as at least the currently proposed precautions are trivially defeated. Further, they may introduce new denial of service considerations, where an attacker may disable DNSSEC functionality for a specific host, or a set of hosts behind a specific DNS cache. 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 Wed May 19 07:41: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 HAA02894 for ; Wed, 19 May 2004 07:41:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQPOH-000Cdr-1T for namedroppers-data@psg.com; Wed, 19 May 2004 11:37:41 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQPOD-000Cda-VI for namedroppers@ops.ietf.org; Wed, 19 May 2004 11:37:38 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 0128C10791A for ; Wed, 19 May 2004 11:37:36 +0000 (GMT) Message-ID: <40AB4690.7050606@algroup.co.uk> Date: Wed, 19 May 2004 12:35:44 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Proposal to fix NSEC X-Enigmail-Version: 0.83.6.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 I understand this draft comes very late in the day, but it is also my understanding that it addresses a very crucial issue for registries in the EU and possibly other regions: their obligation to protect registrant data. I am sure that this will cause discussions of both a technical and political nature. I would like to make it clear from the outset that my comments on technical matters are on behalf of Nominet, but political comments are my own - I am not empowered by Nominet to discuss policy issues on their behalf. I know that many of you will be at the DNSSEC deployment workshop in SF on Sunday - both Geoffrey and I will be there and will be happy to discuss this draft with anyone who is interested. http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-00.txt I will, of course, be submitting this to the I-D editor, but because of the nearness of Sunday I thought it best to post it now. 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 Wed May 19 09:00: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 JAA07450 for ; Wed, 19 May 2004 09:00:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQQai-000KY0-Ru for namedroppers-data@psg.com; Wed, 19 May 2004 12:54:36 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQQaf-000KXZ-Nm for namedroppers@ops.ietf.org; Wed, 19 May 2004 12:54:33 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 6A13C107919; Wed, 19 May 2004 12:54:32 +0000 (GMT) Message-ID: <40AB5898.9070104@algroup.co.uk> Date: Wed, 19 May 2004 13:52:40 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <40AB4690.7050606@algroup.co.uk> <20040519122355.GA14215@vacation.karoshi.com.> In-Reply-To: <20040519122355.GA14215@vacation.karoshi.com.> X-Enigmail-Version: 0.83.6.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 bmanning@vacation.karoshi.com wrote: > On Wed, May 19, 2004 at 12:35:44PM +0100, Ben Laurie wrote: > >>I understand this draft comes very late in the day, but it is also my >>understanding that it addresses a very crucial issue for registries in >>the EU and possibly other regions: their obligation to protect >>registrant data. > > > I guess that I remain unconvinced. > What -registrant- data is stored in the DNS? > In most cases, -registrant- data is stored in > some whois-like database. NSEC provides an index to whois. 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 Wed May 19 09:18: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 JAA09589 for ; Wed, 19 May 2004 09:18:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQQvk-000NBd-Th for namedroppers-data@psg.com; Wed, 19 May 2004 13:16:20 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQQvi-000NAF-AV for namedroppers@ops.ietf.org; Wed, 19 May 2004 13:16:18 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i4JDGAVM013514 for ; Wed, 19 May 2004 15:16:10 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i4JDG9f3013513 for namedroppers@ops.ietf.org; Wed, 19 May 2004 15:16:10 +0200 (CEST) (envelope-from ted) Message-Id: <200405191316.i4JDG9f3013513@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 19 May 2004 15:16:09 +0200 In-Reply-To: "Ben Laurie's message as of May 19, 15:02" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Ben Laurie, on May 19, 15:02, in "Re: Proposal to fix ..."] > bmanning@vacation.karoshi.com wrote: ... > > I guess that I remain unconvinced. > > What -registrant- data is stored in the DNS? > > In most cases, -registrant- data is stored in > > some whois-like database. > > NSEC provides an index to whois. That is correct: the whois data is the (privacy legislation) problem, and being able to walk the tree exposes this problem even more, and certainly makes it more visible. However, "fixing NSEC" will not fix the real (whois) problem. -- teds -- to unsubscribe send a message to namedroppers-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 May 19 09:40: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 JAA10917 for ; Wed, 19 May 2004 09:40:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRGX-000Pj4-AT for namedroppers-data@psg.com; Wed, 19 May 2004 13:37:49 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRGP-000PiA-Kv for namedroppers@ops.ietf.org; Wed, 19 May 2004 13:37:41 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i4JDaGkZ007212; Wed, 19 May 2004 09:36:16 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i4JDZs4A001240; Wed, 19 May 2004 09:35:54 -0400 (EDT) From: "Scott Rose" To: "Ben Laurie" , Subject: RE: Proposal to fix NSEC Date: Wed, 19 May 2004 09:35:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <40AB4690.7050606@algroup.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just did a quick first read - Is the NSECINFO RR really necessary? It seems redundant to me and just another RR/RRSIG combo to be placed in the additional section for a negative response. The hash ID could be the first field in the NSEC2 RDATA (just like in DS, RRSIG, etc) - no need for another record to store that. The iterations could be stored there as well, but I don't know how useful it is to begin with. Why is it 3 octets long (odd number btw)? Couldn't it become a DoS attack vector by a malicious or silly admin setting the number arbitrarily high? I also fail to see the use of the salt value in the NSECINFO. The draft states it is there to prevent dictionary attacks. Couldn't an attacker could just get the salt, and then perform the attack? I would recommend dropping the NSECINFO RR altogether and move the digest code and the iterations (though shortening the field to 2 octets) into the NSEC2 RDATA. Although I wouldn't mind dropping the iterations field as well. Please correct me if I am misreading the NSECINFO RR spec. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Ben Laurie > Sent: Wednesday, May 19, 2004 7:36 AM > To: namedroppers@ops.ietf.org > Subject: Proposal to fix NSEC > > > I understand this draft comes very late in the day, but it is also my > understanding that it addresses a very crucial issue for registries in > the EU and possibly other regions: their obligation to protect > registrant data. > > I am sure that this will cause discussions of both a technical and > political nature. I would like to make it clear from the outset that my > comments on technical matters are on behalf of Nominet, but political > comments are my own - I am not empowered by Nominet to discuss policy > issues on their behalf. > > I know that many of you will be at the DNSSEC deployment workshop in SF > on Sunday - both Geoffrey and I will be there and will be happy to > discuss this draft with anyone who is interested. > > http://www.links.org/dnssec/draft-laurie-dnsext-nsec2-00.txt > > I will, of course, be submitting this to the I-D editor, but because of > the nearness of Sunday I thought it best to post it now. > > 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: > -- to unsubscribe send a message to namedroppers-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 May 19 09:42: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 JAA11031 for ; Wed, 19 May 2004 09:42:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRIs-000PyT-Bw for namedroppers-data@psg.com; Wed, 19 May 2004 13:40:14 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRIo-000Pxr-SN for namedroppers@ops.ietf.org; Wed, 19 May 2004 13:40:11 +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 i4JDe4Dt013758 for ; Wed, 19 May 2004 15:40:05 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4JDe3ts002450 for ; Wed, 19 May 2004 15:40:03 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4JDe1h2002447 for ; Wed, 19 May 2004 15:40:03 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 19 May 2004 15:40:01 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <40AB4690.7050606@algroup.co.uk> Message-ID: References: <40AB4690.7050606@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk You're basically bringing back the NO record, with some added jazz: http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt We've already done this 3 years ago and I see no reason in bringing this back. It does not solve a problem (see below). It does not bring anything new. A few notes on the spec: 1) You propose an either/or architectural design. No provisioning for bw compatibility with nsec, nor signalling that a zone/server/resolver/validator/stub supports either/both. You need signalling since the nsec and nsec2 are mutually exclusive. Unless your NSEC2 proposal absoletes NSEC (bring out the flags for flagday), but then its not an 'alternate scheme' like the proposal claims. If you're thinking of signalling, there is no room for signals in NSEC records (been there done that). 2) The wildcard/closest encounter text is broken. The assumption is that even empty (but existing) nodes need a record (EXIST). Which makes them NOT EMPTY (since the type EXIST exists). Not to mention the extra records you have to put up with: every EXIST type needs a sig plus an nsec[2] plus a sig. This assumption is false. Handling wildcards in dnssec is complex. 3) The NSECINFO spec is broken. You can't proof the NSEC type exist, since you need the NSECINFO record to verify NSEC that proofs NSECINFO exist. Thats a circular dependency. In case you're trying to solve zone walking: Zone walking is still possible, hash by hash. An offline dictionary attack (remember that the NSECINFO trick does not work) does the rest. To speed things up, you could brute-force labels with length up to 5 or 6 characters. Cheers, 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 May 19 09:43:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11104 for ; Wed, 19 May 2004 09:43:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRKo-0000EL-58 for namedroppers-data@psg.com; Wed, 19 May 2004 13:42:14 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRKk-0000Dk-3R for namedroppers@ops.ietf.org; Wed, 19 May 2004 13:42:10 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i4JDg34e013790 for ; Wed, 19 May 2004 15:42:03 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i4JDg3dB013789 for namedroppers@ops.ietf.org; Wed, 19 May 2004 15:42:03 +0200 (CEST) (envelope-from ted) Message-Id: <200405191342.i4JDg3dB013789@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 19 May 2004 15:42:03 +0200 In-Reply-To: ""Olaf M. Kolkman"'s message as of May 19, 15:32" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting "Olaf M. Kolkman", on May 18, 8:55, in "WG Last Call: DNSSEC ..."] > > Dear Colleagues, > > This message starts the WG last call for the DNSSEC-bis document set. > > draft-ietf-dnsext-dnssec-intro-10.txt > draft-ietf-dnsext-dnssec-proto-06.txt > and > draft-ietf-dnsext-dnssec-records-08.txt I have carefully read the three documents. On a number of issues, we (NLnet Labs) had some violant discussions, but in all cases we concluded that the solutions and wordings as chosen by the authors were the best possible. I would like to state that I support the document set as is, and thank the authors for the tremendous amount of work they have done. 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 Wed May 19 09:52: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 JAA11413 for ; Wed, 19 May 2004 09:52:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRTK-0001Mn-Un for namedroppers-data@psg.com; Wed, 19 May 2004 13:51:02 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRTF-0001MB-0N for namedroppers@ops.ietf.org; Wed, 19 May 2004 13:50:57 +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 i4JDoord010467; Wed, 19 May 2004 14:50:50 +0100 (BST) To: Ben Laurie cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Ben Laurie of "Wed, 19 May 2004 13:52:40 BST." <40AB5898.9070104@algroup.co.uk> Date: Wed, 19 May 2004 14:50:50 +0100 Message-ID: <10466.1084974650@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ben" == Ben Laurie writes: >> I guess that I remain unconvinced. What -registrant- data is >> stored in the DNS? In most cases, -registrant- data is stored >> in some whois-like database. Ben> NSEC provides an index to whois. If there's a problem with disclosure of whois data, fix whois. [There's already a WG doing precisely that.] Redesigning the DNSSEC protocol to fix a whois problem does not seem to be sensible. -- to unsubscribe send a message to namedroppers-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 May 19 09:53: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 JAA11435 for ; Wed, 19 May 2004 09:53:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRT1-0001IF-0i for namedroppers-data@psg.com; Wed, 19 May 2004 13:50:43 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRSm-0001Gb-C1 for namedroppers@ops.ietf.org; Wed, 19 May 2004 13:50:28 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 8D72D10791A; Wed, 19 May 2004 13:50:27 +0000 (GMT) Message-ID: <40AB65B4.70401@algroup.co.uk> Date: Wed, 19 May 2004 14:48:36 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: In-Reply-To: X-Enigmail-Version: 0.83.6.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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > Just did a quick first read - > > Is the NSECINFO RR really necessary? It seems redundant to me and just > another RR/RRSIG combo to be placed in the additional section for a negative > response. The hash ID could be the first field in the NSEC2 RDATA (just > like in DS, RRSIG, etc) - no need for another record to store that. The > iterations could be stored there as well, but I don't know how useful it is > to begin with. Sure, the reason I stored it as a separate record was because of redundancy, since it has to be the same for the whole zone, but it might indeed make more sense to include it in NSEC2. > Why is it 3 octets long (odd number btw)? 2 was too few, in my view. > Couldn't it > become a DoS attack vector by a malicious or silly admin setting the number > arbitrarily high? Yes, I noted that somewhere, implementations should probably just fail for values locally considered to be too high. > I also fail to see the use of the salt value in the NSECINFO. The draft > states it is there to prevent dictionary attacks. Couldn't an attacker > could just get the salt, and then perform the attack? Its to prevent precomputed dictionary attacks (this is explained in the security considerations). This matters if your zone is worth rescanning frequently. > I would recommend dropping the NSECINFO RR altogether and move the digest > code and the iterations (though shortening the field to 2 octets) into the > NSEC2 RDATA. Although I wouldn't mind dropping the iterations field as > well. I would have no strong objection to moving it. I'm not sure I believe 2 octets is sufficient for iterations, and I don't think dropping iterations is a good idea, since that is how you choose the cost of dictionary attacks. 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 Wed May 19 10:04: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 KAA12112 for ; Wed, 19 May 2004 10:04:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRdd-0002bx-Sf for namedroppers-data@psg.com; Wed, 19 May 2004 14:01:41 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRdX-0002bJ-Kc for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:01:35 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id ADD2FE7E9A; Wed, 19 May 2004 15:01:34 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents Message-Id: <20040519140134.ADD2FE7E9A@mx1.nominet.org.uk> Date: Wed, 19 May 2004 15:01:34 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: > Rate limiting and intelligent firewall filtering can reduce the > exposure to NSEC traversal. It should be fairly straightforward to > train a name server implementation to detect these attacks too. Sure, > these defences might not be much help against a well-disguised > attack. But they do provide some level of protection. So there are > some non-DNS means of detecting and limiting NSEC traversals that are > outwith the scope of the draft. FWIW we've in the last two years weve observed an increase in WHOIS elaboration attempts against whois.nic.uk which employ pools of unsecured WHOIS (and web) proxies, as well as what are probably `botnets'. I suspect that unsecured DNS resolvers are considerably more numerous, and that no suitable rate-limiting mechanisms -- even intelligent ones which might employ advanced pattern analysis -- will be practicable againt NSEC RR enumeration. 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: From owner-namedroppers@ops.ietf.org Wed May 19 10:17: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 KAA13752 for ; Wed, 19 May 2004 10:17:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRr7-00048u-Sw for namedroppers-data@psg.com; Wed, 19 May 2004 14:15:37 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRqt-00047O-Vz for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:15:24 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 36B94A864 for ; Wed, 19 May 2004 14:15:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i4JEFFDq008976; Thu, 20 May 2004 00:15:15 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200405191415.i4JEFFDq008976@drugs.dv.isc.org> To: Ben Laurie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Proposal to fix NSEC In-reply-to: Your message of "Wed, 19 May 2004 12:35:44 +0100." <40AB4690.7050606@algroup.co.uk> Date: Thu, 20 May 2004 00:15:15 +1000 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 sort of thing has already been looked at and rejected. The existing NSEC names also have a useful property in that they provide the wildcard name that would otherwise match the query name. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 19 10:23: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 KAA14573 for ; Wed, 19 May 2004 10:23:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRwc-0004gR-2m for namedroppers-data@psg.com; Wed, 19 May 2004 14:21:18 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRwK-0004f1-41 for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:21:00 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BQRwJ-0001EZ-Bd; Wed, 19 May 2004 16:20:59 +0200 In-Reply-To: To: roy@dnss.ec Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 19 May 2004 16:20:53 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 19.05.2004 16:20:59, Serialize complete at 19.05.2004 16:20:59 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 Roy, > We've already done this 3 years ago and I see no reason in bringing this > back. With all my respects, the reason is on the table: the NSEC traversal problem to be fixed within DNS. Obviously, the notes on the spec you've just submitted have to be addressed. 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: From owner-namedroppers@ops.ietf.org Wed May 19 10:26: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 KAA14790 for ; Wed, 19 May 2004 10:26:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQRyd-0004um-OL for namedroppers-data@psg.com; Wed, 19 May 2004 14:23:23 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQRyE-0004sC-A3 for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:22:58 +0000 Received: from dlv.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 19 May 2004 10:22:57 -0400 id 000FF879.40AB6DC1.00002E5D From: David Blacka Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 10:22:55 -0400 User-Agent: KMail/1.6.2 References: <20040518084824.4181bd4d.olaf@ripe.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405191022.55712.davidb@verisignlabs.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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 18 May 2004 11:54 am, Simon Josefsson wrote: > What are those "non-DNS protocol means of detecting and limiting the > attack"? ... > I believe it would be more honest to simply state that DNSSEC introduce > this security vulnerability, full stop. I.e., drop the last sentence. I, too, would like to see this last sentence dropped, because this sentence provides no useful information. There may or may not be non-DNS means of limiting NSEC walking, but simply stating that they exist somewhere out there in the wide, wide world without providing a pointer to any of them is not helpful to the reader. -- 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 Wed May 19 10:36: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 KAA15753 for ; Wed, 19 May 2004 10:36:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQS8j-0006FU-Nl for namedroppers-data@psg.com; Wed, 19 May 2004 14:33:49 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQS8c-0006D8-Ur for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:33:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AA8AB139A3 for ; Wed, 19 May 2004 14:33:42 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Wed, 19 May 2004 15:16:09 +0200." <200405191316.i4JDG9f3013513@open.nlnetlabs.nl> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 19 May 2004 14:33:42 +0000 Message-Id: <20040519143342.AA8AB139A3@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 > > NSEC provides an index to whois. > ... > However, "fixing NSEC" will not fix the real (whois) problem. > > -- teds i agree with ted. dns is a publication mechanism, and if you don't want something published you probably shouldn't be putting it into dns at all. and, if your only way to keep whois safe is to hide its index, then you have probably got other troubles. parts of the "index" are exposed every day in server logs or in-addr.arpa/ip6.arpa walks. -- to unsubscribe send a message to namedroppers-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 May 19 10:39: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 KAA16076 for ; Wed, 19 May 2004 10:39:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQSCf-0006ee-G8 for namedroppers-data@psg.com; Wed, 19 May 2004 14:37:53 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQSCa-0006eL-8F for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:37:48 +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 i4JEbdrd010614; Wed, 19 May 2004 15:37:39 +0100 (BST) To: ted@NLnetLabs.nl (Ted Lindgreen) cc: namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Wed, 19 May 2004 15:42:03 +0200." <200405191342.i4JDg3dB013789@open.nlnetlabs.nl> Date: Wed, 19 May 2004 15:37:39 +0100 Message-ID: <10613.1084977459@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ted" == Ted Lindgreen writes: Ted> I would like to state that I support the document set as is, Ted> and thank the authors for the tremendous amount of work they Ted> have done. I heartily agree. Gentlemen, please take a bow. We should all shake you warmly by the hand and buy you a drink. Perhaps in San Diego? -- to unsubscribe send a message to namedroppers-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 May 19 10:42: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 KAA16307 for ; Wed, 19 May 2004 10:42:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQSEw-0006wR-Ph for namedroppers-data@psg.com; Wed, 19 May 2004 14:40:14 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQSEa-0006tH-0i for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:39:52 +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 i4JEdKTP014374; Wed, 19 May 2004 16:39:20 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4JEdIPD003968; Wed, 19 May 2004 16:39:18 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4JEdIjc003965; Wed, 19 May 2004 16:39:18 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 19 May 2004 16:39:18 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Marcos Sanz/Denic cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 19 May 2004, Marcos Sanz/Denic wrote: > Roy, > > > We've already done this 3 years ago and I see no reason in bringing this > > back. > > With all my respects, the reason is on the table: > the NSEC traversal problem to be fixed within DNS. NSEC traversal will still exist. hash by hash. Using NSEC2 the attack vector is shifted. From an online dictionary to DNS attack, to an offline, dictionary to NSEC2-hash attack. An obscured circular list is still a circular list. Getting rid of the circular list is a better solution imho, but that has other issues like on the fly signing. private-key stored on an online-box, etc. 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 May 19 10:44: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 KAA16435 for ; Wed, 19 May 2004 10:44:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQSHM-0007Dz-2k for namedroppers-data@psg.com; Wed, 19 May 2004 14:42:44 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQSH8-0007D0-LB for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:42:30 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 4CD7E107919; Wed, 19 May 2004 14:42:29 +0000 (GMT) Message-ID: <40AB71E6.4050103@algroup.co.uk> Date: Wed, 19 May 2004 15:40:38 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: roy@dnss.ec Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <40AB4690.7050606@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.83.6.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 roy@dnss.ec wrote: > > > You're basically bringing back the NO record, with some added jazz: > http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt Correct, though I did reinvent it all on my own :-) > We've already done this 3 years ago and I see no reason in bringing this > back. It does not solve a problem (see below). It does not bring anything > new. > > A few notes on the spec: > > 1) You propose an either/or architectural design. No provisioning for bw > compatibility with nsec, nor signalling that a > zone/server/resolver/validator/stub supports either/both. You need > signalling since the nsec and nsec2 are mutually exclusive. > Unless your NSEC2 proposal absoletes NSEC (bring out the flags for > flagday), but then its not an 'alternate scheme' like the proposal > claims. If you're thinking of signalling, there is no room for > signals in NSEC records (been there done that). Surely the returned RRs could simply be either NSEC or NSEC2, and the resolver chews whichever it gets? > 2) The wildcard/closest encounter text is broken. The assumption is that > even empty (but existing) nodes need a record (EXIST). Which makes them > NOT EMPTY (since the type EXIST exists). Not to mention the extra > records you have to put up with: every EXIST type needs a sig plus an > nsec[2] plus a sig. This assumption is false. Handling wildcards in > dnssec is complex. Why is the assumption false? > 3) The NSECINFO spec is broken. You can't proof the NSEC type exist, since > you need the NSECINFO record to verify NSEC that proofs NSECINFO > exist. Thats a circular dependency. I'm not sure I understand this, but in any case, it has been proposed that the NSECINFO record is rolled into NSEC2, which would certainly remove circularity, if any exists. > In case you're trying to solve zone walking: Zone walking is still > possible, hash by hash. An offline dictionary attack (remember that the > NSECINFO trick does not work) does the rest. To speed things up, you could > brute-force labels with length up to 5 or 6 characters. If we made hashes take, say, 10 ms to compute, then this attack would take nearly a year. This is the point, surely? I'd note that simply querying for a 6 character domain name only takes that kind of CPU time without any attempt to optimise it (i.e. I used dig). 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 Wed May 19 10:47: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 KAA16743 for ; Wed, 19 May 2004 10:47:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQSKA-0007eI-Qy for namedroppers-data@psg.com; Wed, 19 May 2004 14:45:38 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQSK5-0007dB-Kg for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:45:33 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id BA0EE107919; Wed, 19 May 2004 14:45:32 +0000 (GMT) Message-ID: <40AB729D.1020707@algroup.co.uk> Date: Wed, 19 May 2004 15:43:41 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <10466.1084974650@gromit.rfc1035.com> In-Reply-To: <10466.1084974650@gromit.rfc1035.com> X-Enigmail-Version: 0.83.6.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 Jim Reid wrote: >>>>>>"Ben" == Ben Laurie writes: > > > >> I guess that I remain unconvinced. What -registrant- data is > >> stored in the DNS? In most cases, -registrant- data is stored > >> in some whois-like database. > > Ben> NSEC provides an index to whois. > > If there's a problem with disclosure of whois data, fix whois. [There's > already a WG doing precisely that.] Redesigning the DNSSEC protocol to > fix a whois problem does not seem to be sensible. The problem is the _combination_ of NSEC and whois. 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 Wed May 19 10:56: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 KAA17163 for ; Wed, 19 May 2004 10:56:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQSSf-0008mB-W4 for namedroppers-data@psg.com; Wed, 19 May 2004 14:54:25 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQSSR-0008lF-LH for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:54:11 +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 i4JErpxe014530; Wed, 19 May 2004 16:53:51 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4JErntl004446; Wed, 19 May 2004 16:53:49 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4JErniB004443; Wed, 19 May 2004 16:53:49 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 19 May 2004 16:53:49 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ben Laurie cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <40AB71E6.4050103@algroup.co.uk> Message-ID: References: <40AB4690.7050606@algroup.co.uk> <40AB71E6.4050103@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 19 May 2004, Ben Laurie wrote: > roy@dnss.ec wrote: > > > > > > You're basically bringing back the NO record, with some added jazz: > > http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt > > Correct, though I did reinvent it all on my own :-) > > > We've already done this 3 years ago and I see no reason in bringing this > > back. It does not solve a problem (see below). It does not bring anything > > new. > > > > A few notes on the spec: > > > > 1) You propose an either/or architectural design. No provisioning for bw > > compatibility with nsec, nor signalling that a > > zone/server/resolver/validator/stub supports either/both. You need > > signalling since the nsec and nsec2 are mutually exclusive. > > Unless your NSEC2 proposal absoletes NSEC (bring out the flags for > > flagday), but then its not an 'alternate scheme' like the proposal > > claims. If you're thinking of signalling, there is no room for > > signals in NSEC records (been there done that). > > Surely the returned RRs could simply be either NSEC or NSEC2, and the > resolver chews whichever it gets? That means a requirement to implement both. If I just implement either NSEC or NSEC2 in my resolver, one can be used to downgrade the other. > > 2) The wildcard/closest encounter text is broken. The assumption is that > > even empty (but existing) nodes need a record (EXIST). Which makes them > > NOT EMPTY (since the type EXIST exists). Not to mention the extra > > records you have to put up with: every EXIST type needs a sig plus an > > nsec[2] plus a sig. This assumption is false. Handling wildcards in > > dnssec is complex. > > Why is the assumption false? That would be in the dnssec-protocol draft. Empty non-terminals are not special in DNSSEC. > > 3) The NSECINFO spec is broken. You can't proof the NSEC type exist, since > > you need the NSECINFO record to verify NSEC that proofs NSECINFO > > exist. Thats a circular dependency. > > I'm not sure I understand this, but in any case, it has been proposed > that the NSECINFO record is rolled into NSEC2, which would certainly > remove circularity, if any exists. > > > In case you're trying to solve zone walking: Zone walking is still > > possible, hash by hash. An offline dictionary attack (remember that the > > NSECINFO trick does not work) does the rest. To speed things up, you could > > brute-force labels with length up to 5 or 6 characters. > > If we made hashes take, say, 10 ms to compute, then this attack would > take nearly a year. This is the point, surely? I'd note that simply > querying for a 6 character domain name only takes that kind of CPU time > without any attempt to optimise it (i.e. I used dig). I would prefer an offline dictionary attack over a online querying attack if I did not want to leave to much trails. 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 May 19 10:59: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 KAA17713 for ; Wed, 19 May 2004 10:59:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQSV4-00094e-Jo for namedroppers-data@psg.com; Wed, 19 May 2004 14:56:54 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQSUx-00093X-3q for namedroppers@ops.ietf.org; Wed, 19 May 2004 14:56: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 i4JEugrd010655; Wed, 19 May 2004 15:56:42 +0100 (BST) To: Ben Laurie cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Ben Laurie of "Wed, 19 May 2004 15:40:38 BST." <40AB71E6.4050103@algroup.co.uk> Date: Wed, 19 May 2004 15:56:42 +0100 Message-ID: <10654.1084978602@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ben" == Ben Laurie writes: >> still possible, hash by hash. An offline dictionary attack >> (remember that the NSECINFO trick does not work) does the >> rest. To speed things up, you could brute-force labels with >> length up to 5 or 6 characters. Ben> If we made hashes take, say, 10 ms to compute, then this Ben> attack would take nearly a year. This is the point, surely? Ever heard of Moore's law? Or how about writing an M$ worm that can harness most of the world's Windows boxes for a dictionary attack? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 19 12:19: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 MAA21016 for ; Wed, 19 May 2004 12:19:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQTiG-000HKK-Vj for namedroppers-data@psg.com; Wed, 19 May 2004 16:14:36 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQThi-000HGN-LB for namedroppers@ops.ietf.org; Wed, 19 May 2004 16:14:02 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id AA80E10791D; Wed, 19 May 2004 16:14:01 +0000 (GMT) Message-ID: <40AB875B.1040601@algroup.co.uk> Date: Wed, 19 May 2004 17:12:11 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: roy@dnss.ec Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <40AB4690.7050606@algroup.co.uk> <40AB71E6.4050103@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.83.6.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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: > On Wed, 19 May 2004, Ben Laurie wrote: > > >>roy@dnss.ec wrote: >> >>> >>> >>>You're basically bringing back the NO record, with some added jazz: >>>http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt >> >>Correct, though I did reinvent it all on my own :-) >> >> >>>We've already done this 3 years ago and I see no reason in bringing this >>>back. It does not solve a problem (see below). It does not bring anything >>>new. >>> >>>A few notes on the spec: >>> >>>1) You propose an either/or architectural design. No provisioning for bw >>> compatibility with nsec, nor signalling that a >>> zone/server/resolver/validator/stub supports either/both. You need >>> signalling since the nsec and nsec2 are mutually exclusive. >>> Unless your NSEC2 proposal absoletes NSEC (bring out the flags for >>> flagday), but then its not an 'alternate scheme' like the proposal >>> claims. If you're thinking of signalling, there is no room for >>> signals in NSEC records (been there done that). >> >>Surely the returned RRs could simply be either NSEC or NSEC2, and the >>resolver chews whichever it gets? > > > That means a requirement to implement both. Yes. Or we could deprecate NSEC. > If I just implement either > NSEC or NSEC2 in my resolver, one can be used to downgrade the other. > > >>>2) The wildcard/closest encounter text is broken. The assumption is that >>> even empty (but existing) nodes need a record (EXIST). Which makes them >>> NOT EMPTY (since the type EXIST exists). Not to mention the extra >>> records you have to put up with: every EXIST type needs a sig plus an >>> nsec[2] plus a sig. This assumption is false. Handling wildcards in >>> dnssec is complex. >> >>Why is the assumption false? > > > That would be in the dnssec-protocol draft. Empty non-terminals are not > special in DNSSEC. I'll come back to this when I've thought about it more. >>>3) The NSECINFO spec is broken. You can't proof the NSEC type exist, since >>> you need the NSECINFO record to verify NSEC that proofs NSECINFO >>> exist. Thats a circular dependency. >> >>I'm not sure I understand this, but in any case, it has been proposed >>that the NSECINFO record is rolled into NSEC2, which would certainly >>remove circularity, if any exists. >> >> >>>In case you're trying to solve zone walking: Zone walking is still >>>possible, hash by hash. An offline dictionary attack (remember that the >>>NSECINFO trick does not work) does the rest. To speed things up, you could >>>brute-force labels with length up to 5 or 6 characters. >> >>If we made hashes take, say, 10 ms to compute, then this attack would >>take nearly a year. This is the point, surely? I'd note that simply >>querying for a 6 character domain name only takes that kind of CPU time >>without any attempt to optimise it (i.e. I used dig). > > > I would prefer an offline dictionary attack over a online querying attack > if I did not want to leave to much trails. NSEC makes this equally easy, of course, so I don't really see how this is relevant? 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 Wed May 19 12:19: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 MAA21041 for ; Wed, 19 May 2004 12:19:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQTjA-000HUJ-Uf for namedroppers-data@psg.com; Wed, 19 May 2004 16:15:32 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQTiW-000HNr-MN for namedroppers@ops.ietf.org; Wed, 19 May 2004 16:14:52 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id CD2F0107919; Wed, 19 May 2004 16:14:51 +0000 (GMT) Message-ID: <40AB878D.6080203@algroup.co.uk> Date: Wed, 19 May 2004 17:13:01 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid Cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <10654.1084978602@gromit.rfc1035.com> In-Reply-To: <10654.1084978602@gromit.rfc1035.com> X-Enigmail-Version: 0.83.6.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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Reid wrote: >>>>>>"Ben" == Ben Laurie writes: > > > >> still possible, hash by hash. An offline dictionary attack > >> (remember that the NSECINFO trick does not work) does the > >> rest. To speed things up, you could brute-force labels with > >> length up to 5 or 6 characters. > > Ben> If we made hashes take, say, 10 ms to compute, then this > Ben> attack would take nearly a year. This is the point, surely? > > Ever heard of Moore's law? Indeed I have, which is why iterations is a tunable parameter. 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 Wed May 19 12:23: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 MAA21347 for ; Wed, 19 May 2004 12:23:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQTo6-000IIU-7L for namedroppers-data@psg.com; Wed, 19 May 2004 16:20:38 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQTnN-000IAb-NR for namedroppers@ops.ietf.org; Wed, 19 May 2004 16:19:53 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BQTnK-00030T-00 for ; Wed, 19 May 2004 18:19:52 +0200 Received: from grey01.nada.kth.se ([130.237.226.15]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 May 2004 18:19:50 +0200 Received: from jas by grey01.nada.kth.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 May 2004 18:19:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 16:19:48 +0000 (UTC) Lines: 29 Message-ID: References: <10466.1084974650@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 130.237.226.15 (Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701) 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 Jim Reid rfc1035.com> writes: > > >>>>> "Ben" == Ben Laurie algroup.co.uk> writes: > > >> I guess that I remain unconvinced. What -registrant- data is > >> stored in the DNS? In most cases, -registrant- data is stored > >> in some whois-like database. > > Ben> NSEC provides an index to whois. > > If there's a problem with disclosure of whois data, fix whois. [There's > already a WG doing precisely that.] Redesigning the DNSSEC protocol to > fix a whois problem does not seem to be sensible. Right. But designing DNSSEC to not introduce new realistic attack vectors, compared to vanilla DNS, has always appeared sensible to me. Whois is one example of where the new attack vector can be utilized. Improving the whois protocol will remove whois as an example for our discussions, but it will not remove the traversal problem. The alternatives to NSEC do reduce the attack vector into an offline dictionary attack, which I believe is an acceptable risk. Especially considering that online dictionary attacks cannot be prevented fully either. And nobody claims online dictionary attacks is a problem today. Keep in mind that online dictionary attacks are cheaper than offline dictionary attacks. 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 Wed May 19 12:23: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 MAA21381 for ; Wed, 19 May 2004 12:23:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQToR-000ILV-8l for namedroppers-data@psg.com; Wed, 19 May 2004 16:20:59 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQToI-000IKK-Pv for namedroppers@ops.ietf.org; Wed, 19 May 2004 16:20:50 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i4JGKikZ031988 for ; Wed, 19 May 2004 12:20:44 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i4JGKS4A009042 for ; Wed, 19 May 2004 12:20:28 -0400 (EDT) From: "Scott Rose" To: "DNSEXT WG" Subject: RE: Proposal to fix NSEC Date: Wed, 19 May 2004 12:20:28 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov 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 Content-Transfer-Encoding: 7bit I'm trying to fit the EXIST RR into the NSEC response cases in draft-ietf-dnsext-dnssec-proto. I think I understand how the NSEC2 and EXIST combos would work. Only case 2 (no name, no wildcard) would be affected. However, could it be possible to do a EXIST walk of a zone? If EXIST RRs exist at every authoritative name in the zone, it is possible for an attacker to do the same sort of walk just in reverse. For example: in the response in the draft, what if an attacker then queries for "a.b.b.d.e IN A" or similar? assuming they they get a negative answer again, a new closest encloser is given (and another point in the namespace). Scott -- to unsubscribe send a message to namedroppers-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 May 19 12:27: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 MAA21546 for ; Wed, 19 May 2004 12:27:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQTtI-000JFk-FV for namedroppers-data@psg.com; Wed, 19 May 2004 16:26:00 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQTt1-000JDB-MU for namedroppers@ops.ietf.org; Wed, 19 May 2004 16:25:43 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id C964F1078D4; Wed, 19 May 2004 16:25:42 +0000 (GMT) Message-ID: <40AB8A18.2090304@algroup.co.uk> Date: Wed, 19 May 2004 17:23:52 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com Cc: Jim Reid , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <10466.1084974650@gromit.rfc1035.com> <40AB729D.1020707@algroup.co.uk> <20040519160606.GF14591@vacation.karoshi.com.> In-Reply-To: <20040519160606.GF14591@vacation.karoshi.com.> X-Enigmail-Version: 0.83.6.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 bmanning@vacation.karoshi.com wrote: > On Wed, May 19, 2004 at 03:43:41PM +0100, Ben Laurie wrote: >>The problem is the _combination_ of NSEC and whois. > > again, what registrant data is stored in the DNS? > Its clearly -NOT- in the NSEC RR, based on the spec. > > if your concern is the binding of registrant data to > some lable stuck in the DNS, then the problem is not > the DNS or its attendent lables, neither is it the > registrant data. The problem is the -BINDING- between > these two datasets. And that binding is not DNS related. Then clearly it is not whois related either - so what do we fix? -- 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 Wed May 19 13:04: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 NAA24390 for ; Wed, 19 May 2004 13:04:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQURI-000O41-SY for namedroppers-data@psg.com; Wed, 19 May 2004 17:01:08 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQUR2-000O0e-EX for namedroppers@ops.ietf.org; Wed, 19 May 2004 17:00:52 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 36C461078D4; Wed, 19 May 2004 17:00:51 +0000 (GMT) Message-ID: <40AB9255.5060203@algroup.co.uk> Date: Wed, 19 May 2004 17:59:01 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose Cc: DNSEXT WG Subject: Re: Proposal to fix NSEC References: In-Reply-To: X-Enigmail-Version: 0.83.6.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 Scott Rose wrote: > I'm trying to fit the EXIST RR into the NSEC response cases in > draft-ietf-dnsext-dnssec-proto. I think I understand how the NSEC2 and > EXIST combos would work. > > Only case 2 (no name, no wildcard) would be affected. However, could it be > possible to do a EXIST walk of a zone? If EXIST RRs exist at every > authoritative name in the zone, it is possible for an attacker to do the > same sort of walk just in reverse. To be clear, EXISTs only exist where no other RR exists, but I don't think that changes your point. > For example: in the response in the draft, what if an attacker then queries > for "a.b.b.d.e IN A" or similar? assuming they they get a negative answer > again, a new closest encloser is given (and another point in the namespace). Clearly, if they want to know whether one of b.b.d.e, b.d.e, d.e or e exists, it is only a little more expensive to just ask than to discover it by being handed the EXIST record. Paricularly since in practice it is almost always true that the closest encloser will be the name with the first element removed, and will already be known to the attacker. 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 Wed May 19 14:05: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 OAA27747 for ; Wed, 19 May 2004 14:05:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQVNg-0006DD-Ig for namedroppers-data@psg.com; Wed, 19 May 2004 18:01:28 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQVNO-0006B7-8K for namedroppers@ops.ietf.org; Wed, 19 May 2004 18:01:10 +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 i4JI14rd010998; Wed, 19 May 2004 19:01:05 +0100 (BST) To: Simon Josefsson cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Simon Josefsson of "Wed, 19 May 2004 16:19:48 -0000." Date: Wed, 19 May 2004 19:01:04 +0100 Message-ID: <10997.1084989664@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Simon" == Simon Josefsson writes: Simon> Right. But designing DNSSEC to not introduce new realistic Simon> attack vectors, compared to vanilla DNS, has always Simon> appeared sensible to me. Whois is one example of where the Simon> new attack vector can be utilized. Improving the whois Simon> protocol will remove whois as an example for our Simon> discussions, but it will not remove the traversal problem. While this is true, I'm not convinced that there really is a traversal problem. The DNS is a public database after all. Of course some people restrict zone transfers for operational and policy reasons, notably TLDs. But these are not protocol issues. And while it would be nice if DNSSEC didn't make zone traversal easy -- like your now dead NO record draft tried to do -- it's so far been too hard to find a way of doing that which works for all possibilities for authenticated proof of non-existence. If there weren't so many tricky corner cases, especially with wildcards, no doubt something like your NO record would have been incorporated into the current drafts. I think we're at a point with DNSSEC where an engineering decision needs to be made. The question shouldn't be whether DNSSEC is perfect or not but if DNSSEC is "good enough". Simon> The alternatives to NSEC do reduce the attack vector into Simon> an offline dictionary attack, which I believe is an Simon> acceptable risk. If the rewards for a successful attack are high enough, this isn't an acceptable risk. How much would it cost to implement SHA-1 in hardware, assuming there aren't chips that can do this already? -- to unsubscribe send a message to namedroppers-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 May 19 14:10: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 OAA27873 for ; Wed, 19 May 2004 14:10:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQVSZ-0006s9-2y for namedroppers-data@psg.com; Wed, 19 May 2004 18:06:31 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQVSH-0006qC-H9 for namedroppers@ops.ietf.org; Wed, 19 May 2004 18:06:13 +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 i4JI66rd011008; Wed, 19 May 2004 19:06:07 +0100 (BST) To: Ben Laurie cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Ben Laurie of "Wed, 19 May 2004 17:23:52 BST." <40AB8A18.2090304@algroup.co.uk> Date: Wed, 19 May 2004 19:06:06 +0100 Message-ID: <11006.1084989966@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ben" == Ben Laurie writes: >> if your concern is the binding of registrant data to some lable >> stuck in the DNS, then the problem is not the DNS or its >> attendent lables, neither is it the registrant data. The >> problem is the -BINDING- between these two datasets. And that >> binding is not DNS related. Ben> Then clearly it is not whois related either - so what do we fix? The BINDING. Though replacing whois is also attractive. -- to unsubscribe send a message to namedroppers-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 May 19 14:30: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 OAA28764 for ; Wed, 19 May 2004 14:30:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQVna-0009m2-1V for namedroppers-data@psg.com; Wed, 19 May 2004 18:28:14 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQVnN-0009kH-T4 for namedroppers@ops.ietf.org; Wed, 19 May 2004 18:28:02 +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 i4JIS0Bb002264 for ; Wed, 19 May 2004 20:28:00 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4JIS0703040 for ; Wed, 19 May 2004 20:28:00 +0200 (MEST) Message-Id: <200405191828.i4JIS0703040@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: Proposal to fix NSEC In-reply-to: Your message of "Wed, 19 May 2004 19:01:04 BST." <10997.1084989664@gromit.rfc1035.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: <3035.1084991278.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 19 May 2004 20:28:00 +0200 From: Peter Koch 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 Jim reid wrote: > While this is true, I'm not convinced that there really is a traversal > problem. The DNS is a public database after all. Of course some people Jim, you know I'm all with you here and I've been arguing for years that AXFR restrictions are not a security but an obscurity measure. > restrict zone transfers for operational and policy reasons, notably They've done it due to BIND (and other products) introducing the ability and due to "security consultants" recommending it and for other non-reasons. If it were only for those I'd say: go, do your homework. But as always, some animals are more equal than others and in this case they have a point. Being able to list all registered/delegated names is different from serving a name upon request. And while we seem to agree that the data is public, the compilation may not. > TLDs. But these are not protocol issues. And while it would be nice if Well, you're right, the DNS wasn't built to keep things secret but instead to publish data. But now we have a "feature" that has been an (unspoken) part of the system for years, which has a value for a limited but important set of zones and it's going to go away. > I think we're at a point with DNSSEC where an engineering decision > needs to be made. The question shouldn't be whether DNSSEC is perfect > or not but if DNSSEC is "good enough". The problem is that the engineering question is closely coupled to an operational or maybe even policy question for a key part of the infrastructure. If DNSSEC isn't "good enough" for TLD zones (or a significant subset of those), that's a show stopper. Yes, we could have had this discussion earlier. > Simon> The alternatives to NSEC do reduce the attack vector into > Simon> an offline dictionary attack, which I believe is an > Simon> acceptable risk. > > If the rewards for a successful attack are high enough, this isn't an > acceptable risk. How much would it cost to implement SHA-1 in > hardware, assuming there aren't chips that can do this already? There are other alternatives, including online signing, maybe with a different key. The zones in question have some special properties (almost "NS only"), which may also be exploited to find a solution. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 19 15:00: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 PAA01261 for ; Wed, 19 May 2004 15:00:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQWG8-000DRG-Et for namedroppers-data@psg.com; Wed, 19 May 2004 18:57:44 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQWG5-000DQq-LS for namedroppers@ops.ietf.org; Wed, 19 May 2004 18:57:41 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i4JIvPkZ020586 for ; Wed, 19 May 2004 14:57:25 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i4JIur4A028370 for ; Wed, 19 May 2004 14:56:53 -0400 (EDT) From: "Scott Rose" To: "DNSEXT WG" Subject: RE: Proposal to fix NSEC Date: Wed, 19 May 2004 14:56:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <40AB9255.5060203@algroup.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov 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 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ben Laurie [mailto:ben@algroup.co.uk] > > > > Only case 2 (no name, no wildcard) would be affected. However, > could it be > > possible to do a EXIST walk of a zone? If EXIST RRs exist at every > > authoritative name in the zone, it is possible for an attacker to do the > > same sort of walk just in reverse. > > To be clear, EXISTs only exist where no other RR exists, but I don't > think that changes your point. > Then I don't believe I understand where the EXIST RR would be in a zone. For example, in a flat zone (all authoritative names in the zone are ".example.com." and no wildcards. Is there only one EXIST RR (saying "example.com IN EXIST"), or multiple? Or is generated and signed on the fly? Bringing back Roy's comment on the wildcard clarification and the DNSSECbis protocol draft, I think Sections 4 and 5 would need to be updated. Specifically, the response in the example in section 5 would not need NSEC2 RRset (b). Scott -- to unsubscribe send a message to namedroppers-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 May 19 15:48: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 PAA08535 for ; Wed, 19 May 2004 15:48:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQX00-000IWh-DC for namedroppers-data@psg.com; Wed, 19 May 2004 19:45:08 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQWzz-000IWQ-9e for namedroppers@ops.ietf.org; Wed, 19 May 2004 19:45:07 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 2BA151078D4; Wed, 19 May 2004 19:45:06 +0000 (GMT) Message-ID: <40ABB94C.5070509@algroup.co.uk> Date: Wed, 19 May 2004 20:45:16 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Enigmail-Version: 0.83.6.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 Peter Koch wrote: > Jim reid wrote: >>If the rewards for a successful attack are high enough, this isn't an >>acceptable risk. How much would it cost to implement SHA-1 in >>hardware, assuming there aren't chips that can do this already? > > > There are other alternatives, including online signing, maybe with a > different key. The zones in question have some special properties (almost > "NS only"), which may also be exploited to find a solution. I have hesitated to suggest alternatives that include online signing, because of the principle that private keys should not be exposed by putting them on connected machines. However, it is definitely worth saying that online signing would completely eliminate traversal. 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 Wed May 19 15:49: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 PAA08680 for ; Wed, 19 May 2004 15:49:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQX1q-000Ii2-ID for namedroppers-data@psg.com; Wed, 19 May 2004 19:47:02 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQX1o-000Ihe-Jk for namedroppers@ops.ietf.org; Wed, 19 May 2004 19:47:00 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id E7F631078D4; Wed, 19 May 2004 19:46:59 +0000 (GMT) Message-ID: <40ABB9BE.5010205@algroup.co.uk> Date: Wed, 19 May 2004 20:47:10 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose Cc: DNSEXT WG Subject: Re: Proposal to fix NSEC References: In-Reply-To: X-Enigmail-Version: 0.83.6.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=AWL,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: Ben Laurie [mailto:ben@algroup.co.uk] >> >>>Only case 2 (no name, no wildcard) would be affected. However, >> >>could it be >> >>>possible to do a EXIST walk of a zone? If EXIST RRs exist at every >>>authoritative name in the zone, it is possible for an attacker to do the >>>same sort of walk just in reverse. >> >>To be clear, EXISTs only exist where no other RR exists, but I don't >>think that changes your point. >> > > > Then I don't believe I understand where the EXIST RR would be in a zone. > For example, in a flat zone (all authoritative names in the zone are > ".example.com." and no wildcards. Is there only one EXIST RR > (saying "example.com IN EXIST"), or multiple? Or is generated and signed > on the fly? There would be none, since, presumably, there would be at least one other RR for example.com (e.g. SOA). It is absolutely not generated and signed on the fly. > Bringing back Roy's comment on the wildcard clarification and the DNSSECbis > protocol draft, I think Sections 4 and 5 would need to be updated. > Specifically, the response in the example in section 5 would not need NSEC2 > RRset (b). Are you referring to sections 4 and 5 of DNSSECbis? Or of NSEC2? 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 Wed May 19 15:58: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 PAA09298 for ; Wed, 19 May 2004 15:58:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQXAL-000Jog-Mb for namedroppers-data@psg.com; Wed, 19 May 2004 19:55:49 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQXAK-000JoE-G4 for namedroppers@ops.ietf.org; Wed, 19 May 2004 19:55:48 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i4JJsXCs018320; Wed, 19 May 2004 15:54:33 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i4JJs74A003950; Wed, 19 May 2004 15:54:07 -0400 (EDT) From: "Scott Rose" To: "Ben Laurie" Cc: "DNSEXT WG" Subject: RE: Proposal to fix NSEC Date: Wed, 19 May 2004 15:54:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <40ABB9BE.5010205@algroup.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov 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 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ben Laurie [mailto:ben@algroup.co.uk] > > > Bringing back Roy's comment on the wildcard clarification and > the DNSSECbis > > protocol draft, I think Sections 4 and 5 would need to be updated. > > Specifically, the response in the example in section 5 would > not need NSEC2 > > RRset (b). > > Are you referring to sections 4 and 5 of DNSSECbis? Or of NSEC2? > Sections 4 and 5 in the NSEC2 draft first, the eventually the DNSSECbis docset if NSEC2 is adopted. With the wildcard clarification work Ed Lewis started a while back, it makes it easier to understand wildcards and denial of existance responses. Scott > 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 Wed May 19 16:00: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 QAA09720 for ; Wed, 19 May 2004 16:00:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQXCd-000K4H-HY for namedroppers-data@psg.com; Wed, 19 May 2004 19:58:11 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQXCc-000K3j-25 for namedroppers@ops.ietf.org; Wed, 19 May 2004 19:58:10 +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 i4JJw2Zl016549; Wed, 19 May 2004 21:58:02 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4JJw0V1012203; Wed, 19 May 2004 21:58:00 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4JJw0fq012200; Wed, 19 May 2004 21:58:00 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 19 May 2004 21:58:00 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ben Laurie cc: Peter Koch , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <40ABB94C.5070509@algroup.co.uk> Message-ID: References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> <40ABB94C.5070509@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 19 May 2004, Ben Laurie wrote: > Peter Koch wrote: > > > > There are other alternatives, including online signing, maybe with a > > different key. The zones in question have some special properties (almost > > "NS only"), which may also be exploited to find a solution. > > I have hesitated to suggest alternatives that include online signing, > because of the principle that private keys should not be exposed by > putting them on connected machines. A ssh/tls/ipsec capable machines have a private key on connected machines. > However, it is definitely worth saying that online signing would > completely eliminate traversal. Definitly. 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 May 19 18:49: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 SAA26356 for ; Wed, 19 May 2004 18:49:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQZnY-0009g3-2h for namedroppers-data@psg.com; Wed, 19 May 2004 22:44:28 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQZnX-0009fr-7O for namedroppers@ops.ietf.org; Wed, 19 May 2004 22:44:27 +0000 Received: by shell-ng.nominum.com (Postfix, from userid 1411) id 44B7556849; Wed, 19 May 2004 15:44:26 -0700 (PDT) To: Ben Laurie Cc: Peter Koch , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> <40ABB94C.5070509@algroup.co.uk> From: Bob Halley Date: 19 May 2004 15:44:26 -0700 In-Reply-To: <40ABB94C.5070509@algroup.co.uk> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie writes: > I have hesitated to suggest alternatives that include online signing, > because of the principle that private keys should not be exposed by > putting them on connected machines. However, it is definitely worth > saying that online signing would completely eliminate traversal. The problems with online signing are: It's a CPU burden for the authoritative nameserver. You must trust your slaves enough to give them the right to make signatures. In the standard DNSSEC model, a rogue slave can deny service, but it cannot generate authenticated zone content. You have to have some kind of security relationship with all of your slaves, either to give them the online signing private key or to otherwise authenticate the key they are using for online signatures. -- to unsubscribe send a message to namedroppers-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 May 19 19:41: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 TAA29266 for ; Wed, 19 May 2004 19:41:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQadc-000EoG-2z for namedroppers-data@psg.com; Wed, 19 May 2004 23:38:16 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQada-000Enl-7J for namedroppers@ops.ietf.org; Wed, 19 May 2004 23:38:14 +0000 Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i4JNbw012243; Thu, 20 May 2004 06:37:58 +0700 (ICT) Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i4JNbvDB000733; Thu, 20 May 2004 06:37:57 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i4JNWixG004265; Thu, 20 May 2004 06:32:46 +0700 (ICT) From: Robert Elz To: Peter Koch cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 May 2004 06:32:44 +0700 Message-ID: <19443.1085009564@munnari.OZ.AU> 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 Date: Wed, 19 May 2004 20:28:00 +0200 From: Peter Koch Message-ID: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> | But as always, some animals are more equal than others and in this case | they have a point. Being able to list all registered/delegated names is | different from serving a name upon request. And while we seem to agree that | the data is public, the compilation may not. Both are public data. Remember the history of the DNS please. The DNS is just a more scalable and manageable (and flexible) replacement for the HOSTS.TXT file, a single file, listing everything, available to everyone. If the data aren't meant to be public, they simply should not be in the DNS. [I truly hate that "data" is plural.] Playing around with the protocols to attempt to make it harder to find this public data is just plain crazy. If there is data in whois that shouldn't be public, it ought be removed from whois - or whois ought to be secured. Neither the DNS, nor DNSSEC is in any way related to that. kre ps: the section in question in the security considerations shouldn't be there at all - not just the final sentence of it, the whole thing. There is no security implication in being able to find out the names in a DNS zone file. That's the point of the DNS. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 19 20: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 UAA00111 for ; Wed, 19 May 2004 20:00:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQax7-000H1p-NH for namedroppers-data@psg.com; Wed, 19 May 2004 23:58:25 +0000 Received: from [202.12.29.59] (helo=apnic.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQax3-000H16-WC for namedroppers@ops.ietf.org; Wed, 19 May 2004 23:58:22 +0000 Received: from apnic.net (durian.apnic.net [202.12.29.252]) by apnic.net (8.12.8/8.12) with SMTP id i4JNwJ6J020534; Thu, 20 May 2004 09:58:19 +1000 Date: Thu, 20 May 2004 09:58:19 +1000 From: George Michaelson To: Robert Elz Cc: Peter Koch , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-Id: <20040520095819.2bf390ca@garlic> In-Reply-To: <19443.1085009564@munnari.OZ.AU> References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> <19443.1085009564@munnari.OZ.AU> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.9.10claws47 (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 On Thu, 20 May 2004 06:32:44 +0700 Robert Elz wrote: >If there is data in whois that shouldn't be public, it ought be removed >from whois - or whois ought to be secured. Neither the DNS, nor DNSSEC is >in any way related to that. > >kre Both ARIN and APNIC have recently passed policy changes to support higher levels of data 'hiding' in whois, because of various national privacy laws. In APNIC, we intend implementing this via our portal services, with minimal schema changes to WHOIS: data will just stop appearing under the resource holders control (the one who gets it from us, that is: downstreams may not have direct control over this) There is a dynamic tension between an ISP/LIR's desire to expose their downstream allocations (eg to direct abuse complaints to the nearest responsible party) and to meet some classes of users legitimate request not to have their personal contact details published. Its likely that CRISP is going to provide similar features, to selectively mask or opaque parts of the dataset which currently comes from WHOIS or like services. cheers -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3858 3150 | Australia Fax: +61 7 3858 3199 | http://www.apnic.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: From owner-namedroppers@ops.ietf.org Thu May 20 04:18: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 EAA04550 for ; Thu, 20 May 2004 04:18:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQifM-000LTG-Am for namedroppers-data@psg.com; Thu, 20 May 2004 08:12:36 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQifL-000LT3-CZ for namedroppers@ops.ietf.org; Thu, 20 May 2004 08:12:35 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 0B7F61078D4; Thu, 20 May 2004 08:12:34 +0000 (GMT) Message-ID: <40AC68F1.8030309@algroup.co.uk> Date: Thu, 20 May 2004 09:14:41 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: roy@dnss.ec Cc: Peter Koch , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> <40ABB94C.5070509@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.83.6.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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: > On Wed, 19 May 2004, Ben Laurie wrote: > > >>Peter Koch wrote: >> >>>There are other alternatives, including online signing, maybe with a >>>different key. The zones in question have some special properties (almost >>>"NS only"), which may also be exploited to find a solution. >> >>I have hesitated to suggest alternatives that include online signing, >>because of the principle that private keys should not be exposed by >>putting them on connected machines. > > > A ssh/tls/ipsec capable machines have a private key on connected > machines. I didn't intend to suggest it was a general principle, more that it was a DNSSEC principle. It seems to me that DNSSEC is fortunate in that it is possible to do its job without online keys, and it makes sense to try to preserve that good fortune. 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 Thu May 20 04:47: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 EAA05676 for ; Thu, 20 May 2004 04:47:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQj9q-000P8m-Ka for namedroppers-data@psg.com; Thu, 20 May 2004 08:44:06 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQj9p-000P8Y-D3 for namedroppers@ops.ietf.org; Thu, 20 May 2004 08:44:05 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BQj9o-0006T3-K2; Thu, 20 May 2004 10:44:04 +0200 In-Reply-To: <19443.1085009564@munnari.OZ.AU> To: Robert Elz Cc: namedroppers@ops.ietf.org, Peter Koch Subject: Re: Proposal to fix NSEC MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Thu, 20 May 2004 10:43:58 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 20.05.2004 10:44:04, Serialize complete at 20.05.2004 10:44:04 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 > | different from serving a name upon request. And while we seem to agree that > | the data is public, the compilation may not. > > Both are public data. Again, the compilation may not be public. That is an *actual fact* in the case of many TLDs. Could we stop declaring this as a non-problem? We'd have two ways to go: a) We face it's a problem, live with it and *say so* in the actual drafts. b) We invest our discussing energy in the NSEC2 proposal (or NO, or any other) to fix whatever is broken. > If there is data in whois that shouldn't be public, it ought be removed > from whois - or whois ought to be secured. Neither the DNS, nor DNSSEC is > in any way related to that. Simon just said it: fixing whois will remove whois from the examples, but won't remove the traversal problem. 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: From owner-namedroppers@ops.ietf.org Thu May 20 05:45: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 FAA08329 for ; Thu, 20 May 2004 05:45:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQk3Z-0006DR-PS for namedroppers-data@psg.com; Thu, 20 May 2004 09:41:41 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQk3Y-0006DA-Ck for namedroppers@ops.ietf.org; Thu, 20 May 2004 09:41:40 +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 i4K9fUrd017970; Thu, 20 May 2004 10:41:32 +0100 (BST) To: Marcos Sanz/Denic cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Marcos Sanz/Denic of "Thu, 20 May 2004 10:43:58 +0200." Date: Thu, 20 May 2004 10:41:30 +0100 Message-ID: <17969.1085046090@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic writes: Marcos> a) We face it's a problem, live with it and *say so* in Marcos> the actual drafts. b) We invest our discussing energy in Marcos> the NSEC2 proposal (or NO, or any other) to fix whatever Marcos> is broken. There's also (c) provide a clear definition of the "problem" and get consensus that it really is a problem. Once that's been done, we can have a discussion about (a) or (b). As far as I can see, the case that there are technical problems with zone traversal has still to be made. All we've had so far are fluffy layer 9 things about compilation copyright or indexes into whois that might cause disclosure of personal data in the whois database. These are nothing to do with the DNS protocol and can't be solved there IMO. So could somebody please tell us -- or me at any rate -- what are the technical DNS protocol problems with zone traversal? I'd really like to know what problem we're being asked to solve. It would be good to get this established before there is any analysis of the possible solutions. -- to unsubscribe send a message to namedroppers-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 May 20 06: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 GAA09979 for ; Thu, 20 May 2004 06:28:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQkkY-000Bq1-MT for namedroppers-data@psg.com; Thu, 20 May 2004 10:26:06 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQkkU-000BnW-9y for namedroppers@ops.ietf.org; Thu, 20 May 2004 10:26:02 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4KAPxlZ008875 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 20 May 2004 10:26:01 GMT (envelope-from roy+dated+1087640824.9a9ffe@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4KAPvso017179 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 20 May 2004 11:25:59 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4KAR4uq062762 for ; Thu, 20 May 2004 11:27:04 +0100 (BST) (envelope-from roy+dated+1087640824.9a9ffe@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4KAR43U062761 for namedroppers@ops.ietf.org; Thu, 20 May 2004 11:27:04 +0100 (BST) (envelope-from roy+dated+1087640824.9a9ffe@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 20 May 2004 11:27:03 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16556.34807.204862.570446@giles.gnomon.org.uk> Date: Thu, 20 May 2004 11:27:03 +0100 To: Jim Reid Cc: Marcos Sanz/Denic , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <17969.1085046090@gromit.rfc1035.com> References: <17969.1085046090@gromit.rfc1035.com> 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-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 >>>>> "Jim" == Jim Reid writes: Jim> There's also (c) provide a clear definition of the "problem" I thought this had already been stated in this thread. Currently, the DNS allows the operator of an authoritative nameserver to permit unauthenticated queries, but to deny enumeration of the zone to unauthenticated parties. With DNSSEC, this is not possible. If you allow queries then you allow enumeration. This is a technical change: specifically, the authentication model is now less fine-grained than it used to be. Whether this technical change constitutes a problem would seem to depend on the legal and policy framework in which the nameserver is operating, but it would appear that at least some ccTLDs in EU states are concerned that this technical change _might_ raise legal or policy issues that _might_ be a barrier to deployment... -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 May 20 07:10: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 HAA11412 for ; Thu, 20 May 2004 07:10:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQlON-000GiU-6u for namedroppers-data@psg.com; Thu, 20 May 2004 11:07:15 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQlOJ-000Ghp-W1 for namedroppers@ops.ietf.org; Thu, 20 May 2004 11:07:12 +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 i4KB71rd018096; Thu, 20 May 2004 12:07:01 +0100 (BST) To: Roy Badami cc: Marcos Sanz/Denic , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Roy Badami of "Thu, 20 May 2004 11:27:03 BST." <16556.34807.204862.570446@giles.gnomon.org.uk> Date: Thu, 20 May 2004 12:07:00 +0100 Message-ID: <18095.1085051220@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Badami writes: Roy> I thought this had already been stated in this thread. Well I think it hasn't. :-) Roy> Currently, the DNS allows the operator of an authoritative Roy> nameserver to permit unauthenticated queries, but to deny Roy> enumeration of the zone to unauthenticated parties. Roy> With DNSSEC, this is not possible. If you allow queries then Roy> you allow enumeration. This is already known. Now why do some people believe that this enumeration is a *technical* problem? What, specifically, are the technical protocol problems that arise from this? If there's a layer-9 problem about compilation copyright or whatever, that needs to be solved at layer-9, not here. In fact it can't be solved here. BTW, enumeration of an unsigned zone by unauthorised parties is theoretically possible. DNSSEC just makes this theoretical concern a practical possibility. -- to unsubscribe send a message to namedroppers-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 May 20 07:22: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 HAA12261 for ; Thu, 20 May 2004 07:22:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQlbP-000ITl-8F for namedroppers-data@psg.com; Thu, 20 May 2004 11:20:43 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQlbM-000ITM-3h for namedroppers@ops.ietf.org; Thu, 20 May 2004 11:20:40 +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 i4KBKXrd018120; Thu, 20 May 2004 12:20:33 +0100 (BST) To: Roy Badami cc: Marcos Sanz/Denic , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Roy Badami of "Thu, 20 May 2004 11:27:03 BST." <16556.34807.204862.570446@giles.gnomon.org.uk> Date: Thu, 20 May 2004 12:20:33 +0100 Message-ID: <18119.1085052033@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Badami writes: Roy> Whether this technical change constitutes a problem would Roy> seem to depend on the legal and policy framework in which the Roy> nameserver is operating, but it would appear that at least Roy> some ccTLDs in EU states are concerned that this technical Roy> change _might_ raise legal or policy issues that _might_ be a Roy> barrier to deployment... I must have taken extra stupid pills this morning. I don't understand this. Data in the DNS is public. That's why it's there. So if some jurisdiction says public data shouldn't be disclosed, then that data shouldn't be in the DNS. End of story. I'm confused. Earlier on this thread, somebody said NSEC records could be used as an index into a TLD's whois database. Fine. But how could the legal and policy framework where a name server operates have anything to do with that? Concerns about hypothetical legal and policy issues that might be a barrier to deployment are far beyond the scope of this list. -- to unsubscribe send a message to namedroppers-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 May 20 07:46: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 HAA12869 for ; Thu, 20 May 2004 07:46:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQlyc-000LAj-0G for namedroppers-data@psg.com; Thu, 20 May 2004 11:44:42 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQlyZ-000LAQ-RC for namedroppers@ops.ietf.org; Thu, 20 May 2004 11:44:39 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4KBiblZ090932 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 20 May 2004 11:44:38 GMT (envelope-from roy+dated+1087645541.24420a@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4KBiYso017473 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 20 May 2004 12:44:36 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4KBjfuq063131 for ; Thu, 20 May 2004 12:45:41 +0100 (BST) (envelope-from roy+dated+1087645541.24420a@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4KBjfCW063130 for namedroppers@ops.ietf.org; Thu, 20 May 2004 12:45:41 +0100 (BST) (envelope-from roy+dated+1087645541.24420a@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 20 May 2004 12:45:39 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16556.39523.357152.92612@giles.gnomon.org.uk> Date: Thu, 20 May 2004 12:45:39 +0100 To: Jim Reid Cc: Roy Badami , Marcos Sanz/Denic , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <18095.1085051220@gromit.rfc1035.com> References: <16556.34807.204862.570446@giles.gnomon.org.uk> <18095.1085051220@gromit.rfc1035.com> 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-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 >>>>> "Jim" == Jim Reid writes: Jim> This is already known. Now why do some people believe that Jim> this enumeration is a *technical* problem? Well, DNSSEC removes a piece of functionality from the DNS, namely the ability to apply different access control to enumeration from that this is applied to queries. Since DNSSEC never had a functional spec, it is of course rather difficult to claim that this is a technical problem. Since this is a piece of functionality that some people find useful and others don't, it is hardly surprising that whether its absence from the spec constitutes a problem is the subject of debate. Jim> specifically, are the technical protocol problems that arise Jim> from this? Specifically, I suspect that the technical problem some people see is that the DNSSEC protocol doesn't meet the functional spec that they have in their minds. It does meet the functional spec that other people have in their minds. Since to my knowledge there has never been a formal functional spec for DNSSEC, both sides are in some sense correct. Jim> If there's a layer-9 problem about compilation copyright or Jim> whatever, that needs to be solved at layer-9, not here. In Jim> fact it can't be solved here. I suspect that most of the concerns relate to the EU Data Protection Directive (and the transposed legislation of the member states), rather than anything to do with copyright. It's not at all clear to me that zone file enumeration does in itself create data protection issues, but this is by no means a simple area of legislation. But if there _is_ an issue, then suggesting that EU law should be changed in order to fit in with the decisions of the IETF is not likely to be a productive approach... Jim> BTW, enumeration of an unsigned zone by unauthorised parties Jim> is theoretically possible. DNSSEC just makes this theoretical Jim> concern a practical possibility. Yes, and the law is very good at coping with distinctions like that... :-) Essentially the question is, do the benefits of DNSSEC outweigh the costs of no longer being able to prohibit enumeration? If some domains have a serious issue with this, is it worth delaying DNSSEC in order to try and enhance it to include the functionality those domains desire? Which decision is likely to give me a signed .co.uk zone sooner? Only the ccTLD operators concerned can attempt to answer that question. -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 May 20 09:08: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 JAA15625 for ; Thu, 20 May 2004 09:08:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQnGC-0005wj-Kx for namedroppers-data@psg.com; Thu, 20 May 2004 13:06:56 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQnGB-0005wM-FY for namedroppers@ops.ietf.org; Thu, 20 May 2004 13:06:55 +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 i4KD6rgh002113 for ; Thu, 20 May 2004 15:06:54 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4KD6rP05195 for ; Thu, 20 May 2004 15:06:53 +0200 (MEST) Message-Id: <200405201306.i4KD6rP05195@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: Proposal to fix NSEC In-reply-to: Your message of "19 May 2004 15:44:26 PDT." 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: <5190.1085058410.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 20 May 2004 15:06:53 +0200 From: Peter Koch 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 Bob Halley wrote: > The problems with online signing are: > > It's a CPU burden for the authoritative nameserver. Yes, but the operators in question (TLD registries) should be able to deal with this. > You must trust your slaves enough to give them the right > to make signatures. In the standard DNSSEC model, a > rogue slave can deny service, but it cannot generate > authenticated zone content. Most TLDs already have all their nameservers under their very own control (although not necessarily on a physical level). So betrayal by 2ndary isn't a problem. For cases where one of the servers is compromised, DoS is possible even with DNSSEC because an attacker would be able to provide for forged signatures. The risk of forged entries can be reduced by using different keys. The offline key would be used to sign RRSets, securing positive responses (mostly DS RRs). The online key could be used to sign online NSEC RRs to be generated on the fly (and pointing at some uncritical, maybe not even existing name). It's just that I don't see an opportunity to signal this distinction at the moment. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 20 09:08: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 JAA15647 for ; Thu, 20 May 2004 09:08:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQnE8-0005Z1-Ib for namedroppers-data@psg.com; Thu, 20 May 2004 13:04:48 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQnE5-0005YV-8G for namedroppers@ops.ietf.org; Thu, 20 May 2004 13:04:45 +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 i4KD4ard018296; Thu, 20 May 2004 14:04:37 +0100 (BST) To: Roy Badami cc: Marcos Sanz/Denic , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Roy Badami of "Thu, 20 May 2004 12:45:39 BST." <16556.39523.357152.92612@giles.gnomon.org.uk> Date: Thu, 20 May 2004 14:04:36 +0100 Message-ID: <18295.1085058276@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Badami writes: Jim> This is already known. Now why do some people believe that Jim> this enumeration is a *technical* problem? Roy> Well, DNSSEC removes a piece of functionality from the DNS, Roy> namely the ability to apply different access control to Roy> enumeration from that this is applied to queries. Access control has never been part of the DNS protocol. So DNSSEC can't possibly remove something that was never there. :-) Most DNS implementations provide access controls. But you shouldn't confuse these with the DNS protocol. Though admittedly many people mistakenly believe that the DNS protocol is "whatever BIND does". Roy> Specifically, I suspect that the technical problem some Roy> people see is that the DNSSEC protocol doesn't meet the Roy> functional spec that they have in their minds. This isn't a DNS protocol issue. Roy> It's not at all clear to me that zone file enumeration does Roy> in itself create data protection issues, but this is by no Roy> means a simple area of legislation. But if there _is_ an Roy> issue, then suggesting that EU law should be changed in order Roy> to fit in with the decisions of the IETF is not likely to be Roy> a productive approach... I wasn't suggesting that. And to turn it around, expecting the IETF to solve abstract, hypothetical issues about an EU directive by redesigning a DNS protocol isn't going to be productive either. The DNSSEC protocol is legislature-neutral. It has to be. Now how that protocol is used may well have legal considerations. But that's an issue for each deployer to make a judgement about. Roy> If some domains have a serious issue with this, is it worth Roy> delaying DNSSEC in order to try and enhance it to include the Roy> functionality those domains desire? Not if it means another couple of years wrangling over drafts and re-opening old wounds. Especially if there's no-one left standing after yet another protracted holy war. If some domains have concerns about policy issues relating to protocol deployment, they should address those policy issues in whatever is the appropriate policy forum: ICANN perhaps. -- to unsubscribe send a message to namedroppers-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 May 20 10:48: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 KAA21472 for ; Thu, 20 May 2004 10:48:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQonR-000J9L-6q for namedroppers-data@psg.com; Thu, 20 May 2004 14:45:21 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQonO-000J8L-T7 for namedroppers@ops.ietf.org; Thu, 20 May 2004 14:45:19 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i4KEjGII001233; Thu, 20 May 2004 10:45:16 -0400 To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> From: Derek Atkins Date: Thu, 20 May 2004 10:45:16 -0400 In-Reply-To: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Thu, 20 May 2004 15:06:53 +0200") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) 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 Peter, Peter Koch writes: > Bob Halley wrote: > >> The problems with online signing are: >> >> It's a CPU burden for the authoritative nameserver. > > Yes, but the operators in question (TLD registries) should be able to deal > with this. I don't think you understand what level of CPU burden online signing can be in the face of unauthenticatd queries. It's a DoS attack waiting to happen. Turn this "feature" on in your DNS servers and I can bring your server to its knees without even trying. It's very simple: I send a string of random requests to your server for random (non-existant) hosts in your authoritative zone. To make sure you can't block this easily at your firewall I spoof the sender address (I don't care about the responses anyways). Even if modern TLD CPUs can handle 10,000 RSA encryptions per second (my laptop tops out at around 2,000 with full-bore CPU usage), that just means I need to send you 10,000 requests per second. That's about 10mbps (probably even less). Not too hard to achieve. Note that my 2000/s is full-CPU. You need a good deal of CPU to actually perform the DNS query/response, so that reduces the number of actual RSA operations possible. The problem is that it's just too prone to DoS attacks.... Which is BAD. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-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 May 20 12:13: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 MAA28531 for ; Thu, 20 May 2004 12:13:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQq6b-0005Ja-EM for namedroppers-data@psg.com; Thu, 20 May 2004 16:09:13 +0000 Received: from [199.239.208.244] (helo=199.239.208.244) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQq6U-0005IL-5p for namedroppers@ops.ietf.org; Thu, 20 May 2004 16:09:06 +0000 Received: from [24.239.105.131] (helo=x) by 199.239.208.244 with asmtp (Exim 3.36 #1) id 1BQq5s-0006vt-00; Thu, 20 May 2004 12:08:28 -0400 Reply-To: From: "Sal Mangiapane" To: , "Ben Laurie" Cc: "Peter Koch" , Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 12:08:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,RCVD_NUMERIC_HELO autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Wed, 19 May 2004, Ben Laurie wrote: > > > Peter Koch wrote: > > > > > > There are other alternatives, including online signing, maybe with a > > > different key. The zones in question have some special properties (almost > > > "NS only"), which may also be exploited to find a solution. > > > > I have hesitated to suggest alternatives that include online signing, > > because of the principle that private keys should not be exposed by > > putting them on connected machines. > > A ssh/tls/ipsec capable machines have a private key on connected > machines. > > > However, it is definitely worth saying that online signing would > > completely eliminate traversal. > > Definitly. > first posting to any IETF list. Please forgive me if this has been discussed. I would appreciate references that I may read. How will signing completely eliminate traversal? Has anyone suggested a parallel internet standard similar to DNS that would be used for authorizing digital signatures? Then, DNS (and E-mail, VoIP, etc) could each define their specific required information for using digital signatures. DNS would not be burdened with implementing (and supporting) it's own PKI infrastructure. Best Regards, Sal Salvatore Mangiapane -- to unsubscribe send a message to namedroppers-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 May 20 12:41: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 MAA00470 for ; Thu, 20 May 2004 12:41:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQqYL-00094e-QD for namedroppers-data@psg.com; Thu, 20 May 2004 16:37:53 +0000 Received: from [199.239.208.244] (helo=199.239.208.244) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQqXs-00091i-Hk for namedroppers@ops.ietf.org; Thu, 20 May 2004 16:37:24 +0000 Received: from [24.239.105.131] (helo=x) by 199.239.208.244 with asmtp (Exim 3.36 #1) id 1BQqXb-0007F5-00; Thu, 20 May 2004 12:37:07 -0400 Reply-To: From: "Sal Mangiapane" To: "Derek Atkins" , "Peter Koch" Cc: Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 12:36:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00, RCVD_NUMERIC_HELO autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Peter Koch writes: > > > Bob Halley wrote: > > > >> The problems with online signing are: > >> > >> It's a CPU burden for the authoritative nameserver. > > > > Yes, but the operators in question (TLD registries) should be able to deal > > with this. > > I don't think you understand what level of CPU burden online signing > can be in the face of unauthenticated queries. It's a DoS attack > waiting to happen. Turn this "feature" on in your DNS servers and I > can bring your server to its knees without even trying. It's very > simple: I send a string of random requests to your server for random > (non-existent) hosts in your authoritative zone. To make sure you > can't block this easily at your firewall I spoof the sender address (I > don't care about the responses anyways). > > Even if modern TLD CPUs can handle 10,000 RSA encryptions per second > (my laptop tops out at around 2,000 with full-bore CPU usage), that > just means I need to send you 10,000 requests per second. That's > about 10mbps (probably even less). Not too hard to achieve. Note > that my 2000/s is full-CPU. You need a good deal of CPU to actually > perform the DNS query/response, so that reduces the number of actual > RSA operations possible. > > The problem is that it's just too prone to DoS attacks.... Which is BAD. A standard could be established to help thwart DoS attack. 1) Only use signatures for queries from named name servers (ns record exists). 2) Only use signatures when the named name server uses signatures (it signed the request). 3) When your server load exceeds a predefined limit (like 30% CPU) drop all query requests from unknown name servers (such as caching name servers). 4) When your server load exceeds some next higher limit (like 50% CPU) drop all query requests except when signed from a named name server. This methodology will also encourage adoption of the new standard for obvious reasons. Of course, 1) could easily be spoofed. 2) could not, but may tie up your DNS server verifying signatures. Best Regards, Sal Salvatore Mangiapane -- to unsubscribe send a message to namedroppers-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 May 20 12:55: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 MAA01847 for ; Thu, 20 May 2004 12:55:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQqn8-000BRX-TR for namedroppers-data@psg.com; Thu, 20 May 2004 16:53:10 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQqlM-000B64-Gk for namedroppers@ops.ietf.org; Thu, 20 May 2004 16:51:20 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Thu, 20 May 2004 12:51:09 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.5.43) with SMTP id M2004052012510800287 ; Thu, 20 May 2004 12:51:08 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 May 2004 12:51:09 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE1050AC@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'salm@servanttechnology.com'" Cc: namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 12:49:00 -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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > The problem is that [online signing is] just too prone to > > DoS attacks.... Which is BAD. > > A standard could be established to help thwart DoS attack. > > 1) Only use signatures for queries from named name servers > (ns record exists). This blatantly ignores the completely common case where the set of recursive/caching/resolving nameservers for an organization are separate from the set of authoritative nameservers (with NS records for the zone delegation) for that organization. As a result, your notional standard is not likely to work. --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: From owner-namedroppers@ops.ietf.org Thu May 20 13:13: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 NAA03166 for ; Thu, 20 May 2004 13:13:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQr3k-000ENn-Ti for namedroppers-data@psg.com; Thu, 20 May 2004 17:10:20 +0000 Received: from [199.239.208.244] (helo=199.239.208.244) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQr3R-000EIl-CA for namedroppers@ops.ietf.org; Thu, 20 May 2004 17:10:01 +0000 Received: from [24.239.105.131] (helo=x) by 199.239.208.244 with asmtp (Exim 3.36 #1) id 1BQr3K-0007cH-00; Thu, 20 May 2004 13:09:54 -0400 Reply-To: From: "Sal Mangiapane" To: "Loomis, Rip" Cc: Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 13:09:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE1050AC@US-Columbia-CIST.mail.saic.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00, RCVD_NUMERIC_HELO autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > The problem is that [online signing is] just too prone to > > > DoS attacks.... Which is BAD. > > > > A standard could be established to help thwart DoS attack. > > > > 1) Only use signatures for queries from named name servers > > (ns record exists). > > This blatantly ignores the completely common case where > the set of recursive/caching/resolving nameservers for an > organization are separate from the set of authoritative > nameservers (with NS records for the zone delegation) > for that organization. As a result, your notional standard > is not likely to work. > > --Rip > This is exactly what each group would need to establish. In this case, what the criteria for DNS would be. The Internet benefits from the ubiquity of DNS. Couldn't the same be true for a single system of digital signatures? -- to unsubscribe send a message to namedroppers-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 May 20 14:36: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 OAA10158 for ; Thu, 20 May 2004 14:36:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQsKU-000PH5-Nt for namedroppers-data@psg.com; Thu, 20 May 2004 18:31:42 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQsKO-000PGO-94 for namedroppers@ops.ietf.org; Thu, 20 May 2004 18:31:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id F23BD13DE5 for ; Thu, 20 May 2004 18:31:35 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Roy Badami of "Thu, 20 May 2004 11:27:03 +0100." <16556.34807.204862.570446@giles.gnomon.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 20 May 2004 18:31:35 +0000 Message-Id: <20040520183135.F23BD13DE5@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 > ... Currently, the DNS allows the operator of an authoritative > nameserver to permit unauthenticated queries, but to deny enumeration > of the zone to unauthenticated parties. actually, it doesn't. no rfc specifies this behaviour. it's a BINDism that other implementors have added because users think it's a useful feature. RFC 1034 and RFC 1035 say how to answer AXFR, but no RFC says how to block it. > With DNSSEC, this is not possible. If you allow queries then you > allow enumeration. if you want the ability to block enumeration to be part of the standard, then you should try to write it up and get it done. i suspect that IETF will not agree that this is a necessary or "pure enough" feature. but if you can get it done, then you might be able to get IETF to think that DNSSEC should preserve this functionality. -- to unsubscribe send a message to namedroppers-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 May 20 15: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 PAA12728 for ; Thu, 20 May 2004 15:07:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQspx-0003pF-41 for namedroppers-data@psg.com; Thu, 20 May 2004 19:04:13 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQspo-0003nT-6z for namedroppers@ops.ietf.org; Thu, 20 May 2004 19:04:04 +0000 Received: from hypatia.dns.net (c6-rba-130.dial-up.net [196.26.218.130]) by mercury.is.co.za (Postfix) with ESMTP id 86B3AC8D6E; Thu, 20 May 2004 21:04:00 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i4KIpwl30027; Thu, 20 May 2004 20:51:58 +0200 Date: Thu, 20 May 2004 20:51:58 +0200 From: Andras Salamon To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-ID: <20040520185158.GA29915@dns.net> References: <17969.1085046090@gromit.rfc1035.com> <16556.34807.204862.570446@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16556.34807.204862.570446@giles.gnomon.org.uk> User-Agent: Mutt/1.5.6i 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 On Thu, May 20, 2004 at 11:27:03AM +0100, Roy Badami wrote: > Currently, the > DNS allows the operator of an authoritative nameserver to permit > unauthenticated queries, but to deny enumeration of the zone to > unauthenticated parties. As Jim stated, some _implementations_ of DNS servers allow this kind of control. > This is a technical change: specifically, the authentication model is > now less fine-grained than it used to be. More accurately, a previously possible hack would no longer be possible. > Whether this technical change constitutes a problem would seem to > depend on the legal and policy framework in which the nameserver is > operating, As stated by Jim, if a DNS operator is concerned about publishing sensitive data, they should remove that data from the set of DNS records accessible over a public network, by any means, including enumeration. If, to comply with data protection legislation, an operator is relying on enumeration of records not being possible, then that operator is asking for trouble and is possibly already in breach (depending on the jurisdiction). First, don't put private data in a public database. Second, the DNS servers accessible over the Internet constitute a public database. Conclusion: don't put private data onto DNS servers accessible over the Internet. How many times does this need to be repeated? -- Andras Salamon andras@dns.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: From owner-namedroppers@ops.ietf.org Thu May 20 15:29: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 PAA14756 for ; Thu, 20 May 2004 15:29:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQtAS-0006ew-8v for namedroppers-data@psg.com; Thu, 20 May 2004 19:25:24 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQtAP-0006dp-FZ for namedroppers@ops.ietf.org; Thu, 20 May 2004 19:25:21 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4KJPIlZ019051 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 20 May 2004 19:25:20 GMT (envelope-from roy+dated+1087673185.d55638@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4KJPHso019248 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 20 May 2004 20:25:18 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4KJQPuq065490 for ; Thu, 20 May 2004 20:26:25 +0100 (BST) (envelope-from roy+dated+1087673185.d55638@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4KJQPuW065489 for namedroppers@ops.ietf.org; Thu, 20 May 2004 20:26:25 +0100 (BST) (envelope-from roy+dated+1087673185.d55638@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 20 May 2004 20:26:25 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16557.1632.918749.103466@giles.gnomon.org.uk> Date: Thu, 20 May 2004 20:26:24 +0100 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <20040520183135.F23BD13DE5@sa.vix.com> References: <16556.34807.204862.570446@giles.gnomon.org.uk> <20040520183135.F23BD13DE5@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 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-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 writes: Paul> if you want the ability to block enumeration to be part of Paul> the standard, then you should try to write it up and get it Paul> done. i suspect that IETF will not agree that this is a Paul> necessary or "pure enough" feature. but if you can get it Paul> done, then you might be able to get IETF to think that Paul> DNSSEC should preserve this functionality. I have neither the motivation nor the inspiration to do that. I'm happy to leave that to those who feel a desperate need to use this feature... :-) I was just trying to counter what I perceived to be a possible sense of "there's no possible reason why this issue should botther you" in some of the comments in this thread. There is a clear real-world difference between allowing queries and allowing a wholesale download of the zone file. There is most definitely a difference in the real world between a theortical attack and a practical attack. These differences may well affect what a registry feels comfortable doing in terms of European data protection legislation. If ccTLD operators suggest that this might be an issue for them, then it is IMHO unreasonable for anyone (other than a lawyer versed in this area) to tell them they are wrong. I realize that Ben Laurie has made it clear that he doesn't speak for Nominet in terms of policy, and has not explicitly stated Nominet's concerns, but it's clear from the URL below that the Nominet PAB does have concerns (although not exacly what they are). http://www.nominet.org.uk/Pab/PabMeetingPapers/ZoneFileEnumerationInDnssec.html I'm assuming that the DNSSECbis document set is not going to be derailed at this late stage -- it's hardly as if the NXT record is some new idea which has been pushed through with little discussion, and the world has been waiting long enough for deployable DNSSEC. But if at a later date a significant number of ccTLD registries decide that the issue is a showstopper for them, then I would hope that the IETF will provide a suitable forum for these issues to be explored further. -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 May 20 16: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 QAA17402 for ; Thu, 20 May 2004 16:03:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQtiL-000BQx-68 for namedroppers-data@psg.com; Thu, 20 May 2004 20:00:25 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQtiG-000BPd-QD for namedroppers@ops.ietf.org; Thu, 20 May 2004 20:00:20 +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 i4KK0JSs010319 for ; Thu, 20 May 2004 22:00:19 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4KK0JW06661 for ; Thu, 20 May 2004 22:00:19 +0200 (MEST) Message-Id: <200405202000.i4KK0JW06661@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: Proposal to fix NSEC In-reply-to: Your message of "Thu, 20 May 2004 20:51:58 +0200." <20040520185158.GA29915@dns.net> 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: <6654.1085083216.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 20 May 2004 22:00:19 +0200 From: Peter Koch 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 Andras Salamon wrote: > How many times does this need to be repeated? try until it's true. I'd really appreciate if people wouldn't generally neglect any difference between every single record of data (or a set of data) being public (i.e. accessible anonymously without any further authorization) and all of the data being accessible at once. There is a difference and we have several examples, whois itself being one of it. Another are "public" phone directories allowing for name to number mappings but not for bulk transfer or "reverse mapping". (Commercial) databases of other kinds come to mind. So, just repeating over and over again that "public" is "public" doesn't lead us anywhere. Now, back to DNS, it may well be that it wasn't designed to protect the zone(s) from being XFRed, but there are other things it wasn't designed for, too (like being a flat keyword index). Again, AXFR doesn't constitute a technical or security problem per se. Of course that's a layer 9 problem, but so what? Isn't DNSSEC as a whole there to solve layer 9 problems? If the world weren't so bad, we wouldn't need any security protocols. Now, for AXFR blocks not being standardized: REFUSED does exist. There's no (longer a) DNS way to communicate between master and slaves the necessary authorization info, but that doesn't prove anything more than you cannot rely upon it (unless you have out of band communication). I believe DNSSEC is necessary and I want it deployed - without a major protocol redesign which would cost more time than available - given that there are other protocols in the queue which kind of need a secured DNS. But here's a deployment obstacle which has come up really late (well, NO was worked on a few years ago, but the problem wasn't emphasized back then) and which needs an engineering solution. Can we work on one? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 20 16:40: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 QAA20514 for ; Thu, 20 May 2004 16:40:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQuHd-000Gzk-Qj for namedroppers-data@psg.com; Thu, 20 May 2004 20:36:53 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQuHc-000GzW-0V for namedroppers@ops.ietf.org; Thu, 20 May 2004 20:36:52 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id D9078317E9B for ; Thu, 20 May 2004 22:36:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 22:36:45 +0200 X-Mailer: Apple Mail (2.613) 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 Dear Colleagues, Let me try and sumarise what I've seen so far and suggest a way forward. Ben proposed a mechanism to fix "NSEC zone traversal" that apparently hinders TLDs in the deployment of DNSSEC. Although the discussion on the validity of this reason is interesting it is not a protocol issue. We will not be able to change TLD policies. The proposed mechanism, I'll refer to is as NSEC2, may have technical merit. I think it is fair to say that the working group is still digesting the technical details of the proposal. Please continue to do so, having documented why a technology will or will not work is a good thing. As far as I understand the security properties of the proposed technology are such that changes are needed to the protocol as in DNSSEC-bis. This means that we have to introduce a flag day. That flag day either is "now" or after the DNSSEC-bis protocol is out in the field. We as a working group have a choice. - We take up this NSEC2 proposal as a working item. If we do so we will have to merge the technology into the current DNSSEC-bis document set. Having a flag day, after introducing DNSSEC-bis just does not make sense. Realize that taking up this as a working item would result in an unknown delay of getting the DNSSEC specifications done. Not only will the WG need time to assess the quality of the proposed solution but people currently funded to work on the effort may see that funding stop and walk away. Realisticly we are looking at significantly more than 6 months [*] delay. (We'll have to assess interaction with wildcards and other DNS elements. We'll have to test for corner cases, &c, &c). There are more pessimistic scenarios than the 6 months scenario. - We do not take up NSEC2 as a working item This would not imply that the "NSEC zone traversal" is a non-issue. It may actually hinder deployment of DNSSEC some TLD zones. If we go this route we may have a proposed standard and start of deployment in some zones this year in less than 6 months [*]. The DNSSEC-bis document set is clear on the fact that DNSSEC does not offer privacy. We just have to live with that. I'll be tracking the discussion with the following in mind. If I do not see rough consensus on taking up NSEC2 as a work item by June 1 I'll reject this as a work item. If, after June 1, there is consensus on taking up NSEC2 as a work item I'll try to make an inventory on how many participants of the working group can commit resources to make this work. If it turns out we cannot produce standards, documents and code on a reasonable time or we alienate a significant fraction of the people that are now committed on working on this we'll also not take NSEC2 up as a work item. If we'll take NSEC2 as a work item then - in order to avoid a flag day - the current DNSSEC-bis doc set will be put on hold until NSEC2 is cooked enough to be merged into the DNSSEC-bis documents. Olaf Kolkman DNSEXT Co-Chair (Olafur is away from keyboard for a week or two.) [*] I've been telling people that DNSSEC will be ready in 6 months over the last 3 years. As a result the combination of "6 months" and DNSSEC in one sentence rises suspicion. -- to unsubscribe send a message to namedroppers-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 May 20 16:51: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 QAA22035 for ; Thu, 20 May 2004 16:51:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQuTK-000Ikg-OB for namedroppers-data@psg.com; Thu, 20 May 2004 20:48:58 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQuTJ-000IkP-Ez for namedroppers@ops.ietf.org; Thu, 20 May 2004 20:48:57 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 680BE107919; Thu, 20 May 2004 20:48:56 +0000 (GMT) Message-ID: <40AD1A3C.2030800@algroup.co.uk> Date: Thu, 20 May 2004 21:51:08 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Enigmail-Version: 0.83.6.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 Peter Koch wrote: > Bob Halley wrote: > > >>The problems with online signing are: >> >> It's a CPU burden for the authoritative nameserver. > > > Yes, but the operators in question (TLD registries) should be able to deal > with this. > > >> You must trust your slaves enough to give them the right >> to make signatures. In the standard DNSSEC model, a >> rogue slave can deny service, but it cannot generate >> authenticated zone content. > > > Most TLDs already have all their nameservers under their very own control > (although not necessarily on a physical level). So betrayal by 2ndary isn't > a problem. For cases where one of the servers is compromised, DoS is possible > even with DNSSEC because an attacker would be able to provide for forged > signatures. The risk of forged entries can be reduced by using different > keys. The offline key would be used to sign RRSets, securing positive responses > (mostly DS RRs). The online key could be used to sign online NSEC RRs to > be generated on the fly (and pointing at some uncritical, maybe not even > existing name). It's just that I don't see an opportunity to signal this > distinction at the moment. If you were going to do this, it would make more sense to simply sign a denial of the existence of the particular domain, rather than messing with NSEC records. If you had a signed denial, then the easy way to signal it is to have an RR that is specifically for that purpose (that is, when you receive a NOTHISDOESNTEXIST RR you expect it to be signed with the special key used for that purpose alone). This is another solution I didn't dare suggest! 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 Thu May 20 17:19: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 RAA25741 for ; Thu, 20 May 2004 17:19:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQut6-000Mua-Nq for namedroppers-data@psg.com; Thu, 20 May 2004 21:15:36 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQut5-000MuK-RR for namedroppers@ops.ietf.org; Thu, 20 May 2004 21:15:35 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4KLFWlZ061147 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 20 May 2004 21:15:34 GMT (envelope-from roy+dated+1087679800.cd4a87@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4KLFVso019902 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 20 May 2004 22:15:32 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4KLGeuq066649 for ; Thu, 20 May 2004 22:16:40 +0100 (BST) (envelope-from roy+dated+1087679800.cd4a87@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4KLGel3066648 for namedroppers@ops.ietf.org; Thu, 20 May 2004 22:16:40 +0100 (BST) (envelope-from roy+dated+1087679800.cd4a87@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 20 May 2004 22:16:36 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16557.8244.301154.213051@giles.gnomon.org.uk> Date: Thu, 20 May 2004 22:16:36 +0100 To: Olaf Kolkman Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> References: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> 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-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 >>>>> "Olaf" == Olaf Kolkman writes: Olaf> Ben proposed a mechanism to fix "NSEC zone traversal" that Olaf> apparently hinders TLDs in the deployment of Olaf> DNSSEC. I had been intending to avoid making any further on-list comments, given I haven't been a WG participant, and that much of this thread has been discussing issues which are both outside the scope of this WG and outside the expertese of this WG. But I just want to make one further point. Contrary to what you suggest, I don't believe anyone with authority to do so has clearly stated that that zone file traversal is a serious barrier to deployment in certain registries. Ben very specifically stated that he speaks for Nominet only on technical matters, not on policy matters and, I believe, has avoided commenting in this thread other than on the technical issues relating to his proposal. There may be other people who have expressed this view whose afiliations I am unware of, of course. I don't have a strong opinion as to whether zone file traversal is a serious issue for adoption or not. I'm just trying to suggest that the answer to this question isn't as obvious as some particpants seem to believe. Nor am I expressing an opinion as to whether it would be appropriate to consider modifying the DNSSECbis document set at this late stage. However unless it is possible to get relevent input from those TLDs that currently have a policy of not making their zone files available to the public, then I suggest it would not be productive to persue this issue at this stage, but that it should simply be noted as an item for possible future study. -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 May 20 17:21: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 RAA25998 for ; Thu, 20 May 2004 17:21:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQuxB-000NQ1-7G for namedroppers-data@psg.com; Thu, 20 May 2004 21:19:49 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQuxA-000NPl-45 for namedroppers@ops.ietf.org; Thu, 20 May 2004 21:19:48 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id D1813317F83; Thu, 20 May 2004 23:19:44 +0200 (CEST) In-Reply-To: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <69C1B21C-AAA3-11D8-B9EA-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 23:19:43 +0200 To: Peter Koch X-Mailer: Apple Mail (2.613) 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 On May 20, 2004, at 3:06 PM, Peter Koch wrote: > The offline key would be used to sign RRSets, securing positive > responses > (mostly DS RRs). The online key could be used to sign online NSEC RRs > to > be generated on the fly (and pointing at some uncritical, maybe not > even > existing name). It's just that I don't see an opportunity to signal > this > distinction at the moment. Good idea... There is no reason why one part of a zone cannot be signed with zone signing key 1 and another signed with zone signing key 2. There is no need for signaling. This is an essential property to be remembered during key rollovers when there may be several RRsets from a zone living somewhere in a cache that have signatures made with valid keys. The zone operator needs to provide the public key material of both the keys during the rollover. Note also that if you minimize the signature validity time on the apex keyset you reduce the useful lifetime of the a compromised key. --Olaf (no hats) -- to unsubscribe send a message to namedroppers-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 May 20 17:25: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 RAA26380 for ; Thu, 20 May 2004 17:25:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQv0z-000O0V-K5 for namedroppers-data@psg.com; Thu, 20 May 2004 21:23:45 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQv0y-000O04-IB for namedroppers@ops.ietf.org; Thu, 20 May 2004 21:23:44 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 64D9A317FC7 for ; Thu, 20 May 2004 23:23:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v613) To: namedroppers@ops.ietf.org Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-1--593162129 From: Olaf Kolkman Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 23:23:40 +0200 X-Mailer: Apple Mail (2.613) 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,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-1--593162129 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Forwarded message 1 out of 2 (there where problems posting) > From: Paul Vixie > Date: May 19, 2004 4:33:42 PM CEST > To: namedroppers@ops.ietf.org > Subject: Re: Proposal to fix NSEC > > >>> NSEC provides an index to whois. >> ... >> However, "fixing NSEC" will not fix the real (whois) problem. >> >> -- teds > > i agree with ted. dns is a publication mechanism, and if you don't > want > something published you probably shouldn't be putting it into dns at > all. > and, if your only way to keep whois safe is to hide its index, then you > have probably got other troubles. parts of the "index" are exposed > every > day in server logs or in-addr.arpa/ip6.arpa walks. > > --Apple-Mail-1--593162129 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Forwarded message 1 out of 2 (there where problems posting) 0000,0000,0000From: Paul Vixie < 0000,0000,0000Date: May 19, 2004 4:33:42 PM CEST 0000,0000,0000To: namedroppers@ops.ietf.org 0000,0000,0000Subject: Re: Proposal to fix NSEC NSEC provides an index to whois. ... However, "fixing NSEC" will not fix the real (whois) problem. -- teds i agree with ted. dns is a publication mechanism, and if you don't want something published you probably shouldn't be putting it into dns at all. and, if your only way to keep whois safe is to hide its index, then you have probably got other troubles. parts of the "index" are exposed every day in server logs or in-addr.arpa/ip6.arpa walks. --Apple-Mail-1--593162129-- -- to unsubscribe send a message to namedroppers-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 May 20 17:37: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 RAA27714 for ; Thu, 20 May 2004 17:37:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQvBq-000PZN-CV for namedroppers-data@psg.com; Thu, 20 May 2004 21:34:58 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQvBn-000PZ4-Ki for namedroppers@ops.ietf.org; Thu, 20 May 2004 21:34:55 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id F191F4ECC3; Thu, 20 May 2004 23:34:54 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5261E4ECB5 for ; Thu, 20 May 2004 23:34:53 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i4KLYrlT002483 for ; Thu, 20 May 2004 23:34:53 +0200 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i4KLYrs8011790 for namedroppers@ops.ietf.org; Thu, 20 May 2004 23:34:53 +0200 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQv1k-000O9W-Nd for namedroppers@ops.ietf.org; Thu, 20 May 2004 21:24:33 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id AD255317FD0 for ; Thu, 20 May 2004 23:24:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v613) To: namedroppers@ops.ietf.org Message-Id: <13DD462A-AAA4-11D8-91E9-000393DA2D46@ripe.net> Content-Type: multipart/alternative; boundary=Apple-Mail-2--593113137 From: Olaf Kolkman Subject: this week in dnssec, 10 years ago. Date: Thu, 20 May 2004 23:24:29 +0200 X-Mailer: Apple Mail (2.613) X-RIPE-Spam-Status: U 0.499462 / 0.1 / 0.0 / disabled X-RIPE-Signature: 3ca6dab6be2f5eebd53d480512ef53e5 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,HTML_MESSAGE autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-2--593113137 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable Forwarded message 2 out of 2 (there where problems posting) > From: Paul Vixie > Date: May 19, 2004 6:49:40 PM CEST > To: namedroppers@ops.ietf.org > Subject: this week in dnssec, 10 years ago. > > >> ... But designing DNSSEC to not introduce new realistic attack=20 >> vectors, >> compared to vanilla DNS, has always appeared sensible to me. ... > > simon picked an interesting point in time to make his concerns widely=20= > known > and propose a significant protocol/system design change to address=20 > them. do > we have some kind of carrier wave / harmonic underlying this whole=20 > project? > >> The alternatives to NSEC do reduce the attack vector into an offline >> dictionary attack, which I believe is an acceptable risk. ... > > this week in dnssec, 10 years ago, donald eastlake proposed "NX" which=20= > became > "NXT" and then "NSEC". see below. how much longer do we want to work=20= > on > this? i was thinking we'd begin early deployment work this month or=20= > next... > > re: > > -------- > > To: dns-security@tis.com > Subject: Thought on non-existant and wildcarded names > Date: Mon, 09 May 94 14:55:42 -0400 > From: "Donald E. Eastlake 3rd (Beast)" > X-Mts: smtp > > This is what I came up with and am thinking of merging into the next=20= > draft: > =0C > INTERNET-DRAFT DNS Protocol Security=20 > Extensions > > > > > > > Domain Name Protocol Security Extensions > > > > W. Special Handling of Wildcard Matches and Non-existence > > DNS security provides the means for establishing integrity and data > origin authenticity. However, this applies only to actual RRs in a > secured zone. There are two places where would be insufficient > without some additional steps. The first case is securely indicating > the absence of data. The other is the that of wildcard RRs. Wildcard > RRs have node names whose first label is an asterisk ("*"). These act > as instructions for synthesizing RRs not actually present. > > Since there are an enormous number of possible DNS names, it is > impossible to create and sign separate existence RRs for all possible > wildcard matches or denial RRs for all possible queries for > non-existent data. These are handled securely as described below. > > The following example zone is used in this section: > > FOO. IN SOA QQ.FOO. admin.QQ.FOO. > ( 60 ; serial > 7200 ; refresh > 600 ; retry > 1000000 ; expire > 60 ; minimum > ) > NS QQ > NS X.BAR > MX 10 A1 > MX 99 QQ > > A1 A 192.0.2.252 > A 192.245.52.250 > MX 10 A1 > MX 99 QQ > > X.BAR A 192.0.2.253 > A 192.245.52.249 > MX 10 X.BAR > MX 80 Y.Z.BAR > > Y.Z.BAR A 192.245.52.248 > MX 10 Y.Z.BAR > MX 80 Z.BAR > > > Donald E. Eastlake 3rd & Charles W. Kaufman [Page=20= > 1] > =0C > > INTERNET-DRAFT DNS Protocol Security=20 > Extensions > > > *.BAR MX 10 Y.Z.BAR > MX 80 X.BAR > > QQ A 192.0.2.254 > MX 10 QQ > MX 50 A1 > > > > W.1 Wildcard RR Matches > > The Domain Name System contains a provision for RRs that match any = name > below a point in the name tree unless a more specific name matches. > (See section 4.3.3 in RFC 1034.) For example, in zone FOO, there is = an > RRs named *.BAR.FOO and also more specifiec RRs with names X.BAR.FOO=20= > and > Y.Z.BAR.FOO. The wildcard RRs with name *.BAR.FOO can be though of as > instructions for synthesizing RRs with matching names and the same > class, type, TTL, and RDATA, when a matching query arrives. > > If a type MX query is made to zone FOO as above for Z.BAR.FOO, it will > match the wildcard RR and not any of the more specific RRs. So a > response will be made with the queried name (Z.BAR.FOO) substituted = for > the wildcard name (*.BAR.FOO). On the other hand, a query for=20 > X.BAR.FOO > or Z.BAR.FOO or anything below them will ignore the wildcard and = either > respond with the specific RR or a non-existent name response. Queries > for xx.FOO, where xx is any label but BAR, will be unaffected by the > wildcard. > > A wildcard is frequently used for such purposes as causing mail to a > large class of name to be sent to a particular set of mail gateways by > using wildcard MX RRs. > > Wildcard RRs are signed by SIG RRs with the same wildcard name and the > signature is based on the wildcard name. To make it possible to = verify > the signature, the SIG RR has a LABELS field which gives the number of > actual labels in its name, above the wildcard *, if there is one, not > counting the null label for root. If the actual number of labels > present in the RR name equals the LABELS field, then no wildcard is > involved. If the actual number of labels present is larger, then an * > can be temporarily substituted for the synthesized part of the name to > verify the signature. > > If a wildcard RR has been supressed because it appears inside a SIG on=20= > a > request for a security aware resolver to a security aware server, the > resolver has to do the wildcard expansion. > > > > > > > > Donald E. Eastlake 3rd & Charles W. Kaufman [Page=20= > 2] > =0C > > INTERNET-DRAFT DNS Protocol Security=20 > Extensions > > > W.2 Non-existent Types > > When a secure query is made for a name and class that exist is a zone, > but for an RR type that does not exist, there needs to be a secure way > to know that the type does not exist. This can be determined by > retrieving and examining all the SIG RRs. All types will be indicated > within the SIGs and the partial RR set signets in the SIGs can be used > to assure that a complete set of SIGs has been retrieved. > > Thus a query from a security aware resolver for a name that exists for > some RR in a zone but not as the owner of any RR of the requested type > should be answered by a security aware server with the usual error but > with all the SIGs for that name as additional information. > > > > W.3 Nonexistent Names > > The nonexistence of a name in a zone is indicates by the NX resource = RR > for a name interval containing the nonexistent name. An NX RR is > returned in the additional information section, along with the error,=20= > if > the client is security aware. NX RRs can also be returned if an > explicit query is made for the NX type. > > The existence of NX records means that any query for any name to a > security aware server serving a secure zone should result in an reply > containing at least one signed RR. > > > > W.3.1 The NX Resource Record > > The NX resource record is used to securely indicate that no RRs with = an > owner name in a certain name interval exist in a domain (or that any > specific names in that interval are masked by a wildcard). > > The owner name of the NX RR is an existing name in the zone. It's=20 > RDATA > is another existing name in the zone. The presence of the NX RR means > that no name between its owner name and the name in its RDATA area > exists. This implies a canonical ordering of all domain names in a > zone. > > The ordering is to sort labels as unsigned left justified octet = strings > where the absence of a byte sorts before a zero byte. Names are then > sorted by sorting on the highest level label and then, within those > names with the same highest level label by the next lower label, etc. > Since we are talking about a zone, the zone name itself always exists > and all other names are the zone name with some prefix of lower level > labels. Thus the zone name itself always sorts first. > > > > Donald E. Eastlake 3rd & Charles W. Kaufman [Page=20= > 3] > =0C > > INTERNET-DRAFT DNS Protocol Security=20 > Extensions > > > There is a slight problem with the last NX in a zone as it wants to=20 > have > an owner name which is the last existing name is sort order, which is > easy, but it is not obvious what name to put in its RDATA to indicate > the entire remainder of the name space. This is handled by treating=20= > the > name space as circular and putting the zone name in the RDATA of the > last NX. > > There are additional complexities due to interaction with wildcards as > explained below. > > The NX RRs for a zone can be automatically calculated and added to the > zone by the same recommended off-line process that signs the zone. = The > NX RRs TTL should not exceed the zone minimum TTL. > > The type number for the NX RR is xxx. > > > > W.3.2 NX RDATA format > > The RDATA for an NX RR consists simply of a domain name. > > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | next domain name / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > W.3.3 Interaction of NX RRs and Wildcard RRs > > As a wildcard RR causes all possible names in an interval to exist, > there should not be an NX record that would cover any part of this > interval. Thus if *.X.ZONE exists you would expect an NX RR that ends > at X.ZONE and one that starts with the last name covered by *.X.ZONE. > However, this "last name covered" is something very ugly and long like > \255\255\255....X.zone. So the NX for the interval following is = simply > given the owner name *.X.zone. This "*" type name is not expanded = when > the NX is returned as additional information in connection with a = query > for a non-existent name. > > If there could be any wildcard RRs in a zone and thus wildcard NXs,=20 > care > must be taken in interpreting the results of explicit NX retrievals as > the owner name may be a wildcard expansion. > > The existence of one or more wildcard RRs covering a name interval=20 > makes > it possible for a malicious server to hide any more specificly named=20= > RRs > > > Donald E. Eastlake 3rd & Charles W. Kaufman [Page=20= > 4] > =0C > > INTERNET-DRAFT DNS Protocol Security=20 > Extensions > > > in the internal. The server can just falsely return the wildcard = match > instead of the more specificly named RRs. If there is a zone wide > wildcard, there will be only one NX RR whose owner name and RDATA are > both the zone name. In this case a server could conceal the existence > of any more specific RRs in the zone. It would be possible to make a > more complex NX feature, taking into account the types of RRs that did > not exist in a name interval, and the like, which would eliminate this > possibility. But it would be more complex and would be so = constraining > as to make any future dynamic update feature very difficult. See > Section xxx. > > Below is the sample zone given above with NX RRs added. > > FOO. IN SOA QQ.FOO. admin.QQ.FOO. > ( 60 ; serial > 7200 ; refresh > 600 ; retry > 1000000 ; expire > 60 ; minimum > ) > NS QQ > NS X.BAR > MX 10 A1 > MX 99 QQ > NX A1 > > A1 A 192.0.2.252 > A 192.245.52.250 > MX 10 A1 > MX 99 QQ > NX BAR > > X.BAR A 192.0.2.253 > A 192.245.52.249 > MX 10 X.BAR > MX 80 Y.Z.BAR > ; no NX, covered by *.BAR > > Y.Z.BAR A 192.245.52.248 > MX 10 Y.Z.BAR > MX 80 Z.BAR > ; no NX, covered by *.BAR > > *.BAR MX 10 Y.Z.BAR > MX 80 X.BAR > NX QQ > > QQ A 192.0.2.254 > MX 10 QQ > MX 50 A1 > > > Donald E. Eastlake 3rd & Charles W. Kaufman [Page=20= > 5] > =0C > > INTERNET-DRAFT DNS Protocol Security=20 > Extensions > > > NX FOO. > > > > W.3.4 Blocking NX Pseudo-Zone Transfers > > In a secure zone, a resolver can query for the initial NX associated > with the zone name. Using the RDATA field from that RR, it can query > for the next NX RR. By repeating this, it can walk through all the = NXs > in the zone. If there are no wildcards, it can use this technique to > find all names in a zone. If it does type ANY queries, it can > incrementally get all information in the zone and perhaps defeat > attempts to administratively block zone transfers. > > If there are any wildcards, this NX walking technique will not find = any > more specific RR names in the part of the name space the wildcard > covers. By doing explicit retrievals for wildcard names, a resolver > could determine what intervals are covered by wildcards but still = could > not, with these techniques, find any names inside such intervals. > > If it is desired to block NX walking, the recommended method is to add=20= > a > zone wide wildcard of the KEY type which asserts the nonexistence of=20= > any > keys. This will cause there to be only one NX RR in the zone for the > zone name and leak no information about what real names exist in the > zone. This protection from pseudo-zone transfers is bought at the > expense of eliminating the data origin authentication of the non- > existence of names that NX RRs can provide. If an entire zone is > covered by a wildcard, a malicious server can return an RR produced by > matching that wildcard and can thus hide all the real data and > delegations with more specific names in the zone. > > > > > > > > > > > > > > > > > > > > > > > Donald E. Eastlake 3rd & Charles W. Kaufman [Page=20= > 6] > =0C > > -------- > > --Apple-Mail-2--593113137 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Forwarded message 2 out of 2 (there where problems posting) 0000,0000,0000From: Paul Vixie < 0000,0000,0000Date: May 19, 2004 6:49:40 PM CEST 0000,0000,0000To: namedroppers@ops.ietf.org 0000,0000,0000Subject: this week in dnssec, 10 years ago. ... But designing DNSSEC to not introduce new realistic attack vectors, compared to vanilla DNS, has always appeared sensible to me. ... simon picked an interesting point in time to make his concerns widely known and propose a significant protocol/system design change to address them. do we have some kind of carrier wave / harmonic underlying this whole project? The alternatives to NSEC do reduce the attack vector into an offline dictionary attack, which I believe is an acceptable risk. ... this week in dnssec, 10 years ago, donald eastlake proposed "NX" which became "NXT" and then "NSEC". see below. how much longer do we want to work on this? i was thinking we'd begin early deployment work this month or next... re: -------- To: dns-security@tis.com Subject: Thought on non-existant and wildcarded names Date: Mon, 09 May 94 14:55:42 -0400 From: "Donald E. Eastlake 3rd (Beast)" < X-Mts: smtp This is what I came up with and am thinking of merging into the next draft: =0C INTERNET-DRAFT DNS Protocol Security Extensions Domain Name Protocol Security Extensions W. Special Handling of Wildcard Matches and Non-existence DNS security provides the means for establishing integrity and data origin authenticity. However, this applies only to actual RRs in a secured zone. There are two places where would be insufficient without some additional steps. The first case is securely indicating the absence of data. The other is the that of wildcard RRs. Wildcard RRs have node names whose first label is an asterisk ("*"). These act as instructions for synthesizing RRs not actually present. Since there are an enormous number of possible DNS names, it is impossible to create and sign separate existence RRs for all possible wildcard matches or denial RRs for all possible queries for non-existent data. These are handled securely as described below. The following example zone is used in this section: FOO. IN SOA QQ.FOO. admin.QQ.FOO. ( 60 ; serial 7200 ; refresh 600 ; retry 1000000 ; expire 60 ; minimum ) NS QQ NS X.BAR MX 10 A1 MX 99 QQ A1 A 192.0.2.252 A 192.245.52.250 MX 10 A1 MX 99 QQ X.BAR A 192.0.2.253 A 192.245.52.249 MX 10 X.BAR MX 80 Y.Z.BAR Y.Z.BAR A 192.245.52.248 MX 10 Y.Z.BAR MX 80 Z.BAR Donald E. Eastlake 3rd & Charles W. Kaufman [Page 1] =0C INTERNET-DRAFT DNS Protocol Security Extensions *.BAR MX 10 Y.Z.BAR MX 80 X.BAR QQ A 192.0.2.254 MX 10 QQ MX 50 A1 W.1 Wildcard RR Matches The Domain Name System contains a provision for RRs that match any name below a point in the name tree unless a more specific name matches. (See section 4.3.3 in RFC 1034.) For example, in zone FOO, there is an RRs named *.BAR.FOO and also more specifiec RRs with names X.BAR.FOO and Y.Z.BAR.FOO. The wildcard RRs with name *.BAR.FOO can be though of as instructions for synthesizing RRs with matching names and the same class, type, TTL, and RDATA, when a matching query arrives. If a type MX query is made to zone FOO as above for Z.BAR.FOO, it will match the wildcard RR and not any of the more specific RRs. So a response will be made with the queried name (Z.BAR.FOO) substituted for the wildcard name (*.BAR.FOO). On the other hand, a query for X.BAR.FOO or Z.BAR.FOO or anything below them will ignore the wildcard and either respond with the specific RR or a non-existent name response. Queries for xx.FOO, where xx is any label but BAR, will be unaffected by the wildcard. A wildcard is frequently used for such purposes as causing mail to a large class of name to be sent to a particular set of mail gateways by using wildcard MX RRs. Wildcard RRs are signed by SIG RRs with the same wildcard name and the signature is based on the wildcard name. To make it possible to verify the signature, the SIG RR has a LABELS field which gives the number of actual labels in its name, above the wildcard *, if there is one, not counting the null label for root. If the actual number of labels present in the RR name equals the LABELS field, then no wildcard is involved. If the actual number of labels present is larger, then an * can be temporarily substituted for the synthesized part of the name to verify the signature. If a wildcard RR has been supressed because it appears inside a SIG on a request for a security aware resolver to a security aware server, the resolver has to do the wildcard expansion. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 2] =0C INTERNET-DRAFT DNS Protocol Security Extensions W.2 Non-existent Types When a secure query is made for a name and class that exist is a zone, but for an RR type that does not exist, there needs to be a secure way to know that the type does not exist. This can be determined by retrieving and examining all the SIG RRs. All types will be indicated within the SIGs and the partial RR set signets in the SIGs can be used to assure that a complete set of SIGs has been retrieved. Thus a query from a security aware resolver for a name that exists for some RR in a zone but not as the owner of any RR of the requested type should be answered by a security aware server with the usual error but with all the SIGs for that name as additional information. W.3 Nonexistent Names The nonexistence of a name in a zone is indicates by the NX resource RR for a name interval containing the nonexistent name. An NX RR is returned in the additional information section, along with the error, if the client is security aware. NX RRs can also be returned if an explicit query is made for the NX type. The existence of NX records means that any query for any name to a security aware server serving a secure zone should result in an reply containing at least one signed RR. W.3.1 The NX Resource Record The NX resource record is used to securely indicate that no RRs with an owner name in a certain name interval exist in a domain (or that any specific names in that interval are masked by a wildcard). The owner name of the NX RR is an existing name in the zone. It's RDATA is another existing name in the zone. The presence of the NX RR means that no name between its owner name and the name in its RDATA area exists. This implies a canonical ordering of all domain names in a zone. The ordering is to sort labels as unsigned left justified octet strings where the absence of a byte sorts before a zero byte. Names are then sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. Since we are talking about a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 3] =0C INTERNET-DRAFT DNS Protocol Security Extensions There is a slight problem with the last NX in a zone as it wants to have an owner name which is the last existing name is sort order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NX. There are additional complexities due to interaction with wildcards as explained below. The NX RRs for a zone can be automatically calculated and added to the zone by the same recommended off-line process that signs the zone. The NX RRs TTL should not exceed the zone minimum TTL. The type number for the NX RR is xxx. W.3.2 NX RDATA format The RDATA for an NX RR consists simply of a domain name. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next domain name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ W.3.3 Interaction of NX RRs and Wildcard RRs As a wildcard RR causes all possible names in an interval to exist, there should not be an NX record that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NX RR that ends at X.ZONE and one that starts with the last name covered by *.X.ZONE. However, this "last name covered" is something very ugly and long like \255\255\255....X.zone. So the NX for the interval following is simply given the owner name *.X.zone. This "*" type name is not expanded when the NX is returned as additional information in connection with a query for a non-existent name. If there could be any wildcard RRs in a zone and thus wildcard NXs, care must be taken in interpreting the results of explicit NX retrievals as the owner name may be a wildcard expansion. The existence of one or more wildcard RRs covering a name interval makes it possible for a malicious server to hide any more specificly named RRs Donald E. Eastlake 3rd & Charles W. Kaufman [Page 4] =0C INTERNET-DRAFT DNS Protocol Security Extensions in the internal. The server can just falsely return the wildcard match instead of the more specificly named RRs. If there is a zone wide wildcard, there will be only one NX RR whose owner name and RDATA are both the zone name. In this case a server could conceal the existence of any more specific RRs in the zone. It would be possible to make a more complex NX feature, taking into account the types of RRs that did not exist in a name interval, and the like, which would eliminate this possibility. But it would be more complex and would be so constraining as to make any future dynamic update feature very difficult. See Section xxx. Below is the sample zone given above with NX RRs added. FOO. IN SOA QQ.FOO. admin.QQ.FOO. ( 60 ; serial 7200 ; refresh 600 ; retry 1000000 ; expire 60 ; minimum ) NS QQ NS X.BAR MX 10 A1 MX 99 QQ NX A1 A1 A 192.0.2.252 A 192.245.52.250 MX 10 A1 MX 99 QQ NX BAR X.BAR A 192.0.2.253 A 192.245.52.249 MX 10 X.BAR MX 80 Y.Z.BAR ; no NX, covered by *.BAR Y.Z.BAR A 192.245.52.248 MX 10 Y.Z.BAR MX 80 Z.BAR ; no NX, covered by *.BAR *.BAR MX 10 Y.Z.BAR MX 80 X.BAR NX QQ QQ A 192.0.2.254 MX 10 QQ MX 50 A1 Donald E. Eastlake 3rd & Charles W. Kaufman [Page 5] =0C INTERNET-DRAFT DNS Protocol Security Extensions NX FOO. W.3.4 Blocking NX Pseudo-Zone Transfers In a secure zone, a resolver can query for the initial NX associated with the zone name. Using the RDATA field from that RR, it can query for the next NX RR. By repeating this, it can walk through all the NXs in the zone. If there are no wildcards, it can use this technique to find all names in a zone. If it does type ANY queries, it can incrementally get all information in the zone and perhaps defeat attempts to administratively block zone transfers. If there are any wildcards, this NX walking technique will not find any more specific RR names in the part of the name space the wildcard covers. By doing explicit retrievals for wildcard names, a resolver could determine what intervals are covered by wildcards but still could not, with these techniques, find any names inside such intervals. If it is desired to block NX walking, the recommended method is to add a zone wide wildcard of the KEY type which asserts the nonexistence of any keys. This will cause there to be only one NX RR in the zone for the zone name and leak no information about what real names exist in the zone. This protection from pseudo-zone transfers is bought at the expense of eliminating the data origin authentication of the non- existence of names that NX RRs can provide. If an entire zone is covered by a wildcard, a malicious server can return an RR produced by matching that wildcard and can thus hide all the real data and delegations with more specific names in the zone. Donald E. Eastlake 3rd & Charles W. Kaufman [Page 6] =0C -------- = --Apple-Mail-2--593113137-- -- to unsubscribe send a message to namedroppers-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 May 20 17:47: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 RAA28344 for ; Thu, 20 May 2004 17:47:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQvLa-0000uR-Dk for namedroppers-data@psg.com; Thu, 20 May 2004 21:45:02 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQvLZ-0000tt-5D for namedroppers@ops.ietf.org; Thu, 20 May 2004 21:45:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7DC5113951 for ; Thu, 20 May 2004 21:45:00 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Roy Badami of "Thu, 20 May 2004 20:26:24 +0100." <16557.1632.918749.103466@giles.gnomon.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 20 May 2004 21:45:00 +0000 Message-Id: <20040520214500.7DC5113951@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 was just trying to counter what I perceived to be a possible sense > of "there's no possible reason why this issue should botther you" in > some of the comments in this thread. there's no possible reason why this issue should bother you. if someone wants to enumerate the secondlevel names in a tld, they will do it using well understood data mining techniques including watching log files from busy mail and web and proxy servers, surfing the PTR's, spidering the web itself, or buying the ISC Domain Survey four times a year, or perhaps all of the above. a tld operator's lack of desire for such enumeration cannot prevent it. and dnssec's lack of compatibility with the well known BINDist hack of turning off AXFR access or limiting it to well known addresses or TSIGs, does not mean that dnssec has something wrong with it. > There is a clear real-world difference between allowing queries and > allowing a wholesale download of the zone file. There is most > definitely a difference in the real world between a theortical attack > and a practical attack. but there is no real-world difference in enumerability between a tld that allows open AXFR, a tld that does not allow AXFR, a tld that uses dnssec (with NSEC chains), or a tld that does not use dnssec (or uses it without NSEC chains, as in the NSEC2 proposal). if you don't believe this, then tell me a tld and i'll enumerate it for you, without using NSEC chains or AXFR. it could take me a few months depending on how many sites therein are linked from other sites, and how many PTRs have target names under that tld, but sooner or later i'll get it, either all of it, or enough to cover the part of your "whois" data that you think preventing AXFR (and not using NSEC) is keeping others from having an index to. > These differences may well affect what a registry feels comfortable > doing in terms of European data protection legislation. if you'll give me the phone numbers of the legislators in question, i'll be happy to call them and tell them that because the names are exposed in other contexts, that the internet is already in violation of their data protection standards. perhaps they'll decide to disconnect europe from the internet in order to keep this data safe. > I'm assuming that the DNSSECbis document set is not going to be > derailed at this late stage -- it's hardly as if the NXT record is > some new idea which has been pushed through with little discussion, > and the world has been waiting long enough for deployable DNSSEC. > > But if at a later date a significant number of ccTLD registries decide > that the issue is a showstopper for them, then I would hope that the > IETF will provide a suitable forum for these issues to be explored > further. that's a reasonable middle ground, in my opinion. -- to unsubscribe send a message to namedroppers-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 May 20 17:52: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 RAA28848 for ; Thu, 20 May 2004 17:52:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQvQh-0001kz-5l for namedroppers-data@psg.com; Thu, 20 May 2004 21:50:19 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQvQf-0001kU-6V for namedroppers@ops.ietf.org; Thu, 20 May 2004 21:50:17 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i4KLoD021407; Fri, 21 May 2004 04:50:14 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i4KLo2Fd012724; Fri, 21 May 2004 04:50:03 +0700 (ICT) From: Robert Elz To: Roy Badami cc: Jim Reid , Marcos Sanz/Denic , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <16556.39523.357152.92612@giles.gnomon.org.uk> References: <16556.39523.357152.92612@giles.gnomon.org.uk> <16556.34807.204862.570446@giles.gnomon.org.uk> <18095.1085051220@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 May 2004 04:50:02 +0700 Message-ID: <15226.1085089802@munnari.OZ.AU> 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 Date: Thu, 20 May 2004 12:45:39 +0100 From: Roy Badami Message-ID: <16556.39523.357152.92612@giles.gnomon.org.uk> | I suspect that most of the concerns relate to the EU Data Protection | Directive (and the transposed legislation of the member states), | rather than anything to do with copyright. No, that's clearly not the case. There's nothing at all in the DNS which can in any way violate any data protection acts - nor would it make sense for anyone to attempt to legislate in that direction (and even if you're one who assumes that legislatures have no sense at all, this would be even further away than that). What's in the DNS is exactly what the owners of the data desire to advertise - it's put there at their request. This is just like a business directory, or the phone book - except the DNS contains (unless someone of their own volition adds the little used LOC, RP, etc records) even less personal type data than those other directories do. There doesn't need to be any way at all to go from anything in the DNS to any kind of data that identifies in any way the owner of the domain, or provides any information about that entity (whether there should be a way to do that is a different issue - the DNS itself mandates nothing like that - of course, organisations are free to ad that kind of info if they desire, either directly in RP, LOT, TXT etc, or indirectly, via www.domain web pages). This isn't a case of someone collecting various personal data, and then making it all available to anyone who asks (whois might be, but that's not the issue here, not in any way at all - and irrespective of whether or not whois is being "fixed"). The issue here is that some domains, typically domains which sell sub-domains, like to believe that the data they have - ie: the list of names registered, is their personal property, and no-one else should be able to get near it. That's nonsense, and we shouldn't be doing anything to pander to that opinion - if anything, being very explicit that there is no desire at all to attempt to enforce any such notions is exactly what should be being said. 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 May 20 18:01: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 SAA29436 for ; Thu, 20 May 2004 18:01:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQvZY-0003ZW-5d for namedroppers-data@psg.com; Thu, 20 May 2004 21:59:28 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQvZX-0003ZB-22 for namedroppers@ops.ietf.org; Thu, 20 May 2004 21:59:27 +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 i4KLxPEJ021169 for ; Thu, 20 May 2004 23:59:25 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4KLxPJ07088 for ; Thu, 20 May 2004 23:59:25 +0200 (MEST) Message-Id: <200405202159.i4KLxPJ07088@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: this week in dnssec, 10 years ago. In-reply-to: Your message of "Thu, 20 May 2004 23:24:29 +0200." <13DD462A-AAA4-11D8-91E9-000393DA2D46@ripe.net> 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: <7080.1085090291.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 20 May 2004 23:59:25 +0200 From: Peter Koch 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 Surely someone would have come up with the following "solution" sooner or later, I just didn't know it was as soon as 10 years back :-) > > Subject: Thought on non-existant and wildcarded names > > Date: Mon, 09 May 94 14:55:42 -0400 > > If it is desired to block NX walking, the recommended method is to add a > > zone wide wildcard of the KEY type which asserts the nonexistence of Obviously a wildcard in the "registry zone" eliminates the need for any NXDOMAIN response and thus any "link" information coming from NSEC RRs, so that the "pointer" part may carry bogus information. Now, that's replacing the devil with ... and I can't believe me writing this. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 20 18:31: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 SAA02461 for ; Thu, 20 May 2004 18:31:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQw1d-0007r0-78 for namedroppers-data@psg.com; Thu, 20 May 2004 22:28:29 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQw1b-0007qj-M7 for namedroppers@ops.ietf.org; Thu, 20 May 2004 22:28:28 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id D85191078D4; Thu, 20 May 2004 22:28:26 +0000 (GMT) Message-ID: <40AD318F.3090800@algroup.co.uk> Date: Thu, 20 May 2004 23:30:39 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <20040520214500.7DC5113951@sa.vix.com> In-Reply-To: <20040520214500.7DC5113951@sa.vix.com> X-Enigmail-Version: 0.83.6.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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>I was just trying to counter what I perceived to be a possible sense >>of "there's no possible reason why this issue should botther you" in >>some of the comments in this thread. > > > there's no possible reason why this issue should bother you. > > if someone wants to enumerate the secondlevel names in a tld, they will > do it using well understood data mining techniques including watching > log files from busy mail and web and proxy servers, surfing the PTR's, > spidering the web itself, or buying the ISC Domain Survey four times a > year, or perhaps all of the above. > > a tld operator's lack of desire for such enumeration cannot prevent it. > and dnssec's lack of compatibility with the well known BINDist hack of > turning off AXFR access or limiting it to well known addresses or TSIGs, > does not mean that dnssec has something wrong with it. It is my understanding that what NSEC2 tries to achieve is to make enumeration no easier than it is with plain DNS. Clearly there is no point in doing more than this. 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 Thu May 20 18:55: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 SAA03901 for ; Thu, 20 May 2004 18:55:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQwOz-000BQT-HT for namedroppers-data@psg.com; Thu, 20 May 2004 22:52:37 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQwOs-000BPS-SL for namedroppers@ops.ietf.org; Thu, 20 May 2004 22:52:31 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BQwOn-0002Fe-00 for ; Fri, 21 May 2004 00:52:30 +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 ; Fri, 21 May 2004 00:52:25 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 May 2004 00:52:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 22:52:22 +0000 (UTC) Lines: 33 Message-ID: References: <10997.1084989664@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 217.215.27.65 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040405 Firefox/0.8) 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 Jim Reid rfc1035.com> writes: > And while it would be nice if DNSSEC didn't make zone traversal > easy -- like your now dead NO record draft tried to do -- it's > so far been too hard to find a way of doing that which works for > all possibilities for authenticated proof of non-existence. If > there weren't so many tricky corner cases, especially with > wildcards, no doubt something like your NO record would have > been incorporated into the current drafts. What was wrong with the wildcard handling in the expired NO draft? I don't recall pending technical issues last time. Anyway, solving wildcard handling is a simple technical matter, despite its complexities. I haven't seen anyone seriously suggesting it is strictly impossible to solve it. > Simon> The alternatives to NSEC do reduce the attack vector into > Simon> an offline dictionary attack, which I believe is an > Simon> acceptable risk. > > If the rewards for a successful attack are high enough, this isn't an > acceptable risk. How much would it cost to implement SHA-1 in > hardware, assuming there aren't chips that can do this already? My point was that nobody would bother to do dictionary attacks on SHA-1 hashes when they can do online dictionary attacks more easily. And online dictionary attacks cannot be prevented currently. So the attack has been mitigated beyond other currently acceptably attack vectors. Regards, 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 Thu May 20 19:24: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 TAA05241 for ; Thu, 20 May 2004 19:24:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQwql-000G9f-Q4 for namedroppers-data@psg.com; Thu, 20 May 2004 23:21:19 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQwqk-000G9S-HU for namedroppers@ops.ietf.org; Thu, 20 May 2004 23:21:18 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BQwqj-0002gg-00 for ; Fri, 21 May 2004 01:21:17 +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 ; Fri, 21 May 2004 01:21:17 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 May 2004 01:21:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 23:21:14 +0000 (UTC) Lines: 28 Message-ID: References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> <19443.1085009564@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 217.215.27.65 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040405 Firefox/0.8) 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 Robert Elz munnari.OZ.AU> writes: > ps: the section in question in the security considerations shouldn't be > there at all - not just the final sentence of it, the whole thing. There > is no security implication in being able to find out the names in a DNS > zone file. That's the point of the DNS. There can be security implications in finding out names of hosts in a domain, without knowing the names in advance. See for instance: 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 Yes, the attack requires weaknesses in other applications, but the point is that access to the information about names in a domain, acquired via zone transfers, helped an attacker. This still holds, for new not yet public weaknesses in various applications. Perhaps core of the problem is to realize that public data, handled in some ways, can become a privacy or security issue, however paradoxical it may sound at first. A nice write-up that expand on this theme is: http://www.cs.uwyo.edu/~rex/privacy.html Regards, 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 Thu May 20 20:01: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 UAA07186 for ; Thu, 20 May 2004 20:01:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQxQO-000Lfl-O7 for namedroppers-data@psg.com; Thu, 20 May 2004 23:58:08 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQxQN-000LfK-Gu for namedroppers@ops.ietf.org; Thu, 20 May 2004 23:58:07 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i4KNw2B1022584; Thu, 20 May 2004 16:58:03 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 May 2004 16:58:02 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ben Laurie'" , namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 16:57: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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Interesting. I am trying to work out the reason for the hash iterations. Let us call the set of names in the zone D = {d0, d1, d2, d3 ... dn} The problem is to be able to enumerate the inverse of the set D' = { ]d0-d1[, ]d1-d2[ ... ]dn-d0[ } It suffices to present one member of D' to prove that any given domain is not a member of D. To describe a member of D we simply specify dx, dx+1 So what you are saying is that we do not need to deal with D, we can apply a one way function... HD = {H(d0), H(d1), ... H(dn) } HD' = { { ]H(d0)-H(d1)[, ]H(d1)-H(d2)[ ... ]H(dn)-H(d0)[ } So why do we need to specify more than H(dx), (H(dx+1)) ??? -- to unsubscribe send a message to namedroppers-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 May 20 20:41: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 UAA08889 for ; Thu, 20 May 2004 20:41:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQy4C-0002Hp-RO for namedroppers-data@psg.com; Fri, 21 May 2004 00:39:16 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQy46-0002HR-O9 for namedroppers@ops.ietf.org; Fri, 21 May 2004 00:39:10 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 3B03AA863 for ; Fri, 21 May 2004 00:39:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i4L0d7tN059686; Fri, 21 May 2004 10:39:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200405210039.i4L0d7tN059686@drugs.dv.isc.org> To: Peter Koch Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: this week in dnssec, 10 years ago. In-reply-to: Your message of "Thu, 20 May 2004 23:59:25 +0200." <200405202159.i4KLxPJ07088@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Fri, 21 May 2004 10:05:31 +1000 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 > Surely someone would have come up with the following "solution" sooner or > later, I just didn't know it was as soon as 10 years back :-) > > > > Subject: Thought on non-existant and wildcarded names > > > Date: Mon, 09 May 94 14:55:42 -0400 > > > > If it is desired to block NX walking, the recommended method is to add a > > > zone wide wildcard of the KEY type which asserts the nonexistence of > > Obviously a wildcard in the "registry zone" eliminates the need for any > NXDOMAIN response and thus any "link" information coming from NSEC RRs, so > that the "pointer" part may carry bogus information. Now, that's replacing th > e > devil with ... and I can't believe me writing this. > > -Peter Actually it doesn't "registry zones" are treated like any other zone for validation. The wildcard response still need the NOQNAME proof to be sent to prove that the wildcard is actually the correct response and not a forged the response. The NOQNAME proof will also prove if it is the correct wildcard answering the query or not. NSEC2 does not supply the information to determine if the correct wildcard has been presented. This is in the owner and next names of the NOQNAME NSEC proof. NXDOMAIN needs two proofs to be sent NOQNAME and NOWILDCARD (these may be the same NSEC record). A wildcard response remove the need for the NOWILDCARD proof. For NSEC2 to work you would also have to send additional records. If the qname was a.b.c.d.e.f.example the NOQNAME proof becomes. one of: f.example does not exist. or a proof that f.example exist and a proof that e.f.example does not exist. or a proof that e.f.example exists and a proof that d.e.f.example does not exist. or a proof that d.e.f.example exists and a proof that c.d.e.f.example does not exist. or a proof that c.d.e.f.example exist and a proof that b.d.e.f.example does not exist. or a.b.c.d.e.f.example does not exist and a proof that b.d.e.f.example exist. The additional proof is to prove that there is no delegation, empty non-terminal. From the above you can determine the correct wildcard that should be matched or the correct NOWILDCARD proof to look for. NSEC2 would also require a NSEC record for every empty non-terminal node. ENUM will love this:-). Under NSEC there is implicit information buried in the names. This has to be made explicit under NSEC2. Note: This is *just* a technical analysis of the proposal. Mark > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 20 20:42: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 UAA08924 for ; Thu, 20 May 2004 20:42:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQy5B-0002RP-L3 for namedroppers-data@psg.com; Fri, 21 May 2004 00:40:17 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQy52-0002Py-Lr for namedroppers@ops.ietf.org; Fri, 21 May 2004 00:40:08 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4L0e5lZ004096 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 21 May 2004 00:40:07 GMT (envelope-from roy+dated+1087692074.eb0342@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4L0e4so021002 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 May 2004 01:40:05 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4L0fEuq068627 for ; Fri, 21 May 2004 01:41:14 +0100 (BST) (envelope-from roy+dated+1087692074.eb0342@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4L0fEKe068626 for namedroppers@ops.ietf.org; Fri, 21 May 2004 01:41:14 +0100 (BST) (envelope-from roy+dated+1087692074.eb0342@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 21 May 2004 01:41:13 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16557.20521.83937.65985@giles.gnomon.org.uk> Date: Fri, 21 May 2004 01:41:13 +0100 To: Olaf Kolkman Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> References: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> 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-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 >>>>> "Olaf" == Olaf Kolkman writes: Olaf> As far as I understand the security properties of the Olaf> proposed technology are such that changes are needed to the Olaf> protocol as in DNSSEC-bis. This means that we have to Olaf> introduce a flag day. It's not obviously (to me) an incredibly nasty flag day. If there is a real desire to do this subsequently, zones can be given a choice of publishing NSEC or NSEC2 records or both. The flag day is then the day on which publishing NSEC records ceases to be mandatory. On this day, old resolvers which don't understand the NSEC2 RR will start getting resolution failures for non-existent domains, rather than getting a clean NXDOMAIN answer. Whilst not entirely ideal behaviour, this is potentially a manageable scenario... -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 May 20 21:25: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 VAA11183 for ; Thu, 20 May 2004 21:25:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQyjm-0009mo-VO for namedroppers-data@psg.com; Fri, 21 May 2004 01:22:14 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQyjm-0009mb-4x for namedroppers@ops.ietf.org; Fri, 21 May 2004 01:22:14 +0000 Received: by sa.vix.com (Postfix, from userid 716) id E538113DF0; Fri, 21 May 2004 01:22:13 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: New versions of DNSSECbis drafts posted References: From: Paul Vixie Date: 21 May 2004 01:22:13 +0000 In-Reply-To: Message-ID: Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk erik@zoneedit.com (Erik Aronesty) writes: > Quick question: if ip-spoofing were impossible, would DNSSEC be obsolete? no. dnssec creates end to end trust between a zone owner/editor/publisher and a resolver. attacks it guards against include not only ip spoofing, but corrupting forwarders like NAT boxes, and corrupt authority servers. -- Paul Vixie -- to unsubscribe send a message to namedroppers-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 May 20 22:04:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12721 for ; Thu, 20 May 2004 22:04:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQzM3-000G1M-5h for namedroppers-data@psg.com; Fri, 21 May 2004 02:01:47 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BQzLz-000G0h-Qp for namedroppers@ops.ietf.org; Fri, 21 May 2004 02:01:44 +0000 Received: (qmail 75985 invoked from network); 21 May 2004 02:07:11 -0000 Received: from yahoobb219001188012.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.12) by necom830.hpcl.titech.ac.jp with SMTP; 21 May 2004 02:07:11 -0000 Message-ID: <40AD6407.4030600@necom830.hpcl.titech.ac.jp> Date: Fri, 21 May 2004 11:05:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: New versions of DNSSECbis drafts posted References: In-Reply-To: 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 Paul Vixie wrote: > erik@zoneedit.com (Erik Aronesty) writes: > > >>Quick question: if ip-spoofing were impossible, would DNSSEC be obsolete? Yes. > no. dnssec creates end to end trust between a zone owner/editor/publisher > and a resolver. attacks it guards against include not only ip spoofing, but > corrupting forwarders like NAT boxes, and corrupt authority servers. Anything behind NAT does not worth considering. Corrupt authority servers are just as harmful and likely as corrupt resolvers. Moreover, complexity of DNSSEC increases the possibility of resolver corrupts, a lot. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 20 22:37: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 WAA13879 for ; Thu, 20 May 2004 22:37:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BQzs5-000L5B-BJ for namedroppers-data@psg.com; Fri, 21 May 2004 02:34:53 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQzs4-000L4w-Fq for namedroppers@ops.ietf.org; Fri, 21 May 2004 02:34:52 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 6DFFAA863 for ; Fri, 21 May 2004 02:34:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i4L2YZoS083892; Fri, 21 May 2004 12:34:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200405210234.i4L2YZoS083892@drugs.dv.isc.org> To: Simon Josefsson Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Proposal to fix NSEC In-reply-to: Your message of "Thu, 20 May 2004 23:21:14 GMT." Date: Fri, 21 May 2004 12:34:35 +1000 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 > Robert Elz munnari.OZ.AU> writes: > > > ps: the section in question in the security considerations shouldn't be > > there at all - not just the final sentence of it, the whole thing. There > > is no security implication in being able to find out the names in a DNS > > zone file. That's the point of the DNS. > > There can be security implications in finding out names of hosts in a domain, > without knowing the names in advance. See for instance: > > 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 > > Yes, the attack requires weaknesses in other applications, but the point is t > hat > access to the information about names in a domain, acquired via zone transfer > s, > helped an attacker. This still holds, for new not yet public weaknesses in > various applications. It also demonstrates that there are security implications for *not* knowing all the names and attached data in advance. If you want to allow rlogins from a namespace you have to have a local copy of that namespace. This was a case were allowing AXFR *fixed* part of the security issues as it allowed you to get the local copy. > Perhaps core of the problem is to realize that public data, handled in some > ways, can become a privacy or security issue, however paradoxical it may soun > d > at first. A nice write-up that expand on this theme is: > > http://www.cs.uwyo.edu/~rex/privacy.html > > Regards, > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 20 22:49: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 WAA14425 for ; Thu, 20 May 2004 22:49:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR04Y-000NMH-Qm for namedroppers-data@psg.com; Fri, 21 May 2004 02:47:46 +0000 Received: from [199.239.208.244] (helo=199.239.208.244) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR04P-000NKd-Ud for namedroppers@ops.ietf.org; Fri, 21 May 2004 02:47:38 +0000 Received: from [24.239.105.131] (helo=x) by 199.239.208.244 with asmtp (Exim 3.36 #1) id 1BR04O-0005d5-00; Thu, 20 May 2004 22:47:36 -0400 Reply-To: From: "Sal Mangiapane" To: "Loomis, Rip" Cc: Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 22:47:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00, RCVD_NUMERIC_HELO autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > This blatantly ignores the completely common case where > > the set of recursive/caching/resolving nameservers for an > > organization are separate from the set of authoritative > > nameservers These DNS servers can receive a trusted response but could not respond to the originating request with a trusted (signed) answer. They can't because they are unknown by authoritative nameservers. I'm thinking they are outside the chain of trust. What am I missing? Will these become obsolete? Regards, Sal Salvatore Mangiapane -- to unsubscribe send a message to namedroppers-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 May 21 01:04: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 BAA21627 for ; Fri, 21 May 2004 01:04:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR29D-000Is5-OI for namedroppers-data@psg.com; Fri, 21 May 2004 05:00:43 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR29C-000IpQ-I0 for namedroppers@ops.ietf.org; Fri, 21 May 2004 05:00:42 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 6F0EE107919; Fri, 21 May 2004 05:00:41 +0000 (GMT) Message-ID: <40AD8D80.9070700@algroup.co.uk> Date: Fri, 21 May 2004 06:02:56 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: In-Reply-To: X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > Interesting. > > I am trying to work out the reason for the hash iterations. > > > Let us call the set of names in the zone > D = {d0, d1, d2, d3 ... dn} > > The problem is to be able to enumerate the inverse of the set > D' = { ]d0-d1[, ]d1-d2[ ... ]dn-d0[ } > > It suffices to present one member of D' to prove that any given domain is > not a member of D. > > To describe a member of D we simply specify dx, dx+1 > > > So what you are saying is that we do not need to deal with D, we can apply a > one way function... > > HD = {H(d0), H(d1), ... H(dn) } > > HD' = { { ]H(d0)-H(d1)[, ]H(d1)-H(d2)[ ... ]H(dn)-H(d0)[ } > > So why do we need to specify more than H(dx), (H(dx+1)) ??? To increase the cost of dictionary attacks. 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 Fri May 21 04:39: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 EAA15188 for ; Fri, 21 May 2004 04:39:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR5Sn-0000ld-GA for namedroppers-data@psg.com; Fri, 21 May 2004 08:33:09 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR5Sj-0000l9-Np for namedroppers@ops.ietf.org; Fri, 21 May 2004 08:33:05 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BR5Si-0002Tn-00 for ; Fri, 21 May 2004 10:33:04 +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 ; Fri, 21 May 2004 10:33:04 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 May 2004 10:33:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: this week in dnssec, 10 years ago. Date: Fri, 21 May 2004 10:33:02 +0200 Lines: 40 Message-ID: References: <200405202159.i4KLxPJ07088@grimsvotn.TechFak.Uni-Bielefeld.DE> <200405210039.i4L0d7tN059686@drugs.dv.isc.org> 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:lg4VVdSO3cxXn+X/orsWY97SqAU= 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 Mark Andrews writes: >> Surely someone would have come up with the following "solution" sooner or >> later, I just didn't know it was as soon as 10 years back :-) >> >> > > Subject: Thought on non-existant and wildcarded names >> > > Date: Mon, 09 May 94 14:55:42 -0400 >> >> > > If it is desired to block NX walking, the recommended method is to add a >> > > zone wide wildcard of the KEY type which asserts the nonexistence of >> >> Obviously a wildcard in the "registry zone" eliminates the need for any >> NXDOMAIN response and thus any "link" information coming from NSEC RRs, so >> that the "pointer" part may carry bogus information. Now, that's replacing th >> e >> devil with ... and I can't believe me writing this. >> >> -Peter > > Actually it doesn't "registry zones" are treated like any > other zone for validation. > > The wildcard response still need the NOQNAME proof to be > sent to prove that the wildcard is actually the correct > response and not a forged the response. The NOQNAME proof > will also prove if it is the correct wildcard answering the > query or not. > > NSEC2 does not supply the information to determine if the > correct wildcard has been presented. This is in the owner > and next names of the NOQNAME NSEC proof. No, I believe sufficient information is present. To verify that any wildcard RR doesn't cover the queried name, you compute a few SHA-1 hashes on the only possible wildcard owner names that can be relevant, and compare with the additional NO records returned. This logic was described in the NO draft. Regards, 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 Fri May 21 04:48: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 EAA15974 for ; Fri, 21 May 2004 04:48:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR5f5-0002S1-MF for namedroppers-data@psg.com; Fri, 21 May 2004 08:45:51 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR5f4-0002RV-Jf for namedroppers@ops.ietf.org; Fri, 21 May 2004 08:45:50 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BR5f3-0006h9-Ka; Fri, 21 May 2004 10:45:49 +0200 In-Reply-To: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> To: Olaf Kolkman Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Fri, 21 May 2004 10:45:47 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 21.05.2004 10:45:49, Serialize complete at 21.05.2004 10:45:49 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 Olaf, > If I do not see rough consensus on taking up NSEC2 as a work item by > June 1 I'll reject this as a work item. Thanks to the chairs for hearing the voices of those stating they have a deployment problem with the specification in its current form. While it is true that DNSSec has a long and painful story tracking back to 10 years ago, that's plainly because the protocol itself isn't so easy as thought in the beginning. I wouldn't like to see these kind of retrospective arguments bound to the future of proposals to solve the NSEC traversal. 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: From owner-namedroppers@ops.ietf.org Fri May 21 04:57: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 EAA16336 for ; Fri, 21 May 2004 04:57:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR5ne-0004SQ-S6 for namedroppers-data@psg.com; Fri, 21 May 2004 08:54:42 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR5nd-0004Rs-0h for namedroppers@ops.ietf.org; Fri, 21 May 2004 08:54:41 +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 i4L8sbrd020344; Fri, 21 May 2004 09:54:37 +0100 (BST) To: Roy Badami Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Your message of "Thu, 20 May 2004 20:26:24 BST." <16557.1632.918749.103466@giles.gnomon.org.uk> Date: Fri, 21 May 2004 09:54:37 +0100 Message-ID: <20343.1085129677@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Badami writes: Roy> If ccTLD operators suggest that this might be an issue for Roy> them, then it is IMHO unreasonable for anyone (other than a Roy> lawyer versed in this area) to tell them they are wrong. I don't believe anyone here is claiming they are wrong or that their concerns about EU directives are invalid. As you say only a clueful lawyer can make that determination. I do think it's wrong however to attempt to solve layer 9 problems by redesigning a protocol. -- to unsubscribe send a message to namedroppers-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 May 21 05:28: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 FAA18309 for ; Fri, 21 May 2004 05:28:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR6H8-000BG5-DN for namedroppers-data@psg.com; Fri, 21 May 2004 09:25:10 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR6H7-000BFj-23 for namedroppers@ops.ietf.org; Fri, 21 May 2004 09:25:09 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id C367F107AE8; Fri, 21 May 2004 09:25:07 +0000 (GMT) Message-ID: <40ADCB7D.3030001@algroup.co.uk> Date: Fri, 21 May 2004 10:27:25 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <20040520214500.7DC5113951@sa.vix.com> <40AD318F.3090800@algroup.co.uk> In-Reply-To: <40AD318F.3090800@algroup.co.uk> X-Enigmail-Version: 0.83.6.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 Ben Laurie wrote: > Paul Vixie wrote: > >>> I was just trying to counter what I perceived to be a possible sense >>> of "there's no possible reason why this issue should botther you" in >>> some of the comments in this thread. >> >> >> >> there's no possible reason why this issue should bother you. >> >> if someone wants to enumerate the secondlevel names in a tld, they will >> do it using well understood data mining techniques including watching >> log files from busy mail and web and proxy servers, surfing the PTR's, >> spidering the web itself, or buying the ISC Domain Survey four times a >> year, or perhaps all of the above. >> >> a tld operator's lack of desire for such enumeration cannot prevent it. >> and dnssec's lack of compatibility with the well known BINDist hack of >> turning off AXFR access or limiting it to well known addresses or TSIGs, >> does not mean that dnssec has something wrong with it. > > > It is my understanding that what NSEC2 tries to achieve is to make > enumeration no easier than it is with plain DNS. Clearly there is no > point in doing more than this. Actually, I'll take that back, there may be a point in doing more, but there's certainly an argument that suggests that its reasonable to expect not to be in a worse position by virtue of switching from DNS to DNSSEC. 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 Fri May 21 08:48: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 IAA28138 for ; Fri, 21 May 2004 08:48:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR9Nb-000JrY-Ub for namedroppers-data@psg.com; Fri, 21 May 2004 12:44:03 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR9Na-000JrI-TV for namedroppers@ops.ietf.org; Fri, 21 May 2004 12:44:03 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 029F71FDCB; Fri, 21 May 2004 13:44:02 +0100 (BST) Date: Fri, 21 May 2004 13:26:56 +0100 From: Alex Bligh Reply-To: Alex Bligh To: namedroppers@ops.ietf.org Cc: Alex Bligh , paul@vix.com Message-ID: <261518784.1085146016@[192.168.100.5]> X-Mailer: Mulberry/3.1.1 (Win32) Subject: Re: Proposal to fix NSEC X-Resent-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > i agree with ted. dns is a publication mechanism, and if you don't want > something published you probably shouldn't be putting it into dns at all. > and, if your only way to keep whois safe is to hide its index, then you > have probably got other troubles. parts of the "index" are exposed every > day in server logs or in-addr.arpa/ip6.arpa walks. With respect Paul, I think you are handwaving. The wish to have data published in response to a specific query is not necessarily commensurate with the wish to have it published under any circumstances whatsoever. Many people write emails, and thus publish their email addresses. This does not necessarily mean they want them compiled into lists of email addresses, associated with other data, and sold as a database. Current DNS protocol and servers allow a granularity of policy decision on what gets published, when, and to whom. The currently proposals for DNSSEC would remove the ability of DNSSEC users to take advantage of that granularity (i.e. they reduce current functionality that is in use, and wanted, at least by a significant subset of users) Whether or not making use of a function that prevents publication of entire zone files is desirable is a policy question, and not a protocol question. However, given that the current DNSSEC proposals remove functionality that is in use (prevention of publication of entire zone files), it's worth a few of lines describing why removal of that functionality is important. The problem has been described as simply a legal problem. Whilst indeed there are EU law considerations, I am aware that the IETF's approach to legal problems in the past has often been "fix the law"; and indeed, often rightly so. However, the problem goes beyond that. In this instance, in my opinion, the law is merely a symptom of what people want. RFC1591 talks about the local internet community. In the UK, and the rest of the EU, people are perhaps more sensitive to privacy issues than they seem to be in the US. Hence, if you sign up for a phone here, you have the (legal) right to have your number listed in directory enquiries, but not to have your name included in a database of names and phone numbers sold to others by the phone company, and indeed the phone company has an obligation not to distribute the data for purposes other than those for which it collected it. That legal right is based on widely held beliefs about privacy. I picked the phone book example because it's the closest I could find to DNS. And there is a strongly held local internet community (in an RFC1591 sense) views that such privacy should continue to apply. See for instance item 8 at: http://tinyurl.com/2l59u I'm posting this rest of this message in a personal capacity, but as a director of Nominet since it started, and a member of its policy advisory board, I'll submit the following: the issue of zonefile protection has been a very significant issue for stakeholders, and an issue on which we (Nominet) have spent a considerable amount of time and money. And the reason we've done this is not for narrow commercial advantage, but because over the past years we've come to realize it's an important matter to the local community. That's why we are concerned about protocol changes which remove our ability to do protect zonefiles. My understanding is that several other ccTLDs have the same concerns for similar reason. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 09:17: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 JAA29882 for ; Fri, 21 May 2004 09:17:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BR9qq-000PHj-Fa for namedroppers-data@psg.com; Fri, 21 May 2004 13:14:16 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BR9qp-000PGb-8W for namedroppers@ops.ietf.org; Fri, 21 May 2004 13:14:15 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4LDEClZ049202 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 21 May 2004 13:14:13 GMT (envelope-from roy+dated+1087737321.6490cf@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4LDEAso023962 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 May 2004 14:14:11 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4LDFMuq071811 for ; Fri, 21 May 2004 14:15:22 +0100 (BST) (envelope-from roy+dated+1087737321.6490cf@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4LDFLYk071810 for namedroppers@ops.ietf.org; Fri, 21 May 2004 14:15:22 +0100 (BST) (envelope-from roy+dated+1087737321.6490cf@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 21 May 2004 14:15:21 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16558.232.962289.181750@giles.gnomon.org.uk> Date: Fri, 21 May 2004 14:15:20 +0100 To: Alex Bligh Cc: namedroppers@ops.ietf.org, paul@vix.com Subject: Re: Proposal to fix NSEC In-Reply-To: <261518784.1085146016@[192.168.100.5]> References: <261518784.1085146016@[192.168.100.5]> 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-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 >>>>> "Alex" == Alex Bligh writes: Alex> See for instance item 8 at: http://tinyurl.com/2l59u And although Alex doesn't state this explicitly, the PAB minutes available at the URL above seem to indicate that it is Nominet's stated policy that zone file protection takes precedence over DNSSEC deployment. Which means for me (as an end user) that I won't be getting a secure delegation of my .org.uk domain in the foreseeable future... -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 09:47: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 JAA01358 for ; Fri, 21 May 2004 09:47:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRAK3-0005A6-Ei for namedroppers-data@psg.com; Fri, 21 May 2004 13:44:27 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRAJy-000589-0X for namedroppers@ops.ietf.org; Fri, 21 May 2004 13:44:22 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 1C83E1FE6B; Fri, 21 May 2004 14:44:21 +0100 (BST) Date: Fri, 21 May 2004 14:44:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Roy Badami Cc: namedroppers@ops.ietf.org, paul@vix.com, Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <266160138.1085150657@[192.168.100.5]> In-Reply-To: <16558.232.962289.181750@giles.gnomon.org.uk> References: <261518784.1085146016@[192.168.100.5]> <16558.232.962289.181750@giles.gnomon.org.uk> X-Mailer: Mulberry/3.1.1 (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 21 May 2004 14:15 +0100 Roy Badami wrote: > And although Alex doesn't state this explicitly, the PAB minutes > available at the URL above seem to indicate that it is Nominet's > stated policy that zone file protection takes precedence over DNSSEC > deployment. We are constrained by what is legal, and guided by what our stakeholders want. Enumerable zonefiles seem to have problems on both grounds. My assessment is that there is (perhaps wrongly) rather more stakeholder interest in privacy aspects than DNSsec (to which the normal answer is "what?"). > Which means for me (as an end user) that I won't be getting a secure > delegation of my .org.uk domain in the foreseeable future... This would depend in part on whether or not the problem is fixable or workroundable via NSEC2 or some other way. Nominet would love to deploy it, indeed it's been a strategic objective for over a year: http://tinyurl.com/2mk8f Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 10:14: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 KAA03138 for ; Fri, 21 May 2004 10:14:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRAkS-000BOA-Am for namedroppers-data@psg.com; Fri, 21 May 2004 14:11:44 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRAkP-000BNM-6x for namedroppers@ops.ietf.org; Fri, 21 May 2004 14:11:41 +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 i4LEBbrd020852; Fri, 21 May 2004 15:11:37 +0100 (BST) To: Alex Bligh cc: namedroppers@ops.ietf.org, paul@vix.com Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Alex Bligh of "Fri, 21 May 2004 13:26:56 BST." <261518784.1085146016@[192.168.100.5]> Date: Fri, 21 May 2004 15:11:37 +0100 Message-ID: <20851.1085148697@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Alex" == Alex Bligh writes: This discussion is getting off-topic for this list which is supposed to be about DNS protocol issues. Alex> With respect Paul, I think you are handwaving. The wish to Alex> have data published in response to a specific query is not Alex> necessarily commensurate with the wish to have it published Alex> under any circumstances whatsoever. Many people write Alex> emails, and thus publish their email addresses. This does Alex> not necessarily mean they want them compiled into lists of Alex> email addresses, associated with other data, and sold as a Alex> database. With all respect, I think this is hand waving too. Anyone with half a clue will realise that by publishing their email address, they have no control over what others may do with that data. Even when there are supposedly the safeguards of data protection and anti-spam legislation. For instance, by responding to this mail I accept the risk that someone may harvest my address and send me spam even though I don't want them to do that. Going back to DNS, I doubt very much if anyone registering a domain name in a TLD cares or even realises that the whole TLD zone file might be available. Or not as the case may be. They just want their domain name visible through the DNS protocol. Alex> However, the problem goes beyond that. In this instance, in Alex> my opinion, the law is merely a symptom of what people want. A discussion about "what people want" is well off-topic for this list. Alex> That's why we are concerned about protocol Alex> changes which remove our ability to do protect zonefiles. It's still not clear to me what those concerns actually are and why traversing the zone file is such a worry. Maybe I'm just being more stupid than usual. As Paul has pointed out, there are plenty of ways of enumerating a TLD zone today, with or without some flavour of DNSSEC, irrespective of whether zone transfers are possible. If the concern is NSEC records makes whois disclosure easier, then fix whois: that's where the personal data lives after all. That data isn't in the DNS. If it's about copyright, the copyright holder's rights should still apply. Just like record companies sell copyrighted material on (copy-protected) CDs but are able to pursue anyone who illegally duplicates that material. In some respects, zone traversal might actually alleviate the concerns of these TLDs. Suppose you put a delegation into the zone that doesn't have a genuine whois entry or a registrar or end user. The delegated zone has no web server or MX records so nothing other than the domain name itself is ever published. And that's found by walking the NSEC list. If this name pops up in your query logs, voila! The honey trap has found someone who's up to no good and you can set your lawyers on them. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 10: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 KAA03297 for ; Fri, 21 May 2004 10:16:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRAmV-000Bp6-45 for namedroppers-data@psg.com; Fri, 21 May 2004 14:13:51 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRAmO-000Bns-PL for namedroppers@ops.ietf.org; Fri, 21 May 2004 14:13:45 +0000 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.11/8.12.11) with ESMTP id i4LEDf64010869 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 21 May 2004 16:13:41 +0200 To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org Subject: Re: relevent? References: <200405202159.i4KLxPJ07088@grimsvotn.TechFak.Uni-Bielefeld.DE> <200405210039.i4L0d7tN059686@drugs.dv.isc.org> <20040521122333.GA20885@vacation.karoshi.com.> From: Simon Josefsson X-Hashcash: 0:040521:bmanning@vacation.karoshi.com:391125e79b51215c X-Hashcash: 0:040521:namedroppers@ops.ietf.org:9267fb0227db5b9b Date: Fri, 21 May 2004 16:13:40 +0200 In-Reply-To: <20040521122333.GA20885@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Fri, 21 May 2004 12:23:33 +0000") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) 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.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bmanning@vacation.karoshi.com writes: >> No, I believe sufficient information is present. To verify that any >> wildcard RR doesn't cover the queried name, you compute a few SHA-1 >> hashes on the only possible wildcard owner names that can be relevant, > > thats a bit presumptious, don't you think? how can you > possibly determine relevant, possible owner names? I may have misunderstood something. Here is how I perceive things. Consider any query for a non-existing name a.b.c.d.e.f.com in the zone f.com. To prove that a.b.c.d.e.f.com doesn't exist, the server has to return records proving that the following names do not exist: a.b.c.d.e.f.com *.b.c.d.e.f.com *.c.d.e.f.com *.d.e.f.com *.e.f.com *.f.com This is the same for NXT, NSEC and presumably all alternatives as well. With NXT/NSEC, the verifier can read the "next owner name" field of the RRs, and make sure all above names are included in the range of some of the returned RRs. Since alternative solution doesn't have a "next owner name" field, this technique doesn't work. But the above set of possibly relevant owner names is always a small number, so the verifier can compute the hash of each of the above strings and verify that all are included in the range of all NO RRs returned. The only difference in processing is that during each wildcard iteration, you compare the hash of the name instead of the name, with what is stored in the returned RRs. The second complication due to wildcard names is that when the response exists and is a wildcard name, you must also prove that no more specific owner name exists. The logic is a bit different, but I believe there is no problem implementing it with hashed names. Were you thinking of some other problem? Or is my reasoning flawed? Regards, 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 Fri May 21 10: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 KAA04387 for ; Fri, 21 May 2004 10:27:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRAxF-000EC5-6h for namedroppers-data@psg.com; Fri, 21 May 2004 14:24:57 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRAx5-000EAt-9D for namedroppers@ops.ietf.org; Fri, 21 May 2004 14:24:47 +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 i4LEOkIT009598; Fri, 21 May 2004 10:24:46 -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 i4LEOiRw020296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 May 2004 10:24:45 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i4LEOhN3027462; Fri, 21 May 2004 10:24:43 -0400 Subject: Re: Proposal to fix NSEC From: Greg Hudson To: Jim Reid Cc: namedroppers@ops.ietf.org In-Reply-To: <20343.1085129677@gromit.rfc1035.com> References: <20343.1085129677@gromit.rfc1035.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1085149483.15159.65.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 21 May 2004 10:24:43 -0400 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_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2004-05-21 at 04:54, Jim Reid wrote: > I don't believe anyone here is claiming they are wrong or that their > concerns about EU directives are invalid. As you say only a clueful > lawyer can make that determination. I do think it's wrong however to > attempt to solve layer 9 problems by redesigning a protocol. So, I don't support modifying NSEC, but this attitude that legal requirements should never have any impact whatsoever on an IETF protocol is weird. You can't "solve" all layer 9 problems at the layer 9 level. IETF protocols exist to meet people's needs. People have needs for a variety of reasons, including the presence of legal requirements. We certainly have the right to say "we think this need is bogus, or too hard to meet, so we're going to punt on it," but to categorically declare the need out of scope because it's "not technical" is sophistry. -- to unsubscribe send a message to namedroppers-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 May 21 11:02: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 LAA07467 for ; Fri, 21 May 2004 11:02:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRBUv-000Jkw-HF for namedroppers-data@psg.com; Fri, 21 May 2004 14:59:45 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRBUq-000JkF-CT for namedroppers@ops.ietf.org; Fri, 21 May 2004 14:59:40 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 28ECC13DE5 for ; Fri, 21 May 2004 14:33:53 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Ben Laurie of "Fri, 21 May 2004 10:27:25 +0100." <40ADCB7D.3030001@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 21 May 2004 14:33:53 +0000 Message-Id: <20040521143353.28ECC13DE5@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 > > It is my understanding that what NSEC2 tries to achieve is to make > > enumeration no easier than it is with plain DNS. Clearly there is no > > point in doing more than this. > > Actually, I'll take that back, there may be a point in doing more, but > there's certainly an argument that suggests that its reasonable to expect > not to be in a worse position by virtue of switching from DNS to DNSSEC. So, "What Once Were Vices Are Now Habits" hits it fairly close, I guess. I hereby renew my call that someone write a BCP describing the BINDism of rejecting AXFR based on source address or lack-of-TSIG so that this can be called a DNS protocol feature so that DNSSEC can be called incomplete without 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 Fri May 21 11:24: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 LAA08623 for ; Fri, 21 May 2004 11:24:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRBqr-000OIJ-QC for namedroppers-data@psg.com; Fri, 21 May 2004 15:22:25 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRBqc-000OCR-R1 for namedroppers@ops.ietf.org; Fri, 21 May 2004 15:22:11 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 020B41FDCB; Fri, 21 May 2004 16:22:10 +0100 (BST) Date: Fri, 21 May 2004 16:22:06 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jim Reid Cc: namedroppers@ops.ietf.org, paul@vix.com, Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <272028736.1085156526@[192.168.100.5]> In-Reply-To: <20851.1085148697@gromit.rfc1035.com> References: <20851.1085148697@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.1 (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 Jim, --On 21 May 2004 15:11 +0100 Jim Reid wrote: (with apologies for reodering) >>>>>> "Alex" == Alex Bligh writes: > > This discussion is getting off-topic for this list which is supposed > to be about DNS protocol issues. ... > A discussion about "what people want" is well off-topic for this list. The protocol issue at stake is the removal of a piece of functionality (granularity in zonefile protection). I think you agree that much. Whether or not removal of functionality is acceptable depends on the value of that functionality. AIUI Your view (and Paul's) is that it is valueless, and thus removing it doesn't matter. I find it hard to see how you can on the one hand assert this, and on the other describe as off-topic those attempting to explain to you the value they have. Functionality does not exist in an abstract space. What people want from their protocols (what is useful vs. useless functionality) surely drives what gets included and what doesn't. > For instance, by responding to this mail I accept the risk that > someone may harvest my address and send me spam even though I don't > want them to do that. Yep. But I am guessing you wouldn't want psg.com as list operator to be complicit in it. > Going back to DNS, I doubt very much if anyone > registering a domain name in a TLD cares or even realises that the > whole TLD zone file might be available. That isn't what they tell us. > Alex> That's why we are concerned about protocol > Alex> changes which remove our ability to do protect zonefiles. > > It's still not clear to me what those concerns actually are and why > traversing the zone file is such a worry. Maybe I'm just being more > stupid than usual. As Paul has pointed out, there are plenty of ways > of enumerating a TLD zone today, with or without some flavour of > DNSSEC, irrespective of whether zone transfers are possible. Paul has asserted out that a third party can make a partial, non-shapshot, list of TLD zonefile contents over months. I don't dispute that. If I spent three months on it, I bet I could work out a way to steal a substantial proportion of your possessions. That doesn't make it either right, or legal, or desirable, for your landlord to decide that there is thus little point in putting a lock on your door. Despite the fact that "bad things happen", the zonefile operator does not need to be complicit in it or make it easier. > If the > concern is NSEC records makes whois disclosure easier, then fix whois: > that's where the personal data lives after all. > If it's about copyright, the copyright holder's rights should > still apply. IANAL but the difference AIUI is that under the proposed protocol, one would be publishing the compilation (in which separate copyright exists) oneself. However, I don't want to reduce this to a legal argument as for me, at least, that's only one portion of the argument. The fact is (see references) stateholders in certain ccTLDs do not wish the zonefile to be published by the ccTLD operator. > honey trap Easy enough without DNSSEC. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 11:34: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 LAA09436 for ; Fri, 21 May 2004 11:34:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRC0T-000PwB-VT for namedroppers-data@psg.com; Fri, 21 May 2004 15:32:21 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRC0M-000PvC-PC for namedroppers@ops.ietf.org; Fri, 21 May 2004 15:32:14 +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 i4LFWDwT019847 for ; Fri, 21 May 2004 17:32:13 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4LFWD809985 for ; Fri, 21 May 2004 17:32:13 +0200 (MEST) Message-Id: <200405211532.i4LFWD809985@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: Proposal to fix NSEC In-reply-to: Your message of "Thu, 20 May 2004 10:45:16 EDT." 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: <9981.1085153532.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Fri, 21 May 2004 17:32:13 +0200 From: Peter Koch 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 Derek Atkins wrote: > Even if modern TLD CPUs can handle 10,000 RSA encryptions per second > (my laptop tops out at around 2,000 with full-bore CPU usage), that > just means I need to send you 10,000 requests per second. That's you're right that expensive responses ease DoS, but the potential is there already. Even without malicious intent one would want to evaluate the current NXDOMAIN/referral ratio to estimate the resources needed under "normal" operations. Shouldn't be as bad as for the root servers. For reaction to DoS it was already suggested to start dropping answers if the number of NXDOMAIN responses grow over a certain threshold. > The problem is that it's just too prone to DoS attacks.... Which is BAD. I'm not saying it's easy. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 11:42: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 LAA09738 for ; Fri, 21 May 2004 11:42:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRC7z-0001JF-5l for namedroppers-data@psg.com; Fri, 21 May 2004 15:40:07 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRC7t-0001Hh-8S for namedroppers@ops.ietf.org; Fri, 21 May 2004 15:40:01 +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 i4LFe063021162 for ; Fri, 21 May 2004 17:40:00 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4LFe0210017 for ; Fri, 21 May 2004 17:40:00 +0200 (MEST) Message-Id: <200405211540.i4LFe0210017@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: Proposal to fix NSEC 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: <10015.1085153999.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Fri, 21 May 2004 17:39:59 +0200 From: Peter Koch 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 {responding to Olaf and Ben in one message} Olaf Kolkman wrote: > There is no reason why one part of a zone cannot be signed with zone > signing key 1 and another > signed with zone signing key 2. There is no need for signaling. right, but if both keys are equally applicable a compromised "negative" key (the one used for online signing) could be used to sign not only fake negative responses but also fake DS RRs. The first can ``only'' be used for DoS (leaving aside corner cases of DNS tree walking). Whether this matters depends on whether one is willing to accept the risk. Ben Laurie wrote: > denial of the existence of the particular domain, rather than messing > with NSEC records. If you had a signed denial, then the easy way to > signal it is to have an RR that is specifically for that purpose (that > is, when you receive a NOTHISDOESNTEXIST RR you expect it to be signed > with the special key used for that purpose alone). the advantage of "messing with NSEC" is that it's there while any new RR type needs more work. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 12:00: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 MAA10687 for ; Fri, 21 May 2004 12:00:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRCOv-0004de-Ux for namedroppers-data@psg.com; Fri, 21 May 2004 15:57:37 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRCOq-0004Y2-Er for namedroppers@ops.ietf.org; Fri, 21 May 2004 15:57:32 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 84B901FDCB; Fri, 21 May 2004 16:57:31 +0100 (BST) Date: Fri, 21 May 2004 16:57:26 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <274149345.1085158646@[192.168.100.5]> In-Reply-To: <20040521143353.28ECC13DE5@sa.vix.com> References: <20040521143353.28ECC13DE5@sa.vix.com> X-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, --On 21 May 2004 14:33 +0000 Paul Vixie wrote: >> Actually, I'll take that back, there may be a point in doing more, but >> there's certainly an argument that suggests that its reasonable to expect >> not to be in a worse position by virtue of switching from DNS to DNSSEC. > > So, "What Once Were Vices Are Now Habits" hits it fairly close, I guess. I think the issue is that RFC1034 did not mandate, but equally did not prohibit making zonefiles not enumerable (whether or not that prohibition is BCP), whereas current DNSSEC does (effectively) prohibit it as NSEC (which allows the behavior) is mandatory. >From RFC1034: The secondary server must request a zone transfer via an AXFR request for the zone. ** The AXFR may cause an error, such as refused **, but normally is answered by a sequence of response messages. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 14:44: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 OAA20992 for ; Fri, 21 May 2004 14:44:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BREv6-000CQ5-Np for namedroppers-data@psg.com; Fri, 21 May 2004 18:39:00 +0000 Received: from [193.176.144.164] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BREuw-000CNu-JC for namedroppers@ops.ietf.org; Fri, 21 May 2004 18:38:50 +0000 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.11/8.12.11) with ESMTP id i4LIcnNl020253 for ; Fri, 21 May 2004 20:38:49 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200405211838.i4LIcnNl020253@bartok.sidn.nl> To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 20:38:49 +0200 From: Jaap Akkerhuis 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 I see a some of arguments being made about EU concerns over privacy. The subject whether DNSSEC would be run into EU privacy concerns pops up on a regular base in various places. Therefore, SIDN, the Dutch registry, asked for an opinion of the faculty of law of the University of Brabant. These people, all lawyers, are specialized in privacy and the influence of crypto technology on the law (and vice versa). They don't have no specialist knowledge of the DNS, but know the role it has in the proper working of the Internet. I explained them the situation: Lots of ccTLDs are preventing zone transfers to be done by the public in general often using privacy concerns as the primary motif. I also explained that DNSSEC has this back door where you can get the names out of the zone by walking the NXT records. So the basic question was, is there really a concern that this backdoor might prevent the deployment of DNSSEC in Europe because of privacy regulation? Note, this was before NSEC records existed. I'm sticking here to the term NXT records to stay close to the original conversation. They were willing to do an small study, and, if they thought that there might be any problems, they would raise that and then we would decide whether a larger study was necessary. It resulted in: Tilburg University (B.J. Koops & E. Schreuders), Quickscan DNSsec/NXT and privacy, March 2003 (unpublished). It is not really big, I give here a translation from the Dutch, leaving out some of the details. We don't think that there is a special privacy problem with the deployment of DNSSEC caused by the NXT walking which would give you a list of names which might be used to query the whois service. The privacy rules are already in force by the Wbp (Dutch privacy law, fully implementing the EU directives --j) and the regulation of the registry. (I'm skipping the details they quote from court cases and articles in our regulations --j). DNSsec only offers something new by the capability to get a list of domain names. This list is irrelevant from a privacy point of view, only the combination with the whois database gives the list personal sensitive information (with the exception that of domain names such as michaeljfox.com, vix.com and jaap-akkerhuis.nl). Possible problems occur when the list is used for interrogating the whois database. But for that, there are already existing rules so DNSsec doesn't add any problems. In short, the back door can give personal data but only in combination with whois for which is existing regulation. Although they don't claim that they didn't do "fundamental research", We (SIDN) would have been happy to pay for such a study as well, but they refused, since they thought that such a study would have a very similar outcome. So, we concluded that the NXT walking (now NSEC) and (EU) privacy concerns would not be a show stopper for introducing DNSSEC in the NL zone. On this list in this context I noticed that also concernsabout the IP-rights (Intellectual Property rights) popped up, like one had on a telephone directory. (There the data is also meant to be public, but on how it is organized there are IP rights). You cannot just copy a directory because of that. For a zone file you can claim this probably as well. That gives you a handle to whack people making copies. We discussed this internally somewhat. We think that IP-rights on a zone file is an interesting idea, but doesn't prevent zone enumeration. It has more juridical aspects then technical. Back to (EU and other) pivacy concerns. Given the fact that there are multiple ways to do data mining for domain names in a zone as pointed out by Paul Vixie and Robert Elz, one really must take steps to limit access to "whois data". jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 15:38: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 PAA24404 for ; Fri, 21 May 2004 15:38:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRFnH-000LEw-IM for namedroppers-data@psg.com; Fri, 21 May 2004 19:34:59 +0000 Received: from [216.168.239.87] (helo=ns1.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRFnG-000LEi-BG for namedroppers@ops.ietf.org; Fri, 21 May 2004 19:34:58 +0000 Received: from localhost.localdomain (roadie [127.0.0.1]) by ns1.verisignlabs.com (8.12.8/8.12.8) with ESMTP id i4LJYfeD011250; Fri, 21 May 2004 15:34:41 -0400 Received: (from markk@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i4LJYfIY011248; Fri, 21 May 2004 15:34:41 -0400 Date: Fri, 21 May 2004 15:34:41 -0400 From: Mark Kosters To: Marcos Sanz/Denic Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-ID: <20040521193441.GK2071@verisignlabs.com> References: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i 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,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, May 21, 2004 at 10:45:47AM +0200, Marcos Sanz/Denic wrote: > Olaf, > > > If I do not see rough consensus on taking up NSEC2 as a work item by > > June 1 I'll reject this as a work item. > > Thanks to the chairs for hearing the voices of those stating they have a > deployment problem with the specification in its current form. > > While it is true that DNSSec has a long and painful story tracking back to > 10 years ago, that's plainly because the protocol itself isn't so easy as > thought in the beginning. I wouldn't like to see these kind of > retrospective arguments bound to the future of proposals to solve the NSEC > traversal. I have mixed feelings about this. Despite us having zones available to download (after signing an agreement not to use this data in a harmful way), NSEC walking is going happen. They will do this out of ignorance or malfeasance. Rate limiting will be of some limited benefit but will not solve the issue.* What it does for us is increase load on systems serving up responses that serve no purpose. Thus, I would like to see some sort of way of reducing this behavior from occuring. Also, registries have the convergence of protocol improvements, operational realities, and political pressures. To that end, I sympathize with other registries as they think about how to deploy this monster. I hope that some of you who stomped your feet at Roy, Dave, and I over opt-in would open your minds, listen and help solve this issue. On the flip side, I too like to see dnssec deployed in the near future. Unfortunately, it will not happen if the pain is worse than the gain. Thanks, Mark * I think that the rate-limiting sentence should be taken out of the intro draft - it will not work except in the most trivial cases. -- Mark Kosters markk@verisignlabs.com 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 Fri May 21 15:45: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 PAA24675 for ; Fri, 21 May 2004 15:45:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRFux-000Mq6-D6 for namedroppers-data@psg.com; Fri, 21 May 2004 19:42:55 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRFuu-000MpX-53 for namedroppers@ops.ietf.org; Fri, 21 May 2004 19:42:52 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 462431FE69; Fri, 21 May 2004 20:42:51 +0100 (BST) Date: Fri, 21 May 2004 20:42:46 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jaap Akkerhuis , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <287669136.1085172166@[192.168.100.5]> In-Reply-To: <200405211838.i4LIcnNl020253@bartok.sidn.nl> References: <200405211838.i4LIcnNl020253@bartok.sidn.nl> X-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 21 May 2004 20:38 +0200 Jaap Akkerhuis wrote: > For a zone file you can claim > this probably as well. That gives you a handle to whack people > making copies. The (expensive, uncertain) legal "handle to whack people" doing something unlawful is no substitute for stopping them doing it in the first place. That's the same reason you have a lock on your front door despite laws against theft, and (bring this back to a protocol level) the same reason we promote strong encryption in protocols such as DNSSEC despite computer crime and fraud laws. If we said in a more general case "we'll leave this out the protocol and let them sort out the consequences in court" we might as well not do DNSSEC, and just pay investigators and lawyers to go verify whether DNS records are accurate and sue if not. Whilst the legal point is interesting, my main argument is from a functionality point of view. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 19:15: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 TAA11939 for ; Fri, 21 May 2004 19:15:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRJBG-0004cY-Np for namedroppers-data@psg.com; Fri, 21 May 2004 23:11:58 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRJB3-0004ai-3p for namedroppers@ops.ietf.org; Fri, 21 May 2004 23:11:45 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id E8431A864 for ; Fri, 21 May 2004 23:11:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i4LNBVDh064459; Sat, 22 May 2004 09:11:35 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> To: Simon Josefsson Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: relevent? In-reply-to: Your message of "Fri, 21 May 2004 16:13:40 +0200." Date: Sat, 22 May 2004 09:11:31 +1000 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 > bmanning@vacation.karoshi.com writes: > > >> No, I believe sufficient information is present. To verify that any > >> wildcard RR doesn't cover the queried name, you compute a few SHA-1 > >> hashes on the only possible wildcard owner names that can be relevant, > > > > thats a bit presumptious, don't you think? how can you > > possibly determine relevant, possible owner names? > > I may have misunderstood something. Here is how I perceive things. > > Consider any query for a non-existing name a.b.c.d.e.f.com in the zone > f.com. To prove that a.b.c.d.e.f.com doesn't exist, the server has to > return records proving that the following names do not exist: > > a.b.c.d.e.f.com > *.b.c.d.e.f.com > *.c.d.e.f.com > *.d.e.f.com > *.e.f.com > *.f.com > > This is the same for NXT, NSEC and presumably all alternatives as > well. You obviously don't understand the "closest encloser" restrictions. ONLY ONE AND EXACTLY ONE of those wildcards is relevent. You need to know what names exist to determine which wildcard to use. NSEC provides this information in the owner and next names (yes both of these are required not just the next name). For NO/NSEC2 the information required to determine this has to be explicitly provided. The actual set of proofs reqired are !f.com + !*.com or !e.f.com + !*.f.com + %f.com or !d.e.f.com + !*.e.f.com + %e.f.com or !c.d.e.f.com + !*.d.e.f.com + %d.e.f.com or !b.c.d.e.f.com + !*.c.d.e.f.com + %c.d.e.f.com or !a.b.c.d.e.f.com + !*.b.c.d.e.f.com + %b.c.d.e.f.com ! == not exist % == exist I don't believe NO had this as general DNSSEC did not have this specified at the time. Mark > With NXT/NSEC, the verifier can read the "next owner name" field of > the RRs, and make sure all above names are included in the range of > some of the returned RRs. > > Since alternative solution doesn't have a "next owner name" field, > this technique doesn't work. But the above set of possibly relevant > owner names is always a small number, so the verifier can compute the > hash of each of the above strings and verify that all are included in > the range of all NO RRs returned. > > The only difference in processing is that during each wildcard > iteration, you compare the hash of the name instead of the name, with > what is stored in the returned RRs. > > The second complication due to wildcard names is that when the > response exists and is a wildcard name, you must also prove that no > more specific owner name exists. The logic is a bit different, but I > believe there is no problem implementing it with hashed names. > > Were you thinking of some other problem? Or is my reasoning flawed? > > Regards, > 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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 19:44: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 TAA13172 for ; Fri, 21 May 2004 19:44:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRJcr-000ApN-88 for namedroppers-data@psg.com; Fri, 21 May 2004 23:40:29 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRJcq-000Ap6-BW for namedroppers@ops.ietf.org; Fri, 21 May 2004 23:40:28 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 20B50A862 for ; Fri, 21 May 2004 23:40:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i4LNeNc9078248; Sat, 22 May 2004 09:40:25 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200405212340.i4LNeNc9078248@drugs.dv.isc.org> To: Jaap Akkerhuis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Proposal to fix NSEC In-reply-to: Your message of "Fri, 21 May 2004 20:38:49 +0200." <200405211838.i4LIcnNl020253@bartok.sidn.nl> Date: Sat, 22 May 2004 09:40:23 +1000 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 see a some of arguments being made about EU concerns over privacy. > The subject whether DNSSEC would be run into EU privacy concerns > pops up on a regular base in various places. > > Therefore, SIDN, the Dutch registry, asked for an opinion of the > faculty of law of the University of Brabant. These people, all > lawyers, are specialized in privacy and the influence of crypto > technology on the law (and vice versa). They don't have no specialist > knowledge of the DNS, but know the role it has in the proper working > of the Internet. > > I explained them the situation: > > Lots of ccTLDs are preventing zone transfers to be done by > the public in general often using privacy concerns as the > primary motif. I also explained that DNSSEC has this back > door where you can get the names out of the zone by walking > the NXT records. So the basic question was, is there really > a concern that this backdoor might prevent the deployment > of DNSSEC in Europe because of privacy regulation? > > Note, this was before NSEC records existed. I'm sticking here to > the term NXT records to stay close to the original conversation. > > They were willing to do an small study, and, if they thought that > there might be any problems, they would raise that and then we would > decide whether a larger study was necessary. > > It resulted in: > Tilburg University (B.J. Koops & E. Schreuders), Quickscan > DNSsec/NXT and privacy, March 2003 (unpublished). > > It is not really big, I give here a translation from the Dutch, > leaving out some of the details. > > We don't think that there is a special privacy problem with > the deployment of DNSSEC caused by the NXT walking which > would give you a list of names which might be used to query > the whois service. The privacy rules are already in force > by the Wbp (Dutch privacy law, fully implementing the EU > directives --j) and the regulation of the registry. (I'm > skipping the details they quote from court cases and articles > in our regulations --j). > > DNSsec only offers something new by the capability to get > a list of domain names. This list is irrelevant from a > privacy point of view, only the combination with the whois > database gives the list personal sensitive information (with > the exception that of domain names such as michaeljfox.com, > vix.com and jaap-akkerhuis.nl). Possible problems occur > when the list is used for interrogating the whois database. > But for that, there are already existing rules so DNSsec > doesn't add any problems. > > In short, the back door can give personal data but only > in combination with whois for which is existing regulation. > > Although they don't claim that they didn't do "fundamental research", > We (SIDN) would have been happy to pay for such a study as well, > but they refused, since they thought that such a study would have > a very similar outcome. > > So, we concluded that the NXT walking (now NSEC) and (EU) privacy > concerns would not be a show stopper for introducing DNSSEC in the > NL zone. > > On this list in this context I noticed that also concernsabout the > IP-rights (Intellectual Property rights) popped up, like one had > on a telephone directory. (There the data is also meant to be public, > but on how it is organized there are IP rights). You cannot just > copy a directory because of that. But you can compile your own. I seem to remember a court case here where OCR scanning of a existing directory was illegal but getting a team of typists to re-enter all the data in a existing directory was legal. > For a zone file you can claim > this probably as well. That gives you a handle to whack people > making copies. We discussed this internally somewhat. We think > that IP-rights on a zone file is an interesting idea, but doesn't > prevent zone enumeration. It has more juridical aspects then > technical. > > Back to (EU and other) pivacy concerns. Given the fact that there > are multiple ways to do data mining for domain names in a zone as > pointed out by Paul Vixie and Robert Elz, one really must take steps > to limit access to "whois data". > > jaap > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 19:57: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 TAA14008 for ; Fri, 21 May 2004 19:57:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRJrD-000EPN-4F for namedroppers-data@psg.com; Fri, 21 May 2004 23:55:19 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRJr9-000EKs-Uj for namedroppers@ops.ietf.org; Fri, 21 May 2004 23:55:16 +0000 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.11/8.12.11) with ESMTP id i4LNt7QQ007144 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 22 May 2004 01:55:08 +0200 To: Mark Andrews Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: relevent? References: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> From: Simon Josefsson X-Hashcash: 0:040521:Mark_Andrews@isc.org:29c58d649ee2f18b X-Hashcash: 0:040521:bmanning@vacation.karoshi.com:1d16456a2ebdb1b1 X-Hashcash: 0:040521:namedroppers@ops.ietf.org:e88c5e7b5f61e912 Date: Sat, 22 May 2004 01:55:06 +0200 In-Reply-To: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> (Mark Andrews's message of "Sat, 22 May 2004 09:11:31 +1000") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) 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 Mark Andrews writes: > You need to know what names exist to determine which wildcard > to use. NSEC provides this information in the owner and next > names (yes both of these are required not just the next name). > > For NO/NSEC2 the information required to determine this has > to be explicitly provided. > > The actual set of proofs reqired are > > !f.com + !*.com > or > !e.f.com + !*.f.com + %f.com > or > !d.e.f.com + !*.e.f.com + %e.f.com > or > !c.d.e.f.com + !*.d.e.f.com + %d.e.f.com > or > !b.c.d.e.f.com + !*.c.d.e.f.com + %c.d.e.f.com > or > !a.b.c.d.e.f.com + !*.b.c.d.e.f.com + %b.c.d.e.f.com > > ! == not exist > % == exist And how is it impossible for NO/NSEC2 to support this? How I see it is that the verifier would compute a hash of all the following strings: a.b.c.d.e.f.com *.b.c.d.e.f.com *.c.d.e.f.com *.d.e.f.com *.e.f.com *.f.com The hashes for the positive proofs are also needed, i.e.: f.com e.f.com d.e.f.com c.d.e.f.com b.c.d.e.f.com Using those hash values, together with the returned records, the client can discover which of your clauses hold (if any). For example, let's say we have the following (abbreviated hash values to simplify reading, imagine they are full length SHA-1 hashes): H(a.b.c.d.e.f.com) = 181 H(*.b.c.d.e.f.com) = 38383 H(*.c.d.e.f.com) = 3292 H(*.d.e.f.com) = 4959 H(*.e.f.com) = 606 H(*.f.com) = 1194 H(f.com) = 5271 H(e.f.com) = 14 H(d.e.f.com) = 596 H(c.d.e.f.com) = 94984 H(b.c.d.e.f.com) = 903 Now let's assume the query is a.b.c.d.e.f.com and the returned NO records are: $ORIGIN _no.f.com 150 IN NO A 200 ;; the main proof that a.b.c.d.e.f.com (181) does not exist ;; Additional proofs: 550 IN NO A 650 ;; proves d.e.f.com (596) does not exist 550 IN NO A 650 ;; proves *.e.f.com (606) does not exist (by chance, same record) 14 IN NO A 50 ;; proves e.f.com (14) exists The verifier is able to discover that one out of all relevant wildcard situations apply, in this case the third of your clause. To do this it simply iterates over all possible candidates (a small number). The client can now trust that a specific a.b.c.d.e.f.com do not exist, and that e.f.com do exists but there is no d.e.f.com nor *.e.f.com. So it is able to authenticate denial of existence for ab.c.d.e.f.com. If I'm going to understand why NO/NSEC2 doesn't work, please give more details. 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 Fri May 21 20: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 UAA14181 for ; Fri, 21 May 2004 20:01:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRJuw-000FGq-2b for namedroppers-data@psg.com; Fri, 21 May 2004 23:59:10 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRJuv-000FGY-6C for namedroppers@ops.ietf.org; Fri, 21 May 2004 23:59:09 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4LNx5lZ043359 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 21 May 2004 23:59:07 GMT (envelope-from roy+dated+1087776017.8397e5@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4LNx4so026645 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 22 May 2004 00:59:05 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4M00Huq075316 for ; Sat, 22 May 2004 01:00:17 +0100 (BST) (envelope-from roy+dated+1087776017.8397e5@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4M00HDN075315 for namedroppers@ops.ietf.org; Sat, 22 May 2004 01:00:17 +0100 (BST) (envelope-from roy+dated+1087776017.8397e5@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 22 May 2004 01:00:16 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16558.38928.396306.626075@giles.gnomon.org.uk> Date: Sat, 22 May 2004 01:00:16 +0100 To: Mark Andrews Cc: Jaap Akkerhuis , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <200405212340.i4LNeNc9078248@drugs.dv.isc.org> References: <200405211838.i4LIcnNl020253@bartok.sidn.nl> <200405212340.i4LNeNc9078248@drugs.dv.isc.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-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 >>>>> "Mark" == Mark Andrews writes: Mark> But you can compile your own. I seem to remember a Mark> court case here where OCR scanning of a existing directory Mark> was illegal but getting a team of typists to re-enter all Mark> the data in a existing directory was legal. Hmm, I'm kind of surprised that even OCR was illegal in the US. But there is a significant difference between UK and US copyright law in this area. AIUI in US copyright law there is an exclusion from copyright for a unique, canonical representation of a set of data. A consistently formatted alphabeticised list of names and phone numbers of all telephone users would hence fall into this category, since it is not regarded as a creative work. Many other jurisditions (certainly the UK) do not draw this distinction. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 21 23:35: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 XAA23028 for ; Fri, 21 May 2004 23:35:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRNEZ-0003wX-IE for namedroppers-data@psg.com; Sat, 22 May 2004 03:31:39 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRNEY-0003wB-Ni for namedroppers@ops.ietf.org; Sat, 22 May 2004 03:31:38 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4M3VQQB018790; Fri, 21 May 2004 20:31:26 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 May 2004 20:31:25 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: Jim Reid , Roy Badami Cc: namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Fri, 21 May 2004 20:31: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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >>>>> "Roy" == Roy Badami writes: > > Roy> If ccTLD operators suggest that this might be an issue for > Roy> them, then it is IMHO unreasonable for anyone (other than a > Roy> lawyer versed in this area) to tell them they are wrong. > > I don't believe anyone here is claiming they are wrong or that their > concerns about EU directives are invalid. As you say only a clueful > lawyer can make that determination. I do think it's wrong however to > attempt to solve layer 9 problems by redesigning a protocol. I disagree. The ONLY purpose of the protocols is to solve layer 9 problems. Layer 9 is PEOPLE. Roy is stating that this issue is a showstopper for him. Your proposal is in effect saying that the IETF, an organization with zero internal democracy and zero accountability should override European Union law decided by the democratically appointed European parliament and the council of ministers appointed by the democratically elected European governments. Please consider the fact that the IETF claim to be above international law might just possibly be the result of a ridiculous degree of arrogance. It is a valid point to say that the IETF may not have competence in this area, but that may well mean that the IETF does not have competence to write any specs whatsoever. if the legal interpretation is an issue I suggest that we ask Michael Froomkin or some other DNS savy lawyer their opinion rather than saying, "I do not understand this issue, therefore I will not allow it to be raised." It seems somewhat strange that people are arguing that the effects of DNS zone walking are so well understood that no change could possibly be required. The same people were arguing a little while ago that a minor change that would introduce the risk of severe DNS operational instability should be rejected for the sole reason that the implication of the change could not possibly be understood. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat May 22 00:28: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 XAA23029 for ; Fri, 21 May 2004 23:35:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRNEP-0003vG-3B for namedroppers-data@psg.com; Sat, 22 May 2004 03:31:29 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRNEN-0003v1-On for namedroppers@ops.ietf.org; Sat, 22 May 2004 03:31:27 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4M3VNgt018769; Fri, 21 May 2004 20:31:23 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 May 2004 20:31:22 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: Ben Laurie , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Fri, 21 May 2004 20:31:22 -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.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > So why do we need to specify more than H(dx), (H(dx+1)) ??? > > To increase the cost of dictionary attacks. Ben, I think that this risks turning a good proposal into one with a questionable feature that will distract from the main value. Essentially all you are arguing for here is an expensive hash function. The valud of crypto is that you can introduce asymmetric attack costs. It is much harder for an attacker to break DES than it is for the defender to encrypt their message - 2^55.5 times as hard in fact. That is a real benefit. Here you just make the problem harder by an equal factor for attacker and defender. That is not a core value here. Leaving aside that nit, the proposal has real value and adds real security. The comparative attack analysis that has been offered is totally bogus: The DNS system without DNSSEC provides a lookup function that returns an answer to the question "is x a member of S" and returns a binary response. With DNSSEC and NSEC you get a response "there are NO members of x in the range a,b AND a,b are both members of S" Sorry, but anyone who claims that there is no security issue raised here is speaking through their hat. The fact that I publish a binary response function returning set membership does not mean that I am willing to reveal the set. That is simply untrue. The number of real world attacks that are made possible by revealing S is very, very large and very, very significant. I know that there are folk who dispute this in the IETF, remember however that there are people in the IETF who have actively discouraged the deployment of firewalls in the past, and some still do. Regardless of where you stand on that debate please understand that the fact that if you want to deploy a security protocol it had better meet the security requirements set by the security establishment. In the real world the fact that there is an easy way for an attacker to discover the names of all my public facing machines is a really really significant issue. In the real world 95% of attacks are made by people who are clueless. In the real world security is risk management, not risk elimination. If you do not believe me on this go talk to Bruce S. or read Secrets and Lies. In the real world every security incident costs real money. Filters that catch 95% of the bozos save real money. The current NSEC record is bogus. It insists on addressing a security issue that simply does not exist (securing insecure zones) while refusing to address a real security issue which is rightly considered by many to be a showstopper for adoption. If there was a logic to the IETF process we would ask people two questions, first what are the showstoppers that would cause you not to deploy? second why should we care? I know the IETF lives in a crypto-communist la-la land where it is impolite to ask such questions but the failure to do so is the reason that DNSSEC is still a failed spec ten years on. The canonical texts for my company are Jim Collins, built to last where facing the brutal facts is considered one key to success. My showstoppers are 1) the spec must be incrementally deployable in large zones and 2) it must address the zone walking issue. The reason you should care is that I am one of the very few members of the security field who has an interest in this group. I am Principal Scientist of the security division of company that has major influence in the Security field. I also have personal influence, as the author of XKMS, and co-editor of SAML and WS-Security I can help convince key constituencies that they should buy in to DNSSEC. The security community is not going to support a spec that introduces a new security vulnerability that was not previously present and introduces operational demands that threaten the stability of core DNS. As the spec stands I cannot recommend it to my colleagues and in fact would have to recommend that they do NOT deploy. With an updated NSEC record that meets the showstopper objections I describe I will be in a position to recommend DNSSEC. I believe that it is even possible that with a small amount of appropriate preparation work it might be possible that MARID and MARID accreditations could serve as a 'killer-app' for DNSSEC. One important political point here is that a MARID accreditation service would be outside the control of ICANN. Remember that killer-app means, the app which motivates building the infrastructure, not necessarily the most important app the infrastructure will serve. Email was not the Internet killer app, everyone had to be online before it had value, but now everyone is online email is more important than the web. 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 Sat May 22 02:41: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 CAA15642 for ; Sat, 22 May 2004 02:41:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRQ9a-000AhY-6a for namedroppers-data@psg.com; Sat, 22 May 2004 06:38:42 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRQ9X-000Ah6-Db for namedroppers@ops.ietf.org; Sat, 22 May 2004 06:38:39 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1D27E13E3C for ; Sat, 22 May 2004 06:38:39 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: relevent? In-Reply-To: Message from Simon Josefsson of "Sat, 22 May 2004 01:55:06 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 22 May 2004 06:38:39 +0000 Message-Id: <20040522063839.1D27E13E3C@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 > ... > The verifier is able to discover that one out of all relevant wildcard > situations apply, in this case the third of your clause. To do this > it simply iterates over all possible candidates (a small number). ... it is not reasonable to ask a verifier to iterate in this additional way. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat May 22 03: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 DAA17648 for ; Sat, 22 May 2004 03:19:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRQjf-000H6M-8Y for namedroppers-data@psg.com; Sat, 22 May 2004 07:15:59 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRQjY-000H5C-75 for namedroppers@ops.ietf.org; Sat, 22 May 2004 07:15:52 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i4M6sg015650; Sat, 22 May 2004 13:54:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i4M6r5Zg011319; Sat, 22 May 2004 13:53:08 +0700 (ICT) From: Robert Elz To: "Hallam-Baker, Phillip" cc: Jim Reid , Roy Badami , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 May 2004 13:53:05 +0700 Message-ID: <22859.1085208785@munnari.OZ.AU> 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 Date: Fri, 21 May 2004 20:31:23 -0700 From: "Hallam-Baker, Phillip" Message-ID: | Roy is stating that this issue is a showstopper for him. Your proposal | is in effect saying that the IETF, an organization with zero internal | democracy and zero accountability should override European Union law Don't be totally absurd. As Jaap already showed (after more research than the topic deserved), the European laws have nothing whatever to do with this. They're designed to protect the privacy of the individual, who in this case, has given their domain name to the DNS operator to publish - by request (or more likely, by contract, if the data weren't published, there might be legal action involved). Incidentally, nor does copyright, which has also been mentioned - in order to get copyright protection, the item to be protected has to have been published, which is exactly what the organisations that are objecting don't want to do, they're trying to keep their list of names secret, which is really the anthises of the whole purpose of the DNS. If they were to publish it, they could get copyright protection, but as they don't want that, they're resorting to all kinds of avenues to try to keep the secret - which is, without doubt, difficult, or impossible. 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 Sat May 22 03: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 DAA18348 for ; Sat, 22 May 2004 03:34:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRQyB-000JAr-VF for namedroppers-data@psg.com; Sat, 22 May 2004 07:30:59 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRQy8-000JAM-5u for namedroppers@ops.ietf.org; Sat, 22 May 2004 07:30:56 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BRQy5-0003fg-00 for ; Sat, 22 May 2004 09:30:55 +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 ; Sat, 22 May 2004 09:30:53 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 May 2004 09:30:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: relevent? Date: Sat, 22 May 2004 09:30:46 +0200 Lines: 37 Message-ID: References: <20040522063839.1D27E13E3C@sa.vix.com> 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:SFc0eJsj1jgH03VefY6ivB9yxEA= 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 Paul Vixie writes: >> ... >> The verifier is able to discover that one out of all relevant wildcard >> situations apply, in this case the third of your clause. To do this >> it simply iterates over all possible candidates (a small number). ... > > it is not reasonable to ask a verifier to iterate in this additional way. Why not? Are you worried about CPU efficiency? The most computationally expensive operation of the iteration is likely the hashing. I don't see anything else in the verification process that would take time; the iteration over possible relevant names is over a small number, typically <<100, and each loop compute a hash and can directly compare the hash against the received NO/NSEC2 records. You could cache some of the hash computations to improve performance, but given the below I doubt you would need that for performance reasons alone. My box does ~1.000.000 SHA1 ops/second, compared to ~1.000 RSA 512 bit verify ops/second, and ~200 RSA 1024 bit verify ops/second. So it doesn't appear as CPU efficiency would be a valid concern. Code complexity? The logic is straight forward. You can modularize the NO/NSEC2 wildcard verify logic into a separate module. It is just a Small Matter Of Programming. Compared to other warts in NXT/NSEC, it doesn't have any consequences on the basic DNS model. Take the zone cut issue with NXT/NSEC, where you have two records with the same name/type/class, but must not confuse the two as one comes from the parent zone and one from the child zone. Catering for this wart may require changes to the backend of a DNS cache. Recall that NO (and likely also NSEC2, but I haven't read it) fixes the zone cut issue. Regards, 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 Sat May 22 04:59: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 EAA21435 for ; Sat, 22 May 2004 04:59:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRSIX-0006Jo-6c for namedroppers-data@psg.com; Sat, 22 May 2004 08:56:05 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRSIW-0006JX-9L for namedroppers@ops.ietf.org; Sat, 22 May 2004 08:56:04 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 6580D1FDCB; Sat, 22 May 2004 09:56:03 +0100 (BST) Date: Sat, 22 May 2004 09:55:58 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Robert Elz , "Hallam-Baker, Phillip" Cc: Jim Reid , Roy Badami , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <335260799.1085219758@[192.168.100.5]> In-Reply-To: <22859.1085208785@munnari.OZ.AU> References: <22859.1085208785@munnari.OZ.AU> X-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, --On 22 May 2004 13:53 +0700 Robert Elz wrote: > | Roy is stating that this issue is a showstopper for him. Your proposal > | is in effect saying that the IETF, an organization with zero internal > | democracy and zero accountability should override European Union law > > Don't be totally absurd. As Jaap already showed (after more research > than the topic deserved), the European laws have nothing whatever to do > with this ... Incidentally, nor does copyright, which has also > been mentioned - in order I'm not going to put privileged legal advice on list (drop me a note off-list if you like) but suffice to say the old saw about ask two different lawyers, get two different answers is all the more true in two different jurisdictions. For me the point, however, isn't wholly about the law. It's about what stakeholders want. They do not want ccTLD operators publishing zonefiles. And ccTLD operators do not want to publish zonefiles. It appears the same might be true of VRSN. Current RFCs permit non-publication. The current DNSsec proposal prohibits this. Whether or not all these people are unduly worried is to an extent a moot question, though personally I agree with Phillip Hallam-Baker's analysis that more information is revealed. 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 Sat May 22 05:04: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 FAA21724 for ; Sat, 22 May 2004 05:04:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRSP4-0007Zt-EM for namedroppers-data@psg.com; Sat, 22 May 2004 09:02:50 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRSP3-0007ZV-FI for namedroppers@ops.ietf.org; Sat, 22 May 2004 09:02:49 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4M92klZ069927 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sat, 22 May 2004 09:02:48 GMT (envelope-from roy+dated+1087808638.25755b@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4M92hso028904 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 22 May 2004 10:02:45 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4M93wuq080518 for ; Sat, 22 May 2004 10:03:58 +0100 (BST) (envelope-from roy+dated+1087808638.25755b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4M93w0e080512 for namedroppers@ops.ietf.org; Sat, 22 May 2004 10:03:58 +0100 (BST) (envelope-from roy+dated+1087808638.25755b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 22 May 2004 10:03:57 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16559.6012.737739.292859@giles.gnomon.org.uk> Date: Sat, 22 May 2004 10:03:56 +0100 To: "Hallam-Baker, Phillip" Cc: Jim Reid , Roy Badami , namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC In-Reply-To: References: 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-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 >>>>> "Hallam-Baker," == Hallam-Baker, Phillip writes: Hallam-Baker,> Roy is stating that this issue is a showstopper for Hallam-Baker,> him. For the record, all I actually said that was that ccTLDs have raised some concerns, and I disgreed with some of the sweeping arguments that were being used against such possible concerns... Though it appears now that Nominet have pretty much stated that this is a showstopper for 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 Sat May 22 10:00: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 JAA07207 for ; Sat, 22 May 2004 09:59:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRWy4-0006oW-Qy for namedroppers-data@psg.com; Sat, 22 May 2004 13:55:16 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRWy3-0006oG-IO for namedroppers@ops.ietf.org; Sat, 22 May 2004 13:55:15 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4MDtAfB003896; Sat, 22 May 2004 06:55:11 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 22 May 2004 06:55:10 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Robert Elz'" , "Hallam-Baker, Phillip" Cc: Jim Reid , Roy Badami , namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Sat, 22 May 2004 06:55:05 -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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Don't be totally absurd. As Jaap already showed (after > more research > than the topic deserved), What I was objecting to was the assertion that regardless of whether the law was applicable or not that 'layer 9' is out of scope. > the European laws have nothing > whatever to do > with this. They're designed to protect the privacy of the > individual, > who in this case, has given their domain name to the DNS operator to > publish - by request (or more likely, by contract, if the data weren't > published, there might be legal action involved). The domain name is in many cases a personal identifier. The use that the owner has authorized is publication of that data in isolation. Privacy law has volumes of case law where a distinction is made between isolated publication and publication of compilations. > Incidentally, nor does copyright, which has also been > mentioned - in order > to get copyright protection, the item to be protected has to have been > published, which is exactly what the organisations that are > objecting don't > want to do, they're trying to keep their list of names > secret, which is > really the anthises of the whole purpose of the DNS. You are clearly not a lawyer, copyright has not required publication since the ratification of the Berne convention several decades ago. -- to unsubscribe send a message to namedroppers-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 May 22 10:23: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 KAA09379 for ; Sat, 22 May 2004 10:23:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRXMc-000CU5-KN for namedroppers-data@psg.com; Sat, 22 May 2004 14:20:38 +0000 Received: from [192.215.81.75] (helo=relay2.san1.attens.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRXMb-000CT7-If for namedroppers@ops.ietf.org; Sat, 22 May 2004 14:20:37 +0000 Received: from tiger.ben.algroup.co.uk (1010ahost163.starwoodbroadband.com [12.149.158.163]) by relay2.san1.attens.com (8.11.6/8.9.3) with ESMTP id i4MEKaT22271 for ; Sat, 22 May 2004 14:20:37 GMT Received: from algroup.co.uk (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i4MFFlRP032882; Sat, 22 May 2004 16:15:48 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <40AF6EA3.9040700@algroup.co.uk> Date: Sat, 22 May 2004 16:15:47 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: In-Reply-To: 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 Hallam-Baker, Phillip wrote: >>>So why do we need to specify more than H(dx), (H(dx+1)) ??? >> >>To increase the cost of dictionary attacks. > > I think that this risks turning a good proposal into one with a > questionable feature that will distract from the main value. Essentially all > you are arguing for here is an expensive hash function. > > The valud of crypto is that you can introduce asymmetric attack > costs. It is much harder for an attacker to break DES than it is for the > defender to encrypt their message - 2^55.5 times as hard in fact. That is a > real benefit. > > Here you just make the problem harder by an equal factor for > attacker and defender. That is not a core value here. This is true, but neglects the fact that the attacker has to hash far more things than the defender. However, an asymmetric solution would be even nicer, I'll agree. 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: From owner-namedroppers@ops.ietf.org Sat May 22 10:49: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 KAA10717 for ; Sat, 22 May 2004 10:49:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRXhj-000GVg-PZ for namedroppers-data@psg.com; Sat, 22 May 2004 14:42:27 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRXhi-000GVH-Gu for namedroppers@ops.ietf.org; Sat, 22 May 2004 14:42:26 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4MEfkIR024026; Sat, 22 May 2004 07:41:50 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 22 May 2004 07:41:46 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Simon Josefsson'" , bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org Subject: RE: relevent? Date: Sat, 22 May 2004 07:41:36 -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.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Consider any query for a non-existing name a.b.c.d.e.f.com in the zone > f.com. To prove that a.b.c.d.e.f.com doesn't exist, the server has to > return records proving that the following names do not exist: > > a.b.c.d.e.f.com > *.b.c.d.e.f.com > *.c.d.e.f.com > *.d.e.f.com > *.e.f.com > *.f.com > > This is the same for NXT, NSEC and presumably all alternatives as > well. Meng did some analysis in MARID on this. I think he might have the answer. The first point that has to be understood is that wildcards are not really a DNS protocol feature, they are exclusively the result of server action. The only reason that wildcards exist in the original DNS spec at all is that it is desirable to communicate wildcards in zone transfers and the like. Since wildcards are the result of server synthesis there is in fact only one server whose wildcard synthesis is relevant, that is the server holding the enclosing SOA record, what Meng refers to as the zone cut. In other words it is critical to observe the fact that there are delegations: In other words structure matters, a better example would be: a.b.][c.d.][e.f.][com][.] We do not, repeat DO NOT need to consider the existence of c.d.e.f.com in the context of wildcarding since WE WOULD NOT HAVE GOT THERE WITHOUT PROOF THEY EXISTED. In fact all we need to know is that: The zone c.d.e.f.com does not contain a wildcard b.c.d.e.f.com does not exist. This statement can be proven in a single statement that is attached to the zone node c.d.e.f.com: This zone does not contain a wildcard This zone does not contain any nodes x such that s < H(x) < e where s < SHA1(b), e > SHA1 (b) Since we are at it we might as well fix wildcarding for SRV and like records at the same time. There is no logical reason why it should be imposible to deal with wildcards in the middle of a name, so called 'synthetic' but a more accurate description would be 'non-transferable' and that only because the protocol neglects to realize the need for them. All that is necessary here is to add a wildcard NODE which can have descendents. Let us use _* as the wildcard node. The same principle and proof can be applied to the wildcard node descendents. i.e. to prove that a.b.c.d.e.f.com does not exist when the zone contains wildcard records such as x.*.c.d.e.f.com, y.*, z.* etc it is merely necessary to list the intervals x-y, y-z, z-x. By fixing this deficiency in DNS we also eliminate all engineering (i.e. not layer 9) objections to use of SRV style name differentiation in the DNS as a substitute for defining new resource records, a strategy that has as Dave Crocker rightly points out a track record of over a decade of failure. 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 Sat May 22 11:11: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 LAA12706 for ; Sat, 22 May 2004 11:11:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRY5o-000Lib-CY for namedroppers-data@psg.com; Sat, 22 May 2004 15:07:20 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRY5l-000Lhz-Fq for namedroppers@ops.ietf.org; Sat, 22 May 2004 15:07:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E2DB613E08 for ; Sat, 22 May 2004 15:07:16 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Alex Bligh of "Sat, 22 May 2004 09:55:58 +0100." <335260799.1085219758@[192.168.100.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 22 May 2004 15:07:16 +0000 Message-Id: <20040522150716.E2DB613E08@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 > Paul, I'm Paul. He's Robert. > --On 22 May 2004 13:53 +0700 Robert Elz wrote: > > ... > > Don't be totally absurd. As Jaap already showed (after more research > > than the topic deserved), the European laws have nothing whatever to do > > with this ... Incidentally, nor does copyright, which has also > > been mentioned - in order > > ... > For me the point, however, isn't wholly about the law. It's about what > stakeholders want. They do not want ccTLD operators publishing zonefiles. > And ccTLD operators do not want to publish zonefiles. It appears the same > might be true of VRSN. Current RFCs permit non-publication. ... Have any of you here looked at , perchance? The thing that's boggling my mind at the moment is that the stakeholders, or ccTLD operators, or VRSN, believes that by prohibiting zone transfers they are preventing enumeration. It just ain't so, and while I'm still Paul and he's still Robert and I can't authoritatively speak for him, I suspect that Robert's use of the word "absurd" has to do with the general misconception that preventing direct enumeration at the DNS protocol level is actually buying anything for anybody. > ... Whether or not all these people are unduly worried is to an extent > a moot question, ... No, it's not moot, not yet anyway. DNSSECbis as documented in the current set of drafts and as implemented in BIND 9.3.0-beta4 has undergone significant review and lab testing and appears ready for deployment. If the DNS protocol development community is going to back away and redesign it again, then two questions have to be answered first: 1. what exactly is it that you think you're going to get by making the enumeration of your zones an indirect activity rather than a direct one, noting that anyone who wants the enumeration can get it by indirect data mining techniques...? 2. why are we doing this in May, when every other time that we've pulled DNSSEC back for yet another redesign that's added one or two years to the schedule, we've done it in December...? > ... though personally I agree with Phillip Hallam-Baker's analysis > that more information is revealed. If he said that, he was wrong. More likely you misunderstood him. The same information is revealed, it just happens slightly later and is an indirect activity. Take a look at before you try to decide what's "finally and actually" revealed, no matter what. (Noting that the ISC Domain Survey does not use or depend upon AXFR.) -- to unsubscribe send a message to namedroppers-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 May 22 11:11: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 LAA12710 for ; Sat, 22 May 2004 11:11:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRY7p-000M9H-W3 for namedroppers-data@psg.com; Sat, 22 May 2004 15:09:25 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRY7p-000M90-8A for namedroppers@ops.ietf.org; Sat, 22 May 2004 15:09:25 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4MF9L5o005084; Sat, 22 May 2004 08:09:21 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sat, 22 May 2004 08:09:21 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ben Laurie'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Sat, 22 May 2004 08:09:15 -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.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > > Here you just make the problem harder by an equal factor for > > attacker and defender. That is not a core value here. > > This is true, but neglects the fact that the attacker has to hash far > more things than the defender. However, an asymmetric > solution would be even nicer, I'll agree. We have a dictionary corpus of n values and perform r iterations. You are saing that the attacker has to perform n*r work units rather than only n units and that this is sufficient value to justify increasing the per lookup work function of client and server from 1 unit to r units. I still don't see the value. We usually assume that an attacker is likely to use hardware. A dictionary attack is going to work in any situation where you can perform individual lookups without restriction. That is not the attack that causes real concern here. What I am concerned with is dictionary discovery. -- to unsubscribe send a message to namedroppers-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 May 22 11:15: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 LAA12793 for ; Sat, 22 May 2004 11:15:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRYBi-000MxC-Pr for namedroppers-data@psg.com; Sat, 22 May 2004 15:13:26 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRYBi-000Mwj-2G for namedroppers@ops.ietf.org; Sat, 22 May 2004 15:13:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id ABB1313E3C for ; Sat, 22 May 2004 15:13:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: relevent? In-Reply-To: Message from Simon Josefsson of "Sat, 22 May 2004 09:30:46 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 22 May 2004 15:13:25 +0000 Message-Id: <20040522151325.ABB1313E3C@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 > >> ... > >> The verifier is able to discover that one out of all relevant wildcard > >> situations apply, in this case the third of your clause. To do this > >> it simply iterates over all possible candidates (a small number). ... > > > > it is not reasonable to ask a verifier to iterate in this additional way. > > Why not? because it's already iterating in several other ways, and this is basically a new innermost-loop, and the span of the iteration can be controlled by an attacker. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat May 22 11:29: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 LAA13522 for ; Sat, 22 May 2004 11:29:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRYOm-000PaQ-Gw for namedroppers-data@psg.com; Sat, 22 May 2004 15:26:56 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRYOk-000PZF-PV for namedroppers@ops.ietf.org; Sat, 22 May 2004 15:26:55 +0000 Received: (qmail 18173 invoked by uid 1001); 22 May 2004 15:26:53 -0000 To: paul@vix.com Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 22 May 2004 15:07:16 +0000" References: <20040522150716.E2DB613E08@sa.vix.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 22 May 2004 17:26:53 +0200 Message-ID: <18171.1085239613@bizet.nethelp.no> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_00,DOMAIN_BODY, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > For me the point, however, isn't wholly about the law. It's about what > > stakeholders want. They do not want ccTLD operators publishing zonefiles. > > And ccTLD operators do not want to publish zonefiles. It appears the same > > might be true of VRSN. Current RFCs permit non-publication. ... > > Have any of you here looked at , perchance? > > The thing that's boggling my mind at the moment is that the stakeholders, > or ccTLD operators, or VRSN, believes that by prohibiting zone transfers > they are preventing enumeration. It just ain't so, and while I'm still > Paul and he's still Robert and I can't authoritatively speak for him, I > suspect that Robert's use of the word "absurd" has to do with the general > misconception that preventing direct enumeration at the DNS protocol level > is actually buying anything for anybody. With some knowledge of how the .no domain operates, I think it is fair to say: At least some stakeholders are fully aware of the fact that prohibiting zone transfers does not prevent enumeration. However, they still find it valuable to prevent zone transfers - the important point here being the amount of work (and time) it takes to perform the enumeration: If a domain can be enumerated in a month today, and could be enumerated in a minute with NSEC (just to take an example), this is a dramatic reduction in the amount of work needed - and a correspondingly lower barrier to at least some undesirable uses of the domain data. Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat May 22 11:41: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 LAA13974 for ; Sat, 22 May 2004 11:41:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRYaI-00028X-TG for namedroppers-data@psg.com; Sat, 22 May 2004 15:38:50 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRYaG-00027g-Ql for namedroppers@ops.ietf.org; Sat, 22 May 2004 15:38:49 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C0CFC1FDCB; Sat, 22 May 2004 16:38:43 +0100 (BST) Date: Sat, 22 May 2004 16:38:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <359418887.1085243916@[192.168.100.5]> In-Reply-To: <20040522150716.E2DB613E08@sa.vix.com> References: <20040522150716.E2DB613E08@sa.vix.com> X-Mailer: Mulberry/3.1.1 (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 Paul, > I'm Paul. He's Robert. Apologies > Have any of you here looked at , perchance? Yes - it works by PTR query. That does not give a complete and accurate enumeration, nor does it give a single snapshot in time. Nor does is it published BY the ccTLD operator. That is like saying there is no point in protecting my streetmap of SF because you and everyone else have a streetmap of SF that's "quite like it". For the sake of completeness awk ... | fgrep co.uk | uniq on AOL's mailserver logs is also going to produce another similar but inaccurate database. Just to illustrate the point, can you tell me what the domain is in Nominet's zonefile right now, alphabetically immediately following alex.org.uk. The 10 next ones? No, you can't, without access to a secondary. > The thing that's boggling my mind at the moment is that the stakeholders, > or ccTLD operators, or VRSN, believes that by prohibiting zone transfers > they are preventing enumeration. They are preventing enumeration (i.e. provision of a 100% accurate copy by the ccTLD publishing the information). They are not preventing you or anyone else from compiling their own, incomplete and inaccurate work from information not derived from the ccTLD operator. >> ... though personally I agree with Phillip Hallam-Baker's analysis >> that more information is revealed. > > If he said that, he was wrong. More likely you misunderstood him. I am not sure which part of the following I am meant to have misunderstood before I agreed with it: --On 21 May 2004 20:31 -0700 "Hallam-Baker, Phillip" wrote: > The comparative attack analysis that has been offered is totally > bogus: > > The DNS system without DNSSEC provides a lookup function that > returns an answer to the question "is x a member of S" and returns a > binary response. > > With DNSSEC and NSEC you get a response "there are NO members of x > in the range a,b AND a,b are both members of S" > > Sorry, but anyone who claims that there is no security issue raised > here is speaking through their hat. The fact that I publish a binary > response function returning set membership does not mean that I am willing > to reveal the set. That is simply untrue. 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 Sat May 22 11:56:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14445 for ; Sat, 22 May 2004 11:56:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRYp1-0005NU-SE for namedroppers-data@psg.com; Sat, 22 May 2004 15:54:03 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRYp0-0005N4-Rt for namedroppers@ops.ietf.org; Sat, 22 May 2004 15:54:03 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 2BE3A1FDCB; Sat, 22 May 2004 16:54:02 +0100 (BST) Date: Sat, 22 May 2004 16:53:57 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <360339881.1085244837@[192.168.100.5]> In-Reply-To: <20040522150716.E2DB613E08@sa.vix.com> References: <20040522150716.E2DB613E08@sa.vix.com> X-Mailer: Mulberry/3.1.1 (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 22 May 2004 15:07 +0000 Paul Vixie wrote: > No, it's not moot, not yet anyway It is perhaps an interest reflection on the workings of the IETF that the requirements of those deploying the protocol (ignoring, for a minute, why they have those requirements) appear occasionally to be only a secondary consideration in protocol design. I would suggest there is perhaps a positive correlation between on the one hand to the IETF listening to to the requirements of those who want to deploy a protocol on the one hand, and the protocol actually getting deployed on the other. In the context of a requirement to preserve existing functionlity, the fact that *you* think requirements are misplaced (I don't, but who knows, in the final analysis you might well be right) doesn't cut much mustard when the requirement comes from the internet community, as communicated to those who are going to make the deployment decision. 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 Sat May 22 12:38: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 MAA15830 for ; Sat, 22 May 2004 12:38:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRZSK-000CuQ-Kf for namedroppers-data@psg.com; Sat, 22 May 2004 16:34:40 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRZSJ-000CuC-RU for namedroppers@ops.ietf.org; Sat, 22 May 2004 16:34:39 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3FED713E03 for ; Sat, 22 May 2004 16:34:39 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Alex Bligh of "Sat, 22 May 2004 16:53:57 +0100." <360339881.1085244837@[192.168.100.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 22 May 2004 16:34:39 +0000 Message-Id: <20040522163439.3FED713E03@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 > It is perhaps an interest reflection on the workings of the IETF that the > requirements of those deploying the protocol (ignoring, for a minute, why > they have those requirements) appear occasionally to be only a secondary > consideration in protocol design. I apologize for the apparent truth of that reflection, but it's inaccurate. SLD holders outnumber TLD holders by a factor of many millions. As an SLD holder I can tell you that I do not fear enumeration as much as I fear spoofing. There are a few SLD holders who hold the opposite view, just as among TLD holders you will find both views. When the "NO RR" was evaluated by the dnsext working group, these opposing requirements were taken into account, and anti-enumeration lost out. I had no dog in that race so this was only of academic interest to me -- "what does BIND have to implement?" and "how can we get DNSSEC done in a decade?" where my only concerns. If the WG made the wrong choice and if DNSSEC is unimplementable because TLD holders fear enumeration and so SLD holders will have secure path to the root zone, then it appears that there's really no choice except to declare failure. Perhaps Ohta or Bernstein would like to take a shot at the problem. > I would suggest there is perhaps a positive correlation between on the > one hand to the IETF listening to to the requirements of those who > want to deploy a protocol on the one hand, and the protocol actually > getting deployed on the other. Many voices were heard. Primary among them were SLD holders, who either don't care about enumeration, or who fear a two-decade approach to DNSSEC even more, or who fear spoofing even more. > In the context of a requirement to preserve existing functionlity, the > fact that *you* think requirements are misplaced (I don't, but who > knows, in the final analysis you might well be right) doesn't cut much > mustard when the requirement comes from the internet community, as > communicated to those who are going to make the deployment decision. What *I* think, since you mentioned it, is that TLD holders who fear enumeration think that restricting AXFR is actually preventing enumeration, and that if they'd spend a few years in the trenches against spammers and data miners they would come to the conclusion that "all useful malevolent forms of enumeration are already possible and are already being done" and would then conclude that a one-decade DNSSEC is better than a two-decade DNSSEC, given that all other things are equal. -- to unsubscribe send a message to namedroppers-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 May 22 16:55: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 QAA26762 for ; Sat, 22 May 2004 16:55:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRdOv-000C7w-Tx for namedroppers-data@psg.com; Sat, 22 May 2004 20:47:25 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRdOu-000C5h-IO for namedroppers@ops.ietf.org; Sat, 22 May 2004 20:47:24 +0000 Received: from [192.168.1.13] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Sat, 22 May 2004 16:47:23 -0400 id 00133C5A.40AFBC5B.000016F6 In-Reply-To: <20040522150716.E2DB613E08@sa.vix.com> References: <20040522150716.E2DB613E08@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <32DB9135-AC31-11D8-BC10-000A95CC77E2@verisignlabs.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: David Blacka Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 16:47:11 -0400 To: Paul Vixie X-Mailer: Apple Mail (2.613) 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 On May 22, 2004, at 11:07 AM, Paul Vixie wrote: > The thing that's boggling my mind at the moment is that the > stakeholders, > or ccTLD operators, or VRSN, believes that by prohibiting zone > transfers > they are preventing enumeration. It just ain't so, and while I'm still > Paul and he's still Robert and I can't authoritatively speak for him, I > suspect that Robert's use of the word "absurd" has to do with the > general > misconception that preventing direct enumeration at the DNS protocol > level > is actually buying anything for anybody. While I am in no way empowered to speak officially for VRSN, I will say that VeriSign probably doesn't care terribly much about "preventing enumeration", as you can download the zones yourself, if you care to. From my point of view (speaking as an individual), I am more worried about the operational impact of a bunch of knuckle-heads who decided to suck down COM via a NSEC chain walk because either a) they don't know they can just ftp the zone, b) they are too lazy to go through the moderate hoops in order to do so, or c) the want to use the information for something bad. On the other hand, it is hard to say if this activity will result in operational problems at all without a crystal ball. -- 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 Sat May 22 20:10: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 UAA05402 for ; Sat, 22 May 2004 20:10:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRgW3-000PzX-0C for namedroppers-data@psg.com; Sun, 23 May 2004 00:06:59 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRgW0-000Pz8-S7 for namedroppers@ops.ietf.org; Sun, 23 May 2004 00:06:57 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BRgVz-0008NB-00 for ; Sun, 23 May 2004 02:06:55 +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 ; Sun, 23 May 2004 02:06:55 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 May 2004 02:06:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: relevent? Date: Sun, 23 May 2004 02:06:52 +0200 Lines: 32 Message-ID: References: <20040522151325.ABB1313E3C@sa.vix.com> 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:8wLT6CLmNk1Onlr3RRPVoQRbQUc= 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 Paul Vixie writes: >> >> ... >> >> The verifier is able to discover that one out of all relevant wildcard >> >> situations apply, in this case the third of your clause. To do this >> >> it simply iterates over all possible candidates (a small number). ... >> > >> > it is not reasonable to ask a verifier to iterate in this additional way. >> >> Why not? > > because it's already iterating in several other ways, and this is basically > a new innermost-loop, and the span of the iteration can be controlled by an > attacker. The maximum iteration count needed can be computed from the domain name used in the query (e.g., a.b.c.d.e.f.com), so the attacker cannot influence the iteration count by returning special data. An attacker may cause clients to look up a name chosen by the attacker, perhaps as the worst case a.b.c.d.e.f.g.h.....z.com or similar. But the attacker is limited by the limits in the DNS protocol -- owner names cannot be longer than 255 octets. So the attacker can cause the client to compute a few hundred SHA-1 hashes, in the worst case. A few hundred SHA-1 hashes is fast compared to a 2048 bit RSA verify. And making a client perform a 2048 bit RSA verify is possible today, just send it an bogus KEY/SIG pair. Regards, 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 Sun May 23 01:13: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 BAA15720 for ; Sun, 23 May 2004 01:13:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRlF1-0005fa-4K for namedroppers-data@psg.com; Sun, 23 May 2004 05:09:43 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRlF0-0005fD-4Q for namedroppers@ops.ietf.org; Sun, 23 May 2004 05:09:42 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 22 May 2004 22:09:40 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sat, 22 May 2004 22:09:33 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 22 May 2004 22:09:40 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 22 May 2004 22:09:41 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 22 May 2004 22:09:40 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 22 May 2004 22:10:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposal to fix NSEC Date: Sat, 22 May 2004 22:09:38 -0700 Message-ID: Thread-Topic: Proposal to fix NSEC Thread-Index: AcRAQKbb5g0lW7FqQBOGEhpzaZQH0wAQzVKQ From: "Christian Huitema" To: "David Blacka" , "Paul Vixie" Cc: X-OriginalArrivalTime: 23 May 2004 05:10:12.0294 (UTC) FILETIME=[39CEEE60:01C44084] 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: quoted-printable > From my point of view (speaking as an individual), I am more worried > about the operational impact of a bunch of knuckle-heads who decided to > suck down COM via a NSEC chain walk ... Basic rate limiting may not prevent enumeration, but it can certainly mitigate the denial-of-service side-effect of such bone-headed behavior. -- Christian Huitema -- to unsubscribe send a message to namedroppers-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 May 23 05:33: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 FAA07679 for ; Sun, 23 May 2004 05:33:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRpGc-000OyJ-1H for namedroppers-data@psg.com; Sun, 23 May 2004 09:27:38 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRpGa-000Oy3-1A for namedroppers@ops.ietf.org; Sun, 23 May 2004 09:27:36 +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 i4N9R2rd024973; Sun, 23 May 2004 10:27:02 +0100 (BST) To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: relevent? In-Reply-To: Your message of "Sat, 22 May 2004 09:30:46 +0200." Date: Sun, 23 May 2004 10:27:02 +0100 Message-ID: <24972.1085304422@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Simon" == Simon Josefsson writes: Simon> Take the zone cut Simon> issue with NXT/NSEC, where you have two records with the Simon> same name/type/class, but must not confuse the two as one Simon> comes from the parent zone and one from the child zone. Simon> Catering for this wart may require changes to the backend Simon> of a DNS cache. Recall that NO (and likely also NSEC2, but Simon> I haven't read it) fixes the zone cut issue. To "fix the zone cut issue", a delegation's NS and any glue records would need to be in exactly one place: the child or parent, probably the parent. AFAIK, the NO and NSEC2 drafts don't suggest that. -- to unsubscribe send a message to namedroppers-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 May 23 08:58: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 IAA15158 for ; Sun, 23 May 2004 08:58:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRsUN-000A1L-V2 for namedroppers-data@psg.com; Sun, 23 May 2004 12:54:03 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRsUM-000A0s-MG for namedroppers@ops.ietf.org; Sun, 23 May 2004 12:54:02 +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 i4NCs0rd025205; Sun, 23 May 2004 13:54:00 +0100 (BST) To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Alex Bligh of "Sat, 22 May 2004 09:55:58 BST." <335260799.1085219758@[192.168.100.5]> Date: Sun, 23 May 2004 13:54:00 +0100 Message-ID: <25204.1085316840@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Alex" == Alex Bligh writes: Alex> I'm not going to put privileged legal advice on list (drop Alex> me a note off-list if you like) but suffice to say the old Alex> saw about ask two different lawyers, get two different Alex> answers is all the more true in two different jurisdictions. But the EU directive in question applies in both jurisdictions. And anyway the answer a lawyer gives can depend on the question asked. Alex> For me the point, however, isn't wholly about the law. It's Alex> about what stakeholders want. Even when they're misguided? Or if they want the impossible? Note too that this DNS stakeholder wants his zones secured from spoofing. And he wants that now. Though perhaps that's also a misguided demand for the impossible. :-) Alex> Current RFCs permit non-publication. No they don't, though I suspect this depends on your definition of "publication". No DNS RFC says anything about access controls. Apart from saying servers can sometimes return REFUSED -- which may or may not be for reasons to do with access controls -- the RFCs are silent on this matter. So the current RFCs neither prohibit or allow non-publication, for your definition of this term. In purely DNS terms, entering names into a public zone file constitutes publication. If something isn't to be published, it shouldn't go in the DNS. Alex> The current DNSsec proposal prohibits this. Wrong again. The current drafts just make it more explicit that attempts to conceal a zone's contents by restricting zone transfers -- ie security through obscurity -- are futile. This should not come as a surprise to anyone. As has already been pointed out, there are many techniques that are currently in use to enumerate a zone. It seems some of us haven't yet got over that. Sigh. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 23 10:32: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 KAA19530 for ; Sun, 23 May 2004 10:32:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRtvp-0000NM-2U for namedroppers-data@psg.com; Sun, 23 May 2004 14:26:29 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRtvm-0000Li-7V for namedroppers@ops.ietf.org; Sun, 23 May 2004 14:26:26 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4NEQNYM022195; Sun, 23 May 2004 07:26:24 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 23 May 2004 07:26:23 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 07:26:19 -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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... though personally I agree with Phillip Hallam-Baker's analysis > > that more information is revealed. > > If he said that, he was wrong. More likely you misunderstood > him. The same information is revealed, it just happens slightly > later and is an indirect activity. This shows why DNSEXT should transfer work on DNSSEC to the security area. From a security point of view more information IS revealled. The computational difficulty of arriving at an enumeration is significantly reduced with the DNSEXT. The alternative attack routes suggested as equivalent are not. Comparative security analysis is a VERY weak form of argument. A huge number of security vulnerabilities result from faulty comparative argument, in fact it is one of the most common causes of security flaws. The errors in WEP were due to that type of reasoning. The IETF has a reputation for designing security mechanisms that are so completely over-designed that they are undeployable, while failing to meet security requirements considered critical by end users. IPSEC refused to address NAT but created a negotiation mechanism for key negotiation. If you want anyone to use DNSSEC then you had better address the requirements of the security community. 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 Sun May 23 11:07: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 LAA21500 for ; Sun, 23 May 2004 11:07:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRuWa-0006Ol-RP for namedroppers-data@psg.com; Sun, 23 May 2004 15:04:28 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRuWZ-0006NM-I3 for namedroppers@ops.ietf.org; Sun, 23 May 2004 15:04:27 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4NF4Nge008789; Sun, 23 May 2004 08:04:23 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 23 May 2004 08:04:23 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'David Blacka'" , Paul Vixie Cc: namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 08:04:13 -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.9 required=5.0 tests=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 David Blacka > While I am in no way empowered to speak officially for VRSN, > I will say > that VeriSign probably doesn't care terribly much about "preventing > enumeration", as you can download the zones yourself, if you care to. I am not speaking for VRSN here officially either. Registry services may not have a position here. Security Services is very likely to form one. Several proposed anti-spam and anti-phishing measures use the DNS in a fashion that could benefit from DNSSEC but not if doing so opened up zone enumeration. 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 Sun May 23 11:37: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 LAA22148 for ; Sun, 23 May 2004 11:37:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRuxm-000B6N-FK for namedroppers-data@psg.com; Sun, 23 May 2004 15:32:34 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRuxe-000B2q-Kc for namedroppers@ops.ietf.org; Sun, 23 May 2004 15:32:26 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4NFWHA7027676; Sun, 23 May 2004 08:32:17 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 23 May 2004 08:32:17 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 08:32:13 -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.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > SLD holders outnumber TLD holders by a factor of many > millions. As an SLD > holder I can tell you that I do not fear enumeration as much as I fear > spoofing. There are a few SLD holders who hold the opposite > view, just as > among TLD holders you will find both views. You are not typical of an SLD holder. The community that has to be convinced here are the people who operate corporate firewalls. If you do not have a firewall yet you are not going to be interested in DNSSEC. I speak to that communiuty on a regular basis. We actually operate a lot of firewalls on an outsourced basis. That community does not want to have people walk their domain for very good reason. Dealling with attacks costs real money. Allowing domain enumeration will cost these people real money as it will mean that systems will be attacked which the attacker would not otherwise have discovered. > When the "NO RR" was evaluated by the dnsext working group, > these opposing > requirements were taken into account, and anti-enumeration > lost out. So did reality. Agenda denial is not a very credible tactic. Demand for DNSSEC is negligible. Give me the names of ten supporters of DNSSEC in its current form who are influential in the security community. Not only is the community of potential DNSSEC users not represented in this group, any time someone does drop by to make a request they get met with hostility and patronizing remarks. > If the WG made the wrong choice and if DNSSEC is > unimplementable because TLD > holders fear enumeration and so SLD holders will have secure > path to the > root zone, then it appears that there's really no choice > except to declare failure. Ah my way or the high way eh? > > I would suggest there is perhaps a positive correlation > between on the > > one hand to the IETF listening to to the requirements of those who > > want to deploy a protocol on the one hand, and the protocol actually > > getting deployed on the other. > > Many voices were heard. Primary among them were SLD holders, > who either > don't care about enumeration, or who fear a two-decade approach to > DNSSEC even more, or who fear spoofing even more. The requirement denial approach seems to be the main reason for delay. DNSSEC would have been deployed already if OPTIN had been accepted. > What *I* think, since you mentioned it, is that TLD holders who fear > enumeration think that restricting AXFR is actually preventing The enumeration issue is going to be a much bigger issue at the SLD level. In fact that is what the NSA guy said in a DNSEXT meeting four years ago, for him enumeration is a real issue. The only reason this is taking so long is institutional. Over a century of use has proved Roberts Rules of order to be a much more effective way to run a meeting than the IETF has devised. In OASIS we regularly complete specs much more complex than DNSSEC within two years. I suggest that the solution to this problem is to submit a new draft that describes an OPT-IN and OBFUSCATED NXT record as 'experimental'. The spam and phishing groups do not care a jot over spec level issues but they do care about deployability, the enumeration issue and who is prepared to endorse the spec. It is also much more likely that this application area will be a killer app for DNSSEC than preventing spoofing. It has taken ten years and a major spam crisis for people to realize that email spoofing was a sufficiently bad thing that something should be done about 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 Sun May 23 11:55: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 LAA22795 for ; Sun, 23 May 2004 11:55:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRvGi-000E1A-Td for namedroppers-data@psg.com; Sun, 23 May 2004 15:52:08 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRvGh-000E0l-7l for namedroppers@ops.ietf.org; Sun, 23 May 2004 15:52:07 +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 i4NFq6Xi016571 for ; Sun, 23 May 2004 17:52:06 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4NFq6L16015 for ; Sun, 23 May 2004 17:52:06 +0200 (MEST) Message-Id: <200405231552.i4NFq6L16015@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: Proposal to fix NSEC In-reply-to: Your message of "Sun, 23 May 2004 08:32:13 PDT." 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: <16010.1085327522.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Sun, 23 May 2004 17:52:05 +0200 From: Peter Koch 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 "Hallam-Baker, Phillip" wrote: > That community does not want to have people walk their domain > for very good reason. Dealling with attacks costs real money. > Allowing domain enumeration will cost these people real money > as it will mean that systems will be attacked which the attacker > would not otherwise have discovered. this "ostrich approach" is the one reason why I'd really like to see NSEC in its current form. Zone walking/AXFR has nothing to do with end system security and "hiding" potential attack targets by AXFR blocks is dangerous at best. What do these people do to make their IP adresses less guessable? Deploy IPv6? This is not what the thread was started for and this kind of "security" will distract from the real deployment issue here. The "registry type" zones are special and it's them we need a solution for. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 23 14:09:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27691 for ; Sun, 23 May 2004 14:09:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRxLe-000Bqj-DK for namedroppers-data@psg.com; Sun, 23 May 2004 18:05:22 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRxLc-000Bq6-KD for namedroppers@ops.ietf.org; Sun, 23 May 2004 18:05:20 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B67BB1FDCB; Sun, 23 May 2004 19:05:18 +0100 (BST) Date: Sun, 23 May 2004 19:05:12 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jim Reid Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <454615362.1085339112@[192.168.100.5]> In-Reply-To: <25204.1085316840@gromit.rfc1035.com> References: <25204.1085316840@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, --On 23 May 2004 13:54 +0100 Jim Reid wrote: > But the EU directive in question applies in both jurisdictions. And > anyway the answer a lawyer gives can depend on the question asked. As I am sure you know, EU directives (as opposed to regulations and treaty articles) are implemented by national law, and the implementation can vary. Further, they are implemented in the context of existing national law, which varies. But heh, let's not make this alt.lawyers.barrackroom. > Alex> For me the point, however, isn't wholly about the law. It's > Alex> about what stakeholders want. > > Even when they're misguided? Or if they want the impossible? It isn't impossible. We have supplied an example demonstrating making zonefiles not enumerable via DNSSEC. Noone yet has suggested NSEC2 is fatally flawed. The consequent effects on delay of implementation may be undesirable, but that is a different point. Nor, in my view, is it misguided. Note people are not asking that it ccTLDs should make it impossible to discover the contents of their zones to any extent. They are simply asking that ccTLDs should not themselves publish them in toto. > Note too that this DNS stakeholder wants his zones secured from > spoofing. And he wants that now. Though perhaps that's also a > misguided demand for the impossible. :-) > > Alex> Current RFCs permit non-publication. > > No they don't, though I suspect this depends on your definition of > "publication". No DNS RFC says anything about access controls. Apart > from saying servers can sometimes return REFUSED -- which may or may > not be for reasons to do with access controls -- the RFCs are silent > on this matter. They permit a refused answer. They do not specify how that can be generated. Where RFCs permit behavior (refused) and do not constain when that behavior may or may not be used, it is up to local policy. And, indeed, that administrative (policy) refusal appears to be utilized by every DNS server codebase in non-minimal deployment, many of whom claim RFC compatibility. > Alex> The current DNSsec proposal prohibits this. > > Wrong again. The current drafts just make it more explicit that > attempts to conceal a zone's contents by restricting zone transfers -- All it seems to me they say is that NSEC is mandatory, and zone enumeration is a consequence of NSEC. > ie security through obscurity -- are futile. Your view is that it is futile. That view appears not to be shared by everyone. I would suggest it is not shared by those who bother to lock down AFXR either. I am surprised if you wouldn't go so far as to allow that it was a matter of opinion. And in the end, the view that matters is the view of those who want to deploy it (and, in registry cases, their stakeholders). Otherwise you will have designed a protocol which is perceived as flawed, and no matter how much you say that the perception is wrong (whether you are right or wrong), it's deployment will be significantly hindered. I can tell you that the interest in zonefile enumeration and spam, exceeds interest in DNSSEC deployment by a couple of orders of magnitude in terms of the people I talk to. Many see the security issues in DNS fixed by the little padlock that appears on their web browser. Many of the more enlightened ones see DNSSEC as an undeployable nightmare. Please bear in mind I am making the foregoing statements as a DNSSEC supporter, and in the context of an organization for whom deployment of DNSSEC is a key strategic aim. The point is that if you want better stakeholder acceptance, and hence greater deployment, listening to people's concerns is important. To me it seems a fair view of the argument goes like this: 1. Current DNSSEC permits enumerability. Previous DNS did not prohibit disallowing enumerability through AXFR, and as such that became a feature in all significant nameserver deployments, that has been utilized by many people. 2. Some people view preventing enumerability as important from a local policy point of view. Amongst those are ccTLD operators who are concerned for reasons of data protection, copyright, spam and local internet community driven policy. Also amongst those are certain members of the security community who fear leakage of information. 3. A further number of people believe the policy of those in (2) to be futile, for various non-DNSSEC related reasons. 4. Fixing the concerns in (2), via NSEC2 or otherwise, can only delay DNSSEC being ready for deployment. Everyone wants DNSSEC to be deployable quickly. It is possible there is a fix or workaround less likely to delay than NSEC2, but if there is, it hasn't been published here. 5. Fixing (2) is likely increase the speed and scope of deployment once the protocol is ready for deployment, on the basis those holding view (2) above are less likely to deploy, and less likely to deploy quickly, if their concerns are not addressed. Further, fixing (2) after significant deployment is likely to be problematic. I believe (3) is a red-herring for this group: it seems to me a local policy issue, and however ill-advised you might feel people to be to take that policy, the case is at least arguable and new revisions of protocols should not break existing functionality. What I believe we are talking about is a simple trade-off between (2) and (5) on the one hand, and (4) on the other. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 23 15:32: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 PAA02161 for ; Sun, 23 May 2004 15:32:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRydF-000Pbp-1e for namedroppers-data@psg.com; Sun, 23 May 2004 19:27:37 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BRydD-000Pbc-Qd for namedroppers@ops.ietf.org; Sun, 23 May 2004 19:27:35 +0000 Received: (qmail 84337 invoked by uid 1016); 23 May 2004 19:27:50 -0000 Date: 23 May 2004 19:27:50 -0000 Message-ID: <20040523192750.84336.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Magical enumeration techniques References: <335260799.1085219758@[192.168.100.5]> <25204.1085316840@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: > The current drafts just make it more explicit that > attempts to conceal a zone's contents by restricting zone transfers -- > ie security through obscurity -- are futile. I have two TXT records for names of the form k.cr.yp.to, where k is a hex MD5 hash of some cryptographic data. One of them is '762fa7ce541bf0817b4f913a2b51a5cd.cr.yp.to:0d32ae8d1ef36e9c71fef18c9a603299 in tinydns format. Please tell us the other one. ---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 May 23 15:48: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 PAA02849 for ; Sun, 23 May 2004 15:48:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRyvU-00031C-Kd for namedroppers-data@psg.com; Sun, 23 May 2004 19:46:28 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRyvT-00030Y-EK for namedroppers@ops.ietf.org; Sun, 23 May 2004 19:46:27 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4NJkLU9029800; Sun, 23 May 2004 12:46:21 -0700 (PDT) Received: from [205.214.163.10] (vpn-10-50-16-53.qualcomm.com [10.50.16.53]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4NJkF3P017382; Sun, 23 May 2004 12:46:16 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <454615362.1085339112@[192.168.100.5]> References: <25204.1085316840@gromit.rfc1035.com> <454615362.1085339112@[192.168.100.5]> Date: Sun, 23 May 2004 12:46:13 -0700 To: Alex Bligh , Jim Reid From: Ted Hardie Subject: Re: Proposal to fix NSEC Cc: namedroppers@ops.ietf.org, Alex Bligh 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:05 PM +0100 05/23/2004, Alex Bligh wrote: >And in the end, the view that matters is the view of those who want to >deploy it (and, in registry cases, their stakeholders). Otherwise you will >have designed a protocol which is perceived as flawed, and no matter how >much you say that the perception is wrong (whether you are right or wrong), >it's deployment will be significantly hindered. I can tell you that the >interest in zonefile enumeration and spam, exceeds interest in DNSSEC >deployment by a couple of orders of magnitude in terms of the people I talk >to. First, to mention something that is in no way Alex's fault, I have to say that I find the use of the term "stakeholder" makes my teeth hurt. Different individuals have different interests, and lumping them together such that "regulatory powers with guns", "captive customers", and "end users" are all in the same bucket just makes no sense to me. Not all that salient, really, so forgive the digression. Second, we're here to make engineering decisions. We're not trying to make those in ignorance of regulatory realities or operational desires, but we have to recognize that it only makes sense for us to discuss them here in terms of the engineering effects (we're not going to change regulations in any jurisdiction, get people to be "more interested" in one thing than another, or otherwise change the political or economic landscape). We also need to recognize that the DNS is used in many jurisdictions for many different purposes. At this very late stage, taking in a last minute change to this set of specs both doesn't serve the long-unslaked thirst for deployment and would appear (note that verb, please) to privilege one set of interests after long discussion had come to other conclusions. Put bluntly, we're at the "find technical errors stage", not the design stage. The behavior folks are trying to adjust is a known element of the design and has been for a long time. It is not a technical error and a last minute attempt to adjust it doesn't make sense. Speaking personally, and with regards for all concerned, Ted Hardie -- to unsubscribe send a message to namedroppers-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 May 23 15:56: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 PAA03411 for ; Sun, 23 May 2004 15:56:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRz3M-00053m-Qd for namedroppers-data@psg.com; Sun, 23 May 2004 19:54:36 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRz3I-0004zX-4M for namedroppers@ops.ietf.org; Sun, 23 May 2004 19:54:32 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BRz3G-00087e-00 for ; Sun, 23 May 2004 21:54:30 +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 ; Sun, 23 May 2004 21:54:30 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 May 2004 21:54:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: relevent? Date: Sun, 23 May 2004 21:54:27 +0200 Lines: 22 Message-ID: References: <24972.1085304422@gromit.rfc1035.com> 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:SUc7WANNpX+jrTKd14IDnRkmvyE= 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 Jim Reid writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> Take the zone cut > Simon> issue with NXT/NSEC, where you have two records with the > Simon> same name/type/class, but must not confuse the two as one > Simon> comes from the parent zone and one from the child zone. > Simon> Catering for this wart may require changes to the backend > Simon> of a DNS cache. Recall that NO (and likely also NSEC2, but > Simon> I haven't read it) fixes the zone cut issue. > > To "fix the zone cut issue", a delegation's NS and any glue records > would need to be in exactly one place: the child or parent, probably > the parent. AFAIK, the NO and NSEC2 drafts don't suggest that. Right. I meant the additional zone cut issue introduced by DNSSEC. To fix the issue completely would require more drastic measures, but I'm not sure anyone has been suggesting this. Regards, 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 Sun May 23 16:17: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 QAA04323 for ; Sun, 23 May 2004 16:17:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRzN9-0009zK-E4 for namedroppers-data@psg.com; Sun, 23 May 2004 20:15:03 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRzN8-0009yr-AI for namedroppers@ops.ietf.org; Sun, 23 May 2004 20:15:02 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i4NKF1lF026846; Sun, 23 May 2004 13:15:01 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 23 May 2004 13:15:01 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Peter Koch'" , namedroppers@ops.ietf.org Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 13:15: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.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 Peter writes: > this "ostrich approach" is the one reason why I'd really like > to see NSEC in its current form. Nobody has yet specified an attack that has anything like the effectiveness of zone walking. > Zone walking/AXFR has nothing to do with end system security > and "hiding" potential attack targets by AXFR blocks is > dangerous at best. You argument amounts to 'security through plain sight' which is as discredited as security through obscurity. The application of design arguments such as security through obscurity and end-to-end to operations is a bad mistake. It is even worse to turn that argument into an ideology and attempt to ridicule those who say the ideology is false. Please do not attempt to claim superior expertise in this area again. > What do these people do to make their IP adresses less > guessable? Deploy IPv6? Deployment of NAT for this purpose is near universal. The IETF tried to fight that for years as well. I am aware of the paper by Steve Bellovin on guessing IP addresses behind NAT, as with your proposed dictionary attack it is orders of magnitude harder and less reliable than direct observation. > This is not what the thread was started for and this kind of > "security" will > distract from the real deployment issue here. The "registry > type" zones are > special and it's them we need a solution for. Actually the same issue is true at the second level. Allowing zone walking is not considered good security practice at any level. -- to unsubscribe send a message to namedroppers-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 May 23 16:28: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 QAA04695 for ; Sun, 23 May 2004 16:28:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRzXd-000C2j-8A for namedroppers-data@psg.com; Sun, 23 May 2004 20:25:53 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRzXb-000C2L-Su for namedroppers@ops.ietf.org; Sun, 23 May 2004 20:25:52 +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 i4NKPmrd025679; Sun, 23 May 2004 21:25:49 +0100 (BST) To: Alex Bligh cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Alex Bligh of "Sat, 22 May 2004 16:38:36 BST." <359418887.1085243916@[192.168.100.5]> Date: Sun, 23 May 2004 21:25:48 +0100 Message-ID: <25678.1085343948@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Alex" == Alex Bligh writes: Alex> Just to illustrate the point, can you tell me what the Alex> domain is in Nominet's zonefile right now, alphabetically Alex> immediately following alex.org.uk. The 10 next ones? No, you Alex> can't, without access to a secondary. Why do you think this information is of any value? Why is it worth trying to conceal it, even though it's not that hard to find? More to the point, why do these stakeholders you keep banging on about? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 23 16:41: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 QAA05391 for ; Sun, 23 May 2004 16:41:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BRzjg-000E5V-2H for namedroppers-data@psg.com; Sun, 23 May 2004 20:38:20 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BRzje-000E58-Rv for namedroppers@ops.ietf.org; Sun, 23 May 2004 20:38:18 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4NKcGKq007406; Sun, 23 May 2004 13:38:16 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 23 May 2004 13:38:16 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" , Alex Bligh , Jim Reid Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 13:38: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.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 > First, to mention something that is in no way Alex's fault, I > have to say > that I find the use of the term "stakeholder" makes my teeth hurt. > Different individuals have different interests, and lumping > them together > such that "regulatory powers with guns", "captive customers", and > "end users" are all in the same bucket just makes no sense to me. How else can we address deployment other than by looking at the people who might deploy but have refused to and asking them why they did not? I agree that it would be much better to address the fact that there are many stakeholders and that their interests may conflict. But your argument seems to be that because there might be some stakeholders that are not represented that they should all be ignored. > We also need to recognize > that the DNS is used in many jurisdictions for many different > purposes. The many jurisdicitions argument does not mean that we should ignore all of them. In practice the type of legislation that has an effect on engineering work tends to be remarkably consistent across jurisdictions. > At this very late stage, taking in a last minute change to this set of > specs both doesn't serve the long-unslaked thirst for deployment > and would appear (note that verb, please) to privilege one set of > interests after long discussion had come to other conclusions. Nobody has yet stated an opposed interest here, there has been a lot of 'protect the spec from change at all costs' and some 'lets force people to accept our security ideology' but no real assertion of a valid opposition. Having watched the previous discussions I did not see any real debate over opposed interests then either. In fact all I have seen for five years is the argument, 'we cannot fix the spec to make it deployable, it will be deployed so very soon'. > Put bluntly, we're at the "find technical errors stage", not > the design > stage. The behavior folks are trying to adjust is a known element of > the design and has been for a long time. It is not a technical error > and a last minute attempt to adjust it doesn't make sense. If this argument wins I predict that we will be debating the same exact argument in three years time. I don't think the merits of this issue have ever been debated, I think we got fobbed off with the same agenda denial tactics three and five years ago. Then we had some fillibustering to make real sure that some people got their way even if the majority disagreed. I suggest that the way forward here is for a small group to design an NXT that works, that we submit it as experimental and we let the market decide who is right. The only reason the market is going to make a choice for experimental over an approved standard is if there is a genuine issue with the approved version. -- to unsubscribe send a message to namedroppers-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 May 23 16:58: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 QAA06096 for ; Sun, 23 May 2004 16:58:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS00H-000Hwn-QC for namedroppers-data@psg.com; Sun, 23 May 2004 20:55:29 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS00G-000Hup-Bk for namedroppers@ops.ietf.org; Sun, 23 May 2004 20:55:28 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 3A5FD1FDCB; Sun, 23 May 2004 21:55:27 +0100 (BST) Date: Sun, 23 May 2004 21:55:20 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jim Reid Cc: Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Proposal to fix NSEC Message-ID: <464823040.1085349320@[192.168.100.5]> In-Reply-To: <25678.1085343948@gromit.rfc1035.com> References: <25678.1085343948@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.1 (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 23 May 2004 21:25 +0100 Jim Reid wrote: > Alex> Just to illustrate the point, can you tell me what the > Alex> domain is in Nominet's zonefile right now, alphabetically > Alex> immediately following alex.org.uk. The 10 next ones? No, you > Alex> can't, without access to a secondary. > > Why do you think this information is of any value? I am illustrating that Paul cannot enumerate the zone either accurately or completely. Or did you mean why is the zone as a whole of any value? Because people (stakeholders) care about to what purpose ccTLDs data is put to, hence the operators care for the same reason. For some but not all values of "care" this is reflected in the law. I would suggest the facts (i) that many if not every ccTLD operator has been the targets of attacks by various groups attempting to extract data, and several have, with varying degrees of success and at considerable expense, tried to sue such people, (ii) a considerable of ICANN/GAC/ccTLD debate is spent on the intellectual property of the zonefile suggests that the information is valuable to someone. > Why is it worth > trying to conceal it, even though it's not that hard to find? If it's not that hard to find, Paul would be able to answer my question. Perhaps you can. > More > to the point, why do these stakeholders you keep banging on about? See above. They do not want ccTLD operators publishing lists of domain names registered, as they fear (accurately) those lists will be misused. Just because there are other ways to get partial, inaccurate lists of some of the domain names concerned, they do not see why the ccTLD operator should be complicit in this. As I said before, just because someone can break into your flat, it doesn't mean the landlord should help them. I believe the view has a good foundation in logic, but in the final analysis it doesn't much matter to me if they believe the reason not to have enumerable zonefiles is it increases the prevalence of bluebirds flying over rainbows; at least in Nominet's case, the obligation is to implement policy in the interests of, and in consultation with stakeholders, which (to avoid people's teeth being put on edge) is the old RFC1591 "in the interests of the local internet community". I am not sufficiently paternalistic to tell them what is in their interests and what is not. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 23 17:02: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 RAA06288 for ; Sun, 23 May 2004 17:02:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS04W-000J0L-7s for namedroppers-data@psg.com; Sun, 23 May 2004 20:59:52 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS04V-000IzV-8q for namedroppers@ops.ietf.org; Sun, 23 May 2004 20:59:51 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 9F9651FDCB; Sun, 23 May 2004 21:59:50 +0100 (BST) Date: Sun, 23 May 2004 21:59:44 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Hallam-Baker, Phillip" , "'Ted Hardie'" , Jim Reid Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: RE: Proposal to fix NSEC Message-ID: <465087580.1085349584@[192.168.100.5]> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 23 May 2004 13:38 -0700 "Hallam-Baker, Phillip" wrote: >> First, to mention something that is in no way Alex's fault, I >> have to say >> that I find the use of the term "stakeholder" makes my teeth hurt. >> Different individuals have different interests, and lumping >> them together >> such that "regulatory powers with guns", "captive customers", and >> "end users" are all in the same bucket just makes no sense to me. > > How else can we address deployment other than by looking at the > people who might deploy but have refused to and asking them why > they did not? To be fair I was talking about Nominet's stakeholders. And for various reasons, mostly internal but given the issue was a surprise to certain other ccTLDs too not entirely, we (Nominet) were perhaps less involved in this process earlier on than we might have been - which we are now seeking to correct: not by whinging from the sidelines, but by contributing. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 23 17:10: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 RAA07056 for ; Sun, 23 May 2004 17:10:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS0CC-000KrE-32 for namedroppers-data@psg.com; Sun, 23 May 2004 21:07:48 +0000 Received: from [193.176.144.164] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS0C7-000KqL-Su for namedroppers@ops.ietf.org; Sun, 23 May 2004 21:07:44 +0000 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.11/8.12.11) with ESMTP id i4NL7fTU039868; Sun, 23 May 2004 23:07:41 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200405232107.i4NL7fTU039868@bartok.sidn.nl> To: David Blacka cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-reply-to: Your message of Sat, 22 May 2004 16:47:11 -0400. <32DB9135-AC31-11D8-BC10-000A95CC77E2@verisignlabs.com> Date: Sun, 23 May 2004 23:07:41 +0200 From: Jaap Akkerhuis 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 From my point of view (speaking as an individual), I am more worried about the operational impact of a bunch of knuckle-heads who decided to suck down COM via a NSEC chain walk. (s/COM/a zone/) That is my personal worry as well. I really don't want throw a lot of resources to nameservers to accomodate script kiddies. On the other hand, it is hard to say if this activity will result in operational problems at all without a crystal ball. We had a secured nl zone up for a year. This was published overhere. When the zone came up, we noticed a lot of AXFR attempts. The only zone walking activities noticed were our own attempts. But of course, this doesn't mean that such thong won't happen when it will be more common. jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 23 17:32: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 RAA07803 for ; Sun, 23 May 2004 17:32:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS0X4-000OiW-76 for namedroppers-data@psg.com; Sun, 23 May 2004 21:29:22 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS0X3-000OiH-HP for namedroppers@ops.ietf.org; Sun, 23 May 2004 21:29:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 28F8E13E4E for ; Sun, 23 May 2004 21:29:21 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Jaap Akkerhuis of "Sun, 23 May 2004 23:07:41 +0200." <200405232107.i4NL7fTU039868@bartok.sidn.nl> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 23 May 2004 21:29:21 +0000 Message-Id: <20040523212921.28F8E13E4E@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 really don't want throw a lot of resources to nameservers to > accomodate script kiddies. as if any of us had a choice about that any more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 23 17:32: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 RAA07826 for ; Sun, 23 May 2004 17:32:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS0Vw-000OVS-3Z for namedroppers-data@psg.com; Sun, 23 May 2004 21:28:12 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS0Vn-000OUq-7a for namedroppers@ops.ietf.org; Sun, 23 May 2004 21:28:03 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C9BB613E48 for ; Sun, 23 May 2004 21:28:02 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Alex Bligh of "Sun, 23 May 2004 21:55:20 +0100." <464823040.1085349320@[192.168.100.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 23 May 2004 21:28:02 +0000 Message-Id: <20040523212802.C9BB613E48@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 > > Alex> Just to illustrate the point, can you tell me what the > > Alex> domain is in Nominet's zonefile right now, alphabetically > > Alex> immediately following alex.org.uk. The 10 next ones? No, you > > Alex> can't, without access to a secondary. > > > > Why do you think this information is of any value? > > I am illustrating that Paul cannot enumerate the zone either accurately or > completely. i never said i could. what i said was that i could get a complete useful enumeration, containing everything a spammer or marketroid would need in order to make "the bad use" of whois that ccTLD's supposedly don't want made. -- to unsubscribe send a message to namedroppers-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 May 23 19:11: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 TAA13286 for ; Sun, 23 May 2004 19:11:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS24P-000KmT-Lo for namedroppers-data@psg.com; Sun, 23 May 2004 23:07:53 +0000 Received: from [192.35.165.131] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS24G-000Kht-Iq for namedroppers@ops.ietf.org; Sun, 23 May 2004 23:07:44 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 90132319FC8 for ; Sun, 23 May 2004 16:07:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Scope of discussion (was Re: Proposal to fix NSEC) Date: Sun, 23 May 2004 16:07:47 -0700 X-Mailer: Apple Mail (2.613) 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 Dear Colleagues, I would like to narrow the discussion. With reference to an earlier message [1]. I think it is clear at this point that the current DNSSEC-bis protocol spec eases content enumeration; I think it is clear that this causes a number of TLDs (and other players) to believe that they cannot deploy DNSSEC in its current form. Please refrain from further discussion of these two points; this is a real issue. The question on the table is what this WG needs to do. In my previous mail I have listed two possibilities. Taking up work to prevent zone enumeration while holding the DNSSEC bis document-set or shipping DNSSEC bis and forgetting about solving the enumeration problem. Off course there are other options. Ship the document DNSSEC-bis document set and work out the enumeration problem later (but commit on finding a solution). The 3rd option may not be that bad given that DNSSEC-bis conforms to the requirements of a Proposed standard and that it is (should be) clear that Proposed Standards are subject to change (RFC2026, 4.1.1). If we go this route we have to realize that we have to field new technology that _may_ not interoperate with DNSSEC bis. There may be other ways of going forward, stalling development of NSEC2 but introduce a mechanism into DNSSEC-bis that introduces versioning of NSEC, if you see the signal you should expect the new features (say NSEC2) or treat the zone as unsecured. That would delay too, but maybe not that long. Rough consensus is difficult to read from the current thread. It would help if you make your (motivated) position clearer and provide your arguments for taking one of the options. Do so before June 1. Two additional remarks: + PLEASE REVIEW THE DNSSEC-bis DOCUMENT SET, review is orthogonal to this discussion. + Please remain courteous and discuss arguments on the quality of the arguments, qualities of the author are out of scope. Thanks, --Olaf Kolkman DNSEXT co-chair (Olafur is still away from keyboard) [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00489.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: From owner-namedroppers@ops.ietf.org Sun May 23 20:29: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 UAA16464 for ; Sun, 23 May 2004 20:29:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS3IV-000B5e-Bo for namedroppers-data@psg.com; Mon, 24 May 2004 00:26:31 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS3IU-000B4F-46 for namedroppers@ops.ietf.org; Mon, 24 May 2004 00:26:30 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i4O0QRaR029675; Sun, 23 May 2004 17:26:28 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Sun, 23 May 2004 17:25:12 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Olaf Kolkman'" , namedroppers@ops.ietf.org Subject: RE: Scope of discussion (was Re: Proposal to fix NSEC) Date: Sun, 23 May 2004 17:25:11 -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 > In my previous mail I have listed two possibilities. Taking > up work to > prevent zone enumeration while holding the DNSSEC bis document-set or > shipping DNSSEC bis and forgetting about solving the enumeration > problem. Off course there are other options. Ship the document > DNSSEC-bis document set and work out the enumeration problem > later (but > commit on finding a solution). I strongly suggest option 3 with one proviso: Where the docs say MUST use NSEC say "MUST use a mechanism that provides proof of non-existence" > There may be other ways of going forward, stalling > development of NSEC2 > but introduce a mechanism into DNSSEC-bis that introduces > versioning of > NSEC, if you see the signal you should expect the new features (say > NSEC2) or treat the zone as unsecured. That would delay too, > but maybe not that long. Better than trying to go forward with deployment and discovering that there is a protocol deficiency that cannot be fixed after the fact. People get paranoid about crypto specs, I used to. Then I started an essay where I tried to prove this, only when I started to look at the evidence SSL is in much better shape than anything else despite being a disaster in original form, likewise with WEP. Throw the stuff over the fence and see what sticks. Empirically that is the best way to get to security. -- to unsubscribe send a message to namedroppers-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 May 23 21:11: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 VAA17941 for ; Sun, 23 May 2004 21:11:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BS3wN-000Ji6-Mv for namedroppers-data@psg.com; Mon, 24 May 2004 01:07:43 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BS3wM-000Jhr-Tg for namedroppers@ops.ietf.org; Mon, 24 May 2004 01:07:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5ADAF13E5A for ; Mon, 24 May 2004 01:07:42 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) In-Reply-To: Message from Olaf Kolkman of "Sun, 23 May 2004 16:07:47 MST." <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 24 May 2004 01:07:42 +0000 Message-Id: <20040524010742.5ADAF13E5A@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 > The question on the table is what this WG needs to do. > ... > The 3rd option may not be that bad given that DNSSEC-bis conforms to the > requirements of a Proposed standard and that it is (should be) clear that > Proposed Standards are subject to change (RFC2026, 4.1.1). If we go this > route we have to realize that we have to field new technology that _may_ > not interoperate with DNSSEC bis. that's not realistic. if dnssec-bis takes off and creates an installed base, then there will be no incompatible changes to it between PS/DS/FS, and those stages will just be used to refine the documents based on implementation and deployment experience. if dnssec-bis fails to take off for ANY reason, then getting more funding or development, or being taken seriously when saying "we really think we've got it right this time," has a likelihood approaching zero. > There may be other ways of going forward, stalling development of NSEC2 but > introduce a mechanism into DNSSEC-bis that introduces versioning of NSEC, > if you see the signal you should expect the new features (say NSEC2) or > treat the zone as unsecured. That would delay too, but maybe not that long. > > Rough consensus is difficult to read from the current thread. It would help > if you make your (motivated) position clearer and provide your arguments > for taking one of the options. Do so before June 1. i like "advance dnssec-bis as it is, and if someone wants to work on stopping enumeration, let them commit to it and let them figure out how to sell it and let them figure out whether selling it is made harder if it's not backward compatible." -- to unsubscribe send a message to namedroppers-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 May 24 07:41: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 HAA28749 for ; Mon, 24 May 2004 07:41:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSDm6-000Ehu-Fw for namedroppers-data@psg.com; Mon, 24 May 2004 11:37:46 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSDm5-000Ehe-1C for namedroppers@ops.ietf.org; Mon, 24 May 2004 11:37:45 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id AE394E7EC9; Mon, 24 May 2004 12:37:43 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-Id: <20040524113743.AE394E7EC9@mx1.nominet.org.uk> Date: Mon, 24 May 2004 12:37:43 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > When the "NO RR" was evaluated by the dnsext working group, these opposing > requirements were taken into account, and anti-enumeration lost out. I had > no dog in that race so this was only of academic interest to me -- "what > does BIND have to implement?" and "how can we get DNSSEC done in a decade?" > where my only concerns. > > If the WG made the wrong choice and if DNSSEC is unimplementable because TLD > holders fear enumeration and so SLD holders will have secure path to the > root zone, then it appears that there's really no choice except to declare > failure. Four years ago, when Simon's NO draft was considered by the WG, it appeared entirely plausible that implementation-based rate limiting mechanisms would be sufficent to offset any threat of elaboration. With the subsequent increase of the sophistication/size/duration/untraceablity/scope of such of distributed abuse -- especially including zombie networks "for hire" -- we believe this is no longer the case, and that protocol-level modifictions again have to be considered by the WG as a possible "palliative" strategy. The old anwer isn't the new answer, but I don't believe this the same as declaring failure . . . 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: From owner-namedroppers@ops.ietf.org Mon May 24 08:14:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01024 for ; Mon, 24 May 2004 08:14:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSEJS-000Lcs-3M for namedroppers-data@psg.com; Mon, 24 May 2004 12:12:14 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSEJO-000LcR-R1 for namedroppers@ops.ietf.org; Mon, 24 May 2004 12:12:11 +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 i4OCC6n1074958 for ; Mon, 24 May 2004 14:12:07 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4OCC3L0000742 for ; Mon, 24 May 2004 14:12:03 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4OCC2Aq000739 for ; Mon, 24 May 2004 14:12:03 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 24 May 2004 14:12:02 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: nsec2 large label pain Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'd like to address an issue due to large labels in NSEC2. SHA1 output is 160 bits. Represented in hexadecimal thats 40 bytes for the owner name and the next domain name as well. The signature of the NSEC2 has the same owner name. Thats 120 Bytes extra per NSEC2 compared to nsec (minus 3 times the original label length). This has negative implications for packet-size, zone-size and truncation. I'd like to see that reflected in the draft. 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 May 24 08:54: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 IAA02881 for ; Mon, 24 May 2004 08:54:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSEuQ-0001qX-2Q for namedroppers-data@psg.com; Mon, 24 May 2004 12:50:26 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSEuM-0001pP-Oh for namedroppers@ops.ietf.org; Mon, 24 May 2004 12:50:22 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 18A48E7E9E; Mon, 24 May 2004 13:50:22 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-Id: <20040524125022.18A48E7E9E@mx1.nominet.org.uk> Date: Mon, 24 May 2004 13:50:22 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk FWIW I don't believe we've made clear the following point: Nominet is prepared to commit our own resources to develop patch code to implement draft-laurie-dnsext-nsec2 for, at a minimum, BIND 9.3, NSD 2.x and Net::DNS::SEC. The intent is to facilitate the evaluation of the efficaciousness, environmental impact and interoperability of the use of NSEC2 RRs. We expect to make these patches available under the same licenses as the corresponding source distributions, and to continue to maintain and distribute the patches until either the draft expires "with finality", or, perhaps, the patches or protocol become integrated into the distributions themselves. It's never been Nominet's intention to simply toss I-Ds over the fence as a cynical exercise in FUD propagation, especially while the core DNSSECbis docs are in WGLC. Hope this helps . . . 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: From owner-namedroppers@ops.ietf.org Mon May 24 09:08: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 JAA03589 for ; Mon, 24 May 2004 09:08:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSF98-0005eV-4E for namedroppers-data@psg.com; Mon, 24 May 2004 13:05:38 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSF8z-0005b2-SY for namedroppers@ops.ietf.org; Mon, 24 May 2004 13:05:30 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BSF8y-0007Qw-00 for ; Mon, 24 May 2004 15:05:28 +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, 24 May 2004 15:05:28 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 May 2004 15:05:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 15:05:26 +0200 Lines: 18 Message-ID: References: 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:xGc6aDYfZ6jSqeXgQGVeAZ+zyfE= 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 roy@dnss.ec writes: > I'd like to address an issue due to large labels in NSEC2. > > SHA1 output is 160 bits. Represented in hexadecimal thats 40 bytes for the > owner name and the next domain name as well. The signature of the NSEC2 > has the same owner name. Thats 120 Bytes extra per NSEC2 compared to nsec > (minus 3 times the original label length). This has negative implications > for packet-size, zone-size and truncation. I'd like to see that reflected > in the draft. Can't you use standard DNS name compression techniques on the SIG owner name? If so, it is more like 80 bytes, minus the original label length, extra. If this size increase is a major obstacle for people, it may be possible to explore hash truncation. Regards, 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 May 24 09:27: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 JAA04924 for ; Mon, 24 May 2004 09:27:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSFRC-000AG1-Qm for namedroppers-data@psg.com; Mon, 24 May 2004 13:24:18 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSFR0-000AD9-AX for namedroppers@ops.ietf.org; Mon, 24 May 2004 13:24:06 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSFQz-0006Go-B8; Mon, 24 May 2004 15:24:05 +0200 In-Reply-To: To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Mon, 24 May 2004 15:23:58 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 24.05.2004 15:24:05, Serialize complete at 24.05.2004 15:24:05 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 > length, extra. If this size increase is a major obstacle for people, > it may be possible to explore hash truncation. Rather to explore an alternative representation to hexadecimal? 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: From owner-namedroppers@ops.ietf.org Mon May 24 10:14: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 KAA08482 for ; Mon, 24 May 2004 10:14:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSG9y-000KBi-4w for namedroppers-data@psg.com; Mon, 24 May 2004 14:10:34 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSG9g-000K6l-MP for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:10:16 +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 i4OE9gql001439; Mon, 24 May 2004 16:09:46 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4OE9e96004202; Mon, 24 May 2004 16:09:40 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4OE9aIB004199; Mon, 24 May 2004 16:09:40 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 24 May 2004 16:09:36 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Simon Josefsson cc: namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new 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,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 24 May 2004, Simon Josefsson wrote: > roy@dnss.ec writes: > > > I'd like to address an issue due to large labels in NSEC2. > > > > SHA1 output is 160 bits. Represented in hexadecimal thats 40 bytes for the > > owner name and the next domain name as well. The signature of the NSEC2 > > has the same owner name. Thats 120 Bytes extra per NSEC2 compared to nsec > > (minus 3 times the original label length). This has negative implications > > for packet-size, zone-size and truncation. I'd like to see that reflected > > in the draft. > > Can't you use standard DNS name compression techniques on the SIG > owner name? Absolutely. You can. > If so, it is more like 80 bytes, minus the original label > length, extra. plus the compression-pointer. > If this size increase is a major obstacle for people, > it may be possible to explore hash truncation. There are several ways to 'fix this', including a new label type (type HASH or something evil) if you like. There are other obstacles as well. Current label length restricts the message digest size (if represented in hex) to 248 bits. This excludes functions like sha-256/384/512. 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 May 24 10:17: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 KAA08961 for ; Mon, 24 May 2004 10:17:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGFa-000LWX-7z for namedroppers-data@psg.com; Mon, 24 May 2004 14:16:22 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGFV-000LVr-8x for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:16:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0619B13E10 for ; Mon, 24 May 2004 14:16:17 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Mon, 24 May 2004 12:37:43 +0100." <20040524113743.AE394E7EC9@mx1.nominet.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 24 May 2004 14:16:17 +0000 Message-Id: <20040524141617.0619B13E10@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 > Four years ago, when Simon's NO draft was considered by the WG, it > appeared entirely plausible that implementation-based rate limiting > mechanisms would be sufficent to offset any threat of elaboration. wow. that was the wrong view, both on the facts and on principle. > ... we believe this is no longer the case, and that protocol-level > modifictions again have to be considered by the WG as a possible > "palliative" strategy. > > The old anwer isn't the new answer, but I don't believe this the same > as declaring failure . . . you're using different words than declaring failure, but if adopted, this position would have the same result as declaring failure. nothing we can do in dns will ever prevent useful enumerations by bad people who will use the data to index your whois and spam your customers. -- to unsubscribe send a message to namedroppers-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 May 24 10:31: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 KAA10168 for ; Mon, 24 May 2004 10:31:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGSC-000OSJ-CO for namedroppers-data@psg.com; Mon, 24 May 2004 14:29:24 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGS6-000OQz-CM for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:29:18 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSGS5-0000x6-1p; Mon, 24 May 2004 16:29:17 +0200 In-Reply-To: To: roy@dnss.ec Cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Mon, 24 May 2004 16:28:48 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 24.05.2004 16:29:16, Serialize complete at 24.05.2004 16:29:16 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 > There are other obstacles as well. Current label length restricts the > message digest size (if represented in hex) to 248 bits. This excludes > functions like sha-256/384/512. If we forget hex (with a byte-utilization rate of 50%) and do kind of base64 (75%), then sha-256 can still be used. 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: From owner-namedroppers@ops.ietf.org Mon May 24 10:36: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 KAA10581 for ; Mon, 24 May 2004 10:36:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGWd-000PZC-BV for namedroppers-data@psg.com; Mon, 24 May 2004 14:33:59 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGWV-000PVa-BM for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:33:51 +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 i4OEXoM8013915 for ; Mon, 24 May 2004 16:33:50 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4OEXoq19353 for ; Mon, 24 May 2004 16:33:50 +0200 (MEST) Message-Id: <200405241433.i4OEXoq19353@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: nsec2 large label pain In-reply-to: Your message of "Mon, 24 May 2004 16:09:36 +0200." 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: <19349.1085409229.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 24 May 2004 16:33:49 +0200 From: Peter Koch 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 roy@dnss.ec wrote: > There are several ways to 'fix this', including a new label type (type > HASH or something evil) if you like. this rings the complexity bell, but see below[*]. > There are other obstacles as well. Current label length restricts the > message digest size (if represented in hex) to 248 bits. This excludes 252? > functions like sha-256/384/512. First of all, is it really necessary to have so "wide" fingerprints or isn't the goal better achieved otherwise? Even with a more efficient encoding (now's time again for the 8 bit debate ...) you'd end up with no more than 504 bits in a label. Practical considerations might lead to a 5/8 encoding, using e.g. A-Z0-5, large enough for 256 bit. But then, why should the hash be restricted to one label only, other than that longer hashes restrict the overall available length of the zone name? [*] The "new" label type could be bitstring (RFC 2673) or something similar. This would solve one anomaly of the current proposal: owner names of NSEC2 RRs are names that exist in the zone, but their non-existence is proven by those NSEC2 RRS, too (not necessarily by the one they own, but by others). If bitstring labels were used this would open up a "shadow namespace", so hash owners wouldn't conflict with what they're trying to prove. For similar reasons the NO draft moved the hashes to a subdomain, IIRC. -Peter PS: The draft doesn't yet specify exactly how the hash is calculated and how to apply the seed. I'd guess that the seed - if any - needs to be used twice, like in HMAC. -- to unsubscribe send a message to namedroppers-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 May 24 10:37: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 KAA10614 for ; Mon, 24 May 2004 10:37:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGXo-000PyM-05 for namedroppers-data@psg.com; Mon, 24 May 2004 14:35:12 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGXi-000Pwe-Go for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:35:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 53D8F13E48 for ; Mon, 24 May 2004 14:35:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: ruminations on late-game design changes X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 24 May 2004 14:35:06 +0000 Message-Id: <20040524143506.53D8F13E48@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 it is widely agreed that ipv6 fails to resolve some of ipv4's longstanding problems, such as the tension between the size of the routing table and the size of a globally routeable address block, or address portability, or address mobility, or automatic renumbering. tony li once complained about the speed of the ipv6 design cycle by saying that the delta between ipv4 and ipv6 was "too little, too soon." work continues to try to improve the things that can be improved without new flag days -- but the point is, the protocol design was frozen some years ago and some things were left out. and so, in the 11th hour, when someone made a reasonable-sounding request which was to change the ipv6 packet header format to put destination address first, thus improving by 8 octet-times the earliest moment when a packet level forwarding device could do cut-through routing/switching -- by starting its CAM lookup earlier or whatever -- someone in the ipv6 working group had what i'll call "the wisdom" to say, eternal microoptimization is a bad idea and even if this particular idea is good, it would be part of something larger than itself that would be bad, so, let's not do it. i'd like to restate that case, but this time, against eternal redesign. to be sure, making enumeration more difficult isn't a microoptimization, it's a redesign. but the eternal redesign that has characterized the last ten years of dnssec's "redesign cycle" is clearly no better a thing than eternal microoptimization would have been. once when praising the designers of Modula-3, niklaus wirth wrote that the most difficult thing about programming language design was knowing what to leave out. i think this reasoning may apply to network protocol design also. -- to unsubscribe send a message to namedroppers-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 May 24 10:40: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 KAA10841 for ; Mon, 24 May 2004 10:40:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGbT-0000bC-Il for namedroppers-data@psg.com; Mon, 24 May 2004 14:38:59 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGbE-0000YX-Lm for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:38:44 +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 i4OEcCSG019239; Mon, 24 May 2004 16:38:12 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4OEc9AU004806; Mon, 24 May 2004 16:38:09 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4OEc9HS004803; Mon, 24 May 2004 16:38:09 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 24 May 2004 16:38:09 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Marcos Sanz/Denic cc: roy@dnss.ec, Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new 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,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 24 May 2004, Marcos Sanz/Denic wrote: > > There are other obstacles as well. Current label length restricts the > > message digest size (if represented in hex) to 248 bits. This excludes > > functions like sha-256/384/512. > > If we forget hex (with a byte-utilization rate of 50%) and do kind of > base64 (75%), then sha-256 can still be used. Base64 encoding is not possible for a label due to canonicalizing. The best one can do is base32 encoding (62.5%). 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 May 24 10:41: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 KAA10902 for ; Mon, 24 May 2004 10:41:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGc3-0000m7-DA for namedroppers-data@psg.com; Mon, 24 May 2004 14:39:35 +0000 Received: from [192.215.81.76] (helo=relay3.san1.attens.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGbl-0000hL-Nw for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:39:21 +0000 Received: from tiger.ben.algroup.co.uk (1010ahost183.starwoodbroadband.com [12.149.158.183]) by relay3.san1.attens.com (8.11.6/8.9.3) with ESMTP id i4OEd9h11728 for ; Mon, 24 May 2004 14:39:10 GMT Received: from algroup.co.uk (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i4OFJ6WK035509; Mon, 24 May 2004 16:19:10 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <40B2126A.7020306@algroup.co.uk> Date: Mon, 24 May 2004 16:19:06 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: Simon Josefsson CC: Mark Andrews , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: relevent? References: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> In-Reply-To: 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 Simon Josefsson wrote: > Mark Andrews writes: > > >> You need to know what names exist to determine which wildcard >> to use. NSEC provides this information in the owner and next >> names (yes both of these are required not just the next name). >> >> For NO/NSEC2 the information required to determine this has >> to be explicitly provided. >> >> The actual set of proofs reqired are >> >> !f.com + !*.com >> or >> !e.f.com + !*.f.com + %f.com >> or >> !d.e.f.com + !*.e.f.com + %e.f.com >> or >> !c.d.e.f.com + !*.d.e.f.com + %d.e.f.com >> or >> !b.c.d.e.f.com + !*.c.d.e.f.com + %c.d.e.f.com >> or >> !a.b.c.d.e.f.com + !*.b.c.d.e.f.com + %b.c.d.e.f.com >> >> ! == not exist >> % == exist > > > And how is it impossible for NO/NSEC2 to support this? How I see it > is that the verifier would compute a hash of all the following > strings: > > a.b.c.d.e.f.com > *.b.c.d.e.f.com > *.c.d.e.f.com > *.d.e.f.com > *.e.f.com > *.f.com > > The hashes for the positive proofs are also needed, i.e.: > > f.com > e.f.com > d.e.f.com > c.d.e.f.com > b.c.d.e.f.com > > Using those hash values, together with the returned records, the > client can discover which of your clauses hold (if any). For example, > let's say we have the following (abbreviated hash values to simplify > reading, imagine they are full length SHA-1 hashes): > > H(a.b.c.d.e.f.com) = 181 > H(*.b.c.d.e.f.com) = 38383 > H(*.c.d.e.f.com) = 3292 > H(*.d.e.f.com) = 4959 > H(*.e.f.com) = 606 > H(*.f.com) = 1194 > > H(f.com) = 5271 > H(e.f.com) = 14 > H(d.e.f.com) = 596 > H(c.d.e.f.com) = 94984 > H(b.c.d.e.f.com) = 903 > > Now let's assume the query is a.b.c.d.e.f.com and the returned NO > records are: > > $ORIGIN _no.f.com > 150 IN NO A 200 ;; the main proof that a.b.c.d.e.f.com (181) does not exist > ;; Additional proofs: > 550 IN NO A 650 ;; proves d.e.f.com (596) does not exist > 550 IN NO A 650 ;; proves *.e.f.com (606) does not exist (by chance, same record) > 14 IN NO A 50 ;; proves e.f.com (14) exists > > The verifier is able to discover that one out of all relevant wildcard > situations apply, in this case the third of your clause. To do this > it simply iterates over all possible candidates (a small number). The > client can now trust that a specific a.b.c.d.e.f.com do not exist, and > that e.f.com do exists but there is no d.e.f.com nor *.e.f.com. So it > is able to authenticate denial of existence for ab.c.d.e.f.com. > > If I'm going to understand why NO/NSEC2 doesn't work, please give more > details. NSEC2 does work (at least in this respect), but NO didn't. The difference is the EXISTS record, and the problem it solves is that (despite terminology) the closest encloser may not actually exist (that is, there may not be an RR with that exact name, just one with a longer name - or, to put it another way, the closest encloser can be an empty non-terminal). We could demonstrate this, I guess, with hashes rather than EXISTS records by not _actually_ having an EXISTS record, just claiming it in the RR types field of NSEC2 - or even claiming no RR types at all. However, whilst this might be neater, it does nothing to hide the closest encloser (clearly, since a resolver needs to know exactly what it is), so its just another way of expressing the same thing. It also makes the logic for NSEC2 rather different from NSEC and, since it seems clear that the future is not likely to replace NSEC with NSEC2, but rather to offer them as alternatives, this would seem (to me) to be an unnecessary burden on implementers. I suppose it is also worth saying that it wouldn't reduce the size of the zone, either, since you'd be swapping an EXISTS record for an NSEC2 record. 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: From owner-namedroppers@ops.ietf.org Mon May 24 10:46: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 KAA11098 for ; Mon, 24 May 2004 10:46:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGgC-0001aO-ER for namedroppers-data@psg.com; Mon, 24 May 2004 14:43:52 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGg4-0001YJ-Lv for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:43:44 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSGg3-0002x5-NP; Mon, 24 May 2004 16:43:43 +0200 In-Reply-To: To: roy@dnss.ec Cc: Simon Josefsson , namedroppers@ops.ietf.org, roy@dnss.ec Subject: Re: nsec2 large label pain MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Mon, 24 May 2004 16:43:40 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 24.05.2004 16:43:43, Serialize complete at 24.05.2004 16:43:43 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 > Base64 encoding is not possible for a label due to canonicalizing. The > best one can do is base32 encoding (62.5%). SHA-256 still works, though. Do we need something bigger? 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: From owner-namedroppers@ops.ietf.org Mon May 24 10:52: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 KAA11421 for ; Mon, 24 May 2004 10:52:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGlX-0002l8-2a for namedroppers-data@psg.com; Mon, 24 May 2004 14:49:23 +0000 Received: from [192.215.81.74] (helo=relay1.san2.attens.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGlO-0002jh-3z for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:49:14 +0000 Received: from tiger.ben.algroup.co.uk (1010ahost183.starwoodbroadband.com [12.149.158.183]) by relay1.san2.attens.com (8.11.6/8.9.3) with ESMTP id i4OEnD322907 for ; Mon, 24 May 2004 14:49:13 GMT Received: from algroup.co.uk (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i4OFhlWK035567; Mon, 24 May 2004 16:43:54 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <40B21833.9080100@algroup.co.uk> Date: Mon, 24 May 2004 16:43:47 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: roy@dnss.ec CC: namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain References: In-Reply-To: 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@dnss.ec wrote: > I'd like to address an issue due to large labels in NSEC2. > > SHA1 output is 160 bits. Represented in hexadecimal thats 40 bytes for the > owner name and the next domain name as well. The signature of the NSEC2 > has the same owner name. Thats 120 Bytes extra per NSEC2 compared to nsec > (minus 3 times the original label length). This has negative implications > for packet-size, zone-size and truncation. I'd like to see that reflected > in the draft. I did put a note about it. Do you have a particular suggestion for what we should say where? Or shall I invent some words myself? Can we do base 64 to reduce size? I realise this (theoretically at least) introduces character set issues. If we respect those, can we do base 37 - this reduces 160 bits to 31 bytes (i.e. an overhead of 93 bytes minus three times the original label length)? Is that worth the ugliness? Incidentally, someone said yesterday that the average label length in some TLD (.com?) was 15 characters, IIRC, so this would give an average overhead of 48 bytes. Given that DNSSEC (according to Olaf) introduces a 350 byte overhead already, that doesn't sound _too_ bad to me. 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: From owner-namedroppers@ops.ietf.org Mon May 24 10:57: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 KAA11755 for ; Mon, 24 May 2004 10:57:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSGql-00047l-OJ for namedroppers-data@psg.com; Mon, 24 May 2004 14:54:47 +0000 Received: from [81.26.226.10] (helo=mail.gbg.bostream.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSGqc-00044a-7A for namedroppers@ops.ietf.org; Mon, 24 May 2004 14:54:38 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) by mail.gbg.bostream.net (8.12.11/8.12.10) with ESMTP id i4OEsUMO023269; Mon, 24 May 2004 16:54:31 +0200 To: Marcos Sanz/Denic Cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain References: From: Simon Josefsson X-Hashcash: 0:040524:sanz@denic.de:03bf08d6a3386b52 X-Hashcash: 0:040524:roy@dnss.ec:21467bc3f0c07e45 X-Hashcash: 0:040524:namedroppers@ops.ietf.org:0d74f901c6e25451 Date: Mon, 24 May 2004 16:54:30 +0200 In-Reply-To: (Marcos Sanz's message of "Mon, 24 May 2004 16:43:40 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) 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 Marcos Sanz/Denic writes: > SHA-256 still works, though. Do we need something bigger? Considering that the strongest signature algorithm specified uses SHA-1 today, I suspect it is not an immediate concern, at least. Also, I don't know whether the attacks that are enabled if you even truncate the hash values are serious. That is, answer this question: if you truncate the hash to, say, 64 bits, what can an attacker do? Truncate to 32 bits? It seems non-obvious that this can be abused in any useful way, but I may be missing something. Regards, 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 May 24 11:10: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 LAA12827 for ; Mon, 24 May 2004 11:10:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSH31-00074w-6a for namedroppers-data@psg.com; Mon, 24 May 2004 15:07:27 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSH2k-000710-Mb for namedroppers@ops.ietf.org; Mon, 24 May 2004 15:07:10 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSH2j-00064Z-NJ; Mon, 24 May 2004 17:07:09 +0200 In-Reply-To: To: Simon Josefsson Cc: namedroppers@ops.ietf.org, roy@dnss.ec Subject: Re: nsec2 large label pain MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Mon, 24 May 2004 17:07:07 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 24.05.2004 17:07:09, Serialize complete at 24.05.2004 17:07:09 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 Simon, > Also, I don't know whether the attacks that are enabled if you even > truncate the hash values are serious. The security properties of hashes are known to me. I am sorry to say I cannot make the same statement about *truncated* hashes. Before taking such a step I would like to see some competent crypto-advisor giving his "urbi et orbi".. 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: From owner-namedroppers@ops.ietf.org Mon May 24 11:14: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 LAA13051 for ; Mon, 24 May 2004 11:14:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSH7U-00089w-Gq for namedroppers-data@psg.com; Mon, 24 May 2004 15:12:04 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSH7C-00086T-M0 for namedroppers@ops.ietf.org; Mon, 24 May 2004 15:11: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 i4OFBQrd027572; Mon, 24 May 2004 16:11:29 +0100 (BST) To: Marcos Sanz/Denic cc: roy@dnss.ec, Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain In-Reply-To: Message from Marcos Sanz/Denic of "Mon, 24 May 2004 16:43:40 +0200." Date: Mon, 24 May 2004 16:11:26 +0100 Message-ID: <27571.1085411486@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic writes: >> Base64 encoding is not possible for a label due to >> canonicalizing. The best one can do is base32 encoding (62.5%). Marcos> SHA-256 still works, though. Do we need something bigger? Yes. Perhaps not today, but one day we might. It would be prudent to plan for that now. Or else we'll have a flag day at some point in the future when a longer hash string becomes essential. Remember it wasn't long ago that MD5 was the flavour-of-the-month hash function. Who's to say if SHA-N won't suffer the same fate in a couple of years? -- to unsubscribe send a message to namedroppers-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 May 24 11:27: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 LAA13806 for ; Mon, 24 May 2004 11:27:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSHKV-000BLR-Tb for namedroppers-data@psg.com; Mon, 24 May 2004 15:25:31 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSHKQ-000BKk-Gw for namedroppers@ops.ietf.org; Mon, 24 May 2004 15:25:26 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSHKP-0001AY-LJ; Mon, 24 May 2004 17:25:25 +0200 In-Reply-To: <27571.1085411486@gromit.rfc1035.com> To: Jim Reid Cc: namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Mon, 24 May 2004 17:25:23 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 24.05.2004 17:25:25, Serialize complete at 24.05.2004 17:25:25 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 Jim, > future when a longer hash string becomes essential. Remember it wasn't > long ago that MD5 was the flavour-of-the-month hash function. Who's to > say if SHA-N won't suffer the same fate in a couple of years? In the worst case, SHA would be flawed and its output size would play no role... NSEC2 already offers provisioning for alternative hash types. 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: From owner-namedroppers@ops.ietf.org Mon May 24 12:07: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 MAA16926 for ; Mon, 24 May 2004 12:07:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSHwE-000JXL-Kn for namedroppers-data@psg.com; Mon, 24 May 2004 16:04:30 +0000 Received: from [192.215.81.76] (helo=relay3.san1.attens.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSHw7-000JVy-DN for namedroppers@ops.ietf.org; Mon, 24 May 2004 16:04:23 +0000 Received: from tiger.ben.algroup.co.uk (1010ahost183.starwoodbroadband.com [12.149.158.183]) by relay3.san1.attens.com (8.11.6/8.9.3) with ESMTP id i4OG4Mh15868 for ; Mon, 24 May 2004 16:04:22 GMT Received: from algroup.co.uk (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i4OGx7WK035712; Mon, 24 May 2004 17:59:13 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <40B229DB.9000300@algroup.co.uk> Date: Mon, 24 May 2004 17:59:07 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: Peter Koch CC: namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain References: <200405241433.i4OEXoq19353@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200405241433.i4OEXoq19353@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.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 Peter Koch wrote: > PS: The draft doesn't yet specify exactly how the hash is calculated and > how to apply the seed. I'd guess that the seed - if any - needs to be > used twice, like in HMAC. Indeed the draft does need to nail down the exact calculation - I was intending to do that in the next iteration. HMAC uses the seed twice to avoid extension attacks, which are not relevant to the problem in hand. I'd suggest not using HMACs simply on the grounds that its another thing for implementers to worry about (and there is an overhead in terms of memory consumption for HMAC calculation), but I don't feel all that strongly about it. That said, I was planning to use the salt in each iteration of the hash. What I had in mind was this: Let H(x) be the hash of x and || denote concatenation. Define: H_0(salt,x)=H(x || salt) H_k(salt,x)=H(H_{k-1}(salt,x) || salt) Then the calculated hash is H_{iterations}(salt,name). BTW, I append the salt for technical correctness (it prevents precalculation when the salt is at least as long as the hash function block size). 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: From owner-namedroppers@ops.ietf.org Mon May 24 12:28: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 MAA18092 for ; Mon, 24 May 2004 12:28:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSIG9-000Nkq-K6 for namedroppers-data@psg.com; Mon, 24 May 2004 16:25:05 +0000 Received: from [192.215.81.74] (helo=relay1.san2.attens.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSIG4-000Nj9-Kr for namedroppers@ops.ietf.org; Mon, 24 May 2004 16:25:00 +0000 Received: from tiger.ben.algroup.co.uk (1010ahost183.starwoodbroadband.com [12.149.158.183]) by relay1.san2.attens.com (8.11.6/8.9.3) with ESMTP id i4OGP0306012 for ; Mon, 24 May 2004 16:25:00 GMT Received: from algroup.co.uk (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i4OHEeWK035751; Mon, 24 May 2004 18:14:40 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <40B22D80.9080308@algroup.co.uk> Date: Mon, 24 May 2004 18:14:40 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: Marcos Sanz/Denic CC: Simon Josefsson , namedroppers@ops.ietf.org, roy@dnss.ec Subject: Re: nsec2 large label pain References: In-Reply-To: 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 Marcos Sanz/Denic wrote: > Simon, > > >>Also, I don't know whether the attacks that are enabled if you even >>truncate the hash values are serious. > > > The security properties of hashes are known to me. I am sorry to say I > cannot make the same statement about *truncated* hashes. > > Before taking such a step I would like to see some competent > crypto-advisor giving his "urbi et orbi".. Although some crypto advisors want to get wobbly about truncated hashes, this one says that if they didn't work well, they'd constitute an attack on the untruncated hash. My concern about truncation would be more mundane: reduced utility for the purpose in hand, since collisions would prevent proving nonexistence. That said, we could add to our risk by including a bitlength as another option in NSECINFO (or NSEC2 if we move options there). 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: From owner-namedroppers@ops.ietf.org Mon May 24 12:33: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 MAA18327 for ; Mon, 24 May 2004 12:33:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSILv-000PFi-3M for namedroppers-data@psg.com; Mon, 24 May 2004 16:31:03 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSILW-000PAd-2r for namedroppers@ops.ietf.org; Mon, 24 May 2004 16:30:38 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4OGUXw6014525; Mon, 24 May 2004 09:30:33 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 09:30:32 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: Scope of discussion (was Re: Proposal to fix NSEC) Date: Mon, 24 May 2004 09:30:27 -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 > that's not realistic. if dnssec-bis takes off and creates an > installed base, > then there will be no incompatible changes to it between > PS/DS/FS, and those > stages will just be used to refine the documents based on > implementation and > deployment experience. What is the killer app that would cause it to take off? > if dnssec-bis fails to take off for > ANY reason, then > getting more funding or development, or being taken seriously > when saying "we > really think we've got it right this time," has a likelihood > approaching zero. That is defeatist thinking. I think that DNSSEC needs a killer-app. I don't think that protecting the DNS infrastructure itself is likely to serve until there is a massive DNS attack that changes the way the infrastructure is viewed. But a killer app need not be the intended purpose of even the main purpose after the system is deployed. The Internet killer app was the Web, not email. The Web allowed the Internet to expand rapidly outside academia, but today email is the app that is most valuable for most people. The killer app for the microcomputer was the spreadsheet - an app that hardly any PC user would rate as their most critical today. At that time you bought a PC for your secretary to do word processing on, no manager would admit doing that. I think that the most likely killer app for DNSSEC is email accreditation services for anti-spam mechanisms. Of course this could easily be served by a separate protocol. But reusing DNS means that it can pull DNS extensions and DNSSEC along in its wake. Needless to say, stopping trivial enumeration is critical for this application. -- to unsubscribe send a message to namedroppers-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 May 24 12:48: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 MAA18759 for ; Mon, 24 May 2004 12:48:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSIay-0002Ka-Hz for namedroppers-data@psg.com; Mon, 24 May 2004 16:46:36 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSIav-0002JT-Nu for namedroppers@ops.ietf.org; Mon, 24 May 2004 16:46:33 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id CA3FCE7EA5; Mon, 24 May 2004 17:46:32 +0100 (BST) To: namedroppers@ops.ietf.org, paul@vix.com Subject: Re: Proposal to fix NSEC Message-Id: <20040524164632.CA3FCE7EA5@mx1.nominet.org.uk> Date: Mon, 24 May 2004 17:46:32 +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 Paul Vixie writes: > > Four years ago, when Simon's NO draft was considered by the WG, it > > appeared entirely plausible that implementation-based rate limiting > > mechanisms would be sufficent to offset any threat of elaboration. > > wow. that was the wrong view, both on the facts and on principle. Perhaps, but, FWIW, that was the message being delivered by several participants in the DNSSEC "educational outreach" process at the time . . . 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: From owner-namedroppers@ops.ietf.org Mon May 24 13:07: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 NAA20212 for ; Mon, 24 May 2004 13:07:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSItb-0006IM-Kr for namedroppers-data@psg.com; Mon, 24 May 2004 17:05:51 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSItW-0006GO-9X for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:05:46 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i4OH5dCs019777 for ; Mon, 24 May 2004 13:05:39 -0400 Received: from lapdancer ([129.6.220.7]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i4OH4s4C022760 for ; Mon, 24 May 2004 13:05:03 -0400 (EDT) Message-ID: <009301c44198$68b010a0$7ba723c0@lapdancer> From: "Scott Rose" To: References: Subject: peaceful co-existance of NSEC and NSEC2 Date: Mon, 24 May 2004 10:07:02 -0400 Organization: NIST 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov 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 Content-Transfer-Encoding: 7bit While talking about some stuff regarding the NSEC and NSEC2. Is there a way to proceed with DNSSEC deployment with the option of having NSEC2 coming later - and have both systems co-exist? I do not know the answer now, but the first option was to use different values in the DNSKEY protocol field to indicate status of non-existance responses in the zone. 3 - uses NSEC as in DNSSECbis docset 4 - uses NSEC2 or something else 5 - etc... However, the problem here is interoperability with signalling unsigned delegations. If a NSEC-DNSSEC sec-aware resolver gets a unsigned delegation with a NSEC2 RR (proving no DS RR exists), will the resolver could exit with servfail (protocol error) instead of proceeding with knowledge that the zone is unsigned. If the resolver continues, it will see the DNSKEY RR in the zone having a protocol field of 4 (or whatever) and declare that as invalid. This could be bad since postive responses could be verified as normal, only negative response are different. This is just a possibility. There might be others, or we could drop the idea of co-existance of NSEC with NSEC2 (or some other option). Just something to keep in mind as a possibilty to allow early adopters to start using DNSSEC (those that do not believe they have to fear zone enumeration). Scott -- to unsubscribe send a message to namedroppers-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 May 24 13:08: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 NAA20401 for ; Mon, 24 May 2004 13:08:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSIuj-0006cP-3y for namedroppers-data@psg.com; Mon, 24 May 2004 17:07:01 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSIub-0006Xg-Px for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:06:53 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4OH6r0X004838; Mon, 24 May 2004 10:06:53 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 10:06:53 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: ruminations on late-game design changes Date: Mon, 24 May 2004 10:06: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 > once when praising the designers of Modula-3, niklaus wirth > wrote that the > most difficult thing about programming language design was > knowing what to > leave out. i think this reasoning may apply to network > protocol design also. Bad example. Pascal was an abject failure because it contained a major design flaw, it was impossible to implement I/O libraries as character strings of different lengths were considered incompatible types. This flaw was pointed out repeatedly during the design phase, treated to similar filibustering, rejected by the standards committee and every compiler devised a separate work arround. Most of the flaws of C that demanded correction in Java and C# were solved long before in Pascal. C++ could have corrected them if total backwards compatibility had not crippled the design. Instead we had nearly fifteen years of wasted effort in that field until Gosling worked out the right marketting strategy to get the field back on track. Tony Hoare was an advocate of simpler programming languages long before Wirth, and he also pointed out (repeatedly) that it could be overdone. -- to unsubscribe send a message to namedroppers-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 May 24 13:11: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 NAA20463 for ; Mon, 24 May 2004 13:11:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSIwm-00075y-Gh for namedroppers-data@psg.com; Mon, 24 May 2004 17:09:08 +0000 Received: from [198.32.6.68] (helo=vacation.Foo.COM) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSIwb-00073G-LH for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:08:57 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com. (8.12.8/8.12.8) with ESMTP id i4NNWMNw000673; Sun, 23 May 2004 23:32:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4NNWMJm000670; Sun, 23 May 2004 23:32:22 GMT Date: Sun, 23 May 2004 23:32:22 +0000 From: bmanning@vacation.karoshi.com To: Olaf Kolkman Cc: namedroppers@ops.ietf.org Subject: DNSSEC docset last call Message-ID: <20040523233222.GA655@vacation.karoshi.com.> References: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.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.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm in favor of shipping out the docs as currently written. This does not imply that there are areas of the spec that don't need work. There are. But what we have now is "good enough" for what is needed for those who are waiting for deployment. To paraphrase Moses, "Let my docset go". --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 13:14:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20515 for ; Mon, 24 May 2004 13:14:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJ0n-0008CL-Mu for namedroppers-data@psg.com; Mon, 24 May 2004 17:13:17 +0000 Received: from [198.32.6.68] (helo=vacation.Foo.COM) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJ0X-00073G-Ee for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:13:01 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com. (8.12.8/8.12.8) with ESMTP id i4NEujNw032235; Sun, 23 May 2004 14:56:45 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4NEujUt032232; Sun, 23 May 2004 14:56:45 GMT Date: Sun, 23 May 2004 14:56:45 +0000 From: bmanning@vacation.karoshi.com To: "Hallam-Baker, Phillip" Cc: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-ID: <20040523145645.GA32216@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.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, May 23, 2004 at 07:26:19AM -0700, Hallam-Baker, Phillip wrote: > > > ... though personally I agree with Phillip Hallam-Baker's analysis > > > that more information is revealed. > > > > If he said that, he was wrong. More likely you misunderstood > > him. The same information is revealed, it just happens slightly > > later and is an indirect activity. > > This shows why DNSEXT should transfer work on DNSSEC to the security > area. Again? The last time the security area had DNSSEC, we got stuff that could not be deployed due to excessive "chatter" btwwn parent and child. There are more good security people on the DNS lists than DNS people of any sort on the security lists. > The IETF has a reputation for designing security mechanisms that > are so completely over-designed that they are undeployable, while > failing to meet security requirements considered critical by end > users. IPSEC refused to address NAT but created a negotiation > mechanism for key negotiation. > > If you want anyone to use DNSSEC then you had better address the > requirements of the security community. Philip, why do you presume that the "security" community speaks with a single voice? > Phill --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 13:15: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 NAA20535 for ; Mon, 24 May 2004 13:15:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJ1H-0008Rl-Nw for namedroppers-data@psg.com; Mon, 24 May 2004 17:13:47 +0000 Received: from [192.215.81.77] (helo=relay4.san1.attens.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJ0h-00087p-OM for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:13:14 +0000 Received: from tiger.ben.algroup.co.uk (1010ahost183.starwoodbroadband.com [12.149.158.183]) by relay4.san1.attens.com (8.11.6/8.9.3) with ESMTP id i4OHDBW13400 for ; Mon, 24 May 2004 17:13:11 GMT Received: from algroup.co.uk (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i4OH7eWK035736; Mon, 24 May 2004 18:07:40 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <40B22BDB.3040106@algroup.co.uk> Date: Mon, 24 May 2004 18:07:39 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: Marcos Sanz/Denic CC: roy@dnss.ec, Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: nsec2 large label pain References: In-Reply-To: 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 Marcos Sanz/Denic wrote: >>Base64 encoding is not possible for a label due to canonicalizing. The >>best one can do is base32 encoding (62.5%). > > > SHA-256 still works, though. Do we need something bigger? SHA-1 means that for a 1 in 2 chance of a single collision, you need around 10^24 names. I imagine that makes it sufficient for now? I could add SHA-256 as an option. Fine by me. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 13:17: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 NAA20582 for ; Mon, 24 May 2004 13:17:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJ2p-0008u1-GP for namedroppers-data@psg.com; Mon, 24 May 2004 17:15:23 +0000 Received: from [198.32.6.68] (helo=vacation.Foo.COM) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJ2k-00073G-WD for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:15:19 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com. (8.12.8/8.12.8) with ESMTP id i4N5fBNw031685; Sun, 23 May 2004 05:41:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4N5fBhE031682; Sun, 23 May 2004 05:41:11 GMT Date: Sun, 23 May 2004 05:41:11 +0000 From: bmanning@vacation.karoshi.com To: Alex Bligh Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-ID: <20040523054111.GA31665@vacation.karoshi.com.> References: <20040522150716.E2DB613E08@sa.vix.com> <360339881.1085244837@[192.168.100.5]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <360339881.1085244837@[192.168.100.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=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > you might well be right) doesn't cut much mustard when the requirement > comes from the internet community, as communicated to those who are going > to make the deployment decision. > > Alex Hum... one might argue that the folks who have been putting up money for development and have indicated why they want certain features in DNSSEC are prepared to deploy based on the current material. If there are folks whos requirements for features differ from the currently funded activities, then they are free to back their requirements with monies to cover development and integration costs. Its not like this is the end-all for DNSSEC. One should retain the perspective that this is the -third- iteration of the spec, with associated code and attempts at deployment. There is no reason to beleive that further, iterative refinement would not be forthcoming. Lets just get this stuff out the door and then look at what should be in DNSSECv5. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 13:17: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 NAA20602 for ; Mon, 24 May 2004 13:17:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJ35-0008zz-5l for namedroppers-data@psg.com; Mon, 24 May 2004 17:15:39 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJ2r-0008uU-Ig for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:15:25 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BSJ2q-0006IE-00 for ; Mon, 24 May 2004 19:15:24 +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, 24 May 2004 19:15:24 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 May 2004 19:15:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: relevent? Date: Mon, 24 May 2004 19:15:21 +0200 Lines: 29 Message-ID: References: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> <40B2126A.7020306@algroup.co.uk> 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:LJyaoA8r30I09P01Vzc70mkN5O0= 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 Ben Laurie writes: >> The verifier is able to discover that one out of all relevant >> wildcard situations apply, in this case the third of your clause. >> To do this it simply iterates over all possible candidates (a small >> number). The client can now trust that a specific a.b.c.d.e.f.com >> do not exist, and that e.f.com do exists but there is no d.e.f.com >> nor *.e.f.com. So it is able to authenticate denial of existence >> for ab.c.d.e.f.com. If I'm going to understand why NO/NSEC2 >> doesn't work, please give more details. > > NSEC2 does work (at least in this respect), but NO didn't. The > difference is the EXISTS record, and the problem it solves is that > (despite terminology) the closest encloser may not actually exist > (that is, there may not be an RR with that exact name, just one with a > longer name - or, to put it another way, the closest encloser can be > an empty non-terminal). I'm sorry to be dense, but I don't follow how NO didn't work. What was wrong in the algorithm verifiers can follow to prove non-existence using NO records in my previous message? Don't get me wrong, I'm not trying to push a NO solution (all I have proposed is to drop one sentence in the security considerations of the current specifications), but since we're discussing it, I'd might as well try to learn something. 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 May 24 13:24: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 NAA20756 for ; Mon, 24 May 2004 13:24:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJ99-000Ak9-K8 for namedroppers-data@psg.com; Mon, 24 May 2004 17:21:55 +0000 Received: from [198.32.6.68] (helo=vacation.Foo.COM) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJ8y-000AiG-72 for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:21:44 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com. (8.12.8/8.12.8) with ESMTP id i4LJINNw021693; Fri, 21 May 2004 19:18:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4LJINAm021690; Fri, 21 May 2004 19:18:23 GMT Date: Fri, 21 May 2004 19:18:23 +0000 From: bmanning@vacation.karoshi.com To: Jaap Akkerhuis Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-ID: <20040521191823.GB21649@vacation.karoshi.com.> References: <200405211838.i4LIcnNl020253@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405211838.i4LIcnNl020253@bartok.sidn.nl> 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 this list in this context I noticed that also concernsabout the > IP-rights (Intellectual Property rights) popped up, like one had > on a telephone directory. (There the data is also meant to be public, > but on how it is organized there are IP rights). You cannot just > copy a directory because of that. For a zone file you can claim > this probably as well. That gives you a handle to whack people > making copies. We discussed this internally somewhat. We think > that IP-rights on a zone file is an interesting idea, but doesn't > prevent zone enumeration. It has more juridical aspects then > technical. the one concern here is that the process of signing the data sorts the zone into a "normal" form. this is a two-edged sword :) in the singed case, I can unambigiously prove that the zone contents were sorted and signed by me. e.g. the compilation is mine. > > Back to (EU and other) pivacy concerns. Given the fact that there > are multiple ways to do data mining for domain names in a zone as > pointed out by Paul Vixie and Robert Elz, one really must take steps > to limit access to "whois data". There are otheres that called out the ability to either "slow-scan" the replies & build up a copy of the DB over time, or "brute-force" the effort. Both take time, both are known tools (and some of us have used them!) > jaap --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 13:24: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 NAA20774 for ; Mon, 24 May 2004 13:24:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJA5-000Axr-6G for namedroppers-data@psg.com; Mon, 24 May 2004 17:22:53 +0000 Received: from [198.32.6.68] (helo=vacation.Foo.COM) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJ9y-000AiG-QS for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:22:47 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com. (8.12.8/8.12.8) with ESMTP id i4LCNaNw020911; Fri, 21 May 2004 12:23:36 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4LCNXnC020908; Fri, 21 May 2004 12:23:33 GMT Date: Fri, 21 May 2004 12:23:33 +0000 From: bmanning@vacation.karoshi.com To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: relevent? Message-ID: <20040521122333.GA20885@vacation.karoshi.com.> References: <200405202159.i4KLxPJ07088@grimsvotn.TechFak.Uni-Bielefeld.DE> <200405210039.i4L0d7tN059686@drugs.dv.isc.org> 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.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 > No, I believe sufficient information is present. To verify that any > wildcard RR doesn't cover the queried name, you compute a few SHA-1 > hashes on the only possible wildcard owner names that can be relevant, thats a bit presumptious, don't you think? how can you possibly determine relevant, possible owner names? > Regards, > Simon --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 13:31: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 NAA20889 for ; Mon, 24 May 2004 13:31:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJG3-000CcH-6X for namedroppers-data@psg.com; Mon, 24 May 2004 17:29:03 +0000 Received: from [198.32.6.68] (helo=vacation.Foo.COM) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJFz-000CIr-EJ for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:29:00 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com. (8.12.8/8.12.8) with ESMTP id i4KEKtNw017783; Thu, 20 May 2004 14:20:55 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4KEKttB017780; Thu, 20 May 2004 14:20:55 GMT Date: Thu, 20 May 2004 14:20:55 +0000 From: bmanning@vacation.karoshi.com To: Marcos Sanz/Denic Cc: Robert Elz , namedroppers@ops.ietf.org, Peter Koch Subject: Re: Proposal to fix NSEC Message-ID: <20040520142055.GA17769@vacation.karoshi.com.> References: <19443.1085009564@munnari.OZ.AU> 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.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 > Again, the compilation may not be public. That is an *actual fact* in the > case of many TLDs. Could we stop declaring this as a non-problem? We'd > have two ways to go: > a) We face it's a problem, live with it and *say so* in the actual drafts. it seems that the origin of this "problem" is a contractual obligation TLDs assume when they sign the ICANN agreement. if this is the case, then it really is a non-problem from a protocol perspective. > b) We invest our discussing energy in the NSEC2 proposal (or NO, or any > other) to fix whatever is broken. not worth the effort. > Simon just said it: fixing whois will remove whois from the examples, but > won't remove the traversal problem. traversing data that by its nature is public seems a reasonable thing to want to do. why is this a problem? > > 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: -- to unsubscribe send a message to namedroppers-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 May 24 13:41: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 NAA21109 for ; Mon, 24 May 2004 13:41:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJQA-000FNV-Om for namedroppers-data@psg.com; Mon, 24 May 2004 17:39:30 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJQ9-000FN4-7F for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:39:29 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4OHd6iE006477; Mon, 24 May 2004 10:39:06 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 10:39:06 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Marcos Sanz/Denic'" , roy@dnss.ec Cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: RE: nsec2 large label pain Date: Mon, 24 May 2004 10:39: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.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 > > There are other obstacles as well. Current label length > restricts the > > message digest size (if represented in hex) to 248 bits. > This excludes > > functions like sha-256/384/512. > > If we forget hex (with a byte-utilization rate of 50%) and do kind of > base64 (75%), then sha-256 can still be used. There are two issues, strength of algorithm and the risk of attack. It may well be better to use SHA-256 and truncate to some length than to use SHA-1. From a purely cryptographic point of view SHA-256 is a much better scheme, it is also likely to be supported better in future hardware acceleration etc. Rather than use hex I would use BASE32 encoding, several people have proposed schemes that use ten numbers and 22 characters as a case-proof symbol set. This means that you get five bits per character rather than four. So a 160 bit digest is only 32 characters. How long should the digest be? Since we are using it to mask a label that is itself bound in size we don't need very many bits at all. In fact the size of the range of the hash need only be the square of the size of the domain. I don't think it very likely that we will have individual zones with more than 2^64 different labels. So the probability of collision will be negligible if have a hash with 2^128 bits. If label size is an issue we could argue over likely domain sizes etc. 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 May 24 13:52: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 NAA21234 for ; Mon, 24 May 2004 13:52:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJZS-000Hdk-Oe for namedroppers-data@psg.com; Mon, 24 May 2004 17:49:06 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJZQ-000HdA-3k for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:49:04 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4OHmxeI029923; Mon, 24 May 2004 10:48:59 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 10:48:59 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Marcos Sanz/Denic'" , Jim Reid Cc: namedroppers@ops.ietf.org Subject: RE: nsec2 large label pain Date: Mon, 24 May 2004 10:48:58 -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 > > future when a longer hash string becomes essential. > Remember it wasn't > > long ago that MD5 was the flavour-of-the-month hash > function. Who's to > > say if SHA-N won't suffer the same fate in a couple of years? > > In the worst case, SHA would be flawed and its output size > would play no > role... > NSEC2 already offers provisioning for alternative hash types. From a pure algorithm perspective the concern here is that MD4 is broken, MD5 is deeply compromised and both MD5 and SHA-1 are both incremental advances on MD4. I have no reason to doubt the security of SHA-1 at this time, but we are past the point where it is appropriate to use it in a NEW specification environment. The whole point of AES was to address these issues industry wide. The length of the algorithm output is not an issue, both SHA-1 and SHA-256 provide more than sufficient bits. We should probably truncate in either case. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 13:55: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 NAA21266 for ; Mon, 24 May 2004 13:55:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSJcl-000Idj-SX for namedroppers-data@psg.com; Mon, 24 May 2004 17:52:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSJck-000Id9-3u for namedroppers@ops.ietf.org; Mon, 24 May 2004 17:52:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4471713E4F for ; Mon, 24 May 2004 17:52:29 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: relevent? In-Reply-To: Message from Simon Josefsson of "Mon, 24 May 2004 19:15:21 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 24 May 2004 17:52:29 +0000 Message-Id: <20040524175229.4471713E4F@sa.vix.com> 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,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm sorry to be dense, but I don't follow how NO didn't work. ... > Don't get me wrong, I'm not trying to push a NO solution ... and yet, you must. perhaps that's the component i'm seeing that others here are not. if we're going to reopen the dnssec design, then we have to re-evaluate NO, opt-in, as well as NSEC2, and anything else lurking in the shadows. anything we don't evaluate fully enough, will clearly just become an 11th hour showstopped 18 months from now when we next feel ready to start deployment. therefore, if this WG decides to adopt NSEC2, we have to broaden the net to include competing proposals, some of whom were shot down just because of the lateness of the hour rather than for functional reasons. -- to unsubscribe send a message to namedroppers-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 May 24 14:33: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 OAA22362 for ; Mon, 24 May 2004 14:33:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSKCj-0002Nd-5u for namedroppers-data@psg.com; Mon, 24 May 2004 18:29:41 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSKCf-0002Mu-Nt for namedroppers@ops.ietf.org; Mon, 24 May 2004 18:29:37 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i4OITT19029260; Mon, 24 May 2004 11:29:29 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 24 May 2004 11:29:29 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: relevent? Date: Mon, 24 May 2004 11:29:29 -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.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul, This is not what is being asked for. I don't think anyone wants to delay DNSSEC bis. I certainly do not want to do 11th hour design. You are completely right about opening cans of worms. I don't want to end up with yet another half-baked fix up that only solves half the problems. All that is needed at this stage to meet everyone's immediate needs is to change the DNSSEC docs so that a zone can say that it does not support NSEC. It would be good if it could also state what it does support. There would be a stiff Security Considerations item that says that this creates serious vulnerabilities. All that is really needed at this stage is a versioning mechanism for the NSEC record. I do not think that any reasonable person could state that there is a consensus here that there is absolutely no possibility that NSEC needs to be revised. That has already happened several times. Basically its just a signed return that says 'NSEC not supported, see the X,Y or Z records instead'. We all understand that there will be deployment issues and that any proposal comming out of the gate late will be at a disadvantage. This does not matter, if DNSSEC is so successfull that it does not need fixing then great! Phill > > I'm sorry to be dense, but I don't follow how NO didn't work. ... > > Don't get me wrong, I'm not trying to push a NO solution ... > > and yet, you must. perhaps that's the component i'm seeing > that others > here are not. if we're going to reopen the dnssec design, > then we have > to re-evaluate NO, opt-in, as well as NSEC2, and anything else lurking > in the shadows. anything we don't evaluate fully enough, will clearly > just become an 11th hour showstopped 18 months from now when > we next feel > ready to start deployment. therefore, if this WG decides to > adopt NSEC2, > we have to broaden the net to include competing proposals, > some of whom > were shot down just because of the lateness of the hour > rather than for > functional reasons. > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 14:42: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 OAA22708 for ; Mon, 24 May 2004 14:42:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSKND-00057G-9G for namedroppers-data@psg.com; Mon, 24 May 2004 18:40:31 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSKNA-00056T-Tr for namedroppers@ops.ietf.org; Mon, 24 May 2004 18:40:29 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 1D50F19B405; Mon, 24 May 2004 14:37:14 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 593D119B3F4 for ; Mon, 24 May 2004 14:37:13 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.35.166.53]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1684846; Mon, 24 May 2004 14:40:22 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 24 May 2004 11:40:10 -0700 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: nsec2 example Cc: edlewis@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 (Apparently there's been a thread on NSEC2 on namedroppers. I haven't read it.) I was asked to look at the NSEC2 proposal. It's hard to give a theoretical analysis of this, so I plucked one example to run against it. I picked an example that I think would present a problem. I'll list the example as well as a few thoughts. Here's the sample zone I am using: @ SOA, other stuff; @ is the name of the zone (="example.org.") *.f some stuff d.e.f some stuff z.e.f some stuff For the purposes of the example, assume every name above has AAAA records, as well as all queries, and is in class IN. I'll also make these assumptions. I'm going to assume the hash of each name is: hash (@) = 98 hash (*.f) = 17 hash (z.e.f) = 138 hash (d.e.f) = 347 So, the full zone has: @ SOA, other stuff *.f some stuff d.e.f some stuff z.e.f some stuff 17 NSEC2 98 NSEC2 138 NSEC2 347 NSEC2 (Hopefully I have this correct. Ben?) Let's look at a query for a.b.c.d.e.f(.@) AAAA, IN. Obviously, it doesn't exist and is not subject to the wild card synthesis. Graphically I see: @ | f / \ * e / \ d z . c . b . a "|,\,/" are links in the tree. "." is a non-existent link, e.g., something below any leaf of the tree. (BTW, because of this, I can't imagine that the EXIST RR is needed. The only nodes that can be closest enclosers in a negative answers have to "be there." Otherwise, I'd have fallen off the tree earlier. DNS does not have terminal non-empty nodes.) So, to prove that there is no data to return to my answer, specifically that a name error has occurred, the following has to be demonstrated: 1) a.b.c.d.e.f does not exist. (Let's call the hash of it "217") 2) b.c.d.e.f does not exist. (Let's call the hash of it "130") 3) c.d.e.f does not exist. (Let's call the hash of it "87") 4) d.e.f does exist 5) *.d.e.f does not exist. (Let's call the hash of it "112") To demonstrate this, the response to the name error has to contain the following NSEC2 RR's: 1) 138 NSEC2 (because 138 < 217 < 347) 2) 98 NSEC2 ( 98 < 130 < 138 ) 3) 17 NSEC2 ( 17 < 87 < 98 ) 4) 347 NSEC2 ( 347 = 347 ) - demonstrating that this exists 5) optimized out 98 NSEC2 ( 98 < 112 < 138 ) (At this point, I should ask - is the above example and understanding of the NSEC2 RR draft correct? If not, then the rest of this isn't worth reading at this point.) It seems that this approach does convey the needed information for this example. I suspect that if there was a wild card synthesis involved, then #5 is replaced by the results of the synthesis. My initial concern was that the client can't be sure that an inappropriate NSEC2 RR was inserted, possibly via a replay attack (of valid data). Well, it seems unlikely, because both the client and server will need to agree on "what needs provin'" and are just exchanging evidence for the proof. What is lost in hashing is the structure of the tree. Hashing is a mapping that flattens an "object". Because of the flattening (it could also be attributed to lossy compression) more information is needed to show the structure. This is manifested in the difference between needing just one or two NSEC RR's (or NXT's) and the need for extra NSEC2 RR's. An NSEC RR showing there is no name from d.e.f to z.e.f would be all that is needed to prove points 1-5. In this example, we need 4 distinct NSEC2 RR's. The upper limit of NSEC2 records is linearly proportional to the number of labels from the closest encloser to the QNAME. I am a bit worried that this is determined by the querier - I mean it is, but that it is worries me. Hypothesis: this is a potential DOS vulnerability. E.g., let's say there is no arin.net. If you ask the .net servers for a.b.c.d.e.f.g.h.arin.net, then the .net server has to perform 8 - 10 hash calculations and include about that many records in the reply. As an aside unrelated to the previous, the use of hashed names "changes the shape of the tree" involuntarily from the point of view of the administrator. I'm not sure that this is a problem, but thought it should be mentioned. In the above example, 17.@ is introduced into the zone. Granted, 17 is a lot prettier than a real 20 byte SHA-1 hash, but what happens is that wild card synthesis may be altered because of these hash names. E.g., if there was a "*.@" in the zone, then the answer to "a.17.@, IN , AAAA" is altered. The synthesis isn't applied because of the blocking (hash) name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 24 15:05: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 PAA23575 for ; Mon, 24 May 2004 15:05:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSKhJ-000ATG-Nz for namedroppers-data@psg.com; Mon, 24 May 2004 19:01:17 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSKh7-000AOZ-28 for namedroppers@ops.ietf.org; Mon, 24 May 2004 19:01:05 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BSKh6-0001eZ-00 for ; Mon, 24 May 2004 21:01:04 +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, 24 May 2004 21:01:04 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 May 2004 21:01:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: relevent? Date: Mon, 24 May 2004 21:00:58 +0200 Lines: 25 Message-ID: References: <20040524175229.4471713E4F@sa.vix.com> 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:O9ST8y9E3FWP1GHNc218N0rqMxk= 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,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: >> I'm sorry to be dense, but I don't follow how NO didn't work. ... >> Don't get me wrong, I'm not trying to push a NO solution ... > > and yet, you must. perhaps that's the component i'm seeing that others > here are not. if we're going to reopen the dnssec design, then we have > to re-evaluate NO, opt-in, as well as NSEC2, and anything else lurking > in the shadows. anything we don't evaluate fully enough, will clearly > just become an 11th hour showstopped 18 months from now when we next feel > ready to start deployment. therefore, if this WG decides to adopt NSEC2, > we have to broaden the net to include competing proposals, some of whom > were shot down just because of the lateness of the hour rather than for > functional reasons. I agree with all that. I don't mind of others wants to reconsider the NO proposal, and time permitting I can try to assist. But my only goal now has been to improve the current specifications, so they can be shipped (if that is the consensus), by dropping a misleading statement in the security consideration. Those two matters are orthogonal, and quite different in proportions. I haven't asked for a redesign, and I'm indifferent to whether one is needed. Regards, 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 May 24 17:21: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 RAA03237 for ; Mon, 24 May 2004 17:21:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSMnC-000CV3-Dl for namedroppers-data@psg.com; Mon, 24 May 2004 21:15:30 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSMnB-000CUn-EL for namedroppers@ops.ietf.org; Mon, 24 May 2004 21:15:29 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id D101619B456; Mon, 24 May 2004 17:12:12 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 4E64C19B44F for ; Mon, 24 May 2004 17:12:12 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.35.166.53]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1685380; Mon, 24 May 2004 17:15:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 24 May 2004 14:14:17 -0700 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: another nsec2 example Cc: edlewis@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=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After the previous example, I thought a bit more about the EXIST RR. Here is an example that shows the need for it (in the NSEC2 proposal). I'll use the same beginning data as the other message I sent, but with a different query. So, starting with: @ SOA, other stuff *.f some stuff d.e.f some stuff z.e.f some stuff 17 NSEC2 98 NSEC2 138 NSEC2 347 NSEC2 This time I'll query for (one.two.three.e.f.@, IN, AAAA). In this case, the closest encloser is the empty non-terminal e.f.@. (What was I thinking last time?) In this case, the following has to be determined: 1) That one.two.three.e.f does not exist 2) That two.three.e.f does not exist 3) That three.e.f does not exist 4) That e.f does exist 5) That *.e.f does not exist The only difference from the previous example is that the proof that e.f exists has to prove the existence of the empty node there. The proposal postulates that the EXIST name is needed there. Faced with that, there is another choice - why not just insert NSEC2's at all existing nodes (as shown in the tree)? We forbade empty non-terminals owning NXT's in the past just to cut down the need to represent them. This is merely a suggestive question - predicated by the potential need for EXIST RR. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 24 18:28: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 SAA13332 for ; Mon, 24 May 2004 18:28:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSNns-000OaT-OC for namedroppers-data@psg.com; Mon, 24 May 2004 22:20:16 +0000 Received: from [81.26.226.10] (helo=mail.gbg.bostream.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSNnq-000OZg-6O for namedroppers@ops.ietf.org; Mon, 24 May 2004 22:20:14 +0000 Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) by mail.gbg.bostream.net (8.12.11/8.12.10) with ESMTP id i4OLgFoG001294; Mon, 24 May 2004 23:42:16 +0200 To: Ben Laurie Cc: namedroppers@ops.ietf.org Subject: Re: relevent? References: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> <40B2126A.7020306@algroup.co.uk> <40B25D67.2090607@algroup.co.uk> From: Simon Josefsson X-Hashcash: 0:040524:ben@algroup.co.uk:9c58ee6912c84e34 X-Hashcash: 0:040524:namedroppers@ops.ietf.org:ae856e62e2efee82 Date: Mon, 24 May 2004 23:42:15 +0200 In-Reply-To: <40B25D67.2090607@algroup.co.uk> (Ben Laurie's message of "Mon, 24 May 2004 21:39:03 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) 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 Ben Laurie writes: > The problem is that if (say), in your example, e.f.com only exists by > virtue of an RR for x.e.f.com, then there will be no NO record for > e.f.com. This is why I had to invent the EXISTS record. Ah, I see. Thanks for explaining! Edward Lewis' suggestion to (in this example) populate the otherwise empty node e.f.com with a NSEC2 RR sounds like something that might be simpler. 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 May 24 20:30: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 UAA19248 for ; Mon, 24 May 2004 20:30:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSPkG-0002JQ-Ks for namedroppers-data@psg.com; Tue, 25 May 2004 00:24:40 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSPkC-0002I5-TZ for namedroppers@ops.ietf.org; Tue, 25 May 2004 00:24:37 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i4P0OZP27430 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 24 May 2004 20:24:35 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4P0OZH9018643 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 May 2004 20:24:35 -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 i4P0OYKf018640; Mon, 24 May 2004 20:24:34 -0400 To: namedroppers@ops.ietf.org cc: Olaf Kolkman Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) In-Reply-To: Message from Olaf Kolkman of "Sun, 23 May 2004 16:07:47 PDT." <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> References: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Mon, 24 May 2004 20:24:34 -0400 Message-ID: <18639.1085444674@marajade.sandelman.ottawa.on.ca> From: Michael Richardson 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Olaf" == Olaf Kolkman writes: Olaf> The question on the table is what this WG needs to do. Olaf> In my previous mail I have listed two possibilities. Taking up Olaf> work to prevent zone enumeration while holding the DNSSEC bis Olaf> document-set or shipping DNSSEC bis and forgetting about Sigh. I hate to say this... if we are going to do this, let's do it *now* I suggest that some may want to go ahead with DNSSEC deployment without NSEC. If doing so, they should not have any NSEC records at all, nor should their resolvers know what to do with them at this point. I think that the chairs should establish a firm time table for doing this work. It should take no more than 5 weeks. - -- ] "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 iQCVAwUBQLKSQIqHRg3pndX9AQHD9QP8DBO+e3QafTWeVWIyCX00oBhwpxroZqp3 AAF1dFFEko4DNWQ8d3EOsjURX13naLVC4f720pbqjjTJM6Jr+6hAb7ezBtye4fHg tOpPqTlLuiyYS+bWRVzd2HNT/qZxRcxLC92bppY03/I3cJp0yMQrQsAJ8FZmb/tt vxOPI3Ywk98= =CPN0 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 24 21:06: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 VAA20307 for ; Mon, 24 May 2004 21:06:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSQLV-000AwY-T5 for namedroppers-data@psg.com; Tue, 25 May 2004 01:03:09 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSQLU-000AwI-UG for namedroppers@ops.ietf.org; Tue, 25 May 2004 01:03:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0AF1A13E10 for ; Tue, 25 May 2004 01:03:08 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) In-Reply-To: Message from Michael Richardson of "Mon, 24 May 2004 20:24:34 -0400." <18639.1085444674@marajade.sandelman.ottawa.on.ca> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 25 May 2004 01:03:08 +0000 Message-Id: <20040525010308.0AF1A13E10@sa.vix.com> 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,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I hate to say this... if we are going to do this, let's do it *now* technically i agree with this statement. but if we were going to do this, we should never have even considered standardizing NXT (ne NSEC), and i'm concerned about vision creep... so concerned in fact that if we decide to re-debate NO/opt-in/NSEC2, i'll wonder how we'll *ever* know that DNSSEC is cooked-enough to stop tinkering with it. (until last week, i thought we knew.) > I suggest that some may want to go ahead with DNSSEC deployment > without NSEC. If doing so, they should not have any NSEC records at all, > nor should their resolvers know what to do with them at this point. this is not realistic. just as many people don't read drafts until WGLC, many implementors and operators will not invest any effort in a standard that's known to be an incomplete shadow of its future self. i'm sure, for example, that isc would have a hard time getting funding to develop code that doesn't generate or look at NSEC, since authoritative denial of existence was made a WG-level showstopper nine years ago. > I think that the chairs should establish a firm time table for doing > this work. It should take no more than 5 weeks. this is also not realistic. with dnssec, we can't call it "done" until it's been extensively reviewed, modelled, and beer&pizza-tested, and for something at the level of NSEC2 that will take six to 12 months. that's how we found "the grandparent problem" and that's how long it takes to find, or be sure you're not able to find, problems of that subtle nature. this debate is making it sound as if we don't know what dnssec is supposed to do, or who it's going to do it for, or what are the concerns of the people dnssec is supposed to do stuff for. i just don't think that's all true. but if i'm wrong, and dnssec is now a solution in search of a problem, then i'd like to question the wisdom of spending any more time on it until the problem is clearly known and explicitly agreed to by all possible stakeholders. (which in other words means, until hell freezes over.) -- to unsubscribe send a message to namedroppers-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 May 25 01:16: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 BAA01173 for ; Tue, 25 May 2004 01:16:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSUFO-000A0E-7K for namedroppers-data@psg.com; Tue, 25 May 2004 05:13:06 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSUFK-0009z6-7Q for namedroppers@ops.ietf.org; Tue, 25 May 2004 05:13:02 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i4P5Cqbc029930 for ; Tue, 25 May 2004 01:12:53 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040524180114.0652aec0@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 25 May 2004 01:12:55 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: NSEC+ and NO 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=-3.7 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY, OPT_IN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Having read the discussions on namedroppers about this topic here are my "grumpy old man" personal reactions/responses. Please take a moment to send me or the list answers to the questions at the end. 0. It is real frustrating when a bunch of late new comers suddenly say they can not deploy DNSSEC for some reason that has nothing to do with DNS, just some obsolete whois stuff and some legal mumbo jumbo that only applies to about 25 countries. 1. I was strongly in favour of exploring NO record and it's implications when Simon started that work. NO failed to catch on for a combination of reasons including: - There was no explicit need to stop zone walking. - It was MUCH more expensive than NXT, 2x names (the real one and hash name) 2x lookups in authoritative server to answer negative answer first the name then the nearest hash More expensive to sign a zone as all hash names had to generated and sorted. - Later on we discovered that NO did not work with empty non-terminals and wildcards. (more later) (NO complied with at-the-time understanding of the issues). 2. MarkK is too much of an gentleman to say this, so I will: - opt-in addresses your publicly stated issue with NSEC. only by securing a domain does become it trivial to find whois info. 3. Someone said that we can not deploy a protocol that a single TLD's is unable to support for local legal reasons. Answer: Get over it, IF you want DNSSEC security, change to a name in a different TLD and put a DNAME at the old one. 4. We have known since day ONE that root and TLD's are special and taken that into consideration, otherwise the opt-in proposal would have not been considered for this long. We have known about EU privacy issues but been told publicly it was a non issue. Thus any statements of the type: "I can not share with you privileged legal opinion" must be considered FUD. So unless the position paper (or at least relevant sections) is made public, the working group MUST ignore the issue. Also what is the implication if some EU citizen registers a domain in say .cn domain does that mean .cn has to follow EU rules? Answer: .cn sovereignty tops EU rules. 5. What in DNS makes something like NO++ difficult? 5.1 Zones with Multiple label names. 5.2 Zones with wild cards. outlaw both and the problem becomes much simpler for any NO-- proposal Moral: When there is a DNS problem do not patch it up, address the underlying issue. If Zone walking is limited to TLD's then restrict the what the zones look like to simplify life. W/O restrictions on zone depth and wildcards, the number of NO++ records server needs/should/may include in an negative answer will depend on the query. If the burden of discovering this is placed on the resolver by requiring label stripping, then time to assert validity of an answer is to great. 5.5 On-line signing of negative answers, who signs it a master server ? a authoritative server ? and with what key. In any case these servers can now be DoS'ed as the work they need to perform is much greater than the effort of the attackers. 6. Current NSEC2 proposal does not address the issue of name conflict between a valid name and a digest, NO addressed this by moving all NO records into a separate name space. There is lots of hot air about the encoding, size of, obfuscating of NSEC2 names, these are minor details lets address the first order problem: For who is zone walking a problem and why? I assert: root zone has no problem. 6.1 Are any TLD's willing to go on the record to say NSEC zone walking is a non-issue show-stopper 6.2 For leaf zones same questions ? 6.3 For enterprise zones same questions ? Unless the WG gets some hard facts presented to these questions this whole issue should be dropped. 7. Should the co-chair have asked question #4? Lets just kill DNSSEC it is to difficult and expensive. Olafur (just some bozo who has followed DNSSEC for 9.5 years) -- to unsubscribe send a message to namedroppers-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 May 25 04:16: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 EAA22915 for ; Tue, 25 May 2004 04:16:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSX4N-0006Nk-0C for namedroppers-data@psg.com; Tue, 25 May 2004 08:13:55 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSX4L-0006NM-4i for namedroppers@ops.ietf.org; Tue, 25 May 2004 08:13:53 +0000 Received: (qmail 5153 invoked from network); 25 May 2004 08:20:37 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 25 May 2004 08:20:37 -0000 Message-ID: <40B30149.2030805@necom830.hpcl.titech.ac.jp> Date: Tue, 25 May 2004 17:18:17 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO References: <6.1.0.6.2.20040524180114.0652aec0@localhost> In-Reply-To: <6.1.0.6.2.20040524180114.0652aec0@localhost> 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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur; > Answer: Get over it, IF you want DNSSEC security, change > to a name in a different TLD and put a DNAME at the old one. DNAME? I'm afraid you are merely making a external problem internal. > Olafur (just some bozo who has followed DNSSEC for 9.5 years) As a person who followed it more than 9.5y, I think it is merely that DNSSEC was a bad idea good for no real purpose. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 25 04:31: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 EAA23636 for ; Tue, 25 May 2004 04:31:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSXHN-0008dQ-Uh for namedroppers-data@psg.com; Tue, 25 May 2004 08:27:21 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSXHM-0008d9-VP for namedroppers@ops.ietf.org; Tue, 25 May 2004 08:27:21 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSXHL-00065r-9D; Tue, 25 May 2004 10:27:19 +0200 In-Reply-To: <6.1.0.6.2.20040524180114.0652aec0@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Tue, 25 May 2004 10:27:08 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 25.05.2004 10:27:19, Serialize complete at 25.05.2004 10:27:19 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 > 0. It is real frustrating when a bunch of late new comers suddenly say they > can not deploy DNSSEC for some reason that has nothing > to do with DNS, just some obsolete whois stuff and some legal mumbo > jumbo that only applies to about 25 countries. I don't know who are you labeling as a "newcomer", exactly what part of the whole is "mumbo jumbo" and whether saying "only 25 countries" isn't an oxymoron itself. Paraphrasing an authority person: please remain courteous and discuss arguments on the quality of the arguments, qualities of the author are out of scope. -- to unsubscribe send a message to namedroppers-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 May 25 04:37: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 EAA23953 for ; Tue, 25 May 2004 04:37:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSXPN-000A86-Mt for namedroppers-data@psg.com; Tue, 25 May 2004 08:35:37 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSXPM-000A7h-Fj for namedroppers@ops.ietf.org; Tue, 25 May 2004 08:35:36 +0000 Received: (qmail 5249 invoked from network); 25 May 2004 08:42:21 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 25 May 2004 08:42:21 -0000 Message-ID: <40B30661.6000708@necom830.hpcl.titech.ac.jp> Date: Tue, 25 May 2004 17:40:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: ruminations on late-game design changes References: <20040524143506.53D8F13E48@sa.vix.com> In-Reply-To: <20040524143506.53D8F13E48@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.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 Paul Vixie; > it is widely agreed that ipv6 fails to resolve some of ipv4's longstanding > problems, such as the tension between the size of the routing table and > the size of a globally routeable address block, or address portability, > or address mobility, or automatic renumbering. No. IPv6 failed because it tries to solve a lot of problems most of which are useless and impossible to solve. The only real problem was routing table size one, which was seemingly too hard to solve and ignored. Packet format is a minor issue. So is DNSSEC. In this case, real world operation is the real problem and, unlike IPv6 one, is not solvable. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 25 06:57: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 GAA01143 for ; Tue, 25 May 2004 06:57:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSZXh-000Bjy-2O for namedroppers-data@psg.com; Tue, 25 May 2004 10:52:21 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSZXf-000Bj5-NG for namedroppers@ops.ietf.org; Tue, 25 May 2004 10:52:19 +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 i4PAqDrd029486; Tue, 25 May 2004 11:52:13 +0100 (BST) To: Marcos Sanz/Denic cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from Marcos Sanz/Denic of "Tue, 25 May 2004 10:27:08 +0200." Date: Tue, 25 May 2004 11:52:13 +0100 Message-ID: <29484.1085482333@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic writes: Marcos> I don't know who are you labeling as a "newcomer", exactly Marcos> what part of the whole is "mumbo jumbo" and whether saying Marcos> "only 25 countries" isn't an oxymoron itself. Olafur's reference to "legal mumbo jumbo" is well made IMO. The lawyers for Nominet and SIDN appear to be giving conflicting advice about the imapct of an EU directive on NSEC. We're not lawyers, let alone lawyers who understand this field. So unless the legal issues can be explained to namedroppers by an expert, what we have is to all intents and purposes legal mumbo-jumbo. -- to unsubscribe send a message to namedroppers-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 May 25 12:12: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 MAA23455 for ; Tue, 25 May 2004 12:12:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSeQR-000Nc8-Eg for namedroppers-data@psg.com; Tue, 25 May 2004 16:05:11 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSeQ7-000NUk-4J for namedroppers@ops.ietf.org; Tue, 25 May 2004 16:04:51 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A548C19B36C; Tue, 25 May 2004 12:01:20 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 31A8719B341; Tue, 25 May 2004 12:01:20 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.35.166.53]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1688545; Tue, 25 May 2004 12:04:49 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <6.1.0.6.2.20040524180114.0652aec0@localhost> References: <6.1.0.6.2.20040524180114.0652aec0@localhost> Date: Tue, 25 May 2004 09:04:51 -0700 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= From: Edward Lewis Subject: Re: NSEC+ and NO Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY, OPT_IN autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 1:12 -0400 5/25/04, =D3lafur Gu=F0mundsson wrote: >0. It is real frustrating when a bunch of late new comers suddenly say they > can not deploy DNSSEC for some reason that has nothing > to do with DNS, just some obsolete whois stuff and some legal mumbo > jumbo that only applies to about 25 countries. Yes it is frustrating, when you've chased what=20 you understood to be a goal, near it, and then=20 find the outcome not to be what you expected.=20 It's even worse if you find out the goal is=20 actually somewhere else, a place you could have=20 been if you had made a different decision years=20 back. I can not lay blame at the feet of those who=20 raise last minute objections. The waterfall=20 model of engineering (requirements,=20 implementations, test, deploy) rarely works in=20 that order with some feedback loops. Things=20 change, conditions change as time progresses.=20 That and attention to a topic changes over time -=20 a lot of folks with limited resources may have=20 decided years ago to ignore a research project,=20 but now the project draws more attention, a=20 broader range of opinion. I think that we all do get smarter from this broader range of opinion. =46or those who have been working on the project=20 for years encounter new comments from new=20 sources, there are two outcomes. One is to=20 repeat the rationale of why a similar comment in=20 the past did not fly, e.g., why there are=20 problems with the NO RR proposal. The other=20 outcome is to generate a reaction to the new=20 proposal - positively or negatively. In the case of the NSEC2, we have some past=20 experience with the such a proposal, and that's=20 been discussed. (I'm not claiming closure on the=20 topic.) Today, though, the question isn't really whether=20 NSEC2 is a good thing or bad thing. The issue is=20 what does the WG do. That is more determined=20 with what the WG is constituted and prepared to=20 do. One way to look at the issue is the WG is=20 composed of engineers. Do the current specs=20 represent sound, workable engineering? If so, we=20 should publish them and see what happens. Maybe=20 the current specs will be the next Betamax, but=20 they work. The other way is to expand our roles to being=20 "problem solvers in the large." I.e., that we=20 sit down and consider legal opinions as part of=20 our input. IOW, we should hold up all output=20 until we have the perfect solution - defined by=20 one that makes everyone happy. If I were to make a decision right now - right=20 now because many know I easily change so-called=20 sides in a discussion - I would say that we=20 should release the documents regardless of=20 (perceived, anticipated) legal hassles. I don't=20 think that we are capable of negotiating between=20 different legal environments - we are just=20 engineers. Yesterday I made the comment to Rob that I feel=20 the documents ought not go forward. That's=20 because I don't see that there's a clean way to=20 migrate from NSEC to NSEC2, assuming there's a=20 need to. There are a lot of versions of BIND=20 with experimental (and disabled) DNSSEC code in=20 them, but hey, that's the cost of doing business=20 I guess. We should continue to listen for more input from=20 the external community. Perhaps there is a need=20 to develop NSEC2. In other messages I concluded=20 (personally) that it can express negative=20 answers, but at a cost that makes me wonder if it=20 is workable (the linear growth of work as=20 determined by the client). > >1. I was strongly in favour of exploring NO record and it's implications > when Simon started that work. > NO failed to catch on for a combination of reasons including: > - There was no explicit need to stop zone walking. > - It was MUCH more expensive than NXT, > 2x names (the real one and hash name) > 2x lookups in authoritative server to answer negative answer > first the name then the nearest hash > More expensive to sign a zone as all hash names had to > generated and sorted. > - Later on we discovered that NO did not=20 >work with empty non-terminals and=20 >wildcards. (more later) (NO complied with > at-the-time understanding of the issues). > >2. MarkK is too much of an gentleman to say this, so I will: > - opt-in addresses your publicly stated issue with NSEC. > only by securing a domain does become it trivial to > find whois info. > >3. Someone said that we can not deploy a protocol that a single TLD's is > unable to support for local legal reasons. > Answer: Get over it, IF you want DNSSEC security, change > to a name in a different TLD and put a DNAME at the old one. > >4. We have known since day ONE that root and TLD's are special and taken > that into consideration, otherwise the opt-in proposal would have > not been considered for this long. > We have known about EU privacy issues but been told publicly > it was a non issue. > Thus any statements of the type: > "I can not share with you privileged legal opinion" > must be considered FUD. So unless the position paper (or at > least relevant sections) is made public, the working group > MUST ignore the issue. > > Also what is the implication if some EU citizen registers a domain > in say .cn domain does that mean .cn has to follow EU rules? > Answer: .cn sovereignty tops EU rules. > >5. What in DNS makes something like NO++ difficult? > 5.1 Zones with Multiple label names. > 5.2 Zones with wild cards. > outlaw both and the problem becomes much simpler for any NO-- proposal > Moral: When there is a DNS problem do not patch it up, address the > underlying issue. > If Zone walking is limited to TLD's then restrict the what the > zones look like to simplify life. > W/O restrictions on zone depth and wildcards, the number of > NO++ records server needs/should/may include in an negative > answer will depend on the query. > If the burden of discovering this is placed on the resolver > by requiring label stripping, then time to assert validity of > an answer is to great. > >5.5 On-line signing of negative answers, who signs it > a master server ? > a authoritative server ? > and with what key. > In any case these servers can now be DoS'ed as the work they need to > perform is much greater than the effort of the attackers. > >6. Current NSEC2 proposal does not address the issue of name conflict betwe= en > a valid name and a digest, NO addressed this by moving all NO records > into a separate name space. > There is lots of hot air about the encoding, size of, obfuscating of > NSEC2 names, these are minor details lets address the first order > problem: > > For who is zone walking a problem and why? > > I assert: root zone has no problem. > >6.1 > Are any TLD's willing to go on the record to say NSEC zone > walking is a > non-issue > show-stopper > >6.2 > For leaf zones same questions ? > >6.3 > For enterprise zones same questions ? > > Unless the WG gets some hard facts presented to these questions > this whole issue should be dropped. > >7. Should the co-chair have asked question #4? > Lets just kill DNSSEC it is to difficult and expensive. > > Olafur (just some bozo who has followed DNSSEC for 9.5 years) > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 25 13:11: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 NAA00571 for ; Tue, 25 May 2004 13:11:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSfOe-000AF7-T4 for namedroppers-data@psg.com; Tue, 25 May 2004 17:07:24 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSfNU-000A1T-3p for namedroppers@ops.ietf.org; Tue, 25 May 2004 17:06:12 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4PH67aa029543; Tue, 25 May 2004 10:06:07 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 May 2004 10:06:07 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=27=D3lafur_Gu=F0mundsson=27?= , namedroppers@ops.ietf.org Subject: RE: NSEC+ and NO Date: Tue, 25 May 2004 10:06:04 -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 > 0. It is real frustrating when a bunch of late new comers > suddenly say they > can not deploy DNSSEC for some reason that has nothing > to do with DNS, just some obsolete whois stuff and some > legal mumbo > jumbo that only applies to about 25 countries. Hold it right there. This issue has been raised repeatedly, but I have yet to hear a substantive answer. All I have seen or heard is pointers to claims that it has been answered before. This is a classic agenda denial tactic. Don't address the substance of the argument, attack the standing of the person making it. The reason that this process is taking so long is that instead of facing the real challenges for deployment these are mau-maued off the table, then when they inevitably return the process is repeated. It would hardly be surprising if people had been slow comming forward with issues. The treatment they have received in this group has hardly been wellcoming. I get hissed by the then AD and future chair the first time I try to say a word in a DNSEXT meeting. The mode of argument is always 'your experience, knowledge and business interests are irrelevant to this group', followed by 'my understanding of the complexities of DNS means that my statements cannot be disputed'. The fact is however that every issue that has come out at the "last minute" has been raised repeatedly and ignored. Now we are told that the only options are between doing it according to the current specs and abandoning DNSSEC entirely. This is a false choice, we do not need to delay or abandon the DNSSEC specs, we do not need to define a new NSEC record. All we need to do is to make NSEC optional. Making NSEC optional reduces but does not eliminate the security benefit of DNSSEC. Since we are talking about an infrastructure that is currently insecure and will take many years to deploy a security infrastructure for there it makes no sense to make NSEC a show stopper. IF DNSSEC is deployed you will discover FAR more problems than just NSEC. I don't think that at the time proving non-existence of domains was accepted as a showstopper 9 years ago that the implications for the present day Internet could have been understood. Over that time the number of users has gone from a few million college students to a billion. There has also been a radical change in the understanding of the security problem over that time. When I started doing Web security in 1992 the security field was still centered on the problem of securing multiple user access to a single, non networked computer. The role cryptography might play in a network environment was poorly understood. Since then there has been a radical reassesment of the appropriate application of cryptography in the field. Much of this is the result of extensive and painful experience trying to deploy cryptographic systems. From a pure security perspective NSEC buys you very little of value. This is because DNS is not just a protocol, it is a component in a system. In a system there is no useful distinction between a subsystem that replies 'It does not exist' and one that says 'I cannot find 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 Tue May 25 13:56: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 NAA03649 for ; Tue, 25 May 2004 13:56:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSg70-000KZD-Pc for namedroppers-data@psg.com; Tue, 25 May 2004 17:53:14 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSg6j-000KUT-Mo for namedroppers@ops.ietf.org; Tue, 25 May 2004 17:52:57 +0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4PHqkV2026149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2004 10:52:47 -0700 (PDT) Received: from [10.0.0.136] (vpn-10-50-16-61.qualcomm.com [10.50.16.61]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4PHqhvB024428; Tue, 25 May 2004 10:52:44 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Tue, 25 May 2004 10:52:41 -0700 To: "Hallam-Baker, Phillip" , =?iso-8859-1?Q?=27=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson=27?= , namedroppers@ops.ietf.org From: Ted Hardie Subject: RE: NSEC+ and NO 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:06 AM -0700 05/25/2004, Hallam-Baker, Phillip wrote: > >>From a pure security perspective NSEC buys you very little of value. >This is because DNS is not just a protocol, it is a component in >a system. In a system there is no useful distinction between >a subsystem that replies 'It does not exist' and one that says >'I cannot find it'. I strongly disagree with this. From an application designer's perspective, getting back a *trustable* "this does not exist" is very different from getting "I cannot find it". You may be thinking in terms of human driven activities like browsing, in which there is a human to apply heuristics to an error code; in some of those the human tends to apply the same guesses to what to do next in response to both. But this is not the only class of applications, and for many of the discovery elements of those, I believe reliable data for non-existence is required. Speaking personally, regards, Ted Hardie -- to unsubscribe send a message to namedroppers-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 May 25 16:55: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 QAA18625 for ; Tue, 25 May 2004 16:55:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSist-000A3M-UW for namedroppers-data@psg.com; Tue, 25 May 2004 20:50:51 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSisa-0009zC-TO for namedroppers@ops.ietf.org; Tue, 25 May 2004 20:50:36 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 3ECF119B460; Tue, 25 May 2004 16:46:58 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id BBCB619B43D; Tue, 25 May 2004 16:46:57 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.35.166.53]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1689857; Tue, 25 May 2004 16:50:30 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 25 May 2004 13:50:00 -0700 To: "Hallam-Baker, Phillip" From: Edward Lewis Subject: RE: NSEC+ and NO 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.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:06 -0700 5/25/04, Hallam-Baker, Phillip wrote: >Hold it right there. This issue has been raised repeatedly, but I >have yet to hear a substantive answer. All I have seen or heard is >pointers to claims that it has been answered before. First a plea for civility. I've yet to see any response (on-line, I did get one verbal response) to my NSEC2 examples. In my mind they listed the issues I perceive - "in my mind." If what I have written is unclear or misinformed as far as premise, I'd appreciate comments on the examples. The messages are: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00608.html and http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00610.html (To keep threading clean, if you have comments on the messages, reply to those, not this message.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 25 17:23: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 RAA21741 for ; Tue, 25 May 2004 17:23:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSjKV-000Dne-GM for namedroppers-data@psg.com; Tue, 25 May 2004 21:19:23 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSjKQ-000Dn5-MH for namedroppers@ops.ietf.org; Tue, 25 May 2004 21:19:18 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i4PJkJof010970 for ; Tue, 25 May 2004 15:46:19 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlUaaBv; Tue, 25 May 04 15:46:18 -0400 Received: from localhost (suresh@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id i4PJlgJG024252 for ; Tue, 25 May 2004 15:47:42 -0400 (EDT) Date: Tue, 25 May 2004 15:47:42 -0400 (EDT) From: Suresh Krishnaswamy X-X-Sender: suresh@filbert To: namedroppers@ops.ietf.org Subject: -proto -records ambiguity? Message-ID: 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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In -records section 3 (last para): "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset it covers." And in -proto section 2.2: "For each authoritative RRset in a signed zone there MUST be at least one RRSIG record that meets all of the following requirements: ... o The RRSIG RR's TTL is equal to the TTL of the RRset" I feel that the "SHOULD" in -records and "MUST" in -proto must somehow be reconciled. If the expectation is to be able to have an RRset and its corresponding RRSIG coexist with differing TTLs, does the above referenced bulleted item in -proto really hold? Suresh -- to unsubscribe send a message to namedroppers-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 May 25 18:04: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 SAA25911 for ; Tue, 25 May 2004 18:04:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSjxK-000J2D-De for namedroppers-data@psg.com; Tue, 25 May 2004 21:59:30 +0000 Received: from [69.10.132.76] (helo=willow.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSjxJ-000J1w-5W for namedroppers@ops.ietf.org; Tue, 25 May 2004 21:59:29 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by willow.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4PLxLDA006889 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 25 May 2004 22:59:28 +0100 Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4PLxDso014894 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 25 May 2004 22:59:14 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4PM0h5o099240 for ; Tue, 25 May 2004 23:00:43 +0100 (BST) (envelope-from roy+dated+1088114443.c7a2af@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4PM0hri099239 for namedroppers@ops.ietf.org; Tue, 25 May 2004 23:00:43 +0100 (BST) (envelope-from roy+dated+1088114443.c7a2af@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 25 May 2004 23:00:42 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16563.49674.412883.793394@giles.gnomon.org.uk> Date: Tue, 25 May 2004 23:00:42 +0100 To: Edward Lewis Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-Reply-To: References: 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 (willow.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) 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 >>>>> "Edward" == Edward Lewis writes: Edward> I've yet to see any response (on-line, I did get one Edward> verbal response) to my NSEC2 examples. In my mind they Edward> listed the issues I perceive - "in my mind." If what I Edward> have written is unclear or misinformed as far as premise, Edward> I'd appreciate comments on the examples. Of course, the Nominet zones (at least) have no wild cards, and this is true of most TLDs. And the immediate example that springs to mind of a TLD that currently uses wildcards is .museum, which uses the wildcards to take a browser to an index page listing names in the museum gTLD -- so they presumably would have no concerns about enumeration. So a simplified NSEC2 that prohibited wild cards in the zone might well satisfy the concerns of the vast majority of TLD operators, and perhaps others, too. I'm sure someone elsewhere in this thread implied in passing the idea that zones might be given a choice of mechanisms for authenticated denial: one with the properties of NXT/NSEC, or an alternative that lacked the perceived enumeration problem but constrained the zone to contain no wildcards. However I think I concur with something that I think someone else in this thread (sorry, I forget who) had in mind a while back: _if_ any changes are going to be made to the spec at this stage, the one change that should seriously be contemplated is introducing a mechanism allowing a zone to declare (on a per-zone basis) what authenticated denial mechanism they use. I'm inclined to believe that authenticated denial should remain a mandatory feature for secure zones, but a flag indicating what mechanism the zone uses would make any future introduction of an alternative to NSEC much more painless. If an alternative authenticated denial proposal gains support subsequent to DNSSEC deployment, then such a flag would allow resolvers not supporting the new mechanism to (correctly) return an unauthenticated NXDOMAIN response (or a null answer in the case of an empty non-terminal) rather than returning SERVFAIL. -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 May 25 18:05: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 SAA25966 for ; Tue, 25 May 2004 18:05:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSjwF-000IpU-4N for namedroppers-data@psg.com; Tue, 25 May 2004 21:58:23 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSjwD-000IpA-9V for namedroppers@ops.ietf.org; Tue, 25 May 2004 21:58:21 +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 i4PLwIP07709 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 25 May 2004 17:58:20 -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 i4PM36101259 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 25 May 2004 18:03:12 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4PLv4H9008045 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 25 May 2004 17:57:04 -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 i4PLv3le008042 for ; Tue, 25 May 2004 17:57:04 -0400 To: namedroppers@ops.ietf.org Subject: Re: Scope of discussion References: <20040525010308.0AF1A13E10@sa.vix.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 25 May 2004 17:57:03 -0400 Message-ID: <8041.1085522223@marajade.sandelman.ottawa.on.ca> From: Michael Richardson 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Olaf" == Olaf Kolkman writes: Olaf> I think it is clear at this point that the current DNSSEC-bis Olaf> protocol spec eases content enumeration; I think it is clear Olaf> that this causes a number of TLDs (and other players) to Olaf> believe that they cannot deploy DNSSEC in its current form. I disagree. Only bind ever gave them the feeling that content enumeration wasn't trivial to begin with. If limiting things is desired, then someone needs to write those requirements clearly, and then say that DNSSEC fails at them. - -- ] "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 iQCVAwUBQLPBLoqHRg3pndX9AQGAcAQA6r+B6zSIdSjhxR+QGM7UYd1CmbwYyqAT 4pQprLlhEvNhEL6dhBsbbCgHFOER/G5f0sGgusxotkEgsFE2qBH+FwCdPcV+S9PA I74iUCznKTC804qNpJRx+eUnsKUyrMa97AvAgCMBkRiNeabddO9ON5+IjF+xEkPk rjuOZDSqQsw= =+tms -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 25 18:19: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 SAA28924 for ; Tue, 25 May 2004 18:19:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSkDi-000LnQ-7R for namedroppers-data@psg.com; Tue, 25 May 2004 22:16:26 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSkDg-000Ln6-3r for namedroppers@ops.ietf.org; Tue, 25 May 2004 22:16:24 +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 i4PM3aT07754 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 25 May 2004 18:04:10 -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 i4PM5L101478 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 25 May 2004 18:05:28 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4PLxJH9008105 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 25 May 2004 17:59:19 -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 i4PLxJZ7008102; Tue, 25 May 2004 17:59:19 -0400 To: namedroppers@ops.ietf.org cc: Paul Vixie Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) In-Reply-To: Message from Paul Vixie of "Tue, 25 May 2004 01:03:08 -0000." <20040525010308.0AF1A13E10@sa.vix.com> References: <20040525010308.0AF1A13E10@sa.vix.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 25 May 2004 17:59:18 -0400 Message-ID: <8100.1085522358@marajade.sandelman.ottawa.on.ca> From: Michael Richardson 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Vixie writes: >> I hate to say this... if we are going to do this, let's do it >> *now* Paul> technically i agree with this statement. but if we were going Paul> to do this, we should never have even considered >> I think that the chairs should establish a firm time table for >> doing this work. It should take no more than 5 weeks. Paul> this is also not realistic. with dnssec, we can't call it Paul> "done" until it's been extensively reviewed, modelled, and Paul> beer&pizza-tested, and for something at the level of NSEC2 Paul> that will take six to 12 months. that's how we found "the Yeah, I agree. I don't want to pick up the NSEC2 work. I don't care about enumeration. But, if we have to do it, then we have to it now, and we have to figure out how to do it quickly. Yes, it requires beer, pizza and additional workshops. Yes, that requires resources. If the NSEC2 proponents have the resources then perhaps they would step up to the plate on this. - -- ] "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 iQCVAwUBQLPBsIqHRg3pndX9AQFagAP/TR4Cmnm/+Z1G+vMG+Nn0TSovbQGItxe5 GyuPV4ywJECMcspJm7o7UGbO6fG5xWvdlUhAfTAuIWYArhfskfjJVtqrLFsPOAwa GdRZRgwDR8e6Z5dj/dL8KtFbLkKH7CvZ+/2wO+kcb2A/93nXLVQHfbSqpkK+3g4a 3Das0nouffw= =uPh5 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 25 18:43: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 SAA02383 for ; Tue, 25 May 2004 18:43:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSkbF-000OuG-Fb for namedroppers-data@psg.com; Tue, 25 May 2004 22:40:45 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSkbC-000OtB-9q for namedroppers@ops.ietf.org; Tue, 25 May 2004 22:40:42 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i4PLWaCs026519 for ; Tue, 25 May 2004 17:32:36 -0400 Received: from lapdancer ([129.6.220.4]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i4PLWB4A026800 for ; Tue, 25 May 2004 17:32:11 -0400 (EDT) Message-ID: <006901c44286$e5ecf8a0$7ba723c0@lapdancer> From: "Scott Rose" To: References: Subject: Re: -proto -records ambiguity? Date: Tue, 25 May 2004 14:34:21 -0400 Organization: NIST 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov 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 Content-Transfer-Encoding: 7bit I believe the MUST in the proto document is the correct way. The TTL statement in the Record draft should be changed to reflect that. D'oh. Thanks for catching that. ----- Original Message ----- From: "Suresh Krishnaswamy" To: Sent: Tuesday, May 25, 2004 3:47 PM Subject: -proto -records ambiguity? > > In -records section 3 (last para): > "The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset it > covers." > > And in -proto section 2.2: > "For each authoritative RRset in a signed zone there MUST be at least one > RRSIG record that meets all of the following requirements: > .... > o The RRSIG RR's TTL is equal to the TTL of the RRset" > > I feel that the "SHOULD" in -records and "MUST" in -proto must somehow be > reconciled. If the expectation is to be able to have an RRset and its > corresponding RRSIG coexist with differing TTLs, does the above > referenced bulleted item in -proto really hold? > > Suresh > > -- > to 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 May 25 19:22:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06903 for ; Tue, 25 May 2004 19:22:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSlD0-00042Q-1R for namedroppers-data@psg.com; Tue, 25 May 2004 23:19:46 +0000 Received: from [216.93.164.123] (helo=zak.ecotroph.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSlCz-00042C-6m for namedroppers@ops.ietf.org; Tue, 25 May 2004 23:19:45 +0000 Received: from [10.0.1.70] ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Tue, 25 May 2004 19:09:30 -0400 id 0005C5E6.40B3D22A.00000583 In-Reply-To: <16563.49674.412883.793394@giles.gnomon.org.uk> References: <16563.49674.412883.793394@giles.gnomon.org.uk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9293C6FA-AEA0-11D8-A66A-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit Cc: Edward Lewis , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org From: Andrew Newton Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Tue, 25 May 2004 19:09:28 -0400 To: Roy Badami X-Mailer: Apple Mail (2.613) 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 On May 25, 2004, at 6:00 PM, Roy Badami wrote: > > However I think I concur with something that I think someone else in > this thread (sorry, I forget who) had in mind a while back: _if_ any > changes are going to be made to the spec at this stage, the one change > that should seriously be contemplated is introducing a mechanism > allowing a zone to declare (on a per-zone basis) what authenticated > denial mechanism they use. > > I'm inclined to believe that authenticated denial should remain a > mandatory feature for secure zones, but a flag indicating what > mechanism the zone uses would make any future introduction of an > alternative to NSEC much more painless. > If possible, this pick-your-poison approach sounds good to me. -andy -- to unsubscribe send a message to namedroppers-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 May 25 23:33: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 XAA18884 for ; Tue, 25 May 2004 23:33:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSp67-000BaM-2u for namedroppers-data@psg.com; Wed, 26 May 2004 03:28:55 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSp64-000Ba7-RD for namedroppers@ops.ietf.org; Wed, 26 May 2004 03:28:52 +0000 Received: from Puki.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i4Q3Gebc035093; Tue, 25 May 2004 23:16:41 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040525102400.02f9a038@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 25 May 2004 23:16:00 -0400 To: Ben Laurie From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: NSEC+ and NO Cc: namedroppers@ops.ietf.org In-Reply-To: <40B35FB7.1080302@algroup.co.uk> References: <6.1.0.6.2.20040524180114.0652aec0@localhost> <40B35FB7.1080302@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks Ben for sticking to technical issues. At 11:01 25/05/2004, Ben Laurie wrote: >=D3lafur Gu=F0mundsson wrote: >>2. MarkK is too much of an gentleman to say this, so I will: >> - opt-in addresses your publicly stated issue with NSEC. >> only by securing a domain does become it trivial to >> find whois info. > >Security or privacy, choose one, you mean? > >Another problem with this coould be that you are now publishing a list of= =20 >high-value targets. But it is the "targets" choice, not the registries. >>6. Current NSEC2 proposal does not address the issue of name conflict= between >> a valid name and a digest, NO addressed this by moving all NO records >> into a separate name space. > >I haven't understood why this is needed - why do name conflicts matter?=20 >Since NSEC2 records are special, they can be treated as being in a=20 >separate namespace anyway. Explicitly adding one just wastes space. Or am= =20 >I missing something? Ok let me demonstrate, for the sake of argument we hash with md5 once and the hashed name is encoded in hex. MD5("amazon.co.uk") =3D beb32a6851b0317502d5a40ce5146e43.co.uk. Now, what if I have already registered that name and even gone as far as trademarking it. what happens ? how will resolvers react seeing both NS and NSEC-bis at the same=20 note? what does the denial for my name look like ? The current proposal addresses this partially by having multiple rounds of hash, and salt. But these parameters can only be changed once in a while. Moving the rounds into the NSEC2 record allows the zone signer to keep= trying until there is no conflict, but there is no way for resolver to query= directly for the NSEC2 record as the resolver does not know how many rounds there= are. These are just some of the complications that needs to be thought out documented, coded and tested a few times, before DNSSEC v4 will be ready in 2006. First lets get the requirements on the table, not the solutions. As far as I can tell there is only one requirement on the table: NO ZONE walking of TLD's via negative answer records. As for constraints size (number of names) wildcards label depth. Add requirements and constraints as you see fit. Think about both TLD's and leaf zones. Then think about ENUM, a sparse but deep zone, what are the implications there. We can not keep on solving just one party's problem we need to think= forward. Once we have the requirements we can think about how to best address the issue, either by protocol changes, document changes or (maybe) ignore. Example: Opt-in was viewed by some as a solution to a "Verisign only"= problem, in hindsight it might provide what you want/need. Olafur=20 -- to unsubscribe send a message to namedroppers-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 May 26 00:40: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 AAA21559 for ; Wed, 26 May 2004 00:40:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSq7j-000K5w-CZ for namedroppers-data@psg.com; Wed, 26 May 2004 04:34:39 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSq7h-000K5a-Hp for namedroppers@ops.ietf.org; Wed, 26 May 2004 04:34:37 +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 i4Q0KMrd001487; Wed, 26 May 2004 01:20:24 +0100 (BST) To: Roy Badami cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: Message from Roy Badami of "Tue, 25 May 2004 23:00:42 BST." <16563.49674.412883.793394@giles.gnomon.org.uk> Date: Wed, 26 May 2004 01:20:22 +0100 Message-ID: <1486.1085530822@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Badami writes: Roy> So a simplified NSEC2 that prohibited wild cards in the zone Roy> might well satisfy the concerns of the vast majority of TLD Roy> operators, and perhaps others, too. This is not an option, even though I'd *love* to exterminate wildcards from the DNS protocol. Suppose some form of NSEC2-style DNSSEC was deployed by a TLD. It later decides it must have a wildcard in the zone. So it has to drop this suggested NSEC2 flavour DNSSEC and either becomes insecure or else presumably adopts NSEC flavour DNSSEC and lives with enumeration and so forth. Icky. It would be even worse for implementers and security-aware resolvers as they'd need to keep track of which zone used which flavour of DNSSEC. That could be very, very unpleasant. So if there's going to be a Secure DNS protocol, it must be something that can work for every and any zone. Oh, and did I hear anyone say "Sitefinder"? :-) BTW, remarkably few TLD operators have said anything here about the concerns that have motivated this NSEC2 draft. Where's this "vast majority"? -- to unsubscribe send a message to namedroppers-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 May 26 00:40: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 AAA21577 for ; Wed, 26 May 2004 00:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSqAp-000Kef-Kl for namedroppers-data@psg.com; Wed, 26 May 2004 04:37:51 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSqAn-000KeC-W3 for namedroppers@ops.ietf.org; Wed, 26 May 2004 04:37:50 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id QAA24584; Wed, 26 May 2004 16:37:48 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i4Q4bmfw076469; Wed, 26 May 2004 16:37:48 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: Olafur Omundsson cc: namedroppers@ops.ietf.org from: don@plugh.daedalus.co.nz Subject: Re: NSEC+ and NO In-Reply-To: Your message of "Tue, 25 May 2004 01:12:55 -0400." Date: Wed, 26 May 2004 16:37:48 +1200 Message-ID: <76468.1085546268@toybsd.zl2tnm.gen.nz> 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 Olafur Omundsson?= wrote: >6.1 > Are any TLD's willing to go on the record to say NSEC zone > walking is a > non-issue > show-stopper I'm not the policy guru for NZ, just the guy who gets asked DNS stuff. However, it's very clear to me that there would need to be a major change in view among NZ registry stakeholders for NSEC to be accepted because of the zone walking problem. The ability to walk the zone would have to viewed in the same light as for zone downloads, given that the for the most part, the same policy issues are exposed. It's possible that the rate of such walking could be restricted in the simple cases, but I don't think I could put my hand on my heart and say that such throttling would stop those even mildly determined to get a copy of a zone, nor that it would not potentially negatively impact the performance of the name servers in responding to legitimate queries. Current zone transfer policy[1] is basically "no zone transfers unless authorised and conditions met". The new draft policy[2], likely to be accepted very shortly, is more restrictive, basically denies access to zone files unless an "exceptional reason" for access to the zone can be demonstrated. There is a clear trend towards becoming more protective of the registry database, and the index to the WHOIS data it represents. That said, DNSSEC is quite clearly on the NZ registry radar; we would very much like to be on the leading (but perhaps not bleeding) edge of DNSSEC deployment. Getting a little more pragmatic, I think the real question is, can we have our cake and eat it too? Or, can we break NSEC walking without breaking NSEC? Consider... Authenticated denial relies on there being am authenticatable "space" between each record, thus if I have: a.example. NSEC c.example. ... c.example. ... then I know that there are no records between a.example and c.example. But if I instead inserted: a.example. NSEC a_.example. ... a_.example. NSEC a__.example. ... ; booby-trap a__.example. NSEC c.example. ... c.example. ... What if an explicit query to a_.example. triggered some kind of defensive response, such as a complete refusal to return the NSEC record? In this example, because of the third NSEC, you would never get the booby-trap record except as the result of an attempt to walk the NSEC chain. -- don [1] http://www.dnc.org.nz/content/zone_transfer.pdf [2] http://www.dnc.org.nz/content/proposed_new_zone_transfer_policy.pdf -- to unsubscribe send a message to namedroppers-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 May 26 02:17: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 CAA11010 for ; Wed, 26 May 2004 02:17:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSrg0-0007E2-6S for namedroppers-data@psg.com; Wed, 26 May 2004 06:14:08 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSrfz-0007Dj-0R for namedroppers@ops.ietf.org; Wed, 26 May 2004 06:14:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9F6E613DE5 for ; Wed, 26 May 2004 05:13:00 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: Message from Jim Reid of "Wed, 26 May 2004 01:20:22 +0100." <1486.1085530822@gromit.rfc1035.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 26 May 2004 05:13:00 +0000 Message-Id: <20040526051300.9F6E613DE5@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 > Roy> So a simplified NSEC2 that prohibited wild cards in the zone > Roy> might well satisfy the concerns of the vast majority of TLD > Roy> operators, and perhaps others, too. last time this was proposed, i wondered whether use of such signalling on a zone that actually did have a wildcard would be "invalid," and who would be hurt by it if a zone was published that "invalid" way, and whether validators, if among those hurt, could even detect the condition. in other words, would we be providing a way to turn on both the heat and air conditioning at the same time, or is there an interlock preventing this? and if there's no interlock, who pays the cost of all the wasted energy, or does the house just blow up, and are my children in it at the time? -- to unsubscribe send a message to namedroppers-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 May 26 03:05: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 DAA25344 for ; Wed, 26 May 2004 03:05:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSsRU-000Ggr-RH for namedroppers-data@psg.com; Wed, 26 May 2004 07:03:12 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSsRT-000Gg0-Ce for namedroppers@ops.ietf.org; Wed, 26 May 2004 07:03:11 +0000 Received: (qmail 9986 invoked by uid 1001); 26 May 2004 07:03:09 -0000 To: jim@rfc1035.com Cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag From: sthaug@nethelp.no In-Reply-To: Your message of "Wed, 26 May 2004 01:20:22 +0100" References: <1486.1085530822@gromit.rfc1035.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 26 May 2004 09:03:09 +0200 Message-ID: <9984.1085554989@bizet.nethelp.no> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > BTW, remarkably few TLD operators have said anything here about the > concerns that have motivated this NSEC2 draft. Where's this "vast > majority"? One ccTLD operator I've talked to has said that their views are pretty well covered by what Nominet people on this list have expressed so far. I agree that it would be good to have explicit reactions from the TLD operators. Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 26 04:14: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 EAA29073 for ; Wed, 26 May 2004 04:14:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BStVT-00021m-Tr for namedroppers-data@psg.com; Wed, 26 May 2004 08:11:23 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BStVS-00021R-5i for namedroppers@ops.ietf.org; Wed, 26 May 2004 08:11:22 +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 i4Q8BGLb062297 for ; Wed, 26 May 2004 10:11:18 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4Q8BEQx030322 for ; Wed, 26 May 2004 10:11:14 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4Q8BBsu030319 for ; Wed, 26 May 2004 10:11:14 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 10:11:11 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: More on NSEC2 label size and DoS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new 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,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I still see a technical limit with NSEC2: 1) multiple hashed labels. I assume that every label needs to be hashed individually (Ben ?). Due to the SHA-1 digest size in base32, (32 characters), plus 1 byte label length+type, and a maximum owner name length of 255 bytes, there is a maximum of 7 hashed labels, i.e., there are issues for names like: 1.1.1.1.1.2.2.2.2.3.3.1.2.3.4.in-addr.arpa. and 5.4.1.4.1.1.0.1.6.3.1.e164.arpa. 2) DoS issue with multiple labels. Since a hash(label) needs to be performed by the server to look up (internally) the proper NSEC for proof, the effort for creating a response would be higher then the effort for sending a query, compared to NSEC or non-DNS. 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 May 26 04:25: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 EAA00052 for ; Wed, 26 May 2004 04:25:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSthC-0003KA-ES for namedroppers-data@psg.com; Wed, 26 May 2004 08:23:30 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSth9-0003Ju-Pp for namedroppers@ops.ietf.org; Wed, 26 May 2004 08:23:27 +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 i4Q7gqDC019961 for ; Wed, 26 May 2004 09:42:52 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4Q7goh25164 for ; Wed, 26 May 2004 09:42:50 +0200 (MEST) Message-Id: <200405260742.i4Q7goh25164@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: NSEC+ and NO In-reply-to: Your message of "Wed, 26 May 2004 16:37:48 +1200." <76468.1085546268@toybsd.zl2tnm.gen.nz> 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: <25158.1085557368.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 26 May 2004 09:42:49 +0200 From: Peter Koch 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 don@plugh.daedalus.co.nz wrote: > But if I instead inserted: > > a.example. NSEC a_.example. ... > a_.example. NSEC a__.example. ... ; booby-trap > a__.example. NSEC c.example. ... > c.example. ... > > What if an explicit query to a_.example. triggered some kind of > defensive response, such as a complete refusal to return the NSEC > record? In this example, because of the third NSEC, you would never get > the booby-trap record except as the result of an attempt to walk the > NSEC chain. "NSEC" walking would usually not be done with explicit queries for NSEC RRs (because that's too easy to answer with REFUSED, since there's probably no need for those queries) but by asking for "random" names and interpreting the NXDOMAIN responses (and the NSEC RRs therein). So, one wouldn't ask for "a_.example." anyway but for e.g. the next name after "a_", say "a__". Now you could protect this name by the booby-trap, but then I'd ask for "a___" and the more traps you have the lesser NXDOMAIN responses you can really support with NSEC, which sooner or later would hit an innocent requestor who's not walking but just mistyped a domain name. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 26 04:28: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 EAA00111 for ; Wed, 26 May 2004 04:28:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BStjr-0003fv-SL for namedroppers-data@psg.com; Wed, 26 May 2004 08:26:15 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BStjq-0003fh-Nu for namedroppers@ops.ietf.org; Wed, 26 May 2004 08:26:14 +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 i4Q8Pvqe062430; Wed, 26 May 2004 10:25:57 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4Q8PtoB030655; Wed, 26 May 2004 10:25:55 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4Q8PsX1030652; Wed, 26 May 2004 10:25:54 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 10:25:54 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Roy Badami cc: Edward Lewis , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-Reply-To: <16563.49674.412883.793394@giles.gnomon.org.uk> Message-ID: References: <16563.49674.412883.793394@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 25 May 2004, Roy Badami wrote: > However I think I concur with something that I think someone else in > this thread (sorry, I forget who) had in mind a while back: _if_ any > changes are going to be made to the spec at this stage, the one change > that should seriously be contemplated is introducing a mechanism > allowing a zone to declare (on a per-zone basis) what authenticated > denial mechanism they use. You can't declare anything 'by zone'. A resolver is _completely_clueless_ about zone concept. A zone in merely space delegate to an entity minus subspace delegated by that entity. If, big if, anything can be declared by zone (similar like SOA), how would you proof that record exist ? or not exist ? 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 May 26 05: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 FAA01543 for ; Wed, 26 May 2004 05:00:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSuEV-0007ZD-7c for namedroppers-data@psg.com; Wed, 26 May 2004 08:57:55 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSuET-0007Yu-Mr for namedroppers@ops.ietf.org; Wed, 26 May 2004 08:57:53 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 060681FE6D; Wed, 26 May 2004 09:57:53 +0100 (BST) Date: Wed, 26 May 2004 09:57:44 +0100 From: Alex Bligh Reply-To: Alex Bligh To: don@plugh.daedalus.co.nz, Olafur Omundsson Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC+ and NO Message-ID: <680967389.1085565464@[192.168.100.5]> In-Reply-To: <76468.1085546268@toybsd.zl2tnm.gen.nz> References: <76468.1085546268@toybsd.zl2tnm.gen.nz> X-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 26 May 2004 16:37 +1200 don@plugh.daedalus.co.nz wrote: > But if I instead inserted: > > a.example. NSEC a_.example. ... > a_.example. NSEC a__.example. ... ; booby-trap > a__.example. NSEC c.example. ... > c.example. ... > > What if an explicit query to a_.example. triggered some kind of > defensive response, such as a complete refusal to return the NSEC > record? In this example, because of the third NSEC, you would never get > the booby-trap record except as the result of an attempt to walk the > NSEC chain. This only works if the querying person cannot distinguish the booby-trap records (or those leading to them) from the real records. But you have to (as you have illustrated) put your booby-trap records as close as possible to the records themselves. For example if the records are: string.example NSEC string_.example string_.example NSEC string__.example ; booby trap string__.example NSEC struth.example struth.example... then when you get the boobytrap result (for string_.example) you just look up string_zzzzzzzzzzzzz.example instead, which will give you a non-exist pointing to struth.example. On a more theoretical level, what you are trying to do is introduce small segments of the space "between" names that do not return useful non-existence proof. You want to make that space as small as possible in order that non-existence proof works elsewhere. But that makes it trivially easy to ask instead for a name outside that small space but in the larger space before the next "real" name. 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 May 26 05:03: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 FAA01648 for ; Wed, 26 May 2004 05:03:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSuI1-000859-3J for namedroppers-data@psg.com; Wed, 26 May 2004 09:01:33 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSuHz-00084o-VL for namedroppers@ops.ietf.org; Wed, 26 May 2004 09:01:32 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i4PIQ57g021631; Tue, 25 May 2004 11:26:05 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 May 2004 11:26:05 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Ted Hardie'" , "Hallam-Baker, Phillip" , =?iso-8859-1?Q?=27=D3lafur_Gu=F0mundsson=27?= , namedroppers@ops.ietf.org Subject: RE: NSEC+ and NO Date: Tue, 25 May 2004 11:25:56 -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 strongly disagree with this. From an application > designer's perspective, > getting back a *trustable* "this does not exist" is very > different from getting > "I cannot find it". You may be thinking in terms of human > driven activities > like browsing, in which there is a human to apply heuristics > to an error > code; in some of those the human tends to apply the same guesses > to what to do next in response to both. But this is not the > only class > of applications, and for many of the discovery elements of those, > I believe reliable data for non-existence is required. Your argument would only support the statement "reliable data for non-existence is required FOR CERTAIN APPLICATIONS". Given that the choice being asserted is between a DNSSEC as is, and no DNSSEC at all, ever I think it is reasonable to point out that there is a wide range of Internet USE that is addressed without NSEC. If DNSSEC v1 is only sufficient to provide security for Web browsing that is more than enough to justify the effort. It is exactly the same as in MARID, don't insist on solving the entire problem in the first go. MARID will not provide the solution to spam, but it does provide me with one of the tools I need. The big fallacy we fell into ten years ago was beleiving that imperfect security was worse than no security at all. SSL disproved that, SSL v1 was so bad I broke it fifteen minutes into Marc A's presentation, and not in a small way either. SSL v2 was a bit better but has plenty of holes. Yet these did not stop SSL v3 being the most successful cryptographic protocol of all time. In the WiFi area WEP was a disaster, but fixes soon appeared. If it wasn't for the fact that WiFi systems tend to be in hardware it would not have been such a serious problem. We can make as much fun of the SSL and WEP groups as we like, but the fact is that they deployed a real solution that is now both secure and widely used. This group has not, despite having tried for longer. Delivering a cryptographic system that delivers real security for an important class of applications is a very worthwhile project, even if a limitation in the protocol means that it does not protect other applications. In this case we are far better off than with SSL or WEP because we know what the problem is and there is even a fix for the problem. All that is being said is that the fix should not be mandatory, nor should inability to come up with an acceptable fix in the next few days mean that the entire scheme is scrapped. Some people are saying delay the specs, I am not. I am saying publish the @&$*@!! things and start deployment today. Just do not force anyone to use a part of the specs that many believe to be broken. All my experience of deploying real world cryptographic protocols tells me that we are nowhere close to having a legacy issue here. There will be more than enough time to fix this. The only question is whether we leave ourselves an acceptable way to deploy a new NSEC without having to revise all the existing RRs and clobber the deployed base yet again. -- to unsubscribe send a message to namedroppers-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 May 26 05:41: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 FAA02859 for ; Wed, 26 May 2004 05:41:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSurM-000D0K-50 for namedroppers-data@psg.com; Wed, 26 May 2004 09:38:04 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSurI-000D03-7b for namedroppers@ops.ietf.org; Wed, 26 May 2004 09:38:00 +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 i4Q8Kdh1062382 for ; Wed, 26 May 2004 10:20:39 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4Q8KbQE030546 for ; Wed, 26 May 2004 10:20:37 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4Q8Kbwk030543 for ; Wed, 26 May 2004 10:20:37 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 10:20:37 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Re: More on NSEC2 label size and DoS In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk btw, if hashes are per owner name instead of per label, then other size issues are at hand, since for every intermediate label level (empty non terminal) a new NSEC+SIG (or EXIST) needs to be created. That hurts in zones under ip6.arpa and e164.arpa. Roy On Wed, 26 May 2004 roy@dnss.ec wrote: > Hi, > > I still see a technical limit with NSEC2: > > 1) multiple hashed labels. > > I assume that every label needs to be hashed individually (Ben ?). Due to > the SHA-1 digest size in base32, (32 characters), plus 1 byte label > length+type, and a maximum owner name length of 255 bytes, there is a > maximum of 7 hashed labels, i.e., there are issues for names like: > > 1.1.1.1.1.2.2.2.2.3.3.1.2.3.4.in-addr.arpa. and > 5.4.1.4.1.1.0.1.6.3.1.e164.arpa. > > 2) DoS issue with multiple labels. > > Since a hash(label) needs to be performed by the server to look up > (internally) the proper NSEC for proof, the effort for creating a response > would be higher then the effort for sending a query, compared to NSEC or > non-DNS. > > 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: > -- to unsubscribe send a message to namedroppers-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 May 26 05:41:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02945 for ; Wed, 26 May 2004 05:41:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSusw-000D9p-UN for namedroppers-data@psg.com; Wed, 26 May 2004 09:39:42 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSusw-000D9a-2I for namedroppers@ops.ietf.org; Wed, 26 May 2004 09:39:42 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 745D11FE6C; Wed, 26 May 2004 09:49:02 +0100 (BST) Date: Wed, 26 May 2004 09:48:53 +0100 From: Alex Bligh Reply-To: Alex Bligh To: sthaug@nethelp.no, jim@rfc1035.com Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Message-ID: <680436315.1085564933@[192.168.100.5]> In-Reply-To: <9984.1085554989@bizet.nethelp.no> References: <1486.1085530822@gromit.rfc1035.com> <9984.1085554989@bizet.nethelp.no> X-Mailer: Mulberry/3.1.1 (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 26 May 2004 09:03 +0200 sthaug@nethelp.no wrote: >> BTW, remarkably few TLD operators have said anything here about the >> concerns that have motivated this NSEC2 draft. Where's this "vast >> majority"? > > One ccTLD operator I've talked to has said that their views are pretty > well covered by what Nominet people on this list have expressed so far. > I agree that it would be good to have explicit reactions from the TLD > operators. In terms of European (by which I really mean RIPE area) ccTLDs, you are probably best asking this at some CENTR event. I am not sure a large number of ccTLD people are on this list, and even to the extent they are, they are probably technical people rather than technical plus policy people. 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 May 26 06: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 GAA04329 for ; Wed, 26 May 2004 06:02:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvCf-000Fyw-7Y for namedroppers-data@psg.com; Wed, 26 May 2004 10:00:05 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvCd-000FyM-BU for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:00:03 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 1C82119641; Wed, 26 May 2004 11:34:17 +0200 (CEST) Date: Wed, 26 May 2004 11:34:17 +0200 (CEST) From: Jakob Schlyter To: Alex Bligh Cc: don@plugh.daedalus.co.nz, Olafur Omundsson , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: <680967389.1085565464@[192.168.100.5]> Message-ID: References: <76468.1085546268@toybsd.zl2tnm.gen.nz> <680967389.1085565464@[192.168.100.5]> 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 On Wed, 26 May 2004, Alex Bligh wrote: > This only works if the querying person cannot distinguish the booby-trap > records (or those leading to them) from the real records. note that the "person" will most probably be some sort of program. > then when you get the boobytrap result (for string_.example) you > just look up string_zzzzzzzzzzzzz.example instead, which will give you > a non-exist pointing to struth.example. you do not know if there are zero or more boobytraps in between. this is in no way failsafe, but could probably be used to stop simple walking and plain enumeration by guessing labels. I think it should be explored further by those who might need it. jakob -- to unsubscribe send a message to namedroppers-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 May 26 06: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 GAA05539 for ; Wed, 26 May 2004 06:21:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvUI-000ILP-Su for namedroppers-data@psg.com; Wed, 26 May 2004 10:18:18 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvUF-000IKz-Ld for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:18:15 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4QAIClZ026360 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 26 May 2004 10:18:14 GMT (envelope-from roy+dated+1088158781.456731@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4QAI9so017952 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 26 May 2004 11:18:11 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4QAJf5o002734 for ; Wed, 26 May 2004 11:19:41 +0100 (BST) (envelope-from roy+dated+1088158781.456731@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4QAJfaG002733 for namedroppers@ops.ietf.org; Wed, 26 May 2004 11:19:41 +0100 (BST) (envelope-from roy+dated+1088158781.456731@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 26 May 2004 11:19:39 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16564.28474.714383.372054@giles.gnomon.org.uk> Date: Wed, 26 May 2004 11:19:38 +0100 To: roy@dnss.ec Cc: Roy Badami , Edward Lewis , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-Reply-To: References: <16563.49674.412883.793394@giles.gnomon.org.uk> 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-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 >>>>> "roy" == roy writes: roy> You can't declare anything 'by zone'. A resolver is roy> _completely_clueless_ about zone concept. We may be talking at cross purposes, but surely DNSSEC declares keys on a per-zone basis, with DNSKEY records stored at the zone apex? How would this be different? -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 May 26 06:22: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 GAA05613 for ; Wed, 26 May 2004 06:22:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvWi-000IdO-BZ for namedroppers-data@psg.com; Wed, 26 May 2004 10:20:48 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvWh-000Id7-8P for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:20:47 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSv1G-0003b1-P2; Wed, 26 May 2004 11:48:18 +0200 In-Reply-To: <680436315.1085564933@[192.168.100.5]> To: Alex Bligh Cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 26 May 2004 11:48:10 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 26.05.2004 11:48:18, Serialize complete at 26.05.2004 11:48:18 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 > > One ccTLD operator I've talked to has said that their views are pretty > > well covered by what Nominet people on this list have expressed so far. > > I agree that it would be good to have explicit reactions from the TLD > > operators. > > In terms of European (by which I really mean RIPE area) ccTLDs, you > are probably best asking this at some CENTR event. I am not sure a > large number of ccTLD people are on this list, and even to the extent > they are, they are probably technical people rather than technical plus > policy people. Perhaps this link might illustrate the magnitude of the issue within CENTR area: http://www.centr.org/technical/zone-access.html 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: From owner-namedroppers@ops.ietf.org Wed May 26 06:22: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 GAA05631 for ; Wed, 26 May 2004 06:22:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvWq-000Iex-LF for namedroppers-data@psg.com; Wed, 26 May 2004 10:20:56 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvWh-000Id7-PG for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:20:47 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSutb-00026v-0o; Wed, 26 May 2004 11:40:23 +0200 In-Reply-To: <6.1.0.6.2.20040525102400.02f9a038@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: Ben Laurie , namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 26 May 2004 11:40:12 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 26.05.2004 11:40:22, Serialize complete at 26.05.2004 11:40:22 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 > Ok let me demonstrate, for the sake of argument we hash with md5 once > and the hashed name is encoded in hex. > MD5("amazon.co.uk") = beb32a6851b0317502d5a40ce5146e43.co.uk. > > Now, what if I have already registered that name and even gone as > far as trademarking it. > what happens ? RFC2782, for instance, prepended "_" to avoid collisions with natural names.. > First lets get the requirements on the table, not the solutions. > > As far as I can tell there is only one requirement on the table: > NO ZONE walking of TLD's via negative answer records. It's actually not a requirement only applying to TLDs. 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: From owner-namedroppers@ops.ietf.org Wed May 26 06:23: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 GAA05662 for ; Wed, 26 May 2004 06:23:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvWj-000Ido-C6 for namedroppers-data@psg.com; Wed, 26 May 2004 10:20:49 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvWi-000Id7-9D for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:20:48 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSuYH-00061l-Ao; Wed, 26 May 2004 11:18:21 +0200 In-Reply-To: <16563.49674.412883.793394@giles.gnomon.org.uk> To: Roy Badami Cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 26 May 2004 11:18:15 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 26.05.2004 11:18:21, Serialize complete at 26.05.2004 11:18:21 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 Roy, > So a simplified NSEC2 that prohibited wild cards in the zone might > well satisfy the concerns of the vast majority of TLD operators, and > perhaps others, too. Dispatching wildcards from NSEC2 would not be an option. The DE-zone has entries of the form *.abc.de some stuff Ed's analysis (which I've collated and regard as sound) applies for these cases, too. However, the linear growth of server work and answer size in hands of the client doesn't seem that dangerous to me. 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: From owner-namedroppers@ops.ietf.org Wed May 26 06:38: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 GAA06998 for ; Wed, 26 May 2004 06:38:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvlh-000Kon-2w for namedroppers-data@psg.com; Wed, 26 May 2004 10:36:17 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvlf-000KoP-SY for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:36:16 +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 i4QAaE57007848 for ; Wed, 26 May 2004 12:36:14 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4QAaEk26142 for ; Wed, 26 May 2004 12:36:14 +0200 (MEST) Message-Id: <200405261036.i4QAaEk26142@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: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-reply-to: Your message of "Wed, 26 May 2004 11:18:15 +0200." 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: <26136.1085567765.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 26 May 2004 12:36:14 +0200 From: Peter Koch 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 Marcos Sanz/Denic wrote: > Dispatching wildcards from NSEC2 would not be an option. > > The DE-zone has entries of the form > > *.abc.de some stuff a workaround would be to simply move those into separate zones - even without necessarily having to change your registration policy. That would cause some, maybe even some more, overhead on the side of server maintenance, but if getting rid of wildcards eases a solution it's worth exploring this path. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 26 06:40: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 GAA07045 for ; Wed, 26 May 2004 06:40:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvnZ-000L8i-SL for namedroppers-data@psg.com; Wed, 26 May 2004 10:38:13 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvnQ-000L6f-Ol for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:38:04 +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 i4QARTp7063491; Wed, 26 May 2004 12:27:29 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QARQn4000649; Wed, 26 May 2004 12:27:26 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QARQVZ000646; Wed, 26 May 2004 12:27:26 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 12:27:26 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Roy Badami cc: roy@dnss.ec, Edward Lewis , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-Reply-To: <16564.28474.714383.372054@giles.gnomon.org.uk> Message-ID: References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 26 May 2004, Roy Badami wrote: > >>>>> "roy" == roy writes: > > roy> You can't declare anything 'by zone'. A resolver is > roy> _completely_clueless_ about zone concept. > > We may be talking at cross purposes, but surely DNSSEC declares keys > on a per-zone basis, with DNSKEY records stored at the zone apex? How > would this be different? I can deploy a test.dnss.ec zone where silly.test.dnss.ec is signed by the dnss.ec DNSKEY. 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 May 26 06:40: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 GAA07070 for ; Wed, 26 May 2004 06:40:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvnS-000L7O-V5 for namedroppers-data@psg.com; Wed, 26 May 2004 10:38:06 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvnP-000L6f-Hk for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:38:03 +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 i4QAMEcA063382; Wed, 26 May 2004 12:22:14 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QAMBoc000346; Wed, 26 May 2004 12:22:11 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QAMACu000343; Wed, 26 May 2004 12:22:11 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 12:22:10 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Jim Reid cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: More on NSEC2 label size and DoS In-Reply-To: <2290.1085566418@gromit.rfc1035.com> Message-ID: References: <2290.1085566418@gromit.rfc1035.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 26 May 2004, Jim Reid wrote: > >>>>> "roy" == roy writes: > > roy> btw, if hashes are per owner name instead of per label, then > roy> other size issues are at hand, since for every intermediate > roy> label level (empty non terminal) a new NSEC+SIG (or EXIST) > roy> needs to be created. > > roy> That hurts in zones under ip6.arpa and e164.arpa. > > Something similar to NSEC2 would be pointless for e164.arpa because > the name space is regular and well-known: eg all North American E.164 > numbers are exactly 10 digits long after the +1. Enumeration of this > name space using DNS lookups is a no-brainer irrespective of how or if > the zones get signed. True, but irrelevant. If NSEC2 is adopted, deprecating NSEC, it does not discriminate between reverse and forward zones. If ip6.arpa is signed, it is signed with NSEC2. No choice, no way out. 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 May 26 06:42: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 GAA07203 for ; Wed, 26 May 2004 06:42:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvpl-000LUl-K0 for namedroppers-data@psg.com; Wed, 26 May 2004 10:40:29 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvpk-000LUQ-Br for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:40: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 i4QAeMrd002390; Wed, 26 May 2004 11:40:24 +0100 (BST) To: Marcos Sanz/Denic cc: Alex Bligh , namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: Message from Marcos Sanz/Denic of "Wed, 26 May 2004 11:48:10 +0200." Date: Wed, 26 May 2004 11:40:22 +0100 Message-ID: <2389.1085568022@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic writes: Marcos> Perhaps this link might illustrate the magnitude of the Marcos> issue within CENTR area: Marcos> http://www.centr.org/technical/zone-access.html This doesn't really help. It just shows that a bunch of TLDs restrict AXFR to their slave servers and sometimes to trusted third parties. It doesn't say why they do this. For instance, I can understand why DeNIC wouldn't want random users to be able to slurp the 1GB or so of the .de zone, guzzling bandwidth and needlessly loading the TLD's name servers. -- to unsubscribe send a message to namedroppers-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 May 26 06:49: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 GAA07559 for ; Wed, 26 May 2004 06:49:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSvwX-000MYu-GB for namedroppers-data@psg.com; Wed, 26 May 2004 10:47:29 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSvwV-000MYL-5p for namedroppers@ops.ietf.org; Wed, 26 May 2004 10:47:27 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4QAlOlZ050327 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 26 May 2004 10:47:26 GMT (envelope-from roy+dated+1088160533.1f1fdf@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4QAlKso018079 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 26 May 2004 11:47:23 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4QAmr5o002956 for ; Wed, 26 May 2004 11:48:53 +0100 (BST) (envelope-from roy+dated+1088160533.1f1fdf@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4QAmrQK002955 for namedroppers@ops.ietf.org; Wed, 26 May 2004 11:48:53 +0100 (BST) (envelope-from roy+dated+1088160533.1f1fdf@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 26 May 2004 11:48:51 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16564.30227.3445.173997@giles.gnomon.org.uk> Date: Wed, 26 May 2004 11:48:51 +0100 To: roy@dnss.ec Cc: Roy Badami , Edward Lewis , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-Reply-To: References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> 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-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 >>>>> "roy" == roy writes: roy> I can deploy a test.dnss.ec zone where silly.test.dnss.ec is roy> signed by the dnss.ec DNSKEY. You can? -proto 2.1 requires a delegated secure zone to contain a DNSKEY record at the apex. And 2.2 requires RRsets to be signed with at least one RRSIG where the Signer's Name equals the name of the zone containing the RRset. -records 3.1.7 requires the Signer's Name in an RRSIG to match the name of the zone containing the RRset. -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 May 26 07:37: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 HAA09531 for ; Wed, 26 May 2004 07:37:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSwgy-00038x-QK for namedroppers-data@psg.com; Wed, 26 May 2004 11:35:28 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSwgx-00038S-Hm for namedroppers@ops.ietf.org; Wed, 26 May 2004 11:35:27 +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 i4QBZHK5064269; Wed, 26 May 2004 13:35:17 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QBZE3R002698; Wed, 26 May 2004 13:35:14 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QBZBIT002695; Wed, 26 May 2004 13:35:12 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 13:35:11 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Roy Badami cc: roy@dnss.ec, Edward Lewis , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-Reply-To: <16564.30227.3445.173997@giles.gnomon.org.uk> Message-ID: References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 26 May 2004, Roy Badami wrote: > >>>>> "roy" == roy writes: > > roy> I can deploy a test.dnss.ec zone where silly.test.dnss.ec is > roy> signed by the dnss.ec DNSKEY. > > You can? Yes, you can. > -proto 2.1 requires a delegated secure zone to contain a DNSKEY record > at the apex. And 2.2 requires RRsets to be signed with at least one > RRSIG where the Signer's Name equals the name of the zone containing > the RRset. -records 3.1.7 requires the Signer's Name in an RRSIG to > match the name of the zone containing the RRset. I know, I've heard of those docs. The problem is that a validator has no way to check that. 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 May 26 07:37: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 HAA09532 for ; Wed, 26 May 2004 07:37:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSwgB-0002zk-Nc for namedroppers-data@psg.com; Wed, 26 May 2004 11:34:39 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSwgA-0002zT-DS for namedroppers@ops.ietf.org; Wed, 26 May 2004 11:34:38 +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 i4QADcrd002291; Wed, 26 May 2004 11:13:39 +0100 (BST) To: roy@dnss.ec cc: namedroppers@ops.ietf.org Subject: Re: More on NSEC2 label size and DoS In-Reply-To: Message from roy@dnss.ec of "Wed, 26 May 2004 10:20:37 +0200." Date: Wed, 26 May 2004 11:13:38 +0100 Message-ID: <2290.1085566418@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "roy" == roy writes: roy> btw, if hashes are per owner name instead of per label, then roy> other size issues are at hand, since for every intermediate roy> label level (empty non terminal) a new NSEC+SIG (or EXIST) roy> needs to be created. roy> That hurts in zones under ip6.arpa and e164.arpa. Something similar to NSEC2 would be pointless for e164.arpa because the name space is regular and well-known: eg all North American E.164 numbers are exactly 10 digits long after the +1. Enumeration of this name space using DNS lookups is a no-brainer irrespective of how or if the zones get signed. -- to unsubscribe send a message to namedroppers-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 May 26 07:57: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 HAA10686 for ; Wed, 26 May 2004 07:57:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSwzd-00060Q-En for namedroppers-data@psg.com; Wed, 26 May 2004 11:54:45 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSwzc-0005zn-FP for namedroppers@ops.ietf.org; Wed, 26 May 2004 11:54:44 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSwGd-0002d1-13; Wed, 26 May 2004 13:08:15 +0200 In-Reply-To: <2389.1085568022@gromit.rfc1035.com> To: Jim Reid Cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 26 May 2004 13:08:13 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 26.05.2004 13:08:14, Serialize complete at 26.05.2004 13:08:14 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 Jim, > Marcos> http://www.centr.org/technical/zone-access.html > > This doesn't really help. It just shows that a bunch of TLDs restrict > AXFR to their slave servers and sometimes to trusted third parties. Point taken. However, I think these TLDs aren't placing the zipped zone at everyone's disposal via anonymous FTP either. 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: From owner-namedroppers@ops.ietf.org Wed May 26 07: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 HAA10704 for ; Wed, 26 May 2004 07:57:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSwzm-00061j-1r for namedroppers-data@psg.com; Wed, 26 May 2004 11:54:54 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSwzd-0005zn-1y for namedroppers@ops.ietf.org; Wed, 26 May 2004 11:54:45 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BSwMn-0003t2-FC; Wed, 26 May 2004 13:14:37 +0200 In-Reply-To: <200405261036.i4QAaEk26142@grimsvotn.TechFak.Uni-Bielefeld.DE> To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Wed, 26 May 2004 13:14:35 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 26.05.2004 13:14:37, Serialize complete at 26.05.2004 13:14:37 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 > That would cause > some, maybe even some more, overhead on the side of server maintenance, > but if getting rid of wildcards eases a solution it's worth > exploring this path. Agreed. 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: From owner-namedroppers@ops.ietf.org Wed May 26 08:01: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 IAA10928 for ; Wed, 26 May 2004 08:01:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSx3j-0006mK-TD for namedroppers-data@psg.com; Wed, 26 May 2004 11:58:59 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSx3i-0006lN-2W for namedroppers@ops.ietf.org; Wed, 26 May 2004 11:58:58 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4QBwulZ022564 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 26 May 2004 11:58:57 GMT (envelope-from roy+dated+1088164824.31e16d@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4QBwqso018364 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 26 May 2004 12:58:54 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4QC0O5o003355 for ; Wed, 26 May 2004 13:00:24 +0100 (BST) (envelope-from roy+dated+1088164824.31e16d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4QC0OAm003354 for namedroppers@ops.ietf.org; Wed, 26 May 2004 13:00:24 +0100 (BST) (envelope-from roy+dated+1088164824.31e16d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 26 May 2004 13:00:22 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16564.34517.954862.554622@giles.gnomon.org.uk> Date: Wed, 26 May 2004 13:00:21 +0100 To: roy@dnss.ec Cc: Roy Badami , Edward Lewis , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-Reply-To: References: <16563.49674.412883.793394@giles.gnomon.org.uk> 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-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 >>>>> "roy" == roy writes: roy> If, big if, anything can be declared by zone (similar like roy> SOA), how would you proof that record exist ? or not exist ? Place a new RR at the zone apex, that specifies the authenticated denial algorithm(s) used by the zone. You can validate it by its RRSIG. Make the RR mandatory for all zones that use something else instead of (or in addition to) NSEC. By definition, therefore, the only secure zones that lack this RR will be able to deny its existence using NSEC. Require that any zone that doesn't support NSEC MUST return this new RR as part of its authenticated denial proof. -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 May 26 08:05: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 IAA11140 for ; Wed, 26 May 2004 08:05:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSx7l-0007Y6-VW for namedroppers-data@psg.com; Wed, 26 May 2004 12:03:09 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSx7f-0007VM-IV for namedroppers@ops.ietf.org; Wed, 26 May 2004 12:03:03 +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 i4QC2tGW064546 for ; Wed, 26 May 2004 14:02:55 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QC2r9D003456 for ; Wed, 26 May 2004 14:02:53 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QC2qBt003453 for ; Wed, 26 May 2004 14:02:52 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 14:02:52 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: Message-ID: References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, OPT_IN,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Lets stop this sillyness, and get back to Authenticated Denial Flags. The point is, something about authenticated denial mechanism needs to be signalled. It cannot be done by a record per_zone, since that would introduce a circular probem. (The NSECINFO in the NSEC2 draft has this problem). Another way to go is to subtype this into the NSEC2 record. A version field. Where and 8 bit version field holds either: 0 ffu 1 clear label (plain old DNSSEC) 2 reserved (later:hashed labels) 3 reserved (later:hashed ownernames) 4 reserved (later:opt-in) etc. And we simply document version 0, clear label. With the restriction that version !1 MUST be discarded as being proof if version is not implemented (AND signature verifies) and all NSEC records in a zone have the same version. Ofcourse future versions are not backwards compatible, so the need-to-denial-check-aggression-cost of not compatible resolvers is placed at those who deploy future versions. How does that sound ? 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 May 26 08:05: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 IAA11164 for ; Wed, 26 May 2004 08:05:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSx82-0007ay-35 for namedroppers-data@psg.com; Wed, 26 May 2004 12:03:26 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BSx7u-0007ZG-Nx for namedroppers@ops.ietf.org; Wed, 26 May 2004 12:03:18 +0000 Received: (qmail 23521 invoked by uid 1001); 26 May 2004 11:36:36 -0000 To: jim@rfc1035.com Cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag From: sthaug@nethelp.no In-Reply-To: Your message of "Wed, 26 May 2004 11:40:22 +0100" References: <2389.1085568022@gromit.rfc1035.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 26 May 2004 13:36:36 +0200 Message-ID: <23519.1085571396@bizet.nethelp.no> 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,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This doesn't really help. It just shows that a bunch of TLDs restrict > AXFR to their slave servers and sometimes to trusted third parties. It > doesn't say why they do this. For instance, I can understand why DeNIC > wouldn't want random users to be able to slurp the 1GB or so of the > .de zone, guzzling bandwidth and needlessly loading the TLD's name > servers. But it's okay to let random users enumerate the zone by following NSEC RRs? Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 26 08:39: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 IAA13463 for ; Wed, 26 May 2004 08:39:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSxcM-000CBe-Ms for namedroppers-data@psg.com; Wed, 26 May 2004 12:34:46 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSxcE-000CAT-Ao for namedroppers@ops.ietf.org; Wed, 26 May 2004 12:34:38 +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 i4QBkIrd002500; Wed, 26 May 2004 12:46:18 +0100 (BST) To: sthaug@nethelp.no cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: Message from sthaug@nethelp.no of "Wed, 26 May 2004 13:36:36 +0200." <23519.1085571396@bizet.nethelp.no> Date: Wed, 26 May 2004 12:46:18 +0100 Message-ID: <2499.1085571978@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "sthaug" == sthaug writes: >> This doesn't really help. It just shows that a bunch of TLDs >> restrict AXFR to their slave servers and sometimes to trusted >> third parties. It doesn't say why they do this. For instance, I >> can understand why DeNIC wouldn't want random users to be able >> to slurp the 1GB or so of the .de zone, guzzling bandwidth and >> needlessly loading the TLD's name servers. sthaug> But it's okay to let random users enumerate the zone by sthaug> following NSEC RRs? IMO, yes. UDP traffic to an already active socket has to be better for the name server and underlying OS than carrying the same traffic over freshly-created TCP connections, all other things being equal. Not that I care about enumeration anyway, however it's done. -- to unsubscribe send a message to namedroppers-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 May 26 09:19: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 JAA15368 for ; Wed, 26 May 2004 09:19:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSyGK-000IMk-V8 for namedroppers-data@psg.com; Wed, 26 May 2004 13:16:04 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSyFv-000IKQ-86 for namedroppers@ops.ietf.org; Wed, 26 May 2004 13:15:39 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4QDFUU9016687; Wed, 26 May 2004 06:15:30 -0700 (PDT) Received: from [10.0.0.136] (vpn-10-50-0-23.qualcomm.com [10.50.0.23]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4QDFR3P019319; Wed, 26 May 2004 06:15:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Wed, 26 May 2004 06:15:26 -0700 To: "Hallam-Baker, Phillip" , =?iso-8859-1?Q?=27=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson=27?= , namedroppers@ops.ietf.org From: Ted Hardie Subject: RE: NSEC+ and NO 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:25 AM -0700 05/25/2004, Hallam-Baker, Phillip wrote: > > I strongly disagree with this. From an application >> designer's perspective, >> getting back a *trustable* "this does not exist" is very >> different from getting >> "I cannot find it". You may be thinking in terms of human >> driven activities >> like browsing, in which there is a human to apply heuristics >> to an error >> code; in some of those the human tends to apply the same guesses >> to what to do next in response to both. But this is not the >> only class >> of applications, and for many of the discovery elements of those, >> I believe reliable data for non-existence is required. > >Your argument would only support the statement "reliable data >for non-existence is required FOR CERTAIN APPLICATIONS". How do you propose to let the DNS resolver know what application has requested a record? > >Some people are saying delay the specs, I am not. I am saying publish >the @&$*@!! things and start deployment today. Just do not force >anyone to use a part of the specs that many believe to be broken. To quote one of my colleagues, "The mailing list has no guns". >All my experience of deploying real world cryptographic protocols >tells me that we are nowhere close to having a legacy issue here. >There will be more than enough time to fix this. The only question >is whether we leave ourselves an acceptable way to deploy a new >NSEC without having to revise all the existing RRs and clobber >the deployed base yet again. I do not have the same experience with cryptographic protocols, but I fairly sure that we have to aim at the target we want to hit. Even if it takes several iterations to get it right, if we are not aiming at a protocol that allows for reliable data for non-existence, I believe we are aiming at the wrong target. regards, Ted Hardie -- to unsubscribe send a message to namedroppers-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 May 26 09:26: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 JAA15686 for ; Wed, 26 May 2004 09:26:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSyNS-000JK5-45 for namedroppers-data@psg.com; Wed, 26 May 2004 13:23:26 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSyNK-000JJA-Pb for namedroppers@ops.ietf.org; Wed, 26 May 2004 13:23:18 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4QDNHlZ092574 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 26 May 2004 13:23:19 GMT (envelope-from roy+dated+1088169887.57b215@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4QDNEso018738 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 26 May 2004 14:23:15 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.9p2/8.12.9) with ESMTP id i4QDOl5o003890 for ; Wed, 26 May 2004 14:24:47 +0100 (BST) (envelope-from roy+dated+1088169887.57b215@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.9p2/8.12.9/Submit) id i4QDOloA003889 for namedroppers@ops.ietf.org; Wed, 26 May 2004 14:24:47 +0100 (BST) (envelope-from roy+dated+1088169887.57b215@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 26 May 2004 14:24:47 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16564.39582.570457.670964@giles.gnomon.org.uk> Date: Wed, 26 May 2004 14:24:46 +0100 To: roy@dnss.ec Cc: namedroppers@ops.ietf.org Subject: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> 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-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 >>>>> "roy" == roy writes: roy> Lets stop this sillyness, and get back to Authenticated roy> Denial Flags. The point is, something about authenticated roy> denial mechanism needs to be signalled. It cannot be done by roy> a record per_zone, since that would introduce a circular roy> probem. (The NSECINFO in the NSEC2 draft has this problem). Hmmm, I think I've just spotted a bigger problem with any authenticated denial flag. If a zone (.org.uk, say) decides not to use NSEC, then (obviously) old resolvers that don't understand the authenticated denial mechanism chosen by .org.uk won't be able to verify non-existence proofs presented for .org.uk, and will have to treat them much as NXDOMAIN responses from insecure zones. I'd been assuming that this isn't necessarily a Very Bad Thing. Unfortunately, with DS, provably insecure delegations rely on authenticated denial to prove the non-existence of a DS record. So in this scenario, assuming that gnomon.org.uk is a secure zone, someone could spoof data in my zone by spoofing an insecure delegation from .org.uk and old resolvers would be unaware that anything untoward had happened. -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 May 26 10:06: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 KAA17600 for ; Wed, 26 May 2004 10:06:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSz0h-00017Y-59 for namedroppers-data@psg.com; Wed, 26 May 2004 14:03:59 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSz0Q-00013q-3n for namedroppers@ops.ietf.org; Wed, 26 May 2004 14:03:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A5D1A13E14 for ; Wed, 26 May 2004 14:03:41 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from Peter Koch of "Wed, 26 May 2004 09:42:49 +0200." <200405260742.i4Q7goh25164@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 26 May 2004 14:03:41 +0000 Message-Id: <20040526140341.A5D1A13E14@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 > "NSEC" walking would usually not be done with explicit queries for NSEC RRs > (because that's too easy to answer with REFUSED, since there's probably no > need for those queries) ... actually i was planning on using ANY queries starting at @, the answers to which would include NSEC. that way i can gather all the data in the same pass where i gather all the names. in the scenario, booby traps would be quite effective. the trouble with booby traps is, since udp source addresses are spoofworthy, it would possible to make an authority server generate and hold a huge amount of state just by forging a boobytrap-o-gram from a zillion different addresses. if there's a quota, you can make them overrun it, thus making room for your real zonewalk queries. if there's no quota, you can make them run out of state-memory. -- to unsubscribe send a message to namedroppers-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 May 26 10:37: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 KAA21645 for ; Wed, 26 May 2004 10:37:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSzU9-0006Id-Ct for namedroppers-data@psg.com; Wed, 26 May 2004 14:34:25 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSzU2-0006Hu-7B for namedroppers@ops.ietf.org; Wed, 26 May 2004 14:34:18 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 71CEC13E48 for ; Wed, 26 May 2004 14:34:17 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from Marcos Sanz/Denic of "Wed, 26 May 2004 11:40:12 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 26 May 2004 14:34:17 +0000 Message-Id: <20040526143417.71CEC13E48@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 > > As far as I can tell there is only one requirement on the table: > > NO ZONE walking of TLD's via negative answer records. > > It's actually not a requirement only applying to TLDs. 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 guess we'll need some kind of formal survey of the user base to get a handle on exactly who cares about what. i'm willing to retune the survey software i wrote for "sitefinder" last year, or we can ask ben edelman if he'd be interested. things i'd like to know are: 1. are you concerned about external axfr? for privacy reasons, or resources? 2. are you concerned about zone walking? for privacy reasons, or resources? 3. do you use split-dns to keep sensitive data from being accessed by query? 4. are your axfr/zonewalk concerns based on carefully researched law opinions? 5. are your axfr/zonewalk concerns based on competitive/marketing worries? 6. are you only planning dnssec so your childzones can secure themselves? 7. how many tld's, sld's, 3ld's do these concerns pertain to? there may be more. but we can't do engineering without knowing the customer's requirements, and we can't sit here and make up those requirements, or guess them, or listen to the subset of customers who subscribe to this mailing list. if we really want to say that we care about these concerns, we have to find out what they are, exhaustively and objectively, and then publish the results. -- to unsubscribe send a message to namedroppers-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 May 26 10:57: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 KAA22891 for ; Wed, 26 May 2004 10:57:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BSznM-000ANW-D3 for namedroppers-data@psg.com; Wed, 26 May 2004 14:54:16 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSzm6-000A4c-4b for namedroppers@ops.ietf.org; Wed, 26 May 2004 14:52:58 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 1DE1D19641 for ; Wed, 26 May 2004 16:52:57 +0200 (CEST) Date: Wed, 26 May 2004 16:52:56 +0200 (CEST) From: Jakob Schlyter To: IETF DNSEXT WG Subject: NIC-SE statement regarding NSEC zone walking Message-ID: 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 FYI, jakob -- cut -- Date: Wed, 26 May 2004 16:17:59 +0200 From: Per-Olof Josefsson NIC-SE does not consider NXT zone-walking a problem for DNSSEC deployment within the .se-zone. We consider all data in the DNS to be public information, both as single records and as a collection. The data we actually need to protect is served by WHOIS and protecting this data should be done by the protocol serving it, not by DNS itself. Misuse of DNS data is a problem as it is already, but it will not be solved by stopping deployment of DNSSEC which by other means will make the DNS more secure. We believe that DNSSEC can be deployed in its current form, and are planning to do so. The changes proposed by NSEC2 will, if accepted by the DNSEXT working group, delay the standards process (again) for another 12-18 months time we rather spend on real world deployment. NIC-SE will give an presentation of our current DNSSEC pilot including various aspects such as the zone walking issue at the CENTR meeting in Stockholm at Tuesday 22 june at 09:00. The presentation will be given by either or both Johan Ihren member of the ICANN security group and Jakob Schlyter one of the DNSSEC RFC writers Regards P-O Josefsson NIC-SE -- to unsubscribe send a message to namedroppers-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 May 26 11:27: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 LAA24171 for ; Wed, 26 May 2004 11:27:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT0GU-000GDv-UD for namedroppers-data@psg.com; Wed, 26 May 2004 15:24:22 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT0GD-000GCk-Cm for namedroppers@ops.ietf.org; Wed, 26 May 2004 15:24:05 +0000 Received: from wds1.nominet.org.uk (notes1.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id AD01FE7E9F for ; Wed, 26 May 2004 16:24:04 +0100 (BST) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Cc: geoff@nominet.org.uk Subject: Confirming the Nominet position X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Jay Daley" Date: Wed, 26 May 2004 16:24:03 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 05/26/2004 04:24:04 PM, Serialize complete at 05/26/2004 04:24:04 PM Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable Here is a proper explanation of the Nominet position. 1. Showstopper Zone file enumeration is a show-stopper for us that will prevent us from=20 fully implementing DNSSEC. So if DNSSEC stays in its current form then we=20 will have to make a local determination about how/what we implement, which = is still to be decided. Our reason for this is our view of what is the=20 appropriate policy to act in the best interests of our local community,=20 which for some time has been to deny access to our zone files.=20 =20 2. Late new comers The criticism levelled about "late new comers" is well founded and I'm=20 sorry that is the case. This is something we should have raised some time = ago. Recognising that we were late with this we did try to avoid just=20 unproductive foot stamping by the development of the NSEC2 draft as a=20 positive alternative. We are now committed to the process and we will be=20 here to stay. As evidence of this I should make clear that our next steps = will be to get NSEC2 patches written for BIND and if possible NSD to allow = proper interoperability testing. 3. Way ahead Ideally we would like NSEC2 to go forward properly, but I understand very=20 well that this causes significant problems for many in this WG. So we=20 would be quite happy with a mechanism that allowed NSEC2 to be introduced=20 later in a backwards compatible fashion, such as the previously suggested=20 version field for NSEC. 3. Legal mumbo jumbo I'm sorry if we appear to have been hiding behind legal mumbo jumbo, this=20 was not our intention. So I need to be clear that our legal advice is=20 ancillary to our view in (1) above, not the determining factor.=20 However, for those of you that have asked, this is the gist of our legal=20 advice... As compilations, zone file databases are protected under EU law by=20 ?Database Right?. As a derivative work of the main register from which=20 they are sourced, they are likely also to attract copyright protection in=20 addition to or in place of database right. Both database right and copyright are negative rights in that they=20 prohibit certain acts (primarily, copying the whole or a substantial part=20 of the materials) but do not grant positive rights (unlike, for example, a = patent, which grants a monopoly on the material involved). Database right=20 is unique to countries which implement European Community law, but=20 copyright is more universal.=20 If legal rights would be infringed with copying, then is it not better to=20 allow the copying, and then rely on the law to assist against any=20 infringers? The short answer is ?no?, and here the analogy of locking=20 one?s house or car despite laws against burglary and theft may be helpful. = Prevention is not always better than cure, if one is led to make an=20 overly restrictive solution in order to prevent a minor risk. However, if = the risk of harm is major, and is highly likely to take place, and will be = expensive and difficult to put right after the event, then in those=20 circumstances, prevention is very definitely better than cure. The problem with both copyright and database right arises with=20 enforcement, particularly in respect of electronic data such as a zone=20 file. Firstly it can be hard to identify whether a data mining event has=20 taken place, in the context of the high volume of traffic affecting the=20 nameservers on a day to day basis. If a technical department cannot show=20 this, there is nothing that a legal department can do. Even if it is clear = that it is happening, the technical department may not be able to trace=20 who has done it, because the use of multiple proxies can make it=20 impossible (or prohibitively expensive) to find it. Even if this can be=20 done, the person(s) involved may be abroad. If they are in a difficult=20 jurisdiction (even including eastern Europe, which is part of the EU) the=20 differences in language and legal systems add to the expense and=20 complexity of pursuing legal proceedings.=20 Jay Daley Director of IT Nomient UK -- to unsubscribe send a message to namedroppers-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 May 26 11:56: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 LAA25392 for ; Wed, 26 May 2004 11:56:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT0i8-000NJ2-4R for namedroppers-data@psg.com; Wed, 26 May 2004 15:52:56 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT0hS-000NAj-Mj for namedroppers@ops.ietf.org; Wed, 26 May 2004 15:52:14 +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 i4QFqCV2006721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 May 2004 08:52:13 -0700 (PDT) Received: from [10.0.0.136] (vpn-10-50-0-23.qualcomm.com [10.50.0.23]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4QFq93P001504 for ; Wed, 26 May 2004 08:52:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Wed, 26 May 2004 08:52:08 -0700 To: namedroppers@ops.ietf.org From: Ted Hardie Subject: OT: Concordances was Re: Confirming the Nominet position 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Note the Off topic pointer. There is no protocol or engineering in this message. Hit D now. This is a personal opinion. I am not a lawyer. If you are still listening, I can't imagine why. At 4:24 PM +0100 05/26/2004, Jay Daley wrote: > >As compilations, zone file databases are protected under EU law by >?Database Right?. As a derivative work of the main register from which >they are sourced, they are likely also to attract copyright protection in >addition to or in place of database right. There is a great deal of very detailed law on the subject of how concordances relate to rights in the resources for which the concordances were created. Effectively, you have published the entries which allow the creation of a concordance of the database/resource all along; anyone with a recursive resolver could in turn use that concordance data to reconstruct as much of the original resource as they cared to it. The change you are seeing now is that a new mechanism for iterating through the published entries makes the construction of the concordance easier. Deployment of that mechanism or failure to deploy that mechanism has *no effect* on the rights of the users to create or use concordances of the data. Write that down. You have always published this data; that's the point of the DNS. Write that down. The real threat in all of this is not in the DNS itself, but in the use of the concordance data as a key into a different database of other resources. That is being addressed in a different working group (CRISP), and your engineering talent and resources put there might be better spent. (Just an opinion). In short, spending your time and effort to deploying a real solution (IRIS) to the core problem (accessible user data in administrative databases), makes sense. Educating your government that whether or not you use DNSSEC will make *no difference* to whether or not you publish the actual data and will make *no difference* to the rights individuals have to make concordances may also make sense. You may not have the stomach for it, and I certainly would understand that. Did I mention that this was off topic, that I am not a lawyer, and that I can't imagine why you are listening? Good. regards, Ted Hardie -- to unsubscribe send a message to namedroppers-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 May 26 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 NAA29593 for ; Wed, 26 May 2004 13:04:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT1lE-000DPW-M8 for namedroppers-data@psg.com; Wed, 26 May 2004 17:00:12 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT1l6-000DLI-5F for namedroppers@ops.ietf.org; Wed, 26 May 2004 17:00:04 +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 i4QGxfmH066822; Wed, 26 May 2004 18:59:41 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QGxdiw009259; Wed, 26 May 2004 18:59:39 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QGxdAb009256; Wed, 26 May 2004 18:59:39 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 18:59:39 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ben Laurie cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: More on NSEC2 label size and DoS In-Reply-To: <40B4D23B.2070805@algroup.co.uk> Message-ID: References: <40B4D23B.2070805@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 26 May 2004, Ben Laurie wrote: > roy@dnss.ec wrote: > > btw, if hashes are per owner name instead of per label, then other size > > issues are at hand, since for every intermediate label level (empty non > > terminal) a new NSEC+SIG (or EXIST) needs to be created. > > > > That hurts in zones under ip6.arpa and e164.arpa. > > This is true. I have not calculated how much it hurts. It is related to > the sparseness of the domains. Are there figures for those? > > A back of the envelope calculation I did on the plane says that for e164 > in dense domains, the hit is 10-100% extra. For sparse domains it can be > much higher, but presumably sparse domains are small. Okay, the problem is not e164 but ip6.arpa: 9.1.1.0.6.0.1.0.7.8.0.0.2.9.1.0.a.0.0.8.1.0.0.0.0.1.6.0.1.0.0.2.ip6.arpa. Remember, at _each_ intermediate label level including empty non-terminals (in the above example there are 35 labels) a NSEC (or EXIST) is needed for every occuring value at that label. 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 May 26 13:29: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 NAA01107 for ; Wed, 26 May 2004 13:29:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT298-000IGD-J5 for namedroppers-data@psg.com; Wed, 26 May 2004 17:24:54 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT28m-000IBq-Un for namedroppers@ops.ietf.org; Wed, 26 May 2004 17:24:33 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 41147E7E53; Wed, 26 May 2004 18:24:32 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Message-Id: <20040526172432.41147E7E53@mx1.nominet.org.uk> Date: Wed, 26 May 2004 18:24:32 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: > For instance, I can understand why DeNIC > wouldn't want random users to be able to slurp the 1GB or so of the > .de zone, guzzling bandwidth and needlessly loading the TLD's name > servers. The same `random users' which might be interested in `guzzling bandwidth' with zone transfers will probably also be interested in using scripts which effect NSEC RR elaboration, with even more deleterious impact on resource utilisation. This is of course also possible with NSEC2 RRs, but will probably be interesting only to a significantly smaller audience. 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: From owner-namedroppers@ops.ietf.org Wed May 26 13:39: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 NAA01493 for ; Wed, 26 May 2004 13:39:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT2IJ-000JnP-Uk for namedroppers-data@psg.com; Wed, 26 May 2004 17:34:23 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT2IF-000Jmt-2u for namedroppers@ops.ietf.org; Wed, 26 May 2004 17:34:19 +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 i4QHY0vD067073; Wed, 26 May 2004 19:34:01 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QHXwcl009883; Wed, 26 May 2004 19:33:58 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QHXvj9009880; Wed, 26 May 2004 19:33:58 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 19:33:57 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ben Laurie cc: roy@dnss.ec, Jim Reid , namedroppers@ops.ietf.org Subject: Re: More on NSEC2 label size and DoS In-Reply-To: <40B4D2B5.10407@algroup.co.uk> Message-ID: References: <2290.1085566418@gromit.rfc1035.com> <40B4D2B5.10407@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 26 May 2004, Ben Laurie wrote: > roy@dnss.ec wrote: > > On Wed, 26 May 2004, Jim Reid wrote: > > > > > >>>>>>>"roy" == roy writes: > >> > >> roy> btw, if hashes are per owner name instead of per label, then > >> roy> other size issues are at hand, since for every intermediate > >> roy> label level (empty non terminal) a new NSEC+SIG (or EXIST) > >> roy> needs to be created. > >> > >> roy> That hurts in zones under ip6.arpa and e164.arpa. > >> > >>Something similar to NSEC2 would be pointless for e164.arpa because > >>the name space is regular and well-known: eg all North American E.164 > >>numbers are exactly 10 digits long after the +1. Enumeration of this > >>name space using DNS lookups is a no-brainer irrespective of how or if > >>the zones get signed. > > > > > > True, but irrelevant. If NSEC2 is adopted, deprecating NSEC, it does not > > discriminate between reverse and forward zones. If ip6.arpa is signed, it > > is signed with NSEC2. No choice, no way out. > > My intention (I cannot speak for the WG, of course) was to make it > possible to choose NSEC or NSEC2, since if you don't mind zonewalking, > you shouldn't have to incur the overhead of NSEC2. ack -- to unsubscribe send a message to namedroppers-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 May 26 15:42: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 PAA09529 for ; Wed, 26 May 2004 15:42:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT4DE-000Fup-Ei for namedroppers-data@psg.com; Wed, 26 May 2004 19:37:16 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT4D4-000Ft9-Vg for namedroppers@ops.ietf.org; Wed, 26 May 2004 19:37:07 +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 i4QJaktA067906; Wed, 26 May 2004 21:36:47 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QJaeaD011636; Wed, 26 May 2004 21:36:40 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4QJad61011633; Wed, 26 May 2004 21:36:40 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 26 May 2004 21:36:39 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Roy Badami cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: <16564.39582.570457.670964@giles.gnomon.org.uk> Message-ID: References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> <16564.39582.570457.670964@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 26 May 2004, Roy Badami wrote: > >>>>> "roy" == roy writes: > > roy> Lets stop this sillyness, and get back to Authenticated > roy> Denial Flags. The point is, something about authenticated > roy> denial mechanism needs to be signalled. It cannot be done by > roy> a record per_zone, since that would introduce a circular > roy> probem. (The NSECINFO in the NSEC2 draft has this problem). > > Hmmm, I think I've just spotted a bigger problem with any > authenticated denial flag. > > If a zone (.org.uk, say) decides not to use NSEC, then (obviously) old > resolvers that don't understand the authenticated denial mechanism > chosen by .org.uk won't be able to verify non-existence proofs > presented for .org.uk, and will have to treat them much as NXDOMAIN > responses from insecure zones. I'd been assuming that this isn't > necessarily a Very Bad Thing. > > Unfortunately, with DS, provably insecure delegations rely on > authenticated denial to prove the non-existence of a DS record. > > So in this scenario, assuming that gnomon.org.uk is a secure zone, > someone could spoof data in my zone by spoofing an insecure delegation > from .org.uk and old resolvers would be unaware that anything untoward > had happened. Yes. So it would fall back to vanilla DNS. That is what org.uk is now. In fact, there is nothing lost. Lets say example.com is required to use NSEC2 by their constituency/lawyer/etc. 2 scenarios: 1) DNSSEC deployment is heldup until NSEC2 is done. "example.com" can deploy DNSSEC in 24-36 months. until then, vanilla DNS only for world. or 2) DNSSEC deployment continues. NSEC2 development continues. "example.com" can deploy DNSSEC in 24-36 months, while world can adopt DNSSEC with NSEC in (say) 6 months. My pick would be scenario number 2. Note: this only works with a version field in NSEC. We simply state V1 is NSEC as we know it. !V1 must then be interpreted as plain DNS (verify the NSEC SIG, so the resolver knows the NSEC is legit, treat the delegation or denial as unsecured). 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 May 26 18:13: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 SAA23690 for ; Wed, 26 May 2004 18:13:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT6Z5-000IZR-Dj for namedroppers-data@psg.com; Wed, 26 May 2004 22:07:59 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT6Z4-000IYs-Eu for namedroppers@ops.ietf.org; Wed, 26 May 2004 22:07:58 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CE5C613951 for ; Wed, 26 May 2004 22:07:57 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: Message from Marcos Sanz/Denic of "Wed, 26 May 2004 13:08:13 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 26 May 2004 22:07:57 +0000 Message-Id: <20040526220757.CE5C613951@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 > > This doesn't really help. It just shows that a bunch of TLDs restrict > > AXFR to their slave servers and sometimes to trusted third parties. > > Point taken. However, I think these TLDs aren't placing the zipped > zone at everyone's disposal via anonymous FTP either. well, they ought to. but i guess every generation wants to learn that security through obscurity is an illusion, the hard way. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 26 18:33: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 SAA25324 for ; Wed, 26 May 2004 18:33:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT6uO-000Ll7-8f for namedroppers-data@psg.com; Wed, 26 May 2004 22:30:00 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT6uL-000Lkc-87 for namedroppers@ops.ietf.org; Wed, 26 May 2004 22:29:57 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4QMTslZ049689 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 26 May 2004 22:29:56 GMT (envelope-from roy+dated+1088202658.f0e9d8@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4QMTqso021192 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 26 May 2004 23:29:54 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4QMUw31000334 for ; Wed, 26 May 2004 23:30:58 +0100 (BST) (envelope-from roy+dated+1088202658.f0e9d8@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4QMUwjL000328 for namedroppers@ops.ietf.org; Wed, 26 May 2004 23:30:58 +0100 (BST) (envelope-from roy+dated+1088202658.f0e9d8@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 26 May 2004 23:30:56 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16565.6816.203820.50021@giles.gnomon.org.uk> Date: Wed, 26 May 2004 23:30:56 +0100 To: roy@dnss.ec Cc: Roy Badami , namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> <16564.39582.570457.670964@giles.gnomon.org.uk> 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-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 >>>>> "roy" == roy writes: roy> 2) DNSSEC deployment continues. NSEC2 development roy> continues. "example.com" can deploy DNSSEC in 24-36 months, roy> while world can adopt DNSSEC with NSEC in (say) 6 months. The problem is that a signed (NSEC2) zone can have a secure delegation to another zone (NSEC1 or NSEC2). People will naturally expect that delegated zone to be safe; they need to be made aware that the subzone is not secure as far as NSEC1 resolvers go, unless it is configured as a trust anchor. Note that this problem is new to DS; in RFC2535 provably insecure delegations did not depend on authenticated denial. Maybe this is an acceptable state of affairs, but it makes me nervous. -=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 May 26 20:17: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 UAA00902 for ; Wed, 26 May 2004 20:17:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT8Xj-000OEs-PC for namedroppers-data@psg.com; Thu, 27 May 2004 00:14:43 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT8Xi-000OEJ-JX for namedroppers@ops.ietf.org; Thu, 27 May 2004 00:14:42 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4R0EdlZ031931 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 27 May 2004 00:14:41 GMT (envelope-from roy+dated+1088208944.dca158@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4R0Ecso021714 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 27 May 2004 01:14:39 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4R0FjS5001059 for ; Thu, 27 May 2004 01:15:45 +0100 (BST) (envelope-from roy+dated+1088208944.dca158@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4R0FikT001058 for namedroppers@ops.ietf.org; Thu, 27 May 2004 01:15:44 +0100 (BST) (envelope-from roy+dated+1088208944.dca158@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 27 May 2004 01:15:44 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16565.13104.363074.585875@giles.gnomon.org.uk> Date: Thu, 27 May 2004 01:15:44 +0100 To: namedroppers@ops.ietf.org cc: roy@dnss.ec Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: <16565.6816.203820.50021@giles.gnomon.org.uk> References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> <16564.39582.570457.670964@giles.gnomon.org.uk> <16565.6816.203820.50021@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) 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-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 To be more specific, here is what I'm talking about. Alice is an authoritive nameserver for tld. She uses NSEC2. Bob in an authoritive nameserver for sld.tld delegated from tld by means of a DS record. (It doesn't matter whether he uses NSEC1 or NSEC2.) Charlie is a security-aware resolver. However, he only understands NSEC1. Charlie has a secure entry point into tld (either as a trust anchor, or delegated from a signed root). He does not have sld.tld configured as a trust anchor, but uses the DS record as his secure entry point. Mallory wishes to tamper with the contents of sld.tld, as seen by Charlie. He therefore tampers with the DNS response from Alice refering Charlie to Bob. In particular, he removes the DS record, and inserts a randomly chosen NSEC2 record from tld, together with its RRSIG. Charlie sees the lack of a DS record as indicating an insecure delegation. He can see an NSEC2 record, and he can verify that it is signed by tld's ZSK, but he can't tell whether it proves the lack of a DS record. He simply has to assume that sld.tld is insecure. At his point Mallory can tamper with responses from Bob to Charlie with impunity. One fix would be to introduce a null DS record, which is semantically identical to having no DS record, and to require NSEC2 zones to include null DS recods for all insecure delegations. An NSEC1 resolver then can always verify a claim of an insecure delegation: either there will be an NSEC1 record proving the lack of DS record, or there will be a null DS record. -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 May 26 21:03: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 VAA04539 for ; Wed, 26 May 2004 21:03:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT9Go-00085i-UD for namedroppers-data@psg.com; Thu, 27 May 2004 01:01:18 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT9Gf-00083T-RG for namedroppers@ops.ietf.org; Thu, 27 May 2004 01:01:09 +0000 Received: from [192.168.1.13] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Wed, 26 May 2004 21:01:08 -0400 id 0013577A.40B53DD4.00002517 In-Reply-To: <16565.13104.363074.585875@giles.gnomon.org.uk> References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> <16564.39582.570457.670964@giles.gnomon.org.uk> <16565.6816.203820.50021@giles.gnomon.org.uk> <16565.13104.363074.585875@giles.gnomon.org.uk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4FA765FC-AF79-11D8-966F-000A95CC77E2@verisignlabs.com> Content-Transfer-Encoding: 7bit Cc: roy@dnss.ec, namedroppers@ops.ietf.org From: David Blacka Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Wed, 26 May 2004 21:00:56 -0400 To: Roy Badami X-Mailer: Apple Mail (2.613) 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 On May 26, 2004, at 8:15 PM, Roy Badami wrote: > To be more specific, here is what I'm talking about. > > Alice is an authoritive nameserver for tld. She uses NSEC2. > > Bob in an authoritive nameserver for sld.tld delegated from tld by > means of a DS record. (It doesn't matter whether he uses NSEC1 or > NSEC2.) > > Charlie is a security-aware resolver. However, he only understands > NSEC1. Then, to Charlie, tld is, for all intents and purposes, not secure. You can repeat this exercise with algorithms instead of different NSEC types: tld is signed by algorithm A, sld.tld is signed with B, Charlie only understands B... Except with NSEC2, it is possible that Charlie will be able to establish a chain of trust to sld.tld, if no one tampers with anything. Versioning DNSSEC, by its very nature, will fragment DNSSEC islands of security. That is not much of an issue if the fragmentation happens towards the leaf nodes, but, at the TLD level, it will force all clients to understand all of the versions in order to be useful. -- 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 Wed May 26 21:28: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 VAA05519 for ; Wed, 26 May 2004 21:28:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BT9cz-000B1R-Mc for namedroppers-data@psg.com; Thu, 27 May 2004 01:24:13 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT9cy-000B1C-Kl for namedroppers@ops.ietf.org; Thu, 27 May 2004 01:24:12 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4R1HxlZ046555 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 27 May 2004 01:18:01 GMT (envelope-from roy+dated+1088212743.131a9f@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4R1Hvso021988 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 27 May 2004 02:17:59 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4R1J3Fo001434 for ; Thu, 27 May 2004 02:19:03 +0100 (BST) (envelope-from roy+dated+1088212743.131a9f@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4R1J3eb001433 for namedroppers@ops.ietf.org; Thu, 27 May 2004 02:19:03 +0100 (BST) (envelope-from roy+dated+1088212743.131a9f@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 27 May 2004 02:19:01 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16565.16901.386808.336979@giles.gnomon.org.uk> Date: Thu, 27 May 2004 02:19:01 +0100 To: David Blacka Cc: Roy Badami , roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: <4FA765FC-AF79-11D8-966F-000A95CC77E2@verisignlabs.com> References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> <16564.39582.570457.670964@giles.gnomon.org.uk> <16565.6816.203820.50021@giles.gnomon.org.uk> <16565.13104.363074.585875@giles.gnomon.org.uk> <4FA765FC-AF79-11D8-966F-000A95CC77E2@verisignlabs.com> 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-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 >>>>> "David" == David Blacka writes: David> Then, to Charlie, tld is, for all intents and purposes, not David> secure. Not quite. All records in tld can be verified by Charlie, so tld is secure for some purposes. Obviously, authenticated denial is not available for RRsets in tld. But less obviously, all delegations from tld are insecure. This last point is fixable. David> You can repeat this exercise with algorithms instead of David> different NSEC types: tld is signed by algorithm A, sld.tld David> is signed with B, Charlie only understands B... David> Except with NSEC2, it is possible that Charlie will be able David> to establish a chain of trust to sld.tld, if no one tampers David> with anything. If the purpose of versioning is to allow later deployment of NSEC2, then it would be good to consider the implications of such a deployment strategy, and to consider fixing things that are fixable. As a domain holder in a ccTLD that will probably choose to deploy NSEC2 rather than NSEC, I don't much like the prospect that my delegation will not be secure for the installed base of DNSSEC resolvers. If that's the case, the cost of NSEC2 is too high... -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 May 26 22:08: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 WAA07567 for ; Wed, 26 May 2004 22:08:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTAGq-000I7q-5Y for namedroppers-data@psg.com; Thu, 27 May 2004 02:05:24 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTAGl-000I76-RS for namedroppers@ops.ietf.org; Thu, 27 May 2004 02:05:20 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id OAA30993; Thu, 27 May 2004 14:05:18 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i4R25Ifw068158; Thu, 27 May 2004 14:05:18 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: Alex Bligh From: don@plugh.daedalus.co.nz CC: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Your message of "Wed, 26 May 2004 09:57:44 +0100." <680967389.1085565464@[192.168.100.5]> Date: Thu, 27 May 2004 14:05:18 +1200 Message-ID: <68157.1085623518@toybsd.zl2tnm.gen.nz> 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 Alex Bligh wrote: >On a more theoretical level, what you are trying to do is introduce >small segments of the space "between" names that do not return useful >non-existence proof. That's exactly what I'm suggesting. > You want to make that space as small as possible >in order that non-existence proof works elsewhere. But that makes it >trivially easy to ask instead for a name outside that small space but >in the larger space before the next "real" name. Is that actually the case? Do we care about queries for domains that don't exist? Is there a problem with the following: a.example. NS ns1.isp.com. NS ns2.isp.com. DS ... RRSIG DS ... NSEC a_.example. NS DS RRSIG NSEC RRSIG NSEC .. b.example. NS ns1.isp.net. NS ns2.isp.net. NSEC b_.example. NS RRSIG NSEC RRSIG NSEC ... d.example. ... That is, if someone asks for foo.a.example with DNSSEC, they'll get a referral with a signed DS record; if they ask for foo.b.example, they'll get an referral with a signed NSEC record that securely marks the delegation as insecure. If they ask for foo.c.example, they'll get an NXDOMAIN. Which is what they'd have gut if DNSSEC wasn't in the picture. In essence, only the parts of the zone containing the live domains support authenticated denial; that is, from a registry's point of view, we don't really care about what happens to a domain that doesn't exist anyway, as long as we can give an authenticated "here is the DS record for this delegation", or an authenticated "this domain doesn't have a DS record". Is this a compromise that will work for TLD registries? Note that I'm really focusing on registry domains; these have fairly specific requirements (.museum notwithstanding). -- don -- to unsubscribe send a message to namedroppers-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 May 26 22:52: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 WAA09239 for ; Wed, 26 May 2004 22:52:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTAwt-000Nl0-3G for namedroppers-data@psg.com; Thu, 27 May 2004 02:48:51 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTAwr-000NkN-GA for namedroppers@ops.ietf.org; Thu, 27 May 2004 02:48:49 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 7AA8319B53A; Wed, 26 May 2004 22:44:53 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id CB67919B53A; Wed, 26 May 2004 22:44:52 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1695765; Wed, 26 May 2004 22:48:47 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <16563.49674.412883.793394@giles.gnomon.org.uk> References: <16563.49674.412883.793394@giles.gnomon.org.uk> Date: Wed, 26 May 2004 22:48:10 -0400 To: Roy Badami From: Edward Lewis Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Cc: Edward Lewis , 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.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk When I think on this topic there are a few assumptions I make. One is that record synthesis (aka wild cards) is an integral part of the protocol. It doesn't matter to me if a proposed solution has a problem domain that doesn't use record synthesis, the proposed solution must be compatible with the synthesis process. Two is that the DNS is a very constrained lookup service. Queries consist of three factors and three factors only as far as the data space is concerned. Flags can be used to turn on/request processing at the server, but the answers returned with special processing must be coherent at any DNS moment. Three is that the DNS is simple, a non-negotiated protocol. The client can't indicate that it understands certain processing schemes and the server can't tailor an answer to the querier's dialect. Because of these assumptions, when I see proposals that say "well, we don't want to use wild cards" I react negatively. Abstractly, this is like defining "A and !B" operations and "!A and B" operations. What happens when someone in the future tries to do "A and B" operations? Either we have to apply a lot of epoxy to define what happens when the erroneous "A and B" operations occur or we will have to be willing to see divergent implementations. I.e., corner cases will ensue. In the past I have tried to add a security options record to a zone, this proposal came out in summer 1999, just before the IETF in Oslo (to help fix the era in the memory of folks). One of the pitfalls of this is that the record becomes one more issue for inclusion in the non-answer section of a reply. I am off-line now so I can't find the dns-security archives, but I recall a message from John Gilmore rejecting the proposal "with prejudice" for another reason. (I recall because I had to ask him what that meant.) Here's the problem with having multiple approaches to negative answers, especially if they are not introduced simultaneously. NSEC-era resolvers will panic when seeing NSEC2 records - they will have no chance understanding the semantics. For example, let's say "com." uses NSEC2 and not NSEC. At all delegations to non-secured zones, a NSEC2 record will be used to prove the absence of a DS record. The proper response by a NSEC-era verifier to the lack of either a DS set or a NSEC demonstrating no DS set is an error, resulting in a service failure (SERVFAIL). It doesn't matter if we play a trick with key algorithms. The older NSEC-era resolvers will panic, unless we retool the error handling for that state. If we were able to include both NSEC and NSEC2 as workable solutions in one step, I think that would also be unwise. DNS isn't about choices, it's supposed to be a lightweight system. (Look at the relatively slow adoption of IPsec - too many knobs to turn and align right.) DNS isn't supposed to be a feature-rich service. (Remember the lessons from the A6 deprecation.) I'd rather see just one defined and the other forgotten. The WG has a technically sound set of documents pending promotion. The WG has also heard some concerns about new requirements that the current document set does not meet. The dilemma is that the WG represents the collective wisdom of DNS oriented engineers and that the new requirements are still seemingly incompletely defined in the WG's realm of expertise. (Meaning that TLD's in different legal jurisdictions have different requirement sets.) A solution to the question "how do we proceed" is for the WG to deliver the documents to the IETF and IESG. The broader community of the IETF, with guidance and expertise contacted by the IESG, will then have in their hands a sound approach to securing DNS within a given set of assumptions and requirements made by the WG. With a broader base of review, the perceived new requirements can be evaluated and judged and a determination can then be made the WG's documented solution is good enough or that the WG must go back to the chalk board and update the design. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 27 00:06: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 AAA12140 for ; Thu, 27 May 2004 00:06:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTC4x-0009aE-NP for namedroppers-data@psg.com; Thu, 27 May 2004 04:01:15 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTC4w-0009ZX-BX for namedroppers@ops.ietf.org; Thu, 27 May 2004 04:01:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B566813951 for ; Thu, 27 May 2004 04:01:13 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) In-Reply-To: Message from Edward Lewis of "Wed, 26 May 2004 22:48:10 -0400." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Thu, 27 May 2004 04:01:13 +0000 Message-Id: <20040527040113.B566813951@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 --=-=-= > From: Edward Lewis > ... > In the past I have tried to add a security options record to a zone, this > proposal came out in summer 1999, just before the IETF in Oslo (to help fix > the era in the memory of folks). One of the pitfalls of this is that the > record becomes one more issue for inclusion in the non-answer section of a > reply. I am off-line now so I can't find the dns-security archives, but I > recall a message from John Gilmore rejecting the proposal "with prejudice" > for another reason. (I recall because I had to ask him what that meant.) see attached. --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=912 Return-Path: owner-dns-security Delivery-Date: Mon Jun 28 04:52:36 1999 Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03187 Mon, 28 Jun 1999 04:50:12 -0400 (EDT) Message-Id: <199906280849.BAA18446@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Paul A Vixie cc: namedroppers@internic.net, dns-security@lists.tislabs.com, gnu@toad.com Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo In-reply-to: <199906261911.MAA08114@bb.rc.vix.com> Date: Mon, 28 Jun 1999 01:49:48 -0700 From: John Gilmore Sender: owner-dns-security@lists.tislabs.com Precedence: bulk MIME-Version: 1.0 > > 11. SECure-RR (5 minutes) Edward Lewis > > > i very much hope that john gilmore will be at the oslo meeting to defend his > point of view (that we can't deploy a new RR at this time if we're expecting > to use dnssec widely this year.) I won't be in Oslo, unfortunately. Hugh Daniel will be there, but he doesn't have the history. Deploying an RR type that only exists in superzones is not quite as bad as deploying one that exists everywhere. The number of superzones is smaller than the number of zones, and the most critical superzones (. and .com and etc) are running on machines that "nominally" always upgrade to the latest BIND anyway, so they'll be able to serve new RR types. Having scanned the draft once: Summary: REJECT WITH PREJUDICE. Poorly defined, unnecessarily complex, doesn't solve the problem it claims to, doesn't even address the real problems of DNSSEC. The biggest problem with DNSSEC appears to be paper designs that do not benefit from operational evolution. In other words, DNSSEC is not going through the winning part of the IETF process (draft, implement, try, redraft, implement, try, ... standardize). Instead we go through a series of paper specs trying to standardize them with no operational experience. Note I said operational, not programming. I suggest that we operate with the specs we have and learn from 'em. THEN change 'em. This paper design continues many of the problems of prior DNSSEC drafts; it lays out grand schemes without considering the operational details. The open-ended "Security parameters of a zone" is one example (including things like "Signature policy. This is an untested issue."). The draft goes to even more ridiculous lengths than NXT to secure negative answers. (NXT more than doubles the size of your zone, to give definitive "NO"s for names that aren't in the zone.) In addition to NXT, we now have a bitmap in the parent zone (!!!) that gives five options on how the child zone might handle negative answers. These options can be used in combination. (At least if the WG thinks this level of abomination is needed, it should be expressed in the child zone rather than in the parent. Such a record in the child would be signed by the zone key, so it can't be spoofed. Though I suppose its *absence* could be spoofed, hmm...) Then we get to the meat. The SEC record doesn't really have fields that specify security parameters. Instead it holds little sub-packets, each of which has to be parsed, each of which specifies security parameters. These sub-packets have option specifier bytes, optional lengths, and data. The length of most of the options is defined in the spec, so that when new options are added, all existing implementations will be unable to parse them. The draft specifies various combinations of options that are not permitted together. I don't see why we don't just go straight to X.509 and ASN.1 instead -- it's simpler and easier. The text file format is highly readable, consisting of a series of hex numbers. (At least the numbers are in hex; the DNSSEC KEY record has bit-flags expressed in decimal.) The parsing of the hex is screwy; some fields have 0x, some do not, and this difference appears to have some meaning, though it's not clear what meaning. The draft claims it's a successor to Zone Key Referral by me and Jerry Scharf. Did I really do that? It doesn't actually include the name of the Zone Key Referral draft, but elsewhere it says it's "by the same authors" (as itself, presumably). John --=-=-=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 27 00:06: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 AAA12169 for ; Thu, 27 May 2004 00:06:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTC7x-000AYW-Or for namedroppers-data@psg.com; Thu, 27 May 2004 04:04:21 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTC7x-000AY8-0d for namedroppers@ops.ietf.org; Thu, 27 May 2004 04:04:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C1AF9139A3 for ; Thu, 27 May 2004 04:04:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from don@plugh.daedalus.co.nz of "Thu, 27 May 2004 14:05:18 +1200." <68157.1085623518@toybsd.zl2tnm.gen.nz> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 27 May 2004 04:04:20 +0000 Message-Id: <20040527040420.C1AF9139A3@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 > ... > In essence, only the parts of the zone containing the live domains > support authenticated denial; that is, from a registry's point of view, > we don't really care about what happens to a domain that doesn't exist > anyway, as long as we can give an authenticated "here is the DS record > for this delegation", or an authenticated "this domain doesn't have a DS > record". this isn't practical. if the .org people did this, then isc.org would be subject to downgrade attacks wherein an attacker could insert unsecured responses into the transaction stream making folks believe that isc.org did not exist, and the querier would not be able to tell that it had been spoofed. i want both positive and negative responses about my parent domain to be signed and verifiable. > Is this a compromise that will work for TLD registries? i hope not. not for any registry of which i'd like to be a customer, anyway. -- to unsubscribe send a message to namedroppers-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 May 27 01:06: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 BAA14609 for ; Thu, 27 May 2004 01:06:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTD2f-000L8l-4j for namedroppers-data@psg.com; Thu, 27 May 2004 05:02:57 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTD2d-000L6i-L7 for namedroppers@ops.ietf.org; Thu, 27 May 2004 05:02:55 +0000 Received: from [192.168.1.13] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 27 May 2004 01:02:54 -0400 id 001358E1.40B5767E.0000565B In-Reply-To: <16565.16901.386808.336979@giles.gnomon.org.uk> References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> <16564.39582.570457.670964@giles.gnomon.org.uk> <16565.6816.203820.50021@giles.gnomon.org.uk> <16565.13104.363074.585875@giles.gnomon.org.uk> <4FA765FC-AF79-11D8-966F-000A95CC77E2@verisignlabs.com> <16565.16901.386808.336979@giles.gnomon.org.uk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <150C5601-AF9B-11D8-966F-000A95CC77E2@verisignlabs.com> Content-Transfer-Encoding: 7bit Cc: roy@dnss.ec, namedroppers@ops.ietf.org From: David Blacka Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 01:02:41 -0400 To: Roy Badami X-Mailer: Apple Mail (2.613) 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 May 26, 2004, at 9:19 PM, Roy Badami wrote: >>>>>> "David" == David Blacka writes: > > David> Then, to Charlie, tld is, for all intents and purposes, not > David> secure. > > Not quite. All records in tld can be verified by Charlie, so tld is > secure for some purposes. Obviously, authenticated denial is not > available for RRsets in tld. But less obviously, all delegations from > tld are insecure. This last point is fixable. It is possible that you are using a different set of assumptions than I am. I'm assuming that Charlie, when it doesn't understand NSEC2, operates under the current DNSSECbis specs. That assumption sort of rules out null DS records, I think. I make this assumption because if, for instance, Charlie would have to understand both NSEC and null DS, then it might as well understand NSEC2 as well. > David> You can repeat this exercise with algorithms instead of > David> different NSEC types: tld is signed by algorithm A, sld.tld > David> is signed with B, Charlie only understands B... > > David> Except with NSEC2, it is possible that Charlie will be able > David> to establish a chain of trust to sld.tld, if no one tampers > David> with anything. > > If the purpose of versioning is to allow later deployment of NSEC2, > then it would be good to consider the implications of such a > deployment strategy, and to consider fixing things that are fixable. I absolutely agree with this. However, even though we may now think we know what NSEC2 looks like, if we pursue this versioning path, we will have to assume that we do not actually know what future NSEC-like records will look like. That makes it pretty difficult to figure out how to compensate for it, I think. -- 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 Thu May 27 03: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 DAA06072 for ; Thu, 27 May 2004 03:53:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTFeG-000EZr-SH for namedroppers-data@psg.com; Thu, 27 May 2004 07:49:56 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTFeF-000EYb-Gb for namedroppers@ops.ietf.org; Thu, 27 May 2004 07:49:55 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id TAA32762 for ; Thu, 27 May 2004 19:49:54 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i4R7nsfw079571 for ; Thu, 27 May 2004 19:49:54 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org From: don@plugh.daedalus.co.nz Subject: Re: NSEC+ and NO In-Reply-To: Your message of "Thu, 27 May 2004 04:04:20 GMT." <20040527040420.C1AF9139A3@sa.vix.com> Date: Thu, 27 May 2004 19:49:54 +1200 Message-ID: <79570.1085644194@toybsd.zl2tnm.gen.nz> 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 Paul Vixie wrote: >this isn't practical. if the .org people did this, then isc.org would be >subject to downgrade attacks wherein an attacker could insert unsecured >responses into the transaction stream making folks believe that isc.org >did not exist, and the querier would not be able to tell that it had been >spoofed. i want both positive and negative responses about my parent domain >to be signed and verifiable. Can you explain to me the difference, from a security enabled resolver's point of view, between the following three cases: (1) A non security enabled name server returning NXDOMAIN for a name that doesn't exist; (2) A security enabled name server returning NXDOMAIN for a name that doesn't exist (but which would return signed data or an appropriately signed NSEC if the name did exist), as per my previous post; and (3) A man in the middle intercepting a request and responding to it with NXDOMAIN. -- don -- to unsubscribe send a message to namedroppers-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 May 27 05:25: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 FAA09900 for ; Thu, 27 May 2004 05:25:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTH5f-000C7m-7r for namedroppers-data@psg.com; Thu, 27 May 2004 09:22:19 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTH5d-000C7B-3K for namedroppers@ops.ietf.org; Thu, 27 May 2004 09:22:17 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4R9MElZ082958 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 27 May 2004 09:22:15 GMT (envelope-from roy+dated+1088241798.20a390@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4R9MBso024080 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 27 May 2004 10:22:13 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4R9NJ9v003932 for ; Thu, 27 May 2004 10:23:19 +0100 (BST) (envelope-from roy+dated+1088241798.20a390@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4R9NJi2003931 for namedroppers@ops.ietf.org; Thu, 27 May 2004 10:23:19 +0100 (BST) (envelope-from roy+dated+1088241798.20a390@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 27 May 2004 10:23:16 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16565.45956.205803.87821@giles.gnomon.org.uk> Date: Thu, 27 May 2004 10:23:16 +0100 To: David Blacka Cc: Roy Badami , roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: <150C5601-AF9B-11D8-966F-000A95CC77E2@verisignlabs.com> References: <16563.49674.412883.793394@giles.gnomon.org.uk> <16564.28474.714383.372054@giles.gnomon.org.uk> <16564.30227.3445.173997@giles.gnomon.org.uk> <16564.39582.570457.670964@giles.gnomon.org.uk> <16565.6816.203820.50021@giles.gnomon.org.uk> <16565.13104.363074.585875@giles.gnomon.org.uk> <4FA765FC-AF79-11D8-966F-000A95CC77E2@verisignlabs.com> <16565.16901.386808.336979@giles.gnomon.org.uk> <150C5601-AF9B-11D8-966F-000A95CC77E2@verisignlabs.com> 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-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 >>>>> "David" == David Blacka writes: David> It is possible that you are using a different set of David> assumptions than I am. I'm assuming that Charlie, when it David> doesn't understand NSEC2, operates under the current David> DNSSECbis specs. Possibly. I am assuming that DNSSECbis is modified so NSEC RRs contain a version field, which is set to 1 (say). I am also assuming that when a DNSSECbis resolver sees a response in which all the NSEC RRs have a version greater than 1 (and those RRs are correctly signed), it treats the response as insecure, rather than bogus. The question is, would this allow the subsequent introduction of a version 2 NSEC record in a relatively painless manner? I assert that the null DS record would make such introduction more painless. The main cost (increased zone size) is borne by those who want to use later versions of NSEC, though it does of course add a (small) additional complexity to DNSSECbis resolvers. David> I absolutely agree with this. However, even though we may David> now think we know what NSEC2 looks like, if we pursue this David> versioning path, we will have to assume that we do not David> actually know what future NSEC-like records will look like. David> That makes it pretty difficult to figure out how to David> compensate for it, I think. That's true. But null DS records don't rely on having any NSEC-like records at all. So it would seem to me that they can complensate for _any_ change to NSEC. -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 May 27 05:32: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 FAA10322 for ; Thu, 27 May 2004 05:32:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTHDM-000EIX-Uy for namedroppers-data@psg.com; Thu, 27 May 2004 09:30:16 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTHDL-000EHc-TN for namedroppers@ops.ietf.org; Thu, 27 May 2004 09:30:16 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BTHDJ-0003kX-87; Thu, 27 May 2004 11:30:13 +0200 In-Reply-To: <20040526220757.CE5C613951@sa.vix.com> To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Thu, 27 May 2004 11:30:11 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 27.05.2004 11:30:13, Serialize complete at 27.05.2004 11:30:13 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 > > Point taken. However, I think these TLDs aren't placing the zipped > > zone at everyone's disposal via anonymous FTP either. > > well, they ought to. In virtue of what? 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: From owner-namedroppers@ops.ietf.org Thu May 27 05:54: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 FAA11840 for ; Thu, 27 May 2004 05:54:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTHYS-000IVQ-CL for namedroppers-data@psg.com; Thu, 27 May 2004 09:52:04 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTHYQ-000IUv-OD for namedroppers@ops.ietf.org; Thu, 27 May 2004 09:52:02 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id E508EE7E96; Thu, 27 May 2004 10:52:01 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Message-Id: <20040527095201.E508EE7E96@mx1.nominet.org.uk> Date: Thu, 27 May 2004 10:52:01 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > but i guess every generation wants to learn that security through obscurity > is an illusion, the hard way. NSEC2 RRs are intended to prevent the zone from being _trivially_ elaborated. It's one thing to park a car unlocked with the keys in the ignition; it's another to park it in a garage, lock the doors, and remove the key. Also, NSEC2 uses strong encryption, so it isn't entirely justifiable to charactarise it as security through obscurity. 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: From owner-namedroppers@ops.ietf.org Thu May 27 07:44: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 HAA16570 for ; Thu, 27 May 2004 07:44:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTJEO-000EIt-Qk for namedroppers-data@psg.com; Thu, 27 May 2004 11:39:28 +0000 Received: from [193.176.144.164] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTJEM-000EHh-U7 for namedroppers@ops.ietf.org; Thu, 27 May 2004 11:39:27 +0000 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.11/8.12.11) with ESMTP id i4RBdPQF063545; Thu, 27 May 2004 13:39:25 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200405271139.i4RBdPQF063545@bartok.sidn.nl> To: IETF DNSEXT WG cc: Jakob Schlyter Subject: Re: NIC-SE statement regarding NSEC zone walking In-reply-to: Your message of Wed, 26 May 2004 16:52:56 +0200. Date: Thu, 27 May 2004 13:39:25 +0200 From: Jaap Akkerhuis 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 -- cut -- Date: Wed, 26 May 2004 16:17:59 +0200 From: Per-Olof Josefsson NIC-SE does not consider NXT zone-walking a problem for DNSSEC deployment within the .se-zone. We consider all data in the DNS to be public information, both as single records and as a collection. The data we actually need to protect is served by WHOIS and protecting this data should be done by the protocol serving it, not by DNS itself. Just in case that it wasn't clear from my earlier mai. This is the position of SIDN as well for the nl-zone. jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 27 07:46: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 HAA17066 for ; Thu, 27 May 2004 07:46:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTJIp-000F6f-WA for namedroppers-data@psg.com; Thu, 27 May 2004 11:44:03 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTJIo-000F6C-JB for namedroppers@ops.ietf.org; Thu, 27 May 2004 11:44:02 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id E22694FE0B; Thu, 27 May 2004 13:44:01 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 2C88D4FC7B for ; Thu, 27 May 2004 13:44:01 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i4RBi1Q2020681 for ; Thu, 27 May 2004 13:44:01 +0200 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i4RBi19J024372 for namedroppers@ops.ietf.org; Thu, 27 May 2004 13:44:01 +0200 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSu5o-0006BH-8X for namedroppers@ops.ietf.org; Wed, 26 May 2004 08:48:56 +0000 Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id AA106E7EB8 for ; Wed, 26 May 2004 09:48:55 +0100 (BST) To: namedroppers@ops.ietf.org Cc: geoff@nominet.org.uk Subject: Confirming the Nominet position MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Jay Daley" Date: Wed, 26 May 2004 09:48:34 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 05/26/2004 09:48:56 AM, Serialize complete at 05/26/2004 09:48:56 AM Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Status: U 0.499857 / 0.0 / 0.0 / disabled X-RIPE-Signature: 1358e35dc2f60ff60f0b41c892ad960d 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 Content-Transfer-Encoding: quoted-printable Two things =20 1. Late new comers The criticism levelled about "late new comers" is well founded and I'm=20 sorry that is the case. This is something we should have raised some time = ago. Recognising that we were late with this we did try to avoid just=20 unproductive foot stamping by the development of the NSEC2 draft as a=20 positive alternative. We are now committed to the process and we will be=20 here to stay. As evidence of this I should make clear that our next steps = will be to write NSEC2 patches for BIND and if possible NSD to allow=20 proper interoperability testing. Ideally we would like NSEC2 to go forward properly now but I understand=20 very well that this causes significant problems for many in this WG. So=20 we would be quite happy with a mechanism that allowed NSEC2 to be=20 introduced later in a backwards compatible fashion, such as the previosuly = suggestion version field for NSEC. 2. Legal mumbo jumbo I'm sorry if we appear to have been hiding behind legal mumbo jumbo, this=20 was not our intention. So I need to be clear that zone file enumeration=20 is a show-stopper for us that will prevent us from fully implementing=20 DNSSEC and our legal advice is ancillary to that not the determining=20 factor. So if DNSSEC stays in its current form then we will have to make=20 a local determination about how/what we implement, which is still to be=20 decided. However, for those of you that have asked, this is the gist of our legal=20 advice... As compilations, zone file databases are protected under EU law by=20 ?Database Right?. As a derivative work of the main register from which=20 they are sourced, they are likely also to attract copyright protection in=20 addition to or in place of database right. Both database right and copyright are negative rights in that they=20 prohibit certain acts (primarily, copying the whole or a substantial part=20 of the materials) but do not grant positive rights (unlike, for example, a = patent, which grants a monopoly on the material involved). Database right=20 is unique to countries which implement European Community law, but=20 copyright is more universal.=20 If legal rights would be infringed with copying, then is it not better to=20 allow the copying, and then rely on the law to assist against any=20 infringers. The short answer is ?no?, and here the analogy of locking=20 one?s house or car despite laws against burglary and theft may be helpful. = Prevention is not always better than cure, if one is led to make an=20 overly restrictive solution in order to prevent a minor risk. However, if = the risk of harm is major, and is highly likely to take place, and will be = expensive and difficult to put right after the event, then in those=20 circumstances, prevention is very definitely better than cure. The problem with both copyright and database right arises with=20 enforcement, particularly in respect of electronic data such as a zone=20 file. Firstly it can be hard to identify whether a data mining event has=20 taken place, in the context of the high volume of traffic affecting the=20 nameservers on a day to day basis. If a technical department cannot show=20 this, there is nothing that a legal department can do. Even if it is clear = that it is happening, the technical department may not be able to trace=20 who has done it, because the use of multiple proxies can make it=20 impossible (or prohibitively expensive) to find it. Even if this can be=20 done, the person(s) involved may be abroad. If they are in a difficult=20 jurisdiction (even including eastern Europe, which is part of the EU) the=20 differences in language and legal systems add to the expense and=20 complexity of pursuing legal proceedings.=20 Jay -- to unsubscribe send a message to namedroppers-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 May 27 07:59: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 HAA18318 for ; Thu, 27 May 2004 07:59:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTJVN-000Hsl-Mi for namedroppers-data@psg.com; Thu, 27 May 2004 11:57:01 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTJVK-000Hr0-5X for namedroppers@ops.ietf.org; Thu, 27 May 2004 11:56:58 +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 i4RBuudW002401 for ; Thu, 27 May 2004 13:56:57 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i4RBuub00497 for ; Thu, 27 May 2004 13:56:56 +0200 (MEST) Message-Id: <200405271156.i4RBuub00497@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: NSEC+ and NO In-reply-to: Your message of "Thu, 27 May 2004 14:05:18 +1200." <68157.1085623518@toybsd.zl2tnm.gen.nz> 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: <493.1085659015.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Thu, 27 May 2004 13:56:55 +0200 From: Peter Koch 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 don@plugh.daedalus.co.nz wrote: > That is, if someone asks for foo.a.example with DNSSEC, they'll get a > referral with a signed DS record; if they ask for foo.b.example, they'll > get an referral with a signed NSEC record that securely marks the > delegation as insecure. > > If they ask for foo.c.example, they'll get an NXDOMAIN. Which is what > they'd have gut if DNSSEC wasn't in the picture. If I got that right you're in essence suggesting that the "pointer part" of the NSEC RR be optional. Instead of having it point "somewhere", I'd use the target for explicit signalling of this feature, e.g. let it point to the root domain (yes, that would make a problem in ".") or the owner name itself (which makes problems in "empty" zones) or abuse the NSEC 'bit' in the RR list. However, this would open *all* delegated domains, whether secure or not, to a DoS because someone could intercept an answer and substitute the referral by an NXDOMAIN response. Since those are unprotected under this scheme, there's no way to tell whether or not the delegation really exists (the answer would have to carry some witnessing of the "NSEC doesn't use pointer" feature, e.g. per the NSEC of the zone [*]) But, since SERVFAIL or REFUSED could always be spoofed (although usually not cached), there is already a risk of DoS even with authenticated denial. The quality of both attacks is different (I just cannot reach, say, a webserver or I may be made to believe a whole organisation ceased to exist - or at least lost their domain name) but the quality of this difference could be and even may have been discussed. The 'threats' draft and the DNSSEC docset don't discuss this kind of "negative" response (and I'm not sure they should). -Peter [*] As was said earlier in this thread, these "per zone" features have their own difficulties because you don't necessarily know the enclosing zone, so a delegation could be deeper inside a zone than one level, e.g. "sub.sub.example" in "example", but per this feature it could be required to use one-sublevel-only delegations. -- to unsubscribe send a message to namedroppers-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 May 27 08:05: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 IAA18839 for ; Thu, 27 May 2004 08:05:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTJbm-000JWx-E0 for namedroppers-data@psg.com; Thu, 27 May 2004 12:03:38 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTJbi-000JVm-VL for namedroppers@ops.ietf.org; Thu, 27 May 2004 12:03:35 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 472165DD47; Thu, 27 May 2004 14:03:34 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 48C5F5DD34 for ; Thu, 27 May 2004 14:03:31 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i4RC3TQ2028229 for ; Thu, 27 May 2004 14:03:29 +0200 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i4RC3TDn025386 for namedroppers@ops.ietf.org; Thu, 27 May 2004 14:03:29 +0200 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BT0DI-000Fvp-R6 for namedroppers@ops.ietf.org; Wed, 26 May 2004 15:21:05 +0000 Received: from wds1.nominet.org.uk (notes1.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id EB119E7E9F for ; Wed, 26 May 2004 16:21:03 +0100 (BST) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Cc: geoff@nominet.org.uk Subject: Confirming the Nominet position X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Jay Daley" Date: Wed, 26 May 2004 16:21:02 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 05/26/2004 04:21:03 PM, Serialize complete at 05/26/2004 04:21:03 PM Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Status: U 0.498392 / 0.0 / 0.0 / disabled X-RIPE-Signature: 43cd0e6e0f2d3d7a2608c4d7076636ba 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 Content-Transfer-Encoding: quoted-printable Here is a proper explanation of the Nominet position. 1. Showstopper Zone file enumeration is a show-stopper for us that will prevent us from=20 fully implementing DNSSEC. So if DNSSEC stays in its current form then we=20 will have to make a local determination about how/what we implement, which = is still to be decided. Our reason for this is our view of what is the=20 appropriate policy to act in the best interests of our local community,=20 which for some time has been to deny access to our zone files.=20 =20 2. Late new comers The criticism levelled about "late new comers" is well founded and I'm=20 sorry that is the case. This is something we should have raised some time = ago. Recognising that we were late with this we did try to avoid just=20 unproductive foot stamping by the development of the NSEC2 draft as a=20 positive alternative. We are now committed to the process and we will be=20 here to stay. As evidence of this I should make clear that our next steps = will be to get NSEC2 patches written for BIND and if possible NSD to allow = proper interoperability testing. 3. Way ahead Ideally we would like NSEC2 to go forward properly, but I understand very=20 well that this causes significant problems for many in this WG. So we=20 would be quite happy with a mechanism that allowed NSEC2 to be introduced=20 later in a backwards compatible fashion, such as the previously suggested=20 version field for NSEC. 3. Legal mumbo jumbo I'm sorry if we appear to have been hiding behind legal mumbo jumbo, this=20 was not our intention. So I need to be clear that our legal advice is=20 ancillary to our view in (1) above, not the determining factor.=20 However, for those of you that have asked, this is the gist of our legal=20 advice... As compilations, zone file databases are protected under EU law by=20 ?Database Right?. As a derivative work of the main register from which=20 they are sourced, they are likely also to attract copyright protection in=20 addition to or in place of database right. Both database right and copyright are negative rights in that they=20 prohibit certain acts (primarily, copying the whole or a substantial part=20 of the materials) but do not grant positive rights (unlike, for example, a = patent, which grants a monopoly on the material involved). Database right=20 is unique to countries which implement European Community law, but=20 copyright is more universal.=20 If legal rights would be infringed with copying, then is it not better to=20 allow the copying, and then rely on the law to assist against any=20 infringers? The short answer is ?no?, and here the analogy of locking=20 one?s house or car despite laws against burglary and theft may be helpful. = Prevention is not always better than cure, if one is led to make an=20 overly restrictive solution in order to prevent a minor risk. However, if = the risk of harm is major, and is highly likely to take place, and will be = expensive and difficult to put right after the event, then in those=20 circumstances, prevention is very definitely better than cure. The problem with both copyright and database right arises with=20 enforcement, particularly in respect of electronic data such as a zone=20 file. Firstly it can be hard to identify whether a data mining event has=20 taken place, in the context of the high volume of traffic affecting the=20 nameservers on a day to day basis. If a technical department cannot show=20 this, there is nothing that a legal department can do. Even if it is clear = that it is happening, the technical department may not be able to trace=20 who has done it, because the use of multiple proxies can make it=20 impossible (or prohibitively expensive) to find it. Even if this can be=20 done, the person(s) involved may be abroad. If they are in a difficult=20 jurisdiction (even including eastern Europe, which is part of the EU) the=20 differences in language and legal systems add to the expense and=20 complexity of pursuing legal proceedings.=20 Jay -- to unsubscribe send a message to namedroppers-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 May 27 09:54: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 JAA25681 for ; Thu, 27 May 2004 09:54:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTLH8-000BJj-VS for namedroppers-data@psg.com; Thu, 27 May 2004 13:50:26 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTLH3-000BI5-D2 for namedroppers@ops.ietf.org; Thu, 27 May 2004 13:50:21 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id C921DE7EF2; Thu, 27 May 2004 14:50:20 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: More on NSEC2 label size and DoS References: Message-Id: <20040527135020.C921DE7EF2@mx1.nominet.org.uk> Date: Thu, 27 May 2004 14:50:20 +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 roy@dnss.ec writes: > Okay, the problem is not e164 but ip6.arpa: > > 9.1.1.0.6.0.1.0.7.8.0.0.2.9.1.0.a.0.0.8.1.0.0.0.0.1.6.0.1.0.0.2.ip6.arpa. > > Remember, at _each_ intermediate label level including empty non-terminals > (in the above example there are 35 labels) a NSEC (or EXIST) is needed for > every occuring value at that label. This is a good argument for NSEC2 as an _alternative_ to NSEC rather than as a replacement. It's probably undesirable to secure zones in {in-addr,ip6,e164}.arpa using NSEC2 RRs, especially as the namespace of domains in these zones is dramatically smaller. 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: From owner-namedroppers@ops.ietf.org Thu May 27 09:56: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 JAA25740 for ; Thu, 27 May 2004 09:56:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTLLC-000CFX-4V for namedroppers-data@psg.com; Thu, 27 May 2004 13:54:38 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTLL7-000CEX-AM for namedroppers@ops.ietf.org; Thu, 27 May 2004 13:54:33 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4RDsQW4010984; Thu, 27 May 2004 13:54:26 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4RDsQ6J010981; Thu, 27 May 2004 13:54:26 GMT Date: Thu, 27 May 2004 13:54:25 +0000 From: bmanning@vacation.karoshi.com To: Jay Daley Cc: namedroppers@ops.ietf.org, geoff@nominet.org.uk Subject: Re: Confirming the Nominet position Message-ID: <20040527135425.GA10971@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.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 > The problem with both copyright and database right arises with > enforcement, particularly in respect of electronic data such as a zone > file. Firstly it can be hard to identify whether a data mining event has > taken place, in the context of the high volume of traffic affecting the > nameservers on a day to day basis. If a technical department cannot show > this, there is nothing that a legal department can do. Even if it is clear > that it is happening, the technical department may not be able to trace > who has done it, because the use of multiple proxies can make it > impossible (or prohibitively expensive) to find it. Even if this can be > done, the person(s) involved may be abroad. If they are in a difficult > jurisdiction (even including eastern Europe, which is part of the EU) the > differences in language and legal systems add to the expense and > complexity of pursuing legal proceedings. to make it easier to track, would "watermarking" the database be helpful? > Jay --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 Thu May 27 10:05: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 KAA26440 for ; Thu, 27 May 2004 10:05:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTLSV-000EBl-Ia for namedroppers-data@psg.com; Thu, 27 May 2004 14:02:11 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTLSM-000E9R-DO for namedroppers@ops.ietf.org; Thu, 27 May 2004 14:02:02 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4RE20W4011009; Thu, 27 May 2004 14:02:00 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4RE20m9011006; Thu, 27 May 2004 14:02:00 GMT Date: Thu, 27 May 2004 14:02:00 +0000 From: bmanning@vacation.karoshi.com To: Geoffrey Sisson Cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Message-ID: <20040527140200.GB10971@vacation.karoshi.com.> References: <20040527095201.E508EE7E96@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527095201.E508EE7E96@mx1.nominet.org.uk> 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 > Paul Vixie writes: > > but i guess every generation wants to learn that security through obscurity > > is an illusion, the hard way. > > Also, NSEC2 uses strong encryption, so it isn't entirely justifiable to > charactarise it as security through obscurity. > > Geoff DNS use of "strong encryption" is not to provide confidentiality. We're not hiding anything here. We're providing integrity. --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 Thu May 27 10:09: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 KAA26839 for ; Thu, 27 May 2004 10:09:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTLWe-000Ewy-3D for namedroppers-data@psg.com; Thu, 27 May 2004 14:06:28 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTLWN-000EtL-IL for namedroppers@ops.ietf.org; Thu, 27 May 2004 14:06:11 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2E25913951 for ; Thu, 27 May 2004 14:06:11 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from don@plugh.daedalus.co.nz of "Thu, 27 May 2004 19:49:54 +1200." <79570.1085644194@toybsd.zl2tnm.gen.nz> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 27 May 2004 14:06:11 +0000 Message-Id: <20040527140611.2E25913951@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 > Paul Vixie wrote: > > ... > > Can you explain to me the difference, from a security enabled resolver's > point of view, between the following three cases: > > (1) A non security enabled name server returning NXDOMAIN for a name > that doesn't exist; > > (2) A security enabled name server returning NXDOMAIN for a name that > doesn't exist (but which would return signed data or an appropriately > signed NSEC if the name did exist), as per my previous post; and > > (3) A man in the middle intercepting a request and responding to it with > NXDOMAIN. assuming that case (2) does not include an NSEC covering the query name, then among those three there is no visible difference from a validator's point of view. however, there's a fourth case, which i'm interested in: (4) A secure negative response including a covering NSEC, signed with the zone's key, indicating the nonexistence of the name. if a validator has a reason to expect security, such as a static trusted-key for the zone or a parent DS learned during delegation, then cases (1), (2) and (3) would all be treated as a possible instance of (3), and only case (4) would be taken seriously or considered to be useful for subsequent processing (such as giving up on the forwarding of email to that domain, or giving up on contacting a jabber server at that domain, or whatever.) in your previous post you proposed a signalling method that would make us treat all negative responses as temporary failures. that's not a value add. -- to unsubscribe send a message to namedroppers-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 May 27 10:20: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 KAA27962 for ; Thu, 27 May 2004 10:20:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTLi3-000GrP-UP for namedroppers-data@psg.com; Thu, 27 May 2004 14:18:15 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTLhg-000Glq-F6 for namedroppers@ops.ietf.org; Thu, 27 May 2004 14:17:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1D7A713960 for ; Thu, 27 May 2004 14:17:52 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: Message from Marcos Sanz/Denic of "Thu, 27 May 2004 11:30:11 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 27 May 2004 14:17:52 +0000 Message-Id: <20040527141752.1D7A713960@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 > > > Point taken. However, I think these TLDs aren't placing the zipped > > > zone at everyone's disposal via anonymous FTP either. > > > > well, they ought to. > > In virtue of what? having NS RRs in the root zone which give rise to a top level domain is a public benefit activity. not just the subset of the public who wants to register SLDs there, but the entire public -- everybody everywhere. all of the people who decide to respect the trust deed. everyone who recognizes the property lines. and these people have a right to know what you're doing with the property that is only under your control because of their good will. maybe they want to count the names, maybe they want to run a web crawler over them, maybe they want to be able to complain if their trademarks are being used by other people. specific motives don't matter. anyone who wants secrecy for thirdlevel names can have it. and anyone whose business requirements include name secrecy can use a thirdlevel name. but asking for SLD naming secrecy (by preventing TLD enumeration) is like saying "i want you to give my container ship safe passage through international waters, but it may or may not be loaded with drugs, plutonium, or whatever." you can have one, or you can have the other, but the public should not have to grant -- and historically, will not grant -- both. -- to unsubscribe send a message to namedroppers-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 May 27 10:55: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 KAA00225 for ; Thu, 27 May 2004 10:55:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTMEx-000N92-UV for namedroppers-data@psg.com; Thu, 27 May 2004 14:52:15 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTMCz-000Mp9-AX for namedroppers@ops.ietf.org; Thu, 27 May 2004 14:50:13 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BTMCu-0004cc-00 for ; Thu, 27 May 2004 16:50:12 +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 ; Thu, 27 May 2004 16:50:08 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 May 2004 16:50:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Thu, 27 May 2004 16:49:58 +0200 Lines: 30 Message-ID: References: <20040527141752.1D7A713960@sa.vix.com> 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:2uQIUo0g11aVFl83TvTzw//Yrg8= 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 Paul Vixie writes: >> > > Point taken. However, I think these TLDs aren't placing the zipped >> > > zone at everyone's disposal via anonymous FTP either. >> > >> > well, they ought to. >> >> In virtue of what? > > having NS RRs in the root zone which give rise to a top level domain is > a public benefit activity. not just the subset of the public who wants > to register SLDs there, but the entire public -- everybody everywhere. > all of the people who decide to respect the trust deed. everyone who > recognizes the property lines. > > and these people have a right to know what you're doing with the property > that is only under your control because of their good will. maybe they > want to count the names, maybe they want to run a web crawler over them, > maybe they want to be able to complain if their trademarks are being used > by other people. specific motives don't matter. Well spoken, I couldn't agree more. I find it puzzling that some TLDs, even those stating they have no problem with NXT/NSEC walking, have been restricting zone access. Perhaps this WG should simply acknowledge that organizations running TLDs will never agree on policy issues. Regards, 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 Thu May 27 11:05: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 LAA01093 for ; Thu, 27 May 2004 11:05:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTMNc-000Oqm-2c for namedroppers-data@psg.com; Thu, 27 May 2004 15:01:12 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTMND-000Ojh-6C for namedroppers@ops.ietf.org; Thu, 27 May 2004 15:00:47 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 6FE7E19B633; Thu, 27 May 2004 10:56:42 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id EED1019B5AA; Thu, 27 May 2004 10:56:41 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1697855; Thu, 27 May 2004 11:00:46 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 27 May 2004 10:59:59 -0400 To: "Jay Daley" From: Edward Lewis Subject: Re: Confirming the Nominet position Cc: namedroppers@ops.ietf.org, geoff@nominet.org.uk 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.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:24 +0100 5/26/04, Jay Daley wrote: >Here is a proper explanation of the Nominet position. > >3. Legal mumbo jumbo >I'm sorry if we appear to have been hiding behind legal mumbo jumbo, this >was not our intention. So I need to be clear that our legal advice is >ancillary to our view in (1) above, not the determining factor. In preparing this response I didn't see in #1 a reason that was *clearly* technically based. I.e., I suspect that "appropriate policy...best interests" is based in issues that are not technical. So perhaps what I have to say here isn't the "right" answer. I'm at sea the moment someone brings up anything relating to legal issues. Given the conflicting statements about legal opinions on this list, I'd ask for the lawyers to get together and come to some common understanding first. After that - it can become a technical problem again. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 27 11:28: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 LAA02395 for ; Thu, 27 May 2004 11:28:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTMkR-0002tt-Tz for namedroppers-data@psg.com; Thu, 27 May 2004 15:24:47 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTMkD-0002s1-6N for namedroppers@ops.ietf.org; Thu, 27 May 2004 15:24:33 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 5E0DDE7EF2; Thu, 27 May 2004 16:24:32 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: References: Message-Id: <20040527152432.5E0DDE7EF2@mx1.nominet.org.uk> Date: Thu, 27 May 2004 16:24:32 +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 Edward Lewis writes: > Given the conflicting statements about legal opinions on > this list, I'd ask for the lawyers to get together and come to some > common understanding first. After that - it can become a technical > problem again. A common legal understanding covering all potential DNSSEC users is unlikely. It seems almost certain that there will be operators that will deploy DNSSECbis regardless of impact of NSEC RR traversal, and operators that cannot deploy because of it. These divergent requirements deliniate the scope of the technical problem. 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: From owner-namedroppers@ops.ietf.org Thu May 27 11:40: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 LAA03056 for ; Thu, 27 May 2004 11:40:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTMx1-0004mp-1h for namedroppers-data@psg.com; Thu, 27 May 2004 15:37:47 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTMwl-0004jD-C3 for namedroppers@ops.ietf.org; Thu, 27 May 2004 15:37:31 +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 i4RFbArd005309; Thu, 27 May 2004 16:37:10 +0100 (BST) To: Simon Josefsson cc: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: Message from Simon Josefsson of "Thu, 27 May 2004 16:49:58 +0200." Date: Thu, 27 May 2004 16:37:10 +0100 Message-ID: <5308.1085672230@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Simon" == Simon Josefsson writes: Simon> Well spoken, I couldn't agree more. I find it puzzling Simon> that some TLDs, even those stating they have no problem Simon> with NXT/NSEC walking, have been restricting zone access. Why? There are perfectly good operational reasons for that. Like not wanting their name servers burdened with large numbers of long-lived TCP connections. Some may even be running DNS software that doesn't *implement* AXFR. Simon> Perhaps this WG should simply acknowledge that Simon> organizations running TLDs will never agree on policy Simon> issues. Apart from the obvious universal truths, that's a given. Around the world there are too many different (mutually exclusive?) laws on stuff like data protection, privacy, crypto, consumer protection, monopolies and so on. Reconciling these is impossible. It would be foolish to even try. -- to unsubscribe send a message to namedroppers-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 May 27 11:46: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 LAA03458 for ; Thu, 27 May 2004 11:46:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTN2E-0005kF-FS for namedroppers-data@psg.com; Thu, 27 May 2004 15:43:10 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTN26-0005ii-AF for namedroppers@ops.ietf.org; Thu, 27 May 2004 15:43:02 +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 i4RFh0rd005319; Thu, 27 May 2004 16:43:00 +0100 (BST) To: geoff@nominet.org.uk (Geoffrey Sisson) cc: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Thu, 27 May 2004 16:24:32 BST." <20040527152432.5E0DDE7EF2@mx1.nominet.org.uk> Date: Thu, 27 May 2004 16:43:00 +0100 Message-ID: <5318.1085672580@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Geoffrey" == Geoffrey Sisson writes: Geoffrey> A common legal understanding covering all potential Geoffrey> DNSSEC users is unlikely. It seems almost certain that Geoffrey> there will be operators that will deploy DNSSECbis Geoffrey> regardless of impact of NSEC RR traversal, and operators Geoffrey> that cannot deploy because of it. These divergent Geoffrey> requirements deliniate the scope of the technical Geoffrey> problem. If an operator's reasons for not deploying DNSSECbis are policy ones, how can this be a technical problem? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 27 11:58: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 LAA04402 for ; Thu, 27 May 2004 11:58:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTNDm-0007pl-Vt for namedroppers-data@psg.com; Thu, 27 May 2004 15:55:06 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTNDQ-0007mE-Eu for namedroppers@ops.ietf.org; Thu, 27 May 2004 15:54:44 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 2E65F19B663; Thu, 27 May 2004 11:50:39 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 9DC0C19B663 for ; Thu, 27 May 2004 11:50:38 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1698085; Thu, 27 May 2004 11:54:43 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <20040527141752.1D7A713960@sa.vix.com> Date: Thu, 27 May 2004 11:54:41 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Cc: edlewis@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.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:49 +0200 5/27/04, Simon Josefsson wrote: >Perhaps this WG should simply acknowledge that organizations running >TLDs will never agree on policy issues. This WG is supposed to be focusing on the protocol issues of the DNS and not on operational policy choices. The goal is inter-operable specifications. For the sake of the protocol and the applications relying on it we need to have just one approach to authenticated denial of existence. (The approach may be "not at all", NXT, NSEC, NSEC2, signing the responses.) Allowing for alternate approaches means that applications will have to bear the burden of understanding how the DNS went about it's business. The IETF way has been to engineer without regard to legal restrictions - that was the mantra in the says when cryptography was a large concern. We do want the specs to be as widely usable as possible, but technical soundness is more important to compliance with legal opinions. The last sounds absurd - but what good is a legally compliant specification that does not work? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 27 12:22: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 MAA05800 for ; Thu, 27 May 2004 12:22:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTNaI-000DYy-FN for namedroppers-data@psg.com; Thu, 27 May 2004 16:18:22 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTNZn-000DOp-2P for namedroppers@ops.ietf.org; Thu, 27 May 2004 16:17:51 +0000 Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id AD4CAE8085; Thu, 27 May 2004 17:17:49 +0100 (BST) In-Reply-To: <5318.1085672580@gromit.rfc1035.com> To: Jim Reid Cc: geoff@nominet.org.uk (Geoffrey Sisson), namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Jay Daley" Date: Thu, 27 May 2004 17:00:28 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 05/27/2004 05:17:51 PM, Serialize complete at 05/27/2004 05:17:51 PM 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 Jim > If an operator's reasons for not deploying DNSSECbis are policy ones, > how can this be a technical problem? How does it sit with you if a technical change forces an operator into changing their policy? Are you saying that by default the policy must have been wrong in the first place? Jay -- to unsubscribe send a message to namedroppers-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 May 27 12:42: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 MAA06951 for ; Thu, 27 May 2004 12:42:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTNv2-000J24-Ry for namedroppers-data@psg.com; Thu, 27 May 2004 16:39:48 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTNuK-000Ivp-Mv for namedroppers@ops.ietf.org; Thu, 27 May 2004 16:39:04 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8069F13951 for ; Thu, 27 May 2004 16:39:04 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: Message from "Jay Daley" of "Thu, 27 May 2004 17:00:28 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 27 May 2004 16:39:04 +0000 Message-Id: <20040527163904.8069F13951@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 > > If an operator's reasons for not deploying DNSSECbis are policy ones, > > how can this be a technical problem? > > How does it sit with you if a technical change forces an operator into > changing their policy? Are you saying that by default the policy must have > been wrong in the first place? "wrong" is such a strong word. "not the way dns was intended to work" and "placing new requirements on dns, without standardization" are more to the point. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 27 12:57: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 MAA08765 for ; Thu, 27 May 2004 12:57:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTO7Y-000L25-AU for namedroppers-data@psg.com; Thu, 27 May 2004 16:52:44 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTO7M-000L02-7m for namedroppers@ops.ietf.org; Thu, 27 May 2004 16:52:32 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4RGqUW4011349; Thu, 27 May 2004 16:52:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4RGqUO2011346; Thu, 27 May 2004 16:52:30 GMT Date: Thu, 27 May 2004 16:52:30 +0000 From: bmanning@vacation.karoshi.com To: Jay Daley Cc: Jim Reid , Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position Message-ID: <20040527165230.GA11286@vacation.karoshi.com.> References: <5318.1085672580@gromit.rfc1035.com> 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.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 Thu, May 27, 2004 at 05:00:28PM +0100, Jay Daley wrote: > Jim > > If an operator's reasons for not deploying DNSSECbis are policy ones, > > how can this be a technical problem? > > How does it sit with you if a technical change forces an operator into > changing their policy? Are you saying that by default the policy must have > been wrong in the first place? > > Jay Jay, w/o getting into the merits of any given policy, it seems that the crux of the debate seems to be a tussle between what it technically possible and politically desirable. This particular tussle has occured many times in the past. One of my favorites is: http://www.straightdope.com/classics/a3_341.html That aside, I suspect that -IF- one were to waive some of the fundamental design principles of the DNS and DNSSEC, it would be possible to design a technical solution to your particular policy drivers. I would not expect that technical solution to be useful to many/most others. As such, it would seem to inhibit broad use in an Internet-wide context. But I could be wrong. --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 Thu May 27 12:57: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 MAA08784 for ; Thu, 27 May 2004 12:57:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTO8v-000LHl-F9 for namedroppers-data@psg.com; Thu, 27 May 2004 16:54:09 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTO8U-000LCF-AL for namedroppers@ops.ietf.org; Thu, 27 May 2004 16:53:42 +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 i4RGrerd005532; Thu, 27 May 2004 17:53:40 +0100 (BST) To: "Jay Daley" cc: geoff@nominet.org.uk (Geoffrey Sisson), namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: Message from "Jay Daley" of "Thu, 27 May 2004 17:00:28 BST." Date: Thu, 27 May 2004 17:53:40 +0100 Message-ID: <5531.1085676820@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Jay" == Jay Daley writes: Jay> How does it sit with you if a technical change forces an Jay> operator into changing their policy? It depends on the technical change and the policy. If we're talking specifically about a policy which sets out to prevent or thwart zone enumeration, yes, I do think that policy needs to be reviewed. Lots of other technical changes to the DNS -- IDN, IPv6, ENUM, etc -- are likely to mean policy changes for operators. In some cases, these changes will mean policies have to be created. The deployment of DNSSEC will be no different in that respect. As the saying goes, you can't make an omelette without breaking eggs. If anything DNSSEC is going to demand new and/or changed operator policies because of stuff like key handling and so on. Jay> Are you saying that by default the policy must have been Jay> wrong in the first place? Not necessarily. The policy may well have been right for its time. But when circumstances change, policies might have to change too. Even if those policies were right. Or wrong as the case may be. This thread is getting somewhat off-topic for 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: From owner-namedroppers@ops.ietf.org Thu May 27 13:20: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 NAA10153 for ; Thu, 27 May 2004 13:20:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTOU2-000PTZ-GO for namedroppers-data@psg.com; Thu, 27 May 2004 17:15:58 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTOTj-000PR5-OE for namedroppers@ops.ietf.org; Thu, 27 May 2004 17:15:39 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BTOTi-00004q-00 for ; Thu, 27 May 2004 19:15:38 +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 ; Thu, 27 May 2004 19:15:38 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 May 2004 19:15:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 19:15:34 +0200 Lines: 20 Message-ID: References: <20040527152432.5E0DDE7EF2@mx1.nominet.org.uk> <5318.1085672580@gromit.rfc1035.com> 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:ZtSsHJioVtKiSsc4/ceR/Luh9HQ= 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 Jim Reid writes: >>>>>> "Geoffrey" == Geoffrey Sisson writes: > > Geoffrey> A common legal understanding covering all potential > Geoffrey> DNSSEC users is unlikely. It seems almost certain that > Geoffrey> there will be operators that will deploy DNSSECbis > Geoffrey> regardless of impact of NSEC RR traversal, and operators > Geoffrey> that cannot deploy because of it. These divergent > Geoffrey> requirements deliniate the scope of the technical > Geoffrey> problem. > > If an operator's reasons for not deploying DNSSECbis are policy ones, > how can this be a technical problem? The technical problem is to find a solution that fit with the policy. If the WG is not here to change the policy, it should not attempt to. Regards, 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 Thu May 27 13:47: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 NAA11634 for ; Thu, 27 May 2004 13:47:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTOvd-0006av-MV for namedroppers-data@psg.com; Thu, 27 May 2004 17:44:29 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTOvN-0006Yh-I5 for namedroppers@ops.ietf.org; Thu, 27 May 2004 17:44:13 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4RHiCWE000608 for ; Thu, 27 May 2004 18:44:12 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA13936 for ; Thu, 27 May 2004 18:44:10 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4RHiAH12778 for namedroppers@ops.ietf.org; Thu, 27 May 2004 18:44:10 +0100 Date: Thu, 27 May 2004 18:44:10 +0100 From: Tim Chown To: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position Message-ID: <20040527174410.GC11923@login.ecs.soton.ac.uk> Mail-Followup-To: namedroppers@ops.ietf.org References: <5318.1085672580@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean 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 On Thu, May 27, 2004 at 05:00:28PM +0100, Jay Daley wrote: > Jim > > > If an operator's reasons for not deploying DNSSECbis are policy ones, > > how can this be a technical problem? > > How does it sit with you if a technical change forces an operator into > changing their policy? Are you saying that by default the policy must have > been wrong in the first place? Hmm, don't policies continuously get rewritten in the light of the emergence of new technologies (e.g. IPv6 or ENUM as Jim suggested) or changes or evolutions to existing technologies (or their usage or abuse patterns)? A policy is generally just best practice for the current technical environment (within the confines of the law :). Best practice changes, but that doesn't mean what went before it was wrong. Tim -- to unsubscribe send a message to namedroppers-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 May 27 14:23: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 OAA13833 for ; Thu, 27 May 2004 14:23:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTPTd-000Hlj-S9 for namedroppers-data@psg.com; Thu, 27 May 2004 18:19:37 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTPTN-000Hen-3q for namedroppers@ops.ietf.org; Thu, 27 May 2004 18:19:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 660CE13DED for ; Thu, 27 May 2004 18:19:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: Message from Roy Badami of "Thu, 27 May 2004 10:23:16 +0100." <16565.45956.205803.87821@giles.gnomon.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 27 May 2004 18:19:20 +0000 Message-Id: <20040527181920.660CE13DED@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 am assuming that DNSSECbis is modified so NSEC RRs > contain a version field, which is set to 1 (say). please don't do this. find a signalling method, such as a dnskey algorythm id or some existing MBZ field, that will allow new negative signatures in the future (such as the one we're calling NSEC2) but that will not require the dnssec-bis docset to be recut yet again. changes to the dnssec-bis docset at this stage should be because of document or protocol quality issues, not because of design changes in the protocol itself. -- to unsubscribe send a message to namedroppers-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 May 27 15:01: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 PAA16426 for ; Thu, 27 May 2004 15:01:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTQ4z-0006U6-Tz for namedroppers-data@psg.com; Thu, 27 May 2004 18:58:13 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTQ4k-0006QT-Q0 for namedroppers@ops.ietf.org; Thu, 27 May 2004 18:57:58 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4RIvulZ062955 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 27 May 2004 18:57:57 GMT (envelope-from roy+dated+1088276344.24dc21@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4RIvsso026493 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 27 May 2004 19:57:55 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4RIx4l8056169 for ; Thu, 27 May 2004 19:59:04 +0100 (BST) (envelope-from roy+dated+1088276344.24dc21@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4RIx4MN056168 for namedroppers@ops.ietf.org; Thu, 27 May 2004 19:59:04 +0100 (BST) (envelope-from roy+dated+1088276344.24dc21@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 27 May 2004 19:59:03 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16566.14967.104462.921988@giles.gnomon.org.uk> Date: Thu, 27 May 2004 19:59:03 +0100 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: <20040527181920.660CE13DED@sa.vix.com> References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@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 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-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 writes: >> ... I am assuming that DNSSECbis is modified so NSEC RRs >> contain a version field, which is set to 1 (say). Paul> please don't do this. Sorry, perhaps I should have said: "I am assuming, for sake of discussion of the proposal, that the NSEC record is versioned, as proposed in this thread" I didn't mean to imply anything in a wider context. -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 May 27 16:15: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 QAA21504 for ; Thu, 27 May 2004 16:14:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTRCS-0000gY-Fj for namedroppers-data@psg.com; Thu, 27 May 2004 20:10:00 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTRCE-0000cd-M4 for namedroppers@ops.ietf.org; Thu, 27 May 2004 20:09:46 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 3866219B694; Thu, 27 May 2004 16:05:38 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 9584B19B569; Thu, 27 May 2004 16:05:37 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1699247; Thu, 27 May 2004 16:09:45 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <16566.14967.104462.921988@giles.gnomon.org.uk> References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> Date: Thu, 27 May 2004 16:09:42 -0400 To: Roy Badami From: Edward Lewis Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Cc: Paul Vixie , 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 19:59 +0100 5/27/04, Roy Badami wrote: >>>>>> "Paul" == Paul Vixie writes: > > >> ... I am assuming that DNSSECbis is modified so NSEC RRs > >> contain a version field, which is set to 1 (say). > > Paul> please don't do this. > >Sorry, perhaps I should have said: > > "I am assuming, for sake of discussion of the proposal, that the > NSEC record is versioned, as proposed in this thread" > >I didn't mean to imply anything in a wider context. > > -roy I have my doubts that versioning NSEC is possible. Let's say that we put in the current documents: "When descending from a parent to a child, assume a verifier sees neither a DS RR nor a NSEC(v1) RR denying a DS RR and instead sees an NSEC(v2) in the authority section. In this case the verifier is to assume that a new style of authenticated denial is in use and therefore assume the child is unsigned." Assuming that the NSEC(v2) passes signature validation, how does the NSEC(v1)-era validator confirm that the right NSEC(v2) is there? How do you detect an insertion error - that an eavesdropper didn't replay a non-material NSEC(v2) to deny secure access to that zone? Assume a signed child, with such a clause I can reply with an alternate set of name servers and a non-material (but still signed) NSEC(v2) record. I can make it look like the child is unsigned while still passing all of the security checks. It seems to me that you'd have to turn off DNSSEC processing and restart for the next version once everyone has cleared out the old verifiers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 27 16:25: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 QAA22349 for ; Thu, 27 May 2004 16:25:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTRNu-0002jv-AM for namedroppers-data@psg.com; Thu, 27 May 2004 20:21:50 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTRNo-0002jS-HJ for namedroppers@ops.ietf.org; Thu, 27 May 2004 20:21:44 +0000 Received: from wds1.nominet.org.uk (notes1.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id C0C13E7EBD; Thu, 27 May 2004 21:21:43 +0100 (BST) In-Reply-To: <20040527165230.GA11286@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com Cc: Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Jay Daley" Date: Thu, 27 May 2004 21:15:22 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 05/27/2004 09:21:43 PM, Serialize complete at 05/27/2004 09:21:43 PM 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 Bill bmanning@vacation.karoshi.com wrote on 27/05/2004 17:52:30: > That aside, I suspect that -IF- one were to waive some of the > fundamental design principles of the DNS and DNSSEC, it would be > possible to design a technical solution to your particular policy > drivers. This is the crux of it. With DNS no fundamental principles are waived. We enforce our policy by controlling AXFR. With DNSSECbis that is no longer possible. Jay -- to unsubscribe send a message to namedroppers-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 May 27 16:39: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 QAA23482 for ; Thu, 27 May 2004 16:39:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTRbG-0005jk-3Y for namedroppers-data@psg.com; Thu, 27 May 2004 20:35:38 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTRb9-0005iS-Sn for namedroppers@ops.ietf.org; Thu, 27 May 2004 20:35:31 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4RKZTW4011800; Thu, 27 May 2004 20:35:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4RKZTV9011797; Thu, 27 May 2004 20:35:29 GMT Date: Thu, 27 May 2004 20:35:29 +0000 From: bmanning@vacation.karoshi.com To: Jay Daley Cc: bmanning@vacation.karoshi.com, Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position Message-ID: <20040527203529.GC11571@vacation.karoshi.com.> References: <20040527165230.GA11286@vacation.karoshi.com.> 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.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 > bmanning@vacation.karoshi.com wrote on 27/05/2004 17:52:30: > > > That aside, I suspect that -IF- one were to waive some of the > > fundamental design principles of the DNS and DNSSEC, it would be > > possible to design a technical solution to your particular policy > > drivers. > > This is the crux of it. With DNS no fundamental principles are waived. We > enforce our policy by controlling AXFR. With DNSSECbis that is no longer > possible. > > Jay Er... yes it is. Leave your AXFR blocks in place. You still prevent zone transfers. DNSSEC has nothing to do w/ AXFR support. AXFR gives an -exact- copy of the zone, at a point in time. If you wish to prevent entities from getting the data, block queries as well. If you enable queries, then entities may build a NEAR copy of your data - in fact this is exactly what happens with caching nameservers. If I wish to build a highly accuate copy, without DNSSEC, I must generate large numbers of queries in a fairly short period, guessing at lable contents. DNSSEC allows me to reduce the number of queries, but they are still queries for individual records. No AXFR involved. :) --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 Thu May 27 16:45: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 QAA24033 for ; Thu, 27 May 2004 16:45:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTRhj-0007Cg-45 for namedroppers-data@psg.com; Thu, 27 May 2004 20:42:19 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTRhc-0007C4-Dg for namedroppers@ops.ietf.org; Thu, 27 May 2004 20:42:12 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Thu, 27 May 2004 16:42:02 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.5.43) with SMTP id M2004052716420211847 ; Thu, 27 May 2004 16:42:02 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 May 2004 16:42:02 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE1050D2@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Jay Daley'" Cc: namedroppers@ops.ietf.org Subject: RE: Confirming the Nominet position Date: Thu, 27 May 2004 16:40:02 -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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > That aside, I suspect that -IF- one were to waive some of the > > fundamental design principles of the DNS and DNSSEC, it would be > > possible to design a technical solution to your particular policy > > drivers. > > This is the crux of it. With DNS no fundamental principles > are waived. We enforce our policy by controlling AXFR. > With DNSSECbis that is no longer possible. With all due respect, I believe that your policy is based on a capability that is implementation-specific, not part of the protocol, and was therefore specifically not a requirement when DNSSEC was being designed. I would further state that in a reasonably-size TLD with which I have some familiarity, we believe that even zone enumeration down to the level of each individual host is acceptable if it's what's necessary to make DNSSEC work (and I do still believe that signed proof of non-existence is necessary, although someone's working hard to convince me otherwise). Yes, the TLD I mention currently has requirements for the use of split DNS and restriction of AXFR--but those are policy items based on the capabilities and tradeoffs at the time the policy was created. The policy details and implementation will likely change. The fact that someone can more easily enumerate a zone does not make the individual records within that zone any more "vulnerable" or less "private". This applies whether those records are individual hosts, or delegations. If someone does not want their information to be made public, then do not place it in the public DNS. Even in the aggregate, the total list of hosts in any DNS zone does not represent a vulnerability or a loss of privacy--because there was a conscious choice to put the information in DNS in the first doggone place. Or is your statement that it's okay for a notional bad guy to obtain 10% of the .org.uk zone and abuse that information, but the other 90% will really get you angry? I believe that you are, in fact, going against a fundamental principle of DNS right now. The fact that "it always worked that way" (not strictly true, but close enough) doesn't mean that the capability will always work in the exact same way in the future. My $0.019. --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: From owner-namedroppers@ops.ietf.org Thu May 27 17:10:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25818 for ; Thu, 27 May 2004 17:10:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTS6t-000CFX-3v for namedroppers-data@psg.com; Thu, 27 May 2004 21:08:19 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTS6T-000C6t-PU for namedroppers@ops.ietf.org; Thu, 27 May 2004 21:07:53 +0000 Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 291A7E7E65; Thu, 27 May 2004 22:07:53 +0100 (BST) In-Reply-To: <20040527135425.GA10971@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com Cc: geoff@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Jay Daley" Date: Thu, 27 May 2004 21:24:24 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 05/27/2004 10:07:53 PM, Serialize complete at 05/27/2004 10:07:53 PM 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 Bill bmanning@vacation.karoshi.com wrote on 27/05/2004 14:54:25: > to make it easier to track, would "watermarking" the > database be helpful? Possibly, but we would need to decide whether to do this by IP address, by zone etc. (which may not be as trivial as it seems). Whatever the way this is still an after-the-fact control mechanism and those are arduous and expensive to pursue. This is something we unfortunately have a lot of experience of ... http://www.vnunet.com/news/1154488 Jay -- to unsubscribe send a message to namedroppers-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 May 27 17:25: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 RAA27308 for ; Thu, 27 May 2004 17:25:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTSKd-000FSw-Ls for namedroppers-data@psg.com; Thu, 27 May 2004 21:22:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTSK7-000FM8-Up for namedroppers@ops.ietf.org; Thu, 27 May 2004 21:21:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B163013DE9 for ; Thu, 27 May 2004 21:21:59 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: Message from "Jay Daley" of "Thu, 27 May 2004 21:15:22 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 27 May 2004 21:21:59 +0000 Message-Id: <20040527212159.B163013DE9@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 > > That aside, I suspect that -IF- one were to waive some of the > > fundamental design principles of the DNS and DNSSEC, it would be > > possible to design a technical solution to your particular policy > > drivers. > > This is the crux of it. With DNS no fundamental principles are waived. We > enforce our policy by controlling AXFR. With DNSSECbis that is no longer > possible. i disagree. when i put the first AXFR-blocking code into BIND 4 in ~1988, i considered it a protocol violation and i made my apologies to the gods. it appears that those gods have a long memory, and a grand scale of vengeance. -- to unsubscribe send a message to namedroppers-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 May 27 17:57: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 RAA28963 for ; Thu, 27 May 2004 17:57:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTSoP-000Mvm-57 for namedroppers-data@psg.com; Thu, 27 May 2004 21:53:17 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTSoO-000Muv-1B for namedroppers@ops.ietf.org; Thu, 27 May 2004 21:53:16 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4RLrDlZ009062 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 27 May 2004 21:53:14 GMT (envelope-from roy+dated+1088286860.32744a@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4RLrAso027476 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 27 May 2004 22:53:12 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4RLsKKK057321 for ; Thu, 27 May 2004 22:54:20 +0100 (BST) (envelope-from roy+dated+1088286860.32744a@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4RLsKnW057320 for namedroppers@ops.ietf.org; Thu, 27 May 2004 22:54:20 +0100 (BST) (envelope-from roy+dated+1088286860.32744a@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 27 May 2004 22:54:18 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16566.25482.359785.580078@giles.gnomon.org.uk> Date: Thu, 27 May 2004 22:54:18 +0100 To: Edward Lewis Cc: Roy Badami , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> 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-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 >>>>> "Edward" == Edward Lewis writes: Edward> Assume a signed child, with such a clause I can reply with Edward> an alternate set of name servers and a non-material (but Edward> still signed) NSEC(v2) record. I can make it look like Edward> the child is unsigned while still passing all of the Edward> security checks. I'm not sure you can reply with an alternate set of name servers, since the NS RRset still won't have the right signature. But you can certainly respond without a DS record, and with an irrelevent NSEC(v2) record, and fool an NSEC(v1) resolver into believing the child zone is unsigned. I did propose a solution to that; namely a null DS record. I'm not sure a versioned NSEC record is much use without a solution to this problem. -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 May 27 19:09: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 TAA03744 for ; Thu, 27 May 2004 19:09:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTTwE-000Et5-U8 for namedroppers-data@psg.com; Thu, 27 May 2004 23:05:26 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTTwE-000Esf-15 for namedroppers@ops.ietf.org; Thu, 27 May 2004 23:05:26 +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 i4RN2tJ24816; Thu, 27 May 2004 16:02:55 -0700 (PDT) Message-Id: <200405272302.i4RN2tJ24816@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3755 on Legacy Resolver Compatibility for Delegation Signer (DS) 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: Thu, 27 May 2004 16:02:55 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3755 Title: Legacy Resolver Compatibility for Delegation Signer (DS) Author(s): S. Weiler Status: Standards Track Date: May 2004 Mailbox: weiler@tislabs.com Pages: 9 Characters: 19812 Updates: 3658, 2535 I-D Tag: draft-ietf-dnsext-dnssec-2535typecode-change-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3755.txt As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. This document 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: <040527160104.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3755 --OtherAccess Content-Type: Message/External-body; name="rfc3755.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040527160104.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 Thu May 27 19:11: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 TAA03879 for ; Thu, 27 May 2004 19:11:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTTwG-000Etj-LD for namedroppers-data@psg.com; Thu, 27 May 2004 23:05:28 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTTwF-000Esf-Np for namedroppers@ops.ietf.org; Thu, 27 May 2004 23:05: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 i4RN4YJ25149; Thu, 27 May 2004 16:04:34 -0700 (PDT) Message-Id: <200405272304.i4RN4YJ25149@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3757 on Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag 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: Thu, 27 May 2004 16:04:34 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-19.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3757 Title: Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag Author(s): O. Kolkman, J. Schlyter, E. Lewis Status: Standards Track Date: May 2004 Mailbox: olaf@ripe.net, jakob@nic.se, edlewis@arin.net Pages: 8 Characters: 16868 Updates: 3755, 2535 I-D Tag: draft-ietf-dnsext-keyrr-key-signing-flag-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3757.txt With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755. 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: <040527160312.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3757 --OtherAccess Content-Type: Message/External-body; name="rfc3757.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040527160312.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 Thu May 27 21:54: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 VAA11469 for ; Thu, 27 May 2004 21:54:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTWVi-0002h1-IK for namedroppers-data@psg.com; Fri, 28 May 2004 01:50:14 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTWVg-0002g9-2h for namedroppers@ops.ietf.org; Fri, 28 May 2004 01:50:12 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id DDACA19B807; Thu, 27 May 2004 21:45:41 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 6420219B7F6; Thu, 27 May 2004 21:45:41 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1700204; Thu, 27 May 2004 21:49:52 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <16566.25482.359785.580078@giles.gnomon.org.uk> References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <16566.25482.359785.580078@giles.gnomon.org.uk> Date: Thu, 27 May 2004 21:49:29 -0400 To: Roy Badami From: Edward Lewis Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Cc: Edward Lewis , 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 22:54 +0100 5/27/04, Roy Badami wrote: >>>>>> "Edward" == Edward Lewis writes: > > Edward> Assume a signed child, with such a clause I can reply with > Edward> an alternate set of name servers and a non-material (but > Edward> still signed) NSEC(v2) record. I can make it look like > Edward> the child is unsigned while still passing all of the > Edward> security checks. > >I'm not sure you can reply with an alternate set of name servers, >since the NS RRset still won't have the right signature. But you can >certainly respond without a DS record, and with an irrelevent NSEC(v2) >record, and fool an NSEC(v1) resolver into believing the child zone is >unsigned. NS sets are not signed in referrals. They are signed in the authoritative zone, which you may not reach if you have only the substituted servers. >I did propose a solution to that; namely a null DS record. I'm not >sure a versioned NSEC record is much use without a solution to this >problem. See RFC 3658, section 1, in particular the 4th paragraph which states why the NULL KEY RR was dropped. Part of that argument transfers to the idea of a null DS RRset. With authenticated denials, you should not have to hold negative statements. If the positive statement isn't there, you assume the negative statement. This will hold for applications, it should hold for DNS if just to be consistent. If adopted, another change for DNSSECbis, another incompatibility for NSEC(v1)-era validators or a guaranteed delay. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 28 04:21: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 EAA11900 for ; Fri, 28 May 2004 04:21:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTcZF-000P0B-Ej for namedroppers-data@psg.com; Fri, 28 May 2004 08:18:17 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTcZE-000OzX-6O for namedroppers@ops.ietf.org; Fri, 28 May 2004 08:18:16 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 2C036E7EA8; Fri, 28 May 2004 09:18:15 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: <20040527212159.B163013DE9@sa.vix.com> References: <20040527212159.B163013DE9@sa.vix.com> Message-Id: <20040528081815.2C036E7EA8@mx1.nominet.org.uk> Date: Fri, 28 May 2004 09:18:15 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > i disagree. when i put the first AXFR-blocking code into BIND 4 in ~1988, > i considered it a protocol violation and i made my apologies to the gods. > > it appears that those gods have a long memory, and a grand scale of vengeance. RFC 821 specifies SMTP as a protocol which permits any host to connect to an `SMTP-receiver' and deliver messages. Unanticipated developments in the use of SMTP have resulted in this any <-> any principle being challanged, in particular in the work of the marid WG. There have certainly been comparable developments in the (ab)use of DNS; perhaps behaviour that was introduced via implementation rather than specification should now be `ratified' via a standards-track document? 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: From owner-namedroppers@ops.ietf.org Fri May 28 04:51: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 EAA13373 for ; Fri, 28 May 2004 04:51:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTd27-0002qQ-GJ for namedroppers-data@psg.com; Fri, 28 May 2004 08:48:07 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTd26-0002q6-29 for namedroppers@ops.ietf.org; Fri, 28 May 2004 08:48:06 +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 i4S8lt1b007917; Fri, 28 May 2004 10:47:57 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4S8lrDa016368; Fri, 28 May 2004 10:47:53 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4S8lps2016365; Fri, 28 May 2004 10:47:52 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 28 May 2004 10:47:51 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: Roy Badami , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: Message-ID: References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ed, Paul, This 'downgrade attack' is FUD (technically its there, but its a non-issue). How would we EVER use a new signing algorithm, currently not in use, if the downgrade attack would be a problem ? Unless folk upgrade V1 (nsec) resolvers to V2 (nsec2), they see V2 zones as unsigned. My point is: V2 zones do not yet exist. Would-be V2 zones are unsigned now. When V2 zones exist, they will still be unsigned to V1 resolvers. Eventually V1 resolvers will upgrade to V2 resolvers. Part of the upgrade curve. What exactly is the problem ? As an analogy. DNSSEC zones do not yet exist. Would-be DNSSEC zones are unsigned now. When DNSSEC zones exist, they will still be unsigned to LEGACY resolvers. Eventually LEGACY resolvers will upgrade to DNSSEC resolvers. Part of the upgrade curve. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 28 07:00: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 HAA20211 for ; Fri, 28 May 2004 07:00:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTf2o-0000FL-UG for namedroppers-data@psg.com; Fri, 28 May 2004 10:56:58 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTf2m-0000Dc-Nx for namedroppers@ops.ietf.org; Fri, 28 May 2004 10:56:57 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i4SAurn05863; Fri, 28 May 2004 17:56:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i4SApG55016334; Fri, 28 May 2004 17:51:17 +0700 (ICT) From: Robert Elz To: sthaug@nethelp.no cc: jim@rfc1035.com, namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: <23519.1085571396@bizet.nethelp.no> References: <23519.1085571396@bizet.nethelp.no> <2389.1085568022@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 May 2004 17:51:16 +0700 Message-ID: <21551.1085741476@munnari.OZ.AU> 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 Date: Wed, 26 May 2004 13:36:36 +0200 From: sthaug@nethelp.no Message-ID: <23519.1085571396@bizet.nethelp.no> [quoting someone...] | > For instance, I can understand why DeNIC | > wouldn't want random users to be able to slurp the 1GB or so of the | > .de zone, guzzling bandwidth and needlessly loading the TLD's name | > servers. | | But it's okay to let random users enumerate the zone by following | NSEC RRs? There's a big difference (and Jim, it isn't TCP vs UDP, for a zone transfer, the extra overhead of TCP is in the noise). The "problem" of AXFR is that it requires a stable zone image to transfer, and so the server must (somehow) create that stable zone, when the AXFR request is made, and then transfer the zone as it was at the instant the initial SOA of the response was sent - regardless of any later changes that are made to the zone. Since the server has no idea whether or not any changes may be made to the zone while the transfer is in progress, it has to do something to prepare for the possibility that they may occur (as it also has no way to know how long the zone transfer will take to complete, it also can't just delay updates until after that has happened - that could be hours, or more, into the future). This is what makes AXFR costly, and is certainly why I disabled it for non-secondaries when I was running zones for which it made a difference. The extra load of some number of random people doing zone slurps (especially using an NSEC type technique, where each subsequent query has to wait till the reply to the former is received, as that's where the qname for the next query comes from) when compared to the normal load on a busy server of handling "normal" queries (the ones that succeed, and even more, the ones that end up failing) is barely going to be noticeable. You'd need to postulate hundreds, or more likely, thousands, of people all deciding to walk the chain at the same time before the query rate would really start to be noticeable. [Yes, I know, the really busy servers don't want any unnecessary queries, but there are better things to try and stop than this I suspect]. It is also worth noting that the oft made claim that NSEC allows pristine zone copies to be made is false - it improves the chances of that happening over some other methods, but it is certainly not a technique that will guarantee the successful transfer of a zone. kre ps: apologies for the bogus copyright law noise I sent in an earlier message, it has been a long time since I needed to look at that stuff. Copyright was created initially as a means to encourage publication, so that was a requirement to get the protection - beats me why that requirement was dropped, but apparently it has been. -- to unsubscribe send a message to namedroppers-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 May 28 07:22: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 HAA21144 for ; Fri, 28 May 2004 07:22:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTfOZ-0004pV-RF for namedroppers-data@psg.com; Fri, 28 May 2004 11:19:27 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTfOX-0004oZ-TZ for namedroppers@ops.ietf.org; Fri, 28 May 2004 11:19:26 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i4SBJHn06714; Fri, 28 May 2004 18:19:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i4SBDP55017533; Fri, 28 May 2004 18:13:27 +0700 (ICT) From: Robert Elz To: "Jay Daley" cc: namedroppers@ops.ietf.org, geoff@nominet.org.uk Subject: Re: Confirming the Nominet position In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 May 2004 18:13:25 +0700 Message-ID: <17887.1085742805@munnari.OZ.AU> 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 Date: Wed, 26 May 2004 16:21:02 +0100 From: "Jay Daley" Message-ID: | 1. Showstopper | Zone file enumeration is a show-stopper for us that will prevent us from | fully implementing DNSSEC. So if DNSSEC stays in its current form then we | will have to make a local determination about how/what we implement, which | is still to be decided. Our reason for this is our view of what is the | appropriate policy to act in the best interests of our local community, | which for some time has been to deny access to our zone files. Actually, that's fine. No-one (here anyway) can force anyone to implement anything. If you don't implement DNSSEC, or just partially implement it (somehow), that's your choice. Sometime in the future, if UK users wonder why their DNS security isn't up to the standard of everyone else's, you can explain to them why that is in their best interests. If they agree with your explanation, and justification (you can blame this WG for forcing NSEC on DNSSEC if you want) then no problems. If they don't agree with you, then as I understand how nominet works (which I very well might not), you'd eventually end up replaced by someone who would implement DNSSEC. | 3. Legal mumbo jumbo [...] | However, for those of you that have asked, this is the gist of our legal | advice... | | As compilations, zone file databases are protected under EU law by | ?Database Right?. As a derivative work of the main register from which | they are sourced, they are likely also to attract copyright protection in | addition to or in place of database right. Leaving aside the question of whether or not those rights actually exist in the DNS zone files (a topic that can be debated, but namedroppers is not the correct forum for that), what needs explaining is not what those are, but why you'd want to enforce them. That copyright exists in some work (like perhaps this e-mail) doesn't mean that the holder of the right is required to enforce it against anyone else. Go ahead, copy this message as much as you like without my permission - I won't be coming after you. The laws here aren't ones that are forcing anyone into any action wrt the DNS zone files (unlike perhaps whois data), nothing in them is compelling you to restrict access to the zone file. The rationale for this can't rationally be to protect the domain name owners from having their data found - the DNS data (particularly this kind of DNS data - delegations in upper level domains) is publicly available, it has to be to work. The data can be found anyway. The only thing that NSEC is making easier is extracting a more complete list of what is in the domain (if not necessarily a perfect one), more quickly than without NSEC. That difference cannot really make any difference to anyone who is registering a name - whether they get "found" in an hour, or a week, cannot be of any material difference. What's left is the desires of the TLD (or similar) operator themselves, and how they want to handle this data. Is there any compelling reason that can be offered as to just why it is so important to you as a TLD operator to prevent zone enumeration? Anything compelling enough that this WG should go back and start making changes (and perhaps even worse, adding options - just about the last thing the DNS needs now are even more different ways to do things). Please don't tell me "our stakeholders demand it" - like Ted Hardie, mention of "stakeholders" in a context like that drives me insane. If your stakeholders (whatever that means) have good reasons, just tell me the reasons. If they don't, then they're irrelevant to me, and should be to you as well. 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 Fri May 28 07:36: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 HAA21706 for ; Fri, 28 May 2004 07:36:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTfcd-000902-B4 for namedroppers-data@psg.com; Fri, 28 May 2004 11:33:59 +0000 Received: from [192.134.4.151] (helo=maya40.nic.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTfcb-0008zV-Py for namedroppers@ops.ietf.org; Fri, 28 May 2004 11:33:58 +0000 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id i4SBXtUa693489; Fri, 28 May 2004 13:33:55 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id E0050FAF9; Fri, 28 May 2004 13:33:54 +0200 (CEST) Date: Fri, 28 May 2004 13:33:54 +0200 From: Stephane Bortzmeyer To: Jaap Akkerhuis Cc: IETF DNSEXT WG , Jakob Schlyter , Per-Olof Josefsson Subject: Re: NIC-SE statement regarding NSEC zone walking Message-ID: <20040528113354.GA9316@nic.fr> References: <200405271139.i4RBdPQF063545@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405271139.i4RBdPQF063545@bartok.sidn.nl> 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.5.1+cvs20040105i 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 Thu, May 27, 2004 at 01:39:25PM +0200, Jaap Akkerhuis wrote a message of 19 lines which said: > NIC-SE does not consider NXT zone-walking a problem for DNSSEC deployment > within the .se-zone. We consider all data in the DNS to be public > information, both as single records and as a collection. ... > Just in case that it wasn't clear from my earlier mai. This is the > position of SIDN as well for the nl-zone. Just by curiosity: why all name servers for ".se" or ".nl" prevent AXFR, then? -- to unsubscribe send a message to namedroppers-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 May 28 07:50: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 HAA22489 for ; Fri, 28 May 2004 07:50:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTfqw-000CGX-Gb for namedroppers-data@psg.com; Fri, 28 May 2004 11:48:46 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTfqu-000CEm-BG for namedroppers@ops.ietf.org; Fri, 28 May 2004 11:48:44 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id AA505E7E99; Fri, 28 May 2004 12:48:43 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: <21551.1085741476@munnari.OZ.AU> References: <21551.1085741476@munnari.OZ.AU> Message-Id: <20040528114843.AA505E7E99@mx1.nominet.org.uk> Date: Fri, 28 May 2004 12:48:43 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > The extra load of some number of random people doing zone slurps > (especially using an NSEC type technique, where each subsequent query has > to wait till the reply to the former is received, as that's where the > qname for the next query comes from) when compared to the normal load on > a busy server of handling "normal" queries (the ones that succeed, and > even more, the ones that end up failing) is barely going to be noticeable. It would be surprising if NSEC RR elaboration techniques didn't incorporate considerable parallelism, especially for large zones. This could impose arbitrarily high loads on a busy nameserver. For example, multiple simultaneous elaborations could be run, one starting at 'aaa.co.uk', another starting at 'aab.co.uk', and so on. This isn't idle speculation: prior to incorporating token bucket into the WHOIS server at whois.nic.uk [note: reference to WHOIS for illustrative purposes only!] we used to have a one-second sleep to limit the impact of scripts. Impatient data miners designed tools which sent queries in parallel -- sometimes hundreds per second -- in order to collect data at higher rates. The consequences to server performance were, well, predictable . . . 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: From owner-namedroppers@ops.ietf.org Fri May 28 09:07: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 JAA28584 for ; Fri, 28 May 2004 09:07:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTh0s-0002rA-3p for namedroppers-data@psg.com; Fri, 28 May 2004 13:03:06 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTh0r-0002ql-4Z for namedroppers@ops.ietf.org; Fri, 28 May 2004 13:03:05 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4SD33W4013743; Fri, 28 May 2004 13:03:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4SD33eX013740; Fri, 28 May 2004 13:03:03 GMT Date: Fri, 28 May 2004 13:03:03 +0000 From: bmanning@vacation.karoshi.com To: Jay Daley Cc: bmanning@vacation.karoshi.com, geoff@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position Message-ID: <20040528130303.GB13713@vacation.karoshi.com.> References: <20040527135425.GA10971@vacation.karoshi.com.> 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.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 Thu, May 27, 2004 at 09:24:24PM +0100, Jay Daley wrote: > Bill > > bmanning@vacation.karoshi.com wrote on 27/05/2004 14:54:25: > > > to make it easier to track, would "watermarking" the > > database be helpful? > > Possibly, but we would need to decide whether to do this by IP address, by > zone etc. (which may not be as trivial as it seems). Whatever the way > this is still an after-the-fact control mechanism and those are arduous > and expensive to pursue. This is something we unfortunately have a lot of > experience of ... http://www.vnunet.com/news/1154488 > > Jay Beating this dead mule... Digitally signing the data provides an un-ambigious, hard to forge, proof that the zone and each RR in the zone was signed by a unique source. This "watermark" technique is being considered by some to dis-abmbigious potential conflicts. 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: From owner-namedroppers@ops.ietf.org Fri May 28 09:45: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 JAA00763 for ; Fri, 28 May 2004 09:45:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BThdT-0008OW-SD for namedroppers-data@psg.com; Fri, 28 May 2004 13:42:59 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BThdS-0008OA-AL for namedroppers@ops.ietf.org; Fri, 28 May 2004 13:42:58 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id A42ABE7E72; Fri, 28 May 2004 14:42:57 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: <20040528130303.GB13713@vacation.karoshi.com.> References: <20040527135425.GA10971@vacation.karoshi.com.> <20040528130303.GB13713@vacation.karoshi.com.> Message-Id: <20040528134257.A42ABE7E72@mx1.nominet.org.uk> Date: Fri, 28 May 2004 14:42:57 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bmanning@vacation.karoshi.com writes: > Beating this dead mule... Digitally signing the data provides an > un-ambigious, hard to forge, proof that the zone and each RR in the > zone was signed by a unique source. This "watermark" technique is being > considered by some to dis-abmbigious potential conflicts. Hi Bill Are you suggesting the use of steganography to somehow uniquely identify RRs, or set of RRs, by whomever retrieved them? Or are you suggesting the use of the RRSIGs as legal evidence of the unambiguous origin of the zone data? Or something else? 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: From owner-namedroppers@ops.ietf.org Fri May 28 10:09: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 KAA02755 for ; Fri, 28 May 2004 10:09:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTi0C-000DMe-BO for namedroppers-data@psg.com; Fri, 28 May 2004 14:06:28 +0000 Received: from [217.155.92.105] (helo=tiger.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTi0A-000DLL-CY for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:06:26 +0000 Received: from algroup.co.uk (localhost.ben.algroup.co.uk [127.0.0.1]) by tiger.ben.algroup.co.uk (8.12.9p2/8.12.9) with ESMTP id i4SF1GNf011029; Fri, 28 May 2004 16:01:17 +0100 (BST) (envelope-from ben@algroup.co.uk) Message-ID: <40B7543B.4050609@algroup.co.uk> Date: Fri, 28 May 2004 16:01:15 +0100 From: Ben Laurie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Jay Daley , geoff@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position References: <20040527135425.GA10971@vacation.karoshi.com.> <20040528130303.GB13713@vacation.karoshi.com.> In-Reply-To: <20040528130303.GB13713@vacation.karoshi.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=-2.7 required=5.0 tests=BAYES_00,DOMAIN_BODY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bmanning@vacation.karoshi.com wrote: > On Thu, May 27, 2004 at 09:24:24PM +0100, Jay Daley wrote: > >>Bill >> >>bmanning@vacation.karoshi.com wrote on 27/05/2004 14:54:25: >> >> >>> to make it easier to track, would "watermarking" the >>> database be helpful? >> >>Possibly, but we would need to decide whether to do this by IP address, by >>zone etc. (which may not be as trivial as it seems). Whatever the way >>this is still an after-the-fact control mechanism and those are arduous >>and expensive to pursue. This is something we unfortunately have a lot of >>experience of ... http://www.vnunet.com/news/1154488 >> >>Jay > > > Beating this dead mule... Digitally signing the data provides an > un-ambigious, hard to forge, proof that the zone and each RR in the > zone was signed by a unique source. I don't see how that helps Nominet, since, by definition, if it ends .uk it'll be on their servers and the signatures would surely not be preserved in a list of .uk domains. > This "watermark" technique is being > considered by some to dis-abmbigious potential conflicts. I don't understand what this means? 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: From owner-namedroppers@ops.ietf.org Fri May 28 10:09: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 KAA02841 for ; Fri, 28 May 2004 10:09:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTi0D-000DNK-Nq for namedroppers-data@psg.com; Fri, 28 May 2004 14:06:29 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTi0C-000DMI-1N for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:06:28 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A174319B73C; Fri, 28 May 2004 10:02:06 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 15CB819B6CF; Fri, 28 May 2004 10:02:06 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1702192; Fri, 28 May 2004 10:06:26 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> Date: Fri, 28 May 2004 10:06:25 -0400 To: roy@dnss.ec From: Edward Lewis Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Cc: Edward Lewis , 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:47 +0200 5/28/04, roy@dnss.ec wrote: >V2 zones do not yet exist. Would-be V2 zones are unsigned now. When V2 >zones exist, they will still be unsigned to V1 resolvers. Eventually V1 >resolvers will upgrade to V2 resolvers. Why would they appear unsigned to v1 resolvers? > >Part of the upgrade curve. > >What exactly is the problem ? Whether meeting the *perceived* new requirement is worth the cost of what is likely to be an architectural hack (in design) and potentially a great processing cost (in operations). It's not clear to me that the premise of this debate is valid - that DNSSEC needs to answer to privacy concerns. There is in evidence a a strong vocal component, but from just one effort. There is also a counter argument being offered, that this is a non-issue. Additionally, there seems to be a lot of folks sitting on the side lines on the issue. If we do move ahead and try to solve the problem, we have to figure out how. Using an alternate key algorithm to signal what version of authenticated denial is in use? Sounds hacky to me - what does the cryptographic algorithm have to do with the version of authenticated denial? If it's not clear to a teenager, it's a hack. Null DS or defining melt-down scenarios mean more protocol design work. Quick hits like these can't be taken lightly, lest we engender corner cases later on. There is the perceived need to get DNSSEC specs out now, and reasons for delay had better be well founded. (And we are still at "perceived new requirement.") In operations, the cost of accomplishing obfuscation in authenticate denial will be greater than what we see planned now. When I walked through an example I mentioned a performance vulnerability. The best analogy to it is - there was once a TV game show called "Password" in which one person had a word in front of them and tried to get their partner to guess the word. The one with the word couldn't use it and could only say one word at a time to guide the partner. Often times it would take a number of other words to guide the partner into the needed word - if at all. I think that is the problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 28 10: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 KAA03635 for ; Fri, 28 May 2004 10:15:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTi7l-000FBv-4k for namedroppers-data@psg.com; Fri, 28 May 2004 14:14:17 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTi7k-000FBV-3v for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:14:16 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DCFF113DF0 for ; Fri, 28 May 2004 14:14:15 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: Message from roy@dnss.ec of "Fri, 28 May 2004 10:47:51 +0200." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 28 May 2004 14:14:15 +0000 Message-Id: <20040528141415.DCFF113DF0@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 roy asked "Ed, Paul" to comment on the following: > This 'downgrade attack' is FUD (technically its there, but its a > non-issue). How would we EVER use a new signing algorithm, currently not > in use, if the downgrade attack would be a problem ? by adding new ones without removing old ones, and signing with both during an extended overlap period. (did you think dnssec could be at its third unreleased version after a ten year period without solving something so simple?) > What exactly is the problem ? the people who proposed to use bis2 with NSEC2-like functionality will not also be using NSEC, they propose to do an upgrade without an overlap period. if they instead follow a timeline where the new NSEC2-like functionality is introduced, and existing NSEC users do the "use both" trick for an extended period while the validator population churns over, and when these existing users stop using pre-NSEC2 data because it's not needed, then and only then can new users (of NSEC2-only) deploy, then all will be well. paul, of "ed, paul". -- to unsubscribe send a message to namedroppers-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 May 28 10:16: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 KAA03679 for ; Fri, 28 May 2004 10:16:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTi6Q-000Etu-W5 for namedroppers-data@psg.com; Fri, 28 May 2004 14:12:54 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTi6P-000Etc-KW for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:12:53 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BTi6J-0007AC-Ug; Fri, 28 May 2004 16:12:48 +0200 In-Reply-To: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> To: namedroppers@ops.ietf.org Subject: Re: Scope of discussion MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic Message-ID: Date: Fri, 28 May 2004 16:12:33 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 28.05.2004 16:12:47, Serialize complete at 28.05.2004 16:12:47 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 Dear chairs, dear all, > It would > help if you make your (motivated) position clearer and provide your > arguments for taking one of the options. Do so before June 1. DENIC (7,6 million DE-domains) is looking forward DNSSEC deployment, and that rather happening before secure islands appearing under DE may endanger the common namespace. However, DENIC will not be able to carry this deployment out with the form of the specification as it is today (because of a clashing of the NSEC traversal with [*]). We would be willing to give green light to the current spec if the working group could commit to solving the NSEC traversal problem afterwards. Then, at that point, the form of the problem should be formalized and well defined, with our commitment to contribute to the process. The form of the solution (whether NO/NSEC2, or online signing of NXDOMAIN-answers, or optional use of NSEC or something else) probably can't be decided at the moment. We are aware that providing an open door to the future solution might require slight modifications of the current drafts. Best, Marcos Sanz DENIC eG [*] http://www.denic.de/en/faqs/allgemeine_faqs/index.html#section_185 -- to unsubscribe send a message to namedroppers-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 May 28 10:29: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 KAA05774 for ; Fri, 28 May 2004 10:29:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTiHz-000HDS-JV for namedroppers-data@psg.com; Fri, 28 May 2004 14:24:51 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTiHy-000HD1-Jc for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:24:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2239413951 for ; Fri, 28 May 2004 14:24:50 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag In-Reply-To: Message from Robert Elz of "Fri, 28 May 2004 17:51:16 +0700." <21551.1085741476@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 28 May 2004 14:24:50 +0000 Message-Id: <20040528142450.2239413951@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 robert wrote: > The "problem" of AXFR is that it requires a stable zone image to > transfer, and so the server must (somehow) create that stable zone, > when the AXFR request is made, and then transfer the zone as it was at > the instant the initial SOA of the response was sent - regardless of > any later changes that are made to the zone. > > Since the server has no idea whether or not any changes may be made to > the zone while the transfer is in progress, it has to do something to > prepare for the possibility that they may occur (as it also has no way > to know how long the zone transfer will take to complete, it also > can't just delay updates until after that has happened - that could be > hours, or more, into the future). > > This is what makes AXFR costly, [...] RFC 1035 makes a provision for killing in-progress AXFR if the zone changes while it's being transferred, and BIND4/BIND8 work that way. this causes problems for extremely-dynamic zones, like when UPDATE is used by dhcp in an enterprise or wireless context, and so BIND9 has extensive (and expensive) internal versioning and refcounting so that a zone at a certain serial number can continue its AXFR even though newer zones (with different serial numbers) are being used for subsequent queries (or even subsequent AXFR). robert is quite right, this is the biggest reason why a TLD registry (or anyone else) would find AXFR expensive. however, back in the days when f-root served COM, we were alone among the root servers in supporting AXFR for it. network solutions hated this practice, and ultimately had someone in USGov send us a letter asking us to turn it off, which we did. but while it was on, our puny little 8GB 4x500MHz alphas handled a hell of a lot of outbound AXFR traffic for what was, even then, the largest zone on the planet. we did it on BIND8 and we did it on BIND9. the load, while expensive in exactly the ways that robert suggests above, was never a noticable problem for a little nonprofit without a hardware budget who was totally dependent on the kindness of our friends. in these days when a dual or quad Opteron with 16GB and 2x2GHz or 4x2GHz can be had from reputable vendors like sun, ibm, hp, or a hundred whitebox vendors for a couple thousand USD, no serious commercial entity can complain that any zone, even one the size of COM, cannot support AXFR. > ... > > It is also worth noting that the oft made claim that NSEC allows pristine > zone copies to be made is false - it improves the chances of that happening > over some other methods, but it is certainly not a technique that will > guarantee the successful transfer of a zone. agreed. an NSEC chainwalk would have none of AXFR's guaranteed stability. if the zone changes during a chainwalk, then you get part of the old and part of the new. not that this makes much difference to the zone operators, who are clearly more concerned with competition and abuse than with copyright or resources. paul -- to unsubscribe send a message to namedroppers-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 May 28 10:41: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 KAA06737 for ; Fri, 28 May 2004 10:41:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTiUe-000LsT-FW for namedroppers-data@psg.com; Fri, 28 May 2004 14:37:56 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTiUc-000Lra-Sc for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:37:55 +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 i4SEbmvH010148; Fri, 28 May 2004 16:37:48 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4SEbjd6023823; Fri, 28 May 2004 16:37:45 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4SEbjVh023820; Fri, 28 May 2004 16:37:45 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 28 May 2004 16:37:45 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: Message-ID: References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 28 May 2004, Edward Lewis wrote: > At 10:47 +0200 5/28/04, roy@dnss.ec wrote: > >V2 zones do not yet exist. Would-be V2 zones are unsigned now. When V2 > >zones exist, they will still be unsigned to V1 resolvers. Eventually V1 > >resolvers will upgrade to V2 resolvers. > > Why would they appear unsigned to v1 resolvers? The authenticated denial V2 can not be used by V1 resolvers. Therefor secure delegations in V2 zones, in worst case, are seen as unsigned since the existence of a DS record can't be proven. > > > >Part of the upgrade curve. > > > >What exactly is the problem ? > > Whether meeting the *perceived* new requirement is worth the cost of > what is likely to be an architectural hack (in design) and > potentially a great processing cost (in operations). I really don't care about NSEC2, I care about being able to extend the spec later on, giving those who do care an opporunity to do so. I leave the politic bs of this specific alternative of NSEC to those who care. > It's not clear to me that the premise of this debate is valid - that > DNSSEC needs to answer to privacy concerns. There is in evidence a a > strong vocal component, but from just one effort. There is also a > counter argument being offered, that this is a non-issue. > Additionally, there seems to be a lot of folks sitting on the side > lines on the issue. > > If we do move ahead and try to solve the problem, we have to figure > out how. Using an alternate key algorithm to signal what version of > authenticated denial is in use? Sounds hacky to me - what does the > cryptographic algorithm have to do with the version of authenticated > denial? If it's not clear to a teenager, it's a hack. I agree. The alternate key alg is hacky. That would be a desperate thing to do. It works ofcourse, especially when there is no alternative offered. > Null DS or defining melt-down scenarios mean more protocol design > work. Quick hits like these can't be taken lightly, lest we engender > corner cases later on. There is the perceived need to get DNSSEC > specs out now, and reasons for delay had better be well founded. > (And we are still at "perceived new requirement.") Bringing back NULL DS is a showstopper, I agree. > In operations, the cost of accomplishing obfuscation in authenticate > denial will be greater than what we see planned now. When I walked > through an example I mentioned a performance vulnerability. The best > analogy to it is - there was once a TV game show called "Password" in > which one person had a word in front of them and tried to get their > partner to guess the word. The one with the word couldn't use it and > could only say one word at a time to guide the partner. Often times > it would take a number of other words to guide the partner into the > needed word - if at all. > > I think that is the problem. So how about those mets. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 28 10:50: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 KAA07227 for ; Fri, 28 May 2004 10:50:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTieJ-000Omb-LF for namedroppers-data@psg.com; Fri, 28 May 2004 14:47:55 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTieI-000Om7-8O for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:47:54 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4SElplZ057984 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 28 May 2004 14:47:52 GMT (envelope-from roy+dated+1088347740.27d3c2@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4SEllso031643 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 28 May 2004 15:47:51 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4SEn1e5061632 for ; Fri, 28 May 2004 15:49:01 +0100 (BST) (envelope-from roy+dated+1088347740.27d3c2@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4SEn0Ja061631 for namedroppers@ops.ietf.org; Fri, 28 May 2004 15:49:00 +0100 (BST) (envelope-from roy+dated+1088347740.27d3c2@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 28 May 2004 15:48:58 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16567.20826.302378.846966@giles.gnomon.org.uk> Date: Fri, 28 May 2004 15:48:58 +0100 To: roy@dnss.ec Cc: Edward Lewis , Roy Badami , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> 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-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 >>>>> "roy" == roy writes: roy> Ed, Paul, This 'downgrade attack' is FUD (technically its roy> there, but its a non-issue). How would we EVER use a new roy> signing algorithm, currently not in use, if the downgrade roy> attack would be a problem ? roy> Unless folk upgrade V1 (nsec) resolvers to V2 (nsec2), they roy> see V2 zones as unsigned. That I'm happy with. Changing the algorithm id would achieve this. What makes me nervous is a scenario where a V1 resolver can check signatures on V2 records, and in particular can follow secure delegations from a V2 zone, but can't do so in a secure manner. If people aren't getting the security they believe they're getting, then that is dangerous. Note that I'm not arguing that DNSSEC needs to be modified (either now or later) to prevent enumeration. Nor am I arguing that ccTLDs need to change their policies to allow enumeration. However this impasse does need to be resolved one way or another otherwise I (as a user) won't get to see the benefits of DNSSEC. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 28 10:51: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 KAA07251 for ; Fri, 28 May 2004 10:51:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTidp-000Ogv-Cx for namedroppers-data@psg.com; Fri, 28 May 2004 14:47:25 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTido-000OgV-0H for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:47:24 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id CAD1C19B743; Fri, 28 May 2004 10:43:01 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 1B10319B755; Fri, 28 May 2004 10:43:01 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1702474; Fri, 28 May 2004 10:47:22 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> Date: Fri, 28 May 2004 10:47:20 -0400 To: roy@dnss.ec From: Edward Lewis Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Cc: Edward Lewis , roy@dnss.ec, 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.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:37 +0200 5/28/04, roy@dnss.ec wrote: >On Fri, 28 May 2004, Edward Lewis wrote: > >> At 10:47 +0200 5/28/04, roy@dnss.ec wrote: >> Why would they appear unsigned to v1 resolvers? > >The authenticated denial V2 can not be used by V1 resolvers. Therefor >secure delegations in V2 zones, in worst case, are seen as unsigned since >the existence of a DS record can't be proven. I'm assuming failure to prove or disprove something is a service failure (SERVFAIL). So, instead of being unsigned, they look broken - far worse. >I really don't care about NSEC2, I care about being able to extend the >spec later on, giving those who do care an opporunity to do so. I said the same thing about "sane NXTs" in the wake of the opt-in discussion. To do that, you need to define the failure semantics (see above). Because I was called away from the group, I don't know what happened to the thoughts about defining error reactions to "insane NXTs." (I.e., an NXT that claims that it doesn't exist.) >So how about those mets. Back to .500! I'll see 'em Monday. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 28 10:52: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 KAA07538 for ; Fri, 28 May 2004 10:52:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTigH-000P9S-H9 for namedroppers-data@psg.com; Fri, 28 May 2004 14:49:57 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTigG-000P99-Ch for namedroppers@ops.ietf.org; Fri, 28 May 2004 14:49:56 +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 i4SEnsru010258; Fri, 28 May 2004 16:49:54 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4SEnnuV024118; Fri, 28 May 2004 16:49:49 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4SEnnfk024115; Fri, 28 May 2004 16:49:49 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 28 May 2004 16:49:49 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: <20040528141415.DCFF113DF0@sa.vix.com> Message-ID: References: <20040528141415.DCFF113DF0@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.2 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 28 May 2004, Paul Vixie wrote: > roy asked "Ed, Paul" to comment on the following: > > > This 'downgrade attack' is FUD (technically its there, but its a > > non-issue). How would we EVER use a new signing algorithm, currently not > > in use, if the downgrade attack would be a problem ? > > by adding new ones without removing old ones, and signing with both > during an extended overlap period. Okay, if I sign dnss.ec with TRUDY algorithm only, would your resolver, incapable of understanding TRUDY treat that zone as signed ? unsigned ? Bad ? If you'd follow spec, you should treat is as unsigned. WHOA there is your downgrade attack. > (did you think dnssec could be at its third unreleased version after a > ten year period without solving something so simple?) > > > What exactly is the problem ? > > the people who proposed to use bis2 with NSEC2-like functionality will > not also be using NSEC, they propose to do an upgrade without an overlap > period. if they instead follow a timeline where the new NSEC2-like > functionality is introduced, and existing NSEC users do the "use both" > trick for an extended period while the validator population churns over, > and when these existing users stop using pre-NSEC2 data because it's not > needed, then and only then can new users (of NSEC2-only) deploy, then > all will be well. Then we better well spec your upgrade path. Its not the alternative signing algorithm hack, right ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 28 11:05: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 LAA08169 for ; Fri, 28 May 2004 11:05:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTit4-0001hO-Ft for namedroppers-data@psg.com; Fri, 28 May 2004 15:03:10 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTit3-0001gs-1z for namedroppers@ops.ietf.org; Fri, 28 May 2004 15:03:09 +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 i4SF3532010448; Fri, 28 May 2004 17:03:05 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4SF322d024438; Fri, 28 May 2004 17:03:02 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4SF32XE024435; Fri, 28 May 2004 17:03:02 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 28 May 2004 17:03:02 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: Message-ID: References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, OPT_IN,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 28 May 2004, Edward Lewis wrote: > At 16:37 +0200 5/28/04, roy@dnss.ec wrote: > >On Fri, 28 May 2004, Edward Lewis wrote: > > > >> At 10:47 +0200 5/28/04, roy@dnss.ec wrote: > >> Why would they appear unsigned to v1 resolvers? > > > >The authenticated denial V2 can not be used by V1 resolvers. Therefor > >secure delegations in V2 zones, in worst case, are seen as unsigned since > >the existence of a DS record can't be proven. > > I'm assuming failure to prove or disprove something is a service > failure (SERVFAIL). So, instead of being unsigned, they look broken > - far worse. I understand. But I assumed versioning, where, if you can't cope with the version, you fall back to default (dns). > >I really don't care about NSEC2, I care about being able to extend the > >spec later on, giving those who do care an opporunity to do so. > > I said the same thing about "sane NXTs" in the wake of the opt-in > discussion. To do that, you need to define the failure semantics > (see above). Because I was called away from the group, I don't know > what happened to the thoughts about defining error reactions to > "insane NXTs." (I.e., an NXT that claims that it doesn't exist.) Ask chair, dunno, wasn't me, but you know that. > >So how about those mets. > > Back to .500! I'll see 'em Monday. ;) Have fun :) Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 28 11:20: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 LAA09017 for ; Fri, 28 May 2004 11:20:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTj5z-0004Zn-Jl for namedroppers-data@psg.com; Fri, 28 May 2004 15:16:31 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTj5y-0004Yb-9d for namedroppers@ops.ietf.org; Fri, 28 May 2004 15:16:30 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4SFGMW4014021; Fri, 28 May 2004 15:16:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4SFGLTi014018; Fri, 28 May 2004 15:16:21 GMT Date: Fri, 28 May 2004 15:16:21 +0000 From: bmanning@vacation.karoshi.com To: Geoffrey Sisson Cc: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position Message-ID: <20040528151621.GA13996@vacation.karoshi.com.> References: <20040527135425.GA10971@vacation.karoshi.com.> <20040528130303.GB13713@vacation.karoshi.com.> <20040528134257.A42ABE7E72@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040528134257.A42ABE7E72@mx1.nominet.org.uk> 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 Fri, May 28, 2004 at 02:42:57PM +0100, Geoffrey Sisson wrote: > bmanning@vacation.karoshi.com writes: > > > Beating this dead mule... Digitally signing the data provides an > > un-ambigious, hard to forge, proof that the zone and each RR in the > > zone was signed by a unique source. This "watermark" technique is being > > considered by some to dis-abmbigious potential conflicts. > > Hi Bill > > Are you suggesting the use of steganography to somehow uniquely > identify RRs, or set of RRs, by whomever retrieved them? Or are you > suggesting the use of the RRSIGs as legal evidence of the unambiguous > origin of the zone data? Or something else? > > Regards > Geoff i've been told that digital signatures can be used as legal evidence in some jurisdictions. if true, it is conceivable that by my holding signed data indicates, if not the path by which i received said data, who signed the data. -- 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 Fri May 28 11:42: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 LAA10985 for ; Fri, 28 May 2004 11:42:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTjSh-0008a0-Uu for namedroppers-data@psg.com; Fri, 28 May 2004 15:39:59 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTjSg-0008ZP-T7 for namedroppers@ops.ietf.org; Fri, 28 May 2004 15:39:58 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4SFdmW4014043; Fri, 28 May 2004 15:39:48 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4SFdkEY014040; Fri, 28 May 2004 15:39:46 GMT Date: Fri, 28 May 2004 15:39:46 +0000 From: bmanning@vacation.karoshi.com To: Ben Laurie Cc: bmanning@vacation.karoshi.com, Jay Daley , geoff@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position Message-ID: <20040528153946.GB13996@vacation.karoshi.com.> References: <20040527135425.GA10971@vacation.karoshi.com.> <20040528130303.GB13713@vacation.karoshi.com.> <40B7543B.4050609@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40B7543B.4050609@algroup.co.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,DOMAIN_BODY, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Beating this dead mule... Digitally signing the data provides an > > un-ambigious, hard to forge, proof that the zone and each RR in the > > zone was signed by a unique source. > > I don't see how that helps Nominet, since, by definition, if it ends .uk > it'll be on their servers and the signatures would surely not be > preserved in a list of .uk domains. er... not at all. the server @ 198.32.2.10 has had 100,000s of RRs that end in uk. locally stored. - I could slurp them into zone file format and publish it as uk. for the server users. Not a Nominet server(s) and not Nominet data. QED. > >This "watermark" technique is being > > considered by some to dis-abmbigious potential conflicts. > > I don't understand what this means? How does one distinguish the Nominet collection of data that ends in uk. and the Msrs Bill, Ben & Geoffs collection of data that ends in uk.? The simple way is to "watermark" the dataset and it elements with digital signatures. ergo the database entry "co.uk." with a Nominet signature is clearly signed by Nominet and presumably they acknowledge that the data so signed is authentic to Nominet. One might presume that a careful application might be able to distinguish a "co.uk." signed by Msrs Bill, Ben & Geoff and a "co.uk." signed by Nominet. And it might even be reasonable to consider the possiblity of Nominet being grumpy about finding the unauthorized republication of signed Nominet data by Msrs Bill, Ben & Geoff... don't you think? One should be careful to mind the huge gaps in thinking here, but it is a plausable argument to digitally sign your zones & data. > Cheers, > Ben. --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 Fri May 28 12:12: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 MAA13264 for ; Fri, 28 May 2004 12:12:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTjup-000EP4-5A for namedroppers-data@psg.com; Fri, 28 May 2004 16:09:03 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTjul-000EO5-Nm for namedroppers@ops.ietf.org; Fri, 28 May 2004 16:08:59 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 2B331E7EBB; Fri, 28 May 2004 17:08:59 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: <20040528151621.GA13996@vacation.karoshi.com.> Message-Id: <20040528160859.2B331E7EBB@mx1.nominet.org.uk> Date: Fri, 28 May 2004 17:08:59 +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 bmanning@vacation.karoshi.com writes: > i've been told that digital signatures can be used as > legal evidence in some jurisdictions. if true, it is > conceivable that by my holding signed data indicates, > if not the path by which i received said data, who signed the > data. Hi Bill Thanks for the clarification. As you say, it's possible that RRSIGs could be used to show unambigiously that the data originated from a particular source, but it's unlikely that RRSIG data would be left in unauthorised copies of zones, if for no other reason than they would likely to be seen to consume storage unneccessarily. (I expect elaboration tools will summarily discard them!) 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: From owner-namedroppers@ops.ietf.org Fri May 28 14:10: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 OAA20537 for ; Fri, 28 May 2004 14:10:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTliI-000Fml-UM for namedroppers-data@psg.com; Fri, 28 May 2004 18:04:14 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTliH-000Flq-EM for namedroppers@ops.ietf.org; Fri, 28 May 2004 18:04:13 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E7EC319B738; Fri, 28 May 2004 13:59:48 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5947219B3FD; Fri, 28 May 2004 13:59:48 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1703188; Fri, 28 May 2004 14:04:11 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <16567.20826.302378.846966@giles.gnomon.org.uk> References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <16567.20826.302378.846966@giles.gnomon.org.uk> Date: Fri, 28 May 2004 14:01:11 -0400 To: Roy Badami From: Edward Lewis Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Cc: roy@dnss.ec, Edward Lewis , Roy Badami , Paul Vixie , 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:48 +0100 5/28/04, Roy Badami wrote: >What makes me nervous is a scenario where a V1 resolver can check >signatures on V2 records, and in particular can follow secure >delegations from a V2 zone, but can't do so in a secure manner. Ahh, this is a problem. In order for a v1-era verifier to validate that a potentially valid v2 denial exists, the v2 record has to be signed by at least two keys (of each crypto system) - the old and the new. What happens if a v2 denial record arrives with only a v1 signature? The assumption is that the v2 denial and the v1 denial have the same RR type. If they differ only by the substitution of the hash, then the v1-era verifier will treat it as v1. Recall that the notion of an RRset (always together, verifiable) is broken when if comes to the RRSIG set. It is possible that via a replay, I can remove the v2-indicating RRSIG without detection. As an aside - zones signers have multiple key algorithms to use now. When we talk about a new algorithm, a new algotithm per crypto system is assumed, right? E.g., RSA/SHA-1, v1 and RSA/SHA-1, v2; DSA v1 and DSA v2, etc. (Imagine introducing elliptic curve, do we have to add 2 algorithm numbers for it, v1 and v2. And what if we rev something again - v3? It's ugly.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 28 14: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 OAA20628 for ; Fri, 28 May 2004 14:11:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTliK-000Fnr-SQ for namedroppers-data@psg.com; Fri, 28 May 2004 18:04:16 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTliK-000FnE-0k for namedroppers@ops.ietf.org; Fri, 28 May 2004 18:04:16 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 817C719B3FD; Fri, 28 May 2004 13:59:51 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3AC4F19B777; Fri, 28 May 2004 13:59:50 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1703189; Fri, 28 May 2004 14:04:13 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20040528151621.GA13996@vacation.karoshi.com.> References: <20040527135425.GA10971@vacation.karoshi.com.> <20040528130303.GB13713@vacation.karoshi.com.> <20040528134257.A42ABE7E72@mx1.nominet.org.uk> <20040528151621.GA13996@vacation.karoshi.com.> Date: Fri, 28 May 2004 14:03:49 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: Confirming the Nominet position Cc: Geoffrey Sisson , 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:16 +0000 5/28/04, bmanning@vacation.karoshi.com wrote: > i've been told that digital signatures can be used as > legal evidence in some jurisdictions. if true, it is > conceivable that by my holding signed data indicates, > if not the path by which i received said data, who signed the > data. Evidence != conclusion. I'm sure a digital signature is worthless if the private key needed to generate it is "widely" known. Much like having the keys to a car that caused the accident doesn't mean you were driving it at the time. Sorry, I think I've strayed into a legal discussion... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 28 14:13: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 OAA20689 for ; Fri, 28 May 2004 14:13:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTlp9-000I6U-Lf for namedroppers-data@psg.com; Fri, 28 May 2004 18:11:19 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTlp8-000I6B-St for namedroppers@ops.ietf.org; Fri, 28 May 2004 18:11:18 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i4SIBEW4014422; Fri, 28 May 2004 18:11:14 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i4SIBEuB014419; Fri, 28 May 2004 18:11:14 GMT Date: Fri, 28 May 2004 18:11:13 +0000 From: bmanning@vacation.karoshi.com To: Derek Atkins Cc: bmanning@vacation.karoshi.com, Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position Message-ID: <20040528181113.GB14362@vacation.karoshi.com.> References: <20040527135425.GA10971@vacation.karoshi.com.> <20040528130303.GB13713@vacation.karoshi.com.> <20040528134257.A42ABE7E72@mx1.nominet.org.uk> <20040528151621.GA13996@vacation.karoshi.com.> 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.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 Fri, May 28, 2004 at 02:02:35PM -0400, Derek Atkins wrote: > bmanning@vacation.karoshi.com writes: > > > i've been told that digital signatures can be used as > > legal evidence in some jurisdictions. if true, it is > > conceivable that by my holding signed data indicates, > > if not the path by which i received said data, who signed the > > data. > > Except signatures can be removed. see above. in the example, I end up holding signed data. > I could remove it in my copy, so you > couldn't verify the origin of the document. and -you- are smarter than the average bear. :) > Watermarking needs to be performed _IN_ the document, not by a > signature. And all watermarking techniques have been shown to be > breakable via collusion of multiple recipients of the data. yes... note again (earlier in thread) that watermark was quoted. that was intentional. > -derek -- to unsubscribe send a message to namedroppers-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 May 28 14:44: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 OAA23201 for ; Fri, 28 May 2004 14:44:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTmIf-0000Ji-7r for namedroppers-data@psg.com; Fri, 28 May 2004 18:41:49 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTmIe-0000JS-38 for namedroppers@ops.ietf.org; Fri, 28 May 2004 18:41:48 +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; Fri, 28 May 2004 14:41:46 -0400 id 00135912.40B787EA.00005FB4 From: David Blacka Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 14:41:46 -0400 User-Agent: KMail/1.6.2 References: <16567.20826.302378.846966@giles.gnomon.org.uk> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405281441.46767.davidb@verisignlabs.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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday 28 May 2004 2:01 pm, Edward Lewis wrote: > At 15:48 +0100 5/28/04, Roy Badami wrote: > >What makes me nervous is a scenario where a V1 resolver can check > >signatures on V2 records, and in particular can follow secure > >delegations from a V2 zone, but can't do so in a secure manner. > > Ahh, this is a problem. In order for a v1-era verifier to validate > that a potentially valid v2 denial exists, the v2 record has to be > signed by at least two keys (of each crypto system) - the old and the > new. Y'all are confusing me. There are two ways of introducing non-backwards changes to DNSSEC being discussed at once here, I think. One way is to use "unknown" algorithm numbers. The behavior for DNSSECbis resolvers in this case has already been defined. If this method is being used, then, v2 using zones will appear to be unsigned to v2 unaware resolvers. There would be no way for a "V1 resolver" to check a "V2 zone". Signing with both known and "unknown" algorithms would cause the zone to just be broken. Another way would be to do something like add a version field to the NSEC record. This would require thought and DNSSECbis changes to specify what the DNSSECbis compliant behavior is in the face of an unknown NSEC version. Presumably, however, since this signalling would be done through the NSEC record and not RRSIG, it *would* be possible for chain of trust to be established by a v1 resolver through a v2 zone. > As an aside - zones signers have multiple key algorithms to use now. > When we talk about a new algorithm, a new algotithm per crypto system > is assumed, right? E.g., RSA/SHA-1, v1 and RSA/SHA-1, v2; DSA v1 and > DSA v2, etc. > > (Imagine introducing elliptic curve, do we have to add 2 algorithm > numbers for it, v1 and v2. And what if we rev something again - v3? > It's ugly.) Indeed. -- 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 Fri May 28 15: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 PAA24510 for ; Fri, 28 May 2004 15:00:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTmXt-0004aq-Hd for namedroppers-data@psg.com; Fri, 28 May 2004 18:57:33 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTmXp-0004YO-3L for namedroppers@ops.ietf.org; Fri, 28 May 2004 18:57:29 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4SIvQlZ043875 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 28 May 2004 18:57:28 GMT (envelope-from roy+dated+1088362717.3d31ef@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4SIvNso000449 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 28 May 2004 19:57:25 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4SIwbcl063616 for ; Fri, 28 May 2004 19:58:37 +0100 (BST) (envelope-from roy+dated+1088362717.3d31ef@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4SIwb3A063615 for namedroppers@ops.ietf.org; Fri, 28 May 2004 19:58:37 +0100 (BST) (envelope-from roy+dated+1088362717.3d31ef@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 28 May 2004 19:58:35 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16567.35803.237199.333100@giles.gnomon.org.uk> Date: Fri, 28 May 2004 19:58:35 +0100 To: Edward Lewis Cc: roy@dnss.ec, Paul Vixie , namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) In-Reply-To: References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <16567.20826.302378.846966@giles.gnomon.org.uk> 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-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 >>>>> "Edward" == Edward Lewis writes: Edward> Ahh, this is a problem. In order for a v1-era verifier to Edward> validate that a potentially valid v2 denial exists, the v2 Edward> record has to be signed by at least two keys (of each Edward> crypto system) - the old and the new. I'm not sure I follow. The v1-era verifier will presumably never be able to tell whether the v2 denial is valid, so I'm not sure this solves the problem. Given a malfeasor can always fool a v1-era verifier into believing a delegation from a v2 zone is insecure (by providing a denial of the existence of a DS record -- that the v1-era resolver can't verify), I think it is desirably that a v1-verifier *always* regards a delegation from a v2-zone as insecure. This avoids a false expectation of security. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 28 15:32: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 PAA27326 for ; Fri, 28 May 2004 15:32:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTn25-000AdX-Vb for namedroppers-data@psg.com; Fri, 28 May 2004 19:28:45 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTn24-000Acx-W5 for namedroppers@ops.ietf.org; Fri, 28 May 2004 19:28:45 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id F02A319B8B9; Fri, 28 May 2004 15:24:18 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 708F819B766; Fri, 28 May 2004 15:24:18 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1703589; Fri, 28 May 2004 15:28:43 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <16567.35803.237199.333100@giles.gnomon.org.uk> References: <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <16567.20826.302378.846966@giles.gnomon.org.uk> <16567.35803.237199.333100@giles.gnomon.org.uk> Date: Fri, 28 May 2004 15:28:41 -0400 To: Roy Badami From: Edward Lewis Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Cc: Edward Lewis , roy@dnss.ec, Paul Vixie , 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 19:58 +0100 5/28/04, Roy Badami wrote: >existence of a DS record -- that the v1-era resolver can't verify), I >think it is desirably that a v1-verifier *always* regards a delegation >from a v2-zone as insecure. This avoids a false expectation of If when you are confused you fail "open" you are very vulnerable. Ever try to just confuse a security guard to gain access to a building? When it works, it's usually bad for the building (owner). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 28 15:43: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 PAA28164 for ; Fri, 28 May 2004 15:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTnEA-000DT6-90 for namedroppers-data@psg.com; Fri, 28 May 2004 19:41:14 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTnE8-000DS3-TR for namedroppers@ops.ietf.org; Fri, 28 May 2004 19:41:12 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4SJfCOX012069; Fri, 28 May 2004 12:41:12 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 28 May 2004 12:41:11 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'David Blacka'" , namedroppers@ops.ietf.org Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Date: Fri, 28 May 2004 12:41:11 -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 > If this method is being used, then, v2 using zones will > appear to be unsigned > to v2 unaware resolvers. There would be no way for a "V1 > resolver" to check > a "V2 zone". Signing with both known and "unknown" > algorithms would cause > the zone to just be broken. Could we maybe as a compromise agree now that the only difference between v1 and v2 will be that in v2 a new versioned NSEC record would be used? We do not make any changes to the DNSSECbis document set at all. We write a new short note that says that the V2 identifier is reserved for servers that support NSEC-V, the versioned variant of NSEC. At that point it is possible to start deployment of DNSSEC aware 'stuff' even though we do not have the new NSEC record defined. That 'stuff' can also make partial use of information from a V2 zone, even though there will be certain attacks that are still possible. This compromise would mean that we can go ahead and start deployment on the original schedule. The only difference would be that .uk and .de would start deployment using the V2 identifier and they would have to wait until we define NSECV before they can publish any form of NXT. Worst case this would mean that we burn a version identifier. I think we can live with that. We also get early experience of transitioning the system and code has to be written with this in mind. So far I have avoided comment on the NSEC2 proposal itself. I cannot believe that is going to be the final answer either. 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 Fri May 28 18:11: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 SAA12530 for ; Fri, 28 May 2004 18:11:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTpV7-000Ncz-FJ for namedroppers-data@psg.com; Fri, 28 May 2004 22:06:53 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTpV3-000NcV-1B for namedroppers@ops.ietf.org; Fri, 28 May 2004 22:06:50 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 0A96F19B765; Fri, 28 May 2004 18:02:19 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5029E19B6B7; Fri, 28 May 2004 18:02:14 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1704108; Fri, 28 May 2004 18:06:38 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 28 May 2004 18:06:34 -0400 To: "Hallam-Baker, Phillip" From: Edward Lewis Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Cc: "'David Blacka'" , 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.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:41 -0700 5/28/04, Hallam-Baker, Phillip wrote: >Could we maybe as a compromise agree now that the only difference >between v1 and v2 will be that in v2 a new versioned NSEC >record would be used? I don't think there's been an agreement that there ought to be an answer to zone enumeration. I've been analyzing the possibility of 1) allowing there to be a way forward and 2) adoption of the NSEC2 proposal in case we decided this is to be pursued. I'm not convinced that we need to defend against zone enumeration. I'm all for providing this if it were easy to accomplish. I have yet to see a way to provide a seamless way to convert from NSEC to another approach to authenticated denial (for any purpose). (Hmmm, perhaps detailing what happens if the NSEC claims that it itself doesn't exist - but that's been tried before and failed.) I think that the NSEC2 is capable of obfuscating the zone's contents, but can do so only at a greater cost. This cost can be gamed by the client and has the potential to be rather high. I'd put my opinions this way - if providing a way forward were easy and/or if providing obfuscation was cheap to do, I'd be for it. But from the work I've done, the costs to do either seem to be rather high, meaning that there has to be a lot of need to provide them. >We write a new short note that says that the V2 identifier is >reserved for servers that support NSEC-V, the versioned variant >of NSEC. What is the V2 identifier? >Worst case this would mean that we burn a version identifier. There's no version identifier in the current definition of DNSSECbis, one of the premises was to this proposal was that there would be no need to change the documents. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Even the voices inside my head are refusing to talk to me anymore. -- to unsubscribe send a message to namedroppers-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 May 28 19:53: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 TAA18248 for ; Fri, 28 May 2004 19:53:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTr5j-0006ri-2S for namedroppers-data@psg.com; Fri, 28 May 2004 23:48:47 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTr5h-0006rE-Vx for namedroppers@ops.ietf.org; Fri, 28 May 2004 23:48:46 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i4SNmiUT022849; Fri, 28 May 2004 16:48:44 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Fri, 28 May 2004 16:48:44 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Edward Lewis'" , "Hallam-Baker, Phillip" Cc: "'David Blacka'" , namedroppers@ops.ietf.org Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Date: Fri, 28 May 2004 16:48:41 -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 > At 12:41 -0700 5/28/04, Hallam-Baker, Phillip wrote: > >Could we maybe as a compromise agree now that the only difference > >between v1 and v2 will be that in v2 a new versioned NSEC > >record would be used? > > I don't think there's been an agreement that there ought to be an > answer to zone enumeration. I think you are missing the point that I and Olafur have been making. What the requirements may be is not the subject under discussion. The issue under discussion is whether we have to fix DNSSECbis. The quickest way to arrive at a consensus that we do not have to change DNSSECbis is to convince the Europeans that deployment of DNSSECbis as it stands will not preclude a future ammendment to address an issue they consider a deployment showstopper. -- to unsubscribe send a message to namedroppers-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 May 28 23:20: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 XAA26486 for ; Fri, 28 May 2004 23:20:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTuKX-000GAG-EP for namedroppers-data@psg.com; Sat, 29 May 2004 03:16:17 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTuKT-000G9G-4p for namedroppers@ops.ietf.org; Sat, 29 May 2004 03:16:13 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id PAA12333 for ; Sat, 29 May 2004 15:16:11 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i4T3GBfw058801 for ; Sat, 29 May 2004 15:16:11 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org From: don@plugh.daedalus.co.nz Subject: Re: Confirming the Nominet position In-Reply-To: Your message of "Thu, 27 May 2004 21:21:59 GMT." <20040527212159.B163013DE9@sa.vix.com> Date: Sat, 29 May 2004 15:16:11 +1200 Message-ID: <58800.1085800571@toybsd.zl2tnm.gen.nz> 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 Paul Vixie wrote: >i disagree. when i put the first AXFR-blocking code into BIND 4 in ~1988, >i considered it a protocol violation and i made my apologies to the gods. Unfortunately, protocols designed in a kinder, gentler age have had to be modified or "broken" to accommodate policy and security requirements brought on by the somewhat nastier world that the Internet has become. Every firewall on the planet basically represents a set of protocol violations. Some of them better considered than others. It seems to me somewhat ironic that in attempting to deal with some of the nastiness, DNSSECbis deployment itself faces problems because of another facet of that very same nastiness. >it appears that those gods have a long memory, and a grand scale of >vengeance. -- don -- to unsubscribe send a message to namedroppers-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 May 29 02:15: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 CAA16975 for ; Sat, 29 May 2004 02:15:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTx3E-000OXa-Ha for namedroppers-data@psg.com; Sat, 29 May 2004 06:10:36 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTx3B-000OX9-Nr for namedroppers@ops.ietf.org; Sat, 29 May 2004 06:10:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2BFE213960 for ; Sat, 29 May 2004 06:10:33 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: planned obsolescence, and another TCR In-Reply-To: Message from Edward Lewis of "Fri, 28 May 2004 18:06:34 -0400." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 29 May 2004 06:10:33 +0000 Message-Id: <20040529061033.2BFE213960@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'd put my opinions this way - if providing a way forward were easy > and/or if providing obfuscation was cheap to do, I'd be for it. But > from the work I've done, the costs to do either seem to be rather > high, meaning that there has to be a lot of need to provide them. i have a similar conclusion, which is that if we want NSEC to be upgradeable then it's going to take (at least) some period of time to find out whether it already is, which will take some modelling. if it's not already upgradeable, then it'll take some additional period to decide how to make it so, which should include competing alternatives, independent modelling/analysis/review, prototyping, and testing. i'm calling the first period six weeks, since i know how namedroppers works. it could be longer, since it's coming up on summer in a lot of places, and a lot of namedroppers children will be out of school, and there will be some vacations. if there is a second period (see above) then NSD 2.0 will become out-of-date, and BIND 9.3.0 (now in beta testing but maybe in release candidacy or actual release by that time) will become out-of-date, and then the second period is probably around four months, maybe longer since it will overlap with end-of-year holidays. since we know that we can push out replacement dnssec technology by using different type codes for it and changing the time scale from months to years, it is my hope that on june 1 when WGLC ends, the chairs will recognize that the dnssec-bis docset appears to meet its design goals and appears to have adequate document quality and adequate protocol quality, and forward the documents to IESG for publication. and then, depending on funding and other resources, this WG can start work on a DNSSECv2 that uses different type codes to operate "like ships in the night" with DNSSECv1 and can take a year or even longer to ensure that its design matches the community's then-current requirements and that it is implemented straightforwardly and that deployment considerations are known and handled from day 1. it can even share/reuse keys, and could have a gateway back to DNSSECv1. but it would not be "DNSSECv1 with versions", since the time between now and when we'll know whether that's possible is longer than many of us want to wait. and because DNSSECv1 appears to have achieved its design goals, which did not include confidentiality. -- to unsubscribe send a message to namedroppers-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 May 29 07:12: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 HAA28124 for ; Sat, 29 May 2004 07:12:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BU1fV-000JZM-0V for namedroppers-data@psg.com; Sat, 29 May 2004 11:06:25 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BU1fT-000JY9-EM for namedroppers@ops.ietf.org; Sat, 29 May 2004 11:06:23 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id XAA14237 for ; Sat, 29 May 2004 23:06:22 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i4TB6Mfw084494 for ; Sat, 29 May 2004 23:06:22 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org From: don@plugh.daedalus.co.nz Subject: Re: NSEC+ and NO In-Reply-To: Your message of "Thu, 27 May 2004 14:06:11 GMT." <20040527140611.2E25913951@sa.vix.com> Date: Sat, 29 May 2004 23:06:22 +1200 Message-ID: <84493.1085828782@toybsd.zl2tnm.gen.nz> 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 Paul Vixie wrote: >in your previous post you proposed a signalling method that would make us >treat all negative responses as temporary failures. that's not a value add. No, it isn't. But it still leaves us with a problem. It will be difficult to sell DNSSECbis to registries, especially ones such as NZ and UK that have wide, largely non-technical stakeholder bases, for reasons that are wider than the immediate technical validity of DNSSECbis, but are nevertheless neither invalid nor entirely non-technical, if the zone walking problem is not addressed. I see a number of ways forward with this from a registry point of view: (1) Deploy DNSSECbis regardless. Don't care about the stakeholders. (2) Wait for DNSSECter to come along (be it NSEC2 or some kind of NO). (3) Deploy DNSSECbis with some level of degradation to either disable zone walking or make it sufficiently difficult (and therefore uncommon) that registry managers can reasonably go after perpetrators by other means. Maintain that level of degradation until DNSSECter is available, and switch at the first opportunity. Option (1) is not going to fly in NZ at least, and from what I've seen on this list, not in UK or DE either. Option (2) is the safest choice. But it's not going to help advance DNSSEC. I can't speak for other registries, but in NZ, there is a stated desire to move forward with DNSSEC as far as it is compatible with other policies and requirements. Which leaves option (3). To which the question is: how far does DNSSEC, or at least NSEC, need to be "broken" to prevent zone walking. I put two options to the list in earlier posts; (a) one where the links between names are broken just a little, the other (b) where the NSEC links are completely broken. (a) retains authenticated denial for all but a few highly pathological cases, but appears trivial to defeat. (b) loses authenticated denial for all non-existent domains, but will reliably prevent zone walking. Is there a variation on (a) that can't be trivially defeated (my preferred option); or do I have to deploy (b), which still buys us secure delegation and authenticated denial of secure delegation for domains that do exist. Or should I just throw my hands up in despair, say, "it's too big, too slow, and we can just use end-to-end authentication & encryption anyway", as I'm sure the folks peddling PKI & CA services would just love me to? -- don -- to unsubscribe send a message to namedroppers-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 May 29 09:23: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 JAA03390 for ; Sat, 29 May 2004 09:23:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BU3jr-000CvB-LM for namedroppers-data@psg.com; Sat, 29 May 2004 13:19:03 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BU3jq-000Cuh-GU for namedroppers@ops.ietf.org; Sat, 29 May 2004 13:19:02 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4TDIwlZ005192 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sat, 29 May 2004 13:19:00 GMT (envelope-from roy+dated+1088428814.c96bae@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4TDIvso004949 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 29 May 2004 14:18:58 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4TDKEmP067926 for ; Sat, 29 May 2004 14:20:14 +0100 (BST) (envelope-from roy+dated+1088428814.c96bae@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4TDKEXg067925 for namedroppers@ops.ietf.org; Sat, 29 May 2004 14:20:14 +0100 (BST) (envelope-from roy+dated+1088428814.c96bae@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sat, 29 May 2004 14:20:13 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16568.36364.702734.481383@giles.gnomon.org.uk> Date: Sat, 29 May 2004 14:20:12 +0100 To: don@plugh.daedalus.co.nz Cc: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: <84493.1085828782@toybsd.zl2tnm.gen.nz> References: <20040527140611.2E25913951@sa.vix.com> <84493.1085828782@toybsd.zl2tnm.gen.nz> 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-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 >>>>> "don" == don writes: don> Which leaves option (3). To which the question is: how far don> does DNSSEC, or at least NSEC, need to be "broken" to prevent don> zone walking. I put two options to the list in earlier don> posts; (a) one where the links between names are broken just don> a little, the other (b) where the NSEC links are completely don> broken. If you don't mind online signing, you could synthesize a zone in which every possible name exists and has, say, a TXT record saying "non-existent domain". This might make you unpopular with people who use domain-existence checks as an anti-spam measure, though... -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 Sat May 29 11:14: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 LAA08182 for ; Sat, 29 May 2004 11:14:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BU5Sr-0004Rs-33 for namedroppers-data@psg.com; Sat, 29 May 2004 15:09:37 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BU5Sq-0004Rb-6o for namedroppers@ops.ietf.org; Sat, 29 May 2004 15:09:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9DB3413960 for ; Sat, 29 May 2004 15:09:35 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from don@plugh.daedalus.co.nz of "Sat, 29 May 2004 23:06:22 +1200." <84493.1085828782@toybsd.zl2tnm.gen.nz> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 29 May 2004 15:09:35 +0000 Message-Id: <20040529150935.9DB3413960@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 > >in your previous post you proposed a signalling method that would make us > >treat all negative responses as temporary failures. that's not a value add. > > No, it isn't. But it still leaves us with a problem. yes, and let's give that problem a name. "dnssec-bis's design does not include certain confidentiality features which a number of domainholders appear to want or need." in other words let's call this a design change rather than a quality problem with either the current docset or current protocol. this distinction matters to our WG chairs for administrative reasons, whereas the design change will only matter to IESG. we may in fact have hit the target we were aiming at, but some say it was the wrong target. > ... > I see a number of ways forward with this from a registry point of view: > ... > (2) Wait for DNSSECter to come along (be it NSEC2 or some kind of NO). > ... > Option (2) is the safest choice. But it's not going to help advance > DNSSEC. yes, it will. dnssec can still be deployed in a lot of places, including the root zone and many TLDs including SE and NL. there are four different "islands of trust" models floating around in various research camps that could cause a lot of dnssec deployment to occur even excluding NZ, UK, DE, and probably COM and NET who all object to the enumerability of subdomain names under dnssec-bis. > ... > (3) Deploy DNSSECbis with some level of degradation to either disable > zone walking or make it sufficiently difficult (and therefore uncommon) > that registry managers can reasonably go after perpetrators by other > means. Maintain that level of degradation until DNSSECter is available, > and switch at the first opportunity. > ... > Which leaves option (3). To which the question is: how far does DNSSEC, > or at least NSEC, need to be "broken" to prevent zone walking. ... i consider option (2) to be quite viable. i've also spoken (on the "new TCR" thread i began 12 hours ago) of the dangers of trying to change the dnssec-bis design at this late date. those of us who are itching to begin deployment during 2004, which is the tenth year since dnssec was first spoken of, are shaking with fear of any form of option (3). > ... > Or should I just throw my hands up in despair, say, "it's too big, too > slow, and we can just use end-to-end authentication & encryption > anyway", as I'm sure the folks peddling PKI & CA services would just > love me to? i think you should read the "new TCR" thread, and i think that all of the domainholders who can't tolerate enumeration should contact jim reid to talk about joining dns-moda and making DNSSEC-ter a first year priority. and that you should study auto-msj, auto-johani, dlv, and any possible other island-of-trust brokerage mechanism that could be used for early deployment by your subdomainholders. -- to unsubscribe send a message to namedroppers-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 May 29 19: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 TAA27230 for ; Sat, 29 May 2004 19:18:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUD0c-0008oB-AW for namedroppers-data@psg.com; Sat, 29 May 2004 23:12:58 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUD0a-0008ne-4Q for namedroppers@ops.ietf.org; Sat, 29 May 2004 23:12:57 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4TNCqlZ027016 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sat, 29 May 2004 23:12:54 GMT (envelope-from roy+dated+1088464450.28c046@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4TNCpso007250 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 30 May 2004 00:12:52 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4TNEAYW070842 for ; Sun, 30 May 2004 00:14:10 +0100 (BST) (envelope-from roy+dated+1088464450.28c046@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4TNEArW070841 for namedroppers@ops.ietf.org; Sun, 30 May 2004 00:14:10 +0100 (BST) (envelope-from roy+dated+1088464450.28c046@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Sun, 30 May 2004 00:13:59 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16569.6455.83241.185567@giles.gnomon.org.uk> Date: Sun, 30 May 2004 00:13:59 +0100 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: <20040529150935.9DB3413960@sa.vix.com> References: <84493.1085828782@toybsd.zl2tnm.gen.nz> <20040529150935.9DB3413960@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 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-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 writes: Paul> yes, and let's give that problem a name. "dnssec-bis's Paul> design does not include certain confidentiality features Paul> which a number of domainholders appear to want or need." in Paul> other words let's call this a design change rather than a Paul> quality problem with either the current docset or current Paul> protocol. this distinction matters to our WG chairs for Paul> administrative reasons, whereas the design change will only Paul> matter to IESG. we may in fact have hit the target we were Paul> aiming at, but some say it was the wrong target. Was there ever a well-specified target? Though I tend to agree that the specs have met the target that the WG felt it was working towards (not that I've followed the WG closely). Paul> i consider option (2) to be quite viable. i've also spoken Paul> (on the "new TCR" thread i began 12 hours ago) of the Paul> dangers of trying to change the dnssec-bis design at this Paul> late date. those of us who are itching to begin deployment Paul> during 2004, which is the tenth year since dnssec was first Paul> spoken of, are shaking with fear of any form of option (3). I'm one of the many people you mentioned in passing in a previous thread who had been waiting until the docs are declared 'finished' before paying close attention to them. I share your fear of option (3) even if that might not be obvious from some of my recent posts. Although my ideal scenario would be for Nominet and the IETF to reach a consensus, new specs (if necesary) be drafted, and DNSSEC be depolyed both in the root and in .uk all within 2004, this clearly isn't goint to happen... Islands of trust would seem to be inevitable during the early stages of deployment, and I thank you for the references on this subject... -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 vaf_press@mail.com Sat May 29 19:29:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27936 for ; Sat, 29 May 2004 19:29:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUDGD-00062D-Js for dnsext-archive@ietf.org; Sat, 29 May 2004 19:29:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUDEj-0005Ye-00 for dnsext-archive@ietf.org; Sat, 29 May 2004 19:27:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BUDDl-0005Bu-00; Sat, 29 May 2004 19:26:33 -0400 Received: from [200.61.188.90] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BUDDV-0000xy-P2; Sat, 29 May 2004 19:26:26 -0400 From: "Atualidade Brasileira . xjh" To: rmonmib@ietf.org Subject: Revolução de 64 e esquecimento . kay X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 29 May 2004 19:26:26 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.1 required=5.0 tests=AWL,FORGED_MUA_EUDORA, HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE, MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID, SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora * 0.0 AWL AWL: Auto-whitelist adjustment

(ref.:acj) Aos caros amigos, aguardando, se possível, vossa valiosa opinião. Atenciosamente, Ferreira-Passos, Atualidade Brasileira.

Lindenberg:LinkToFreeTranslator (English, Español, Deutsche, Français, etc.)

Série Temas Patrulhados (7)

A Revolução de 64 e o esquecimento de sua razão de ser

No 40o. aniversário, o levantamento cívico-militar foi largamente comentado, mas a sua causa profunda, inexplicavelmente omitida, afirma Lindenberg

* No 40o. aniversário da Revolução de 31 de março de 1964, que depôs o presidente esquerdista João Goulart, o histórico episódio foi comentado, discutido e esmiuçado em dezenas de artigos e livros, a causa principal do movimento de 64 foi silenciada de maneira quase unânime por seus detratores, e também por não poucos de seus simpatizantes, constata Adolpho Lindenberg em artigo da Série Temas Patrulhados.

* 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, opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

* Neste artigo sobre a Revolução de 64, o autor explica que a sua causa profunda esteve nos rumos cada vez mais esquerdizantes do governo Goulart e na crescente reação do povo brasileiro contra tais rumos; e que as Marchas da Família com Deus e pela Liberdade expressaram bem a inconformidade não somente da classe média, mas da grande maioria da população brasileira para com a comunização do país (SolicitoGratuitamenteEsteArtigoCompleto).

* Se a Revolução não tivesse ocorrido, tudo indica que nosso país teria evoluído para um regime socialista, à semelhança da Cuba castrista, ou do Chile de Allende, continua o autor, acrescentando que as "reformas de base", incluindo uma radical reforma agrária, a política de estatizações e a "demonização" dos Estados Unidos, teriam sido apenas os passos iniciais de um vasto programa de socialização do país.

* Tudo isso, não só com o apóio das lideranças mais radicais, mas também com as "bênçãos" da chamada "esquerda católica". É o que se depreende da ideologia e das metas de figuras exponenciais da era janguista, a começar pelo próprio presidente Goulart, mas também por figuras civis e eclesiásticas de destaque na época, como Leonel Brizola, dom Hélder Câmara, Francisco Julião e outros.

* Pelo inegável apoio e participação de todas as camadas da população com que contou, a Revolução de 64 não pode ser reduzida a um "golpe militar", como pretendem as esquerdas, nem tampouco identificada inteiramente com os rumos e atos do regime militar que lhe sucedeu, ou desqualificada pelos censuráveis atos de torturas acontecidos durante esse regime.

* Entre outros esquecimentos a respeito da Revolução de 64, o articulista constata que os analistas brasileiros que neste 40o. aniversário abordaram o tema, não fizeram sequer uma referência ao papel fundamental do movimento Tradição, Família, Propriedade na criação do clima ideológico e psicológico, na opinião pública brasileira e católica, que levou à Revolução de 64 (EnviarGratuitamenteInfoTFP-Revolução64). O referido silêncio - talvez se pudesse falar até de "patrulhamento" - contrasta com diversos estudos de "brasilianistas" estrangeiros publicados ao longo dos anos, muitos deles de esquerda, que tiveram a honestidade intelectual de reconhecer esse papel fundamental da TFP (EnviarGratuitamenteInfoBrasilianistas ).

* A difusão do livro "Reforma Agrária - Questão de Consciência", escrito por Plinio Corrêa de Oliveira em colaboração com dois bispos e um economista, e as públicas polêmicas dessa entidade com membros da ala esquerda do episcopado e da Ação Católica, tiveram tal relevância que a elas aludiu o presidente Goulart, em tom amargo, em discurso televisionado ao País, um dia antes de sua queda (EnviarGratuitamenteDiscursoGoulart).

* O esquecimento da causa profunda e do contexto histórico nacional em que se deu a Revolução de 64 poderá trazer sérios prejuízos à chamada "memória histórica" do Brasil, pois as novas gerações se verão afetadas por uma espécie de "lacuna" ou "amnésia" a respeito desse período, ou, na melhor das hipóteses, passarão a serem (des)informadas por uma visão profundamente distorcida desse processo, conclui Lindenberg.

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: EnviarEsteArtigoCompletoGratuitamente(No.7)

Outros links gratuitos (e-Book e outros artigos):

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

ProximosArtigos

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática da Revolução de 64 abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:EmTermos

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder 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 Sat May 29 20:37: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 UAA00756 for ; Sat, 29 May 2004 20:37:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUEGo-00011U-EB for namedroppers-data@psg.com; Sun, 30 May 2004 00:33:46 +0000 Received: from [212.93.192.37] (helo=fe-ims2.awalnet.net.sa) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUEGm-00010c-J3 for namedroppers@ops.ietf.org; Sun, 30 May 2004 00:33:45 +0000 Received: from ju-msg-3.SABICJU.SABIC.COM ([212.116.203.2]) by fe-ims2.awalnet.net.sa (AwalNet Mail Server) with ESMTP id <0HYI005AW46ZGV@fe-ims2.awalnet.net.sa> for namedroppers@ops.ietf.org; Sun, 30 May 2004 03:33:03 +0300 (GMT) Received: from mail pickup service by ju-msg-3.SABICJU.SABIC.COM with Microsoft SMTPSVC; Sat, 29 May 2004 20:44:34 +0300 Received: from mail pickup service by ju-msg-3.SABICJU.SABIC.COM with Microsoft SMTPSVC; Sat, 29 May 2004 18:59:38 +0300 Received: from hq-msg-3.SABICHQ.SABIC.COM ([129.1.60.60]) by ju-msg-3.SABICJU.SABIC.COM with Microsoft SMTPSVC(5.0.2195.6713); Sat, 29 May 2004 09:25:15 +0300 Received: from hq-imss-1.SABICHQ.SABIC.COM ([10.70.3.20]) by hq-msg-3.SABICHQ.SABIC.COM with Microsoft SMTPSVC(5.0.2195.6713); Sat, 29 May 2004 09:25:10 +0300 Received: from fe-ims2 ([212.93.192.37]) by hq-imss-1.SABICHQ.SABIC.COM with InterScan Messaging Security Suite; Sat, 29 May 2004 09:25:10 +0300 Received: from psg.com ([147.28.0.62]) by fe-ims2.awalnet.net.sa(AwalNet Mail Server) with ESMTP id <0HYG004SCPUWIQ@fe-ims2.awalnet.net.sa>for qadrism@SABIC.com; Sat, 29 May 2004 09:25:45 +0300 (GMT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BTx3E-000OXa-Ha for namedroppers-data@psg.com; Sat, 29 May 2004 06:10:36 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTx3B-000OX9-Nr for namedroppers@ops.ietf.org; Sat, 29 May 2004 06:10:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2BFE213960 for ; Sat, 29 May 2004 06:10:33 +0000 (GMT envelope-from vixie@sa.vix.com) Date: Sat, 29 May 2004 06:10:33 +0000 From: Paul Vixie Subject: planned obsolescence, and another TCR In-reply-to: Message from Edward Lewis "of Fri, 28 May 2004 18:06:34 -0400." To: namedroppers@ops.ietf.org Message-id: <20040529061033.2BFE213960@sa.vix.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Content-transfer-encoding: 7BIT X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:4 M:4 S:4 R:4 (0.0000 0.0000) X-OriginalArrivalTime: 29 May 2004 06:25:10.0803 (UTC) FILETIME=[B19B6E30:01C44545] 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=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > ... > I'd put my opinions this way - if providing a way forward were easy > and/or if providing obfuscation was cheap to do, I'd be for it. But > from the work I've done, the costs to do either seem to be rather > high, meaning that there has to be a lot of need to provide them. i have a similar conclusion, which is that if we want NSEC to be upgradeable then it's going to take (at least) some period of time to find out whether it already is, which will take some modelling. if it's not already upgradeable, then it'll take some additional period to decide how to make it so, which should include competing alternatives, independent modelling/analysis/review, prototyping, and testing. i'm calling the first period six weeks, since i know how namedroppers works. it could be longer, since it's coming up on summer in a lot of places, and a lot of namedroppers children will be out of school, and there will be some vacations. if there is a second period (see above) then NSD 2.0 will become out-of-date, and BIND 9.3.0 (now in beta testing but maybe in release candidacy or actual release by that time) will become out-of-date, and then the second period is probably around four months, maybe longer since it will overlap with end-of-year holidays. since we know that we can push out replacement dnssec technology by using different type codes for it and changing the time scale from months to years, it is my hope that on june 1 when WGLC ends, the chairs will recognize that the dnssec-bis docset appears to meet its design goals and appears to have adequate document quality and adequate protocol quality, and forward the documents to IESG for publication. and then, depending on funding and other resources, this WG can start work on a DNSSECv2 that uses different type codes to operate "like ships in the night" with DNSSECv1 and can take a year or even longer to ensure that its design matches the community's then-current requirements and that it is implemented straightforwardly and that deployment considerations are known and handled from day 1. it can even share/reuse keys, and could have a gateway back to DNSSECv1. but it would not be "DNSSECv1 with versions", since the time between now and when we'll know whether that's possible is longer than many of us want to wait. and because DNSSECv1 appears to have achieved its design goals, which did not include confidentiality. -- to 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 Sat May 29 20:52: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 UAA00969 for ; Sat, 29 May 2004 20:52:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUEWv-0005Rg-QX for namedroppers-data@psg.com; Sun, 30 May 2004 00:50:25 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUEWs-0005Po-JA for namedroppers@ops.ietf.org; Sun, 30 May 2004 00:50:22 +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 i4U0oHNL021299; Sat, 29 May 2004 20:50:17 -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 i4U0oGOn016331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 May 2004 20:50:16 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i4U0oFYD019017; Sat, 29 May 2004 20:50:15 -0400 Subject: Re: planned obsolescence, and another TCR From: Greg Hudson To: Paul Vixie Cc: namedroppers@ops.ietf.org In-Reply-To: <20040529061033.2BFE213960@sa.vix.com> References: <20040529061033.2BFE213960@sa.vix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1085878215.7925.279.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 29 May 2004 20:50:15 -0400 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_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2004-05-29 at 02:10, Paul Vixie wrote: > i have a similar conclusion, which is that if we want NSEC to be > upgradeable then it's going to take (at least) some period of time to > find out whether it already is, which will take some modelling. It seems like, at the very least, it should be possible to rev all the DNSSEC record types, such that zones signed with DNSSECtre (which somehow magically solves the enumeration "problem" with compromising something equally important) appear unsigned to DNSSECbis-only resolvers. This plan might present an upgrade impediment to zones signed with DNSSECbis; they might have to choose between providing twice as much data or appearing unsigned to DNSSECbis-only resolvers. But if the only reason to upgrade to DNSSECtre is enumeration, then that choice has to be made anyway (either you didn't deploy DNSSECbis, or you did deploy it in spite of the enumeration concern, and you won't solve the enumeration concern without leaving behind DNSSECbis-only resolvers). -- to unsubscribe send a message to namedroppers-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 May 29 22:13: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 WAA02766 for ; Sat, 29 May 2004 22:13:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUFmd-0000x5-4m for namedroppers-data@psg.com; Sun, 30 May 2004 02:10:43 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUFmc-0000wr-9c for namedroppers@ops.ietf.org; Sun, 30 May 2004 02:10:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CB60313DE5 for ; Sun, 30 May 2004 02:10:41 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: planned obsolescence, and another TCR In-Reply-To: Message from Greg Hudson of "Sat, 29 May 2004 20:50:15 -0400." <1085878215.7925.279.camel@egyptian-gods.mit.edu> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 30 May 2004 02:10:41 +0000 Message-Id: <20040530021041.CB60313DE5@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 > It seems like, at the very least, it should be possible to rev all the > DNSSEC record types, such that zones signed with DNSSECtre (which > somehow magically solves the enumeration "problem" with compromising > something equally important) appear unsigned to DNSSECbis-only > resolvers. yes. this is what we did in TCR to invalidate the universe of RFC2535. > This plan might present an upgrade impediment to zones signed with > DNSSECbis; they might have to choose between providing twice as much > data or appearing unsigned to DNSSECbis-only resolvers. it won't be twice as much data. another EDNS0 option bit will have to be allocated to say "when i set the i-want-dnssec option, i really mean dnssec-ter". middleboxes who havn't cached an answer that was fetched using this option will go upstream (forward, using this option) and only data that was fetched using this option will be returned from a middlebox who is queried using this option. (that's what RRD and QDCOUNT>0 did in the original EDNS specification, it was a way of upgrading a hop-by-hop signalling method to end-to-end, and it would have worked, but we were a weary and wary group of folks by that point in the EDNS adventure...) > But if the only reason to upgrade to DNSSECtre is enumeration, then > that choice has to be made anyway (either you didn't deploy DNSSECbis, > or you did deploy it in spite of the enumeration concern, and you > won't solve the enumeration concern without leaving behind > DNSSECbis-only resolvers). speaking for bind, i think it would be necessary to support both -bis and -ter when signing (if that's what the zone operator asks for) and serving. DNSKEY wouldn't have to rev this time, only RRSIG and/or NSEC. it's even dimly possible that NSEC2 or RRSIG2 could be generated from NSEC or RRSIG, assuming that the new ones are subsets of the old, so that a -ter middlebox could synthesize -ter style responses if it had cached something from a -bis style response. the sky's the limit. as long as, that is, we don't try to do it before -bis. if we try to do it before -bis, then either -bis is late, or we have some unfortunate compromises whose sideeffects take a long time to become known, or more likely, both. -bis must go as is. TCR++ is the way to -ter. -- to unsubscribe send a message to namedroppers-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 May 29 22:19: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 WAA02935 for ; Sat, 29 May 2004 22:19:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUFsp-0002NM-Kc for namedroppers-data@psg.com; Sun, 30 May 2004 02:17:07 +0000 Received: from [212.93.192.37] (helo=fe-ims2.awalnet.net.sa) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUFsm-0002M8-GJ for namedroppers@ops.ietf.org; Sun, 30 May 2004 02:17:04 +0000 Received: from ju-msg-3.SABICJU.SABIC.COM ([212.116.203.2]) by fe-ims2.awalnet.net.sa (AwalNet Mail Server) with ESMTP id <0HYI007Y7902VA@fe-ims2.awalnet.net.sa> for namedroppers@ops.ietf.org; Sun, 30 May 2004 05:17:03 +0300 (GMT) Received: from mail pickup service by ju-msg-3.SABICJU.SABIC.COM with Microsoft SMTPSVC; Sat, 29 May 2004 20:52:23 +0300 Received: from mail pickup service by ju-msg-3.SABICJU.SABIC.COM with Microsoft SMTPSVC; Sat, 29 May 2004 19:01:10 +0300 Received: from hq-msg-3.SABICHQ.SABIC.COM ([129.1.60.60]) by ju-msg-3.SABICJU.SABIC.COM with Microsoft SMTPSVC(5.0.2195.6713); Sat, 29 May 2004 14:43:59 +0300 Received: from hq-imss-1.SABICHQ.SABIC.COM ([10.70.3.20]) by hq-msg-3.SABICHQ.SABIC.COM with Microsoft SMTPSVC(5.0.2195.6713); Sat, 29 May 2004 14:31:20 +0300 Received: from fe-ims1 ([212.93.192.34]) by hq-imss-1.SABICHQ.SABIC.COM with InterScan Messaging Security Suite; Sat, 29 May 2004 14:31:19 +0300 Received: from psg.com ([147.28.0.62]) by fe-ims1.awalnet.net.sa(AwalNet Mail Server) with ESMTP id <0HYH00I2B3ZL4M@fe-ims1.awalnet.net.sa>for qadrism@SABIC.com; Sat, 29 May 2004 14:30:59 +0300 (GMT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BU1fV-000JZM-0V for namedroppers-data@psg.com; Sat, 29 May 2004 11:06:25 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BU1fT-000JY9-EM for namedroppers@ops.ietf.org; Sat, 29 May 2004 11:06:23 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id XAA14237 for; Sat, 29 May 2004 23:06:22 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i4TB6Mfw084494 for; Sat, 29 May 2004 23:06:22 +1200 Date: Sat, 29 May 2004 23:06:22 +1200 From: don@plugh.daedalus.co.nz Subject: Re: NSEC+ and NO In-reply-to: "Your message of Thu, 27 May 2004 14:06:11 GMT." <20040527140611.2E25913951@sa.vix.com> To: namedroppers@ops.ietf.org Message-id: <84493.1085828782@toybsd.zl2tnm.gen.nz> Content-transfer-encoding: 7BIT X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:4 M:4 S:4 R:4 (0.0000 0.0000) X-OriginalArrivalTime: 29 May 2004 11:31:20.0788 (UTC) FILETIME=[76F8B140:01C44570] 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 Content-Transfer-Encoding: 7BIT Paul Vixie wrote: >in your previous post you proposed a signalling method that would make us >treat all negative responses as temporary failures. that's not a value add. No, it isn't. But it still leaves us with a problem. It will be difficult to sell DNSSECbis to registries, especially ones such as NZ and UK that have wide, largely non-technical stakeholder bases, for reasons that are wider than the immediate technical validity of DNSSECbis, but are nevertheless neither invalid nor entirely non-technical, if the zone walking problem is not addressed. I see a number of ways forward with this from a registry point of view: (1) Deploy DNSSECbis regardless. Don't care about the stakeholders. (2) Wait for DNSSECter to come along (be it NSEC2 or some kind of NO). (3) Deploy DNSSECbis with some level of degradation to either disable zone walking or make it sufficiently difficult (and therefore uncommon) that registry managers can reasonably go after perpetrators by other means. Maintain that level of degradation until DNSSECter is available, and switch at the first opportunity. Option (1) is not going to fly in NZ at least, and from what I've seen on this list, not in UK or DE either. Option (2) is the safest choice. But it's not going to help advance DNSSEC. I can't speak for other registries, but in NZ, there is a stated desire to move forward with DNSSEC as far as it is compatible with other policies and requirements. Which leaves option (3). To which the question is: how far does DNSSEC, or at least NSEC, need to be "broken" to prevent zone walking. I put two options to the list in earlier posts; (a) one where the links between names are broken just a little, the other (b) where the NSEC links are completely broken. (a) retains authenticated denial for all but a few highly pathological cases, but appears trivial to defeat. (b) loses authenticated denial for all non-existent domains, but will reliably prevent zone walking. Is there a variation on (a) that can't be trivially defeated (my preferred option); or do I have to deploy (b), which still buys us secure delegation and authenticated denial of secure delegation for domains that do exist. Or should I just throw my hands up in despair, say, "it's too big, too slow, and we can just use end-to-end authentication & encryption anyway", as I'm sure the folks peddling PKI & CA services would just love me to? -- don -- to 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 Sun May 30 06:30: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 GAA29752 for ; Sun, 30 May 2004 06:30:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUNVR-000Lci-0C for namedroppers-data@psg.com; Sun, 30 May 2004 10:25:29 +0000 Received: from [212.93.192.34] (helo=fe-ims1.awalnet.net.sa) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUNVM-000LZq-Vt for namedroppers@ops.ietf.org; Sun, 30 May 2004 10:25:25 +0000 Received: from ju-msg-3.SABICJU.SABIC.COM ([212.116.203.2]) by fe-ims1.awalnet.net.sa (AwalNet Mail Server) with ESMTP id <0HYI00LD9VGNAW@fe-ims1.awalnet.net.sa> for namedroppers@ops.ietf.org; Sun, 30 May 2004 13:22:03 +0300 (GMT) Received: from mail pickup service by ju-msg-3.SABICJU.SABIC.COM with Microsoft SMTPSVC; Sun, 30 May 2004 13:02:05 +0300 Received: from hq-msg-3.SABICHQ.SABIC.COM ([129.1.60.60]) by ju-msg-3.SABICJU.SABIC.COM with Microsoft SMTPSVC(5.0.2195.6713); Sun, 30 May 2004 05:20:58 +0300 Received: from hq-imss-1.SABICHQ.SABIC.COM ([10.70.3.20]) by hq-msg-3.SABICHQ.SABIC.COM with Microsoft SMTPSVC(5.0.2195.6713); Sun, 30 May 2004 05:20:41 +0300 Received: from fe-ims2 ([212.93.192.37]) by hq-imss-1.SABICHQ.SABIC.COM with InterScan Messaging Security Suite; Sun, 30 May 2004 05:20:35 +0300 Received: from psg.com ([147.28.0.62]) by fe-ims2.awalnet.net.sa(AwalNet Mail Server) with ESMTP id <0HYI007SX979US@fe-ims2.awalnet.net.sa>for qadrism@SABIC.com; Sun, 30 May 2004 05:21:10 +0300 (GMT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUFmd-0000x5-4m for namedroppers-data@psg.com; Sun, 30 May 2004 02:10:43 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUFmc-0000wr-9c for namedroppers@ops.ietf.org; Sun, 30 May 2004 02:10:42 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CB60313DE5 for ; Sun, 30 May 2004 02:10:41 +0000 (GMT envelope-from vixie@sa.vix.com) Date: Sun, 30 May 2004 02:10:41 +0000 From: Paul Vixie Subject: Re: planned obsolescence, and another TCR In-reply-to: Message from Greg Hudson "of Sat, 29 May 2004 20:50:15 -0400." <1085878215.7925.279.camel@egyptian-gods.mit.edu> To: namedroppers@ops.ietf.org Message-id: <20040530021041.CB60313DE5@sa.vix.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Content-transfer-encoding: 7BIT X-imss-version: 2.5 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:22 M:2 S:5 R:5 X-imss-settings: Baseline:1 C:4 M:4 S:4 R:4 (0.0000 0.0000) X-OriginalArrivalTime: 30 May 2004 02:20:41.0335 (UTC) FILETIME=[B4560070:01C445EC] 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=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > It seems like, at the very least, it should be possible to rev all the > DNSSEC record types, such that zones signed with DNSSECtre (which > somehow magically solves the enumeration "problem" with compromising > something equally important) appear unsigned to DNSSECbis-only > resolvers. yes. this is what we did in TCR to invalidate the universe of RFC2535. > This plan might present an upgrade impediment to zones signed with > DNSSECbis; they might have to choose between providing twice as much > data or appearing unsigned to DNSSECbis-only resolvers. it won't be twice as much data. another EDNS0 option bit will have to be allocated to say "when i set the i-want-dnssec option, i really mean dnssec-ter". middleboxes who havn't cached an answer that was fetched using this option will go upstream (forward, using this option) and only data that was fetched using this option will be returned from a middlebox who is queried using this option. (that's what RRD and QDCOUNT>0 did in the original EDNS specification, it was a way of upgrading a hop-by-hop signalling method to end-to-end, and it would have worked, but we were a weary and wary group of folks by that point in the EDNS adventure...) > But if the only reason to upgrade to DNSSECtre is enumeration, then > that choice has to be made anyway (either you didn't deploy DNSSECbis, > or you did deploy it in spite of the enumeration concern, and you > won't solve the enumeration concern without leaving behind > DNSSECbis-only resolvers). speaking for bind, i think it would be necessary to support both -bis and -ter when signing (if that's what the zone operator asks for) and serving. DNSKEY wouldn't have to rev this time, only RRSIG and/or NSEC. it's even dimly possible that NSEC2 or RRSIG2 could be generated from NSEC or RRSIG, assuming that the new ones are subsets of the old, so that a -ter middlebox could synthesize -ter style responses if it had cached something from a -bis style response. the sky's the limit. as long as, that is, we don't try to do it before -bis. if we try to do it before -bis, then either -bis is late, or we have some unfortunate compromises whose sideeffects take a long time to become known, or more likely, both. -bis must go as is. TCR++ is the way to -ter. -- to 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 Sun May 30 07:53: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 HAA02466 for ; Sun, 30 May 2004 07:53:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUOp1-000FPp-O5 for namedroppers-data@psg.com; Sun, 30 May 2004 11:49:47 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUOp0-000FPP-CM for namedroppers@ops.ietf.org; Sun, 30 May 2004 11:49:46 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 93FCE1FDCB; Sun, 30 May 2004 12:49:45 +0100 (BST) Date: Sun, 30 May 2004 12:49:32 +0100 From: Alex Bligh Reply-To: Alex Bligh To: don@plugh.daedalus.co.nz, namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: NSEC+ and NO Message-ID: <1036874717.1085921372@[192.168.100.5]> In-Reply-To: <84493.1085828782@toybsd.zl2tnm.gen.nz> References: <84493.1085828782@toybsd.zl2tnm.gen.nz> X-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 29 May 2004 23:06 +1200 don@plugh.daedalus.co.nz wrote: > (a) retains authenticated denial for all but a few highly pathological > cases, but appears trivial to defeat. (b) loses authenticated denial > for all non-existent domains, but will reliably prevent zone walking. Two questions: 1. Is there a situation where lack of authenticated denial can result in returning the wrong data in response to a query (meaning as opposed to returning no data when there isn't one)? - i.e. if NSEC were optional, does one leave oneself open to more than a denial of service attack where non-existence is spoofed? (I am asking here to what extent whether temporarily dropping authenticated denial in those zone operators with problems with enumerability is likely to be a fair price to pay). 2. Do people agree that, if lack of authenticated denial is itself an insuperable problem in zones for which NSEC enumerability is problematic, then, **IF** one is going to fix the problem at all, one might as well fix the enumerability problem in the general case (via NSEC2 or elsewise) rather than (say) provide an alternative mechanism of authenticated denial just for those not wishing to deploy NSEC, as the latter would involve just as much interoperability testing, development, specification etc. as the former. (I am asking here whether, if the problem is going to be addressed at all, whether NSEC2 or some similar NSEC replacement approach is in fact the best approach). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 30 07:53: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 HAA02484 for ; Sun, 30 May 2004 07:53:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUOqo-000Fzx-92 for namedroppers-data@psg.com; Sun, 30 May 2004 11:51:38 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUOqn-000Fzg-Ca for namedroppers@ops.ietf.org; Sun, 30 May 2004 11:51:37 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 9C16E1FDCB; Sun, 30 May 2004 12:51:36 +0100 (BST) Date: Sun, 30 May 2004 12:51:24 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Roy Badami , don@plugh.daedalus.co.nz Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC+ and NO Message-ID: <1036986758.1085921484@[192.168.100.5]> In-Reply-To: <16568.36364.702734.481383@giles.gnomon.org.uk> References: <20040527140611.2E25913951@sa.vix.com> <84493.1085828782@toybsd.zl2tnm.gen.nz> <16568.36364.702734.481383@giles.gnomon.org.uk> X-Mailer: Mulberry/3.1.1 (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 29 May 2004 14:20 +0100 Roy Badami wrote: > If you don't mind online signing, you could synthesize a zone in which > every possible name exists and has, say, a TXT record saying > "non-existent domain". > > This might make you unpopular with people who use domain-existence > checks as an anti-spam measure, though... I seem to remember a recent experience where a wildcard was put in one such zone did not meet with universal approbation. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 30 07: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 HAA02555 for ; Sun, 30 May 2004 07:56:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUOuG-000H3q-GN for namedroppers-data@psg.com; Sun, 30 May 2004 11:55:12 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUOuF-000H3E-Gc for namedroppers@ops.ietf.org; Sun, 30 May 2004 11:55:11 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C25F01FDCB; Sun, 30 May 2004 12:55:10 +0100 (BST) Date: Sun, 30 May 2004 12:54:58 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Roy Badami , Paul Vixie Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: NSEC+ and NO Message-ID: <1037200926.1085921698@[192.168.100.5]> In-Reply-To: <16569.6455.83241.185567@giles.gnomon.org.uk> References: <84493.1085828782@toybsd.zl2tnm.gen.nz> <20040529150935.9DB3413960@sa.vix.com> <16569.6455.83241.185567@giles.gnomon.org.uk> X-Mailer: Mulberry/3.1.1 (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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 30 May 2004 00:13 +0100 Roy Badami wrote: > Although my ideal scenario would be for Nominet and the IETF to reach > a consensus, new specs (if necessary) be drafted, and DNSSEC be > depolyed both in the root and in .uk all within 2004, this clearly > isn't goint to happen... If you replace the word deployed with deployable (*) I think that is a realistic target. As Jay indicated, we are happy to provide concrete assistance in getting there. (*) = production software ready to go. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 30 13:21: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 NAA16180 for ; Sun, 30 May 2004 13:21:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUTv6-0003ny-10 for namedroppers-data@psg.com; Sun, 30 May 2004 17:16:24 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUTv3-0003nK-0B for namedroppers@ops.ietf.org; Sun, 30 May 2004 17:16:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C1D5413960 for ; Sun, 30 May 2004 17:16:19 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from Alex Bligh of "Sun, 30 May 2004 12:54:58 +0100." <1037200926.1085921698@[192.168.100.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 30 May 2004 17:16:19 +0000 Message-Id: <20040530171619.C1D5413960@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 > > Although my ideal scenario would be for Nominet and the IETF to reach > > a consensus, new specs (if necessary) be drafted, and DNSSEC be > > depolyed both in the root and in .uk all within 2004, this clearly > > isn't goint to happen... > > If you replace the word deployed with deployable (*) I think that is > a realistic target. As Jay indicated, we are happy to provide concrete > assistance in getting there. > > (*) = production software ready to go. it's now the end of june. unless the change to dnssec-bis were as simple as "add an MBZ octet to DS, DNSKEY, RRSIG, and require current implementations to ignore RRs where this octet has a nonzero value" then we're not going to see "production software ready to go" again in 2004. patches are fine, but maturity has been a challenging issue for dnssec. in NSD 2.0 and BIND 9.3.0 we have production dnssec-bis software ready to go. change dnssec-bis more than the tiny amount described above, and we're into 2005 before we have enough maturity to again call it production ready, no matter what patches are developed or how good those patches are. i don't think the average person on namedroppers@ realizes how much pizza and late nights and whiteboards and "operability testing" went into stabilizing dnssec-bis and getting confidence that it would work. that's how "the grandparent problem" was found. that's how "TCR" was first proposed (and how "the middlebox problem" was found, which drove "TCR"). patch-and-publish is fine when the torchbearing mob is at the castle walls demanding a workaround for sitefinder. it's not fine when reworking dnssec. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 30 13:32:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16630 for ; Sun, 30 May 2004 13:32:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUU90-0008Dn-Az for namedroppers-data@psg.com; Sun, 30 May 2004 17:30:46 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUU8z-0008D9-I4 for namedroppers@ops.ietf.org; Sun, 30 May 2004 17:30:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E0FF013DE5 for ; Sun, 30 May 2004 17:30:44 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from Paul Vixie of "Sun, 30 May 2004 17:16:19 GMT." <20040530171619.C1D5413960@sa.vix.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 30 May 2004 17:30:44 +0000 Message-Id: <20040530173044.E0FF013DE5@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 mean of course.. > it's now the end of june. ...that it's now the end of may. -- to unsubscribe send a message to namedroppers-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 May 30 19: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 TAA01616 for ; Sun, 30 May 2004 19:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUZnT-000GUz-LJ for namedroppers-data@psg.com; Sun, 30 May 2004 23:32:55 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUZnR-000GUV-Tk for namedroppers@ops.ietf.org; Sun, 30 May 2004 23:32:54 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id LAA21787 for ; Mon, 31 May 2004 11:32:52 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i4UNWqfw002676 for ; Mon, 31 May 2004 11:32:52 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org From: Don Stokes Subject: Re: NSEC+ and NO In-Reply-To: Your message of "Sat, 29 May 2004 15:09:35 GMT." <20040529150935.9DB3413960@sa.vix.com> Date: Mon, 31 May 2004 11:32:52 +1200 Message-ID: <2675.1085959972@toybsd.zl2tnm.gen.nz> 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 Paul Vixie wrote: >yes, it will. dnssec can still be deployed in a lot of places, including >the root zone and many TLDs including SE and NL. there are four different >"islands of trust" models floating around in various research camps that >could cause a lot of dnssec deployment to occur even excluding NZ, UK, DE, >and probably COM and NET who all object to the enumerability of subdomain >names under dnssec-bis. From where I sit, the signing of the root zone is the real key to what we do. As far as the Internet at large is concerned, without the root and the majority of registries signing their zones, DNSSEC is just a toy. So the real question in my mind is, will DNSSECbis be deployed on the root? Or will it have to wait for DNSSECter. If the root zone is going to be signed using DNSSECbis, then NZ will want to be doing *something* with DNSSECbis. Which means some form of option (3). I know it gives you the shivers, but providing authenticated chains of trust for DNSSEC-enabled domains that do exist seems to me a heck of a lot more productive than futzing around with IoT brokerage schemes. Especially if we can do some type of option 3a rather than 3b and retain authenticated denial. >and that you should study auto-msj, auto-johani, dlv, and any possible >other island-of-trust brokerage mechanism that could be used for early >deployment by your subdomainholders. Islands of trust is not DNSSEC deployment as far as a TLD is concerned. Sub-domain holders can do what they like; that's why we call it delegation. In terms of specifications, I agree that trying to change DNSSECbis at this stage is probably pointless. We might as well get -bis out now, so that enterprise deployment can occur -- for the most part, enterprises don't have the same privacy concerns as registries for their internal networks and DNS, yet could still benefit from DNSSEC. Meanwhile, lets get on with DNSSECter for deployment on the public Internet. -- don -- to unsubscribe send a message to namedroppers-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 May 30 22:24: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 WAA07299 for ; Sun, 30 May 2004 22:24:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUcOA-000Bwa-9r for namedroppers-data@psg.com; Mon, 31 May 2004 02:18:58 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUcO9-000BwE-Dt for namedroppers@ops.ietf.org; Mon, 31 May 2004 02:18:57 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CB73013951 for ; Mon, 31 May 2004 02:18:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Message from Don Stokes of "Mon, 31 May 2004 11:32:52 +1200." <2675.1085959972@toybsd.zl2tnm.gen.nz> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 31 May 2004 02:18:56 +0000 Message-Id: <20040531021856.CB73013951@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 the real question in my mind is, will DNSSECbis be deployed on the > root? Or will it have to wait for DNSSECter. the root zone is ftp'able, axfr'able, and otherwise not considered a matter of confidential record. therefore i don't think enumerability will be an obstacle to signing the root. all of the rootops can now support dnssec-bis. therefore, it's down to the political problems like "who will know the signing key" and none of those depend on the presumed delta between -bis and -ter. > If the root zone is going to be signed using DNSSECbis, then NZ > will want to be doing *something* with DNSSECbis. Which means some form > of option (3). if you're willing to tolerate another type code roll ("TCR++" for short) then option 3 is on the table. if you think, for some reason, that some other form of extensibilty is necessary, then "option (3)" means "dnssec after 2004" which would seem like a really painful last minute course change after all the compromises and hard work that have gone into the "dnssec in 2004" effort. > > ... you should study auto-msj, auto-johani, dlv, and any possible > > other island-of-trust brokerage mechanism that could be used for > > early deployment by your subdomainholders. > > Islands of trust is not DNSSEC deployment as far as a TLD is concerned. > Sub-domain holders can do what they like; that's why we call it delegation. i think you need to study it more closely. your conclusions don't match the facts as i know them. i'm always willing to take this up 1x1, even by phone, if that seems palatable. > In terms of specifications, I agree that trying to change DNSSECbis at > this stage is probably pointless. We might as well get -bis out now, so > that enterprise deployment can occur -- for the most part, enterprises > don't have the same privacy concerns as registries for their internal > networks and DNS, yet could still benefit from DNSSEC. as the prime mover between one of the early deployment aids ("dlv") that creates islands of trust, i can tell you that my scope is far beyond my own local "enterprise". i think that msj and johani would say the same. so, please study these alternatives more closely before you conclude about them. > Meanwhile, lets get on with DNSSECter for deployment on the public > Internet. agreed. and hopefully, because you said that, you'll be hearing from jim reid about dns-moda. -- to unsubscribe send a message to namedroppers-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 May 31 01:00: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 BAA14030 for ; Mon, 31 May 2004 01:00:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUeqL-0002X5-T2 for namedroppers-data@psg.com; Mon, 31 May 2004 04:56:13 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUeqJ-0002Vj-Tc for namedroppers@ops.ietf.org; Mon, 31 May 2004 04:56:12 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i4V4u2BE069894 for ; Mon, 31 May 2004 00:56:02 -0400 (EDT) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i4V4u1Sm069893 for namedroppers@ops.ietf.org; Mon, 31 May 2004 00:56:01 -0400 (EDT) Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BU0vM-000AdR-74 for namedroppers@ops.ietf.org; Sat, 29 May 2004 10:18:44 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id WAA14004 for ; Sat, 29 May 2004 22:18:43 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i4TAIgfw082084 for ; Sat, 29 May 2004 22:18:42 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) From: don%plugh@daedalus.co.nz To: namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position In-Reply-To: Your message of "Fri, 28 May 2004 18:13:25 +0700." <17887.1085742805@munnari.OZ.AU> Date: Sat, 29 May 2004 22:18:42 +1200 Message-ID: <82083.1085825922@toybsd.zl2tnm.gen.nz> 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 [ 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. ] Robert Elz wrote: >Please don't tell me "our stakeholders demand it" - like Ted Hardie, >mention of "stakeholders" in a context like that drives me insane. If >your stakeholders (whatever that means) have good reasons, just tell me >the reasons. If they don't, then they're irrelevant to me, and should be >to you as well. The reason in NZ is basically abuse. If a registry provided a full list of domains (or a means of obtaining one without strict conditions), one can pretty much guarantee that within a short space of time that list will be used (at a minimum) to construct a spam list either using harvested whois data and/or guessed mailbox names. Such behaviour in the past has caused astonishing amounts of outrage, hence NZ's current policy. For NZ, the immediate positive impact of implementing DNSSECbis is, in the absence of wide-scale awareness and deployment, and the absence of a signed root, is basically nothing, beyond the feel-good factor of being on the leading edge. That "nothing" should become "something" eventually, but over a timescale of years. The negative impact is the immediate availability of a full list of current names for spam and other forms of abuse, something that is likely to be highly unpopular among those with an interest in NZ DNS policy. That makes being an early adopter of DNSSEC a difficult sell unless the zone walking issue is addressed. That's on top of more technical issues such as the additional time and resources required to sign large registry zones. I can't say I like the word "stakeholder" very much either, but in this case the "stakeholders" are the ones paying the piper, and a registry ignores them at its peril. I speak from bitter experience on this. -- don -- to unsubscribe send a message to namedroppers-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 May 31 06:44: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 GAA11889 for ; Mon, 31 May 2004 06:44:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUkC1-0000I2-8v for namedroppers-data@psg.com; Mon, 31 May 2004 10:38:57 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUkBz-0000Ha-8i for namedroppers@ops.ietf.org; Mon, 31 May 2004 10:38:55 +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 i4VAcogF042242; Mon, 31 May 2004 12:38:51 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4VAclD6025192; Mon, 31 May 2004 12:38:47 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4VAck2e025189; Mon, 31 May 2004 12:38:46 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 31 May 2004 12:38:46 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: planned obsolescence, and another TCR In-Reply-To: <20040529061033.2BFE213960@sa.vix.com> Message-ID: References: <20040529061033.2BFE213960@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, OPT_IN,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 29 May 2004, Paul Vixie wrote: > > I'd put my opinions this way - if providing a way forward were easy > > and/or if providing obfuscation was cheap to do, I'd be for it. But > > from the work I've done, the costs to do either seem to be rather > > high, meaning that there has to be a lot of need to provide them. > > i have a similar conclusion, which is that if we want NSEC to be > upgradeable then it's going to take (at least) some period of time to > find out whether it already is, which will take some modelling. if it's > not already upgradeable, then it'll take some additional period to > decide how to make it so, which should include competing alternatives, > independent modelling/analysis/review, prototyping, and testing. There are many possibilities to start an upgrade path, versioning and such. The REAL problem is specifying resolver behaviour when it encounters an unknown vesion of NSEC. It will introduce numerous cornercases since NSEC is used in both negative and positive proofs (this is not FUD, there were some cornercases in the past when we're trying to model opt-in). It also needs to be tested very well. CAIDA has recently done some modelling http://www.caida.org/outreach/papers/2004/dnspam/ and one of the conclusions is that resolvers tend to become aggressive when denied certain data. Ignoring incompatible NSEC versions is exactly what that is. Being one of the authors of the docset and knowing how much effort it took to get here from where we were 4 to 5 years ago, it will be another year _atleast_ before something as little as an MBZ will make it through. Going over the docset again, there are many hooks that needs eyes and text in case the wg decides on versioning. I'm not saying we shouldn't, but before we get to where we are now with rough consensus and running code,it will be another two years. To my frustration, I think we've REALLY missed the bus on NSEC, since everything from label types to packetsize, from header bits to transaction signatures _is_ extendable, while a few of the big namedroppers mud-fights were due to lack of NSEC versioning. Having said that, my conclusion is to ship the docset now and get some real experience in userland. A TCR++ degauss of DNSKEY/NSEC in the near future can introduce a version scheme for NSEC. That would probably also take some time, and is bw compatible with DNSSECbis, but at least we can move forward now. 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 May 31 08:06: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 IAA15137 for ; Mon, 31 May 2004 08:06:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUlTm-000IZG-4p for namedroppers-data@psg.com; Mon, 31 May 2004 12:01:22 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUlTj-000IXI-51 for namedroppers@ops.ietf.org; Mon, 31 May 2004 12:01:19 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i4VC1FxB066385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 31 May 2004 12:01:17 GMT (envelope-from roy+dated+1088596958.a8259b@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4VC1Dso015649 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 31 May 2004 13:01:15 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i4VC2cK5078997 for ; Mon, 31 May 2004 13:02:38 +0100 (BST) (envelope-from roy+dated+1088596958.a8259b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i4VC2csk078996 for namedroppers@ops.ietf.org; Mon, 31 May 2004 13:02:38 +0100 (BST) (envelope-from roy+dated+1088596958.a8259b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 31 May 2004 13:02:37 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16571.7900.899506.817355@giles.gnomon.org.uk> Date: Mon, 31 May 2004 13:02:36 +0100 To: Edward Lewis Cc: "Hallam-Baker, Phillip" , "'David Blacka'" , namedroppers@ops.ietf.org Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) In-Reply-To: References: 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-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 >>>>> "Edward" == Edward Lewis writes: Edward> (Hmmm, perhaps detailing what happens if the NSEC claims Edward> that it itself doesn't exist - but that's been tried Edward> before and failed.) As far as I can see the current document set _does_ detail what happens in this case. -protocol 5.4: Since a validated NSEC RR proves the existence of both itself and its corresponding RRSIG RR, a validator MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR. -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 May 31 09:01: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 JAA17958 for ; Mon, 31 May 2004 09:01:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUmMy-0004Qo-5U for namedroppers-data@psg.com; Mon, 31 May 2004 12:58:24 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUmMw-0004QX-TT for namedroppers@ops.ietf.org; Mon, 31 May 2004 12:58:23 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i4VCwJGE043072; Mon, 31 May 2004 14:58:19 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i4VCwJSh043071; Mon, 31 May 2004 14:58:19 +0200 (CEST) (envelope-from ted) Message-Id: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Mon, 31 May 2004 14:58:19 +0200 In-Reply-To: "Olaf Kolkman's message as of May 20, 22:42" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Olaf Kolkman , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Olaf Kolkman, on May 20, 22:42, in "Re: Proposal to fix ..."] > > Dear Colleagues, .... > If I do not see rough consensus on taking up NSEC2 as a work item by > June 1 I'll reject this as a work item. > > If, after June 1, there is consensus on taking up NSEC2 as a work item > I'll try to make an inventory on how many participants of the working > group can commit resources to make this work. If it turns out we > cannot produce standards, documents and code on a reasonable time or > we alienate a significant fraction of the people that are now > committed on working on this we'll also not take NSEC2 up as a work > item. After following the discussion with great interest, I think that: 1. The virtues of making NSEC-walking difficult seem to be largely overestimated by some people. For all devious purposes (spamlist building, whois lurking, etc), there are already numerous ways to build a close enough list of domainnames with or without NSEC. I really think that the problems at hand will hardly be influenced by having NSEC or NSEC2 in practice. 2. The time, the work, and the funding needed to redo DNSSEC once again seems largely underestimated. Having been involved in the work to go from 2535 to the current docset, I don't believe anyone who says that we can stamp out a DNSSECter docset before 2006 or perhaps even 2007. As for funding such work, I will have a large problem to defend further funding for NLnet Labs on DNSSEC if we go back to the basic design. NLnet Labs must then most likely drop their work on DNSSEC on the floor. So, I think that the working group should NOT delay DNSSECbis by trying to fold in NSEC2 this late in the process. If NSEC2 needs to be worked out it should be done in a separate track. 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 Mon May 31 10:31:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23526 for ; Mon, 31 May 2004 10:31:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUnlH-000OUA-S4 for namedroppers-data@psg.com; Mon, 31 May 2004 14:27:35 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUnlF-000OSH-Tp for namedroppers@ops.ietf.org; Mon, 31 May 2004 14:27:34 +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 i4VEROrd020170; Mon, 31 May 2004 15:27:24 +0100 (BST) To: ted@NLnetLabs.nl (Ted Lindgreen) cc: Olaf Kolkman , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Mon, 31 May 2004 14:58:19 +0200." <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> Date: Mon, 31 May 2004 15:27:23 +0100 Message-ID: <20169.1086013643@gromit.rfc1035.com> From: Jim Reid 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 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ted" == Ted Lindgreen writes: Ted> So, I think that the working group should NOT delay DNSSECbis Ted> by trying to fold in NSEC2 this late in the process. If NSEC2 Ted> needs to be worked out it should be done in a separate track. I agree wholeheartedly with Ted. Folding NSEC2 into DNSSECbis will delay a DNSSEC standard for at least a year, more likely two. This would represent a design change, not just a few tweaks of the current document set. The 11th hour arguments of the NSEC2 people and their stakeholders notwithstanding, the WG has a document set today that has rough consensus, working code and has benefitted from a lot of work and detailed analysis. We have something that works and is deployable. Apart of course from layer-9 issues in some quarters that IMO should not concern this WG. I think the WG should go with the DNSSECbis drafts and the immediate priority should be to review these while they are in Last Call. If NSEC2 is to be worked on, this can be considered after DNSSECbis has gone to IESG. I'd like the NSEC2 supporters to come back with completed, well worked out drafts that not only defined the new protocol but also showed how this will interwork with DNSSECbis, any migration strategy and so on. For now, the WG needs to focus on a technical review of the current document set. To some extent this appears to have been overshadowed by a debate on the layer-9 issues that motivated NSEC2. -- to unsubscribe send a message to namedroppers-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 May 31 10:32: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 KAA23606 for ; Mon, 31 May 2004 10:32:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUnnE-000OoC-Uo for namedroppers-data@psg.com; Mon, 31 May 2004 14:29:36 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUnnD-000Onp-RL for namedroppers@ops.ietf.org; Mon, 31 May 2004 14:29:36 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id C0F20E7E4D; Mon, 31 May 2004 15:29:34 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> Message-Id: <20040531142934.C0F20E7E4D@mx1.nominet.org.uk> Date: Mon, 31 May 2004 15:29:34 +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 ted@NLnetLabs.nl (Ted Lindgreen) writes: > 1. The virtues of making NSEC-walking difficult seem to be largely > overestimated by some people. For all devious purposes (spamlist > building, whois lurking, etc), there are already numerous ways > to build a close enough list of domainnames with or without NSEC. > I really think that the problems at hand will hardly be > influenced by having NSEC or NSEC2 in practice. Please note that information leakage is not the only issue attributable to NSEC RR elaboration: resource depletion due to possibly frequent, multiple simultaneous chains of elaboration could also be significant. Making zone files available via some other mechanism, e.g. FTP or HTTP, without restriction, seems to be the only way to make NSEC RR elaboration less rewarding than other methods of spammer/scammer list construction. Even ICANN TLDs which have a policy of making their register database available to requestors may find that a non-negligible number of users would prefer to use NSEC RR elaboration tools, perhaps to avoid bureaucracy or to conceal their identities. In other words, I don't believe this is strictly a European ccTLD problem. It may be a problem for any nameserver administrator -- especially of large registries -- who is unwilling or unable to make zone file information trivially available via alternate means. 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: From owner-namedroppers@ops.ietf.org Mon May 31 11:03: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 LAA24982 for ; Mon, 31 May 2004 11:03:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUoGv-0004tw-BK for namedroppers-data@psg.com; Mon, 31 May 2004 15:00:17 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUoGu-0004tZ-Bj for namedroppers@ops.ietf.org; Mon, 31 May 2004 15:00:16 +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 i4VF0Eok007447; Mon, 31 May 2004 11:00:14 -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 i4VF0DoM022246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 May 2004 11:00:13 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i4VF0C2F026065; Mon, 31 May 2004 11:00:12 -0400 Subject: Re: Proposal to fix NSEC From: Greg Hudson To: Geoffrey Sisson Cc: namedroppers@ops.ietf.org In-Reply-To: <20040531142934.C0F20E7E4D@mx1.nominet.org.uk> References: <20040531142934.C0F20E7E4D@mx1.nominet.org.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1086015612.1468.72.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 31 May 2004 11:00:12 -0400 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_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (I agree with Ted.) On Mon, 2004-05-31 at 10:29, Geoffrey Sisson wrote: > Please note that information leakage is not the only issue attributable > to NSEC RR elaboration: resource depletion due to possibly frequent, > multiple simultaneous chains of elaboration could also be significant. Two answers: (1) The normal load on most of these servers is pretty high. An awful lot of spammers would have to be doing simultaneous nsec walks (which are rate-limited to some extent by needing to wait an RTT for each request) before it would become a noticeable factor. (2) An nsec walk is an awful lot more efficient than a PTR walk. -- to unsubscribe send a message to namedroppers-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 May 31 11:28: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 LAA26474 for ; Mon, 31 May 2004 11:28:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUofo-0009gR-Dl for namedroppers-data@psg.com; Mon, 31 May 2004 15:26:00 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUofn-0009gB-3N for namedroppers@ops.ietf.org; Mon, 31 May 2004 15:25:59 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 7A62BE7E4F; Mon, 31 May 2004 16:25:58 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <1086015612.1468.72.camel@egyptian-gods.mit.edu> Message-Id: <20040531152558.7A62BE7E4F@mx1.nominet.org.uk> Date: Mon, 31 May 2004 16:25:58 +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=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Greg Hudson writes: > On Mon, 2004-05-31 at 10:29, Geoffrey Sisson wrote: > > Please note that information leakage is not the only issue attributable > > to NSEC RR elaboration: resource depletion due to possibly frequent, > > multiple simultaneous chains of elaboration could also be significant. > > Two answers: > > (1) The normal load on most of these servers is pretty high. An awful > lot of spammers would have to be doing simultaneous nsec walks (which > are rate-limited to some extent by needing to wait an RTT for each > request) before it would become a noticeable factor. Except . . . (Copy of my reply to kre on Friday) ------------------------ Begin included text ------------------------ It would be surprising if NSEC RR elaboration techniques didn't incorporate considerable parallelism, especially for large zones. This could impose arbitrarily high loads on a busy nameserver. For example, multiple simultaneous elaborations could be run, one starting at 'aaa.co.uk', another starting at 'aab.co.uk', and so on. This isn't idle speculation: prior to incorporating token bucket into the WHOIS server at whois.nic.uk [note: reference to WHOIS for illustrative purposes only!] we used to have a one-second sleep to limit the impact of scripts. Impatient data miners designed tools which sent queries in parallel -- sometimes hundreds per second -- in order to collect data at higher rates. The consequences to server performance were, well, predictable . . . ------------------------- End included text ------------------------- > (2) An nsec walk is an awful lot more efficient than a PTR walk. True, though PTR walks are probably more distributed (i.e. involve traversing many different servers, not just RIR servers), though perhaps Daniel or Ed may have more insight into this phenomenon. Also, I suspect that PTR walks are much less rewarding (require much more effort for more lossy results) so would not be as ubiquitous. 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: From owner-namedroppers@ops.ietf.org Mon May 31 11:47: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 LAA27216 for ; Mon, 31 May 2004 11:47:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUoyE-000EvC-AC for namedroppers-data@psg.com; Mon, 31 May 2004 15:45:02 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUoyC-000Eu1-3O for namedroppers@ops.ietf.org; Mon, 31 May 2004 15:45:00 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Mon, 31 May 2004 11:44:49 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.5.43) with SMTP id M2004053111444906771 for ; Mon, 31 May 2004 11:44:49 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 May 2004 11:44:49 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE1050DF@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) Date: Mon, 31 May 2004 11:42:44 -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=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Previously, the WG chairs asked for input by 01 June on WGLC and related issues, given the concerns raised about NSEC and zone enumeration. Since I'm going to be out-of-pocket for two weeks and the chairs never rescinded that request, here's my input. Olaf wrote: > I think it is clear at this point that the current > DNSSEC-bis protocol spec eases content enumeration; > I think it is clear that this causes a number of TLDs > (and other players) to believe that they cannot deploy > DNSSEC in its current form. I think that a capability that was not part of the DNS protocol, but which many folks have made use of (and may believe they rely on) is going to be undermined by (most realistic schemes for) signed proof of non- existence. However, I would state that the "content enumeration" bugaboo is to me just that--a bugaboo. > Please refrain from further discussion of these two > points; this is a real issue. Sorry that I can't follow instructions, but I did want to clarify the extent to which this is a "real issue" in my mind. > The question on the table is what this WG needs to do. > > [slight editing follows to clearly state Olaf's options] > Option 1. Taking up work to prevent zone enumeration > while holding the DNSSEC bis document-set > Option 2. shipping DNSSEC bis and forgetting for now > about solving the enumeration problem. > Option 3. Ship the DNSSEC-bis document set and work out > the enumeration problem later (but commit on finding > a solution). I would prefer Option 2. Option 2 doesn't mean that issues with zone enumeration can never be addressed, but it does make it less likely that major changes will be made (because it makes the changes more painful to implement). I can live with Option 3, particularly if Opt-In (or whatever a better name for it) is added back into the mix of possible solutions. I absolutely can't live with Option 1. If I ever want to have a prayer of having DNSSEC signed zones supported in some fairly major software, we have *got* to get DNSSECbis wrapped up and out the door. It is deployable today and I have no interest in waiting another 18 months for DNSSECbis-TNG (A/K/A DNSSECter). Or, to put it more succinctly, I agree with recent messages from Ted Lindgreen and Jim Reid that included the statement: Ted> So, I think that the working group should NOT delay DNSSECbis Ted> by trying to fold in NSEC2 this late in the process. If NSEC2 Ted> needs to be worked out it should be done in a separate track. --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: From owner-namedroppers@ops.ietf.org Mon May 31 13:12: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 NAA01733 for ; Mon, 31 May 2004 13:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUqH9-0009zy-Og for namedroppers-data@psg.com; Mon, 31 May 2004 17:08:39 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUqH8-0009yz-1w for namedroppers@ops.ietf.org; Mon, 31 May 2004 17:08:38 +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 i4VH8Wsd044390; Mon, 31 May 2004 19:08:34 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4VH8T9K030383; Mon, 31 May 2004 19:08:29 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i4VH8SG3030378; Mon, 31 May 2004 19:08:29 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 31 May 2004 19:08:28 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen cc: Olaf Kolkman , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> Message-ID: References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.2 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 31 May 2004, Ted Lindgreen wrote: > So, I think that the working group should NOT delay DNSSECbis by > trying to fold in NSEC2 this late in the process. If NSEC2 needs > to be worked out it should be done in a separate track. I agree with this conclusion. 'fixing' DNSSECbis for NSEC2 means delay. The fix is not trivial. Ship the docset and start work on NSEC2 in a seperate track. 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 May 31 17:31: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 RAA15990 for ; Mon, 31 May 2004 17:31:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUuIG-000Jcd-Fn for namedroppers-data@psg.com; Mon, 31 May 2004 21:26:04 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUuIF-000Jc9-5X for namedroppers@ops.ietf.org; Mon, 31 May 2004 21:26:03 +0000 Received: from wds1.nominet.org.uk (wds1.dhcp.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 39CCAE7E5F; Mon, 31 May 2004 22:26:02 +0100 (BST) In-Reply-To: <1086015612.1468.72.camel@egyptian-gods.mit.edu> To: Greg Hudson Cc: Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 18, 2003 Message-ID: From: "Jay Daley" Date: Mon, 31 May 2004 22:26:01 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 05/31/2004 10:26:02 PM, Serialize complete at 05/31/2004 10:26:02 PM 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 Greg > (1) The normal load on most of these servers is pretty high. An awful > lot of spammers would have to be doing simultaneous nsec walks (which > are rate-limited to some extent by needing to wait an RTT for each > request) before it would become a noticeable factor. Let me just put this one in perspective. Each of our nameservers has an average load of 100 million queries per day with about 4 million records in our zone files. That means it will take only 25 spammers doing a full walk in one day to double the load on that server (this is on top of the huge increase in traffic that DNSSEC means). As we have on average 3,000 new domains registered per day we can safely expect these spammers to do this every day. Once the script kiddie tools are out then we can expect many, many more than just 25. Jay -- to unsubscribe send a message to namedroppers-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 May 31 19:56: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 TAA23371 for ; Mon, 31 May 2004 19:56:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BUwZC-000KNz-UK for namedroppers-data@psg.com; Mon, 31 May 2004 23:51:42 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BUwZB-000KNa-Sy for namedroppers@ops.ietf.org; Mon, 31 May 2004 23:51:41 +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 i4VNpTV2009073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 May 2004 16:51:30 -0700 (PDT) Received: from [205.214.163.64] (vpn-10-50-16-67.qualcomm.com [10.50.16.67]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i4VNpO3P012437; Mon, 31 May 2004 16:51:26 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> Date: Mon, 31 May 2004 16:51:23 -0700 To: roy@dnss.ec, Ted Lindgreen From: Ted Hardie Subject: Re: Proposal to fix NSEC Cc: Olaf Kolkman , 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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:08 PM +0200 05/31/2004, roy@dnss.ec wrote: >On Mon, 31 May 2004, Ted Lindgreen wrote: > >> So, I think that the working group should NOT delay DNSSECbis by >> trying to fold in NSEC2 this late in the process. If NSEC2 needs >> to be worked out it should be done in a separate track. > >I agree with this conclusion. 'fixing' DNSSECbis for NSEC2 means delay. >The fix is not trivial. Ship the docset and start work on NSEC2 in a >seperate track. I also agree with this conclusion. regards, Ted Hardie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: