From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Olaf Kolkman Subject: DNSEXT list policy Date: Sat, 1 May 2004 08:35:01 +0200 Lines: 190 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 01 08:48:51 2004 Return-path: To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.499340 / 0.0 / 0.0 / disabled X-RIPE-Signature: 61d43d1b5b998dcc93bc8f91c40e30ab Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Namedroppers Moderation policy change Date: Mon, 03 May 2004 13:53:49 -0400 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <200405010635.i416Z1Jl011509@x50.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Olaf Kolkman <olaf@ripe.net>, Thomas Narten <narten@us.ibm.com>, "Margaret Wasserman" <margaret@thingmagic.com> X-From: owner-namedroppers@ops.ietf.org Mon May 03 20:10:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org In-Reply-To: <200405010635.i416Z1Jl011509@x50.ripe.net> References: <200405010635.i416Z1Jl011509@x50.ripe.net> Precedence: bulk At 02:35 2004-05-01, Olaf Kolkman wrote: >- Moderation > > Moderation is based on "subscriber-only with spam filter". Effective now: Posts over 20000 characters by subscribers will be moderated. This is done to combat more intelligent virus mailers that forge subscriber postings to the mailing list . I apologize for the viruses that have made it out to the mailing list over the weekend. Effects on posting: since 2002/01/01 4915 messages have been posted, a maximum[1] of 22 messages would have been affected by this policy 12 of them legitimate ones, 10 malware. Send comments to chairs. thanks =D3lafur (DNSEXT co-chair) (current Namedroppers moderator) [1] Depends on how server counts size with or without headers. =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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: scott.seligman@eng.sun.com Subject: Mail Delivery (failure namedroppers@ops.ietf.org) Date: Mon, 3 May 2004 12:14:25 -0500 Lines: 85 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-From: owner-namedroppers@ops.ietf.org Mon May 03 21:18:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Priority: 3 X-MSMail-Priority: Normal X-PAA-AntiVirus: Removed Exploit/iFrame X-PAA-AntiVirus-Message: Scanned by http://www.pandasoftware.com/PAA Precedence: bulk X-Spam-Report: 11.0 points; * 0.2 NO_REAL_NAME From: does not include a real name * 0.0 EXTRA_MPART_TYPE Header has extraneous Content-type:...type= entry * 1.0 ADDRESS_IN_SUBJECT To: address listed at front of Subject * 3.0 BigEvilList_130 URI: Generated BigEvilList_130 * -0.0 BAYES_40 BODY: Bayesian spam probability is 40 to 44% * [score: 0.4045] * 4.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [69.65.134.38 listed in sbl-xbl.spamhaus.org] * 1.6 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.2 PRIORITY_NO_NAME Message has priority, but no X-Mailer/User-Agent This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C0CA80.6B015D10" ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_001C_01C0CA80.6B015D10 Content-Type: text/plain; charset="us-ascii"; format=flowed ********************************************************** ********************************************************** WARNING: Panda Antivirus GateDefender has detected a virus in file attached to this e-mail message! The attachment has been automatically removed to protect your network. Panda Antivirus GateDefender Administrator: unknown 05/03/04 14:04:48 Panda Antivirus GateDefender (Version 5.1 R1c (5.0.60.2)) - http://www.pandasoftware.com/ Antivirus Vendor: Panda Software Scan Engine Version: 4.1.4.307 Pattern File Version: 3.74537 (Timestamp: 19/04/2004 120851) Machine name: panda Machine IP address: 192.168.1.33 Server: 147.28.0.62 Client: 192.168.1.146 Protocol: SMTP Virus: "Exploit/iFrame" found! Attachment: No file name available ********************************************************** ********************************************************** ------=_NextPart_001_001C_01C0CA80.6B015D10-- ------=_NextPart_000_001B_01C0CA80.6B015D10 Content-Type: text/plain; charset="us-ascii"; format=flowed ********************************************************** ********************************************************** WARNING: Panda Antivirus GateDefender has detected a prohibited file type attached to this e-mail message! The attachment has been automatically removed to protect your network. Panda Antivirus GateDefender Administrator: unknown 05/03/04 14:04:48 Panda Antivirus GateDefender (Version 5.1 R1c (5.0.60.2)) - http://www.pandasoftware.com/ Machine name: panda Machine IP address: 192.168.1.33 Server: 147.28.0.62 Client: 192.168.1.146 Protocol: SMTP Attachment: message.scr ********************************************************** ********************************************************** ------=_NextPart_000_001B_01C0CA80.6B015D10-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: handling of additional data (fwd) Date: Wed, 5 May 2004 08:00:58 +0300 (EEST) Lines: 72 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed May 05 17:23:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: 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 <pekkas@netcore.fi> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: handling of additional data (fwd) Date: Thu, 06 May 2004 18:57:10 +0700 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 06 14:07:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-Reply-To: <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> Precedence: bulk Date: Wed, 5 May 2004 08:00:58 +0300 (EEST) From: Pekka Savola <pekkas@netcore.fi> Message-ID: <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> | 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: handling of additional data (fwd) Date: Fri, 07 May 2004 06:11:29 +0900 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> <10945.1083844630@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 06 23:22:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <10945.1083844630@munnari.OZ.AU> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: handling of additional data (fwd) Date: Fri, 07 May 2004 06:20:51 +0700 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> <10945.1083844630@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 01:32:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <409AAA01.5000607@necom830.hpcl.titech.ac.jp> Precedence: bulk Date: Fri, 07 May 2004 06:11:29 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Paul Vixie <paul@vix.com> Subject: Re: handling of additional data (fwd) Date: Fri, 07 May 2004 00:47:15 +0000 Lines: 12 Sender: owner-namedroppers@ops.ietf.org References: <kre@munnari.OZ.AU> Cc: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 03:00:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: Message from Robert Elz <kre@munnari.OZ.AU> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: handling of additional data (fwd) Date: Fri, 07 May 2004 10:14:57 +0900 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <20040507004715.6D64C139A3@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Robert Elz <kre@munnari.OZ.AU>, Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 03:24:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040507004715.6D64C139A3@sa.vix.com> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: gson@nominum.com (Andreas Gustafsson) Subject: Re: handling of additional data (fwd) Date: Thu, 6 May 2004 18:29:17 -0700 (PDT) Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <kre@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> <20040507004715.6D64C139A3@sa.vix.com> Cc: Robert Elz <kre@munnari.OZ.AU>, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 03:40:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040507004715.6D64C139A3@sa.vix.com> X-Mailer: VM 7.04 under Emacs 20.7.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: handling of additional data (fwd) Date: Fri, 07 May 2004 10:34:26 +0900 Lines: 63 Sender: owner-namedroppers@ops.ietf.org References: <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> <10945.1083844630@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 03:41:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <21729.1083885651@munnari.OZ.AU> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Paul Vixie <paul@vix.com> Subject: Re: handling of additional data (fwd) Date: Fri, 07 May 2004 01:49:24 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <200405070129.i471THJj015893@guava.araneus.fi> Cc: Robert Elz <kre@munnari.OZ.AU>, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 03:59:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: gson@nominum.com (Andreas Gustafsson) 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Matt Larson <mlarson@verisign.com> Subject: Re: handling of additional data (fwd) Date: Fri, 7 May 2004 14:18:47 -0400 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <21729.1083885651@munnari.OZ.AU> <20040507004715.6D64C139A3@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Robert Elz <kre@munnari.OZ.AU>, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 20:30:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> Content-Disposition: inline In-Reply-To: <20040507004715.6D64C139A3@sa.vix.com> User-Agent: Mutt/1.5.6i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: handling of additional data (fwd) Date: Fri, 07 May 2004 15:05:57 -0400 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <21729.1083885651@munnari.OZ.AU> <20040507004715.6D64C139A3@sa.vix.com> <20040507181847.GT31336@chinook.corppc.vrsn.com> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri May 07 21:11:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <20040507181847.GT31336@chinook.corppc.vrsn.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: handling of additional data (fwd) Date: Sat, 08 May 2004 02:00:23 +0700 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> <10945.1083844630@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 21:15:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> Precedence: bulk Date: Fri, 07 May 2004 10:34:26 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Paul Vixie <paul@vix.com> Subject: Re: handling of additional data (fwd) Date: Fri, 07 May 2004 19:57:43 +0000 Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <mlarson@verisign.com> X-From: owner-namedroppers@ops.ietf.org Fri May 07 22:08:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Matt Larson <mlarson@verisign.com> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: handling of additional data (fwd) Date: Sat, 08 May 2004 05:57:55 +0900 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <21729.1083885651@munnari.OZ.AU> <20040507004715.6D64C139A3@sa.vix.com> <20040507181847.GT31336@chinook.corppc.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Paul Vixie <paul@vix.com>, Robert Elz <kre@munnari.OZ.AU>, Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 23:04:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Matt Larson <mlarson@verisign.com> In-Reply-To: <20040507181847.GT31336@chinook.corppc.vrsn.com> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: handling of additional data (fwd) Date: Sat, 08 May 2004 06:19:26 +0900 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> <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 Content-Transfer-Encoding: 7bit Cc: Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 07 23:23:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <24905.1083956423@munnari.OZ.AU> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: handling of additional data (fwd) Date: Sat, 08 May 2004 06:05:34 +0700 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <409BFD5E.8090707@necom830.hpcl.titech.ac.jp> <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> <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 Cc: Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 08 01:23:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <409BFD5E.8090707@necom830.hpcl.titech.ac.jp> Precedence: bulk Date: Sat, 08 May 2004 06:19:26 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: handling of additional data (fwd) Date: Sat, 08 May 2004 08:50:30 +1000 Lines: 74 Sender: owner-namedroppers@ops.ietf.org References: <409BF853.7010908@necom830.hpcl.titech.ac.jp> Cc: Matt Larson <mlarson@verisign.com>, Paul Vixie <paul@vix.com>, Robert Elz <kre@munnari.OZ.AU>, Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 08 05:07:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Sat, 08 May 2004 05:57:55 +0900." <409BF853.7010908@necom830.hpcl.titech.ac.jp> 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: <http://ops.ietf.org/lists/namedroppers/> -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: handling of additional data (fwd) Date: Tue, 11 May 2004 04:44:29 +0900 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <409BFD5E.8090707@necom830.hpcl.titech.ac.jp> <409AE7A2.2030504@necom830.hpcl.titech.ac.jp> <409AAA01.5000607@necom830.hpcl.titech.ac.jp> <Pine.LNX.4.44.0405050758170.15828-100000@netcore.fi> <10945.1083844630@munnari.OZ.AU> <21729.1083885651@munnari.OZ.AU> <24905.1083956423@munnari.OZ.AU> <11924.1083971134@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 10 21:53:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <11924.1083971134@munnari.OZ.AU> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: handling of additional data (fwd) Date: Tue, 11 May 2004 05:00:00 +0900 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200405072250.i47MoUPT066287@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Matt Larson <mlarson@verisign.com>, Paul Vixie <paul@vix.com>, Robert Elz <kre@munnari.OZ.AU>, Pekka Savola <pekkas@netcore.fi>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 10 22:05:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200405072250.i47MoUPT066287@drugs.dv.isc.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. > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: handling of additional data (fwd) Date: Tue, 11 May 2004 11:15:02 +1000 Lines: 72 Sender: owner-namedroppers@ops.ietf.org References: <409FDF40.2000102@necom830.hpcl.titech.ac.jp> X-From: owner-namedroppers@ops.ietf.org Tue May 11 03:26:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 11 May 2004 05:00:00 +0900." <409FDF40.2000102@necom830.hpcl.titech.ac.jp> 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: <http://ops.ietf.org/lists/namedroppers/> -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: handling of additional data (fwd) Date: Tue, 11 May 2004 11:50:22 +0900 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 11 04:53:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-dnsop@lists.uoregon.edu Fri Dec 29 10:45:51 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: handling of additional data [Re: WGLC for draft-ietf-dnsop-ipv6-dns-issues-06.txt] (fwd) Date: Tue, 11 May 2004 10:36:31 +0300 (EEST) Lines: 83 Sender: owner-dnsop@lists.uoregon.edu Reply-To: Pekka Savola <pekkas@netcore.fi> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-dnsop@lists.uoregon.edu Tue May 11 11:04:59 2004 Return-path: <owner-dnsop@lists.uoregon.edu> To: dnsop@lists.uoregon.edu Precedence: bulk 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 <pekkas@netcore.fi> 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 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Michael StJohns <mstjohns@mindspring.com> Subject: Fwd: I-D ACTION:draft-stjohns-dnssec-trustupdate-00.txt Date: Wed, 12 May 2004 10:56:48 -0400 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu May 13 17:02:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: mstjohns@mindspring.com@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: namedroppers@ops.ietf.org X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d5c98dd8862b09390b8d8cc457a57f330350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 > ><ftp://ftp.ietf.org/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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: handling of additional data (fwd) Date: Thu, 13 May 2004 14:14:48 -0400 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 13 20:29:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <200405110115.i4B1F2PT089545@drugs.dv.isc.org> To: Mark Andrews <Mark_Andrews@isc.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Paul Vixie <paul@vix.com> Subject: Re: handling of additional data (fwd) Date: Thu, 13 May 2004 19:36:30 +0000 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Thu May 13 21:48:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Thu, 13 May 2004 14:14:48 -0400." <a06020415bcc96a689f5f@[192.136.136.83]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <VIXIE.94Apr20144720@office.home.vix.com> 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 <paul@vix.com> -------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Gilles Guette <gguette@irisa.fr> Subject: Comments on draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 09:57:37 +0200 Organization: Irisa/Inria - Rennes Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 14 10:11:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: fr, en To: Michael StJohns <mstjohns@mindspring.com> In-Reply-To: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: Comments on draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 08:32:21 -0400 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <40A47BF1.3030104@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri May 14 14:43:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Michael StJohns" <mstjohns@mindspring.com> 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 Precedence: bulk > -----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Gilles Guette <gguette@irisa.fr> Subject: Re: Comments on draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 15:30:35 +0200 Organization: Irisa/Inria - Rennes Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <ANECIHCPCBDLLEJLCOPGCEGBCJAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael StJohns <mstjohns@mindspring.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 14 15:41:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: fr, en To: Scott Rose <scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEGBCJAA.scottr@nist.gov> X-Virus-Scanned: by amavisd-new at irisa.fr Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Comments on draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 10:51:57 -0400 Lines: 59 Sender: owner-namedroppers@ops.ietf.org 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 Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 14 17:00:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Gilles Guette <gguette@irisa.fr> In-Reply-To: <40A47BF1.3030104@irisa.fr> References: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> <40A47BF1.3030104@irisa.fr> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Mike StJohns <Mike.StJohns@nominum.com> Subject: RE: Comments on draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 11:19:20 -0400 Lines: 65 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri May 14 17:25:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: "Scott Rose" <scottr@nist.gov> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Comments on draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 11:20:00 -0400 Lines: 43 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 14 17:25:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Gilles Guette <gguette@irisa.fr> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Mike StJohns <Mike.StJohns@nominum.com> Subject: Re: Fwd: I-D ACTION:draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 11:39:23 -0400 Lines: 37 Sender: owner-namedroppers@ops.ietf.org 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 Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 14 17:46:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Gilles Guette <gguette@irisa.fr> In-Reply-To: <40A48157.6000606@irisa.fr> References: <6.0.1.1.2.20040512105603.0379fec0@pop.mindspring.com> <40A48157.6000606@irisa.fr> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 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 Lines: 91 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 14 21:50:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Michael StJohns <mstjohns@mindspring.com> Subject: RE: Comments on draft-stjohns-dnssec-trustupdate-00.txt Date: Fri, 14 May 2004 11:06:02 -0400 Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <40A47BF1.3030104@irisa.fr> <ANECIHCPCBDLLEJLCOPGCEGBCJAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri May 14 22:45:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: mstjohns@mindspring.com@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: "Scott Rose" <scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEGBCJAA.scottr@nist.gov> References: <40A47BF1.3030104@irisa.fr> <ANECIHCPCBDLLEJLCOPGCEGBCJAA.scottr@nist.gov> X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d2df48f642af5373372467d7732ef2be2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: New versions of DNSSECbis drafts posted Date: Mon, 17 May 2004 03:12:23 -0400 Lines: 23 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon May 17 09:28:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 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 Lines: 100 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 17 21:46:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 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 Lines: 99 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 17 21:46:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 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 Lines: 93 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 17 21:47:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: i-d-announce@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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: WG Last Call: DNSSEC bis documents Date: Tue, 18 May 2004 08:48:24 +0200 Organization: RIPE NCC Lines: 105 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue May 18 09:01:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.090585 / 0.0 / 0.0 / disabled X-RIPE-Signature: e4e1dd016e64d0ee8803d70c5feee406 Precedence: bulk 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 <dnssec-editors@east.isi.edu>. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: WG Last Call: DNSSEC bis documents Date: Tue, 18 May 2004 15:54:17 +0000 (UTC) Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <20040518084824.4181bd4d.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue May 18 18:08:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 39 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) Precedence: bulk Olaf M. Kolkman <olaf <at> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: WG Last Call: DNSSEC bis documents Date: Tue, 18 May 2004 19:07:44 +0100 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 18 20:16:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Tue, 18 May 2004 15:54:17 -0000." <loom.20040518T173746-1@post.gmane.org> Precedence: bulk >>>>> "Simon" == Simon Josefsson <jas@extundo.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: WG Last Call: DNSSEC bis documents Date: Tue, 18 May 2004 19:38:23 +0100 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <8277.1084903664@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 18 20:47:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Jim Reid <jim@rfc1035.com> In-Reply-To: <8277.1084903664@gromit.rfc1035.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Jim Reid wrote: >>>>>>"Simon" == Simon Josefsson <jas@extundo.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: WG Last Call: DNSSEC bis documents Date: Tue, 18 May 2004 20:08:24 +0100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 18 21:16:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Tue, 18 May 2004 19:38:23 BST." <40AA581F.6070201@algroup.co.uk> Precedence: bulk >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: WG Last Call: DNSSEC bis documents Date: Tue, 18 May 2004 13:21:01 -0700 Lines: 30 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "Simon Josefsson" <jas@extundo.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Tue May 18 22:34:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: DNSSEC bis documents thread-index: AcQ9DHW9JFuAlY5YT4iFYO1CF9cGywACHIcw To: "Jim Reid" <jim@rfc1035.com>, "Ben Laurie" <ben@algroup.co.uk> X-OriginalArrivalTime: 18 May 2004 20:21:41.0872 (UTC) FILETIME=[BB458700:01C43D15] Precedence: bulk > >> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: RE: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 09:46:32 +0200 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA09134FE3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 09:59:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA09134FE3@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> To: "Ben Laurie" <ben@algroup.co.uk>, "Simon Josefsson" <jas@extundo.com> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: ted@NLnetLabs.nl (Ted Lindgreen) Subject: RE: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 10:10:05 +0200 Lines: 23 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 10:15:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: RE: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 10:35:57 +0200 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <OFAABE5684.AF6B246B-ONC1256E99.002DA5D4-C1256E99.002DBB79@LocalDomain> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-From: owner-namedroppers@ops.ietf.org Wed May 19 10:42:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <OFAABE5684.AF6B246B-ONC1256E99.002DA5D4-C1256E99.002DBB79@LocalDomain> To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: ted@NLnetLabs.nl (Ted Lindgreen) Subject: RE: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 10:45:43 +0200 Lines: 52 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 10:50:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 <sanz@denic.de>, 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 <sanz@denic.de>, 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: RE: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 11:04:23 +0200 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200405190845.i4J8jhdT011236@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 11:11:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <200405190845.i4J8jhdT011236@open.nlnetlabs.nl> To: ted@NLnetLabs.nl (Ted Lindgreen) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Simon Josefsson" <jas@extundo.com> Subject: Re: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 11:50:47 +0200 (CEST) Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: Message from Simon Josefsson <jas@extundo.com> of "Tue, 18 May 2004 15:54:17 -0000." <loom.20040518T173746-1@post.gmane.org> <8277.1084903664@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 11:58:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: yxa.extundo.com: apache set sender to jas@extundo.com using -f In-Reply-To: <8277.1084903664@gromit.rfc1035.com> To: "Jim Reid" <jim@rfc1035.com> User-Agent: SquirrelMail/1.5.1 [CVS] X-Priority: 3 (Normal) Importance: Normal Precedence: bulk > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Proposal to fix NSEC Date: Wed, 19 May 2004 12:35:44 +0100 Lines: 36 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed May 19 13:46:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 13:52:40 +0100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <40AB4690.7050606@algroup.co.uk> <20040519122355.GA14215@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 15:08:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: bmanning@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 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: ted@NLnetLabs.nl (Ted Lindgreen) Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 15:16:09 +0200 Lines: 24 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 15:22:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: roy@dnss.ec Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 15:40:01 +0200 (CEST) Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <40AB4690.7050606@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed May 19 15:46:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org In-Reply-To: <40AB4690.7050606@algroup.co.uk> X-Virus-Scanned: by amavisd-new Precedence: bulk <hat EDITOR=off> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: Proposal to fix NSEC Date: Wed, 19 May 2004 09:35:54 -0400 Lines: 75 Sender: owner-namedroppers@ops.ietf.org References: <40AB4690.7050606@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed May 19 15:47:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Ben Laurie" <ben@algroup.co.uk>, <namedroppers@ops.ietf.org> 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 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: ted@NLnetLabs.nl (Ted Lindgreen) Subject: Re: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 15:42:03 +0200 Lines: 28 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 15:50:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 14:50:50 +0100 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 15:55:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 19 May 2004 13:52:40 BST." <40AB5898.9070104@algroup.co.uk> Precedence: bulk >>>>> "Ben" == Ben Laurie <ben@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. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 14:48:36 +0100 Lines: 58 Sender: owner-namedroppers@ops.ietf.org References: <ANECIHCPCBDLLEJLCOPGOEJOCJAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 15:56:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Scott Rose <scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGOEJOCJAA.scottr@nist.gov> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 15:01:34 +0100 (BST) Lines: 27 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:07:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Jim Reid <jim@rfc1035.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 00:15:15 +1000 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <40AB4690.7050606@algroup.co.uk> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:22:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-reply-to: Your message of "Wed, 19 May 2004 12:35:44 +0100." <40AB4690.7050606@algroup.co.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 16:20:53 +0200 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405191356040.22555@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:28:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.58.0405191356040.22555@elektron.atoom.net> To: roy@dnss.ec X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: David Blacka <davidb@verisignlabs.com> Subject: Re: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 10:22:55 -0400 Organization: VeriSign, Inc. Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <20040518084824.4181bd4d.olaf@ripe.net> <loom.20040518T173746-1@post.gmane.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:29:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: KMail/1.6.2 In-Reply-To: <loom.20040518T173746-1@post.gmane.org> Content-Disposition: inline Precedence: bulk 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 <davidb@verisignlabs.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: roy@dnss.ec Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 16:39:18 +0200 (CEST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <OFF60D18F3.7CE24A68-ONC1256E99.004E9841-C1256E99.004ED143@denic.de> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:47:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Marcos Sanz/Denic <sanz@denic.de> In-Reply-To: <OFF60D18F3.7CE24A68-ONC1256E99.004E9841-C1256E99.004ED143@denic.de> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 15:40:38 +0100 Lines: 68 Sender: owner-namedroppers@ops.ietf.org References: <40AB4690.7050606@algroup.co.uk> <Pine.LNX.4.58.0405191356040.22555@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:48:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405191356040.22555@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk roy@dnss.ec wrote: > <hat EDITOR=off> > > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 15:43:41 +0100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <10466.1084974650@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:50:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Jim Reid <jim@rfc1035.com> In-Reply-To: <10466.1084974650@gromit.rfc1035.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Jim Reid wrote: >>>>>>"Ben" == Ben Laurie <ben@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. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: WG Last Call: DNSSEC bis documents Date: Wed, 19 May 2004 15:37:39 +0100 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <200405191342.i4JDg3dB013789@open.nlnetlabs.nl> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:53:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: ted@NLnetLabs.nl (Ted Lindgreen) In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Wed, 19 May 2004 15:42:03 +0200." <200405191342.i4JDg3dB013789@open.nlnetlabs.nl> Precedence: bulk >>>>> "Ted" == Ted Lindgreen <ted@NLnetLabs.nl> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: roy@dnss.ec Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 16:53:49 +0200 (CEST) Lines: 71 Sender: owner-namedroppers@ops.ietf.org References: <40AB4690.7050606@algroup.co.uk> <Pine.LNX.4.58.0405191356040.22555@elektron.atoom.net> <40AB71E6.4050103@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 16:59:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <40AB71E6.4050103@algroup.co.uk> X-Virus-Scanned: by amavisd-new Precedence: bulk On Wed, 19 May 2004, Ben Laurie wrote: > roy@dnss.ec wrote: > > <hat EDITOR=off> > > > > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 14:33:42 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <200405191316.i4JDG9f3013513@open.nlnetlabs.nl> X-From: owner-namedroppers@ops.ietf.org Wed May 19 17:02:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 15:56:42 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 17:05:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 19 May 2004 15:40:38 BST." <40AB71E6.4050103@algroup.co.uk> Precedence: bulk >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 16:19:48 +0000 (UTC) Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> <10466.1084974650@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed May 19 18:27:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 29 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) Precedence: bulk Jim Reid <jim <at> rfc1035.com> writes: > > >>>>> "Ben" == Ben Laurie <ben <at> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: Proposal to fix NSEC Date: Wed, 19 May 2004 12:20:28 -0400 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405191646560.22555@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed May 19 18:28:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "DNSEXT WG" <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <Pine.LNX.4.58.0405191646560.22555@elektron.atoom.net> 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 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 17:12:11 +0100 Lines: 98 Sender: owner-namedroppers@ops.ietf.org References: <40AB4690.7050606@algroup.co.uk> <Pine.LNX.4.58.0405191356040.22555@elektron.atoom.net> <40AB71E6.4050103@algroup.co.uk> <Pine.LNX.4.58.0405191646560.22555@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 18:30:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405191646560.22555@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk roy@dnss.ec wrote: > On Wed, 19 May 2004, Ben Laurie wrote: > > >>roy@dnss.ec wrote: >> >>><hat EDITOR=off> >>> >>>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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 17:13:01 +0100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <10654.1084978602@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 18:31:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Jim Reid <jim@rfc1035.com> In-Reply-To: <10654.1084978602@gromit.rfc1035.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk Jim Reid wrote: >>>>>>"Ben" == Ben Laurie <ben@algroup.co.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 17:23:52 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <10466.1084974650@gromit.rfc1035.com> <40AB729D.1020707@algroup.co.uk> <20040519160606.GF14591@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Reid <jim@rfc1035.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 18:31:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: bmanning@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 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 17:59:01 +0100 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <ANECIHCPCBDLLEJLCOPGAEKICJAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: DNSEXT WG <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Wed May 19 19:09:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Scott Rose <scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGAEKICJAA.scottr@nist.gov> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 19:01:04 +0100 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 20:08:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Wed, 19 May 2004 16:19:48 -0000." <loom.20040519T180905-62@post.gmane.org> Precedence: bulk >>>>> "Simon" == Simon Josefsson <jas@extundo.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 19:06:06 +0100 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 20:16:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 19 May 2004 17:23:52 BST." <40AB8A18.2090304@algroup.co.uk> Precedence: bulk >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 20:28:00 +0200 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <10997.1084989664@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Wed May 19 20:34:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 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 Content-ID: <3035.1084991278.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: Proposal to fix NSEC Date: Wed, 19 May 2004 14:56:53 -0400 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <40AB9255.5060203@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed May 19 21:03:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "DNSEXT WG" <namedroppers@ops.ietf.org> 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 Precedence: bulk > -----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 "<some_label>.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 20:45:16 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 21:51:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Peter Koch <pk@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 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 20:47:10 +0100 Lines: 52 Sender: owner-namedroppers@ops.ietf.org References: <ANECIHCPCBDLLEJLCOPGOEKOCJAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: DNSEXT WG <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Wed May 19 21:52:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Scott Rose <scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGOEKOCJAA.scottr@nist.gov> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk 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 > "<some_label>.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Scott Rose" <scottr@nist.gov> Subject: RE: Proposal to fix NSEC Date: Wed, 19 May 2004 15:54:08 -0400 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <40ABB9BE.5010205@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "DNSEXT WG" <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Wed May 19 22:01:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Ben Laurie" <ben@algroup.co.uk> 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 Precedence: bulk > -----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: roy@dnss.ec Subject: Re: Proposal to fix NSEC Date: Wed, 19 May 2004 21:58:00 +0200 (CEST) Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> <40ABB94C.5070509@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 19 22:03:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <40ABB94C.5070509@algroup.co.uk> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Bob Halley <Bob.Halley@nominum.com> Subject: Re: Proposal to fix NSEC Date: 19 May 2004 15:44:26 -0700 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> <40ABB94C.5070509@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 00:55:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <40ABB94C.5070509@algroup.co.uk> Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Precedence: bulk Ben Laurie <ben@algroup.co.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 06:32:44 +0700 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 01:45:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> In-Reply-To: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Date: Wed, 19 May 2004 20:28:00 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: George Michaelson <ggm@apnic.net> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 09:58:19 +1000 Organization: APNIC Pty Ltd Lines: 40 Sender: owner-namedroppers@ops.ietf.org 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 Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 02:05:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU> In-Reply-To: <19443.1085009564@munnari.OZ.AU> X-Mailer: Sylpheed version 0.9.10claws47 (GTK+ 1.2.10; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon 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) Precedence: bulk On Thu, 20 May 2004 06:32:44 +0700 Robert Elz <kre@munnari.OZ.AU> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 09:14:41 +0100 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <200405191828.i4JIS0703040@grimsvotn.TechFak.Uni-Bielefeld.DE> <40ABB94C.5070509@algroup.co.uk> <Pine.LNX.4.58.0405192152120.11379@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 10:24:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405192152120.11379@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 10:43:58 +0200 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <19443.1085009564@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org, Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-From: owner-namedroppers@ops.ietf.org Thu May 20 10:50:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <19443.1085009564@munnari.OZ.AU> To: Robert Elz <kre@munnari.OZ.AU> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 10:41:30 +0100 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 11:49:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Marcos Sanz/Denic <sanz@denic.de> In-Reply-To: Message from Marcos Sanz/Denic <sanz@denic.de> of "Thu, 20 May 2004 10:43:58 +0200." <OF4D74BF2F.A2610872-ONC1256E9A.002ECDC2-C1256E9A.002FF88F@denic.de> Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic <sanz@denic.de> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 11:27:03 +0100 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> <OF4D74BF2F.A2610872-ONC1256E9A.002ECDC2-C1256E9A.002FF88F@denic.de> <17969.1085046090@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Marcos Sanz/Denic <sanz@denic.de>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 12:32:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com> In-Reply-To: <17969.1085046090@gromit.rfc1035.com> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Jim" == Jim Reid <jim@rfc1035.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 12:07:00 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> Cc: Marcos Sanz/Denic <sanz@denic.de>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 13:14:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> of "Thu, 20 May 2004 11:27:03 BST." <16556.34807.204862.570446@giles.gnomon.org.uk> Precedence: bulk >>>>> "Roy" == Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 12:20:33 +0100 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> Cc: Marcos Sanz/Denic <sanz@denic.de>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 13:26:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> of "Thu, 20 May 2004 11:27:03 BST." <16556.34807.204862.570446@giles.gnomon.org.uk> Precedence: bulk >>>>> "Roy" == Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 12:45:39 +0100 Lines: 64 Sender: owner-namedroppers@ops.ietf.org References: <roy@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 Content-Transfer-Encoding: 7bit Cc: Roy Badami <roy@gnomon.org.uk>, Marcos Sanz/Denic <sanz@denic.de>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 13:51:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com> In-Reply-To: <18095.1085051220@gromit.rfc1035.com> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Jim" == Jim Reid <jim@rfc1035.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 15:06:53 +0200 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <ywsk6z86nqt.fsf@shell-ng.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Thu May 20 15:14:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 In-reply-to: Your message of "19 May 2004 15:44:26 PDT." <ywsk6z86nqt.fsf@shell-ng.nominum.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <5190.1085058410.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Bob Halley <Bob.Halley@nominum.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 14:04:36 +0100 Lines: 52 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> Cc: Marcos Sanz/Denic <sanz@denic.de>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 15:14:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> of "Thu, 20 May 2004 12:45:39 BST." <16556.39523.357152.92612@giles.gnomon.org.uk> Precedence: bulk >>>>> "Roy" == Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 10:45:16 -0400 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 16:58:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> In-Reply-To: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Thu, 20 May 2004 15:06:53 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Peter, Peter Koch <pk@TechFak.Uni-Bielefeld.DE> writes: > Bob Halley <Bob.Halley@nominum.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Sal Mangiapane" <salm@servanttechnology.com> Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 12:08:07 -0400 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405192152120.11379@elektron.atoom.net> Reply-To: <salm@servanttechnology.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "Peter Koch" <pk@TechFak.Uni-Bielefeld.DE>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu May 20 18:20:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <roy@dnss.ec>, "Ben Laurie" <ben@algroup.co.uk> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <Pine.LNX.4.58.0405192152120.11379@elektron.atoom.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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. > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Sal Mangiapane" <salm@servanttechnology.com> Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 12:36:51 -0400 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <sjmd64zb1j7.fsf@dogbert.ihtfp.org> Reply-To: <salm@servanttechnology.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu May 20 18:46:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Derek Atkins" <derek@ihtfp.com>, "Peter Koch" <pk@TechFak.Uni-Bielefeld.DE> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <sjmd64zb1j7.fsf@dogbert.ihtfp.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Precedence: bulk > Peter Koch <pk@TechFak.Uni-Bielefeld.DE> writes: > > > Bob Halley <Bob.Halley@nominum.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 12:49:00 -0400 Lines: 23 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 19:03:09 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'salm@servanttechnology.com'" <salm@servanttechnology.com> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Sal Mangiapane" <salm@servanttechnology.com> Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 13:09:44 -0400 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE1050AC@US-Columbia-CIST.mail.saic.com> Reply-To: <salm@servanttechnology.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu May 20 19:18:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> 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 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 > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 18:31:35 +0000 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu May 20 20:44:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Andras Salamon <andras@dns.net> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 20:51:58 +0200 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> <OF4D74BF2F.A2610872-ONC1256E9A.002ECDC2-C1256E9A.002FF88F@denic.de> <17969.1085046090@gromit.rfc1035.com> <16556.34807.204862.570446@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu May 20 21:11:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <16556.34807.204862.570446@giles.gnomon.org.uk> User-Agent: Mutt/1.5.6i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 20:26:24 +0100 Lines: 55 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16556.34807.204862.570446@giles.gnomon.org.uk> <20040520183135.F23BD13DE5@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 21:34:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040520183135.F23BD13DE5@sa.vix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Paul" == Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 22:00:19 +0200 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <20040520185158.GA29915@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Thu May 20 22:09:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 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 Content-ID: <6654.1085083216.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 22:36:45 +0200 Lines: 90 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu May 20 22:45:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 21:51:08 +0100 Lines: 55 Sender: owner-namedroppers@ops.ietf.org References: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 22:55:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Peter Koch <pk@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 Precedence: bulk Peter Koch wrote: > Bob Halley <Bob.Halley@nominum.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 22:16:36 +0100 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 23:24:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Olaf Kolkman <olaf@ripe.net> In-Reply-To: <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) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Precedence: bulk >>>>> "Olaf" == Olaf Kolkman <olaf@ripe.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 23:19:43 +0200 Lines: 37 Sender: owner-namedroppers@ops.ietf.org 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 Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 23:24:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <200405201306.i4KD6rP05195@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-Mailer: Apple Mail (2.613) Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 23:23:40 +0200 Lines: 90 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/alternative; boundary=Apple-Mail-1--593162129 X-From: owner-namedroppers@ops.ietf.org Thu May 20 23:28:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk --Apple-Mail-1--593162129 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Forwarded message 1 out of 2 (there where problems posting) > From: Paul Vixie <paul@vix.com> > 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-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Forwarded message 1 out of 2 (there where problems posting) <excerpt><bold><color><param>0000,0000,0000</param>From: </color></bold>Paul Vixie <<paul@vix.com> <bold><color><param>0000,0000,0000</param>Date: </color></bold>May 19, 2004 4:33:42 PM CEST <bold><color><param>0000,0000,0000</param>To: </color></bold>namedroppers@ops.ietf.org <bold><color><param>0000,0000,0000</param>Subject: </color>Re: Proposal to fix NSEC </bold> <excerpt><excerpt>NSEC provides an index to whois. </excerpt>... However, "fixing NSEC" will not fix the real (whois) problem. -- teds </excerpt> 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. </excerpt> --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: this week in dnssec, 10 years ago. Date: Thu, 20 May 2004 23:24:29 +0200 Lines: 1152 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/alternative; boundary=Apple-Mail-2--593113137 X-From: owner-namedroppers@ops.ietf.org Thu May 20 23:43:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.499462 / 0.1 / 0.0 / disabled X-RIPE-Signature: 3ca6dab6be2f5eebd53d480512ef53e5 Precedence: bulk --Apple-Mail-2--593113137 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=US-ASCII; format=flowed Forwarded message 2 out of 2 (there where problems posting) > From: Paul Vixie <paul@vix.com> > 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)" <dee@skidrow.lkg.dec.com> > 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-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=US-ASCII Forwarded message 2 out of 2 (there where problems posting) <excerpt><bold><color><param>0000,0000,0000</param>From: </color></bold>Paul Vixie <<paul@vix.com> <bold><color><param>0000,0000,0000</param>Date: </color></bold>May 19, 2004 6:49:40 PM CEST <bold><color><param>0000,0000,0000</param>To: </color></bold>namedroppers@ops.ietf.org <bold><color><param>0000,0000,0000</param>Subject: </color>this week in dnssec, 10 years ago. </bold> <excerpt>... But designing DNSSEC to not introduce new realistic attack vectors, compared to vanilla DNS, has always appeared sensible to me. ... </excerpt> 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? <excerpt>The alternatives to NSEC do reduce the attack vector into an offline dictionary attack, which I believe is an acceptable risk. ... </excerpt> 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)" <<dee@skidrow.lkg.dec.com> 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 -------- </excerpt>= --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 21:45:00 +0000 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu May 20 23:51:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 04:50:02 +0700 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <16556.39523.357152.92612@giles.gnomon.org.uk> <roy@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 Cc: Jim Reid <jim@rfc1035.com>, Marcos Sanz/Denic <sanz@denic.de>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 20 23:55:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: <16556.39523.357152.92612@giles.gnomon.org.uk> Precedence: bulk Date: Thu, 20 May 2004 12:45:39 +0100 From: Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: this week in dnssec, 10 years ago. Date: Thu, 20 May 2004 23:59:25 +0200 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <13DD462A-AAA4-11D8-91E9-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri May 21 00:05:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 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 Content-ID: <7080.1085090291.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 23:30:39 +0100 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <20040520214500.7DC5113951@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 00:34:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Paul Vixie <paul@vix.com> In-Reply-To: <20040520214500.7DC5113951@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 22:52:22 +0000 (UTC) Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <10997.1084989664@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri May 21 01:05:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 33 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) Precedence: bulk Jim Reid <jim <at> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 23:21:14 +0000 (UTC) Lines: 35 Sender: owner-namedroppers@ops.ietf.org 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-From: owner-namedroppers@ops.ietf.org Fri May 21 01:27:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 28 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) Precedence: bulk Robert Elz <kre <at> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 16:57:54 -0700 Lines: 34 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Fri May 21 02:04:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Ben Laurie'" <ben@algroup.co.uk>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 01:41:13 +0100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 02:45:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Olaf Kolkman <olaf@ripe.net> In-Reply-To: <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) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Precedence: bulk >>>>> "Olaf" == Olaf Kolkman <olaf@ripe.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: this week in dnssec, 10 years ago. Date: Fri, 21 May 2004 10:05:31 +1000 Lines: 86 Sender: owner-namedroppers@ops.ietf.org References: <200405202159.i4KLxPJ07088@grimsvotn.TechFak.Uni-Bielefeld.DE> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 02:45:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> In-reply-to: Your message of "Thu, 20 May 2004 23:59:25 +0200." <200405202159.i4KLxPJ07088@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Paul Vixie <vixie@vix.com> Subject: Re: New versions of DNSSECbis drafts posted Date: 21 May 2004 01:22:13 +0000 Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <c8dlnr$2832$1@sf1.isc.org> <c8j36c$1ll2$1@sf1.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Fri May 21 03:30:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <c8j36c$1ll2$1@sf1.isc.org> Lines: 9 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: New versions of DNSSECbis drafts posted Date: Fri, 21 May 2004 11:05:59 +0900 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <c8dlnr$2832$1@sf1.isc.org> <c8j36c$1ll2$1@sf1.isc.org> <g3ad02o9q2.fsf@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 04:09:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <vixie@vix.com> In-Reply-To: <g3ad02o9q2.fsf@sa.vix.com> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 12:34:35 +1000 Lines: 55 Sender: owner-namedroppers@ops.ietf.org References: <loom.20040521T005635-67@post.gmane.org> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 04:41:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-reply-to: Your message of "Thu, 20 May 2004 23:21:14 GMT." <loom.20040521T005635-67@post.gmane.org> Precedence: bulk > Robert Elz <kre <at> 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: <http://ops.ietf.org/lists/namedroppers/> -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: "Sal Mangiapane" <salm@servanttechnology.com> Subject: RE: Proposal to fix NSEC Date: Thu, 20 May 2004 22:47:25 -0400 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <OJELKLINFKPMOMIFLIDFEEKGFHAA.salm@servanttechnology.com> Reply-To: <salm@servanttechnology.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri May 21 04:53:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <OJELKLINFKPMOMIFLIDFEEKGFHAA.salm@servanttechnology.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Precedence: bulk > > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 06:02:56 +0100 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCCA@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 07:08:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBCCA@mou1wnexm05.vcorp.ad.vrsn.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: this week in dnssec, 10 years ago. Date: Fri, 21 May 2004 10:33:02 +0200 Lines: 47 Sender: owner-namedroppers@ops.ietf.org 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-From: owner-namedroppers@ops.ietf.org Fri May 21 10:44:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 40 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= Precedence: bulk Mark Andrews <Mark_Andrews@isc.org> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 10:45:47 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 10:51:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> To: Olaf Kolkman <olaf@ripe.net> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 09:54:37 +0100 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <16557.1632.918749.103466@giles.gnomon.org.uk> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 11:00:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: Your message of "Thu, 20 May 2004 20:26:24 BST." <16557.1632.918749.103466@giles.gnomon.org.uk> Precedence: bulk >>>>> "Roy" == Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 10:27:25 +0100 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <20040520214500.7DC5113951@sa.vix.com> <40AD318F.3090800@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 11:33:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: Ben Laurie <ben@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 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 13:26:56 +0100 Lines: 64 Sender: owner-namedroppers@ops.ietf.org Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk>, paul@vix.com X-From: owner-namedroppers@ops.ietf.org Fri May 21 14:53:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Mulberry/3.1.1 (Win32) X-Resent-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 14:15:20 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <261518784.1085146016@[192.168.100.5]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, paul@vix.com X-From: owner-namedroppers@ops.ietf.org Fri May 21 15:21:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <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) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Precedence: bulk >>>>> "Alex" == Alex Bligh <alex@alex.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 14:44:17 +0100 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <261518784.1085146016@[192.168.100.5]> <16558.232.962289.181750@giles.gnomon.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, paul@vix.com, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri May 21 15:51:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: <16558.232.962289.181750@giles.gnomon.org.uk> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --On 21 May 2004 14:15 +0100 Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 15:11:37 +0100 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <alex@alex.org.uk> Cc: namedroppers@ops.ietf.org, paul@vix.com X-From: owner-namedroppers@ops.ietf.org Fri May 21 16:17:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Fri, 21 May 2004 13:26:56 BST." <261518784.1085146016@[192.168.100.5]> Precedence: bulk >>>>> "Alex" == Alex Bligh <alex@alex.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: relevent? Date: Fri, 21 May 2004 16:13:40 +0200 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <200405202159.i4KLxPJ07088@grimsvotn.TechFak.Uni-Bielefeld.DE> <200405210039.i4L0d7tN059686@drugs.dv.isc.org> <iluhduafadd.fsf@latte.josefsson.org> <20040521122333.GA20885@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 16:19:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: bmanning@vacation.karoshi.com X-Hashcash: 0:040521:bmanning@vacation.karoshi.com:391125e79b51215c X-Hashcash: 0:040521:namedroppers@ops.ietf.org:9267fb0227db5b9b In-Reply-To: <20040521122333.GA20885@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Fri, 21 May 2004 12:23:33 +0000") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 10:24:43 -0400 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <20343.1085129677@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 16:35:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com> In-Reply-To: <20343.1085129677@gromit.rfc1035.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 14:33:53 +0000 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <ben@algroup.co.uk> X-From: owner-namedroppers@ops.ietf.org Fri May 21 17:06:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 16:22:06 +0100 Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <20851.1085148697@gromit.rfc1035.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, paul@vix.com, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri May 21 17:34:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com> In-Reply-To: <20851.1085148697@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk Jim, --On 21 May 2004 15:11 +0100 Jim Reid <jim@rfc1035.com> wrote: (with apologies for reodering) >>>>>> "Alex" == Alex Bligh <alex@alex.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:52 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 17:32:13 +0200 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <sjmd64zb1j7.fsf@dogbert.ihtfp.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri May 21 17:40:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 In-reply-to: Your message of "Thu, 20 May 2004 10:45:16 EDT." <sjmd64zb1j7.fsf@dogbert.ihtfp.org> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <9981.1085153532.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 17:39:59 +0200 Lines: 33 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Fri May 21 17:46:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <10015.1085153999.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 16:57:26 +0100 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <20040521143353.28ECC13DE5@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri May 21 18:06:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20040521143353.28ECC13DE5@sa.vix.com> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk Paul, --On 21 May 2004 14:33 +0000 Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Jaap Akkerhuis <jaap@sidn.nl> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 20:38:49 +0200 Lines: 89 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 20:55:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Mark Kosters <markk@verisignlabs.com> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 15:34:41 -0400 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <68EF5D1A-AA9D-11D8-B9EA-000393DA2D46@ripe.net> <OF224C1589.1AC677FC-ONC1256E9B.002F0979-C1256E9B.0030235E@denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 21 21:43:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Marcos Sanz/Denic <sanz@denic.de> Content-Disposition: inline In-Reply-To: <OF224C1589.1AC677FC-ONC1256E9B.002F0979-C1256E9B.0030235E@denic.de> User-Agent: Mutt/1.3.25i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 20:42:46 +0100 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <200405211838.i4LIcnNl020253@bartok.sidn.nl> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Fri May 21 21:52:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jaap Akkerhuis <jaap@sidn.nl>, namedroppers@ops.ietf.org In-Reply-To: <200405211838.i4LIcnNl020253@bartok.sidn.nl> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --On 21 May 2004 20:38 +0200 Jaap Akkerhuis <jaap@sidn.nl> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: relevent? Date: Sat, 22 May 2004 09:11:31 +1000 Lines: 97 Sender: owner-namedroppers@ops.ietf.org References: <iluhdu9euln.fsf@latte.josefsson.org> Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 01:24:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-reply-to: Your message of "Fri, 21 May 2004 16:13:40 +0200." <iluhdu9euln.fsf@latte.josefsson.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: <http://ops.ietf.org/lists/namedroppers/> -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 09:40:23 +1000 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <200405211838.i4LIcnNl020253@bartok.sidn.nl> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 01:48:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jaap Akkerhuis <jaap@sidn.nl> In-reply-to: Your message of "Fri, 21 May 2004 20:38:49 +0200." <200405211838.i4LIcnNl020253@bartok.sidn.nl> 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: <http://ops.ietf.org/lists/namedroppers/> -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: relevent? Date: Sat, 22 May 2004 01:55:06 +0200 Lines: 91 Sender: owner-namedroppers@ops.ietf.org References: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 02:03:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> 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 In-Reply-To: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> (Mark Andrews's message of "Sat, 22 May 2004 09:11:31 +1000") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Mark Andrews <Mark_Andrews@isc.org> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 01:00:16 +0100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <200405211838.i4LIcnNl020253@bartok.sidn.nl> <200405212340.i4LNeNc9078248@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jaap Akkerhuis <jaap@sidn.nl>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 02:09:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <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) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Precedence: bulk >>>>> "Mark" == Mark Andrews <Mark_Andrews@isc.org> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Fri, 21 May 2004 20:31:23 -0700 Lines: 46 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 05:40:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com>, Roy Badami <roy@gnomon.org.uk> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk > >>>>> "Roy" == Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Fri, 21 May 2004 20:31:22 -0700 Lines: 106 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 05:46:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk>, "Hallam-Baker, Phillip" <pbaker@verisign.com> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: Re: relevent? Date: Sat, 22 May 2004 06:38:39 +0000 Lines: 12 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> X-From: owner-namedroppers@ops.ietf.org Sat May 22 08:50:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Sat, 22 May 2004 01:55:06 +0200." <ilulljlbajp.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 13:53:05 +0700 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113EAA7755@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Reid <jim@rfc1035.com>, Roy Badami <roy@gnomon.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 09:23:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113EAA7755@mou1wnexm05.vcorp.ad.vrsn.com> Precedence: bulk Date: Fri, 21 May 2004 20:31:23 -0700 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Message-ID: <C6DDA43B91BFDA49AA2F1E473732113EAA7755@mou1wnexm05.vcorp.ad.vrsn.com> | 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: relevent? Date: Sat, 22 May 2004 09:30:46 +0200 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040522063839.1D27E13E3C@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat May 22 09:42:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 37 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= Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 09:55:58 +0100 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113EAA7755@mou1wnexm05.vcorp.ad.vrsn .com> <22859.1085208785@munnari.OZ.AU> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Reid <jim@rfc1035.com>, Roy Badami <roy@gnomon.org.uk>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat May 22 11:03:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Robert Elz <kre@munnari.OZ.AU>, "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <22859.1085208785@munnari.OZ.AU> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk Paul, --On 22 May 2004 13:53 +0700 Robert Elz <kre@munnari.OZ.AU> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: RE: Proposal to fix NSEC Date: Sat, 22 May 2004 10:03:56 +0100 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113EAA7755@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jim Reid <jim@rfc1035.com>, Roy Badami <roy@gnomon.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 11:09:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113EAA7755@mou1wnexm05.vcorp.ad.vrsn.com> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Hallam-Baker," == Hallam-Baker, Phillip <pbaker@verisign.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Sat, 22 May 2004 06:55:05 -0700 Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Jim Reid <jim@rfc1035.com>, Roy Badami <roy@gnomon.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 16:08:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Robert Elz'" <kre@munnari.OZ.AU>, "Hallam-Baker, Phillip" <pbaker@verisign.com> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 16:15:47 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113EAA7754@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 16:30:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en To: "Hallam-Baker, Phillip" <pbaker@verisign.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113EAA7754@mou1wnexm05.vcorp.ad.vrsn.com> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: relevent? Date: Sat, 22 May 2004 07:41:36 -0700 Lines: 78 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 16:54:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Simon Josefsson'" <jas@extundo.com>, bmanning@vacation.karoshi.com X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Sat, 22 May 2004 08:09:15 -0700 Lines: 30 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 17:15:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Ben Laurie'" <ben@algroup.co.uk>, "Hallam-Baker, Phillip" <pbaker@verisign.com> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 15:07:16 +0000 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat May 22 17:17:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> 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 Precedence: bulk > Paul, I'm Paul. He's Robert. > --On 22 May 2004 13:53 +0700 Robert Elz <kre@munnari.OZ.AU> 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 <http://www.isc.org/ops/ds/>, 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 <http://www.isc.org/ops/ds/> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: Re: relevent? Date: Sat, 22 May 2004 15:13:25 +0000 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> X-From: owner-namedroppers@ops.ietf.org Sat May 22 17:20:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Sat, 22 May 2004 09:30:46 +0200." <iluhdu8c40p.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: sthaug@nethelp.no Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 17:26:53 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <20040522150716.E2DB613E08@sa.vix.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 17:38:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: paul@vix.com In-Reply-To: Your message of "Sat, 22 May 2004 15:07:16 +0000" X-Mailer: Mew version 1.05+ on Emacs 19.34.1 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 <http://www.isc.org/ops/ds/>, 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 16:38:36 +0100 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <20040522150716.E2DB613E08@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat May 22 17:48:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20040522150716.E2DB613E08@sa.vix.com> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk Paul, > I'm Paul. He's Robert. Apologies > Have any of you here looked at <http://www.isc.org/ops/ds/>, 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" <pbaker@verisign.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 16:53:57 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040522150716.E2DB613E08@sa.vix.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat May 22 17:59:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org In-Reply-To: <20040522150716.E2DB613E08@sa.vix.com> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --On 22 May 2004 15:07 +0000 Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 16:34:39 +0000 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sat May 22 18:45:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: David Blacka <davidb@verisignlabs.com> Subject: Re: Proposal to fix NSEC Date: Sat, 22 May 2004 16:47:11 -0400 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <20040522150716.E2DB613E08@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 22 23:07:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040522150716.E2DB613E08@sa.vix.com> To: Paul Vixie <paul@vix.com> X-Mailer: Apple Mail (2.613) Precedence: bulk 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 <davidb@verisignlabs.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: relevent? Date: Sun, 23 May 2004 02:06:52 +0200 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040522151325.ABB1313E3C@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun May 23 02:17:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 32 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= Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: Proposal to fix NSEC Date: Sat, 22 May 2004 22:09:38 -0700 Lines: 16 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sun May 23 07:18:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal to fix NSEC Thread-Index: AcRAQKbb5g0lW7FqQBOGEhpzaZQH0wAQzVKQ To: "David Blacka" <davidb@verisignlabs.com>, "Paul Vixie" <paul@vix.com> X-OriginalArrivalTime: 23 May 2004 05:10:12.0294 (UTC) FILETIME=[39CEEE60:01C44084] 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 ... 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: relevent? Date: Sun, 23 May 2004 10:27:02 +0100 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <iluhdu8c40p.fsf@latte.josefsson.org> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun May 23 11:39:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-Reply-To: Your message of "Sat, 22 May 2004 09:30:46 +0200." <iluhdu8c40p.fsf@latte.josefsson.org> Precedence: bulk >>>>> "Simon" == Simon Josefsson <jas@extundo.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 13:54:00 +0100 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <alex@alex.org.uk> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun May 23 15:04:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Sat, 22 May 2004 09:55:58 BST." <335260799.1085219758@[192.168.100.5]> Precedence: bulk >>>>> "Alex" == Alex Bligh <alex@alex.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 07:26:19 -0700 Lines: 37 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Sun May 23 16:40:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 08:04:13 -0700 Lines: 26 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun May 23 17:12:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'David Blacka'" <davidb@verisignlabs.com>, Paul Vixie <paul@vix.com> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 08:32:13 -0700 Lines: 98 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Sun May 23 17:42:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 17:52:05 +0200 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCDD@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Sun May 23 18:02:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 In-reply-to: Your message of "Sun, 23 May 2004 08:32:13 PDT." <C6DDA43B91BFDA49AA2F1E473732113E5DBCDD@mou1wnexm05.vcorp.ad.vrsn.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <16010.1085327522.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 19:05:12 +0100 Lines: 123 Sender: owner-namedroppers@ops.ietf.org References: <25204.1085316840@gromit.rfc1035.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 23 20:16:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com> In-Reply-To: <25204.1085316840@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk Jim, --On 23 May 2004 13:54 +0100 Jim Reid <jim@rfc1035.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "D. J. Bernstein" <djb@cr.yp.to> Subject: Magical enumeration techniques Date: 23 May 2004 19:27:50 -0000 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <335260799.1085219758@[192.168.100.5]> <25204.1085316840@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun May 23 21:39:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 12:46:13 -0700 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <25204.1085316840@gromit.rfc1035.com> <454615362.1085339112@[192.168.100.5]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 23 21:54:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: hardie@mage.qualcomm.com In-Reply-To: <454615362.1085339112@[192.168.100.5]> To: Alex Bligh <alex@alex.org.uk>, Jim Reid <jim@rfc1035.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: relevent? Date: Sun, 23 May 2004 21:54:27 +0200 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <iluhdu8c40p.fsf@latte.josefsson.org> <24972.1085304422@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sun May 23 21:59:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 22 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= Precedence: bulk Jim Reid <jim@rfc1035.com> writes: >>>>>> "Simon" == Simon Josefsson <jas@extundo.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 13:15:00 -0700 Lines: 49 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Sun May 23 22:20:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Peter Koch'" <pk@TechFak.Uni-Bielefeld.DE>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 21:25:48 +0100 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <alex@alex.org.uk> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun May 23 22:32:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Sat, 22 May 2004 16:38:36 BST." <359418887.1085243916@[192.168.100.5]> Precedence: bulk >>>>> "Alex" == Alex Bligh <alex@alex.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 13:38:14 -0700 Lines: 72 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 23 22:49:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Ted Hardie'" <hardie@qualcomm.com>, Alex Bligh <alex@alex.org.uk>, Jim Reid <jim@rfc1035.com> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Alex Bligh <alex@alex.org.uk> Subject: RE: Proposal to fix NSEC Date: Sun, 23 May 2004 21:59:44 +0100 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCE2@mou1wnexm05.vcorp.ad.vrs n.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 23 23:06:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, 'Ted Hardie' <hardie@qualcomm.com>, Jim Reid <jim@rfc1035.com> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBCE2@mou1wnexm05.vcorp.ad.vrsn.com> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --On 23 May 2004 13:38 -0700 "Hallam-Baker, Phillip" <pbaker@verisign.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 21:55:20 +0100 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <25678.1085343948@gromit.rfc1035.com> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 23 23:07:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jim Reid <jim@rfc1035.com> In-Reply-To: <25678.1085343948@gromit.rfc1035.com> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --On 23 May 2004 21:25 +0100 Jim Reid <jim@rfc1035.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Jaap Akkerhuis <jaap@sidn.nl> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 23:07:41 +0200 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <32DB9135-AC31-11D8-BC10-000A95CC77E2@verisignlabs.com> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun May 23 23:18:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: David Blacka <davidb@verisignlabs.com> In-reply-to: Your message of Sat, 22 May 2004 16:47:11 -0400. <32DB9135-AC31-11D8-BC10-000A95CC77E2@verisignlabs.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 21:28:02 +0000 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 23 23:35:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 21:29:21 +0000 Lines: 10 Sender: owner-namedroppers@ops.ietf.org References: <jaap@sidn.nl> X-From: owner-namedroppers@ops.ietf.org Sun May 23 23:35:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Jaap Akkerhuis <jaap@sidn.nl> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: Scope of discussion (was Re: Proposal to fix NSEC) Date: Sun, 23 May 2004 16:07:47 -0700 Lines: 65 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon May 24 01:15:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Scope of discussion (was Re: Proposal to fix NSEC) Date: Sun, 23 May 2004 17:25:11 -0700 Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Mon May 24 02:35:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Olaf Kolkman'" <olaf@ripe.net>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) Date: Mon, 24 May 2004 01:07:42 +0000 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <olaf@ripe.net> X-From: owner-namedroppers@ops.ietf.org Mon May 24 03:14:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Olaf Kolkman <olaf@ripe.net> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Proposal to fix NSEC Date: Mon, 24 May 2004 12:37:43 +0100 (BST) Lines: 34 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 13:50:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: roy@dnss.ec Subject: nsec2 large label pain Date: Mon, 24 May 2004 14:12:02 +0200 (CEST) Lines: 17 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon May 24 14:19:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Proposal to fix NSEC Date: Mon, 24 May 2004 13:50:22 +0100 (BST) Lines: 26 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 14:59:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 15:05:26 +0200 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405241410010.29208@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon May 24 15:16:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 18 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= 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 15:23:58 +0200 Lines: 13 Sender: owner-namedroppers@ops.ietf.org References: <iluisemrn55.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 15:31:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <iluisemrn55.fsf@latte.josefsson.org> To: Simon Josefsson <jas@extundo.com> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: roy@dnss.ec Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 16:09:36 +0200 (CEST) Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405241410010.29208@elektron.atoom.net> <iluisemrn55.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:22:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Simon Josefsson <jas@extundo.com> In-Reply-To: <iluisemrn55.fsf@latte.josefsson.org> X-Virus-Scanned: by amavisd-new 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. <nit> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Proposal to fix NSEC Date: Mon, 24 May 2004 14:16:17 +0000 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <20040524113743.AE394E7EC9@mx1.nominet.org.uk> X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:22:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 16:28:48 +0200 Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405241519380.29208@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:34:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.58.0405241519380.29208@elektron.atoom.net> To: roy@dnss.ec X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Paul Vixie <paul@vix.com> Subject: ruminations on late-game design changes Date: Mon, 24 May 2004 14:35:06 +0000 Lines: 33 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:40:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 16:33:49 +0200 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405241519380.29208@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:40:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 In-reply-to: Your message of "Mon, 24 May 2004 16:09:36 +0200." <Pine.LNX.4.58.0405241519380.29208@elektron.atoom.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <19349.1085409229.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: roy@dnss.ec Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 16:38:09 +0200 (CEST) Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <OF5C8D38B5.21F4C3BA-ONC1256E9E.004F0509-C1256E9E.004F8ACA@denic.de> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:45:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Marcos Sanz/Denic <sanz@denic.de> In-Reply-To: <OF5C8D38B5.21F4C3BA-ONC1256E9E.004F0509-C1256E9E.004F8ACA@denic.de> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: relevent? Date: Mon, 24 May 2004 16:19:06 +0100 Lines: 118 Sender: owner-namedroppers@ops.ietf.org References: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> <ilulljlbajp.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Andrews <Mark_Andrews@isc.org>, bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:48:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en To: Simon Josefsson <jas@extundo.com> In-Reply-To: <ilulljlbajp.fsf@latte.josefsson.org> Precedence: bulk Simon Josefsson wrote: > Mark Andrews <Mark_Andrews@isc.org> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 16:43:40 +0200 Lines: 13 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405241631141.29208@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org, roy@dnss.ec X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:49:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.58.0405241631141.29208@elektron.atoom.net> To: roy@dnss.ec X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 16:43:47 +0100 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405241410010.29208@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 16:56:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405241410010.29208@elektron.atoom.net> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 16:54:30 +0200 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <OF1A340758.F75D436C-ONC1256E9E.0050BBCC-C1256E9E.0050E725@denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 17:00:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Marcos Sanz/Denic <sanz@denic.de> 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 In-Reply-To: <OF1A340758.F75D436C-ONC1256E9E.0050BBCC-C1256E9E.0050E725@denic.de> (Marcos Sanz's message of "Mon, 24 May 2004 16:43:40 +0200") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Marcos Sanz/Denic <sanz@denic.de> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 17:07:07 +0200 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <iluekp9swnt.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org, roy@dnss.ec X-From: owner-namedroppers@ops.ietf.org Mon May 24 17:14:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <iluekp9swnt.fsf@latte.josefsson.org> To: Simon Josefsson <jas@extundo.com> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 16:11:26 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> Cc: roy@dnss.ec, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 17:19:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Marcos Sanz/Denic <sanz@denic.de> In-Reply-To: Message from Marcos Sanz/Denic <sanz@denic.de> of "Mon, 24 May 2004 16:43:40 +0200." <OF1A340758.F75D436C-ONC1256E9E.0050BBCC-C1256E9E.0050E725@denic.de> Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic <sanz@denic.de> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 17:25:23 +0200 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <27571.1085411486@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 17:30:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <27571.1085411486@gromit.rfc1035.com> To: Jim Reid <jim@rfc1035.com> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 17:59:07 +0100 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <200405241433.i4OEXoq19353@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 18:14:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en To: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> In-Reply-To: <200405241433.i4OEXoq19353@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 18:14:40 +0100 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <OF92DA9168.56D181EC-ONC1256E9E.0052A353-C1256E9E.00530CE9@denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org, roy@dnss.ec X-From: owner-namedroppers@ops.ietf.org Mon May 24 18:33:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en To: Marcos Sanz/Denic <sanz@denic.de> In-Reply-To: <OF92DA9168.56D181EC-ONC1256E9E.0052A353-C1256E9E.00530CE9@denic.de> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: Scope of discussion (was Re: Proposal to fix NSEC) Date: Mon, 24 May 2004 09:30:27 -0700 Lines: 45 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Mon May 24 18:38:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Proposal to fix NSEC Date: Mon, 24 May 2004 17:46:32 +0100 (BST) Lines: 20 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 18:56:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org, paul@vix.com Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: ruminations on late-game design changes Date: Mon, 24 May 2004 10:06:52 -0700 Lines: 33 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:11:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: "Scott Rose" <scottr@nist.gov> Subject: peaceful co-existance of NSEC and NSEC2 Date: Mon, 24 May 2004 10:07:02 -0400 Organization: NIST Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCE6@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:14:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: bmanning@vacation.karoshi.com Subject: DNSSEC docset last call Date: Sun, 23 May 2004 23:32:22 +0000 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:16:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Olaf Kolkman <olaf@ripe.net> Content-Disposition: inline In-Reply-To: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: bmanning@vacation.karoshi.com Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 14:56:45 +0000 Lines: 39 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCDB@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:20:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> Content-Disposition: inline In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBCDB@mou1wnexm05.vcorp.ad.vrsn.com> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: nsec2 large label pain Date: Mon, 24 May 2004 18:07:39 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <OF1A340758.F75D436C-ONC1256E9E.0050BBCC-C1256E9E.0050E725@denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: roy@dnss.ec, Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:21:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en To: Marcos Sanz/Denic <sanz@denic.de> In-Reply-To: <OF1A340758.F75D436C-ONC1256E9E.0050BBCC-C1256E9E.0050E725@denic.de> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: bmanning@vacation.karoshi.com Subject: Re: Proposal to fix NSEC Date: Sun, 23 May 2004 05:41:11 +0000 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040522150716.E2DB613E08@sa.vix.com> <360339881.1085244837@[192.168.100.5]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:23:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> Content-Disposition: inline In-Reply-To: <360339881.1085244837@[192.168.100.5]> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: relevent? Date: Mon, 24 May 2004 19:15:21 +0200 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> <ilulljlbajp.fsf@latte.josefsson.org> <40B2126A.7020306@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:24:04 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 29 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= Precedence: bulk Ben Laurie <ben@algroup.co.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: bmanning@vacation.karoshi.com Subject: relevent? Date: Fri, 21 May 2004 12:23:33 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <200405202159.i4KLxPJ07088@grimsvotn.TechFak.Uni-Bielefeld.DE> <200405210039.i4L0d7tN059686@drugs.dv.isc.org> <iluhduafadd.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:27:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> Content-Disposition: inline In-Reply-To: <iluhduafadd.fsf@latte.josefsson.org> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:53 2006 From: bmanning@vacation.karoshi.com Subject: Re: Proposal to fix NSEC Date: Fri, 21 May 2004 19:18:23 +0000 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <200405211838.i4LIcnNl020253@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:29:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jaap Akkerhuis <jaap@sidn.nl> Content-Disposition: inline In-Reply-To: <200405211838.i4LIcnNl020253@bartok.sidn.nl> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: bmanning@vacation.karoshi.com Subject: Re: Proposal to fix NSEC Date: Thu, 20 May 2004 14:20:55 +0000 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <19443.1085009564@munnari.OZ.AU> <OF4D74BF2F.A2610872-ONC1256E9A.002ECDC2-C1256E9A.002FF88F@denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Robert Elz <kre@munnari.OZ.AU>, namedroppers@ops.ietf.org, Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:34:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Marcos Sanz/Denic <sanz@denic.de> Content-Disposition: inline In-Reply-To: <OF4D74BF2F.A2610872-ONC1256E9A.002ECDC2-C1256E9A.002FF88F@denic.de> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: nsec2 large label pain Date: Mon, 24 May 2004 10:39:00 -0700 Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:47:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Marcos Sanz/Denic'" <sanz@denic.de>, roy@dnss.ec X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: nsec2 large label pain Date: Mon, 24 May 2004 10:48:58 -0700 Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:58:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Marcos Sanz/Denic'" <sanz@denic.de>, Jim Reid <jim@rfc1035.com> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Paul Vixie <paul@vix.com> Subject: Re: relevent? Date: Mon, 24 May 2004 17:52:29 +0000 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> X-From: owner-namedroppers@ops.ietf.org Mon May 24 19:59:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Mon, 24 May 2004 19:15:21 +0200." <ilur7t9rbkm.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: relevent? Date: Mon, 24 May 2004 11:29:29 -0700 Lines: 64 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Mon May 24 20:39:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Edward Lewis <edlewis@arin.net> Subject: nsec2 example Date: Mon, 24 May 2004 11:40:10 -0700 Lines: 136 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Mon May 24 20:48:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: relevent? Date: Mon, 24 May 2004 21:00:58 +0200 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> <20040524175229.4471713E4F@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Mon May 24 21:09:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 25 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= Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Edward Lewis <edlewis@arin.net> Subject: another nsec2 example Date: Mon, 24 May 2004 14:14:17 -0700 Lines: 50 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Mon May 24 23:26:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 To: 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: relevent? Date: Mon, 24 May 2004 23:42:15 +0200 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <200405212311.i4LNBVDh064459@drugs.dv.isc.org> <ilulljlbajp.fsf@latte.josefsson.org> <40B2126A.7020306@algroup.co.uk> <ilur7t9rbkm.fsf@latte.josefsson.org> <40B25D67.2090607@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 25 00:33:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> X-Hashcash: 0:040524:ben@algroup.co.uk:9c58ee6912c84e34 X-Hashcash: 0:040524:namedroppers@ops.ietf.org:ae856e62e2efee82 In-Reply-To: <40B25D67.2090607@algroup.co.uk> (Ben Laurie's message of "Mon, 24 May 2004 21:39:03 +0100") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Ben Laurie <ben@algroup.co.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Michael Richardson <mcr@sandelman.ottawa.on.ca> Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) Date: Mon, 24 May 2004 20:24:34 -0400 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> Cc: Olaf Kolkman <olaf@ripe.net> X-From: owner-namedroppers@ops.ietf.org Tue May 25 02:38:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Olaf Kolkman <olaf@ripe.net> of "Sun, 23 May 2004 16:07:47 PDT." <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Olaf" == Olaf Kolkman <olaf@ripe.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) Date: Tue, 25 May 2004 01:03:08 +0000 Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <mcr@sandelman.ottawa.on.ca> X-From: owner-namedroppers@ops.ietf.org Tue May 25 03:10:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Michael Richardson <mcr@sandelman.ottawa.on.ca> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: NSEC+ and NO Date: Tue, 25 May 2004 01:12:55 -0400 Lines: 111 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Tue May 25 07:23:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: namedroppers@ops.ietf.org Precedence: bulk <Not as co-chair> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: NSEC+ and NO Date: Tue, 25 May 2004 17:18:17 +0900 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <6.1.0.6.2.20040524180114.0652aec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue May 25 10:23:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: namedroppers@ops.ietf.org In-Reply-To: <6.1.0.6.2.20040524180114.0652aec0@localhost> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: NSEC+ and NO Date: Tue, 25 May 2004 10:27:08 +0200 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <6.1.0.6.2.20040524180114.0652aec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 25 10:34:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <6.1.0.6.2.20040524180114.0652aec0@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= <ogud@ogud.com> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: ruminations on late-game design changes Date: Tue, 25 May 2004 17:40:01 +0900 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040524143506.53D8F13E48@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 25 10:41:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040524143506.53D8F13E48@sa.vix.com> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: NSEC+ and NO Date: Tue, 25 May 2004 11:52:13 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> Cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 25 13:04:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Marcos Sanz/Denic <sanz@denic.de> In-Reply-To: Message from Marcos Sanz/Denic <sanz@denic.de> of "Tue, 25 May 2004 10:27:08 +0200." <OF0CAD6877.DE22903B-ONC1256E9F.002D489A-C1256E9F.002E6DEA@denic.de> Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic <sanz@denic.de> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC+ and NO Date: Tue, 25 May 2004 09:04:51 -0700 Lines: 202 Sender: owner-namedroppers@ops.ietf.org References: <6.1.0.6.2.20040524180114.0652aec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 25 18:21:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <6.1.0.6.2.20040524180114.0652aec0@localhost> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= <ogud@ogud.com> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> -- -=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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: NSEC+ and NO Date: Tue, 25 May 2004 10:06:04 -0700 Lines: 75 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Tue May 25 19:22:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: =?iso-8859-1?Q?=27=D3lafur_Gu=F0mundsson=27?= <ogud@ogud.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Ted Hardie <hardie@qualcomm.com> Subject: RE: NSEC+ and NO Date: Tue, 25 May 2004 10:52:41 -0700 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-From: owner-namedroppers@ops.ietf.org Tue May 25 20:00:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: hardie@mage.qualcomm.com In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, =?iso-8859-1?Q?=27=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson=27?= <ogud@ogud.com>, 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Edward Lewis <edlewis@arin.net> Subject: RE: NSEC+ and NO Date: Tue, 25 May 2004 13:50:00 -0700 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue May 25 22:59:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Suresh Krishnaswamy <suresh@tislabs.com> Subject: -proto -records ambiguity? Date: Tue, 25 May 2004 15:47:42 -0400 (EDT) Lines: 23 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Tue May 25 23:26:16 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-X-Sender: suresh@filbert To: 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Michael Richardson <mcr@sandelman.ottawa.on.ca> Subject: Re: Scope of discussion Date: Tue, 25 May 2004 17:57:03 -0400 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <20040525010308.0AF1A13E10@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Wed May 26 00:11:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Olaf" == Olaf Kolkman <olaf@ripe.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Tue, 25 May 2004 23:00:42 +0100 Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 00:11:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020411bcd9609d5aa9@[192.35.166.53]> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (willow.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Precedence: bulk >>>>> "Edward" == Edward Lewis <edlewis@arin.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Michael Richardson <mcr@sandelman.ottawa.on.ca> Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) Date: Tue, 25 May 2004 17:59:18 -0400 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <20040525010308.0AF1A13E10@sa.vix.com> Cc: Paul Vixie <paul@vix.com> X-From: owner-namedroppers@ops.ietf.org Wed May 26 00:23:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Paul Vixie <paul@vix.com> of "Tue, 25 May 2004 01:03:08 -0000." <20040525010308.0AF1A13E10@sa.vix.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: -proto -records ambiguity? Date: Tue, 25 May 2004 14:34:21 -0400 Organization: NIST Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <Pine.GSO.4.55.0405251525140.12203@filbert> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed May 26 00:47:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk <speaking as non-editor> 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. <speaking as editor> D'oh. Thanks for catching that. ----- Original Message ----- From: "Suresh Krishnaswamy" <suresh@tislabs.com> To: <namedroppers@ops.ietf.org> 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: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Andrew Newton <andy@hxr.us> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Tue, 25 May 2004 19:09:28 -0400 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <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 Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 01:26:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <16563.49674.412883.793394@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> X-Mailer: Apple Mail (2.613) Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: NSEC+ and NO Date: Tue, 25 May 2004 23:16:00 -0400 Lines: 85 Sender: owner-namedroppers@ops.ietf.org 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 Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 05:40:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <40B35FB7.1080302@algroup.co.uk> References: <6.1.0.6.2.20040524180114.0652aec0@localhost> <40B35FB7.1080302@algroup.co.uk> Precedence: bulk <chair-hat off> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 01:20:22 +0100 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 06:43:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> of "Tue, 25 May 2004 23:00:42 BST." <16563.49674.412883.793394@giles.gnomon.org.uk> Precedence: bulk >>>>> "Roy" == Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: don@plugh.daedalus.co.nz Subject: Re: NSEC+ and NO Date: Wed, 26 May 2004 16:37:48 +1200 Lines: 73 Sender: owner-namedroppers@ops.ietf.org References: <c8ulc9$2t77$1@sf1.isc.org> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 06:43:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Olafur Omundsson <ogud@ogud.com> In-Reply-To: Your message of "Tue, 25 May 2004 01:12:55 -0400." <c8ulc9$2t77$1@sf1.isc.org> Precedence: bulk Olafur Omundsson?= <ogud@ogud.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 05:13:00 +0000 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <jim@rfc1035.com> X-From: owner-namedroppers@ops.ietf.org Wed May 26 08:22:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Jim Reid <jim@rfc1035.com> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: sthaug@nethelp.no Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 09:03:09 +0200 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <1486.1085530822@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 09:08:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: jim@rfc1035.com In-Reply-To: Your message of "Wed, 26 May 2004 01:20:22 +0100" X-Mailer: Mew version 1.05+ on Emacs 19.34.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: More on NSEC2 label size and DoS Date: Wed, 26 May 2004 10:11:11 +0200 (CEST) Lines: 28 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed May 26 10:19:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: NSEC+ and NO Date: Wed, 26 May 2004 09:42:49 +0200 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <76468.1085546268@toybsd.zl2tnm.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Wed May 26 10:28:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 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 Content-ID: <25158.1085557368.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 10:25:54 +0200 (CEST) Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Edward Lewis <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 10:31:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: <16563.49674.412883.793394@giles.gnomon.org.uk> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: NSEC+ and NO Date: Wed, 26 May 2004 09:57:44 +0100 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <76468.1085546268@toybsd.zl2tnm.gen.nz> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed May 26 11:03:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: don@plugh.daedalus.co.nz, Olafur Omundsson <ogud@ogud.com> In-Reply-To: <76468.1085546268@toybsd.zl2tnm.gen.nz> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: NSEC+ and NO Date: Tue, 25 May 2004 11:25:56 -0700 Lines: 78 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Wed May 26 11:06:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Ted Hardie'" <hardie@qualcomm.com>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, =?iso-8859-1?Q?=27=D3lafur_Gu=F0mundsson=27?= <ogud@ogud.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: Re: More on NSEC2 label size and DoS Date: Wed, 26 May 2004 10:20:37 +0200 (CEST) Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405260934590.28239@elektron.atoom.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed May 26 11:45:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.58.0405260934590.28239@elektron.atoom.net> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 09:48:53 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <1486.1085530822@gromit.rfc1035.com> <9984.1085554989@bizet.nethelp.no> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Wed May 26 11:45:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: sthaug@nethelp.no, jim@rfc1035.com In-Reply-To: <9984.1085554989@bizet.nethelp.no> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: Re: NSEC+ and NO Date: Wed, 26 May 2004 11:34:17 +0200 (CEST) Lines: 26 Sender: owner-namedroppers@ops.ietf.org 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 Cc: don@plugh.daedalus.co.nz, Olafur Omundsson <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:07:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: <680967389.1085565464@[192.168.100.5]> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 11:19:38 +0100 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Roy Badami <roy@gnomon.org.uk>, Edward Lewis <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:25:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 11:48:10 +0200 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <680436315.1085564933@[192.168.100.5]> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:25:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <680436315.1085564933@[192.168.100.5]> To: Alex Bligh <alex@alex.org.uk> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: NSEC+ and NO Date: Wed, 26 May 2004 11:40:12 +0200 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <6.1.0.6.2.20040525102400.02f9a038@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Ben Laurie <ben@algroup.co.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:26:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <6.1.0.6.2.20040525102400.02f9a038@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= <ogud@ogud.com> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 11:18:15 +0200 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <16563.49674.412883.793394@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:26:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <16563.49674.412883.793394@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 12:27:26 +0200 (CEST) Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, Edward Lewis <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:44:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: <16564.28474.714383.372054@giles.gnomon.org.uk> X-Virus-Scanned: by amavisd-new Precedence: bulk On Wed, 26 May 2004, Roy Badami wrote: > >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 12:36:14 +0200 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <OF8C8D39F5.42CA6D2D-ONC1256EA0.00324FFB-C1256EA0.00331C3A@denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:45:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 In-reply-to: Your message of "Wed, 26 May 2004 11:18:15 +0200." <OF8C8D39F5.42CA6D2D-ONC1256EA0.00324FFB-C1256EA0.00331C3A@denic.de> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <26136.1085567765.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Marcos Sanz/Denic <sanz@denic.de> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: Re: More on NSEC2 label size and DoS Date: Wed, 26 May 2004 12:22:10 +0200 (CEST) Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <2290.1085566418@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:46:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Jim Reid <jim@rfc1035.com> In-Reply-To: <2290.1085566418@gromit.rfc1035.com> X-Virus-Scanned: by amavisd-new Precedence: bulk On Wed, 26 May 2004, Jim Reid wrote: > >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 11:40:22 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> Cc: Alex Bligh <alex@alex.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:47:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Marcos Sanz/Denic <sanz@denic.de> In-Reply-To: Message from Marcos Sanz/Denic <sanz@denic.de> of "Wed, 26 May 2004 11:48:10 +0200." <OF6EBFE743.E73EC482-ONC1256EA0.0035A7D3-C1256EA0.0035D93A@denic.de> Precedence: bulk >>>>> "Marcos" == Marcos Sanz/Denic <sanz@denic.de> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 11:48:51 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Roy Badami <roy@gnomon.org.uk>, Edward Lewis <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 12:53:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: More on NSEC2 label size and DoS Date: Wed, 26 May 2004 11:13:38 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405261016591.28239@elektron.atoom.net> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 13:40:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: roy@dnss.ec In-Reply-To: Message from roy@dnss.ec of "Wed, 26 May 2004 10:20:37 +0200." <Pine.LNX.4.58.0405261016591.28239@elektron.atoom.net> Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 13:35:11 +0200 (CEST) Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, Edward Lewis <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 13:40:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: <16564.30227.3445.173997@giles.gnomon.org.uk> X-Virus-Scanned: by amavisd-new Precedence: bulk On Wed, 26 May 2004, Roy Badami wrote: > >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 13:14:35 +0200 Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <200405261036.i4QAaEk26142@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-From: owner-namedroppers@ops.ietf.org Wed May 26 14:03:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <200405261036.i4QAaEk26142@grimsvotn.TechFak.Uni-Bielefeld.DE> To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 13:08:13 +0200 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <2389.1085568022@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 14:03:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <2389.1085568022@gromit.rfc1035.com> To: Jim Reid <jim@rfc1035.com> X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 13:00:21 +0100 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Roy Badami <roy@gnomon.org.uk>, Edward Lewis <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 14:05:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Wed, 26 May 2004 14:02:52 +0200 (CEST) Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed May 26 14:08:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: sthaug@nethelp.no Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 13:36:36 +0200 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <2389.1085568022@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 14:11:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: jim@rfc1035.com In-Reply-To: Your message of "Wed, 26 May 2004 11:40:22 +0100" X-Mailer: Mew version 1.05+ on Emacs 19.34.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 12:46:18 +0100 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <23519.1085571396@bizet.nethelp.no> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 14:42:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: sthaug@nethelp.no In-Reply-To: Message from sthaug@nethelp.no of "Wed, 26 May 2004 13:36:36 +0200." <23519.1085571396@bizet.nethelp.no> Precedence: bulk >>>>> "sthaug" == sthaug <sthaug@nethelp.no> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Ted Hardie <hardie@qualcomm.com> Subject: RE: NSEC+ and NO Date: Wed, 26 May 2004 06:15:26 -0700 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF9@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-From: owner-namedroppers@ops.ietf.org Wed May 26 15:24:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: hardie@mage.qualcomm.com In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF9@mou1wnexm05.vcorp.ad.vrsn.com> To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, =?iso-8859-1?Q?=27=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson=27?= <ogud@ogud.com>, 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? <snip> > >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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Wed, 26 May 2004 14:24:46 +0100 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 15:30:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC+ and NO Date: Wed, 26 May 2004 14:03:41 +0000 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <pk@TechFak.Uni-Bielefeld.DE> X-From: owner-namedroppers@ops.ietf.org Wed May 26 16:10:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Peter Koch <pk@TechFak.Uni-Bielefeld.DE> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC+ and NO Date: Wed, 26 May 2004 14:34:17 +0000 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> X-From: owner-namedroppers@ops.ietf.org Wed May 26 16:44:37 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Marcos Sanz/Denic <sanz@denic.de> of "Wed, 26 May 2004 11:40:12 +0200." <OF28761E77.EF4010B7-ONC1256EA0.0034C2C1-C1256EA0.00351E66@denic.de> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: NIC-SE statement regarding NSEC zone walking Date: Wed, 26 May 2004 16:52:56 +0200 (CEST) Lines: 38 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed May 26 17:08:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Precedence: bulk FYI, jakob -- cut -- Date: Wed, 26 May 2004 16:17:59 +0200 From: Per-Olof Josefsson <Per-Olof.Josefsson@nic.se> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: "Jay Daley" <td@nominet.org.uk> Subject: Confirming the Nominet position Date: Wed, 26 May 2004 16:24:03 +0100 Lines: 92 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: geoff@nominet.org.uk X-From: owner-namedroppers@ops.ietf.org Wed May 26 17:32:42 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Sensitivity: X-Mailer: Lotus Notes Release 6.5 September 26, 2003 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 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Ted Hardie <hardie@qualcomm.com> Subject: OT: Concordances was Re: Confirming the Nominet position Date: Wed, 26 May 2004 08:52:08 -0700 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.0054B882@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-From: owner-namedroppers@ops.ietf.org Wed May 26 18:04:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: hardie@mage.qualcomm.com In-Reply-To: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.0054B882@nominet.org.uk> To: 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: Re: More on NSEC2 label size and DoS Date: Wed, 26 May 2004 18:59:39 +0200 (CEST) Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405260934590.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261016591.28239@elektron.atoom.net> <40B4D23B.2070805@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 19:09:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <40B4D23B.2070805@algroup.co.uk> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 18:24:32 +0100 (BST) Lines: 23 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 19:37:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Jim Reid <jim@rfc1035.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: Re: More on NSEC2 label size and DoS Date: Wed, 26 May 2004 19:33:57 +0200 (CEST) Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <2290.1085566418@gromit.rfc1035.com> <Pine.LNX.4.58.0405261219040.28239@elektron.atoom.net> <40B4D2B5.10407@algroup.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, Jim Reid <jim@rfc1035.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 19:43:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> In-Reply-To: <40B4D2B5.10407@algroup.co.uk> X-Virus-Scanned: by amavisd-new Precedence: bulk On Wed, 26 May 2004, Ben Laurie wrote: > roy@dnss.ec wrote: > > On Wed, 26 May 2004, Jim Reid wrote: > > > > > >>>>>>>"roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: roy@dnss.ec Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Wed, 26 May 2004 21:36:39 +0200 (CEST) Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> <16564.39582.570457.670964@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed May 26 21:49:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Roy Badami <roy@gnomon.org.uk> In-Reply-To: <16564.39582.570457.670964@giles.gnomon.org.uk> X-Virus-Scanned: by amavisd-new Precedence: bulk On Wed, 26 May 2004, Roy Badami wrote: > >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Wed, 26 May 2004 22:07:57 +0000 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> X-From: owner-namedroppers@ops.ietf.org Thu May 27 00:18:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Marcos Sanz/Denic <sanz@denic.de> of "Wed, 26 May 2004 13:08:13 +0200." <OF637F95AF.A3B7F989-ONC1256EA0.003CBC08-C1256EA0.003D2D94@denic.de> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Wed, 26 May 2004 23:30:56 +0100 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> <16564.39582.570457.670964@giles.gnomon.org.uk> <Pine.LNX.4.58.0405262056570.28239@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Roy Badami <roy@gnomon.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 00:38:01 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405262056570.28239@elektron.atoom.net> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 01:15:44 +0100 Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> <16564.39582.570457.670964@giles.gnomon.org.uk> <Pine.LNX.4.58.0405262056570.28239@elektron.atoom.net> <16565.6816.203820.50021@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: roy@dnss.ec X-From: owner-namedroppers@ops.ietf.org Thu May 27 02:24:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <16565.6816.203820.50021@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: David Blacka <davidb@verisignlabs.com> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Wed, 26 May 2004 21:00:56 -0400 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> <16564.39582.570457.670964@giles.gnomon.org.uk> <Pine.LNX.4.58.0405262056570.28239@elektron.atoom.net> <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 Content-Transfer-Encoding: 7bit Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 03:07:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <16565.13104.363074.585875@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> X-Mailer: Apple Mail (2.613) Precedence: bulk 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 <davidb@verisignlabs.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 02:19:01 +0100 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> <16564.39582.570457.670964@giles.gnomon.org.uk> <Pine.LNX.4.58.0405262056570.28239@elektron.atoom.net> <16565.6816.203820.50021@giles.gnomon.org.uk> <16565.13104.363074.585875@giles.gnomon.org.uk> <4FA765FC-AF79-11D8-966F-000A95CC77E2@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Roy Badami <roy@gnomon.org.uk>, roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 03:32:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: David Blacka <davidb@verisignlabs.com> In-Reply-To: <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) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Precedence: bulk >>>>> "David" == David Blacka <davidb@verisignlabs.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: don@plugh.daedalus.co.nz Subject: Re: NSEC+ and NO Date: Thu, 27 May 2004 14:05:18 +1200 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <680967389.1085565464@[192.168.100.5]> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 04:11:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Alex Bligh <alex@alex.org.uk> In-Reply-To: Your message of "Wed, 26 May 2004 09:57:44 +0100." <680967389.1085565464@[192.168.100.5]> Precedence: bulk Alex Bligh <alex@alex.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Wed, 26 May 2004 22:48:10 -0400 Lines: 85 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 04:56:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <16563.49674.412883.793394@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC+ and NO Date: Thu, 27 May 2004 04:04:20 +0000 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <68157.1085623518@toybsd.zl2tnm.gen.nz> X-From: owner-namedroppers@ops.ietf.org Thu May 27 06:10:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag (was: NSEC+ and NO) Date: Thu, 27 May 2004 04:01:13 +0000 Lines: 116 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-From: owner-namedroppers@ops.ietf.org Thu May 27 06:12:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Wed, 26 May 2004 22:48:10 -0400." <a06020401bcdac129a91d@[192.35.166.53]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk --=-=-= > From: Edward Lewis <edlewis@arin.net> > ... > 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 <paul@vix.com> 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 <gnu@toad.com> Sender: owner-dns-security@lists.tislabs.com Precedence: bulk > > 11. SECure-RR (5 minutes) Edward Lewis > > <draft-ietf-dnsind-sec-rr-00.txt> > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: David Blacka <davidb@verisignlabs.com> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 01:02:41 -0400 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> <16564.39582.570457.670964@giles.gnomon.org.uk> <Pine.LNX.4.58.0405262056570.28239@elektron.atoom.net> <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 Content-Transfer-Encoding: 7bit Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 07:14:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <16565.16901.386808.336979@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> X-Mailer: Apple Mail (2.613) Precedence: bulk On May 26, 2004, at 9:19 PM, Roy Badami wrote: >>>>>> "David" == David Blacka <davidb@verisignlabs.com> 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 <davidb@verisignlabs.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:54 2006 From: don@plugh.daedalus.co.nz Subject: Re: NSEC+ and NO Date: Thu, 27 May 2004 19:49:54 +1200 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <20040527040420.C1AF9139A3@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Thu May 27 09:58:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 27 May 2004 04:04:20 GMT." <20040527040420.C1AF9139A3@sa.vix.com> Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 10:23:16 +0100 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBCF7@mou1wnexm05.vcorp.ad.vrsn.com> <a06020411bcd9609d5aa9@[192.35.166.53]> <16563.49674.412883.793394@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261022160.28239@elektron.atoom.net> <16564.28474.714383.372054@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261222390.28239@elektron.atoom.net> <16564.30227.3445.173997@giles.gnomon.org.uk> <Pine.LNX.4.58.0405261333150.28239@elektron.atoom.net> <Pine.LNX.4.58.0405261342250.28239@elektron.atoom.net> <16564.39582.570457.670964@giles.gnomon.org.uk> <Pine.LNX.4.58.0405262056570.28239@elektron.atoom.net> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Roy Badami <roy@gnomon.org.uk>, roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 11:32:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: David Blacka <davidb@verisignlabs.com> In-Reply-To: <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) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Precedence: bulk >>>>> "David" == David Blacka <davidb@verisignlabs.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Thu, 27 May 2004 11:30:11 +0200 Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <20040526220757.CE5C613951@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-From: owner-namedroppers@ops.ietf.org Thu May 27 11:38:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040526220757.CE5C613951@sa.vix.com> To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Thu, 27 May 2004 10:52:01 +0100 (BST) Lines: 24 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 11:58:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: "Jay Daley" <td@nominet.org.uk> Subject: Confirming the Nominet position Date: Wed, 26 May 2004 09:48:34 +0100 Lines: 84 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: geoff@nominet.org.uk X-From: owner-namedroppers@ops.ietf.org Thu May 27 13:49:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 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 X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.499857 / 0.0 / 0.0 / disabled X-RIPE-Signature: 1358e35dc2f60ff60f0b41c892ad960d Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Jaap Akkerhuis <jaap@sidn.nl> Subject: Re: NIC-SE statement regarding NSEC zone walking Date: Thu, 27 May 2004 13:39:25 +0200 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <Pine.OSX.4.60.0405261650410.23259@criollo.schlyter.se> Cc: Jakob Schlyter <jakob@rfc.se> X-From: owner-namedroppers@ops.ietf.org Thu May 27 13:49:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> In-reply-to: Your message of Wed, 26 May 2004 16:52:56 +0200. <Pine.OSX.4.60.0405261650410.23259@criollo.schlyter.se> Precedence: bulk -- cut -- Date: Wed, 26 May 2004 16:17:59 +0200 From: Per-Olof Josefsson <Per-Olof.Josefsson@nic.se> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: NSEC+ and NO Date: Thu, 27 May 2004 13:56:55 +0200 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <68157.1085623518@toybsd.zl2tnm.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Thu May 27 14:04:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 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 Content-ID: <493.1085659015.1@grimsvotn.TechFak.Uni-Bielefeld.DE> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: "Jay Daley" <jay@nominet.org.uk> Subject: Confirming the Nominet position Date: Wed, 26 May 2004 16:21:02 +0100 Lines: 90 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: geoff@nominet.org.uk X-From: owner-namedroppers@ops.ietf.org Thu May 27 14:09:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Sensitivity: X-Mailer: Lotus Notes Release 6.5 September 26, 2003 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 X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.498392 / 0.0 / 0.0 / disabled X-RIPE-Signature: 43cd0e6e0f2d3d7a2608c4d7076636ba Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: More on NSEC2 label size and DoS Date: Thu, 27 May 2004 14:50:20 +0100 (BST) Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405261830530.28239@elektron.atoom.net> X-From: owner-namedroppers@ops.ietf.org Thu May 27 15:59:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: bmanning@vacation.karoshi.com Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 13:54:25 +0000 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.00308345@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org, geoff@nominet.org.uk X-From: owner-namedroppers@ops.ietf.org Thu May 27 16:00:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jay Daley <td@nominet.org.uk> Content-Disposition: inline In-Reply-To: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.00308345@nominet.org.uk> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: bmanning@vacation.karoshi.com Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Thu, 27 May 2004 14:02:00 +0000 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040527095201.E508EE7E96@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 16:09:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Geoffrey Sisson <geoff@nominet.org.uk> Content-Disposition: inline In-Reply-To: <20040527095201.E508EE7E96@mx1.nominet.org.uk> User-Agent: Mutt/1.4.1i Precedence: bulk > Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC+ and NO Date: Thu, 27 May 2004 14:06:11 +0000 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <79570.1085644194@toybsd.zl2tnm.gen.nz> X-From: owner-namedroppers@ops.ietf.org Thu May 27 16:13:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org 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 Precedence: bulk > Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Thu, 27 May 2004 14:17:52 +0000 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> X-From: owner-namedroppers@ops.ietf.org Thu May 27 16:24:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Marcos Sanz/Denic <sanz@denic.de> of "Thu, 27 May 2004 11:30:11 +0200." <OFAFDBBCC1.9A7DB881-ONC1256EA1.00342692-C1256EA1.003433D2@denic.de> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Thu, 27 May 2004 16:49:58 +0200 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> <20040527141752.1D7A713960@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu May 27 16:59:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 30 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= Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 10:59:59 -0400 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.0054B882@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org, geoff@nominet.org.uk X-From: owner-namedroppers@ops.ietf.org Thu May 27 17:12:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.0054B882@nominet.org.uk> To: "Jay Daley" <td@nominet.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 16:24:32 +0100 (BST) Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <a06020402bcdbaf2506fb@[192.168.1.100]> X-From: owner-namedroppers@ops.ietf.org Thu May 27 17:33:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <a06020402bcdbaf2506fb@[192.168.1.100]> Precedence: bulk Edward Lewis <edlewis@arin.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Thu, 27 May 2004 16:37:10 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <jas@extundo.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 17:44:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Simon Josefsson <jas@extundo.com> In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Thu, 27 May 2004 16:49:58 +0200." <iluacztkjqh.fsf@latte.josefsson.org> Precedence: bulk >>>>> "Simon" == Simon Josefsson <jas@extundo.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 16:43:00 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <20040527152432.5E0DDE7EF2@mx1.nominet.org.uk> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 17:51:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: geoff@nominet.org.uk (Geoffrey Sisson) 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> Precedence: bulk >>>>> "Geoffrey" == Geoffrey Sisson <geoff@nominet.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Thu, 27 May 2004 11:54:41 -0400 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <sanz@denic.de> <20040527141752.1D7A713960@sa.vix.com> <iluacztkjqh.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: edlewis@arin.net X-From: owner-namedroppers@ops.ietf.org Thu May 27 18:03:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <iluacztkjqh.fsf@latte.josefsson.org> To: 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: "Jay Daley" <td@nominet.org.uk> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 17:00:28 +0100 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <5318.1085672580@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: geoff@nominet.org.uk (Geoffrey Sisson), namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 18:26:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <5318.1085672580@gromit.rfc1035.com> To: Jim Reid <jim@rfc1035.com> X-Mailer: Lotus Notes Release 6.5 September 26, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 16:39:04 +0000 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <td@nominet.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu May 27 18:46:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from "Jay Daley" <td@nominet.org.uk> of "Thu, 27 May 2004 17:00:28 +0100." <OF8070BEE1.DF9830AB-ON80256EA1.005787D7-80256EA1.00580E1B@nominet.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: bmanning@vacation.karoshi.com Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 16:52:30 +0000 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <5318.1085672580@gromit.rfc1035.com> <OF8070BEE1.DF9830AB-ON80256EA1.005787D7-80256EA1.00580E1B@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Reid <jim@rfc1035.com>, Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 19:00:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jay Daley <td@nominet.org.uk> Content-Disposition: inline In-Reply-To: <OF8070BEE1.DF9830AB-ON80256EA1.005787D7-80256EA1.00580E1B@nominet.org.uk> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 17:53:40 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <td@nominet.org.uk> Cc: geoff@nominet.org.uk (Geoffrey Sisson), namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 19:01:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Jay Daley" <td@nominet.org.uk> In-Reply-To: Message from "Jay Daley" <td@nominet.org.uk> of "Thu, 27 May 2004 17:00:28 BST." <OF8070BEE1.DF9830AB-ON80256EA1.005787D7-80256EA1.00580E1B@nominet.org.uk> Precedence: bulk >>>>> "Jay" == Jay Daley <td@nominet.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Simon Josefsson <jas@extundo.com> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 19:15:34 +0200 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040527152432.5E0DDE7EF2@mx1.nominet.org.uk> <5318.1085672580@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu May 27 19:26:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org Lines: 20 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= Precedence: bulk Jim Reid <jim@rfc1035.com> writes: >>>>>> "Geoffrey" == Geoffrey Sisson <geoff@nominet.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Tim Chown <tjc@ecs.soton.ac.uk> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 18:44:10 +0100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <5318.1085672580@gromit.rfc1035.com> <OF8070BEE1.DF9830AB-ON80256EA1.005787D7-80256EA1.00580E1B@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Thu May 27 19:52:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <OF8070BEE1.DF9830AB-ON80256EA1.005787D7-80256EA1.00580E1B@nominet.org.uk> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 18:19:20 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu May 27 20:33:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 19:59:03 +0100 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 21:06:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040527181920.660CE13DED@sa.vix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Paul" == Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 16:09:42 -0400 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <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" ; format="flowed" Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 22:19:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <16566.14967.104462.921988@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> Precedence: bulk At 19:59 +0100 5/27/04, Roy Badami wrote: >>>>>> "Paul" == Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: "Jay Daley" <td@nominet.org.uk> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 21:15:22 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040527165230.GA11286@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 22:29:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040527165230.GA11286@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Lotus Notes Release 6.5 September 26, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: bmanning@vacation.karoshi.com Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 20:35:29 +0000 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040527165230.GA11286@vacation.karoshi.com.> <OF5C538FD0.147138A2-ON80256EA1.006F1202-80256EA1.006F643D@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bmanning@vacation.karoshi.com, Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 22:43:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jay Daley <td@nominet.org.uk> Content-Disposition: inline In-Reply-To: <OF5C538FD0.147138A2-ON80256EA1.006F1202-80256EA1.006F643D@nominet.org.uk> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Subject: RE: Confirming the Nominet position Date: Thu, 27 May 2004 16:40:02 -0400 Lines: 57 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 22:49:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: 'Jay Daley' <td@nominet.org.uk> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: "Jay Daley" <td@nominet.org.uk> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 21:24:24 +0100 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: geoff@nominet.org.uk, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu May 27 23:14:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040527135425.GA10971@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Lotus Notes Release 6.5 September 26, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: Confirming the Nominet position Date: Thu, 27 May 2004 21:21:59 +0000 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <td@nominet.org.uk> X-From: owner-namedroppers@ops.ietf.org Thu May 27 23:28:46 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from "Jay Daley" <td@nominet.org.uk> of "Thu, 27 May 2004 21:15:22 +0100." <OF5C538FD0.147138A2-ON80256EA1.006F1202-80256EA1.006F643D@nominet.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 22:54:18 +0100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Roy Badami <roy@gnomon.org.uk>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 00:02:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020412bcdbf721e5e8@[192.168.1.100]> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Edward" == Edward Lewis <edlewis@arin.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: rfc-editor@rfc-editor.org Subject: RFC 3757 on Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag Date: Thu, 27 May 2004 16:04:34 -0700 Lines: 113 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 01:15:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: rfc-editor@rfc-editor.org Subject: RFC 3755 on Legacy Resolver Compatibility for Delegation Signer (DS) Date: Thu, 27 May 2004 16:02:55 -0700 Lines: 112 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 01:18:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Thu, 27 May 2004 21:49:29 -0400 Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <16566.25482.359785.580078@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 03:57:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <16566.25482.359785.580078@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> Precedence: bulk At 22:54 +0100 5/27/04, Roy Badami wrote: >>>>>> "Edward" == Edward Lewis <edlewis@arin.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 09:18:15 +0100 (BST) Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <20040527212159.B163013DE9@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Fri May 28 10:28:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <20040527212159.B163013DE9@sa.vix.com> Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: roy@dnss.ec Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 10:47:51 +0200 (CEST) Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Roy Badami <roy@gnomon.org.uk>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 10:55:31 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020412bcdbf721e5e8@[192.168.1.100]> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Fri, 28 May 2004 17:51:16 +0700 Lines: 64 Sender: owner-namedroppers@ops.ietf.org References: <23519.1085571396@bizet.nethelp.no> <2389.1085568022@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: jim@rfc1035.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 13:12:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: sthaug@nethelp.no In-Reply-To: <23519.1085571396@bizet.nethelp.no> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Robert Elz <kre@munnari.OZ.AU> Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 18:13:25 +0700 Lines: 80 Sender: owner-namedroppers@ops.ietf.org References: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.005471E3@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org, geoff@nominet.org.uk X-From: owner-namedroppers@ops.ietf.org Fri May 28 13:30:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Jay Daley" <jay@nominet.org.uk> In-Reply-To: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.005471E3@nominet.org.uk> Precedence: bulk Date: Wed, 26 May 2004 16:21:02 +0100 From: "Jay Daley" <jay@nominet.org.uk> Message-ID: <OF5FFD6E1A.CB26AC0B-ON80256EA0.002E76FF-80256EA0.005471E3@nominet.org.uk> | 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> Subject: Re: NIC-SE statement regarding NSEC zone walking Date: Fri, 28 May 2004 13:33:54 +0200 Organization: NIC France Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <Pine.OSX.4.60.0405261650410.23259@criollo.schlyter.se> <200405271139.i4RBdPQF063545@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: IETF DNSEXT WG <namedroppers@ops.ietf.org>, Jakob Schlyter <jakob@rfc.se>, Per-Olof Josefsson <Per-Olof.Josefsson@nic.se> X-From: owner-namedroppers@ops.ietf.org Fri May 28 13:47:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jaap Akkerhuis <jaap@sidn.nl> 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 X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i Precedence: bulk On Thu, May 27, 2004 at 01:39:25PM +0200, Jaap Akkerhuis <jaap@sidn.nl> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Fri, 28 May 2004 12:48:43 +0100 (BST) Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <21551.1085741476@munnari.OZ.AU> X-From: owner-namedroppers@ops.ietf.org Fri May 28 13:56:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <21551.1085741476@munnari.OZ.AU> Precedence: bulk Robert Elz <kre@munnari.OZ.AU> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: bmanning@vacation.karoshi.com Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 13:03:03 +0000 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bmanning@vacation.karoshi.com, geoff@nominet.org.uk, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 15:12:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jay Daley <td@nominet.org.uk> Content-Disposition: inline In-Reply-To: <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 14:42:57 +0100 (BST) Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> <20040528130303.GB13713@vacation.karoshi.com.> X-From: owner-namedroppers@ops.ietf.org Fri May 28 15:49:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <20040528130303.GB13713@vacation.karoshi.com.> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 16:01:15 +0100 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> <20040528130303.GB13713@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jay Daley <td@nominet.org.uk>, geoff@nominet.org.uk, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:13:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.5) Gecko/20031116 X-Accept-Language: en-gb, en To: bmanning@vacation.karoshi.com In-Reply-To: <20040528130303.GB13713@vacation.karoshi.com.> Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 10:06:25 -0400 Lines: 58 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:15:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> To: roy@dnss.ec 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 14:14:15 +0000 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:22:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from roy@dnss.ec of "Fri, 28 May 2004 10:47:51 +0200." <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Marcos Sanz/Denic <sanz@denic.de> Subject: Re: Scope of discussion Date: Fri, 28 May 2004 16:12:33 +0200 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:22:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <019CAE8D-AD0E-11D8-B615-000393DA2D46@ripe.net> To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag Date: Fri, 28 May 2004 14:24:50 +0000 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <kre@munnari.OZ.AU> X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:37:11 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Robert Elz <kre@munnari.OZ.AU> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: roy@dnss.ec Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 16:37:45 +0200 (CEST) Lines: 73 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> <a0602041cbcdcf4f0d893@[192.168.1.100]> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:44:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602041cbcdcf4f0d893@[192.168.1.100]> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: roy@dnss.ec Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 16:49:49 +0200 (CEST) Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <20040528141415.DCFF113DF0@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:57:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Paul Vixie <paul@vix.com> In-Reply-To: <20040528141415.DCFF113DF0@sa.vix.com> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 10:47:20 -0400 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> <a0602041cbcdcf4f0d893@[192.168.1.100]> <Pine.LNX.4.58.0405281614130.22399@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:58:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <Pine.LNX.4.58.0405281614130.22399@elektron.atoom.net> To: roy@dnss.ec 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 15:48:58 +0100 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Edward Lewis <edlewis@arin.net>, Roy Badami <roy@gnomon.org.uk>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 16:59:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: roy@dnss.ec In-Reply-To: <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "roy" == roy <roy@dnss.ec> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: bmanning@vacation.karoshi.com Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 15:16:21 +0000 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> <20040528130303.GB13713@vacation.karoshi.com.> <20040528134257.A42ABE7E72@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 17:23:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Geoffrey Sisson <geoff@nominet.org.uk> Content-Disposition: inline In-Reply-To: <20040528134257.A42ABE7E72@mx1.nominet.org.uk> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: roy@dnss.ec Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 17:03:02 +0200 (CEST) Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> <a0602041cbcdcf4f0d893@[192.168.1.100]> <Pine.LNX.4.58.0405281614130.22399@elektron.atoom.net> <a06020426bcdd0022783a@[192.168.1.100]> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: roy@dnss.ec, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 17:30:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020426bcdd0022783a@[192.168.1.100]> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: bmanning@vacation.karoshi.com Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 15:39:46 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> <20040528130303.GB13713@vacation.karoshi.com.> <40B7543B.4050609@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bmanning@vacation.karoshi.com, Jay Daley <td@nominet.org.uk>, geoff@nominet.org.uk, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 17:46:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ben Laurie <ben@algroup.co.uk> Content-Disposition: inline In-Reply-To: <40B7543B.4050609@algroup.co.uk> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 17:08:59 +0100 (BST) Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040528151621.GA13996@vacation.karoshi.com.> X-From: owner-namedroppers@ops.ietf.org Fri May 28 18:19:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <20040528151621.GA13996@vacation.karoshi.com.> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 14:03:49 -0400 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> <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" ; format="flowed" Cc: Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 20:16:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040528151621.GA13996@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 14:01:11 -0400 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> <16567.20826.302378.846966@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: roy@dnss.ec, Edward Lewis <edlewis@arin.net>, Roy Badami <roy@gnomon.org.uk>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 20:16:35 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <16567.20826.302378.846966@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: bmanning@vacation.karoshi.com Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 18:11:13 +0000 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> <20040528130303.GB13713@vacation.karoshi.com.> <20040528134257.A42ABE7E72@mx1.nominet.org.uk> <20040528151621.GA13996@vacation.karoshi.com.> <sjmsmdkwhtw.fsf@dogbert.ihtfp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bmanning@vacation.karoshi.com, Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 20:19:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Derek Atkins <derek@ihtfp.com> Content-Disposition: inline In-Reply-To: <sjmsmdkwhtw.fsf@dogbert.ihtfp.org> User-Agent: Mutt/1.4.1i 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: David Blacka <davidb@verisignlabs.com> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 14:41:46 -0400 Organization: VeriSign, Inc. Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16567.20826.302378.846966@giles.gnomon.org.uk> <a0602042cbcdd2cd7f2ba@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Fri May 28 20:49:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: KMail/1.6.2 In-Reply-To: <a0602042cbcdd2cd7f2ba@[192.168.1.100]> Content-Disposition: inline Precedence: bulk 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 <davidb@verisignlabs.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 19:58:35 +0100 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> <16567.20826.302378.846966@giles.gnomon.org.uk> <a0602042cbcdd2cd7f2ba@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: roy@dnss.ec, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 21:06:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a0602042cbcdd2cd7f2ba@[192.168.1.100]> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Edward" == Edward Lewis <edlewis@arin.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial Mechanism Flag) Date: Fri, 28 May 2004 15:28:41 -0400 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <roy@gnomon.org.uk> <16565.45956.205803.87821@giles.gnomon.org.uk> <20040527181920.660CE13DED@sa.vix.com> <16566.14967.104462.921988@giles.gnomon.org.uk> <a06020412bcdbf721e5e8@[192.168.1.100]> <Pine.LNX.4.58.0405281026550.15786@elektron.atoom.net> <16567.20826.302378.846966@giles.gnomon.org.uk> <a0602042cbcdd2cd7f2ba@[192.168.1.100]> <16567.35803.237199.333100@giles.gnomon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Edward Lewis <edlewis@arin.net>, roy@dnss.ec, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri May 28 21:41:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <16567.35803.237199.333100@giles.gnomon.org.uk> To: Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Date: Fri, 28 May 2004 12:41:11 -0700 Lines: 48 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Fri May 28 21:47:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'David Blacka'" <davidb@verisignlabs.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Edward Lewis <edlewis@arin.net> Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Date: Fri, 28 May 2004 18:06:34 -0400 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBD37@mou1wnexm05.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "'David Blacka'" <davidb@verisignlabs.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 29 00:23:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBD37@mou1wnexm05.vcorp.ad.vrsn.com> To: "Hallam-Baker, Phillip" <pbaker@verisign.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Date: Fri, 28 May 2004 16:48:41 -0700 Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'David Blacka'" <davidb@verisignlabs.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 29 01:58:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Edward Lewis'" <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com> X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: don@plugh.daedalus.co.nz Subject: Re: Confirming the Nominet position Date: Sat, 29 May 2004 15:16:11 +1200 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040527212159.B163013DE9@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Sat May 29 05:31:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 27 May 2004 21:21:59 GMT." <20040527212159.B163013DE9@sa.vix.com> Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: planned obsolescence, and another TCR Date: Sat, 29 May 2004 06:10:33 +0000 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <edlewis@arin.net> X-From: owner-namedroppers@ops.ietf.org Sat May 29 08:20:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Fri, 28 May 2004 18:06:34 -0400." <a06020401bcdd64828412@[192.168.1.100]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: don@plugh.daedalus.co.nz Subject: Re: NSEC+ and NO Date: Sat, 29 May 2004 23:06:22 +1200 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <20040527140611.2E25913951@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Sat May 29 13:21:25 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Thu, 27 May 2004 14:06:11 GMT." <20040527140611.2E25913951@sa.vix.com> Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC+ and NO Date: Sat, 29 May 2004 14:20:12 +0100 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040527140611.2E25913951@sa.vix.com> <84493.1085828782@toybsd.zl2tnm.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat May 29 15:28:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: don@plugh.daedalus.co.nz In-Reply-To: <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) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) Precedence: bulk >>>>> "don" == don <don@plugh.daedalus.co.nz> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC+ and NO Date: Sat, 29 May 2004 15:09:35 +0000 Lines: 64 Sender: owner-namedroppers@ops.ietf.org References: <84493.1085828782@toybsd.zl2tnm.gen.nz> X-From: owner-namedroppers@ops.ietf.org Sat May 29 17:18:12 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: Re: NSEC+ and NO Date: Sun, 30 May 2004 00:13:59 +0100 Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <84493.1085828782@toybsd.zl2tnm.gen.nz> <20040529150935.9DB3413960@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun May 30 01:30:49 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040529150935.9DB3413960@sa.vix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Paul" == Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: planned obsolescence, and another TCR Date: Sat, 29 May 2004 20:50:15 -0400 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <20040529061033.2BFE213960@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun May 30 02:55:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040529061033.2BFE213960@sa.vix.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: planned obsolescence, and another TCR Date: Sun, 30 May 2004 02:10:41 +0000 Lines: 47 Sender: owner-namedroppers@ops.ietf.org References: <ghudson@MIT.EDU> X-From: owner-namedroppers@ops.ietf.org Sun May 30 04:17:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Greg Hudson <ghudson@MIT.EDU> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: NSEC+ and NO Date: Sun, 30 May 2004 12:51:24 +0100 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <20040527140611.2E25913951@sa.vix.com> <84493.1085828782@toybsd.zl2tnm.gen.nz> <16568.36364.702734.481383@giles.gnomon.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 30 13:55:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk>, don@plugh.daedalus.co.nz In-Reply-To: <16568.36364.702734.481383@giles.gnomon.org.uk> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --On 29 May 2004 14:20 +0100 Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: NSEC+ and NO Date: Sun, 30 May 2004 12:49:32 +0100 Lines: 37 Sender: owner-namedroppers@ops.ietf.org References: <84493.1085828782@toybsd.zl2tnm.gen.nz> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 30 13:56:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: don@plugh.daedalus.co.nz, namedroppers@ops.ietf.org In-Reply-To: <84493.1085828782@toybsd.zl2tnm.gen.nz> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Alex Bligh <alex@alex.org.uk> Subject: Re: NSEC+ and NO Date: Sun, 30 May 2004 12:54:58 +0100 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <84493.1085828782@toybsd.zl2tnm.gen.nz> <20040529150935.9DB3413960@sa.vix.com> <16569.6455.83241.185567@giles.gnomon.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 30 13:58:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Roy Badami <roy@gnomon.org.uk>, Paul Vixie <paul@vix.com> In-Reply-To: <16569.6455.83241.185567@giles.gnomon.org.uk> X-Mailer: Mulberry/3.1.1 (Win32) Content-Disposition: inline Precedence: bulk --On 30 May 2004 00:13 +0100 Roy Badami <roy@gnomon.org.uk> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC+ and NO Date: Sun, 30 May 2004 17:16:19 +0000 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <alex@alex.org.uk> X-From: owner-namedroppers@ops.ietf.org Sun May 30 19:29:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC+ and NO Date: Sun, 30 May 2004 17:30:44 +0000 Lines: 11 Sender: owner-namedroppers@ops.ietf.org References: <paul@vix.com> X-From: owner-namedroppers@ops.ietf.org Sun May 30 19:36:50 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Paul Vixie <paul@vix.com> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Don Stokes <don@plugh.daedalus.co.nz> Subject: Re: NSEC+ and NO Date: Mon, 31 May 2004 11:32:52 +1200 Lines: 53 Sender: owner-namedroppers@ops.ietf.org References: <20040529150935.9DB3413960@sa.vix.com> X-From: owner-namedroppers@ops.ietf.org Mon May 31 01:44:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Sat, 29 May 2004 15:09:35 GMT." <20040529150935.9DB3413960@sa.vix.com> Precedence: bulk Paul Vixie <paul@vix.com> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: Paul Vixie <paul@vix.com> Subject: Re: NSEC+ and NO Date: Mon, 31 May 2004 02:18:56 +0000 Lines: 52 Sender: owner-namedroppers@ops.ietf.org References: <don@plugh.daedalus.co.nz> X-From: owner-namedroppers@ops.ietf.org Mon May 31 04:28:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Don Stokes <don@plugh.daedalus.co.nz> 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: don%plugh@daedalus.co.nz Subject: Re: Confirming the Nominet position Date: Sat, 29 May 2004 22:18:42 +1200 Lines: 51 Sender: owner-namedroppers@ops.ietf.org References: <17887.1085742805@munnari.OZ.AU> X-From: owner-namedroppers@ops.ietf.org Mon May 31 07:11:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Your message of "Fri, 28 May 2004 18:13:25 +0700." <17887.1085742805@munnari.OZ.AU> 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 <kre@munnari.OZ.AU> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:55 2006 From: roy@dnss.ec Subject: Re: planned obsolescence, and another TCR Date: Mon, 31 May 2004 12:38:46 +0200 (CEST) Lines: 50 Sender: owner-namedroppers@ops.ietf.org References: <20040529061033.2BFE213960@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 31 12:51:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Paul Vixie <paul@vix.com> In-Reply-To: <20040529061033.2BFE213960@sa.vix.com> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: Roy Badami <roy@gnomon.org.uk> Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Date: Mon, 31 May 2004 13:02:36 +0100 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <C6DDA43B91BFDA49AA2F1E473732113E5DBD37@mou1wnexm05.vcorp.ad.vrsn.com> <a06020401bcdd64828412@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'David Blacka'" <davidb@verisignlabs.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 31 14:09:48 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Edward Lewis <edlewis@arin.net> In-Reply-To: <a06020401bcdd64828412@[192.168.1.100]> X-Mailer: VM 7.18 under Emacs 21.3.1 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) Precedence: bulk >>>>> "Edward" == Edward Lewis <edlewis@arin.net> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: ted@NLnetLabs.nl (Ted Lindgreen) Subject: Re: Proposal to fix NSEC Date: Mon, 31 May 2004 14:58:19 +0200 Lines: 46 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 31 15:03:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 <olaf@ripe.net>, 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: Jim Reid <jim@rfc1035.com> Subject: Re: Proposal to fix NSEC Date: Mon, 31 May 2004 15:27:23 +0100 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> Cc: Olaf Kolkman <olaf@ripe.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 31 16:35:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: ted@NLnetLabs.nl (Ted Lindgreen) In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Mon, 31 May 2004 14:58:19 +0200." <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> Precedence: bulk >>>>> "Ted" == Ted Lindgreen <ted@NLnetLabs.nl> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Proposal to fix NSEC Date: Mon, 31 May 2004 15:29:34 +0100 (BST) Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> X-From: owner-namedroppers@ops.ietf.org Mon May 31 16:35:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: Proposal to fix NSEC Date: Mon, 31 May 2004 11:00:12 -0400 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <20040531142934.C0F20E7E4D@mx1.nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 31 17:07:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Geoffrey Sisson <geoff@nominet.org.uk> In-Reply-To: <20040531142934.C0F20E7E4D@mx1.nominet.org.uk> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk (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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: geoff@nominet.org.uk (Geoffrey Sisson) Subject: Re: Proposal to fix NSEC Date: Mon, 31 May 2004 16:25:58 +0100 (BST) Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <1086015612.1468.72.camel@egyptian-gods.mit.edu> X-From: owner-namedroppers@ops.ietf.org Mon May 31 17:33:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <1086015612.1468.72.camel@egyptian-gods.mit.edu> Precedence: bulk Greg Hudson <ghudson@MIT.EDU> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> Subject: Re: Scope of discussion (was Re: Proposal to fix NSEC) Date: Mon, 31 May 2004 11:42:44 -0400 Lines: 70 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: owner-namedroppers@ops.ietf.org Mon May 31 17:50:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: roy@dnss.ec Subject: Re: Proposal to fix NSEC Date: Mon, 31 May 2004 19:08:28 +0200 (CEST) Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Olaf Kolkman <olaf@ripe.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 31 19:18:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs X-X-Sender: roy@elektron.atoom.net To: Ted Lindgreen <ted@NLnetLabs.nl> In-Reply-To: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> X-Virus-Scanned: by amavisd-new 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: "Jay Daley" <td@nominet.org.uk> Subject: Re: Proposal to fix NSEC Date: Mon, 31 May 2004 22:26:01 +0100 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <1086015612.1468.72.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Cc: Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon May 31 23:44:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <1086015612.1468.72.camel@egyptian-gods.mit.edu> To: Greg Hudson <ghudson@MIT.EDU> X-Mailer: Lotus Notes Release 6.5 September 18, 2003 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 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: Ted Hardie <hardie@qualcomm.com> Subject: Re: Proposal to fix NSEC Date: Mon, 31 May 2004 16:51:23 -0700 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> <Pine.LNX.4.58.0405311903100.29810@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Olaf Kolkman <olaf@ripe.net>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Jun 01 02:01:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: hardie@mage.qualcomm.com In-Reply-To: <Pine.LNX.4.58.0405311903100.29810@elektron.atoom.net> To: roy@dnss.ec, Ted Lindgreen <ted@NLnetLabs.nl> 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:56 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: Confirming the Nominet position Date: Fri, 28 May 2004 14:02:35 -0400 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <20040527135425.GA10971@vacation.karoshi.com.> <OFCBB87463.D9ECD53E-ON80256EA1.006FAD30-80256EA1.007037EF@nominet.org.uk> <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 Cc: Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Jun 02 16:40:17 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: bmanning@vacation.karoshi.com In-Reply-To: <20040528151621.GA13996@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Fri, 28 May 2004 15:16:21 +0000") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) 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. Except signatures can be removed. For example, if I were to (theoretically) illictly obtain a signed document, I could use the signature to prove to someone that W went to war in Iraq without proof of WMD. However I don't have to reproduce that signature in all cases, I could remove it in my copy, so you couldn't verify the origin of the document. 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. -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: <http://ops.ietf.org/lists/namedroppers/>