From owner-namedroppers@ops.ietf.org Tue Jun 1 02:44:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25280 for ; Tue, 1 Jun 2004 02:44:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV2sa-0000x4-LK for namedroppers-data@psg.com; Tue, 01 Jun 2004 06:36:08 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV2sX-0000wP-Vj for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 06:36:06 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D922A51CAF; Tue, 1 Jun 2004 08:35:02 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5377651D94 for ; Tue, 1 Jun 2004 08:35:02 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i516Z2Q2021922 for ; Tue, 1 Jun 2004 08:35:02 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i516Z2tm016952 for namedroppers@ops.ietf.org; Tue, 1 Jun 2004 08:35:02 +0200 Date: Tue, 1 Jun 2004 08:35:02 +0200 From: Olaf Kolkman Message-Id: <200406010635.i516Z2tm016952@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Status: U 0.498292 / 0.0 / 0.0 / disabled X-RIPE-Signature: 22fe78af8cbe4a45ec307c7218e71475 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.7 2004/05/17 12:46:38 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 03:49:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02928 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 03:49:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV3yb-0009if-KO for namedroppers-data@psg.com; Tue, 01 Jun 2004 07:46:25 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV3yZ-0009iJ-N8 for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 07:46:24 +0000 Received: from hypatia.dns.net (c9-rba-67.dial-up.net [196.33.246.67]) by mercury.is.co.za (Postfix) with ESMTP id 14155C8E2D; Tue, 1 Jun 2004 09:46:19 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i516IAr01821; Tue, 1 Jun 2004 08:18:10 +0200 Date: Tue, 1 Jun 2004 08:18:10 +0200 From: Andras Salamon <andras@dns.net> To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC Message-ID: <20040601061810.GF1765@dns.net> References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> <Pine.LNX.4.58.0405311903100.29810@elektron.atoom.net> <p06100500bce17569d2cd@[205.214.163.64]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <p06100500bce17569d2cd@[205.214.163.64]> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 31 May 2004, Ted Lindgreen wrote: > So, I think that the working group should NOT delay DNSSECbis by > trying to fold in NSEC2 this late in the process. If NSEC2 needs > to be worked out it should be done in a separate track. Agreed. -- 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 Tue Jun 1 06:18:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12762 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 06:18:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV6IM-0004OW-2z for namedroppers-data@psg.com; Tue, 01 Jun 2004 10:14:58 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV6IK-0004OC-RY for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 10:14:57 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 7B49E1FF89A; Tue, 1 Jun 2004 10:14:48 +0000 (GMT) Message-ID: <40BC5719.8060301@algroup.co.uk> Date: Tue, 01 Jun 2004 11:14:49 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> Cc: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'David Blacka'" <davidb@verisignlabs.com>, namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) References: <C6DDA43B91BFDA49AA2F1E473732113E5DBD37@mou1wnexm05.vcorp.ad.vrsn.com> <a06020401bcdd64828412@[192.168.1.100]> In-Reply-To: <a06020401bcdd64828412@[192.168.1.100]> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > 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. The cost you refer to is extra data in negative DNS responses, correct? But these are only incurred in zones which include labels of the form a.b. In the kind of zone we're talking about (.co.uk) there are no such labels, so the overhead comes down to the extra data size rather than many extra records, as seen in your examples. 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 Tue Jun 1 06:38:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14401 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 06:38:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV6bd-00081X-CA for namedroppers-data@psg.com; Tue, 01 Jun 2004 10:34:53 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV6bb-000814-PM for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 10:34:52 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id D7ADD1FF864; Tue, 1 Jun 2004 10:34:50 +0000 (GMT) Message-ID: <40BC5BCC.4040500@algroup.co.uk> Date: Tue, 01 Jun 2004 11:34:52 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lindgreen <ted@NLnetLabs.nl> Cc: Olaf Kolkman <olaf@ripe.net>, namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> In-Reply-To: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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. If we follow this path, it still leaves two options open at this stage, AFAICS: a) Add some kind of version indication to something so that NSEC2 can be folded in later and not break deployed code (beyond the obvious breakage if it no longer understanding the response, of course). b) Assume that NSEC2 will somehow find a way within the DNSSECbis docset to migrate without change to DNSSECbis. I actually am still of the view that if nameservers suddenly started returning NSEC2 instead of NSEC things would work as desired: namely old resolvers would suddenly get protocol errors instead of NXDOMAIN, and new resolvers would just work. If this causes bad things to happen, then DNSSECbis is already broken, since an attacker can clearly cause NSEC records to be corrupt. 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 Tue Jun 1 06:45:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14907 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 06:45:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV6ir-0009Lb-Eq for namedroppers-data@psg.com; Tue, 01 Jun 2004 10:42:21 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV6ip-0009L9-64 for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 10:42:19 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id D76FB108FCC; Tue, 1 Jun 2004 10:42:17 +0000 (GMT) Message-ID: <40BC5D8A.1050709@algroup.co.uk> Date: Tue, 01 Jun 2004 11:42:18 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh <alex@alex.org.uk> Cc: don@plugh.daedalus.co.nz, namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO References: <84493.1085828782@toybsd.zl2tnm.gen.nz> <1036874717.1085921372@[192.168.100.5]> In-Reply-To: <1036874717.1085921372@[192.168.100.5]> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > --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). For example, returning NXDOMAIN instead of an A or MX record for a domain name used for email causes all your email to get dropped instead of queued. This strikes me as bad. 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 Tue Jun 1 07:12:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17330 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 07:12:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV7Al-000EmV-Mu for namedroppers-data@psg.com; Tue, 01 Jun 2004 11:11:11 +0000 Received: from [131.111.8.18] (helo=draco.cus.cam.ac.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV7Ak-000Elm-J9 for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 11:11:10 +0000 Received: from cet1 by draco.cus.cam.ac.uk with local (Exim 4.34) id 1BV7Ak-0002F4-5s for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 12:11:10 +0100 Subject: Re: Proposal to fix NSEC To: namedroppers@ops.ietf.org Date: Tue, 1 Jun 2004 12:11:10 +0100 (BST) In-Reply-To: <40BC5BCC.4040500@algroup.co.uk> from "Ben Laurie" at Jun 1, 4 11:34:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <E1BV7Ak-0002F4-5s@draco.cus.cam.ac.uk> From: Chris Thompson <cet1@cus.cam.ac.uk> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ben@algroup.co.uk (Ben Laurie) writes: [...] > I actually am still of the view that if nameservers suddenly started > returning NSEC2 instead of NSEC things would work as desired: namely old > resolvers would suddenly get protocol errors instead of NXDOMAIN, and > new resolvers would just work. > > If this causes bad things to happen, then DNSSECbis is already broken, > since an attacker can clearly cause NSEC records to be corrupt. Define "bad". DNSSEC has never been proof against DoS attacks that make it unable to answer questions (as opposed to answer them incorrectly). That doesn't mean that a protocol change that would simulate the effect of a DoS attack would be a desirable thing to advocate. Chris Thompson Email: cet1@cam.ac.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 Tue Jun 1 09:32:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28717 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 09:32:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV9JC-000C2m-KA for namedroppers-data@psg.com; Tue, 01 Jun 2004 13:28:02 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV9J9-000C2F-7P for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 13:27:59 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 915F5E7EB5; Tue, 1 Jun 2004 14:27:58 +0100 (BST) To: namedroppers@ops.ietf.org Subject: WGLC for DNSSECbis docs Message-Id: <20040601132758.915F5E7EB5@mx1.nominet.org.uk> Date: Tue, 1 Jun 2004 14:27:58 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I speak for myself and on behalf and Nominet UK. I believe the use of NSEC RRs is entirely suitable for many DNSSEC applications. In particular, a compelling case exists for their use in zones under {in-addr,ipv6,e164}.arpa where meaningful enumeration is already trivial. I don't believe that an authenticated denial of existence ("negative answer") scheme that is designed to be enumeration-resistant, such as NO or NSEC2, should replace NSEC, but should be available strictly as an alternative, for use in zones where the risk or operational impact of enumeration presents special problems. I understand that it would be impractical at this time to insist upon the inclusion of an alternative negative answer scheme in DNSSECbis. However I believe that it's essential to defer the approval of the current drafts long enough to consider what might be done to make them "friendly" to the future incorporation of an alternative negative answer scheme, in particular, possibly adding a version (or at least MBZ) field to the NSEC RR RDATA field. While the discussion so far appears to be undecided as to whether DNSSECbis can be non-invasively extended to accommodate multiple methods for negative answers, I believe it is preferable to have rough consensus on this issue *before* the current docset goes to the IESG. This shouldn't require a one-year delay, as some of the more pessimistic projections have put it. I sincerely hope the dnsext WG chairs, the Internet Area ADs, and the IESG will recognise that a DNSSEC specification that meets its original design goals but fails to satisfy the operational requirements of a number of significant DNS operators, such as Nominet UK (.uk ccTLD registry) and DeNIC (.de ccTLD registry), will be a serious impediment to the deployment of the protocol. Moreover, I suspect that NSEC RR elaboration will become an operational nuisance even for registries with relatively weak privacy requirements, such as the ICANN gNSO member registries, which may potentially further erode support for the protocol. In short, I request the WGLC be extended at least long enough to establish rough consensus on whether an alternate negative reply scheme can be incorporated into DNSSECbis, or if DNSSECter will be required instead. I've followed the work of this group for a number of years; it would be an understatement to say that I respect and admire the authors and supporting cast for the DNSSECbis docset. So it's painful to find myself having to take sides against some of you. But, under the circumstances, I believe I have little choice. Regards Geoffrey Sisson Nominet 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 Tue Jun 1 09:32:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28741 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 09:32:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BV9M2-000CXC-Gs for namedroppers-data@psg.com; Tue, 01 Jun 2004 13:30:58 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BV9M1-000CWx-Ef for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 13:30:57 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 42C8119B3A4; Tue, 1 Jun 2004 09:25:26 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id AADE619B43A for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 09:25:25 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1715433; Tue, 01 Jun 2004 09:30:55 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020404bce232666da4@[192.168.1.100]> Date: Tue, 1 Jun 2004 09:27:11 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: question about "what is a legal name?" Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In the MARID WG, there is consideration being given to names such as the following: _marid.*.foo.com. I've been saying that the name above is not legal, based on the words in RFC 1034, section 4.3.3 that define wild cards. One answer I have received is that the above name is not a wild card, hence the restrictions that no "*" appear in the <domain> there is not valid. I'd like to hear from others on this, whether the above name is legal or not, whether there is an interoperability issue stemming from the the lack of clarity in the documents. Here's my take. Looking at the tree of labels, I'm going to add a.foo.com and c.foo.com, leaving b.foo.com out. . | com | foo-------------------- | | | * a(.foo.com) c(.foo.com) | _marid What happens when a query arrives for b.foo.com? I think the intent in the specs is to not use *.foo.com. as a "wild card". From the definition of a wild card as "*.<domain without *>", I think the server ought not synthesize from that record. This implies that the algorithm of "find the closest encloser, which is foo.com, and use the '*' labelled child for synthesis" has to be amended to watch out for '*' with children. Another issue I can see of permitting such names is to start with just "*.foo.com." and not the "_marid" label. Assuming the administrator is expecting "*.foo.com." to be a wild card, what happens when some one adds, via dynamic update, the label "_marid" below that domain? Should this addition be barred from dynamic update? These are two "corner cases" that arise from mid-tree * labels. Perhaps implementors feel that there's a way around this by adding flag bits on the labels or by implementing more rules for processing, but my *opinion* is that such names ought to be considered bad ju-ju. (Note: I'm neglecting the "why" of even thinking of such a 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 Tue Jun 1 10:14:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04891 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 10:14:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVA03-000ILc-Nz for namedroppers-data@psg.com; Tue, 01 Jun 2004 14:12:19 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVA01-000ILL-PJ for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 14:12:19 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id C289919B5C9; Tue, 1 Jun 2004 10:06:44 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 4AFA319B478; Tue, 1 Jun 2004 10:06:44 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1715616; Tue, 01 Jun 2004 10:12:15 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602040cbce23d44f9be@[192.168.1.100]> In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBD42@mou1wnexm05.vcorp.ad.vrsn.com> References: <C6DDA43B91BFDA49AA2F1E473732113E5DBD42@mou1wnexm05.vcorp.ad.vrsn.com> Date: Tue, 1 Jun 2004 10:12:19 -0400 To: "Hallam-Baker, Phillip" <pbaker@verisign.com> From: Edward Lewis <edlewis@arin.net> Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Cc: "'Edward Lewis'" <edlewis@arin.net>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:48 -0700 5/28/04, Hallam-Baker, Phillip wrote: >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. Well, convincing not "Europeans" but those with privacy concerns...;) Fine with me, but I'm not optimistic that we can find a "future amendment" means. I'm often wrong. I mean, from the thinking I've done, I really don't see a way to introduce versioning to the DNS protocol. I haven't proven (even to myself) that it can't be done. From all the angles I've looked and with all of my assumptions applied it looks bleak though. The only versioning precedent we have is EDNS(0) - and that only works because an "advanced" protocol speaker falls back to the old ways to a "legacy" protocol speaker. I don't see this strategy working between NSEC and obfuscated authenticated denial. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Jun 1 10:23:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06503 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 10:23:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVA8G-000JQO-G6 for namedroppers-data@psg.com; Tue, 01 Jun 2004 14:20:48 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVA8F-000JPv-Ld for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 14:20:47 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EE43D13DE5 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 14:20:46 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Tue, 01 Jun 2004 11:34:52 +0100." <40BC5BCC.4040500@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 01 Jun 2004 14:20:46 +0000 Message-Id: <20040601142046.EE43D13DE5@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > If we follow this path, it still leaves two options open at this stage, > AFAICS: > ... > b) Assume that NSEC2 will somehow find a way within the DNSSECbis docset to > migrate without change to DNSSECbis. i'm writing up a proposal to this effect in the xterm next to this one. > I actually am still of the view that if nameservers suddenly started > returning NSEC2 instead of NSEC things would work as desired: namely old > resolvers would suddenly get protocol errors instead of NXDOMAIN, and new > resolvers would just work. that would be a downgrade attack, launched by a zone owner against herself, and would only be of interest to zone owners who had not previously implemented dnssec-bis. let's do better. i know several ways to do better. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 10:37:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08421 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 10:37:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVALS-000LY5-PE for namedroppers-data@psg.com; Tue, 01 Jun 2004 14:34:26 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVALR-000LXo-V4 for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 14:34:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A9CA913DE5 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 14:34:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Tue, 01 Jun 2004 10:12:19 -0400." <a0602040cbce23d44f9be@[192.168.1.100]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 01 Jun 2004 14:34:25 +0000 Message-Id: <20040601143425.A9CA913DE5@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ..., but I'm not optimistic that we can find a "future amendment" > means. I'm often wrong. I mean, from the thinking I've done, I > really don't see a way to introduce versioning to the DNS protocol. it's a second dnssec-wanted flag in edns0. (dnssec-bis already depends on edns so this is not a big change.) the bit means "when i said i wanted dnssec responses, i really meant i could handle dnssec-ter if you've got it.) > I haven't proven (even to myself) that it can't be done. From all the > angles I've looked and with all of my assumptions applied it looks bleak > though. > > The only versioning precedent we have is EDNS(0) - and that only works > because an "advanced" protocol speaker falls back to the old ways to a > "legacy" protocol speaker. I don't see this strategy working between > NSEC and obfuscated authenticated denial. if NSEC2 has a new type code (and maybe RRSIG but probably not DNSKEY) and if we promote "want dnssec-ter" as from hop-by-hop to end-to-end (by only returning cached data if it was acquired using the same flags as the current query) then this is all pretty simple. the harder problem is how to keep a bazillion other features out so that -ter can deploy in a short year or two rather than a whole decade. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 10:40:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08689 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 10:40:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVAOv-000MHp-Tw for namedroppers-data@psg.com; Tue, 01 Jun 2004 14:38:01 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVAOu-000MHB-MB for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 14:38:00 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 01 Jun 2004 10:37:59 -0400 id 0013672B.40BC94C7.0000541B From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: protocol-06 section 4.5 Date: Tue, 1 Jun 2004 10:37:59 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200406011037.59743.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I (still) have a problem with section 4.5 of draft-ietf-dnsext-dnssec-protocol-06. Here is the text of that section: A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. In most cases the appropriate cache index for the atomic entry will be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response form described in Section 3.1.3.2 the appropriate cache index will be the double <QNAME,QCLASS>. My first issue of this is that there is no "WHY" expressed here. Given that this is a SHOULD, how is an implementer to know whether or not to follow this method? Second, this is essentially *implementation* advice, not a protocol advisement. Further, it is advising a caching strategy that, AFAIK, the DNS community doesn't have much experience with. Of course, I personally have a hard time seeing how this method would cause problems (other than lack of efficiency), but without experience, it is hard to say. Third, this section, since it says what resolvers SHOULD do, rather than what they MUST NOT do, it stifles resolver innovation. Fourth, it looks like a significantly less efficient caching strategy. Here are some scenarios where a RRset level cache would be able to respond out of cache, but a resolver using this strategy wouldn't: When a subsequent query is for something returned in the authority section of a previous response, like: Q1: www.example.com IN A R1: ANS: www.example.com IN A 1.2.3.4 AUTH example.com NS ns1.example.com example.com NS ns.example.net ADD: ns1.example.com IN A 1.2.3.5 Q2: example.com IN NS Q1: does-not-exist.example.com IN A R1: AUTH: example.com. SOA .... Q2: example.com IN SOA And perhaps more damaging, when a query for an internally followed CNAME is followed by a query for what the CNAME resolved to: Q1: cname.example.com IN A R1: ANS: cname.example.com IN CNAME www.example.com www.example.com IN A 1.2.3.4. AUTH: example.com NS ... etc. Q2: www.example.com. IN A There are probably more examples where this proposed caching strategy results in a cache miss, where a per RRset cache would result in a cache hit. Am I the only one who cares about this? Are resolver authors just going to ignore this section? Does BIND 9.3.x follow this section (I don't think so, but I could be wrong)? I would have written new language for this section myself if I understood what problem it was trying to solve. I've looked through namedroppers archives and failed to find the genesis of this language (I'm not saying it is definitely not there, but I couldn't find it). If we, as a WG, can figure out what the problem is, we can write a section that talks about what resolvers MUST NOT do. If we cannot, we should just drop the whole section. -- 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 Tue Jun 1 10:41:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08877 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 10:41:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVAPC-000ML3-D0 for namedroppers-data@psg.com; Tue, 01 Jun 2004 14:38:18 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVAP3-000MJ8-JB for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 14:38:09 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 59A7E13DDA for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 14:38:09 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Tue, 01 Jun 2004 14:27:58 +0100." <20040601132758.915F5E7EB5@mx1.nominet.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 01 Jun 2004 14:38:09 +0000 Message-Id: <20040601143809.59A7E13DDA@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I understand that it would be impractical at this time to insist upon > the inclusion of an alternative negative answer scheme in DNSSECbis. > However I believe that it's essential to defer the approval of the > current drafts long enough to consider what might be done to make them > "friendly" to the future incorporation of an alternative negative > answer scheme, in particular, possibly adding a version (or at least > MBZ) field to the NSEC RR RDATA field. they are already friendly, in terms of a new edns0 flag bit having end-to-end caching/forwarding treatment, and new type codes. MBZ on the other hand would open a can that contains a large number of worms. would the whole RDATA be able to change based on this MBZ not being zero? if so, then an implementor who ignored the MBZness would not be penalized until several years had gone by, which has usually been a recipe for disaster. > ... > In short, I request the WGLC be extended at least long enough to > establish rough consensus on whether an alternate negative reply scheme > can be incorporated into DNSSECbis, or if DNSSECter will be required > instead. i think that this has already been achieved, but i'm writing it up anyway. > ... > This shouldn't require a one-year delay, as some of the more > pessimistic projections have put it. adding an MBZ would absolutely have that effect on the schedule. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 10:55:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10916 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 10:55:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVAdT-000OV8-Va for namedroppers-data@psg.com; Tue, 01 Jun 2004 14:53:03 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVAdS-000OUW-FJ for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 14:53:02 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i51Eqwom056309; Tue, 1 Jun 2004 16:52:58 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i51EqsWq005071; Tue, 1 Jun 2004 16:52:54 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i51EqsmC005068; Tue, 1 Jun 2004 16:52:54 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 1 Jun 2004 16:52:54 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) In-Reply-To: <20040601143425.A9CA913DE5@sa.vix.com> Message-ID: <Pine.LNX.4.58.0406011644250.4343@elektron.atoom.net> References: <20040601143425.A9CA913DE5@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Jun 2004, Paul Vixie wrote: > if NSEC2 has a new type code (and maybe RRSIG but probably not DNSKEY) and > if we promote "want dnssec-ter" as from hop-by-hop to end-to-end (by only > returning cached data if it was acquired using the same flags as the current > query) then this is all pretty simple. DS as well, to protect non NSEC2 capable resolvers being delegated into a NSEC2 zone. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 12:00:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18167 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 12:00:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVBcm-000883-Iq for namedroppers-data@psg.com; Tue, 01 Jun 2004 15:56:24 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVBcl-00087l-JU for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 15:56:23 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id D76D41FF84A; Tue, 1 Jun 2004 15:56:21 +0000 (GMT) Message-ID: <40BCA726.7020904@algroup.co.uk> Date: Tue, 01 Jun 2004 16:56:22 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Thompson <cet1@cus.cam.ac.uk> Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <E1BV7Ak-0002F4-5s@draco.cus.cam.ac.uk> In-Reply-To: <E1BV7Ak-0002F4-5s@draco.cus.cam.ac.uk> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Chris Thompson wrote: > ben@algroup.co.uk (Ben Laurie) writes: > [...] > >>I actually am still of the view that if nameservers suddenly started >>returning NSEC2 instead of NSEC things would work as desired: namely old >>resolvers would suddenly get protocol errors instead of NXDOMAIN, and >>new resolvers would just work. >> >>If this causes bad things to happen, then DNSSECbis is already broken, >>since an attacker can clearly cause NSEC records to be corrupt. > > > Define "bad". DNSSEC has never been proof against DoS attacks that make > it unable to answer questions (as opposed to answer them incorrectly). > That doesn't mean that a protocol change that would simulate the effect > of a DoS attack would be a desirable thing to advocate. I certainly agree that if we could do better, we should. 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 Tue Jun 1 12:10:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19025 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 12:10:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVBmf-000AAc-Mz for namedroppers-data@psg.com; Tue, 01 Jun 2004 16:06:37 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVBme-000AAF-KV for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 16:06:36 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 9A2D019B4AD; Tue, 1 Jun 2004 12:01:03 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 1F92C19B38E; Tue, 1 Jun 2004 12:01:03 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1716134; Tue, 01 Jun 2004 12:06:35 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020410bce2572f0ccf@[192.168.1.100]> In-Reply-To: <40BC5719.8060301@algroup.co.uk> References: <C6DDA43B91BFDA49AA2F1E473732113E5DBD37@mou1wnexm05.vcorp.ad.vrsn.com> <a06020401bcdd64828412@[192.168.1.100]> <40BC5719.8060301@algroup.co.uk> Date: Tue, 1 Jun 2004 12:05:54 -0400 To: Ben Laurie <ben@algroup.co.uk> From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:14 +0100 6/1/04, Ben Laurie wrote: >The cost you refer to is extra data in negative DNS responses, correct? But >these are only incurred in zones which include labels of the form a.b. In the >kind of zone we're talking about (.co.uk) there are no such labels, so the >overhead comes down to the extra data size rather than many extra records, as >seen in your examples. The cost, as far as the server is concerned, is the computation of hashes and the larger response. (Ditto for the client too.) But the cost isn't limited to any kind of zones. No matter what the "shape" of the zone is, a mischievous client can construct a query that force the server into computing hashes of N names. E.g., let's say 9.net doesn't exist. I can ask for 1.2.3.4.5.6.7.8.9.9.net and the net. servers would need to calculate 11 hashes to answer. If the client asks for 1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net the server now needs to do 20 hashes. My concern is that the client determines the load. Even if the zone is like ip6.arpa, no matter what the existing delegations look like, I can always game the queries to induce the server into a lot of computing cycles. And then there's the answer size issue. In the example above, if I compute 20 hashes, I may need to send 20 NSEC2's and 20 RRSIGs. But I could do better - if hashes fall into shared ranges. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Jun 1 12:10:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19111 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 12:10:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVBme-000AAK-PT for namedroppers-data@psg.com; Tue, 01 Jun 2004 16:06:36 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVBmc-000A94-OD for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 16:06:34 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id ACEAE19B3E6; Tue, 1 Jun 2004 12:01:01 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 33EEF19B38E; Tue, 1 Jun 2004 12:01:01 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1716132; Tue, 01 Jun 2004 12:06:33 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602040fbce256b7f0c6@[192.168.1.100]> In-Reply-To: <16571.7900.899506.817355@giles.gnomon.org.uk> References: <C6DDA43B91BFDA49AA2F1E473732113E5DBD37@mou1wnexm05.vcorp.ad.vrsn.com> <a06020401bcdd64828412@[192.168.1.100]> <16571.7900.899506.817355@giles.gnomon.org.uk> Date: Tue, 1 Jun 2004 11:53:58 -0400 To: Roy Badami <roy@gnomon.org.uk> From: Edward Lewis <edlewis@arin.net> Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Cc: Edward Lewis <edlewis@arin.net>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, "'David Blacka'" <davidb@verisignlabs.com>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:02 +0100 5/31/04, Roy Badami wrote: >>>>>> "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 Okay. That eliminates the use of insane NSEC RR's as a migration strategy. Not that it was all that promising. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Jun 1 12:30:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21626 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 12:30:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVC6g-000D95-C3 for namedroppers-data@psg.com; Tue, 01 Jun 2004 16:27:18 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVC6W-000D84-VV for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 16:27:09 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 373BFE7EC3; Tue, 1 Jun 2004 17:27:08 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) In-Reply-To: <a06020410bce2572f0ccf@[192.168.1.100]> Message-Id: <20040601162708.373BFE7EC3@mx1.nominet.org.uk> Date: Tue, 1 Jun 2004 17:27:08 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > But the cost isn't limited to any kind of zones. No matter what the > "shape" of the zone is, a mischievous client can construct a query > that force the server into computing hashes of N names. E.g., let's > say 9.net doesn't exist. I can ask for 1.2.3.4.5.6.7.8.9.9.net and > the net. servers would need to calculate 11 hashes to answer. If the > client asks for 1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net the server > now needs to do 20 hashes. > > My concern is that the client determines the load. > > Even if the zone is like ip6.arpa, no matter what the existing > delegations look like, I can always game the queries to induce the > server into a lot of computing cycles. NSEC2 hashes are generated when the zone is signed, so this shouldn't impose any load which NSEC doesn't already? 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 Tue Jun 1 12:43:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23303 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 12:43:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVCJc-000EqX-Bq for namedroppers-data@psg.com; Tue, 01 Jun 2004 16:40:40 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVCJb-000Eq6-8y for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 16:40:39 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i51GeKkZ002618 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 12:40:20 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i51GeH4A007546 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 12:40:17 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Date: Tue, 1 Jun 2004 12:40:17 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGKEFBCKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040601162708.373BFE7EC3@mx1.nominet.org.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Geoffrey Sisson > Sent: Tuesday, June 01, 2004 12:27 PM > To: namedroppers@ops.ietf.org > Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial > M echanism Flag) > > > Edward Lewis <edlewis@arin.net> writes: > > > But the cost isn't limited to any kind of zones. No matter what the > > "shape" of the zone is, a mischievous client can construct a query > > that force the server into computing hashes of N names. E.g., let's > > say 9.net doesn't exist. I can ask for 1.2.3.4.5.6.7.8.9.9.net and > > the net. servers would need to calculate 11 hashes to answer. If the > > client asks for 1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net the server > > now needs to do 20 hashes. > > > > My concern is that the client determines the load. > > > > Even if the zone is like ip6.arpa, no matter what the existing > > delegations look like, I can always game the queries to induce the > > server into a lot of computing cycles. > > NSEC2 hashes are generated when the zone is signed, so this shouldn't > impose any load which NSEC doesn't already? > The server needs to generate a hash of the queried name (and to find the closest encloser) to find which NSEC2 RR's to include in the response. That's where the client dictates the work to the server, and the point Ed brought up. I wonder if something like the EXIST RR can shorten this work. Just brainstorming, since I have no clue right now. Scott > 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 12:56:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25335 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 12:56:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVCWr-000HKg-OV for namedroppers-data@psg.com; Tue, 01 Jun 2004 16:54:21 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVCWe-000HGc-0d for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 16:54:08 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 486D4139A3 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 16:54:07 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) In-Reply-To: Message from roy@dnss.ec of "Tue, 01 Jun 2004 16:52:54 +0200." <Pine.LNX.4.58.0406011644250.4343@elektron.atoom.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 01 Jun 2004 16:54:07 +0000 Message-Id: <20040601165407.486D4139A3@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > if NSEC2 has a new type code (and maybe RRSIG but probably not > > DNSKEY) and if we promote "want dnssec-ter" as from hop-by-hop to > > end-to-end (by only returning cached data if it was acquired using > > the same flags as the current query) then this is all pretty simple. > > DS as well, to protect non NSEC2 capable resolvers being delegated > into a NSEC2 zone. for the purpose of proving that dnssec-bis can coexist with and ultimately be replaced by dnssec-ter, only one RR has to be shown to be incompatible. furthermore, dnssec-ter might very well use NO rather than NSEC, or opt-in, or who knows what. the point is, it won't be compatible with dnssec-bis, and we have to show that there's a migration strategy that injures nobody. i personally like NSEC2 and i wish that those ideas had been proposed at the time when NO-vs-NXT was being discussed. but that doesn't mean NSEC2 is the winner, or that it would be the only thing in -ter. we need to show that there is a way forward; we do not need to show where that way leads. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 13:09:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27004 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 13:09:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVCiN-000JOT-2c for namedroppers-data@psg.com; Tue, 01 Jun 2004 17:06:15 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVCiL-000JO3-Sw for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 17:06:14 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 19947E7EB2; Tue, 1 Jun 2004 18:06:13 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs In-Reply-To: <20040601143809.59A7E13DDA@sa.vix.com> Message-Id: <20040601170613.19947E7EB2@mx1.nominet.org.uk> Date: Tue, 1 Jun 2004 18:06:13 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> writes: > they are already friendly, in terms of a new edns0 flag bit having end-to-end > caching/forwarding treatment, and new type codes. MBZ on the other hand would > open a can that contains a large number of worms. would the whole RDATA be > able to change based on this MBZ not being zero? With something resembling NSEC2 it would be likely. > if so, then an implementor > who ignored the MBZness would not be penalized until several years had gone > by, which has usually been a recipe for disaster. There aren't many implementations that would have a significant impact if MBZness is ignored, which hopefully makes vigilence a viable solution. But I'm curious: is it reasonable to design protocols to compensate for the rich diversity of ways in which they might be mis-implemented? Or does MBZ/version/reserved for future use/etc. represent a special case? > > This shouldn't require a one-year delay, as some of the more > > pessimistic projections have put it. > > adding an MBZ would absolutely have that effect on the schedule. Yesterday you said: > 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. . . . which I interpreted to mean you believed MBZ might not be so costly. I wouldn't wish to challenge your estimate of a one-year delay, but I would be interested to learn of previous instances where this has happened. 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 Tue Jun 1 13:24:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28699 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 13:24:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVCwD-000Mgy-38 for namedroppers-data@psg.com; Tue, 01 Jun 2004 17:20:33 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVCwC-000Mgj-B6 for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 17:20:32 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EAC9713E02 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 17:20:31 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Tue, 01 Jun 2004 18:06:13 +0100." <20040601170613.19947E7EB2@mx1.nominet.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 01 Jun 2004 17:20:31 +0000 Message-Id: <20040601172031.EAC9713E02@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... MBZ on the other hand would open a can that contains a large > > number of worms. would the whole RDATA be able to change based on > > this MBZ not being zero? > > With something resembling NSEC2 it would be likely. > > > if so, then an implementor who ignored the > > MBZness would not be penalized until several years had gone by, > > which has usually been a recipe for disaster. > > ... I'm curious: is it reasonable to design protocols to compensate > for the rich diversity of ways in which they might be mis-implemented? > Or does MBZ/version/reserved for future use/etc. represent a special > case? when extending a protocol, it's good to first consider changes to an element that you know existing implementations have to look at. BIND has been especially damaging in this area, for example by copying bits in the header flag from query to response rather than ignoring them and making sure they were set to zero in responses. this essentially "used up" the last two flag bits in the dns header, without returning value. > Yesterday you said: > > > 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. > > ...which I interpreted to mean you believed MBZ might not be so costly. overnight i realized three things. 1. an MBZ isn't enforceable in current/proposed implementations. 2. an MBZ would take significant docset and software work to define. 3. a TCR is always possible and is proof against any existing misdesign. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 13:48:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01409 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 13:48:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVDJv-0001Ql-Q4 for namedroppers-data@psg.com; Tue, 01 Jun 2004 17:45:03 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVDJu-0001Pt-3R for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 17:45:02 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i51HgfkZ012917 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 13:42:41 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i51Hg84A015448 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 13:42:09 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: protocol-06 section 4.5 Date: Tue, 1 Jun 2004 13:42:08 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGKEFECKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200406011037.59743.davidb@verisignlabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If memory serves me right... The concern was having over-eager caching servers generate new responses from stored NSEC RRs. In some cases, the queried name, type may have been updated, and the NSEC no longer valid. For example: query for b.foo.com get: a.foo.com NSEC c.foo.com CNAME then someone queries for <a.foo.com IN A> and gets back the same cached NSEC RR (that shows a.foo.com doesn't have an A RR associated with it). In this case it is correct, but in some cases, the NSEC RR for a.foo.com may be out of date. Caching servers also now know a wildcard RR when they see it, so they may also be tempted to generate positive wildcard responses from cached RRs. It might be able to be re-written as: "caching security aware name serves MUST NOT use cached NSEC RRs to generate negative responses for queries unless those queries matched previous queries. Also, caching server MUST NOT generate their own positive wildcard matches using previously cached wildcard RRs. That text might be more confusing though. It would need to be made very clear (more clear than above). Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka > Sent: Tuesday, June 01, 2004 10:38 AM > To: namedroppers@ops.ietf.org > Subject: protocol-06 section 4.5 > > > I (still) have a problem with section 4.5 of > draft-ietf-dnsext-dnssec-protocol-06. > > Here is the text of that section: > > A security-aware resolver SHOULD cache each response as a single > atomic entry containing the entire answer, including the named > RRset and any associated DNSSEC RRs. The resolver SHOULD discard > the entire atomic entry when any of the RRs contained in it expire. > In most cases the appropriate cache index for the atomic entry will > be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the > response form described in Section 3.1.3.2 the appropriate cache > index will be the double <QNAME,QCLASS>. > > > My first issue of this is that there is no "WHY" expressed here. > Given that this is a SHOULD, how is an implementer to know whether or > not to follow this method? > > Second, this is essentially *implementation* advice, not a protocol > advisement. Further, it is advising a caching strategy that, AFAIK, > the DNS community doesn't have much experience with. Of course, I > personally have a hard time seeing how this method would cause > problems (other than lack of efficiency), but without experience, it > is hard to say. > > Third, this section, since it says what resolvers SHOULD do, rather > than what they MUST NOT do, it stifles resolver innovation. > > Fourth, it looks like a significantly less efficient caching strategy. > Here are some scenarios where a RRset level cache would be able to > respond out of cache, but a resolver using this strategy wouldn't: > > When a subsequent query is for something returned in the authority > section of a previous response, like: > > Q1: www.example.com IN A > R1: ANS: www.example.com IN A 1.2.3.4 > AUTH example.com NS ns1.example.com > example.com NS ns.example.net > ADD: ns1.example.com IN A 1.2.3.5 > > Q2: example.com IN NS > > > Q1: does-not-exist.example.com IN A > R1: AUTH: example.com. SOA .... > > Q2: example.com IN SOA > > > And perhaps more damaging, when a query for an internally followed > CNAME is followed by a query for what the CNAME resolved to: > > Q1: cname.example.com IN A > R1: ANS: cname.example.com IN CNAME www.example.com > www.example.com IN A 1.2.3.4. > AUTH: example.com NS ... > etc. > > Q2: www.example.com. IN A > > There are probably more examples where this proposed caching strategy > results in a cache miss, where a per RRset cache would result in a > cache hit. > > > Am I the only one who cares about this? Are resolver authors just > going to ignore this section? Does BIND 9.3.x follow this section (I > don't think so, but I could be wrong)? > > I would have written new language for this section myself if I > understood what problem it was trying to solve. I've looked through > namedroppers archives and failed to find the genesis of this language > (I'm not saying it is definitely not there, but I couldn't find it). > > If we, as a WG, can figure out what the problem is, we can write a > section that talks about what resolvers MUST NOT do. If we cannot, we > should just drop the whole section. > > > -- > 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 14:15:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03905 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 14:15:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVDkP-0007TQ-KH for namedroppers-data@psg.com; Tue, 01 Jun 2004 18:12:25 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVDkO-0007T4-He for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 18:12:24 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B828719B5CA; Tue, 1 Jun 2004 14:06:49 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 421C819B5C3; Tue, 1 Jun 2004 14:06:49 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1716647; Tue, 01 Jun 2004 14:12:23 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020415bce2709f86b0@[192.168.1.100]> In-Reply-To: <40BC5BCC.4040500@algroup.co.uk> References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> <40BC5BCC.4040500@algroup.co.uk> Date: Tue, 1 Jun 2004 13:44:42 -0400 To: Ben Laurie <ben@algroup.co.uk> From: Edward Lewis <edlewis@arin.net> Subject: Re: Proposal to fix NSEC Cc: edlewis@arin.net, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:34 +0100 6/1/04, Ben Laurie wrote: >If this causes bad things to happen, then DNSSECbis is already broken, since >an attacker can clearly cause NSEC records to be corrupt. In what way (corrupt)? NSEC records are signed, I think. A wrong NSEC (not-germane, I used to say) may be inserted, but the verifier ought to toss it before waiting for the real one. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Jun 1 14:15:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03923 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 14:15:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVDkR-0007UC-W3 for namedroppers-data@psg.com; Tue, 01 Jun 2004 18:12:27 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVDkQ-0007Ta-FD for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 18:12:26 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id EEB4219B5CA; Tue, 1 Jun 2004 14:06:51 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 438AB19B5D2; Tue, 1 Jun 2004 14:06:51 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1716648; Tue, 01 Jun 2004 14:12:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020414bce26b494693@[192.168.1.100]> In-Reply-To: <20040601162708.373BFE7EC3@mx1.nominet.org.uk> References: <20040601162708.373BFE7EC3@mx1.nominet.org.uk> Date: Tue, 1 Jun 2004 14:12:15 -0400 To: geoff@nominet.org.uk (Geoffrey Sisson) From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:27 +0100 6/1/04, Geoffrey Sisson wrote: >NSEC2 hashes are generated when the zone is signed, so this shouldn't >impose any load which NSEC doesn't already? Not quite. When I ask for 1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net, the server will only have pre-generated the hash for net. and not for anything else (that doesn't exist). The client and server will need to communicate over the fact that there is no hash name for 1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net and 2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net and 3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net and ... and 9.9.net and 9.net and net - exists and finally *.net Now wait a minute. I need think about this a bit differently. The server knows up front that 9.net doesn't exist - it doesn't need to "search" for that. So what happens if the server just says 9.net does not exist? If the server can say this outright, then the client can conclude anything below 9.net is also "not explicitly there." Does it matter that the same NSEC2 can be used for 9.net and a longer name? I don't think so. I suppose the needed parts of the answer are 1) that 9.net doesn't exist, 2) that net. does exist, and 3) that *.net doesn't exist. If that's the case, then there isn't a linear growth of calculations and response records. If this is right, then we are pushing the computing power back on the client. The client may still need to compute all of the hashes. If I show a return of <hash1> NSEC2 <hash2> (as the non-existent name closer than the CE) <hash3> NSEC2 <hash4> (as the CE=closest enclosure being there) <hash5> NSEC2 <hash6> (as the *.CE) The client isn't sure whether hash1 is the hash of the queried name or one far shorter. But that's good, keeping the computing off the server. I think that I've been overstating the cost...NSEC2 is more "expensive" than NSEC, but only by a fixed amount (the extra record). However - is it ambiguous? What are the chances that the sequence of hashs of the sequence of subsequently shorter name having a repeat of a triple? I.e., what if the hashes of the above are: 1,2,3,45,67,43,32,1,2,3,33,77,99,... can the client be confused? In a bad way? I don't think an interloper could devastatingly confuse the client here - the client will know that it needs to see proof of one name, proof of non-existence of a direct descendent, and then proof of the missing wild card. Without the private key, an interloper couldn't generate the RRSIGs on the records. PS I through out an unrelated question earlier today that is related to this. I'd also have to prove, if *.net exists, that nothing.*.net exists. That would be a pain. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Jun 1 15:20:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12001 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 15:20:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVEjK-000I54-Ip for namedroppers-data@psg.com; Tue, 01 Jun 2004 19:15:22 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVEjJ-000I4G-3c for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 19:15:21 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0615642B2 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 15:15:20 -0400 (EDT) Date: Tue, 01 Jun 2004 15:15:19 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents In-Reply-To: <20040518084824.4181bd4d.olaf@ripe.net> References: <20040518084824.4181bd4d.olaf@ripe.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040601191520.0615642B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Having attempted to keep an open mind while all the interesting NSEC2 (etc) debate has raged, I will nonetheless note that today is the last day of the WGLC, so here's my opinion, for whatever it's worth: Summary: Ship it. Disclaimers: I'm one of the DNSSECbis editors, so I have to recuse on whether the current documents adaquately express the current protocol. Due to my day job, I also have some interest in getting BIND 9.3.0 out the door, and thus find last minute proposals for semantic changes somewhat disturbing, particularly given that the January 2004 WGLC concluded that the protocol semantics were cooked and that it was just the documents expressing those protocol semantics that still needed work. None of this is the WG's problem, just bias disclosure. Rationale for why I think we should ship DNSSECbis as it stands: - I believe that the protocol is reasonable as an attempt to address the stated design goals (see draft-ietf-dnsext-dns-threats-07 and the earlier source material it references). - I, personally, wearing my just-another-bozo-on-this-bus hat, do not believe that the NSEC enumeration threat is worth further delay at this point, for two reasons: avoiding it wasn't a design goal, and I, personally, don't believe that the information leak in question can really be controlled in any case, given the combination of dictionary attacks, address walking, web crawling, and so forth. - I do understand that some view zone walking as a serious problem, and would not be adverse to further work that attempts to find a way to avoid it, but will note that this would be design goal change and might have nontrivial implications that we don't yet understand. - Part of my reason for wanting to ship now is that I have learned, the hard way, that DNSSEC is (necessarily, due to backward compatability issues) a very complex beast whose semantics we aren't smart enough to change quickly (at least, I know that -I'm- not that smart -- whether others here really are that smart or are just kidding themselves is a personal matter between any such people and their respective rabbis, none of my business). - As one of the people who was originally muttering about perhaps adding a version number in the NSEC RR, I should state that over the weekend I came to the same conclusion as Paul Vixie did, namely, that another typecode roll would probably be the best way to handle an incompatable change (whether to NSEC2 or to something else). - To the extent that DNSSECbis as currently specified might be useful to anybody, it would be a disservice to those users to delay it (yet again) while we hack new semantics. - At the end of the day, I'm left asking myself a simple question: is DNSSECbis cooked enough that it's better than what the users have now? I think that it is, so I think we should ship it. Finally, a recommendation: If I were on the IESG and I were to receive a request for advancement of the DNSSECbis docs, I would find it very helpful to receive, as part of the write-up, several paragraphs explaining the discussion which the WG has already had on this topic, since otherwise I would feel duty-bound to ask the WG about it. This is a sufficiently complex topic and has gone on at sufficient length that it would not be reasonable to expect the entire IESG to follow the debate (not if we also expect them to get anything else done, anyway). So we need to help. That's our chairs' job, but they may need our help, in which case I expect that they will ask us for 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 Tue Jun 1 15:34:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15459 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 15:34:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVEy9-000L3p-6p for namedroppers-data@psg.com; Tue, 01 Jun 2004 19:30:41 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVEy8-000L38-83 for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 19:30:40 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B380619B480; Tue, 1 Jun 2004 15:25:04 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3106819B480; Tue, 1 Jun 2004 15:25:04 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1716952; Tue, 01 Jun 2004 15:30:39 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602041cbce288fe1fa3@[192.168.1.100]> In-Reply-To: <20040601191520.0615642B2@thrintun.hactrn.net> References: <20040518084824.4181bd4d.olaf@ripe.net> <20040601191520.0615642B2@thrintun.hactrn.net> Date: Tue, 1 Jun 2004 15:30:43 -0400 To: Rob Austein <sra@isc.org> From: Edward Lewis <edlewis@arin.net> Subject: Re: WG Last Call: DNSSEC bis documents Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:15 -0400 6/1/04, Rob Austein wrote: >- Part of my reason for wanting to ship now is that I have learned, > the hard way, that DNSSEC is (necessarily, due to backward > compatability issues) a very complex beast whose semantics we aren't > smart enough to change quickly (at least, I know that -I'm- not that > smart -- whether others here really are that smart or are just > kidding themselves is a personal matter between any such people and > their respective rabbis, none of my business). To wit: after talking on the phone with someone about my earlier message on NSEC2 (not a linear growth, but a small constant bump), the question of all the new hash names was still there. I.e., do we have to provide auth denial for the names created as part of the hash? What if there's a name clash? Not to discuss that - but to illustrate - there's still a lot to consider. >- As one of the people who was originally muttering about perhaps > adding a version number in the NSEC RR, I should state that over the > weekend I came to the same conclusion as Paul Vixie did, namely, > that another typecode roll would probably be the best way to handle > an incompatable change (whether to NSEC2 or to something else). Again - there's a lot more needed on this. What is the impact on the design of the applications "above" DNS? I don't think we've adequately discussed and presented this to applications developers. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Jun 1 15:39:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16426 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 15:39:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVF3t-000MBy-6U for namedroppers-data@psg.com; Tue, 01 Jun 2004 19:36:37 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVF3s-000MBa-7B for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 19:36:36 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A323219B602; Tue, 1 Jun 2004 15:31:00 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id F083119B5F3; Tue, 1 Jun 2004 15:30:59 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1717005; Tue, 01 Jun 2004 15:36:35 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602041dbce28a105ffa@[192.168.1.100]> In-Reply-To: <ANECIHCPCBDLLEJLCOPGKEFBCKAA.scottr@nist.gov> References: <ANECIHCPCBDLLEJLCOPGKEFBCKAA.scottr@nist.gov> Date: Tue, 1 Jun 2004 15:35:34 -0400 To: "Scott Rose" <scottr@nist.gov> From: Edward Lewis <edlewis@arin.net> Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Cc: <namedroppers@ops.ietf.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:40 -0400 6/1/04, Scott Rose wrote: >The server needs to generate a hash of the queried name (and to find the >closest encloser) to find which NSEC2 RR's to include in the response. You might note that Ed's often a bozo and it'd be wise for all folks to check his work at all times. >That's where the client dictates the work to the server, and the point Ed >brought up. I wonder if something like the EXIST RR can shorten this work. >Just brainstorming, since I have no clue right now. Actually, the server needs to find the closest encloser via normal matching, then compute on-the-fly the hash of the CE name plus one label of the query name. For a name error response (NXDOMAIN), the server could either compute the wild card hash or pre-compute them all on load/dynamic update. So, a server could cut this down to the one on-the-fly hash. But then again - I still may be wrong... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Jun 1 15:45:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17451 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 15:45:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVF8x-000Mof-Vm for namedroppers-data@psg.com; Tue, 01 Jun 2004 19:41:51 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVF8w-000MoF-Ni for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 19:41:50 +0000 Received: from fury.blacka.com ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 01 Jun 2004 15:41:48 -0400 id 0006275A.40BCDBFC.00002455 From: David Blacka <davidb@verisignlabs.com> To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 Date: Tue, 1 Jun 2004 15:41:48 -0400 User-Agent: KMail/1.6.1 References: <ANECIHCPCBDLLEJLCOPGKEFECKAA.scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGKEFECKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Disposition: inline Organization: Verisign, Inc. Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406011541.48897.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 01 June 2004 1:42 pm, Scott Rose wrote: > If memory serves me right... > > The concern was having over-eager caching servers generate new responses > from stored NSEC RRs. In some cases, the queried name, type may have been > updated, and the NSEC no longer valid. For example: > > query for b.foo.com get: > a.foo.com NSEC c.foo.com CNAME > > then someone queries for <a.foo.com IN A> and gets back the same cached > NSEC RR (that shows a.foo.com doesn't have an A RR associated with it). In > this case it is correct, but in some cases, the NSEC RR for a.foo.com may > be out of date. Caching servers also now know a wildcard RR when they see > it, so they may also be tempted to generate positive wildcard responses > from cached RRs. I have a hard time seeing what you are describing as a serious problem. I'm not saying that I believe that there isn't a serious problem here, but that I don't think that we have described it yet. Right now (ignoring caches doing wildcard synthesis for the moment), what you've described is a cache that is, essentially, doing preemptive negative caching. Unless the NSEC record is actually lying to you, the only problem I see for this is that, after a zone change, downstream clients will not see the zone change (assuming an RRset was added, not removed) for the duration of the NSEC TTL. > It might be able to be re-written as: > > "caching security aware name serves MUST NOT use cached NSEC RRs to > generate negative responses for queries unless those queries matched > previous queries. Also, caching server MUST NOT generate their own > positive wildcard matches using previously cached wildcard RRs. > > That text might be more confusing though. It would need to be made very > clear (more clear than above). This is sort of language I would like to see for section 4.5. However, I think we need to justify it. -- 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 Tue Jun 1 16:05:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20785 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 16:05:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVFS3-000Pzp-4Y for namedroppers-data@psg.com; Tue, 01 Jun 2004 20:01:35 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVFS1-000PzZ-Ue for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 20:01:34 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5B6E142B2 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 16:01:33 -0400 (EDT) Date: Tue, 01 Jun 2004 16:01:33 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: TCR (was: Re: WG Last Call: DNSSEC bis documents) In-Reply-To: <a0602041cbce288fe1fa3@[192.168.1.100]> References: <20040518084824.4181bd4d.olaf@ripe.net> <20040601191520.0615642B2@thrintun.hactrn.net> <a0602041cbce288fe1fa3@192.168.1.100> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040601200133.5B6E142B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 1 Jun 2004 15:30:43 -0400, Ed Lewis wrote: > At 15:15 -0400 6/1/04, Rob Austein wrote: > > >- As one of the people who was originally muttering about perhaps > > adding a version number in the NSEC RR, I should state that over the > > weekend I came to the same conclusion as Paul Vixie did, namely, > > that another typecode roll would probably be the best way to handle > > an incompatable change (whether to NSEC2 or to something else). > > Again - there's a lot more needed on this. What is the impact on the > design of the applications "above" DNS? I don't think we've > adequately discussed and presented this to applications developers. I'm reasonably confident that a complete type code roll would simply revert any DNSSECbis-using applications back into the universe we have today in a relatively clean way. A partial type code roll might be more, um, "interesting". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 18:35:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02184 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 18:35:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVHmT-0002P5-0x for namedroppers-data@psg.com; Tue, 01 Jun 2004 22:30:49 +0000 Received: from [192.71.80.105] (helo=defiant.autonomica.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVHmR-0002Op-Eg for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 22:30:47 +0000 Received: from oban.autonomica.net (h187n2fls315o871.telia.com [217.209.95.187]) by defiant.autonomica.se (Postfix) with ESMTP id E9E9D121283; Wed, 2 Jun 2004 00:30:44 +0200 (CEST) Received: by oban.autonomica.net (Postfix, from userid 1211) id BE9E0E4D0D; Wed, 2 Jun 2004 00:30:44 +0200 (CEST) To: Stephane Bortzmeyer <bortzmeyer@nic.fr> Cc: Jaap Akkerhuis <jaap@sidn.nl>, IETF DNSEXT WG <namedroppers@ops.ietf.org>, Jakob Schlyter <jakob@rfc.se>, Per-Olof Josefsson <Per-Olof.Josefsson@nic.se> Subject: Re: NIC-SE statement regarding NSEC zone walking References: <Pine.OSX.4.60.0405261650410.23259@criollo.schlyter.se> <200405271139.i4RBdPQF063545@bartok.sidn.nl> <20040528113354.GA9316@nic.fr> From: Johan Ihren <johani@autonomica.se> Date: Wed, 02 Jun 2004 00:30:44 +0200 In-Reply-To: <20040528113354.GA9316@nic.fr> (Stephane Bortzmeyer's message of "Fri, 28 May 2004 13:33:54 +0200") Message-ID: <2cy8n6nc6j.fsf@oban.autonomica.net> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.5 (brussels sprouts, darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Stephane Bortzmeyer <bortzmeyer@nic.fr> writes: >> 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? Not speaking for either TLD in any way my guess would be that they consider the DNSSEC advantages outweighing the disadvantages. I.e. if they easily and to zero cost can prevent zone transfers (by disallowing AXFR) they'll do it, but they're not willing to pay the percieved higher price of not doing DNSSEC to achive that limited effect. And, in the end, that has to be the sort of justification that every single zone has to make for themselves. I think it would be naïve to assume that DNSSEC will be the right answer for everyone. For some zones the key management will be considered too expensive, for others it will not. For some zones (clearly) zone walking is percieved to be a showstopper, for others it is not. For some zones the increased child-parent interaction will be a major problem, for some it's worth it. Etc. Etc. The DNSSEC design will cater to this (more or less), although I'd be the first to admit the importance of having as many TLDs as possible "on board". But I do not think it is realistic to assume, or even hope for, participation by every TLD on the Internet. Some TLDs will decide not to do DNSSEC regardless of any new rounds of protocol work. So the question is more one of "who" rather than "if". Johan Ihrén Autonomica -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 19:53:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08303 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 19:53:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVIzw-000HJ9-Mq for namedroppers-data@psg.com; Tue, 01 Jun 2004 23:48:48 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVIzv-000HI0-40 for namedroppers@ops.ietf.org; Tue, 01 Jun 2004 23:48:47 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id EB314E7ED5; Wed, 2 Jun 2004 00:48:45 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs In-Reply-To: <20040601191520.0615642B2@thrintun.hactrn.net> Message-Id: <20040601234845.EB314E7ED5@mx1.nominet.org.uk> Date: Wed, 2 Jun 2004 00:48:45 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein <sra@isc.org> writes: > I, personally, don't believe that the information leak in question > can really be controlled in any case, given the combination of > dictionary attacks, address walking, web crawling, and so forth. I hope that, if nothing else, one key point isn't entirely lost: my concerns about NSEC RRs are not limited to information leakage, but also to the potential resource implications of abuse. Do TLDs really want to have to provision substantial additional capacity just to serve the data mining "community"? As Jay mentioned, it's not inconceivable that were we to deploy DNSSECbis, well over half of all DNS queries might be associated with NSEC RR traversal activity. These of course needn't be explicit NSEC RR queries but could be fabricated queries for non-existant domains. [As an aside: this activity should be measurable if not preventable. Currently we see queries which result in NXDOMAIN responses at a rather steady rate of ~ 6% of total queries; the extent to which this proportion shifted with DNSSEC deployment could serve as a metric of NSEC RR abuse.] I believe that NSEC RR traversal will be *so* much more attractive than any other form of information gathering that it will become pervasive. It's lossless and simple. Implementation-based anti-abuse mechanisms may reduce the simplicity but will not, without dubious guile, reduce the losslessness. Tools will be designed which will take advantage of parallelism and a virtually inexhaustible supply of unsecured resolvers to accelerate traversal and evade anti-abuse strategies. The only way I see to mitigate this is to make the same information available via less expensive facilities, e.g. unrestricted FTP/HTTP access. This may be an option for some operators of nameservers with large zones but, unfortunately, it's not an option for us. This isn't to suggest that something like NSEC2 will be a magic bullet against abuse. Users would no doubt employ NSEC2 RR elaboration combined with cryptographic dictionary attacks to harvest data. But this is harder and lossier, and I believe will consequently prove to be much less attractive, especially in comparison to other data gathering techniques. Perhaps this all sounds overwrought or FUD-ish; however one of the depressing entertainments of working for a ccTLD registry has been observing the resourcefulness and tenacity of abusers, who, year after year, becomes progressively more sophisticated. I appreciate that this message comes late in the day. I regret that we've not shared our operational experiences prior to now. And it is no doubt extremely frustrating to those who have poured a lot of effort into DNSSEC and DNSSECbis to hear it only as the current drafts go to WGLC. > DNSSEC is (necessarily, due to backward > compatability issues) a very complex beast whose semantics we aren't > smart enough to change quickly Yes, I think we have no illusions about this . . . 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 Tue Jun 1 22:24:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15445 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 22:24:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVLLT-000IyO-64 for namedroppers-data@psg.com; Wed, 02 Jun 2004 02:19:11 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BVLLR-000IxZ-Dh for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 02:19:09 +0000 Received: (qmail 56862 invoked from network); 2 Jun 2004 02:28:11 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 2 Jun 2004 02:28:11 -0000 Message-ID: <40BD3A2F.9060201@necom830.hpcl.titech.ac.jp> Date: Wed, 02 Jun 2004 11:23:43 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> CC: namedroppers@ops.ietf.org Subject: Re: question about "what is a legal name?" References: <a06020404bce232666da4@[192.168.1.100]> In-Reply-To: <a06020404bce232666da4@[192.168.1.100]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > I've been saying that the name above is not legal, based on the words in > RFC 1034, section 4.3.3 that define wild cards. One answer I have > received is that the above name is not a wild card, hence the > restrictions that no "*" appear in the <domain> there is not valid. The text in 1034 allows for names like: _marid.*.foo.com but not *.*.foo.com nor _marid.*.*.foo.com See below on why the latter is illegal. > I think the intent in the specs is to not use *.foo.com. as a "wild > card". From the definition of a wild card as "*.<domain without *>", I > think the server ought not synthesize from that record. According to the explicit text of 1034, your guess is invalid. According to 1034; The contents of the wildcard RRs follows the usual rules and formats for RRs. the consequence of "_marid.*.foo.com" without explicit "*.foo.com" is that the node "*.foo.com" does exist with no data. NODATA will be answered to a query of "*.foo.com". As 1034 says: A * label appearing in a query name has no special effect, but can be used to test for wildcards in an authoritative zone; the implicit "*.foo.com" must be treated as wildcard with no data. Does the behaviour satisfy requirements of the person in the MARID WG? > what happens when some one adds, via dynamic update, the label > "_marid" below that domain? It has nothing to do with dynamic update. The result of dynamic update will be that such a node had existed from the beginning. 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 Tue Jun 1 22:52:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17715 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 22:52:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVLpH-000OqX-SG for namedroppers-data@psg.com; Wed, 02 Jun 2004 02:49:59 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVLpG-000OqJ-Qk for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 02:49:58 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id D1A8B19B663; Tue, 1 Jun 2004 22:44:17 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 57EBF19B623; Tue, 1 Jun 2004 22:44:17 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1718719; Tue, 01 Jun 2004 22:49:57 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020400bce2ef2cd8b4@[192.168.1.100]> In-Reply-To: <40BD3A2F.9060201@necom830.hpcl.titech.ac.jp> References: <a06020404bce232666da4@[192.168.1.100]> <40BD3A2F.9060201@necom830.hpcl.titech.ac.jp> Date: Tue, 1 Jun 2004 22:49:52 -0400 To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> From: Edward Lewis <edlewis@arin.net> Subject: Re: question about "what is a legal name?" Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:23 +0900 6/2/04, Masataka Ohta wrote: >The text in 1034 allows for names like: > _marid.*.foo.com >but not > *.*.foo.com >nor > _marid.*.*.foo.com > >See below on why the latter is illegal. > I missed why the latter is illegal, given that the first is okay. Do you mean that there can be only one "*" in a name? And that only if it is the least significant label does the name cause synthesis? >According to 1034; > > The contents of the wildcard RRs follows the usual rules and formats for > RRs. > >the consequence of "_marid.*.foo.com" without explicit >"*.foo.com" is that the node "*.foo.com" does exist with >no data. NODATA will be answered to a query of "*.foo.com". What if there is data at *.foo.com.? Is _marid.*.foo.com still legal? E.g.: *.foo.com. MX 10 host1.foo.com. _marid.*.foo.com. TXT "something important" >As 1034 says: > > A * label appearing in a query name has no special effect, but can be > used to test for wildcards in an authoritative zone; > >the implicit "*.foo.com" must be treated as wildcard with no data. > >Does the behaviour satisfy requirements of the person in the MARID WG? Dunno... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Tue Jun 1 23:06:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18840 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 23:06:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVM2T-0001aL-Pi for namedroppers-data@psg.com; Wed, 02 Jun 2004 03:03:37 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVM2R-0001Zt-Gn for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 03:03:35 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id i5233Y0Y006859 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 23:03:34 -0400 (EDT) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAA4yaqzn; Tue, 1 Jun 04 23:03:34 -0400 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2004060123033313067 for <namedroppers@ops.ietf.org>; Tue, 01 Jun 2004 23:03:33 -0400 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004060123033429120 for <namedroppers@ops.ietf.org>; Tue, 01 Jun 2004 23:03:34 -0400 Received: from shsecpr1-ce0.shdc.chrysler.com (shsecpr1-ce0.shdc.chrysler.com [53.231.128.176]) by odmrspr2-hme0.oddc.chrysler.com (8.12.10/8.12.10/daimlerchrysler-relay-1.1-kcd) with SMTP id i5233RfU020746 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 23:03:34 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.102.252]) by shsecpr1-ce0.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004060123033304643 for <namedroppers@ops.ietf.org>; Tue, 01 Jun 2004 23:03:33 -0400 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id i5233RJh022826 for <namedroppers@ops.ietf.org>; Tue, 1 Jun 2004 23:03:27 -0400 (EDT) Message-ID: <40BD437F.9070903@daimlerchrysler.com> Date: Tue, 01 Jun 2004 23:03:27 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: question about "what is a legal name?" References: <a06020404bce232666da4@[192.168.1.100]> <40BD3A2F.9060201@necom830.hpcl.titech.ac.jp> <a06020400bce2ef2cd8b4@[192.168.1.100]> In-Reply-To: <a06020400bce2ef2cd8b4@[192.168.1.100]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 11:23 +0900 6/2/04, Masataka Ohta wrote: > >> The text in 1034 allows for names like: >> _marid.*.foo.com >> but not >> *.*.foo.com >> nor >> _marid.*.*.foo.com >> >> See below on why the latter is illegal. >> > > I missed why the latter is illegal, given that the first is okay. > > Do you mean that there can be only one "*" in a name? And that only if > it is the least significant label does the name cause synthesis? > >> According to 1034; >> >> The contents of the wildcard RRs follows the usual rules and formats for >> RRs. >> >> the consequence of "_marid.*.foo.com" without explicit >> "*.foo.com" is that the node "*.foo.com" does exist with >> no data. NODATA will be answered to a query of "*.foo.com". > > > What if there is data at *.foo.com.? Is _marid.*.foo.com still legal? > > E.g.: > > *.foo.com. MX 10 host1.foo.com. > _marid.*.foo.com. TXT "something important" I would think so. The existence of the _marid child should have no effect on the functioning of *.foo.com as a "default match", whether that match results in a wildcard synthesis, if one or more appropriate RRsets is present, or, if not present, just an early termination of the algorithm with a NODATA response. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 1 23:30:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19862 for <dnsext-archive@lists.ietf.org>; Tue, 1 Jun 2004 23:30:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVMNT-0005aF-9x for namedroppers-data@psg.com; Wed, 02 Jun 2004 03:25:19 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVMNR-0005Zi-JC for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 03:25:17 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id PAA01360 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 15:25:16 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i523PGfw005943 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 15:25:16 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) From: Don Stokes <don@plugh.daedalus.co.nz> To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Your message of "Tue, 01 Jun 2004 11:42:18 +0100." <40BC5D8A.1050709@algroup.co.uk> Date: Wed, 02 Jun 2004 15:25:16 +1200 Message-ID: <5942.1086146716@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> wrote: >Alex Bligh wrote: >> 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). Secure delegation doesn't work securely without NSEC, as referral NS records are not signed. Any man in the middle can respond with an unauthenticated NS RRset, and if you're expecting a signed response, you have to have either a signed DS record or a signed NSEC record before you can follow the delegation. Otherwise you might be following a forged referral. Thus, authenticated denial is required for secure delegation. One should always return an NSEC record in any case where one would return NODATA in standard DNS. A completely different question is whether one can get away with not returning NSEC where standard DNS would return NXDOMAIN, and I think that's the question that Alex is asking. >For example, returning NXDOMAIN instead of an A or MX record for a >domain name used for email causes all your email to get dropped instead >of queued. This strikes me as bad. If we're only talking about lacking authenticated denial for records that do not exist, i.e. cases where you'd get NXDOMAIN rather than NODATA, then we're not talking about returning NXDOMAIN instead of A or MX. Getting an NSEC record tells me that a domain definitely doesn't exist (and I can bounce email to it, or whatever). If I don't get either signed data or an NSEC, I don't know for sure, and I have to retry; so you're talking about mail (that isn't going to be delivered anyway) getting re-queued instead of bounced. That might be a problem for some; certainly I've frequently mis-typed an email address and not been informed of the message's non-delivery until much later. I can imagine mail queues filling with undelivered spam because a DNSSECbis speaking mail server can't get a definitive yay or nay out of the DNS though. -- 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 Wed Jun 2 00:02:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21804 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 00:02:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVMsu-000C2l-U6 for namedroppers-data@psg.com; Wed, 02 Jun 2004 03:57:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BVMst-000C2M-Qq for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 03:57:47 +0000 Received: (qmail 57506 invoked from network); 2 Jun 2004 04:06:51 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 2 Jun 2004 04:06:51 -0000 Message-ID: <40BD514E.1050104@necom830.hpcl.titech.ac.jp> Date: Wed, 02 Jun 2004 13:02:22 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> CC: namedroppers@ops.ietf.org Subject: Re: question about "what is a legal name?" References: <a06020404bce232666da4@[192.168.1.100]> <40BD3A2F.9060201@necom830.hpcl.titech.ac.jp> <a06020400bce2ef2cd8b4@[192.168.1.100]> In-Reply-To: <a06020400bce2ef2cd8b4@[192.168.1.100]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: >> The text in 1034 allows for names like: >> _marid.*.foo.com >> but not >> *.*.foo.com >> nor >> _marid.*.*.foo.com >> >> See below on why the latter is illegal. >> > > I missed why the latter is illegal, given that the first is okay. I mean "_marid.*.*.foo.com" implies "*.*.foo.com" exist (with no data), which is illegal. > Do you mean that there can be only one "*" in a name? And that only if > it is the least significant label does the name cause synthesis? Yes. > What if there is data at *.foo.com.? Is _marid.*.foo.com still legal? Yes. 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 Wed Jun 2 02:35:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01710 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 02:35:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVPI0-00089F-GZ for namedroppers-data@psg.com; Wed, 02 Jun 2004 06:31:52 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVPHz-000891-If for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 06:31:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E197A13960 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 06:31:50 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Wed, 02 Jun 2004 00:48:45 +0100." <20040601234845.EB314E7ED5@mx1.nominet.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 02 Jun 2004 06:31:50 +0000 Message-Id: <20040602063150.E197A13960@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > I believe that NSEC RR traversal will be *so* much more attractive than > any other form of information gathering that it will become pervasive. I agree. Unless the servers also offer the zone by FTP and AXFR, that is. (Ooops, I think my skirt is showing.) > It's lossless and simple. It's not lossless. If a zone changes during an AXFR, then either the AXFR is TCP-RST'd (BIND4, BIND8, most nonBINDs) or it continues but using the old zone contents (BIND9), but if a zone changes during an NSEC traversal, there will almost certainly be some data loss due to the rewritten NSEC chain. > ... > The only way I see to mitigate this is to make the same information > available via less expensive facilities, e.g. unrestricted FTP/HTTP > access. This may be an option for some operators of nameservers with > large zones but, unfortunately, it's not an option for us. Your position is quite well understood. For the record, did anyone from Nominet comment during the January WGLC on the design goals of DNSSEC-BIS? > ... > I appreciate that this message comes late in the day. I regret that > we've not shared our operational experiences prior to now. And it is > no doubt extremely frustrating to those who have poured a lot of effort > into DNSSEC and DNSSECbis to hear it only as the current drafts go to > WGLC. For my part, it's not frustration but rather sadness. DNSSEC-BIS will be deployed, and some parts of the DNS tree won't benefit from it, and that's how it has to be, but I don't have to like it and in fact I don't like it. Onward to DNSSEC-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 Wed Jun 2 02:48:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02751 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 02:48:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVPTo-0009if-IP for namedroppers-data@psg.com; Wed, 02 Jun 2004 06:44:04 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1BVPTn-0009iN-ER for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 06:44:03 +0000 Received: (qmail 58311 invoked from network); 2 Jun 2004 06:53:08 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 2 Jun 2004 06:53:08 -0000 Message-ID: <40BD7844.7080209@necom830.hpcl.titech.ac.jp> Date: Wed, 02 Jun 2004 15:48:36 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs References: <20040602063150.E197A13960@sa.vix.com> In-Reply-To: <20040602063150.E197A13960@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>It's lossless and simple. > It's not lossless. If a zone changes during an AXFR, then either the AXFR > is TCP-RST'd (BIND4, BIND8, most nonBINDs) or it continues but using the old > zone contents (BIND9), but if a zone changes during an NSEC traversal, there > will almost certainly be some data loss due to the rewritten NSEC chain. If you are saying AXFR not with BIND9 is lossless, if you frequently check SOA during the traverse, you can simulate TCP-RST. Throw away data after the last unmodified serial. 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 Wed Jun 2 03:14:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04258 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 03:14:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVPrw-000DpW-Pc for namedroppers-data@psg.com; Wed, 02 Jun 2004 07:09:00 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVPrv-000DpH-OO for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 07:08:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0F50913951 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 07:08:59 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: HEREIS "draft-vixie-dnssec-ter-00.txt" X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 02 Jun 2004 07:08:59 +0000 Message-Id: <20040602070859.0F50913951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSEXT Working Group Paul Vixie INTERNET-DRAFT ISC <draft-vixie-dnssec-ter-00.txt> June 2004 Extending DNSSEC-BIS (DNSSEC-TER) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As the DNSSEC-BIS document set goes to press, we find that the design goals for DNSSEC have shifted somewhat in the ten years of its preproduction. This memo lists some possible new directions for DNSSEC-TER, and also, some methods by which DNSSEC-TER could first coexist with, and possibly replace, DNSSEC-BIS. 1 - Rationale and Scope 1.1. DNSSEC-BIS, which took ten years to evolve, is widely considered to be a working solution for end to end DNS data authenticity. However, the threat model which drove the design of DNSSEC and DNSSEC-BIS fails to address issues of great interest to some members of the community, for example, domain name confidentiality. Expires December 2004 [Page 1] INTERNET-DRAFT DNSSEC-TER June 2004 1.2. Without proposing any specific new features, this memo will lay out an upgrade path whereby DNSSEC-TER could first coexist with, and then possibly replace DNSSEC-BIS, with no loss of functionality for DNSSEC- BIS adopters. The method used has been called a "type code roll" or TCR. 1.3. The goal of this memo is not to specify DNSSEC-TER itself, but rather, to describe the method by which it can be developed and deployed, compatibly with an existing DNSSEC-BIS installed base. 2 - New Signalling, New Metadata 2.1. Since DNSSEC-BIS already depends on EDNS due to message size increases, it is safe to depend on EDNS to carry a new DNSSEC-TER flag. The meaning of this flag would be, generally, "when I say I want DNSSEC metadata in the response to this query, I can handle, and prefer, DNSSEC-TER metadata." 2.2. DNSSEC-TER might define new metadata records (for example, DS2, NSEC2, RRSIG2, and/or DNSKEY2), but will not redefine the meaning or format of existing DNSSEC-BIS metadata records due to the risk of these records becoming separated from the DNSSEC-TER tag that tells how to interpret them. 2.3. EDNS is a hop by hop protocol, carrying meaning only between an initiator and a responder. A caching forwarder who can process both DNSSEC-TER and DNSSEC-BIS will "tag" its security metadata using the "DNSSEC-TER data is wanted" status of the query which causes that metadata to enter the cache. If cached data exists but was fetched without (or with) this tag, and a query arrives with (or without) the "DNSSEC-TER wanted" flag, then the new query will have to be forwarded upstream toward the authority servers, and the result (even if negative) will be cached and used separately. This behaviour has the effect of promoting the "DNSSEC-TER" wanted flag from hop-by-hop to end-to-end. 2.4. If an authority server or caching recursive server is asked for DNSSEC-TER metadata but only has DNSSEC-BIS metadata available, then DNSSEC-BIS data will be sent. Thus, a requestor who is capable of handling DNSSEC-TER metadata records should ask for DNSSEC-TER first, and then fall back to DNSSEC-BIS if necessary. This optimizes for the eventual case when the installed base of DNSSEC-BIS has completely upgraded to DNSSEC-TER. An initiator is not permitted to assume, from the lack of a DNSSEC-TER response, that either that server or that zone does not in general support DNSSEC-TER. Expires December 2004 [Page 2] INTERNET-DRAFT DNSSEC-TER June 2004 2.5. It is possible that DNSSEC-TER metadata could be synthesized using only DNSSEC-BIS metadata. For example, an NSEC2 RR which offers the benefit of domain name confidentiality might use name hashes rather than domain names to bracket a range of name nonexistence, and it might be possible to compute these hashes using an existing NSEC RR. Therefore, a DNSSEC-TER specification might permit caching forwarders to synthesize NSEC2 RRs using NSEC RRs, thus improving the number of round trips otherwise called for in section 2.3 above. 2.6. A zone signer and/or authority server might choose to support both DNSSEC-BIS and DNSSEC-TER, or only DNSSEC-BIS, or only DNSSEC-TER. It is expected that a validating recursive server, or a caching recursive server, will support either DNSSEC-BIS alone (as is the case today), or both DNSSEC-BIS and DNSSEC-TER, but never DNSSEC-TER alone. 3 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671, IETF DNSIND, September 1998 4 - Author's Address Paul Vixie Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 +1.650.423.1301 <vixie@isc.org> 3557*VIX Expires December 2004 [Page 3] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 03:55:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06071 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 03:55:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVQWm-000LPi-Ks for namedroppers-data@psg.com; Wed, 02 Jun 2004 07:51:12 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVQWl-000LPF-GW for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 07:51:11 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id D65A4E7E86; Wed, 2 Jun 2004 08:51:10 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs In-Reply-To: <20040602063150.E197A13960@sa.vix.com> Message-Id: <20040602075110.D65A4E7E86@mx1.nominet.org.uk> Date: Wed, 2 Jun 2004 08:51:10 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,NO_QS_ASKED autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> writes: > > It's lossless and simple. > > It's not lossless. If a zone changes during an AXFR, then either the AXFR > is TCP-RST'd (BIND4, BIND8, most nonBINDs) or it continues but using the old > zone contents (BIND9), but if a zone changes during an NSEC traversal, there > will almost certainly be some data loss due to the rewritten NSEC chain. True, "lossless" is technically inaccurate. "Practically lossless" (from the standpoint of a data miner, for whom other techniques may be at best somewhere on the order of 80% or 90% lossy) is more accurate. > > The only way I see to mitigate this is to make the same information > > available via less expensive facilities, e.g. unrestricted FTP/HTTP > > access. This may be an option for some operators of nameservers with > > large zones but, unfortunately, it's not an option for us. > > Your position is quite well understood. For the record, did anyone from > Nominet comment during the January WGLC on the design goals of DNSSEC-BIS? No, and for this I can only say "mea culpa". While we've been aware of the potential of NXT/NSEC abuse, it was only in the course of a recent painful legal action (involving WHOIS abuse, and still ongoing) that we fully connected the dots. > For my part, it's not frustration but rather sadness. DNSSEC-BIS will be > deployed, and some parts of the DNS tree won't benefit from it, and that's > how it has to be, but I don't have to like it and in fact I don't like it. I'm concerned that even the parts of the DNS tree who do deploy may face operational issues unless they give away the data in their zone files with no questions asked. Even a minor procedural obstacle, such as requiring a subscription to a service or formal request via a web form, may result in an abuser preferring the simplicity/anonymity of NSEC RR elaboration instead. I also may have under-represented the case of DNS end-users, for whom simple privacy is the principal concern. Even using split DNS, they may have information they'd prefer not to broadcast. 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 Wed Jun 2 04:27:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07541 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 04:27:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVR3E-00008g-Bj for namedroppers-data@psg.com; Wed, 02 Jun 2004 08:24:44 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVR3C-000080-Mm for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 08:24:42 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i528Odwh066613 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 10:24:39 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i528OcMC066612 for namedroppers@ops.ietf.org; Wed, 2 Jun 2004 10:24:38 +0200 (CEST) (envelope-from ted) Message-Id: <200406020824.i528OcMC066612@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 2 Jun 2004 10:24:38 +0200 In-Reply-To: "Geoffrey Sisson's message as of Jun 2, 1:59" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Geoffrey Sisson, on Jun 2, 1:59, in "Re: WGLC for DNSSECb ..."] ... > I hope that, if nothing else, one key point isn't entirely lost: my > concerns about NSEC RRs are not limited to information leakage, but > also to the potential resource implications of abuse. Do TLDs really > want to have to provision substantial additional capacity just to serve > the data mining "community"? As Jay mentioned, it's not inconceivable > that were we to deploy DNSSECbis, well over half of all DNS queries > might be associated with NSEC RR traversal activity. ... Please, let's stay to facts based on real measurements and don't get excited by FUD based on gross miscalculations. The message from Jay you are refering to contains at least 3 errors and should therefore not be taken seriously. I expected that this was immediately clear to everybody whois dealing with real-life root or TLD operations, but appearently the FUD did stick by some. [Quoting "Jay Daley", on May 31, 23:37, in "Re: Proposal to fix ..."] .... > 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 In short: "4 million records x 25 spammers" == 100 million queries per day hugely increases the load on the UK nameservers. Error 1: A load of 100 million queries per day is not something to get excited about. See the real measurements by CAIDA, RIPE, and NLnet Labs on root and TLD nameserver loads. For your information: with 500 Mhz Athlon or Pentium class systems (off the shelf PC's in 2000), both BIND-8 and BIND-9 can easily handle 6000 queries per second, with NSD this is some 30000. That amounts to 2592000000 per day, or 25 times your current query load,. Error 2: NSEC walking goes by domainname, not by record. There are multiple records per domainname, so here goes another factor. Error 3: To walk NSECs, one needs the answer on a previous query, before one can construct the next one. Depending on network, both nameserver and walking systems, and nameserver software implementation, there is a delay of several tens of milliseconds. Lets say 50, then, one walk can do at most 1728000 lookups per day. In conclusion: the load caused by zonewalkers can be neglected, even if hundreds of spammers are doing it simultaneously. -- 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 Wed Jun 2 04:38:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08119 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 04:38:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVREg-0001lM-6q for namedroppers-data@psg.com; Wed, 02 Jun 2004 08:36:34 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVREf-0001kl-3b for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 08:36:33 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i528aT1a066734; Wed, 2 Jun 2004 10:36:29 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i528aTB2066733; Wed, 2 Jun 2004 10:36:29 +0200 (CEST) (envelope-from ted) Message-Id: <200406020836.i528aTB2066733@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Wed, 2 Jun 2004 10:36:29 +0200 In-Reply-To: "Geoffrey Sisson's message as of Jun 2, 9:56" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: geoff@nominet.org.uk (Geoffrey Sisson), namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Geoffrey Sisson, on Jun 2, 9:56, in "Re: WGLC for DNSSECb ..."] > I also may have under-represented the case of DNS end-users, for whom > simple privacy is the principal concern. Even using split DNS, they > may have information they'd prefer not to broadcast. Really, this is plain nonsense! The purpose of DNS is to publish information. And split DNS is invented to differentiate between audiences. If an end-user does not want certain information to be published to certain audiences, this end-user should not put it in the public part of their split DNS system. -- 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 Wed Jun 2 06:00:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11704 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 06:00:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVSUj-000Dik-4u for namedroppers-data@psg.com; Wed, 02 Jun 2004 09:57:13 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVSUh-000DiD-B4 for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 09:57:11 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BVSUg-0007PQ-00 for <namedroppers@ops.ietf.org>; Wed, 02 Jun 2004 11:57:10 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Wed, 02 Jun 2004 11:57:10 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Wed, 02 Jun 2004 11:57:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: WGLC for DNSSECbis docs Date: Wed, 02 Jun 2004 11:57:03 +0200 Lines: 23 Message-ID: <ilupt8imgeo.fsf@latte.josefsson.org> References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:bWtL2j4JPE72siZRzSPOEC3uRTk= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ted@NLnetLabs.nl (Ted Lindgreen) writes: > Error 2: > NSEC walking goes by domainname, not by record. There are multiple > records per domainname, so here goes another factor. My tool iterate over each RRset. How would you get all records, otherwise? ANY queries aren't reliable, as far as I know. > Error 3: > To walk NSECs, one needs the answer on a previous query, before one > can construct the next one. Sorry, no, it is possible to parallelize it. Send 10^10 queries for uniformly distributed name/type/class, under the target zone, and piece together the replies. If by inspecting the NSEC chain, you realize you didn't get everything, get those specifically, possibly by querying for uniformly distributed name/type/class in the interesting area. Or just increase the initial amount to 10^11 queries for uniformly distributed name/type/class, until you do get everything. 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 Wed Jun 2 06:12:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12287 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 06:12:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVSgH-000FuF-Q1 for namedroppers-data@psg.com; Wed, 02 Jun 2004 10:09:09 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVSgG-000Fte-IM for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 10:09:08 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i52A94Cm067234 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 12:09:05 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52A90rb024943 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 12:09:00 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52A90Pm024940 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 12:09:00 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 2 Jun 2004 12:09:00 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: number games. Re: WGLC for DNSSECbis docs In-Reply-To: <200406020824.i528OcMC066612@open.nlnetlabs.nl> Message-ID: <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Don't fight FUD with FUD. Playing number games is not to be taken lightly. Ask your average Big Corp Accountant Fall Guy. (If you don't know who that is, you're probably the Fall Guy :). Below I've put some references together and my attempt to number games. My conclusion about this attempt is that load concerns definitly are valid. 1) Performance statistics on BIND and NSD: http://www.nlnetlabs.nl/nsd/presentations/ripe47/mgp00010.html It is hard to see from this statistic to see the qps for BIND9 at 99 or 100% response rate, but I guess around 4000 would be right. 2) Currently, co.uk resides on 9 nameservers, 7 of which are bind 9.2.3 (2 of which are UltraDNS Version 2.7.3.1 Build 989) 3) Nominet statistics, registrations under co.uk: http://www.nominet.org.uk/Statistics/RegistrationStatistics/ 5624944 registrations under co.uk on 31st of May this year, with an average growth of 80000 per month. 4) Proof of concept tool at: http://www.josefsson.org/walker/ Queries individual records PLUS the NSEC records. For a delegation only zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the apex). 5) Assuming that one can build a non-parallel, slow lookup thinghy that can do at most 1728000 queries a day, while a 500 Mhz Athlon or Pentium class system with off the shelf PCs in 2000, can serve 2592000000 queries is just naive. What this boils down to is, when I run 'walker', pointing at a single authoritative server on a currently signed co.uk: 11249891 queries. There is an average load on co.uk of 100.000.000 a day (according to Jay's mail), with the help of 10 script kiddies/spammers this would double the load. 200M queries a day may not shake an average TLD, but this exercise assumes just 10 kiddies or spammers are interested in the co.uk zone. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 06:20:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12582 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 06:20:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVSo1-000HoM-RU for namedroppers-data@psg.com; Wed, 02 Jun 2004 10:17:09 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVSo0-000Hnj-JB for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 10:17:08 +0000 Received: from wds1.nominet.org.uk (notes1.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 245BEE7F7F; Wed, 2 Jun 2004 11:17:06 +0100 (BST) In-Reply-To: <200406020824.i528OcMC066612@open.nlnetlabs.nl> To: ted@NLnetLabs.nl (Ted Lindgreen) Cc: gs@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: WGLC for DNSSECbis docs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: <OF7AFC4710.CF648ED0-ON80256EA7.00309D40-80256EA7.00355885@nominet.org.uk> From: "Jay Daley" <td@nominet.org.uk> Date: Wed, 2 Jun 2004 10:41:22 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 06/02/2004 11:17:05 AM, Serialize complete at 06/02/2004 11:17:05 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ted ted wrote on 02/06/2004 09:24:38: > The message from Jay you are refering to contains at least 3 errors > and should therefore not be taken seriously. > I expected that this was immediately clear to everybody whois dealing > with real-life root or TLD operations, but appearently the FUD did > stick by some. I think you have forgotten that we do run a TLD and therefore have considerable real-life experience. FUD is not the way we work and it is unfortunate that you see it that way. > Error 1: > A load of 100 million queries per day is not something to get excited > about. See the real measurements by CAIDA, RIPE, and NLnet Labs on root > and TLD nameserver loads. > For your information: > with 500 Mhz Athlon or Pentium class systems (off the shelf PC's > in 2000), both BIND-8 and BIND-9 can easily handle 6000 queries > per second, with NSD this is some 30000. > That amounts to 2592000000 per day, or 25 times your current > query load,. You are confusing capacity with load. My point is that it takes only a very small number of people to create a very large percentage increase in load. > Error 2: > NSEC walking goes by domainname, not by record. There are multiple > records per domainname, so here goes another factor. My terminology was imprecise - I meant 4 million domain names. > Error 3: > To walk NSECs, one needs the answer on a previous query, before one > can construct the next one. Depending on network, both nameserver > and walking systems, and nameserver software implementation, there > is a delay of several tens of milliseconds. > Lets say 50, then, one walk can do at most 1728000 lookups per day. To parallelise this is trivial, just start at different points in the alphabet, use multiple IP addresses and multiple servers. That has the added advantage of making it harder to detect. 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 Wed Jun 2 07:20:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15814 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 07:20:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVTjt-000102-IU for namedroppers-data@psg.com; Wed, 02 Jun 2004 11:16:57 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVTjs-0000zn-Im for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 11:16:56 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 1A3451FF84A; Wed, 2 Jun 2004 11:16:54 +0000 (GMT) Message-ID: <40BDB725.2030405@algroup.co.uk> Date: Wed, 02 Jun 2004 12:16:53 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> Cc: namedroppers@ops.ietf.org Subject: Re: Proposal to fix NSEC References: <200405311258.i4VCwJSh043071@open.nlnetlabs.nl> <40BC5BCC.4040500@algroup.co.uk> <a06020415bce2709f86b0@[192.168.1.100]> In-Reply-To: <a06020415bce2709f86b0@[192.168.1.100]> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 11:34 +0100 6/1/04, Ben Laurie wrote: > >> If this causes bad things to happen, then DNSSECbis is already broken, >> since >> an attacker can clearly cause NSEC records to be corrupt. > > > In what way (corrupt)? NSEC records are signed, I think. A wrong NSEC > (not-germane, I used to say) may be inserted, but the verifier ought to > toss it before waiting for the real one. Apologies, just got back from Toronto and jetlag has clearly fried my brain: you are correct. 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 Wed Jun 2 07:36:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16457 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 07:36:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVU07-0004sx-39 for namedroppers-data@psg.com; Wed, 02 Jun 2004 11:33:43 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVU05-0004sh-R8 for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 11:33:42 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id C2F3F1FF857; Wed, 2 Jun 2004 11:33:40 +0000 (GMT) Message-ID: <40BDBB13.4040403@algroup.co.uk> Date: Wed, 02 Jun 2004 12:33:39 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> Cc: Rob Austein <sra@isc.org>, namedroppers@ops.ietf.org Subject: Re: WG Last Call: DNSSEC bis documents References: <20040518084824.4181bd4d.olaf@ripe.net> <20040601191520.0615642B2@thrintun.hactrn.net> <a0602041cbce288fe1fa3@[192.168.1.100]> In-Reply-To: <a0602041cbce288fe1fa3@[192.168.1.100]> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 15:15 -0400 6/1/04, Rob Austein wrote: > >> - Part of my reason for wanting to ship now is that I have learned, >> the hard way, that DNSSEC is (necessarily, due to backward >> compatability issues) a very complex beast whose semantics we aren't >> smart enough to change quickly (at least, I know that -I'm- not that >> smart -- whether others here really are that smart or are just >> kidding themselves is a personal matter between any such people and >> their respective rabbis, none of my business). > > > To wit: after talking on the phone with someone about my earlier message > on NSEC2 (not a linear growth, but a small constant bump), the question > of all the new hash names was still there. I.e., do we have to provide > auth denial for the names created as part of the hash? What if there's > a name clash? My view would be that the names don't really exist, or can be considered to be in a different namespace. I don't know if there's some obscure reason that this is the wrong view to have, though. > Not to discuss that - but to illustrate - there's still a lot to consider. I guess we have to discuss it at some point! 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 Wed Jun 2 07:38:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16519 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 07:38:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVU1y-0005BZ-Tz for namedroppers-data@psg.com; Wed, 02 Jun 2004 11:35:38 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVU1x-0005Av-Ee for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 11:35:37 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 4E0691FF857; Wed, 2 Jun 2004 11:35:36 +0000 (GMT) Message-ID: <40BDBB87.5040403@algroup.co.uk> Date: Wed, 02 Jun 2004 12:35:35 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) References: <ANECIHCPCBDLLEJLCOPGKEFBCKAA.scottr@nist.gov> <a0602041dbce28a105ffa@[192.168.1.100]> In-Reply-To: <a0602041dbce28a105ffa@[192.168.1.100]> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 12:40 -0400 6/1/04, Scott Rose wrote: > >> The server needs to generate a hash of the queried name (and to find the >> closest encloser) to find which NSEC2 RR's to include in the response. > > > You might note that Ed's often a bozo and it'd be wise for all folks to > check his work at all times. > >> That's where the client dictates the work to the server, and the point Ed >> brought up. I wonder if something like the EXIST RR can shorten this >> work. >> Just brainstorming, since I have no clue right now. > > > Actually, the server needs to find the closest encloser via normal > matching, then compute on-the-fly the hash of the CE name plus one label > of the query name. For a name error response (NXDOMAIN), the server > could either compute the wild card hash or pre-compute them all on > load/dynamic update. So, a server could cut this down to the one > on-the-fly hash. > > But then again - I still may be wrong... I believe this is correct - the server only needs to compute the hash of the requested name. Whether precomputation is worth the effort depends on parameters. Don't forget that hashes are really very fast. 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 Wed Jun 2 07:42:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16658 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 07:42:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVU63-0005wD-Jm for namedroppers-data@psg.com; Wed, 02 Jun 2004 11:39:51 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVU62-0005vl-Kb for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 11:39:50 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 039051FF857; Wed, 2 Jun 2004 11:39:28 +0000 (GMT) Message-ID: <40BDBC70.90403@algroup.co.uk> Date: Wed, 02 Jun 2004 12:39:28 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: HEREIS "draft-vixie-dnssec-ter-00.txt" References: <20040602070859.0F50913951@sa.vix.com> In-Reply-To: <20040602070859.0F50913951@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > 2.5. It is possible that DNSSEC-TER metadata could be synthesized using > only DNSSEC-BIS metadata. For example, an NSEC2 RR which offers the > benefit of domain name confidentiality might use name hashes rather than > domain names to bracket a range of name nonexistence, and it might be > possible to compute these hashes using an existing NSEC RR. Therefore, > a DNSSEC-TER specification might permit caching forwarders to synthesize > NSEC2 RRs using NSEC RRs, thus improving the number of round trips > otherwise called for in section 2.3 above. I'd note that you'd need a complete copy of the zone to do 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 Wed Jun 2 07:55:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17126 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 07:55:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVUIq-0007lV-89 for namedroppers-data@psg.com; Wed, 02 Jun 2004 11:53:04 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVUIo-0007kY-Rx for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 11:53:03 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 22B584E4B0; Wed, 2 Jun 2004 13:53:02 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id AF4144E35E for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 13:53:01 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i52Br1Q2005938 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 13:53:01 +0200 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i52Br1Xa020427 for namedroppers@ops.ietf.org; Wed, 2 Jun 2004 13:53:01 +0200 Date: Wed, 2 Jun 2004 13:53:01 +0200 From: Olaf Kolkman <olaf@ripe.net> Message-Id: <200406021153.i52Br1Xa020427@cow.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSSECbis WGLC Conclusion X-RIPE-Spam-Status: N 0.000526 / 0.0 / 0.0 / disabled X-RIPE-Signature: 3fadac1be92a7c59f42d3de80a620f9e X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Colleagues, This message concludes the working group last call on 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 We have been taking into account the discussion that started with http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00435.html This note concludes the last call identifies open issues and sets a way forward. Except for the two open issues below we conclude that the WG consents on the DNSSEC bis documentation being complete and ready to be forwarded to the IESG for publication as proposed standard. Issues resolved. Resolved Issue 1: (initiated by: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00424.html) in 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. There is consensus on dropping the last sentence. Resolved Issue 2: (Initiated by: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00623.html ) 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" The proposed "MUST" language did not counter with objections and forces RR-sets and their signatures to expire from caches at the same time. Open Issue 1: See http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00785.html This issue was posted June 1 and needs a little time to be resolved. Please spend cycles on this issue over the next week. Open Issue 2: NSEC2/NO++. The working group consents on not including NSEC2 in DNSECbis. The working group considers to take up "prevention of zone enumeration" as a work item. (this may result in a solution other than NSEC2, we'll refer to this work as NSEC2/NO++). There is a proposal to use a type code roll with EDNS0 based signaling to introduce NSEC2/NO++. There may be other, more gentle, mechanisms to allow for co-existence with DNSSEC-bis. We allow the working group a little over a week (up to June 12) to come to consensus on a possible modification to the document to enable gentle rollover. If that consensus cannot be reached the document will go out as-is and type-code roll will probably be the only way forward. To ease the process of getting consensus we would like to ask for a few (3 or so) volunteers to make a summary of the proposed solutions and analyze the pros and cons during the weekend. If you want to volunteer please reply to both of us within 24 hours after posting of this mail so we can appoint the volunteers by Thursday and have results on Monday. We realize we are going fast but want to have DNSSEC-bis at the IESG before July 1. If you are reading the documents and find editorial nits or inconsistencies you should still bring them up. Either to dnssec-editors@east.isi.edu or to this list. Olaf & Olafur DNSEXT co-chairs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 08:16:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18573 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 08:16:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVUdJ-000Ded-0B for namedroppers-data@psg.com; Wed, 02 Jun 2004 12:14:13 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVUdH-000DeA-S1 for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 12:14:11 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i52CE1kZ009096 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 08:14:01 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i52CDe4A016230 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 08:13:41 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 08:13:41 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200406011541.48897.davidb@verisignlabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thinking about this some more, I think we can break things down into smaller, semi-related chunks. Some might be problems, some might be serious problems (I've come to recognize the difference :) 1. Caches generating negative responses using NSEC RRs recieved from unrelated queries. 2. Caches synthesizing positive wildcard responses from cached wildcard RRs. I think we agree that 2 is a bad thing, so there should be rule against caches doing that. I don't want to put words in your mouth though, so correct me if I'm wrong. Security aware caching name servers MUST NOT use cached wildcard RRs to synthesis postive wildcard matches to queries. I think the 1 is also a problem, but maybe not serious. There could be cases where a resolver could get 2 different answers from 2 different security aware caches if one used old NSEC RRs, and one got the authoritative data from a zone that was updated. It is up to the WG to decide if we should say that caching resolvers MUST NOT generate negative responses from cached NSEC RRs or not. Of course, I'm not sure how NSEC2 changes things just yet, but case 2 would still hold - wildcards aren't affected here. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka > Sent: Tuesday, June 01, 2004 3:42 PM > To: namedroppers@ops.ietf.org > Subject: Re: protocol-06 section 4.5 > > > On Tuesday 01 June 2004 1:42 pm, Scott Rose wrote: > > If memory serves me right... > > > > The concern was having over-eager caching servers generate new responses > > from stored NSEC RRs. In some cases, the queried name, type > may have been > > updated, and the NSEC no longer valid. For example: > > > > query for b.foo.com get: > > a.foo.com NSEC c.foo.com CNAME > > > > then someone queries for <a.foo.com IN A> and gets back the > same cached > > NSEC RR (that shows a.foo.com doesn't have an A RR associated > with it). In > > this case it is correct, but in some cases, the NSEC RR for > a.foo.com may > > be out of date. Caching servers also now know a wildcard RR > when they see > > it, so they may also be tempted to generate positive wildcard responses > > from cached RRs. > > I have a hard time seeing what you are describing as a serious > problem. I'm > not saying that I believe that there isn't a serious problem > here, but that I > don't think that we have described it yet. > > Right now (ignoring caches doing wildcard synthesis for the moment), what > you've described is a cache that is, essentially, doing > preemptive negative > caching. Unless the NSEC record is actually lying to you, the > only problem I > see for this is that, after a zone change, downstream clients > will not see > the zone change (assuming an RRset was added, not removed) for > the duration > of the NSEC TTL. > > > It might be able to be re-written as: > > > > "caching security aware name serves MUST NOT use cached NSEC RRs to > > generate negative responses for queries unless those queries matched > > previous queries. Also, caching server MUST NOT generate their own > > positive wildcard matches using previously cached wildcard RRs. > > > > That text might be more confusing though. It would need to be made very > > clear (more clear than above). > > This is sort of language I would like to see for section 4.5. However, I > think we need to justify it. > > -- > 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 08:58:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19937 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 08:58:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVVCh-000J7e-01 for namedroppers-data@psg.com; Wed, 02 Jun 2004 12:50:47 +0000 Received: from [193.0.3.29] (helo=fopje.dacht.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVVCf-000J77-5c for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 12:50:45 +0000 Received: from ripe.net (unknown [193.0.3.28]) by fopje.dacht.net (Postfix) with ESMTP id 1C5B72FBD4; Wed, 2 Jun 2004 14:50:43 +0200 (CEST) Message-ID: <40BDCD26.4050808@ripe.net> Date: Wed, 02 Jun 2004 14:50:46 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> Cc: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >1. Caches generating negative responses using NSEC RRs recieved from >unrelated queries. > > > (...) >I think the 1 is also a problem, but maybe not serious. There could be >cases where a resolver could get 2 different answers from 2 different >security aware caches if one used old NSEC RRs, and one got the >authoritative data from a zone that was updated. It is up to the WG to >decide if we should say that caching resolvers MUST NOT generate negative >responses from cached NSEC RRs or not. > > > I think that there are two issues under 1. The use of NSECs to generate NXDOMAIN responses for other queries for other names (and classes) than the QNAME, QCLASS for which the NXEC was stored; the use of NSECs to generate NOERROR no-answer responses for qeueries with only a different type than the QNAME, QCLASS, QTYPE for which the NSEC was stored. The first use is _bad_. That is because NSEC RRs may be automagically generated and signed.You would not want to see that NSEC to be used to proof the non existence of other RRs. Here is an example of a (silly) DNS application to proof why an NSEC should not be used to proof the non-existence of other domain names. ns.rp.secret-wg.org is a "secured reverse polish DNS calculator" you can perform calculations by puting your 'stack' into a set of labels and query under the rp.secret-wg.org domain. The answer is provided in a TXT RR. Since there will always be an answer for each possible domain in the rp.secret-wg.org domain (or a SERVFAIL in case of stack underflow) and the namespace is infinite the NSEC RRs that are automatically genrated to proof the NOERROR no-answer reply always points back to the SOA. (You can use the same trick to prevent NSEC walks) The 2 + 2 query provides an NSEC that should not be used to proof that 3 + 2 (3.2.+.rp.secret-wg.org) does not exist. In this particular case you could use the NSEC to proof the nonexistence of other types under 2.2.+.rp.secret-wg.org; The current text in protocol allows for that. ; <<>> DiG 9.3.0beta3 <<>> @ns.rp.secret-wg.org 2.2.+.rp.secret-wg.org ANY +dnssec ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42620 ;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 2048 ;; QUESTION SECTION: ;2.2.+.rp.secret-wg.org. IN ANY ;; ANSWER SECTION: 2.2.+.rp.secret-wg.org. 10 IN TXT "4" 2.2.+.rp.secret-wg.org. 10 IN SIG TXT 1 6 10 20040801123632 20040602123632 27900 rp.secret-wg.org. pwCKCwxRnQ91wvJAxJ4MHEHsxCf0KLWbe66a7znHrzSL2a1Y2wUNeTRq S0VzGpevrQkcS/9XszlM1/+u90THBQ== 2.2.+.rp.secret-wg.org. 10 IN A 193.0.4.49 2.2.+.rp.secret-wg.org. 10 IN SIG A 1 6 10 20040801123632 20040602123632 27900 rp.secret-wg.org. tLOidlVhtOnDkat7DZRr8gmYyoL3xkZCCsNxGYHqU5SvQ07H/FNULcVs X0uwSLKSA/eNewAOzF3tgmSy108dGg== 2.2.+.rp.secret-wg.org. 10 IN NXT rp.secret-wg.org. A TXT SIG NXT 2.2.+.rp.secret-wg.org. 10 IN SIG NXT 1 6 10 20040801123632 20040602123632 27900 rp.secret-wg.org. vRhdJMjlR2+TyKGZn8AWZgZdgdHh51zS1oBTwQEIxRpyXd6I3adnPXOY zlbbeNctj8zefFjy8P148Lgz5NAhNQ== ;; Query time: 209 msec ;; SERVER: 193.0.3.29#53(ns.rp.secret-wg.org) ;; WHEN: Wed Jun 2 14:36:36 2004 ;; MSG SIZE rcvd: 435 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 09:14:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20492 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 09:14:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVVXJ-000NXw-UU for namedroppers-data@psg.com; Wed, 02 Jun 2004 13:12:05 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVVXA-000NWL-1V for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 13:11:56 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id AE2551FF857; Wed, 2 Jun 2004 13:11:54 +0000 (GMT) Message-ID: <40BDD219.30101@algroup.co.uk> Date: Wed, 02 Jun 2004 14:11:53 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> Cc: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > Thinking about this some more, I think we can break things down into > smaller, semi-related chunks. Some might be problems, some might be serious > problems (I've come to recognize the difference :) > > 1. Caches generating negative responses using NSEC RRs recieved from > unrelated queries. > 2. Caches synthesizing positive wildcard responses from cached wildcard > RRs. > > I think we agree that 2 is a bad thing, so there should be rule against > caches doing that. I don't want to put words in your mouth though, so > correct me if I'm wrong. Security aware caching name servers MUST NOT use > cached wildcard RRs to synthesis postive wildcard matches to queries. > > I think the 1 is also a problem, but maybe not serious. There could be > cases where a resolver could get 2 different answers from 2 different > security aware caches if one used old NSEC RRs, and one got the > authoritative data from a zone that was updated. It is up to the WG to > decide if we should say that caching resolvers MUST NOT generate negative > responses from cached NSEC RRs or not. > > Of course, I'm not sure how NSEC2 changes things just yet, but case 2 would > still hold - wildcards aren't affected here. NSEC2 would have exactly the same issue (or non-issue, as the case may be). 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 Wed Jun 2 09:25:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20886 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 09:25:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVVh3-000PDx-Br for namedroppers-data@psg.com; Wed, 02 Jun 2004 13:22:09 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVVh1-000PDY-TW for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 13:22:08 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 035521FF84A; Wed, 2 Jun 2004 13:22:07 +0000 (GMT) Message-ID: <40BDD47E.1020604@algroup.co.uk> Date: Wed, 02 Jun 2004 14:22:06 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> Cc: Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) References: <20040601162708.373BFE7EC3@mx1.nominet.org.uk> <a06020414bce26b494693@[192.168.1.100]> In-Reply-To: <a06020414bce26b494693@[192.168.1.100]> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 17:27 +0100 6/1/04, Geoffrey Sisson wrote: > >> NSEC2 hashes are generated when the zone is signed, so this shouldn't >> impose any load which NSEC doesn't already? > > > Not quite. > > When I ask for 1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net, the server > will only have pre-generated the hash for net. and not for anything else > (that doesn't exist). > > The client and server will need to communicate over the fact that there > is no hash name for > > 1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net > and 2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net > and 3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net > and ... > and 9.9.net > and 9.net > and net - exists > and finally *.net > > Now wait a minute. I need think about this a bit differently. > > The server knows up front that 9.net doesn't exist - it doesn't need to > "search" for that. So what happens if the server just says 9.net does > not exist? If the server can say this outright, then the client can > conclude anything below 9.net is also "not explicitly there." Does it > matter that the same NSEC2 can be used for 9.net and a longer name? I > don't think so. > > I suppose the needed parts of the answer are 1) that 9.net doesn't > exist, 2) that net. does exist, and 3) that *.net doesn't exist. If > that's the case, then there isn't a linear growth of calculations and > response records. > > If this is right, then we are pushing the computing power back on the > client. The client may still need to compute all of the hashes. If I > show a return of > > <hash1> NSEC2 <hash2> (as the non-existent name closer than the CE) > <hash3> NSEC2 <hash4> (as the CE=closest enclosure being there) > <hash5> NSEC2 <hash6> (as the *.CE) > > The client isn't sure whether hash1 is the hash of the queried name or > one far shorter. But that's good, keeping the computing off the server. > > I think that I've been overstating the cost...NSEC2 is more "expensive" > than NSEC, but only by a fixed amount (the extra record). > > However - is it ambiguous? What are the chances that the sequence of > hashs of the sequence of subsequently shorter name having a repeat of a > triple? I.e., what if the hashes of the above are: > > 1,2,3,45,67,43,32,1,2,3,33,77,99,... can the client be confused? In a > bad way? The chances of hash collisions are very small indeed - you'd need around 2^80 names to have a 1:2 chance of a single collision. > I don't think an interloper could devastatingly confuse the client here > - the client will know that it needs to see proof of one name, proof of > non-existence of a direct descendent, and then proof of the missing wild > card. Without the private key, an interloper couldn't generate the > RRSIGs on the records. This seems correct to me. > PS I through out an unrelated question earlier today that is related to > this. I'd also have to prove, if *.net exists, that nothing.*.net > exists. That would be a pain. Why would this be a pain? Just because there's an extra record? 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 Wed Jun 2 10:11:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23476 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:11:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVWPS-0006X5-8j for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:08:02 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVWPR-0006Wj-GA for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:08:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3AA7A13DE9 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 14:08:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: HEREIS "draft-vixie-dnssec-ter-00.txt" In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 02 Jun 2004 12:39:28 +0100." <40BDBC70.90403@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 02 Jun 2004 14:08:01 +0000 Message-Id: <20040602140801.3AA7A13DE9@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > 2.5. It is possible that DNSSEC-TER metadata could be synthesized > > using only DNSSEC-BIS metadata. For example, an NSEC2 RR ... > I'd note that you'd need a complete copy of the zone to do this. that's true of NSEC2 as you've proposed it, but it may not be true of what the chairs are calling "NSEC2/NO++". in any case the possibility of such synthesis should be discussed when setting the parameters for going forward. it could be that such synthesis would be a bad thing in all cases, since the NSEC (or NSEC2/NO++) might say that only one of the RR types actually exists, yet if you query for the other one, you get a positive (synthetic) answer. we do not need to select a particular "NSEC2/NO++" solution in order to prove that one can exist. in <draft-vixie-dnssec-ter-##.txt> i intend only that we show an understanding of the working conditions of the DNSSEC-TER designers. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 10:25:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24827 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:25:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVWe9-0008ca-Gf for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:23:13 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVWe8-0008c6-8B for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:23:12 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 10:23:11 -0400 id 0013885A.40BDE2CF.00003141 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: HEREIS "draft-vixie-dnssec-ter-00.txt" Date: Wed, 2 Jun 2004 10:23:11 -0400 User-Agent: KMail/1.6.2 References: <20040602070859.0F50913951@sa.vix.com> <40BDBC70.90403@algroup.co.uk> In-Reply-To: <40BDBC70.90403@algroup.co.uk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021023.11530.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 7:39 am, Ben Laurie wrote: > Paul Vixie wrote: > > 2.5. It is possible that DNSSEC-TER metadata could be synthesized > > using only DNSSEC-BIS metadata. For example, an NSEC2 RR which offers > > the benefit of domain name confidentiality might use name hashes rather > > than domain names to bracket a range of name nonexistence, and it might > > be possible to compute these hashes using an existing NSEC RR. > > Therefore, a DNSSEC-TER specification might permit caching forwarders to > > synthesize NSEC2 RRs using NSEC RRs, thus improving the number of round > > trips otherwise called for in section 2.3 above. > > I'd note that you'd need a complete copy of the zone to do this. And the private key. -- 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 Wed Jun 2 10:33:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25499 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:33:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVWjk-0009VA-N4 for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:29:00 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVWji-0009Uc-Uh for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:28:59 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i52ESj5X026019; Wed, 2 Jun 2004 10:28:45 -0400 To: Ben Laurie <ben@algroup.co.uk> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: HEREIS "draft-vixie-dnssec-ter-00.txt" References: <20040602070859.0F50913951@sa.vix.com> <40BDBC70.90403@algroup.co.uk> From: Derek Atkins <derek@ihtfp.com> Date: Wed, 02 Jun 2004 10:28:45 -0400 In-Reply-To: <40BDBC70.90403@algroup.co.uk> (Ben Laurie's message of "Wed, 02 Jun 2004 12:39:28 +0100") Message-ID: <sjmfz9em3tu.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> writes: > Paul Vixie wrote: >> 2.5. It is possible that DNSSEC-TER metadata could be synthesized using >> only DNSSEC-BIS metadata. For example, an NSEC2 RR which offers the >> benefit of domain name confidentiality might use name hashes rather than >> domain names to bracket a range of name nonexistence, and it might be >> possible to compute these hashes using an existing NSEC RR. Therefore, >> a DNSSEC-TER specification might permit caching forwarders to synthesize >> NSEC2 RRs using NSEC RRs, thus improving the number of round trips >> otherwise called for in section 2.3 above. > > I'd note that you'd need a complete copy of the zone to do this. It's worse than that -- the signature needs to be recreated as well because you need to sign the hash-name instead of the original domain-name. -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 Wed Jun 2 10:35:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25598 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:35:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVWlv-0009uj-4a for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:31:15 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVWls-0009uE-Mv for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:31:14 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i4SI2Zf3025187; Fri, 28 May 2004 14:02:35 -0400 To: bmanning@vacation.karoshi.com Cc: Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org Subject: Re: Confirming the Nominet position 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.> From: Derek Atkins <derek@ihtfp.com> Date: Fri, 28 May 2004 14:02:35 -0400 In-Reply-To: <20040528151621.GA13996@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Fri, 28 May 2004 15:16:21 +0000") Message-ID: <sjmsmdkwhtw.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_96_XX autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bmanning@vacation.karoshi.com writes: > i've been told that digital signatures can be used as > legal evidence in some jurisdictions. if true, it is > conceivable that by my holding signed data indicates, > if not the path by which i received said data, who signed the > data. 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/> From owner-namedroppers@ops.ietf.org Wed Jun 2 10:35:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25616 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:35:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVWmp-000A3S-OG for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:32:11 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVWmo-000A2f-He for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:32:10 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 10:32:09 -0400 id 00105149.40BDE4E9.000033B8 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 10:32:09 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021032.09533.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 8:13 am, Scott Rose wrote: > Thinking about this some more, I think we can break things down into > smaller, semi-related chunks. Some might be problems, some might be > serious problems (I've come to recognize the difference :) > > 1. Caches generating negative responses using NSEC RRs recieved from > unrelated queries. > 2. Caches synthesizing positive wildcard responses from cached wildcard > RRs. > > I think we agree that 2 is a bad thing, so there should be rule against > caches doing that. I don't want to put words in your mouth though, so > correct me if I'm wrong. Security aware caching name servers MUST NOT use > cached wildcard RRs to synthesis postive wildcard matches to queries. OK, but WHY is this a bad thing? I would agree that if I were writing a resolver, I would not want to be *expected* to synthesis from detected wildcards, but if I did, what would be the harm? I can only think of two things here: 1) if caches synthesized wildcard responses, it would stop cold any wildcard "tricks", and 2) it changes some fundmental principles of DNS, which might have some un-though-of consequences. > I think the 1 is also a problem, but maybe not serious. There could be > cases where a resolver could get 2 different answers from 2 different > security aware caches if one used old NSEC RRs, and one got the > authoritative data from a zone that was updated. It is up to the WG to > decide if we should say that caching resolvers MUST NOT generate negative > responses from cached NSEC RRs or not. How is this different from normal negative caching? If the zone changes between two queries, a negative cache entry might block a client from seeing the change for a while. Of course, synthesizing negative answers from NSEC records would make this effect much, much more common. -- 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 Wed Jun 2 10:39:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25920 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:39:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVWqt-000Atq-HU for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:36:23 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVWqs-000Ash-HP for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:36:22 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i52EZxIZ026048; Wed, 2 Jun 2004 10:35:59 -0400 To: roy@dnss.ec Cc: namedroppers@ops.ietf.org Subject: Re: number games. Re: WGLC for DNSSECbis docs References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> From: Derek Atkins <derek@ihtfp.com> Date: Wed, 02 Jun 2004 10:35:59 -0400 In-Reply-To: <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> (roy@dnss.ec's message of "Wed, 2 Jun 2004 12:09:00 +0200 (CEST)") Message-ID: <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk roy@dnss.ec writes: > 4) Proof of concept tool at: http://www.josefsson.org/walker/ > Queries individual records PLUS the NSEC records. For a delegation only > zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the > apex). Note that this assumes all your children are signed. Remember that NS and Glue records are not signed. If your children are not signed then there is no authoritative data and therefore no NSEC. This means is a delegation-only zone you're only signing the SOA and DS records. This definitely limits the walkability of the full zone, as the NSEC tree is limited to the DS content. Unless, of course, you're actually serving non-delegation data in your zone? -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 Wed Jun 2 10:42:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26022 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:42:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVWv4-000Bqe-HV for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:40:42 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVWv3-000BqE-PJ for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:40:41 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 10:40:40 -0400 id 001081E2.40BDE6E8.0000356D From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 10:40:40 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <40BDCD26.4050808@ripe.net> In-Reply-To: <40BDCD26.4050808@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021040.40570.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 8:50 am, Olaf M. Kolkman wrote: > >1. Caches generating negative responses using NSEC RRs recieved from > >unrelated queries. > I think that there are two issues under 1. The use of NSECs to generate > NXDOMAIN responses for other queries for other names (and classes) than > the QNAME, QCLASS for which the NXEC was stored; the use of NSECs to > generate NOERROR no-answer responses for qeueries with only a different > type than the QNAME, QCLASS, QTYPE for which the NSEC was stored. > > The first use is _bad_. That is because NSEC RRs may be automagically > generated and signed.You would not want to see that NSEC to be used to > proof the non existence of other RRs. > > Here is an example of a (silly) DNS application to proof why an NSEC > should not be used to proof the non-existence of other domain names. What you are saying (I think) is that, if caches synthesize NXDOMAIN responses, then the cache will prevent the user from seeing rapid changes to a zone, against the zone publisher's wishes. Couldn't the zone publisher just put 0 TTLs on the NSEC records in that case? I dimly remember that we determined something more "serious" would result if caches synthesize negative answers, but I cannot remember (if I ever knew) what it was. It was something that fell out of the Opt-In discussion, however. I am hoping that we can re-discover it. -- 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 Wed Jun 2 10:50:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26223 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:50:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVX1T-000Cjy-Kw for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:47:19 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVX1S-000Cjc-Cm for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:47:18 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id CBB9031ED15; Wed, 2 Jun 2004 16:47:20 +0200 (CEST) In-Reply-To: <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <C039CFCF-B4A3-11D8-9A2A-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman <olaf@ripe.net> Subject: Re: number games. Re: WGLC for DNSSECbis docs Date: Wed, 2 Jun 2004 16:47:20 +0200 To: Derek Atkins <derek@ihtfp.com> X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jun 2, 2004, at 4:35 PM, Derek Atkins wrote: > Note that this assumes all your children are signed. Remember that NS > and Glue records are not signed. If your children are not signed then > there is no authoritative data and therefore no NSEC. This means is a > delegation-only zone you're only signing the SOA and DS records. This > definitely limits the walkability of the full zone, as the NSEC tree > is limited to the DS content. > > Unless, of course, you're actually serving non-delegation data in your > zone? > There are NSECs proofing that there is no DS above the delegation point for each unsecured child. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 10:56:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26419 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:56:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVX7c-000Dhy-Pv for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:53:40 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVX7Z-000Dh0-O7 for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:53:37 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i52ErTUt069454; Wed, 2 Jun 2004 16:53:29 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52ErPpm030089; Wed, 2 Jun 2004 16:53:25 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52ErNAq030086; Wed, 2 Jun 2004 16:53:24 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 2 Jun 2004 16:53:23 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Derek Atkins <derek@ihtfp.com> cc: roy@dnss.ec, namedroppers@ops.ietf.org Subject: Re: number games. Re: WGLC for DNSSECbis docs In-Reply-To: <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> Message-ID: <Pine.LNX.4.58.0406021650190.21385@elektron.atoom.net> References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, OPT_IN,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 2 Jun 2004, Derek Atkins wrote: > roy@dnss.ec writes: > > > 4) Proof of concept tool at: http://www.josefsson.org/walker/ > > Queries individual records PLUS the NSEC records. For a delegation only > > zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the > > apex). > > Note that this assumes all your children are signed. Remember that NS > and Glue records are not signed. If your children are not signed then > there is no authoritative data and therefore no NSEC. Errr no. If your children are not signed, you have a NSEC with the DS bit clear in the type bit map to proof the child is not signed. The way the tool works is that it queries for NSEC, followed by queries listed in the type-bit-map of the queried NSEC. > This means is a delegation-only zone you're only signing the SOA and DS > records. This definitely limits the walkability of the full zone, as > the NSEC tree is limited to the DS content. Are you talking opt-in? > Unless, of course, you're actually serving non-delegation data in your > zone? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 10:59:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26568 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 10:59:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVX9a-000E0E-2X for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:55:42 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVX9Z-000Dzo-2f for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:55:41 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 10:55:39 -0400 id 00105149.40BDEA6C.000039C2 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: number games. Re: WGLC for DNSSECbis docs Date: Wed, 2 Jun 2004 10:55:40 -0400 User-Agent: KMail/1.6.2 References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> In-Reply-To: <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021055.40065.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 10:35 am, Derek Atkins wrote: > roy@dnss.ec writes: > > 4) Proof of concept tool at: http://www.josefsson.org/walker/ > > Queries individual records PLUS the NSEC records. For a delegation > > only zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the > > apex). > > Note that this assumes all your children are signed. Remember that NS > and Glue records are not signed. If your children are not signed then > there is no authoritative data and therefore no NSEC. This means is a > delegation-only zone you're only signing the SOA and DS records. This > definitely limits the walkability of the full zone, as the NSEC tree > is limited to the DS content. Delegation NS records get an NSEC. This is a basic rule spelled out in -protocol. However, what you are describing isn't a bad idea, IMHO. It is called "Opt-In". -- 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 Wed Jun 2 11:03:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26735 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:03:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVXC0-000EOv-Vm for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:58:12 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVXBz-000EOG-O1 for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:58:12 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 4C1D431ED38; Wed, 2 Jun 2004 16:58:14 +0200 (CEST) In-Reply-To: <200406021040.40570.davidb@verisignlabs.com> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <40BDCD26.4050808@ripe.net> <200406021040.40570.davidb@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4581E82C-B4A5-11D8-9A2A-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman <olaf@ripe.net> Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 16:58:13 +0200 To: David Blacka <davidb@verisignlabs.com> X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > What you are saying (I think) is that, if caches synthesize NXDOMAIN > responses, then the cache will prevent the user from seeing rapid > changes to > a zone, against the zone publisher's wishes. Almost, if the caches synthesize NXDOMAIN responses based on NSECs in their cache that do not relate to the current query they will get it wrong. > Couldn't the zone publisher > just put 0 TTLs on the NSEC records in that case? That would be an operational hack to prevent caches doing something they MUST NOT do. (That something being making up answers for questions they never asked, since that will in some cases break end-to-end consistency). > I dimly remember that we determined something more "serious" would > result if > caches synthesize negative answers, but I cannot remember (if I ever > knew) > what it was. It was something that fell out of the Opt-In discussion, > however. I am hoping that we can re-discover it. > Rob and/or Roy presented something at an IETF (San Diego, Salt Lake, Yokohama???, I do recall but I cannot find record of that presentation either in the minutes or the list archives). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 11:03:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26759 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:03:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVXDM-000Ebs-5J for namedroppers-data@psg.com; Wed, 02 Jun 2004 14:59:36 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVXDL-000EbL-2R for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 14:59:35 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i52ExThk026134; Wed, 2 Jun 2004 10:59:29 -0400 To: Olaf Kolkman <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: number games. Re: WGLC for DNSSECbis docs References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> <C039CFCF-B4A3-11D8-9A2A-000393DA2D46@ripe.net> From: Derek Atkins <derek@ihtfp.com> Date: Wed, 02 Jun 2004 10:59:29 -0400 In-Reply-To: <C039CFCF-B4A3-11D8-9A2A-000393DA2D46@ripe.net> (Olaf Kolkman's message of "Wed, 2 Jun 2004 16:47:20 +0200") Message-ID: <sjmpt8iknu6.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf Kolkman <olaf@ripe.net> writes: > There are NSECs proofing that there is no DS above the delegation > point for each unsecured child. Yes, but unless things have changed yet again, NS delegation records are not authoritative data, which means you shouldn't need an NSEC at the name to prove that no DS exists. E.g.: @ = example. a NS .. DS .. SIG(DS) .. NSEC c ... SIG(NSEC) b NS .. c NS .. DS .. SIG(DS) .. NSEC . .. SIG(NSEC) "b NS" isn't authoritative so you don't need an NSEC at the node. The 'a NSEC c' proves that no DS exists for b. From draft-ietf-dnsext-nsec-rdata-06 section 2.1.1: Owner names of RRsets not authoritative for the given zone (such as glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name. Neither NS delegations nor glue A records are authoritative data. > --Olaf -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 Wed Jun 2 11:08:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26957 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:08:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVXJT-000GFd-MY for namedroppers-data@psg.com; Wed, 02 Jun 2004 15:05:55 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVXJS-000GF3-Hu for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 15:05:54 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i52F5liU069572; Wed, 2 Jun 2004 17:05:47 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52F5iGR030422; Wed, 2 Jun 2004 17:05:44 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52F5ips030419; Wed, 2 Jun 2004 17:05:44 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 2 Jun 2004 17:05:44 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Derek Atkins <derek@ihtfp.com> cc: Ben Laurie <ben@algroup.co.uk>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: HEREIS "draft-vixie-dnssec-ter-00.txt" In-Reply-To: <sjmfz9em3tu.fsf@dogbert.ihtfp.org> Message-ID: <Pine.LNX.4.58.0406021654210.21385@elektron.atoom.net> References: <20040602070859.0F50913951@sa.vix.com> <40BDBC70.90403@algroup.co.uk> <sjmfz9em3tu.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 2 Jun 2004, Derek Atkins wrote: > Ben Laurie <ben@algroup.co.uk> writes: > > > Paul Vixie wrote: > >> 2.5. It is possible that DNSSEC-TER metadata could be synthesized using > >> only DNSSEC-BIS metadata. For example, an NSEC2 RR which offers the > >> benefit of domain name confidentiality might use name hashes rather than > >> domain names to bracket a range of name nonexistence, and it might be > >> possible to compute these hashes using an existing NSEC RR. Therefore, > >> a DNSSEC-TER specification might permit caching forwarders to synthesize > >> NSEC2 RRs using NSEC RRs, thus improving the number of round trips > >> otherwise called for in section 2.3 above. > > > > I'd note that you'd need a complete copy of the zone to do this. > > It's worse than that -- the signature needs to be recreated as well > because you need to sign the hash-name instead of the original > domain-name. What Ben was referring (Ben ?) to is that the canonically ordered list of ownername(X) and its projected canonically ordered list of HASH(ownername(X)) are non-linear. In other words, X NSEC Y and HASH(X) NSEC2 HASH (Y) have different Y for the same X. If it were linear, binary search would make hashing purposes trivially obsolete. If it were linear, it is not a one-way-hash function. If a cache does want to convert NSEC to NSEC2, it needs knowledge of the entire zone, the zones' private key, hash each individual owner name, rebuild the NSEC2 chain using the ordered hashed ownernames and resign each individual 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 Wed Jun 2 11:12:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27069 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:12:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVXMo-000H4i-6U for namedroppers-data@psg.com; Wed, 02 Jun 2004 15:09:22 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVXMm-000H4A-Ub for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 15:09:21 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i52F9Glp026163; Wed, 2 Jun 2004 11:09:16 -0400 To: David Blacka <davidb@verisignlabs.com> Cc: namedroppers@ops.ietf.org Subject: Re: number games. Re: WGLC for DNSSECbis docs References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> <200406021055.40065.davidb@verisignlabs.com> From: Derek Atkins <derek@ihtfp.com> Date: Wed, 02 Jun 2004 11:09:16 -0400 In-Reply-To: <200406021055.40065.davidb@verisignlabs.com> (David Blacka's message of "Wed, 2 Jun 2004 10:55:40 -0400") Message-ID: <sjmiseakndv.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka <davidb@verisignlabs.com> writes: > Delegation NS records get an NSEC. This is a basic rule spelled out in > -protocol. Hmm.. Then -nsec needs to get corrected because it's less clear there. The -nsec spec says you only need NSECs for authoritative data (of which an NS delegation is not). You are correct that -protocol explicitly specifies authoritative data AND NS delegations (section 2.3). If -protocol is the correct "will of the people" than -nsec should be changed to match. > However, what you are describing isn't a bad idea, IMHO. It is called > "Opt-In". I thought we had agreed that NS delegations did not NEED to be part of the NSEC chain, but clearly I had too much Guiness that night. :( -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 Wed Jun 2 11:18:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27209 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:18:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVXTU-000IUv-Ay for namedroppers-data@psg.com; Wed, 02 Jun 2004 15:16:16 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVXTT-000IUe-6m for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 15:16:15 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i52FGAOc069659; Wed, 2 Jun 2004 17:16:11 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52FG7He030759; Wed, 2 Jun 2004 17:16:07 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52FG7c6030756; Wed, 2 Jun 2004 17:16:07 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 2 Jun 2004 17:16:07 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: David Blacka <davidb@verisignlabs.com> cc: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: <200406021032.09533.davidb@verisignlabs.com> Message-ID: <Pine.LNX.4.58.0406021706460.21385@elektron.atoom.net> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021032.09533.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, OPT_IN,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 2 Jun 2004, David Blacka wrote: > On Wednesday 02 June 2004 8:13 am, Scott Rose wrote: > > Thinking about this some more, I think we can break things down into > > smaller, semi-related chunks. Some might be problems, some might be > > serious problems (I've come to recognize the difference :) > > > > 1. Caches generating negative responses using NSEC RRs recieved from > > unrelated queries. > > 2. Caches synthesizing positive wildcard responses from cached wildcard > > RRs. > > > > I think we agree that 2 is a bad thing, so there should be rule against > > caches doing that. I don't want to put words in your mouth though, so > > correct me if I'm wrong. Security aware caching name servers MUST NOT use > > cached wildcard RRs to synthesis postive wildcard matches to queries. > > OK, but WHY is this a bad thing? I would agree that if I were writing a > resolver, I would not want to be *expected* to synthesis from detected > wildcards, but if I did, what would be the harm? One of the cornercases that Rob and I were dealing with during the opt-in debate, is the following, say you have: A NSEC H H NSEC K A caching resolver caches: A NSEC H A new record F is added, an old record H is removed from the zone. which now reads A NSEC F F NSEC K additionally caching resolver caches F NSEC K Now the cache reads: A NSEC H F NSEC K and has conflicting NSEC The first denies F exists. The second denies H exists. Say resolver makes 'efficient' use of cached NSEC records, which one should be returned for a query for F, for G, and for H. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 11:23:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27632 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:23:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVXXb-000JAE-N7 for namedroppers-data@psg.com; Wed, 02 Jun 2004 15:20:31 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVXXa-000J9r-MI for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 15:20:30 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 11:20:29 -0400 id 000FFDA4.40BDF03D.0000413E From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 11:20:29 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021040.40570.davidb@verisignlabs.com> <4581E82C-B4A5-11D8-9A2A-000393DA2D46@ripe.net> In-Reply-To: <4581E82C-B4A5-11D8-9A2A-000393DA2D46@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021120.29691.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 10:58 am, Olaf Kolkman wrote: > > What you are saying (I think) is that, if caches synthesize NXDOMAIN > > responses, then the cache will prevent the user from seeing rapid > > changes to > > a zone, against the zone publisher's wishes. > > Almost, if the caches synthesize NXDOMAIN responses based on NSECs in > their cache that do not relate to the current query they will get it > wrong. Well, "wrong" in the sense of your silly RPN example. I see this as similar to what happens if caches synthesizes wildcards: synthesizing negative answers from NSEC records stops NSEC games cold. > > Couldn't the zone publisher > > just put 0 TTLs on the NSEC records in that case? > > That would be an operational hack to prevent caches doing something > they MUST NOT do. (That something being making up answers for questions > they never asked, since that will in some cases break end-to-end > consistency). This is circular. What I'm trying to discover is WHY caches MUST NOT do this. If the only reason for not allowing caches to synthesize negative responses is to allow zone publishers to play NSEC games (which could be considered an operational hack itself), wouldn't 0 TTLs on the NSEC records suffice? > > I dimly remember that we determined something more "serious" would > > result if > > caches synthesize negative answers, but I cannot remember (if I ever > > knew) > > what it was. It was something that fell out of the Opt-In discussion, > > however. I am hoping that we can re-discover it. > > Rob and/or Roy presented something at an IETF (San Diego, Salt Lake, > Yokohama???, I do recall but I cannot find record of that presentation > either in the minutes or the list archives). Salt Lake, I believe. I couldn't find a record of it either, other than in my fuzzy memory. -- 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 Wed Jun 2 11:33:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28686 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:33:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVXhO-000Knd-FW for namedroppers-data@psg.com; Wed, 02 Jun 2004 15:30:38 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVXhN-000KnP-Lp for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 15:30:37 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 11:30:36 -0400 id 0013850D.40BDF29C.000044BD From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 11:30:36 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021032.09533.davidb@verisignlabs.com> <Pine.LNX.4.58.0406021706460.21385@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406021706460.21385@elektron.atoom.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021130.36747.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 11:16 am, roy@dnss.ec wrote: > One of the cornercases that Rob and I were dealing with during the opt-in > debate, is the following, say you have: > > A NSEC H > H NSEC K > > A caching resolver caches: > > A NSEC H > > A new record F is added, an old record H is removed from the zone. which > now reads > > A NSEC F > F NSEC K > > additionally caching resolver caches > > F NSEC K > > Now the cache reads: > > A NSEC H > F NSEC K > > and has conflicting NSEC > > The first denies F exists. > The second denies H exists. > > Say resolver makes 'efficient' use of cached NSEC records, which one > should be returned for a query for F, for G, and for H. Wouldn't the resolver return F for the query for F, return either NSEC for the query for G, and return H if H is in the cache, otherwise return F NSEC K? Or, if the cache notices conflicting NSEC records, it might choose to ignore both of them and forward the query? I'll admit the logic for the H case might really suck to implement, but I am still having a hard time understanding the case for MUST NOT. -- 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 Wed Jun 2 11:54:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29604 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 11:54:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVY0z-000NVz-1N for namedroppers-data@psg.com; Wed, 02 Jun 2004 15:50:53 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVY0u-000NQL-N0 for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 15:50:48 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i52FFMCs006298 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 11:15:32 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i52FEY4A023032 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 11:14:35 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: "DNSEXT WG" <namedroppers@ops.ietf.org> Subject: RE: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 11:14:35 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGOEGOCKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200406021032.09533.davidb@verisignlabs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka > > 2. Caches synthesizing positive wildcard responses from cached wildcard > > RRs. > > > > I think we agree that 2 is a bad thing, so there should be rule against > > caches doing that. I don't want to put words in your mouth though, so > > correct me if I'm wrong. Security aware caching name servers > MUST NOT use > > cached wildcard RRs to synthesis postive wildcard matches to queries. > > OK, but WHY is this a bad thing? I would agree that if I were writing a > resolver, I would not want to be *expected* to synthesis from detected > wildcards, but if I did, what would be the harm? > > I can only think of two things here: 1) if caches synthesized wildcard > responses, it would stop cold any wildcard "tricks", and 2) it > changes some > fundmental principles of DNS, which might have some un-though-of > consequences. > Basically yes - a caching resolver should not be allowed to synthesize wildcard responses (which would be authoritative data) since they might be incorrect. DNSSEC allows this to happen (that is, a caching server can determine if a record is really a wildcard, which it couldn't do before). By not allowing wildcard synthesis by caching middle boxes, DNSSECbis keeps wildcard synthesis at the authoritative server. 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 Wed Jun 2 12:11:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00406 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 12:11:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVYGa-0000uG-JK for namedroppers-data@psg.com; Wed, 02 Jun 2004 16:07:00 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVYGR-0000s7-GM for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 16:06:51 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.12.11/8.12.11) with ESMTP id i52G6kcw001025; Wed, 2 Jun 2004 12:06:46 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040602114854.029243c0@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Wed, 02 Jun 2004 12:06:33 -0400 To: roy@dnss.ec, David Blacka <davidb@verisignlabs.com> From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Cc: namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.58.0406021706460.21385@elektron.atoom.net> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021032.09533.davidb@verisignlabs.com> <Pine.LNX.4.58.0406021706460.21385@elektron.atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:16 02/06/2004, roy@dnss.ec wrote: >On Wed, 2 Jun 2004, David Blacka wrote: > >Now the cache reads: > >A NSEC H >F NSEC K > >and has conflicting NSEC > >The first denies F exists. >The second denies H exists. > >Say resolver makes 'efficient' use of cached NSEC records, which one >should be returned for a query for F, for G, and for H. DNS is a loose consistency DB situations like this are legal, and expected for a short time (TTL of the Records). But in most cases the cache does the right think, as lookup in cache will discover it exists. IHMO it is would be acceptable for the cache to do any of the following: 1. QNAME: B use A NSEC H 2. QNAME: G use F NSEC K 3. QNAME: H use cached record for H 4. QNAME: H use F NSEC to deny existence of H 5. QNAME: F use cached records for F 6. QNAME: F use A NSEC to deny existence of H 7. QNAME: B or G or F or H, toss both NSEC records and cached information at F and H. send query to auth server. But option 7 requires too much work so I do not expect any implementation do to that. Remember the BIS documents recommend NSEC TTL be Zone Minimum to minimize events like these. Olafur Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 12:38:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01828 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 12:38:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVYhb-0007Vn-DQ for namedroppers-data@psg.com; Wed, 02 Jun 2004 16:34:55 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVYha-0007VN-1D for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 16:34:54 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i52GYnjR070299; Wed, 2 Jun 2004 18:34:50 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52GYkXQ032094; Wed, 2 Jun 2004 18:34:46 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52GYjds032091; Wed, 2 Jun 2004 18:34:46 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 2 Jun 2004 18:34:45 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: David Blacka <davidb@verisignlabs.com> cc: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: <200406021130.36747.davidb@verisignlabs.com> Message-ID: <Pine.LNX.4.58.0406021822230.21385@elektron.atoom.net> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021032.09533.davidb@verisignlabs.com> <Pine.LNX.4.58.0406021706460.21385@elektron.atoom.net> <200406021130.36747.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, OPT_IN,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 2 Jun 2004, David Blacka wrote: > On Wednesday 02 June 2004 11:16 am, roy@dnss.ec wrote: > > > One of the cornercases that Rob and I were dealing with during the opt-in > > debate, is the following, say you have: > > > > A NSEC H > > H NSEC K > > > > A caching resolver caches: > > > > A NSEC H > > > > A new record F is added, an old record H is removed from the zone. which > > now reads > > > > A NSEC F > > F NSEC K > > > > additionally caching resolver caches > > > > F NSEC K > > > > Now the cache reads: > > > > A NSEC H > > F NSEC K > > > > and has conflicting NSEC > > > > The first denies F exists. > > The second denies H exists. > > > > Say resolver makes 'efficient' use of cached NSEC records, which one > > should be returned for a query for F, for G, and for H. > > Wouldn't the resolver return F for the query for F, Why is F more valid than A NSEC H ? > return either NSEC for the query for G, Or both, or A or F ? > and return H if H is in the cache, otherwise return F NSEC K? The problem is how to define these rules and why is one rule preferred over the other, etc. Besides this is just one corner case. Another one would be A NSEC K F NSEC H (lets not discuss priority rules why one is prefered over the other, or why/how both can be returned). Another problem was negative versus positive proof. Positive proof is cached for TTL seconds, negative proof is cached for SOA minumum field. Is it okay to construct a negative response from a positive cached NSEC. How to deal with TTL then ? Since we concluded at the time that these were meta problems, due to layering (DNSSEC can be viewed as a layer over DNS), the conclusion was, in order to stay away from the above cornercase (and not specifying really weird priority inclusion rules) to cache DNSSEC data (SIG and NSEC) by qtype/qname/qclass, where the NSEC and SIG where properties of the q-tuple and not stored as individual RRsets. > Or, if the cache notices conflicting NSEC records, it might choose to > ignore both of them and forward the query? > > I'll admit the logic for the H case might really suck to implement, but I am > still having a hard time understanding the case for MUST NOT. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 13:01:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02903 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 13:01:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVZ3k-000ATL-9p for namedroppers-data@psg.com; Wed, 02 Jun 2004 16:57:48 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVZ3T-000AQi-8B for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 16:57:31 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 12:57:30 -0400 id 00138A0E.40BE06FA.00005DF7 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 12:57:30 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021130.36747.davidb@verisignlabs.com> <Pine.LNX.4.58.0406021822230.21385@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406021822230.21385@elektron.atoom.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021257.30644.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 12:34 pm, roy@dnss.ec wrote: > On Wed, 2 Jun 2004, David Blacka wrote: > > On Wednesday 02 June 2004 11:16 am, roy@dnss.ec wrote: > > > One of the cornercases that Rob and I were dealing with during the > > > opt-in debate, is the following, say you have: ... > > Wouldn't the resolver return F for the query for F, > > Why is F more valid than A NSEC H ? Why does that matter? > > return either NSEC for the query for G, > > Or both, or A or F ? > > > and return H if H is in the cache, otherwise return F NSEC K? > > The problem is how to define these rules and why is one rule preferred > over the other, etc. Besides this is just one corner case. Another one > would be > > A NSEC K > F NSEC H > > (lets not discuss priority rules why one is prefered over the other, or > why/how both can be returned). It is true that DNSSEC adds the capability to store contradictory proof information. I think, in reality, it doesn't really matter which record the cache uses. > Another problem was negative versus positive proof. Positive proof is > cached for TTL seconds, negative proof is cached for SOA minumum field. Is > it okay to construct a negative response from a positive cached NSEC. How > to deal with TTL then ? Wouldn't the NSEC record itself have the same minimum TTL? > Since we concluded at the time that these were meta problems, due to > layering (DNSSEC can be viewed as a layer over DNS), the conclusion was, > in order to stay away from the above cornercase (and not specifying really > weird priority inclusion rules) to cache DNSSEC data (SIG and NSEC) by > qtype/qname/qclass, where the NSEC and SIG where properties of the q-tuple > and not stored as individual RRsets. Which I think was overkill. In my gut, I feel that caches really shouldn't be synthesizing negative answers to questions they have never seen, and shouldn't be synthesizing wildcards just because they happen to notice one. But, OTOH, I don't see (yet) a justification for "MUST NOT" synthesize. Maybe the case has been made, and I just don't see it yet. -- 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 Wed Jun 2 13:01:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02921 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 13:01:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVZ3e-000ASO-RU for namedroppers-data@psg.com; Wed, 02 Jun 2004 16:57:42 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVZ3S-000AQi-2m for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 16:57:30 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 12:57:29 -0400 id 00133E4B.40BE06F9.00005DE4 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 12:57:29 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <Pine.LNX.4.58.0406021822230.21385@elektron.atoom.net> <sjmk6ypkim6.fsf@dogbert.ihtfp.org> In-Reply-To: <sjmk6ypkim6.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021257.29280.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 12:52 pm, Derek Atkins wrote: > roy@dnss.ec writes: > >> > Say resolver makes 'efficient' use of cached NSEC records, which one > >> > should be returned for a query for F, for G, and for H. > >> > >> Wouldn't the resolver return F for the query for F, > > > > Why is F more valid than A NSEC H ? > > Well, for one thing, SIG(F) will have a newer timestamp than SIG(A > NSEC H). This is a reasonable rule, I think. > Second, unless A NSEC H was obtained by a query for F, the > cache should not associate A NSEC H with F. I.e., if the cache has A > NSEC H due to a query for E, it should not carry over that response > into a query for F. Why not? This is what I'm trying to find out. Why shouldn't the cache carry over the A NSEC H from some previous query to the response for F? -- 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 Wed Jun 2 13:02:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02954 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 13:02:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVZ6C-000AtN-HD for namedroppers-data@psg.com; Wed, 02 Jun 2004 17:00:20 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVZ63-000AqU-BN for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 17:00:11 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i52H00R6070570; Wed, 2 Jun 2004 19:00:01 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52Gxvwf032665; Wed, 2 Jun 2004 18:59:57 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52GxvF4032662; Wed, 2 Jun 2004 18:59:57 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 2 Jun 2004 18:59:57 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Derek Atkins <derek@ihtfp.com> cc: roy@dnss.ec, David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: <sjmk6ypkim6.fsf@dogbert.ihtfp.org> Message-ID: <Pine.LNX.4.58.0406021853090.21385@elektron.atoom.net> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021032.09533.davidb@verisignlabs.com> <Pine.LNX.4.58.0406021706460.21385@elektron.atoom.net> <200406021130.36747.davidb@verisignlabs.com> <Pine.LNX.4.58.0406021822230.21385@elektron.atoom.net> <sjmk6ypkim6.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 2 Jun 2004, Derek Atkins wrote: > roy@dnss.ec writes: > > >> > Say resolver makes 'efficient' use of cached NSEC records, which one > >> > should be returned for a query for F, for G, and for H. > >> > >> Wouldn't the resolver return F for the query for F, > > > > Why is F more valid than A NSEC H ? > > Well, for one thing, SIG(F) will have a newer timestamp than SIG(A > NSEC H). As long query happens within the time-delta of both records, both are valid. Unless we specify rules on which timestamp is more valid. Here comes another corner case: SIG(F NSEC K) 5 - 17 SIG(A NSEC H) 7 - 12 QTIME = 8 Sure, SIG(A NSEC H) has a later inception time, but an earlier expire. We either need to specify all the corner case rules, where the problem is that we don't know what we don't know. Or we avoid it. We do know how to avoid it. > Second, unless A NSEC H was obtained by a query for F, the > cache should not associate A NSEC H with F. I.e., if the cache has A > NSEC H due to a query for E, it should not carry over that response > into a query for F. Exactly. You'd cache the NSEC as a property of the response for query F. That is what the doc specifies, and David was asking why this was neccesary (since it is not clear in the docs why that is). Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 13:25:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04629 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 13:25:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVZRe-000FSF-Ku for namedroppers-data@psg.com; Wed, 02 Jun 2004 17:22:30 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVZRd-000FRi-Ea for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 17:22:29 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 7215F31EDF7; Wed, 2 Jun 2004 19:22:31 +0200 (CEST) In-Reply-To: <200406021120.29691.davidb@verisignlabs.com> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021040.40570.davidb@verisignlabs.com> <4581E82C-B4A5-11D8-9A2A-000393DA2D46@ripe.net> <200406021120.29691.davidb@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D50AC72-B4B9-11D8-9A2A-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman <olaf@ripe.net> Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 19:22:30 +0200 To: David Blacka <davidb@verisignlabs.com> X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jun 2, 2004, at 5:20 PM, David Blacka wrote: >> That would be an operational hack to prevent caches doing something >> they MUST NOT do. (That something being making up answers for >> questions >> they never asked, since that will in some cases break end-to-end >> consistency). > > This is circular. What I'm trying to discover is WHY caches MUST NOT > do this. > If the only reason for not allowing caches to synthesize negative > responses > is to allow zone publishers to play NSEC games (which could be > considered an > operational hack itself), wouldn't 0 TTLs on the NSEC records suffice? > I think that it is just plain wrong for the caching nameserver to make up answers by itself even though it might think it knows what to do based on an NSEC available from a previous query. This 'plain wrong' translates to MUST NOT. If I understand you correctly you argue that my reasoning mostly buys us a "SHOULD NOT" ? --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 13:30:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04794 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 13:30:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVZWj-000G5k-3e for namedroppers-data@psg.com; Wed, 02 Jun 2004 17:27:45 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVZWi-000G5Q-0f for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 17:27:44 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i52HRUkZ003960 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 13:27:30 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i52HRH4A023670 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 13:27:17 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 13:27:17 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGGEHECKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200406021257.30644.davidb@verisignlabs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka > > In my gut, I feel that caches really shouldn't be synthesizing negative > answers to questions they have never seen, and shouldn't be synthesizing > wildcards just because they happen to notice one. But, OTOH, I don't see > (yet) a justification for "MUST NOT" synthesize. Maybe the case has been > made, and I just don't see it yet. > I can agree that it probably won't break things, but it could cause some bad corner cases (NSEC re-use) and contradicts some long standing DNS principles (auth servers generate wildcard responses). But not setting strict guidelines might lead to a resolver too clever for its own good. Right now, the text says responses SHOULD be stored as an atomic entry. Maybe it should be changed to SHOULD NOT generate non-existant responses/wildcard expansions instead of MUST NOT? Personally, I like MUST NOT (especially with wildcard expansion) - it keeps things consistant and reduces some of the complexity that could come from caches doing wacky things with data. Scott > -- > 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 13:41:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05243 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 13:41:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVZgy-000HKe-3I for namedroppers-data@psg.com; Wed, 02 Jun 2004 17:38:20 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVZgq-000HJb-Mt for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 17:38:12 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 8166019B8BE; Wed, 2 Jun 2004 13:32:19 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id F413F19B7B7; Wed, 2 Jun 2004 13:32:15 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1721199; Wed, 02 Jun 2004 13:13:42 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602040abce3ba18e187@[192.136.136.83]> In-Reply-To: <40BDD47E.1020604@algroup.co.uk> References: <20040601162708.373BFE7EC3@mx1.nominet.org.uk> <a06020414bce26b494693@[192.168.1.100]> <40BDD47E.1020604@algroup.co.uk> Date: Wed, 2 Jun 2004 13:13:38 -0400 To: Ben Laurie <ben@algroup.co.uk> From: Edward Lewis <edlewis@arin.net> Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag) Cc: Edward Lewis <edlewis@arin.net>, Geoffrey Sisson <geoff@nominet.org.uk>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> 1,2,3,45,67,43,32,1,2,3,33,77,99,... can the client be confused? In a bad >>way? > >The chances of hash collisions are very small indeed - you'd need around 2^80 >names to have a 1:2 chance of a single collision. The situation is better than that. Assuming no collisions, there'll be one and only one NSEC2 RR owner whose name is the hash of one and only one super-domain of the QNAME. The verifier then has the expectation that one of the other NSEC RR's covers the "one-more-label" super-domain and yet another covers the germane wild card. If there was a NSEC2 RR owned by a hash that matched more than one super-domain of the Qname, then we have a hash collision. >> PS I through out an unrelated question earlier today that is >>related to this. >>I'd also have to prove, if *.net exists, that nothing.*.net exists. That >>would be a pain. > >Why would this be a pain? Just because there's an extra record? It depends. Some are saying that "*.net" is still a wild card even if there is a 9.*.net. If so, then there's no need extra pain. Otherwise, the pain is the enforcement of the contrary. (This is the kind of topic that takes time for analysis.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Jun 2 13:43:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05329 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 13:43:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVZkX-000Hjn-G4 for namedroppers-data@psg.com; Wed, 02 Jun 2004 17:42:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVZkU-000HjM-JY for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 17:41:58 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 48B6513DED for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 17:41:58 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: Message from Olaf Kolkman <olaf@ripe.net> of "Wed, 02 Jun 2004 19:22:30 +0200." <6D50AC72-B4B9-11D8-9A2A-000393DA2D46@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 02 Jun 2004 17:41:58 +0000 Message-Id: <20040602174158.48B6513DED@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think that it is just plain wrong for the caching nameserver to make > up answers by itself even though it might think it knows what to do > based on an NSEC available from a previous query. This 'plain wrong' > translates to MUST NOT. > > If I understand you correctly you argue that my reasoning mostly buys > us a "SHOULD NOT" ? i've always thought that wildcard processing should be done mostly in the client, where the server just returns the "*.whatever" owner names and the client has to figure out how it applies. alas, RFC 1034/1035 were written at a time when most clients had dramatically small code and data stores, and the result is a compromise that's caused no end of trouble (if you consider the impact that wildcards have had on the dnssec schedule, for one easy example.) now, the idea of aggressive negative caching also appeals to me, and in some of my unpublished work i've described an "off the wire" version where certain application-level queries are suppressed in the presence of a cached NSEC covering the prospective QNAME. however, i recognize that this is very dangerous, and should not be attempted "on the wire" (by synthesizing NXDOMAIN responses) at this time. however, i'd like this WG to leave open the possibility that some day, somebody will do a very careful analysis of cases, corner cases, exceptions, and so on, and then specifying it as optional behaviour in caching forwarding validating name servers. so if you make it MUST NOT could you make it MUST NOT (YET) please? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 14:25:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07337 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 14:25:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVaNS-00011m-U1 for namedroppers-data@psg.com; Wed, 02 Jun 2004 18:22:14 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVaNR-000113-Js for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 18:22:13 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 14:22:12 -0400 id 00138541.40BE1AD4.000077A8 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 14:22:12 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021120.29691.davidb@verisignlabs.com> <6D50AC72-B4B9-11D8-9A2A-000393DA2D46@ripe.net> In-Reply-To: <6D50AC72-B4B9-11D8-9A2A-000393DA2D46@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021422.12551.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 1:22 pm, Olaf Kolkman wrote: > On Jun 2, 2004, at 5:20 PM, David Blacka wrote: > >> That would be an operational hack to prevent caches doing something > >> they MUST NOT do. (That something being making up answers for > >> questions > >> they never asked, since that will in some cases break end-to-end > >> consistency). > > > > This is circular. What I'm trying to discover is WHY caches MUST NOT > > do this. > > If the only reason for not allowing caches to synthesize negative > > responses > > is to allow zone publishers to play NSEC games (which could be > > considered an > > operational hack itself), wouldn't 0 TTLs on the NSEC records suffice? > > I think that it is just plain wrong for the caching nameserver to make > up answers by itself even though it might think it knows what to do > based on an NSEC available from a previous query. This 'plain wrong' > translates to MUST NOT. > > If I understand you correctly you argue that my reasoning mostly buys > us a "SHOULD NOT" ? Yes, although I too would like it to be a MUST NOT. It occurs to me that, unlike most of the MUSTs and MUST NOTs in the DNSSECbis documents, this could not be enforced (the others are generally "enforced" by the responses not validating). -- 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 Wed Jun 2 15:08:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11485 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 15:08:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVb1h-0007W1-86 for namedroppers-data@psg.com; Wed, 02 Jun 2004 19:03:49 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVb1g-0007Vm-9A for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 19:03:48 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 424E442B2 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 15:03:47 -0400 (EDT) Date: Wed, 02 Jun 2004 15:03:47 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: <200406021120.29691.davidb@verisignlabs.com> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021040.40570.davidb@verisignlabs.com> <4581E82C-B4A5-11D8-9A2A-000393DA2D46@ripe.net> <200406021120.29691.davidb@verisignlabs.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040602190347.424E442B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > I dimly remember that we determined something more "serious" > > > would result if caches synthesize negative answers, but I cannot > > > remember (if I ever knew) what it was. It was something that > > > fell out of the Opt-In discussion, however. I am hoping that we > > > can re-discover it. > > > > Rob and/or Roy presented something at an IETF (San Diego, Salt Lake, > > Yokohama???, I do recall but I cannot find record of that presentation > > either in the minutes or the list archives). > > Salt Lake, I believe. I couldn't find a record of it either, other than in my > fuzzy memory. Yokohama, I think, but might have been Salt Lake, it's been a while. In any case: there was a general issue and a specific issue. I can try to dig out my notes from that era, but IIRC, the specific issue was some bad interaction that would result from use the NXT from a cached positive query to generate a later negative response without going back to the authoritative name server. At first blush that problem would appear to be specific to opt-foo, but given that NSEC RRs sometimes appear in positive responses for wildcard data, it may still apply. The more general issue was that Roy and I (Roy, correct me if I'm getting this wrong) came to the conclusion that the semantics of all this stuff is complex and fragile enough that a recursive name server really ought to stay out of the semantics entirely and just pass the data it got from the authoritative source along to the verifying resolver without changing anything other than the TTLs. This is basicly just another application of the anti-complexity argument. IIRC, the text to which David is objecting is a recommendation that came out of the ISI "DS" workshop in September of, um, 2002? There was an Editors' Note in the doc next to that text for a long time asking the WG whether that recommendation should be in the draft at all, but apparently nobody ever read that note. :) So, in sum: I happen to agree with the text in question as it stands now, but would not object to dropping it entirely. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 15:10:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11827 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 15:10:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVb6P-0008CE-Va for namedroppers-data@psg.com; Wed, 02 Jun 2004 19:08:41 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVb6M-0008Bm-Np for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 19:08:38 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 3131631EEFE; Wed, 2 Jun 2004 21:08:41 +0200 (CEST) In-Reply-To: <200406021422.12551.davidb@verisignlabs.com> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021120.29691.davidb@verisignlabs.com> <6D50AC72-B4B9-11D8-9A2A-000393DA2D46@ripe.net> <200406021422.12551.davidb@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <423F46F6-B4C8-11D8-9A2A-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman <olaf@ripe.net> Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 21:08:40 +0200 To: David Blacka <davidb@verisignlabs.com> X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Yes, although I too would like it to be a MUST NOT. > It occurs to me that, unlike most of the MUSTs and MUST NOTs in the > DNSSECbis > documents, this could not be enforced (the others are generally > "enforced" by > the responses not validating). > > The MUST NOT in this case is intended to preserve a number of end-to-end properties of the namespace. Essentially if your cache follows this behavior you can trust it. If you cannot trust your cache to perform this behavior you are in for inconsistencies and troubleshooting headache, if you then have a "MUST NOT" to point to you may be able to convince your cache supplier he is doing something _bad_. Would you consent with text that explains the reasoning for the MUST NOT create negative responses using NSECs obtained from other queries. Allowing the exeption of using an NSEC that was stored for the same name and class but for another type to proof the nonexistence of a given type? --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 15:10:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11845 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 15:10:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVb6Y-0008DV-HG for namedroppers-data@psg.com; Wed, 02 Jun 2004 19:08:50 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVb6P-0008C3-CS for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 19:08:41 +0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i52J8e52017886 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 15:08:40 -0400 (EDT) Received: from equal-rites.mit.edu (EQUAL-RITES.MIT.EDU [18.18.1.59]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i52J8doL004099 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 15:08:40 -0400 (EDT) Received: (from ghudson@localhost) by equal-rites.mit.edu (8.12.9) id i52J8dOd014629; Wed, 2 Jun 2004 15:08:39 -0400 Date: Wed, 2 Jun 2004 15:08:39 -0400 Message-Id: <200406021908.i52J8dOd014629@equal-rites.mit.edu> From: Greg Hudson <ghudson@MIT.EDU> To: namedroppers@ops.ietf.org Subject: A binary online attack on NSEC2 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (Apologies if this turns out to be half-baked.) Let's say I want to find all the records between a.example.com and z.example.com, neither of which exist, and example.com is using NSEC2. I query for a.example.com and z.example.com, and note the NSEC2 records. If I get the same NSEC2 records, I know there are no records between a and z, and I'm done. If I'm not done, I query for m.example.com. If I get the same NSEC2 record as I did for a, I can discard half the search space; likewise if I get the same NSEC2 record as I got for z. If I get a third, different NSEC2 record, then I know there are records in both halves of the search space. If m.example.com actually exists, I note that down and query l.example.com and n.example.com to find an NSEC2 record. To partition the search space between y.example.com and z.example.com, I query for ym.example.com. (There are, of course, other valid characters in DNS labels besides [a-z], but that's a detail.) As far as I know, this attack should be totally practical, easy to parallelize (each time you find that there are records in both half of the search space, you can split the resulting problem between two machines with no further communication between the two until you assemble the list of records at the end), no more easily prevented than an NSEC walk, and should generate more load than an NSEC 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 Wed Jun 2 15:27:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13659 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 15:27:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVbKu-000Aiw-6s for namedroppers-data@psg.com; Wed, 02 Jun 2004 19:23:40 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVbKr-000AiE-P5 for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 19:23:37 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i52JNIfM071498; Wed, 2 Jun 2004 21:23:19 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52JNEmY002541; Wed, 2 Jun 2004 21:23:14 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i52JNESe002538; Wed, 2 Jun 2004 21:23:14 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 2 Jun 2004 21:23:14 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Greg Hudson <ghudson@MIT.EDU> cc: namedroppers@ops.ietf.org Subject: Re: A binary online attack on NSEC2 In-Reply-To: <200406021908.i52J8dOd014629@equal-rites.mit.edu> Message-ID: <Pine.LNX.4.58.0406022116580.1159@elektron.atoom.net> References: <200406021908.i52J8dOd014629@equal-rites.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 2 Jun 2004, Greg Hudson wrote: > (Apologies if this turns out to be half-baked.) > > Let's say I want to find all the records between a.example.com and > z.example.com, neither of which exist, and example.com is using NSEC2. > > I query for a.example.com and z.example.com, and note the NSEC2 > records. If I get the same NSEC2 records, I know there are no records > between a and z, and I'm done. > > If I'm not done, I query for m.example.com. If I get the same NSEC2 > record as I did for a, I can discard half the search space; likewise > if I get the same NSEC2 record as I got for z. If I get a third, > different NSEC2 record, then I know there are records in both halves > of the search space. If m.example.com actually exists, I note that > down and query l.example.com and n.example.com to find an NSEC2 > record. > > To partition the search space between y.example.com and z.example.com, > I query for ym.example.com. > > (There are, of course, other valid characters in DNS labels besides > [a-z], but that's a detail.) > > As far as I know, this attack should be totally practical, easy to > parallelize (each time you find that there are records in both half of > the search space, you can split the resulting problem between two > machines with no further communication between the two until you > assemble the list of records at the end), no more easily prevented > than an NSEC walk, and should generate more load than an NSEC walk. This is what I wrote in a response earlier on: "What Ben was referring (Ben ?) to is that the canonically ordered list of ownername(X) and its projected canonically ordered list of HASH(ownername(X)) are non-linear. In other words, X NSEC Y and HASH(X) NSEC2 HASH (Y) have different Y for the same X. If it were linear, binary search would make hashing purposes trivially obsolete. If it were linear, it is not a one-way-hash function. If a cache does want to convert NSEC to NSEC2, it needs knowledge of the entire zone, the zones' private key, hash each individual owner name, rebuild the NSEC2 chain using the ordered hashed ownernames and resign each individual 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 Wed Jun 2 15:31:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13867 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 15:31:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVbQP-000BpR-4r for namedroppers-data@psg.com; Wed, 02 Jun 2004 19:29:21 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVbQO-000Bp0-8T for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 19:29:20 +0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i52JTD52024742; Wed, 2 Jun 2004 15:29:14 -0400 (EDT) Received: from equal-rites.mit.edu (EQUAL-RITES.MIT.EDU [18.18.1.59]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i52JTBoL005320; Wed, 2 Jun 2004 15:29:11 -0400 (EDT) Received: (from ghudson@localhost) by equal-rites.mit.edu (8.12.9) id i52JTBaZ014749; Wed, 2 Jun 2004 15:29:11 -0400 Subject: Re: A binary online attack on NSEC2 From: Greg Hudson <ghudson@MIT.EDU> To: roy@dnss.ec Cc: namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.58.0406022116580.1159@elektron.atoom.net> References: <200406021908.i52J8dOd014629@equal-rites.mit.edu> <Pine.LNX.4.58.0406022116580.1159@elektron.atoom.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1086204551.13764.22.camel@equal-rites.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 02 Jun 2004 15:29:11 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2004-06-02 at 15:23, roy@dnss.ec wrote: > On Wed, 2 Jun 2004, Greg Hudson wrote: > > > (Apologies if this turns out to be half-baked.) Further consideration suggests that it is, sorry. (a.example.com would not generally have the same NSEC2 record as b.example.com even if there are no records between 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 Wed Jun 2 15:50:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14911 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 15:50:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVbgp-000EDk-MJ for namedroppers-data@psg.com; Wed, 02 Jun 2004 19:46:19 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVbgm-000EDL-Gm for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 19:46:16 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 15:46:14 -0400 id 00048BE4.40BE2E86.00000E88 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 15:46:15 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021422.12551.davidb@verisignlabs.com> <423F46F6-B4C8-11D8-9A2A-000393DA2D46@ripe.net> In-Reply-To: <423F46F6-B4C8-11D8-9A2A-000393DA2D46@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021546.15439.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 3:08 pm, Olaf Kolkman wrote: > > Yes, although I too would like it to be a MUST NOT. > > > > It occurs to me that, unlike most of the MUSTs and MUST NOTs in the > > DNSSECbis > > documents, this could not be enforced (the others are generally > > "enforced" by > > the responses not validating). > > The MUST NOT in this case is intended to preserve a number of > end-to-end properties of the namespace. Essentially if your cache > follows this behavior you can trust it. If you cannot trust your cache > to perform this behavior you are in for inconsistencies and > troubleshooting headache, if you then have a "MUST NOT" to point to you > may be able to convince your cache supplier he is doing something > _bad_. > > Would you consent with text that explains the reasoning for the MUST > NOT create negative responses using NSECs obtained from other queries. > Allowing the exeption of using an NSEC that was stored for the same > name and class but for another type to proof the nonexistence of a > given type? I would be happy with either dropping section 4.5 entirely, or with replacing it with "MUST NOT create negative responses..." language, or with the same language using "SHOULD NOT". I think that if the new language could contains reasons why, that would be much better. To be clear: I do not think (at all) that caches should be synthesizing negative responses or wildcards. Nor do I think that the caching scheme outlined in the current section 4.5 won't work or doesn't present some decent advantages to more complex schemes. I just didn't think that the DNSSECbis documents should be in the position of telling implementers how to implement their cache so explicitly and without justification. -- 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 Wed Jun 2 16:00:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15754 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 16:00:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVbrQ-000Fbd-5g for namedroppers-data@psg.com; Wed, 02 Jun 2004 19:57:16 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVbrP-000FbK-7T for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 19:57:15 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 02 Jun 2004 15:57:13 -0400 id 00138A70.40BE3119.000010B1 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 2 Jun 2004 15:57:14 -0400 User-Agent: KMail/1.6.2 References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021120.29691.davidb@verisignlabs.com> <20040602190347.424E442B2@thrintun.hactrn.net> In-Reply-To: <20040602190347.424E442B2@thrintun.hactrn.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021557.14431.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,OPT_IN_CAPS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 June 2004 3:03 pm, Rob Austein wrote: > > > > I dimly remember that we determined something more "serious" > > > > would result if caches synthesize negative answers, but I cannot > > > > remember (if I ever knew) what it was. It was something that > > > > fell out of the Opt-In discussion, however. I am hoping that we > > > > can re-discover it. > > > > > > Rob and/or Roy presented something at an IETF (San Diego, Salt Lake, > > > Yokohama???, I do recall but I cannot find record of that presentation > > > either in the minutes or the list archives). > > > > Salt Lake, I believe. I couldn't find a record of it either, other than > > in my fuzzy memory. > > Yokohama, I think, but might have been Salt Lake, it's been a while. > In any case: there was a general issue and a specific issue. > > I can try to dig out my notes from that era, but IIRC, the specific > issue was some bad interaction that would result from use the NXT from > a cached positive query to generate a later negative response without > going back to the authoritative name server. At first blush that > problem would appear to be specific to opt-foo, but given that NSEC > RRs sometimes appear in positive responses for wildcard data, it may > still apply. What I've been trying to figure out is if we discovered actual breakage. That a user of a cache might have to wait the minimum TTL (or NSEC TTL) in order to see a change to a zone is undesirable, but not, IMHO, breakage. If your notes indicate something more serious than this, then the WG should see them. If anyone disagrees with my not characterizing this as "breakage", please say so. > The more general issue was that Roy and I (Roy, correct me if I'm > getting this wrong) came to the conclusion that the semantics of all > this stuff is complex and fragile enough that a recursive name server > really ought to stay out of the semantics entirely and just pass the > data it got from the authoritative source along to the verifying > resolver without changing anything other than the TTLs. This is > basicly just another application of the anti-complexity argument. I would certainly agree that there are many reasons why a cache SHOULD NOT be synthesizing answers, not the least of which is that it is comparatively hard to do. > IIRC, the text to which David is objecting is a recommendation that > came out of the ISI "DS" workshop in September of, um, 2002? There > was an Editors' Note in the doc next to that text for a long time > asking the WG whether that recommendation should be in the draft at > all, but apparently nobody ever read that note. :) > > So, in sum: I happen to agree with the text in question as it stands > now, but would not object to dropping it entirely. I am curious if you disagree with any of the criticisms of the text that I posted to start this thread? -- 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 Wed Jun 2 18:06:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25289 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 18:06:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVdoZ-000IZS-Hb for namedroppers-data@psg.com; Wed, 02 Jun 2004 22:02:27 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVdoY-000IZD-MI for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 22:02:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C332113DED for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 22:02:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> of "Wed, 02 Jun 2004 15:57:14 -0400." <200406021557.14431.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 02 Jun 2004 22:02:25 +0000 Message-Id: <20040602220225.C332113DED@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... That a user of a cache might have to wait the minimum TTL (or NSEC > TTL) in order to see a change to a zone is undesirable, ... Now that we have the ability to sign the SOA, it could be that we should be including the SOA in every response, so that middleboxes can do a cache purge (or not, befitting local policy) whenever the SOA.SERIAL moves up. Noting that DNSSEC is still in search of its "killer app", being able to securely invalidate cached data in a distributed, lazy fashion could be one. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 2 19:38:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03516 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 19:38:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVfEd-000CwP-4b for namedroppers-data@psg.com; Wed, 02 Jun 2004 23:33:27 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVfEa-000Cvr-RY for namedroppers@ops.ietf.org; Wed, 02 Jun 2004 23:33:25 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id LAA06754 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 11:33:23 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i52NXNfw089836 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 11:33:23 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: NSEC2 on existing records From: Don Stokes <don@plugh.daedalus.co.nz> Date: Thu, 03 Jun 2004 11:33:23 +1200 Message-ID: <89835.1086219203@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Having just got my head around NSEC2, I wonder if the hash lookup of NSEC2 records is really required for names that do actually exist. That is, can we move the "this name exists but we don't have the RRset you asked for" function into the EXISTS function, rather than the NSEC2 function, and remove the type bitmap from the NSEC2 record? That is, given: @ ... foo A 10.0.0.1 RRSIG A <sig foo A> EXISTS A RRSIG EXISTS RRSIG EXISTS <sig foo EXISTS> bar A abc RRSIG A <sig bar A> MX 0 xyz RRSIG MX <sig bar MX> EXISTS A MX RRSIG EXISTS RRSIG EXISTS <sig bar MX> hash(@) NSEC2 hash(foo) SIG NSEC2 <sig hash(@) NSEC2> hash(foo) NSEC2 hash(bar) SIG NSEC2 <sig hash(foo) NSEC2> hash(bar) NSEC2 hash(@) SIG NSEC2 <sig hash(bar) NSEC2> The cases would be: Query "foo A" would return: foo A 10.0.0.1 RRSIG A <sig foo A> providing authenticated data; "foo MX ?" would return: foo EXISTS A RRSIG EXISTS RRSIG EXISTS <sig foo EXISTS> providing authenticated denial of the specific RRset, but without requiring a hash computation; "baz A ?" would return: hash(foo) NSEC2 hash(bar) providing authenticated denial of the name, requiring a hash computation. This approach is most useful to zones containing large numbers of unsecured delegations, as queries to such delegations don't incur a hash lookup to authenticate the lack of DS record. I also think this cuts down on the needed data in the two types of authenticated denial -- in the "name exists" case, you don't actually need the next domain pointer, and in the "no name" case, you don't need a types bitmap for a name you didn't actually query. Have I missed something important? -- 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 Wed Jun 2 20:04:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05359 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 20:04:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVfgl-000HWE-VQ for namedroppers-data@psg.com; Thu, 03 Jun 2004 00:02:31 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVfgk-000HVd-L5 for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 00:02:30 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id MAA06865 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 12:02:29 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i5302Tfw091379 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 12:02:29 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records In-Reply-To: Your message of "Thu, 03 Jun 2004 11:33:23 +1200." <89835.1086219203@toybsd.zl2tnm.gen.nz> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Thu, 03 Jun 2004 12:02:29 +1200 Message-ID: <91378.1086220949@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I wrote: >"baz A ?" would return: > > hash(foo) NSEC2 hash(bar) > >providing authenticated denial of the name, requiring a hash computation. That's: hash(foo) NSEC2 hash(bar) RRSIG NSEC2 <sig hash(foo) NSEC2> of course. -- 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 Wed Jun 2 21:12:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08331 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 21:12:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVgjD-0000zm-Iz for namedroppers-data@psg.com; Thu, 03 Jun 2004 01:09:07 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVgjC-0000zJ-6q for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 01:09:06 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id NAA07317 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 13:09:04 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i53194fw095406 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 13:09:04 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: NSEC+ and NO In-Reply-To: Your message of "Sun, 30 May 2004 12:49:32 +0100." <1036874717.1085921372@[192.168.100.5]> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Thu, 03 Jun 2004 13:09:04 +1200 Message-ID: <95405.1086224944@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh <alex@alex.org.uk> wrote: >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). Was thinking this one through last night, and yes there is. The problem is search lists. If I have a search list of "a.example" and "b.example", and I query "foo", I will look for: foo.a.example. foo.b.example. foo. If a.example is a secured zone, I need an authenticated yes or no for foo.a.example before I can proceed to foo.b.example. If a.example exists but doesn't provide authenticated denial, and foo.a.example does not exist, the search can not proceed when it should. Failing to provide the indication required to fall through to foo.b.example in this case constitutes "wrong data". If the search were to accept unsecured failure as a fall-through, there is data for foo.a.example, but somebody is hiding it from me, then I could erroneously fall through to foo.b.example when foo.a.example did exist. That too would constitute "wrong data". I don't think this affects TLD zones significantly; this could only affect the TLD if the TLD itself was placed in the search list. That could reasonably be described as a configuration error. Similarly, I would describe placing a domain that didn't exist into the search list should be considered a configuration error. (Note that in my example, the domains in the search list are assumed to exist.) IMAO of course. -- 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 Wed Jun 2 23:15:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14222 for <dnsext-archive@lists.ietf.org>; Wed, 2 Jun 2004 23:15:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVidX-000JpZ-BJ for namedroppers-data@psg.com; Thu, 03 Jun 2004 03:11:23 +0000 Received: from [129.9.80.165] (helo=fxshpr08.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVidU-000Joq-6m for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 03:11:20 +0000 Received: (from uucp@localhost) by fxshpr08.extra.daimlerchrysler.com (8.12.8/8.9.0) id i5333rsW020116 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 23:03:53 -0400 (EDT) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAtPaysN; Wed, 2 Jun 04 23:03:53 -0400 Received: from shconpr2-hme0.shdc.chrysler.com ([127.0.0.1]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2004060223111716413 for <namedroppers@ops.ietf.org>; Wed, 02 Jun 2004 23:11:17 -0400 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by shconpr2-hme0.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004060223111613734 for <namedroppers@ops.ietf.org>; Wed, 02 Jun 2004 23:11:16 -0400 Received: from shsecpr1-ce0.shdc.chrysler.com (shsecpr1-ce0.shdc.chrysler.com [53.231.128.176]) by shmrspr2-hme0.shdc.chrysler.com (8.12.10/8.12.10/daimlerchrysler-relay-1.1-kcd) with SMTP id i533BDYV025877 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 23:11:17 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.102.252]) by shsecpr1-ce0.shdc.chrysler.com (SMSSMTP 4.0.0.59) with SMTP id M2004060223111605814 for <namedroppers@ops.ietf.org>; Wed, 02 Jun 2004 23:11:16 -0400 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252]) by wokcdts1.is.chrysler.com (8.12.10/8.9.1) with ESMTP id i533BBJh001504 for <namedroppers@ops.ietf.org>; Wed, 2 Jun 2004 23:11:11 -0400 (EDT) Message-ID: <40BE96CF.6050305@daimlerchrysler.com> Date: Wed, 02 Jun 2004 23:11:11 -0400 From: Kevin Darcy <kcd@daimlerchrysler.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks References: <20040602220225.C332113DED@sa.vix.com> In-Reply-To: <20040602220225.C332113DED@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>... That a user of a cache might have to wait the minimum TTL (or NSEC >>TTL) in order to see a change to a zone is undesirable, ... >> >> > >Now that we have the ability to sign the SOA, it could be that we should >be including the SOA in every response, so that middleboxes can do a cache >purge (or not, befitting local policy) whenever the SOA.SERIAL moves up. > Could this "mandatory" SOA not serve double-duty as the "complementary negative caching record" I proposed in http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02197.html as a prerequisite for proper synthesis of QTYPE=* answers from cache? - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 00:04:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18309 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 00:04:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVjPe-00010d-M4 for namedroppers-data@psg.com; Thu, 03 Jun 2004 04:01:06 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVjPa-0000zU-QO for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 04:01:02 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 881BE42B2 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 00:01:01 -0400 (EDT) Date: Thu, 03 Jun 2004 00:01:01 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: <200406021557.14431.davidb@verisignlabs.com> <200406011037.59743.davidb@verisignlabs.com> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021120.29691.davidb@verisignlabs.com> <20040602190347.424E442B2@thrintun.hactrn.net> <200406021557.14431.davidb@verisignlabs.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040603040101.881BE42B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 2 Jun 2004 15:57:14 -0400, David Blacka wrote: > > I am curious if you disagree with any of the criticisms of the text that I > posted to start this thread? Universal translator dropped out on "stifles resolver innovation", but I mostly agree with the rest of your specific criticisms. I happen to think that the overall reduction in system complexity if everyone were to follow this this particular bit of implementation advice makes the advice worthwhile; YMMV. Other comments: 1) "Less efficient caching strategy" is a known cost of this approach. Well, it was known to me, and I think to Roy, at least. I would have said that I thought it was known to all the folks who were at the ISI DS workshop that recommended this approach, but you (David) were also there and this appears to have surprised you, so maybe this was not as widely understood as I thought. In any case, if we don't just drop this text entirely, we'll need to make it harder to miss this point. Send text. :) 2) SHOULD (as opposed to MUST) was deliberate. 3) Text of the Editors' Note that the WG (apparently) never noticed buried in -protocol-01 (March 2003): Editors' note: This is implementation advice which came out of discussions at various workshops and investigations into possible implementation issues with the (as yet unsettled) opt-in proposal. All of this advice has been discussed in WG meetings, and as far as the editors know these recommendations are not controversial, but it is up to the WG to decide whether this sort of implementation advice belongs in this document. 'Nuff said. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 01:07:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22948 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 01:07:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVkOe-000Aak-TN for namedroppers-data@psg.com; Thu, 03 Jun 2004 05:04:08 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVkOd-000AaB-3X for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 05:04:07 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id RAA08660 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 17:04:06 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i53545fw009315 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 17:04:05 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: Your message of "Wed, 02 Jun 2004 12:09:00 +0200." <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Thu, 03 Jun 2004 17:04:05 +1200 Message-ID: <9314.1086239045@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk roy@dnss.ec wrote: >200M queries a day may not shake an average TLD, but this exercise assumes >just 10 kiddies or spammers are interested in the co.uk zone. If NSEC2 or something a lot like it is deployed, I don't think this will get rid of spammers/scammers/script kiddies doing NSEC2 walks. If you download the entire NSEC2 chain you can do direct dictionary attacks on the zone, without requiring network traffic. Quick tests suggest that even my baby desktop box can do something like 6,000,000 SHA1 hashes per second. A local outfit here was selling second-hand PII/400s for about NZ$40 each -- at that kind of price I can get a *lot* of compute power for very little money. Out of curiosity, I did some experiments today, taking an old copy of a TLD zone, and subjecting it to tests for susceptibility to dictionary attacks. (Note that this is the reverse of actually performing the attack, and, uh, somewhat faster.) These tests suggest I could find 50% of names in a zone in the space of a few hours, on one box, using a fairly dumb dictionary attack on a stored list of hashes. More sophisticated attacks could get better hit rates for more time. While cranking up the NSECINFO iteration count would slow the ratbags down (at the expense of legitimate hash calculations), I fear that NSEC2 will not solve the problem of data mining via traversal of authenticated denial records. It'll be only a matter of time before even script-kiddies are doing NSEC2 traversals and launching dictionary attacks on large zones for fun and profit. -- 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 Thu Jun 3 01:16:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23723 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 01:16:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVkYO-000D5y-Ic for namedroppers-data@psg.com; Thu, 03 Jun 2004 05:14:12 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVkYN-000D5S-DR for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 05:14:11 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id RAA08704 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 17:14:10 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i535E9fw009924 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 17:14:09 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: Your message of "Wed, 02 Jun 2004 14:50:46 +0200." <40BDCD26.4050808@ripe.net> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Thu, 03 Jun 2004 17:14:09 +1200 Message-ID: <9923.1086239649@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> wrote: >ns.rp.secret-wg.org is a "secured reverse polish DNS calculator" you >can perform calculations by puting your 'stack' into a set of labels and >query under the rp.secret-wg.org domain. The answer is provided in a TXT >RR. Since there will always be an answer for each possible domain in the >rp.secret-wg.org domain (or a SERVFAIL in case of stack underflow) and >the namespace is infinite the NSEC RRs >that are automatically genrated to proof the NOERROR no-answer reply >always points back to the SOA. (You can use the same trick to prevent >NSEC walks) Um, but if I have: example. SOA ... ... a.example. NSEC example. ... b.example. NSEC example. ... what's to stop me forging replies for queries to b.example with a.example's (signed) NSEC record, thereby "proving" that b.example does not exist when it does? I thought that was the whole point of NSEC chaining. -- 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 Thu Jun 3 01:48:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26099 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 01:48:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVl3E-000Itp-5n for namedroppers-data@psg.com; Thu, 03 Jun 2004 05:46:04 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVl3C-000Isy-41 for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 05:46:02 +0000 Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i535juj09291; Thu, 3 Jun 2004 12:45:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i535iCae011689; Thu, 3 Jun 2004 12:44:13 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: <20040602220225.C332113DED@sa.vix.com> References: <20040602220225.C332113DED@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jun 2004 12:44:12 +0700 Message-ID: <11324.1086241452@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 02 Jun 2004 22:02:25 +0000 From: Paul Vixie <paul@vix.com> Message-ID: <20040602220225.C332113DED@sa.vix.com> | Now that we have the ability to sign the SOA, it could be that we should | be including the SOA in every response, so that middleboxes can do a cache | purge (or not, befitting local policy) whenever the SOA.SERIAL moves up. Please no, don't go anywhere near that. The SOA is way too coarse for this - all it indicates is that some RR in the zone has altered (or might have) - not that everything in the zone has changed. Using SOA that way would have the effect of defeating caching completely for any zone that is frequently updated (like one using dynamic DNS). If a zone wants to defeat caching, it already has that mechanism, it just sets the TTL on everything to 0, and it is done. Further, making a scheme like that in any way reliable, means having some way to force the "middle box" do do a query to the auth nameserver, so it can get that SOA in a response - if one assumes that it currently has cached all it needs for its operations, noting is going to cause that extra query of the auth servers in normal operations, until the TTLs expire anyway. 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 Thu Jun 3 03:22:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15385 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 03:22:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVmTE-0004rD-N0 for namedroppers-data@psg.com; Thu, 03 Jun 2004 07:17:00 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVmT9-0004ql-Vd for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 07:16:56 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i537GnoB079077; Thu, 3 Jun 2004 09:16:51 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i537Gjum013612; Thu, 3 Jun 2004 09:16:46 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i537Gir5013606; Thu, 3 Jun 2004 09:16:45 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 09:16:44 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Don Stokes <don@plugh.daedalus.co.nz> cc: namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: <9314.1086239045@toybsd.zl2tnm.gen.nz> Message-ID: <Pine.LNX.4.58.0406030911280.3943@elektron.atoom.net> References: <9314.1086239045@toybsd.zl2tnm.gen.nz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Don, That attack was mentioned in: > Date: Wed, 19 May 2004 15:40:01 +0200 (CEST) > From: roy@dnss.ec > To: namedroppers@ops.ietf.org > Subject: Re: Proposal to fix NSEC > > <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 > ... <SNIP> ... > 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. But this was handwaived by some. The crux of it was that with a enumeration of the reverse space, cache poking or other attacks the road to zone-enumeration is shorter, especially if your requirement is to just get to 70% to 75% of the entire zone. Roy On Thu, 3 Jun 2004, Don Stokes wrote: > > roy@dnss.ec wrote: > >200M queries a day may not shake an average TLD, but this exercise assumes > >just 10 kiddies or spammers are interested in the co.uk zone. > > If NSEC2 or something a lot like it is deployed, I don't think this will > get rid of spammers/scammers/script kiddies doing NSEC2 walks. > > If you download the entire NSEC2 chain you can do direct dictionary > attacks on the zone, without requiring network traffic. > > Quick tests suggest that even my baby desktop box can do something like > 6,000,000 SHA1 hashes per second. A local outfit here was selling > second-hand PII/400s for about NZ$40 each -- at that kind of price I can > get a *lot* of compute power for very little money. > > Out of curiosity, I did some experiments today, taking an old copy of a > TLD zone, and subjecting it to tests for susceptibility to dictionary > attacks. (Note that this is the reverse of actually performing the > attack, and, uh, somewhat faster.) > > These tests suggest I could find 50% of names in a zone in the space of > a few hours, on one box, using a fairly dumb dictionary attack on a > stored list of hashes. More sophisticated attacks could get better hit > rates for more time. While cranking up the NSECINFO iteration count > would slow the ratbags down (at the expense of legitimate hash > calculations), I fear that NSEC2 will not solve the problem of data > mining via traversal of authenticated denial records. It'll be only a > matter of time before even script-kiddies are doing NSEC2 traversals and > launching dictionary attacks on large zones for fun and profit. > > -- 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 03:29:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15818 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 03:29:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVmdT-0005xe-97 for namedroppers-data@psg.com; Thu, 03 Jun 2004 07:27:35 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVmdS-0005xO-3l for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 07:27:34 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 778FB1FE67; Thu, 3 Jun 2004 08:27:33 +0100 (BST) Date: Thu, 03 Jun 2004 08:27:15 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: number games. (really NSEC2 vs dictionary attacks) Message-ID: <4E0F619B6863A54FCA7B3D2E@[192.168.100.5]> In-Reply-To: <9314.1086239045@toybsd.zl2tnm.gen.nz> References: <9314.1086239045@toybsd.zl2tnm.gen.nz> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 03 June 2004 17:04 +1200 Don Stokes <don@plugh.daedalus.co.nz> wrote: >> 200M queries a day may not shake an average TLD, but this exercise >> assumes just 10 kiddies or spammers are interested in the co.uk zone. > > If NSEC2 or something a lot like it is deployed, I don't think this will > get rid of spammers/scammers/script kiddies doing NSEC2 walks. I may have missed it, but how do you get from the chain of hashed values (which you can download, but are uninteresting and ephemeral) to a list of domain names (assuming SHA-1 is one-way). 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 Thu Jun 3 03:52:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17410 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 03:52:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVmzG-0008Km-Gh for namedroppers-data@psg.com; Thu, 03 Jun 2004 07:50:06 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVmzF-0008KV-BM for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 07:50:05 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i537nwEp079352; Thu, 3 Jun 2004 09:49:58 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i537nqZ4014365; Thu, 3 Jun 2004 09:49:52 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i537nq2w014362; Thu, 3 Jun 2004 09:49:52 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 09:49:52 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Rob Austein <sra@isc.org> cc: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks In-Reply-To: <20040603040101.881BE42B2@thrintun.hactrn.net> Message-ID: <Pine.LNX.4.58.0406030928530.3943@elektron.atoom.net> References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021120.29691.davidb@verisignlabs.com> <20040602190347.424E442B2@thrintun.hactrn.net> <200406021557.14431.davidb@verisignlabs.com> <20040603040101.881BE42B2@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Rob Austein wrote: > At Wed, 2 Jun 2004 15:57:14 -0400, David Blacka wrote: > > > > I am curious if you disagree with any of the criticisms of the text that I > > posted to start this thread? > > Universal translator dropped out on "stifles resolver innovation", but > I mostly agree with the rest of your specific criticisms. I happen to > think that the overall reduction in system complexity if everyone were > to follow this this particular bit of implementation advice makes the > advice worthwhile; YMMV. > > Other comments: > > 1) "Less efficient caching strategy" is a known cost of this approach. > Well, it was known to me, and I think to Roy, at least. Yes. A more efficient caching strategy was in the order of "premature optimization is the root of all evil" [1] > I would have said that I thought it was known to all the folks who > were at the ISI DS workshop that recommended this approach, but you > (David) were also there and this appears to have surprised you, so > maybe this was not as widely understood as I thought. In any case, > if we don't just drop this text entirely, we'll need to make it > harder to miss this point. Send text. :) Roy [1] Hoare, Tony. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." Quoted in Donald E. Knuth, Literate Programming (Stanford, California: Center for the Study of Language and Information, 1992), 276. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 04:35:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19580 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 04:35:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVnf0-000DxZ-Bq for namedroppers-data@psg.com; Thu, 03 Jun 2004 08:33:14 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVneh-000DvP-DL for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 08:32:55 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5384GSV079523; Thu, 3 Jun 2004 10:04:16 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5384C47014541; Thu, 3 Jun 2004 10:04:13 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5384CGv014538; Thu, 3 Jun 2004 10:04:12 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 10:04:12 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Alex Bligh <alex@alex.org.uk> cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: <Pine.LNX.4.58.0406030951170.3943@elektron.atoom.net> Message-ID: <Pine.LNX.4.58.0406031003000.3943@elektron.atoom.net> References: <9314.1086239045@toybsd.zl2tnm.gen.nz> <4E0F619B6863A54FCA7B3D2E@[192.168.100.5]> <Pine.LNX.4.58.0406030951170.3943@elektron.atoom.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004 roy@dnss.ec wrote: > On Thu, 3 Jun 2004, Alex Bligh wrote: > > > --On 03 June 2004 17:04 +1200 Don Stokes <don@plugh.daedalus.co.nz> wrote: > > > > >> 200M queries a day may not shake an average TLD, but this exercise > > >> assumes just 10 kiddies or spammers are interested in the co.uk zone. > > > > > > If NSEC2 or something a lot like it is deployed, I don't think this will > > > get rid of spammers/scammers/script kiddies doing NSEC2 walks. > > > > I may have missed it, but how do you get from the chain of hashed values > > (which you can download, but are uninteresting and ephemeral) to a > > list of domain names (assuming SHA-1 is one-way). > > It was suggested by Don and me to do a dictionary attack to find a > collision with a hashed label. It might even be feasible to do a brute > force on labels with 6 characters, considering 37 possible values for a > character. > > A device capable of performing 6000000 hash functions per second (quoting > Don) walks a space of 37^6 in about 7 minutes. > > local hash functions is a wee bit more efficient then online querying PS. That's why Ben added an iterations field to NSECINFO to up the cost. 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 Thu Jun 3 04:36:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19670 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 04:36:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVncj-000Dju-28 for namedroppers-data@psg.com; Thu, 03 Jun 2004 08:30:53 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVnch-000DjW-PH for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 08:30:52 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id UAA10145 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 20:30:50 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i538Uofw023089 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 20:30:50 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: Your message of "Thu, 03 Jun 2004 08:27:15 +0100." <4E0F619B6863A54FCA7B3D2E@[192.168.100.5]> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Thu, 03 Jun 2004 20:30:50 +1200 Message-ID: <23088.1086251450@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh <alex@alex.org.uk> wrote: >> If NSEC2 or something a lot like it is deployed, I don't think this will >> get rid of spammers/scammers/script kiddies doing NSEC2 walks. > >I may have missed it, but how do you get from the chain of hashed values >(which you can download, but are uninteresting and ephemeral) to a >list of domain names (assuming SHA-1 is one-way). By dictionary attack. I'm not saying they get the full, complete zone. NSEC2 is proof against that. What I am saying is that walking an NSEC2 chain is still useful to the sorts of people we've been denying AXFRs to. The most obvious, but not the only, use for the chain is a dictionary attack -- you can easily get 50-80% of names in a typical TLD zone via a straight dictionary attack, given a local copy of the complete NSEC2 chain and surprisingly little money's worth of compute power. roy@dnss.ec wrote: >PS. That's why Ben added an iterations field to NSECINFO to up the cost. Unfortunately, it ups the cost to everyone else, too. -- 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 Thu Jun 3 05:03:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21549 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 05:03:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVo5F-000I0Q-J4 for namedroppers-data@psg.com; Thu, 03 Jun 2004 09:00:21 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVo5E-000Hzn-2o for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 09:00:20 +0000 Received: from wds1.nominet.org.uk (notes1.nominet.org.uk [213.248.197.128]) by mx1.nominet.org.uk (Postfix) with ESMTP id 6EAEAE80FA; Thu, 3 Jun 2004 10:00:19 +0100 (BST) In-Reply-To: <23088.1086251450@toybsd.zl2tnm.gen.nz> To: Don Stokes <don@plugh.daedalus.co.nz> Cc: namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: <OF696837A5.B92D0377-ON80256EA8.00304662-80256EA8.00319564@nominet.org.uk> From: "Jay Daley" <td@nominet.org.uk> Date: Thu, 3 Jun 2004 10:00:18 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5|September 26, 2003) at 06/03/2004 10:00:18 AM, Serialize complete at 06/03/2004 10:00:18 AM Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Don don wrote on 03/06/2004 09:30:50: > What I am saying is that walking an NSEC2 chain is still useful to the > sorts of people we've been denying AXFRs to. The most obvious, but not > the only, use for the chain is a dictionary attack -- you can easily > get 50-80% of names in a typical TLD zone via a straight dictionary > attack, given a local copy of the complete NSEC2 chain and surprisingly > little money's worth of compute power. I don't have any analysis to back this up but I doubt very much if any dictionary attack can get anything like the percentages you quote, probably much less than 50%. Once most of the single word DNs have gone most people fall back to double word DNs (e.g. don-systems.co.uk) or other pairings (ds-systems.co.uk) and the variety of ways in which this is done increases the search scope enormously. The susceptibility of a TLD zone to dictionary attack may well be inversely proportional to its size. 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 Thu Jun 3 05:17:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22570 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 05:17:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVoJc-000Ju4-LI for namedroppers-data@psg.com; Thu, 03 Jun 2004 09:15:12 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVoJa-000Jtl-AP for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 09:15:10 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id B133E4EEE8; Thu, 3 Jun 2004 11:15:09 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 60C824E679; Thu, 3 Jun 2004 11:15:09 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i539F9Q2011105; Thu, 3 Jun 2004 11:15:09 +0200 Date: Thu, 3 Jun 2004 11:15:09 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Derek Atkins <derek@ihtfp.com> Cc: davidb@verisignlabs.com, namedroppers@ops.ietf.org Subject: Re: number games. Re: WGLC for DNSSECbis docs Message-Id: <20040603111509.413cb1c4.olaf@ripe.net> In-Reply-To: <sjmiseakndv.fsf@dogbert.ihtfp.org> References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> <200406021055.40065.davidb@verisignlabs.com> <sjmiseakndv.fsf@dogbert.ihtfp.org> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000016 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8f135944361d7d4b93197670716df79b X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 02 Jun 2004 11:09:16 -0400 Derek Atkins <derek@ihtfp.com> wrote: > Hmm.. Then -nsec needs to get corrected because it's less clear there. > The -nsec spec says you only need NSECs for authoritative data (of > which an NS delegation is not). The details are further addressed in proto. These issues have been the subject of a number of questions that where posted to the mailinglist over the last few months. Let us not re-iterate. Relevant text is in proto-2.3 The bitmap for the NSEC RR at a delegation point requires special attention. Bits corresponding to the delegation NS RRset and the RR types for which the parent zone has authoritative data MUST be set to 1; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be set to 0. in proto-3.1.4: If no DS RRset is present at the delegation point, the name server MUST return both the NSEC RR which proves that the DS RRset is not present and the NSEC RR's associated RRSIG RR(s) along with the NS RRset. The name server MUST place the NS RRset before the NSEC RRset and its associated RRSIG RR(s). in proto-3.1.5 NSEC RRs appear in both the parent and child zones at a zone cut, and are authoritative data in both the parent and child zones. The parental and child NSEC RRs at a zone cut are never identical to each other, since the NSEC RR in the child zone's apex will always indicate the presence of the child zone's SOA RR while the parental NSEC RR at the zone cut will never indicate the presence of an SOA RR. As with any other authoritative RRs, NSEC RRs MUST be included in zone transfers of the zone in which they are authoritative data: the parental NSEC RR at a zone cut MUST be included zone transfers of the parent zone, while the NSEC at the zone apex of the child zone MUST be included in zone transfers of the child zone. and in -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 05:26:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19582 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 04:35:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVnek-000Dw3-EW for namedroppers-data@psg.com; Thu, 03 Jun 2004 08:32:58 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVneg-000DvP-71 for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 08:32:54 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5382gU4079509; Thu, 3 Jun 2004 10:02:43 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5382dch014512; Thu, 3 Jun 2004 10:02:39 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5382dqa014509; Thu, 3 Jun 2004 10:02:39 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 10:02:39 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Alex Bligh <alex@alex.org.uk> cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: <4E0F619B6863A54FCA7B3D2E@[192.168.100.5]> Message-ID: <Pine.LNX.4.58.0406030951170.3943@elektron.atoom.net> References: <9314.1086239045@toybsd.zl2tnm.gen.nz> <4E0F619B6863A54FCA7B3D2E@[192.168.100.5]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Alex Bligh wrote: > --On 03 June 2004 17:04 +1200 Don Stokes <don@plugh.daedalus.co.nz> wrote: > > >> 200M queries a day may not shake an average TLD, but this exercise > >> assumes just 10 kiddies or spammers are interested in the co.uk zone. > > > > If NSEC2 or something a lot like it is deployed, I don't think this will > > get rid of spammers/scammers/script kiddies doing NSEC2 walks. > > I may have missed it, but how do you get from the chain of hashed values > (which you can download, but are uninteresting and ephemeral) to a > list of domain names (assuming SHA-1 is one-way). It was suggested by Don and me to do a dictionary attack to find a collision with a hashed label. It might even be feasible to do a brute force on labels with 6 characters, considering 37 possible values for a character. A device capable of performing 6000000 hash functions per second (quoting Don) walks a space of 37^6 in about 7 minutes. local hash functions is a wee bit more efficient then online querying 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 Thu Jun 3 06:53:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00397 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 06:53:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVpnD-0004Xt-Vt for namedroppers-data@psg.com; Thu, 03 Jun 2004 10:49:51 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVpnC-0004XX-7i for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 10:49:50 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i53AnkiO080585; Thu, 3 Jun 2004 12:49:46 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53Ang7K017157; Thu, 3 Jun 2004 12:49:42 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53AngsE017154; Thu, 3 Jun 2004 12:49:42 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 12:49:42 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Jay Daley <td@nominet.org.uk> cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: <OF696837A5.B92D0377-ON80256EA8.00304662-80256EA8.00319564@nominet.org.uk> Message-ID: <Pine.LNX.4.58.0406031149350.3943@elektron.atoom.net> References: <OF696837A5.B92D0377-ON80256EA8.00304662-80256EA8.00319564@nominet.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Jay Daley wrote: > Don > > don wrote on 03/06/2004 09:30:50: > > > What I am saying is that walking an NSEC2 chain is still useful to the > > sorts of people we've been denying AXFRs to. The most obvious, but not > > the only, use for the chain is a dictionary attack -- you can easily > > get 50-80% of names in a typical TLD zone via a straight dictionary > > attack, given a local copy of the complete NSEC2 chain and surprisingly > > little money's worth of compute power. > > I don't have any analysis to back this up but I doubt very much if any > dictionary attack can get anything like the percentages you quote, > probably much less than 50%. Once most of the single word DNs have gone > most people fall back to double word DNs (e.g. don-systems.co.uk) or > other pairings (ds-systems.co.uk) and the variety of ways in which this is > done increases the search scope enormously. The susceptibility of a TLD > zone to dictionary attack may well be inversely proportional to its size. Okay, I did a small proof of concept test. I took an arbitrary european TLD zone from november 2003. Number of registrations under TLD: 169209 Number of unique characters in label: 37 Bruteforce until 7 characters: 60153 hits (36%) Dictionary attack on the left 109056 labels: Wordlist of 3M words matched in the following order: word, %n$word, %n-$word, %n%n-$word, %n%n%n-$word, etc. Where %n is [0--9] This gets 80292 of the leftover 109056 labels So in total I get about 83%. 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 Thu Jun 3 07:04:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01020 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 07:04:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVpzd-0006VK-Ia for namedroppers-data@psg.com; Thu, 03 Jun 2004 11:02:41 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVpza-0006Um-Eo for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 11:02:38 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 89EE91FF82D; Thu, 3 Jun 2004 11:02:37 +0000 (GMT) Message-ID: <40BF054D.4040800@algroup.co.uk> Date: Thu, 03 Jun 2004 12:02:37 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: roy@dnss.ec Cc: Derek Atkins <derek@ihtfp.com>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: HEREIS "draft-vixie-dnssec-ter-00.txt" References: <20040602070859.0F50913951@sa.vix.com> <40BDBC70.90403@algroup.co.uk> <sjmfz9em3tu.fsf@dogbert.ihtfp.org> <Pine.LNX.4.58.0406021654210.21385@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406021654210.21385@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: > On Wed, 2 Jun 2004, Derek Atkins wrote: > > >>Ben Laurie <ben@algroup.co.uk> writes: >> >> >>>Paul Vixie wrote: >>> >>>> 2.5. It is possible that DNSSEC-TER metadata could be synthesized using >>>> only DNSSEC-BIS metadata. For example, an NSEC2 RR which offers the >>>> benefit of domain name confidentiality might use name hashes rather than >>>> domain names to bracket a range of name nonexistence, and it might be >>>> possible to compute these hashes using an existing NSEC RR. Therefore, >>>> a DNSSEC-TER specification might permit caching forwarders to synthesize >>>> NSEC2 RRs using NSEC RRs, thus improving the number of round trips >>>> otherwise called for in section 2.3 above. >>> >>>I'd note that you'd need a complete copy of the zone to do this. >> >>It's worse than that -- the signature needs to be recreated as well >>because you need to sign the hash-name instead of the original >>domain-name. > > > What Ben was referring (Ben ?) to is that the canonically ordered list of > ownername(X) and its projected canonically ordered list of > HASH(ownername(X)) are non-linear. In other words, X NSEC Y and HASH(X) > NSEC2 HASH (Y) have different Y for the same X. Indeed I was. 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 Thu Jun 3 07:12:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01686 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 07:12:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVq77-0007eO-4p for namedroppers-data@psg.com; Thu, 03 Jun 2004 11:10:25 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVq76-0007e2-1u for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 11:10:24 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 413071FF845; Thu, 3 Jun 2004 10:49:33 +0000 (GMT) Message-ID: <40BF023C.5030509@algroup.co.uk> Date: Thu, 03 Jun 2004 11:49:32 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: HEREIS "draft-vixie-dnssec-ter-00.txt" References: <20040602140801.3AA7A13DE9@sa.vix.com> In-Reply-To: <20040602140801.3AA7A13DE9@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>> 2.5. It is possible that DNSSEC-TER metadata could be synthesized >>> using only DNSSEC-BIS metadata. For example, an NSEC2 RR ... > > >>I'd note that you'd need a complete copy of the zone to do this. > > > that's true of NSEC2 as you've proposed it, but it may not be true of what > the chairs are calling "NSEC2/NO++". in any case the possibility of such > synthesis should be discussed when setting the parameters for going forward. True enough. > it could be that such synthesis would be a bad thing in all cases, since the > NSEC (or NSEC2/NO++) might say that only one of the RR types actually exists, > yet if you query for the other one, you get a positive (synthetic) answer. > > we do not need to select a particular "NSEC2/NO++" solution in order to prove > that one can exist. in <draft-vixie-dnssec-ter-##.txt> i intend only that we > show an understanding of the working conditions of the DNSSEC-TER designers. OK. A more serious issue with synthesis, though, is that it won't be signed (presumably). 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 Thu Jun 3 07:20:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02266 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 07:20:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVqDu-0008RQ-26 for namedroppers-data@psg.com; Thu, 03 Jun 2004 11:17:26 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVqDs-0008R3-Vq for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 11:17:25 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 94D701FF82D; Thu, 3 Jun 2004 11:17:23 +0000 (GMT) Message-ID: <40BF08C3.9060602@algroup.co.uk> Date: Thu, 03 Jun 2004 12:17:23 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Stokes <don@plugh.daedalus.co.nz> Cc: namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records References: <89835.1086219203@toybsd.zl2tnm.gen.nz> In-Reply-To: <89835.1086219203@toybsd.zl2tnm.gen.nz> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Don Stokes wrote: > Having just got my head around NSEC2, I wonder if the hash lookup of > NSEC2 records is really required for names that do actually exist. > > That is, can we move the "this name exists but we don't have the RRset > you asked for" function into the EXISTS function, rather than the NSEC2 > function, and remove the type bitmap from the NSEC2 record? > > That is, given: > > @ ... > foo A 10.0.0.1 > RRSIG A <sig foo A> > EXISTS A RRSIG EXISTS > RRSIG EXISTS <sig foo EXISTS> > bar A abc > RRSIG A <sig bar A> > MX 0 xyz > RRSIG MX <sig bar MX> > EXISTS A MX RRSIG EXISTS > RRSIG EXISTS <sig bar MX> > > hash(@) NSEC2 hash(foo) > SIG NSEC2 <sig hash(@) NSEC2> > hash(foo) NSEC2 hash(bar) > SIG NSEC2 <sig hash(foo) NSEC2> > hash(bar) NSEC2 hash(@) > SIG NSEC2 <sig hash(bar) NSEC2> > > The cases would be: > > Query "foo A" would return: > > foo A 10.0.0.1 > RRSIG A <sig foo A> > > providing authenticated data; > > "foo MX ?" would return: > > foo EXISTS A RRSIG EXISTS > RRSIG EXISTS <sig foo EXISTS> > > providing authenticated denial of the specific RRset, but without > requiring a hash computation; > > "baz A ?" would return: > > hash(foo) NSEC2 hash(bar) > > providing authenticated denial of the name, requiring a hash computation. > > This approach is most useful to zones containing large numbers of > unsecured delegations, as queries to such delegations don't incur a hash > lookup to authenticate the lack of DS record. > > I also think this cuts down on the needed data in the two types of > authenticated denial -- in the "name exists" case, you don't actually > need the next domain pointer, and in the "no name" case, you don't need > a types bitmap for a name you didn't actually query. > > Have I missed something important? The downside of this proposal is that currently EXISTS records are only needed to prove closest enclosers that otherwise don't exist. You'd be introducing them for every name in the zone - and you'd still have to have NSEC2 records. The upside, if I understand, is that for the case of proving existence you'd save the size of the hash of the next domain name in the response. Not sure the upside is worth the downside. 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 Thu Jun 3 07:31:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02908 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 07:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVqPI-0009rB-EN for namedroppers-data@psg.com; Thu, 03 Jun 2004 11:29:12 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVqPH-0009qj-KC for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 11:29:11 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i53BT7rg080965; Thu, 3 Jun 2004 13:29:07 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53BT3Ai017851; Thu, 3 Jun 2004 13:29:03 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53BT3ln017848; Thu, 3 Jun 2004 13:29:03 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 13:29:03 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records In-Reply-To: <40BF08C3.9060602@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> References: <89835.1086219203@toybsd.zl2tnm.gen.nz> <40BF08C3.9060602@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Ben Laurie wrote: > Don Stokes wrote: > > The downside of this proposal is that currently EXISTS records are only > needed to prove closest enclosers that otherwise don't exist. You'd be > introducing them for every name in the zone - and you'd still have to > have NSEC2 records. The upside, if I understand, is that for the case of > proving existence you'd save the size of the hash of the next domain > name in the response. Not sure the upside is worth the downside. There has been an alternative proposed for the closest encloser issue. That was to add NSEC2s (instead of EXIST) for every emtpty non-terminal. Another alternative would be the hashing of individual labels, and truncate hashes to accomodate size. 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 Thu Jun 3 07:34:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03079 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 07:34:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVqRy-000ACd-1i for namedroppers-data@psg.com; Thu, 03 Jun 2004 11:31:58 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVqRv-000ACI-6f for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 11:31:55 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i53BVqxB068453 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 11:31:54 GMT (envelope-from roy+dated+1088854309.ebf43d@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i53BVnso001615 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 12:31:51 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i53BVnH9012494 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 12:31:49 +0100 (BST) (envelope-from roy+dated+1088854309.ebf43d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i53BVnt6012493 for namedroppers@ops.ietf.org; Thu, 3 Jun 2004 12:31:49 +0100 (BST) (envelope-from roy+dated+1088854309.ebf43d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Thu, 03 Jun 2004 12:31:47 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16575.3106.634210.548309@giles.gnomon.org.uk> Date: Thu, 3 Jun 2004 12:31:46 +0100 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: Derek Atkins <derek@ihtfp.com>, davidb@verisignlabs.com, namedroppers@ops.ietf.org Subject: Re: number games. Re: WGLC for DNSSECbis docs In-Reply-To: <20040603111509.413cb1c4.olaf@ripe.net> References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> <200406021055.40065.davidb@verisignlabs.com> <sjmiseakndv.fsf@dogbert.ihtfp.org> <20040603111509.413cb1c4.olaf@ripe.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Olaf" == Olaf M Kolkman <olaf@ripe.net> writes: Olaf> The details are further addressed in proto. These issues Olaf> have been the subject of a number of questions that where Olaf> posted to the mailinglist over the last few months. Let us Olaf> not re-iterate. I have to say that as someone reading the doc set for the first time, I this point confusing. -protocol clearly states (2.3) that delegation points require NSEC records. But -records states that the NSEC RR contains the owner name of the next authoritate RRset (section 4, and again in 4.1.1) and as Derek points out this is not true, since an insecure delegation contains no authoritative data. This seems to me to be an editorial error in -records -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 08:16:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05374 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 08:16:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVr4a-000EwI-E0 for namedroppers-data@psg.com; Thu, 03 Jun 2004 12:11:52 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVr4Z-000Evu-1l for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 12:11:51 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 29E131FF82D; Thu, 3 Jun 2004 12:11:50 +0000 (GMT) Message-ID: <40BF1585.3050108@algroup.co.uk> Date: Thu, 03 Jun 2004 13:11:49 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: roy@dnss.ec Cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records References: <89835.1086219203@toybsd.zl2tnm.gen.nz> <40BF08C3.9060602@algroup.co.uk> <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: > On Thu, 3 Jun 2004, Ben Laurie wrote: > > >>Don Stokes wrote: >> >>The downside of this proposal is that currently EXISTS records are only >>needed to prove closest enclosers that otherwise don't exist. You'd be >>introducing them for every name in the zone - and you'd still have to >>have NSEC2 records. The upside, if I understand, is that for the case of >>proving existence you'd save the size of the hash of the next domain >>name in the response. Not sure the upside is worth the downside. > > > There has been an alternative proposed for the closest encloser issue. > That was to add NSEC2s (instead of EXIST) for every emtpty non-terminal. I don't really understand the advantage of this proposal. > Another alternative would be the hashing of individual labels, and > truncate hashes to accomodate size. Hash truncation is fine, so long as it is done carefully. 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 Thu Jun 3 08:21:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05626 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 08:21:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVrC6-000FhT-By for namedroppers-data@psg.com; Thu, 03 Jun 2004 12:19:38 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVrC2-000FgG-9s for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 12:19:34 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i53CIoCs016965 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 08:19:00 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i53CI34A029146 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 08:18:03 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: number games. (really NSEC2 vs dictionary attacks) Date: Thu, 3 Jun 2004 08:18:03 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <Pine.LNX.4.58.0406030951170.3943@elektron.atoom.net> X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > > It was suggested by Don and me to do a dictionary attack to find a > collision with a hashed label. It might even be feasible to do a brute > force on labels with 6 characters, considering 37 possible values for a > character. > > A device capable of performing 6000000 hash functions per second (quoting > Don) walks a space of 37^6 in about 7 minutes. > > local hash functions is a wee bit more efficient then online querying > Also take into consideration that a random non-existant response will contain one or more NSEC2 RRs, and each NSEC2 RRs has 2 hash values of valid names. An attacker may get a large portion of the (hashed) namespace by doing random queries like this without too much effort. They still need to do the dictionary attack however. I also have a question about the salt field in the original spec. I still am not sure it is useful. A determined attacker will just take the salt value anyway and use that. Why not just have the hash be the FQDN? For example: Hash(www.example.com).example.com. Mainly I'm thinking of ways to reduce the need for the NSECINFO RR and move the remaining fields (hash algo and iterations) into the NSEC2 RR. Scott > 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 Thu Jun 3 08:22:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05664 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 08:22:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVrDO-000Fxo-AZ for namedroppers-data@psg.com; Thu, 03 Jun 2004 12:20:58 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVrDN-000Fwt-10 for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 12:20:57 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i53CKoLp081378; Thu, 3 Jun 2004 14:20:50 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53CKk9A018743; Thu, 3 Jun 2004 14:20:46 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53CKkNW018737; Thu, 3 Jun 2004 14:20:46 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 14:20:46 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: roy@dnss.ec, Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records In-Reply-To: <40BF1585.3050108@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406031412171.3943@elektron.atoom.net> References: <89835.1086219203@toybsd.zl2tnm.gen.nz> <40BF08C3.9060602@algroup.co.uk> <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> <40BF1585.3050108@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Ben Laurie wrote: > roy@dnss.ec wrote: > > On Thu, 3 Jun 2004, Ben Laurie wrote: > > > > > >>Don Stokes wrote: > >> > >>The downside of this proposal is that currently EXISTS records are only > >>needed to prove closest enclosers that otherwise don't exist. You'd be > >>introducing them for every name in the zone - and you'd still have to > >>have NSEC2 records. The upside, if I understand, is that for the case of > >>proving existence you'd save the size of the hash of the next domain > >>name in the response. Not sure the upside is worth the downside. > > > > > > There has been an alternative proposed for the closest encloser issue. > > That was to add NSEC2s (instead of EXIST) for every emtpty non-terminal. > > I don't really understand the advantage of this proposal. With EXIST you'll have an NSEC2 record associated anyway. Why do both for the price of one. For instance: a.b.c A #a.b.c NSEC2 #... A NSEC2 RRSIG b.c EXIST #b.c NSEC2 #... EXIST NSEC2 RRSIG c EXIST #c NSEC2 #... EXIST NSEC2 RRSIG Could simply be: a.b.c A #a.b.c NSEC2 #... A NSEC2 RRSIG #b.c NSEC2 #... NSEC2 RRSIG #c NSEC2 #... NSEC2 RRSIG Your proposal introduces 4 records at every empty non-terminal (EXIST/SIG/NSEC2/SIG), while the other proposal introduces 2 records. > > Another alternative would be the hashing of individual labels, and > > truncate hashes to accomodate size. > > Hash truncation is fine, so long as it is done carefully. To compare, my proposal is: #a.#b.#c NSEC2 #.#.#. A NSEC2 RRSIG That saves space no ? 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 Thu Jun 3 08:31:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06165 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 08:31:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVrM3-000HI1-5v for namedroppers-data@psg.com; Thu, 03 Jun 2004 12:29:55 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVrM2-000HHc-5E for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 12:29:54 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i53CTnC6081463; Thu, 3 Jun 2004 14:29:49 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53CTjko019045; Thu, 3 Jun 2004 14:29:45 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53CTjvD019042; Thu, 3 Jun 2004 14:29:45 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 14:29:45 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Scott Rose <scottr@nist.gov> cc: namedroppers@ops.ietf.org Subject: RE: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> Message-ID: <Pine.LNX.4.58.0406031427490.3943@elektron.atoom.net> References: <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Scott Rose wrote: > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org > > > > It was suggested by Don and me to do a dictionary attack to find a > > collision with a hashed label. It might even be feasible to do a brute > > force on labels with 6 characters, considering 37 possible values for a > > character. > > > > A device capable of performing 6000000 hash functions per second (quoting > > Don) walks a space of 37^6 in about 7 minutes. > > > > local hash functions is a wee bit more efficient then online querying > > > > Also take into consideration that a random non-existant response will > contain one or more NSEC2 RRs, and each NSEC2 RRs has 2 hash values of valid > names. An attacker may get a large portion of the (hashed) namespace by > doing random queries like this without too much effort. They still need to > do the dictionary attack however. > > I also have a question about the salt field in the original spec. I still > am not sure it is useful. A determined attacker will just take the salt > value anyway and use that. Why not just have the hash be the FQDN? For > example: Hash(www.example.com).example.com. The salt value is a protection against pre-hashing. If you could prehash your dictionary, searching for collisions would be very fast. 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 Thu Jun 3 09:32:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09450 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 09:32:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVsFx-000Nk8-T4 for namedroppers-data@psg.com; Thu, 03 Jun 2004 13:27:41 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVsFw-000Njf-CS for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 13:27:40 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i53DQpCs021142 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 09:27:01 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i53DQG4A018235 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 09:26:16 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: "DNSEXT WG" <namedroppers@ops.ietf.org> Subject: RE: number games. (really NSEC2 vs dictionary attacks) Date: Thu, 3 Jun 2004 09:26:16 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGCEIMCKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <Pine.LNX.4.58.0406031427490.3943@elektron.atoom.net> X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: roy@dnss.ec [mailto:roy@dnss.ec] > > > > I also have a question about the salt field in the original > spec. I still > > am not sure it is useful. A determined attacker will just take the salt > > value anyway and use that. Why not just have the hash be the FQDN? For > > example: Hash(www.example.com).example.com. > > The salt value is a protection against pre-hashing. If you could prehash > your dictionary, searching for collisions would be very fast. > But that will only slow them down - a bit. Attackers will just do it in real time, and eventually will still be able to do it. The names remain the same, just the tag in front of it changes. They just need to stop and get the new salt whenever it is rolled over. The salt value becomes just another knob that admins need to worry about and most will do "whatever the default tool does". I'm not totally against adding the field. I think it would work, but considering how static most DNS names are, I don't know if it will help DNS as it does in other uses. Scott > 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 Thu Jun 3 09:51:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11503 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 09:51:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVsac-000PbE-Bm for namedroppers-data@psg.com; Thu, 03 Jun 2004 13:49:02 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVsab-000Paz-6n for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 13:49:01 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 1AC934EE5A; Thu, 3 Jun 2004 15:24:47 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A2B354EFBF; Thu, 3 Jun 2004 15:24:46 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i53DNRQ2001225; Thu, 3 Jun 2004 15:23:27 +0200 Date: Thu, 3 Jun 2004 15:23:27 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Don Stokes <don@plugh.daedalus.co.nz> Cc: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Message-Id: <20040603152327.6de24e15.olaf@ripe.net> In-Reply-To: <9923.1086239649@toybsd.zl2tnm.gen.nz> References: <40BDCD26.4050808@ripe.net> <9923.1086239649@toybsd.zl2tnm.gen.nz> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000722 / 0.0 / 0.0 / disabled X-RIPE-Signature: 939290ebaefcfb28d3e11f074334e196 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Um, but if I have: > > example. SOA ... > ... > a.example. NSEC example. ... > b.example. NSEC example. ... > > what's to stop me forging replies for queries to b.example with > a.example's (signed) NSEC record, thereby "proving" that b.example does > not exist when it does? Good point.... (would you really want to proof that 3+2 does not have an answer :-) ) The same reasoning applies to Roy's example where a zone is dynamically updated. An attacker could use NSECs hanging around from a previous 'version' of the zone in an active attack. In the case of an attack it is not the TTL that applies but the signature validity period of the SIG over the NSEC: as long as the signature is valid the NSEC can be reused. So even in the situation where you have fairly short TTLs you will be subject to attacks using the "old NSECs" since short signature validity lifetimes are very difficult to do in large dynamic zones. Back to this thread, I think the bottom line is that we would like our caches to be transperant to changes in the authoritative zone. Is this a suggestion we can all live with (taking the original text and extending it with an explanation)., A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. In most cases the appropriate cache index for the atomic entry will be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response form described in Section 3.1.3.2 the appropriate cache index will be the double <QNAME,QCLASS>. The reason for these recommendations is that between the initial query and the expiration of the data from the cache the authoritative data could have been changed, for instance through dynamic updates. There are two situation for which this is relevant. 1. By using the RRSIG record it is possible to deduce an answer is synthesized from a wildcard. The security aware caching nameserver could store this wildcard data and use it to generate responses to for queries other than the name for which the answer was first received. 2. NSEC RRs received to proof the nonexistence of a name could be re-usec by the cache to proof the non-existence of any name in the name range it spans. Although technically a wildcard to generate answers and an NSEC RR can be used to proof the nonexistence of names an types during the signature validity period, it seems prudent that that caches do not block newly appeared data. Caches following this recommendation will have a consistent view on the namespace. I am sure that native speakers can do a better job. -- Olaf (No hats) PS. I argued for MUST NOT language earlier in this thread. But because of the attack vector mentioned by Don allows for this "plain wrong behaviour" I now think SHOULD NOT language is more approriate. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 10:21:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15051 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 10:21:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVt2d-0002nS-7Y for namedroppers-data@psg.com; Thu, 03 Jun 2004 14:17:59 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVt2c-0002n4-5F for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 14:17:58 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8715451CF2; Thu, 3 Jun 2004 16:17:57 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 414E751CF0 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 16:17:57 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i53EHvQ2027991 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 16:17:57 +0200 Date: Thu, 3 Jun 2004 16:17:57 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: Graceful transition evaluation team volunteers Message-Id: <20040603161757.2c386dd7.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000013 / 0.0 / 0.0 / disabled X-RIPE-Signature: d6f52a4b1b48d45c696d222792c92722 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues With reference to http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html "To ease the process of getting consensus we would like to ask for a few (3 or so) volunteers to make a summary of the proposed solutions and analyze the pros and cons during the weekend. If you want to volunteer please reply to both of us within 24 hours after posting of this mail so we can appoint the volunteers by Thursday and have results on Monday." We have selected Peter Koch, Roy Arends and Jakob Schlyter from the available volunteers. They will create this inventory. Thanks to the others that volunteered. Rob, Peter and Jakob are tasked with: - Making an inventory of the proposed mechanisms to make a transition to future work on authenticated denial of existence. - List the known Pros and Cons, possibly provide new arguments, and possible security considerations of these mechanisms. - Provide a recommendation on a way forward that is least disruptive to the DNSSEC bis specifications as they stand and keep an open path to other methods for authenticated denial existence. -- Olaf & Olafur DNSSEXT Co Chairs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 11:36:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20861 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 11:36:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVuAw-000CEs-GX for namedroppers-data@psg.com; Thu, 03 Jun 2004 15:30:38 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVuAv-000CEc-BT for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 15:30:37 +0000 Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i53FUE6I016012; Thu, 3 Jun 2004 11:30:36 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i53FI6On002277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jun 2004 11:18:07 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i53FI55s022978; Thu, 3 Jun 2004 11:18:05 -0400 Subject: RE: number games. (really NSEC2 vs dictionary attacks) From: Greg Hudson <ghudson@MIT.EDU> To: Scott Rose <scottr@nist.gov> Cc: namedroppers@ops.ietf.org In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> References: <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1086275885.1468.204.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 03 Jun 2004 11:18:05 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2004-06-03 at 08:18, Scott Rose wrote: > I also have a question about the salt field in the original spec. I still > am not sure it is useful. A determined attacker will just take the salt > value anyway and use that. Why not just have the hash be the FQDN? For > example: Hash(www.example.com).example.com. Hm. I was going to say that the salt forces you to attack each hash separately, instead of the entire zone. But on consideration (and rechecking the draft), it looks like the salt has to be the same for the whole zone in order for NSEC2 to be useful. So, if I've procured most of the NSEC2 records for a zone (I can't just download the chain, as some people theorized; as you noted, I have to make random queries until I've accumulated most of the records), I can perform a single walk of my dictionary and test each result for inclusion within the set of NSEC2 hashes. That doesn't seem very expensive at all. Also, if I want to procure lots of NSEC2 records, since I'm just making random queries, I don't need to parallelize as much as I do for NSEC walking (where I have to wait an RTT for each packet). So in some ways it's easier than an NSEC walk. If I can run a script on one machine and get 50-80% of a 4-million-record zone in one day (NSEC2), I might prefer that to getting 100% of a 4-million-record zone in ten days, or having to use ten machines to get them all in one day (NSEC). I'm a little skeptical that spammers will be all that interested in domain walks of any sort. http://www.cdt.org/speech/spam/030319spamreport.shtml suggests that most spammers are content to harvest unobfuscated email addresses on the web, and don't take advantage of easy opportunities to harvest other readily-available sources of addresses (Usenet, WHOIS). And even if I experience zero loss in your domain walk (NSEC), I don't necessarily get many high-quality addresses out of that. If I have four million domains, I'm not going to try thousands of addresses per domain; I'm going to try a few likely targets like "postmaster" and "webmaster" and "root" and "abuse". But even then, probably the vast majority of my email will wind up not even hitting a spam filter, and the people who do read those addresses aren't likely spam suckers. I would be more concerned with underhanded DNS "competitors" who want to replicate the data in your zone and add their own records. Lossiness is a much bigger deal to that category of people, and they have to rescan frequently to remain "competitive"... but there also aren't as many of them, so they're unlikely to generate a lot of load. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 11:43:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21422 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 11:43:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVuKa-000DQl-3Q for namedroppers-data@psg.com; Thu, 03 Jun 2004 15:40:36 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVuKZ-000DQQ-7I for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 15:40:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8BF7D13951 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 15:40:34 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: Message from "Scott Rose" <scottr@nist.gov> of "Thu, 03 Jun 2004 08:18:03 -0400." <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 03 Jun 2004 15:40:34 +0000 Message-Id: <20040603154034.8BF7D13951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... > > local hash functions is a wee bit more efficient then online querying > > Also take into consideration that a random non-existant response will > contain one or more NSEC2 RRs, and each NSEC2 RRs has 2 hash values of valid > names. An attacker may get a large portion of the (hashed) namespace by > doing random queries like this without too much effort. They still need to > do the dictionary attack however. as was discussed in the kerberos community a few years ago, offline dictionary attacks -- where the victim has no idea how much effort is being expended and things like botnets and distributed.net can come into play -- are dangerous. > I also have a question about the salt field in the original spec. I still > am not sure it is useful. A determined attacker will just take the salt > value anyway and use that. Why not just have the hash be the FQDN? For > example: Hash(www.example.com).example.com. that looks really cool, but it doesn't change the danger. home pee cees now have 4GHz processors, and it's still doubling every once in a while. apple's "altivec" may be the first mass production example of what's about to be a very popular kind of technology -- maybe a million vector processors running insecure operating systems on 24x7 DSL lines is the right threat model here. > Mainly I'm thinking of ways to reduce the need for the NSECINFO RR and move > the remaining fields (hash algo and iterations) into the NSEC2 RR. there's a lot of room to clean this up, but it's not on the critical path to getting dnssec-bis out the door. i'm enjoying the thread, but the goals of the WG wrt dnssec are still (1) measure/prove the dnssec-bis document/protocol quality; and (2) select one or several ways that -bis can become -ter later. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 11:59:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22665 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 11:59:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVuZ5-000FjZ-Ae for namedroppers-data@psg.com; Thu, 03 Jun 2004 15:55:35 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVuZ4-000FjF-1g for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 15:55:34 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i53FtGcB083228; Thu, 3 Jun 2004 17:55:17 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53FtCLF022643; Thu, 3 Jun 2004 17:55:12 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53FtALJ022640; Thu, 3 Jun 2004 17:55:12 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 17:55:10 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Greg Hudson <ghudson@MIT.EDU> cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: RE: number games. (really NSEC2 vs dictionary attacks) In-Reply-To: <1086275885.1468.204.camel@egyptian-gods.mit.edu> Message-ID: <Pine.LNX.4.58.0406031752240.3943@elektron.atoom.net> References: <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> <1086275885.1468.204.camel@egyptian-gods.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Greg Hudson wrote: > I'm a little skeptical that spammers will be all that interested in > domain walks of any sort. > http://www.cdt.org/speech/spam/030319spamreport.shtml suggests that most > spammers are content to harvest unobfuscated email addresses on the web, > and don't take advantage of easy opportunities to harvest other > readily-available sources of addresses (Usenet, WHOIS). Because there is no index.... yet. 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 Thu Jun 3 12:20:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23539 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 12:20:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVuuR-000IlH-D6 for namedroppers-data@psg.com; Thu, 03 Jun 2004 16:17:39 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVuuP-000IkZ-6n for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 16:17:37 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 24F5142B2 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 12:17:34 -0400 (EDT) Date: Thu, 03 Jun 2004 12:17:34 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: number games. Re: WGLC for DNSSECbis docs In-Reply-To: <16575.3106.634210.548309@giles.gnomon.org.uk> References: <200406020824.i528OcMC066612@open.nlnetlabs.nl> <Pine.LNX.4.58.0406021056200.21385@elektron.atoom.net> <sjmbrk2m3hs.fsf@dogbert.ihtfp.org> <200406021055.40065.davidb@verisignlabs.com> <sjmiseakndv.fsf@dogbert.ihtfp.org> <20040603111509.413cb1c4.olaf@ripe.net> <16575.3106.634210.548309@giles.gnomon.org.uk> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040603161734.24F5142B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 3 Jun 2004 12:31:46 +0100, Roy Badami wrote: > > I have to say that as someone reading the doc set for the first time, > I this point confusing. -protocol clearly states (2.3) that > delegation points require NSEC records. > > But -records states that the NSEC RR contains the owner name of the > next authoritate RRset (section 4, and again in 4.1.1) and as Derek > points out this is not true, since an insecure delegation contains no > authoritative data. The NSEC RR at the delegtion point is authoritative. > This seems to me to be an editorial error in -records -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 12:21:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23601 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 12:21:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVuwH-000J84-U9 for namedroppers-data@psg.com; Thu, 03 Jun 2004 16:19:33 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVuwG-000J7Z-J3 for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 16:19:32 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id A634B1FF845; Thu, 3 Jun 2004 16:19:31 +0000 (GMT) Message-ID: <40BF4F93.4010402@algroup.co.uk> Date: Thu, 03 Jun 2004 17:19:31 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: roy@dnss.ec Cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records References: <89835.1086219203@toybsd.zl2tnm.gen.nz> <40BF08C3.9060602@algroup.co.uk> <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> <40BF1585.3050108@algroup.co.uk> <Pine.LNX.4.58.0406031412171.3943@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406031412171.3943@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: > On Thu, 3 Jun 2004, Ben Laurie wrote: > > >>roy@dnss.ec wrote: >> >>>On Thu, 3 Jun 2004, Ben Laurie wrote: >>> >>> >>> >>>>Don Stokes wrote: >>>> >>>>The downside of this proposal is that currently EXISTS records are only >>>>needed to prove closest enclosers that otherwise don't exist. You'd be >>>>introducing them for every name in the zone - and you'd still have to >>>>have NSEC2 records. The upside, if I understand, is that for the case of >>>>proving existence you'd save the size of the hash of the next domain >>>>name in the response. Not sure the upside is worth the downside. >>> >>> >>>There has been an alternative proposed for the closest encloser issue. >>>That was to add NSEC2s (instead of EXIST) for every emtpty non-terminal. >> >>I don't really understand the advantage of this proposal. > > With EXIST you'll have an NSEC2 record associated anyway. Why do both for > the price of one. > > For instance: > > a.b.c A > #a.b.c NSEC2 #... A NSEC2 RRSIG > b.c EXIST > #b.c NSEC2 #... EXIST NSEC2 RRSIG > c EXIST > #c NSEC2 #... EXIST NSEC2 RRSIG > > Could simply be: > > a.b.c A > #a.b.c NSEC2 #... A NSEC2 RRSIG > #b.c NSEC2 #... NSEC2 RRSIG > #c NSEC2 #... NSEC2 RRSIG > > Your proposal introduces 4 records at every empty non-terminal > (EXIST/SIG/NSEC2/SIG), while the other proposal introduces 2 records. > > >>>Another alternative would be the hashing of individual labels, and >>>truncate hashes to accomodate size. >> >>Hash truncation is fine, so long as it is done carefully. > > > To compare, my proposal is: > > #a.#b.#c NSEC2 #.#.#. A NSEC2 RRSIG Its actually: #a.b.c NSEC2 #d.e.c A NSEC2 RRSIG for the avoidance of doubt. > That saves space no ? There is an open question: is it OK to optimise away NSEC2 records for EXIST (since EXIST is _only_ produced as a proof of a closest encloser, and MUST NOT [hmmm, bet the I-D doesn't say this] be used to answer a query for the owner name). Your proposal does have the advantage of avoiding the question, at the cost of quite a bit of overhead, sizewise, if the question turns out to have answer "yes". 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 Thu Jun 3 12:31:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23966 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 12:31:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVv61-000KlM-5w for namedroppers-data@psg.com; Thu, 03 Jun 2004 16:29:37 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVv5z-000Kku-Pj for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 16:29:36 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id EB25B1FF846; Thu, 3 Jun 2004 16:29:34 +0000 (GMT) Message-ID: <40BF51EE.4060602@algroup.co.uk> Date: Thu, 03 Jun 2004 17:29:34 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: number games. (really NSEC2 vs dictionary attacks) References: <ANECIHCPCBDLLEJLCOPGCEIMCKAA.scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEIMCKAA.scottr@nist.gov> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: >>-----Original Message----- >>From: roy@dnss.ec [mailto:roy@dnss.ec] > > > >>>I also have a question about the salt field in the original >> >>spec. I still >> >>>am not sure it is useful. A determined attacker will just take the salt >>>value anyway and use that. Why not just have the hash be the FQDN? For >>>example: Hash(www.example.com).example.com. >> >>The salt value is a protection against pre-hashing. If you could prehash >>your dictionary, searching for collisions would be very fast. >> > > > But that will only slow them down - a bit. Attackers will just do it in > real time, and eventually will still be able to do it. The names remain the > same, just the tag in front of it changes. They just need to stop and get > the new salt whenever it is rolled over. The salt value becomes just > another knob that admins need to worry about and most will do "whatever the > default tool does". > > I'm not totally against adding the field. I think it would work, but > considering how static most DNS names are, I don't know if it will help DNS > as it does in other uses. That doesn't matter - they have to run the _whole_ dictionary each time to get the new names. 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 Thu Jun 3 12:41:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24108 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 12:41:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVvE6-000LmT-Js for namedroppers-data@psg.com; Thu, 03 Jun 2004 16:37:58 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVvE4-000Lly-RN for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 16:37:57 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i53GbmRK083527; Thu, 3 Jun 2004 18:37:48 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53GbgaW023318; Thu, 3 Jun 2004 18:37:42 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i53Gbg52023315; Thu, 3 Jun 2004 18:37:42 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 3 Jun 2004 18:37:42 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: roy@dnss.ec, Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records In-Reply-To: <40BF4F93.4010402@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406031821340.3943@elektron.atoom.net> References: <89835.1086219203@toybsd.zl2tnm.gen.nz> <40BF08C3.9060602@algroup.co.uk> <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> <40BF1585.3050108@algroup.co.uk> <Pine.LNX.4.58.0406031412171.3943@elektron.atoom.net> <40BF4F93.4010402@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 3 Jun 2004, Ben Laurie wrote: > roy@dnss.ec wrote: > > > To compare, my proposal is: > > > > #a.#b.#c NSEC2 #.#.#. A NSEC2 RRSIG > > Its actually: > > #a.b.c NSEC2 #d.e.c A NSEC2 RRSIG > > for the avoidance of doubt. You can't really tell what you put in the next domain name field though. I ment hash(a).hash(b).hash(c) instead of hash(a.b.c) or hash(a).b.c, unless you know my proposal better then I do ;-) > There is an open question: is it OK to optimise away NSEC2 records for > EXIST (since EXIST is _only_ produced as a proof of a closest encloser, > and MUST NOT [hmmm, bet the I-D doesn't say this] be used to answer a > query for the owner name). Your proposal does have the advantage of > avoiding the question, at the cost of quite a bit of overhead, sizewise, > if the question turns out to have answer "yes". The problem with EXIST is that it turns empty-non-terminals into non-empty-terminals, only to be able to list the empty-non-terminals for closest-encloser purposes. (now read this backwards :-) EXIST is a hack. With NSEC, the empty-non-terminals simply appear in the owner name of an existing NSEC record, giving proof that such a non-terminal exists. With NSEC2 the problem of a single hash for multiple labels is that ownernames become flat. With my proposal the NSEC ownername is simply projected into a hashed ownername by hashing individual labels. Therefor the empty-non-terminal still exist (in hash-space so to say). 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 Thu Jun 3 13:02:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25260 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 13:02:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVvZr-000P6Y-8E for namedroppers-data@psg.com; Thu, 03 Jun 2004 17:00:27 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVvZp-000P6I-Vc for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 17:00:26 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 135D31FF82D; Thu, 3 Jun 2004 16:27:35 +0000 (GMT) Message-ID: <40BF5176.40002@algroup.co.uk> Date: Thu, 03 Jun 2004 17:27:34 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> Cc: namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) References: <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEIICKAA.scottr@nist.gov> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > >>-----Original Message----- >>From: owner-namedroppers@ops.ietf.org >> >>It was suggested by Don and me to do a dictionary attack to find a >>collision with a hashed label. It might even be feasible to do a brute >>force on labels with 6 characters, considering 37 possible values for a >>character. >> >>A device capable of performing 6000000 hash functions per second (quoting >>Don) walks a space of 37^6 in about 7 minutes. >> >>local hash functions is a wee bit more efficient then online querying >> > > > Also take into consideration that a random non-existant response will > contain one or more NSEC2 RRs, and each NSEC2 RRs has 2 hash values of valid > names. An attacker may get a large portion of the (hashed) namespace by > doing random queries like this without too much effort. They still need to > do the dictionary attack however. Note that my plan was to set the time taken (via iterations) to around the network turnaround time for a query (i.e. of the order of milliseconds). > I also have a question about the salt field in the original spec. I still > am not sure it is useful. A determined attacker will just take the salt > value anyway and use that. Why not just have the hash be the FQDN? For > example: Hash(www.example.com).example.com. The salt is to avoid precalculated dictionary attacks - on each walk, the attacker must recalculate everything. > Mainly I'm thinking of ways to reduce the need for the NSECINFO RR and move > the remaining fields (hash algo and iterations) into the NSEC2 RR. I forgot to mention this last time around. So, if we move the info into NSEC2, it must be the same for the whole zone. Therefore, although the signature must be over the complete record, the server only needs to store _one_ copy of the redundant data, and insert it when sending the NSEC2s. Does this reduce your desire to eliminate NSECINFO data? 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 Thu Jun 3 13:02:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25278 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 13:02:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVvY7-000Ori-9F for namedroppers-data@psg.com; Thu, 03 Jun 2004 16:58:39 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVvY5-000OrB-WF for namedroppers@ops.ietf.org; Thu, 03 Jun 2004 16:58:38 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i53Gw8kZ005429 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 12:58:08 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i53Gvu4A019150 for <namedroppers@ops.ietf.org>; Thu, 3 Jun 2004 12:57:56 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: number games. (really NSEC2 vs dictionary attacks) Date: Thu, 3 Jun 2004 12:57:56 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGOEJGCKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <40BF5176.40002@algroup.co.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > Mainly I'm thinking of ways to reduce the need for the NSECINFO > RR and move > > the remaining fields (hash algo and iterations) into the NSEC2 RR. > > I forgot to mention this last time around. So, if we move the info into > NSEC2, it must be the same for the whole zone. Therefore, although the > signature must be over the complete record, the server only needs to > store _one_ copy of the redundant data, and insert it when sending the > NSEC2s. Does this reduce your desire to eliminate NSECINFO data? > I'm not dead set against it, so I can accept it. I'm just wondering if it is better to have everything in the NSEC to avoid larger responses. It is a question whether 8 more bytes in each NSEC2 RR would mean a smaller response vs. a whole NSECINFO RR and covering RRSIG. I don't know if it makes sense to optimize zone database size at the expense of response size. And the complexity that comes with having another RR for storing some information about other RR types. 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 Thu Jun 3 20:07:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11648 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 20:07:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW2Ba-000Jnd-To for namedroppers-data@psg.com; Fri, 04 Jun 2004 00:03:50 +0000 Received: from [61.95.66.138] (helo=mail.mel.netstarnetworks.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW2BX-000Jm3-LC for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 00:03:47 +0000 Received: from mindrot.org (35.195.20.10.dhcp.netstarnetworks.com [10.20.195.35] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id i5404uJ04546; Fri, 4 Jun 2004 10:04:56 +1000 Message-ID: <40BFBC58.5060602@mindrot.org> Date: Fri, 04 Jun 2004 10:03:36 +1000 From: Damien Miller <djm@mindrot.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) References: <20040603154034.8BF7D13951@sa.vix.com> In-Reply-To: <20040603154034.8BF7D13951@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>I also have a question about the salt field in the original spec. I still >>am not sure it is useful. A determined attacker will just take the salt >>value anyway and use that. Why not just have the hash be the FQDN? For >>example: Hash(www.example.com).example.com. > > that looks really cool, but it doesn't change the danger. home pee cees now > have 4GHz processors, and it's still doubling every once in a while. apple's > "altivec" may be the first mass production example of what's about to be a > very popular kind of technology -- maybe a million vector processors running > insecure operating systems on 24x7 DSL lines is the right threat model here. A solution to this is to make the iterations the log2 of the number of hash rounds, rather than a counter. This better matches the (so far) exponential increase in CPU speed. This approach is used by the OpenBSD blowfish password hash function: http://www.openbsd.org/papers/bcrypt-paper.ps -d -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 3 22:03:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19561 for <dnsext-archive@lists.ietf.org>; Thu, 3 Jun 2004 22:03:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW401-0008cf-Le for namedroppers-data@psg.com; Fri, 04 Jun 2004 02:00:01 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW400-0008bk-7p for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 02:00:00 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id NAA15566 for <namedroppers@ops.ietf.org>; Fri, 4 Jun 2004 13:59:58 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i541xwfw002994 for <namedroppers@ops.ietf.org>; Fri, 4 Jun 2004 13:59:58 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records In-Reply-To: Your message of "Thu, 03 Jun 2004 12:17:23 +0100." <40BF08C3.9060602@algroup.co.uk> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Fri, 04 Jun 2004 13:59:58 +1200 Message-ID: <2993.1086314398@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben Laurie <ben@algroup.co.uk> wrote: >The downside of this proposal is that currently EXISTS records are only >needed to prove closest enclosers that otherwise don't exist. You'd be >introducing them for every name in the zone - and you'd still have to >have NSEC2 records. The upside, if I understand, is that for the case of >proving existence you'd save the size of the hash of the next domain >name in the response. Not sure the upside is worth the downside. The point of the proposal is (a) to cut the amount of work required for authenticated denial of RRsets in existing names using NSEC2, and (b) to cut the traffic on the wire in both authenticated denial cases. The expense, as you say, is to add an additional RR and its signature to the zone, making zone signing harder. Where I'm coming from with regard to (a) is that TLD zones would contain vast numbers of insecure delegations, especially early in the game, and every one of those insecure delegations would need to generate hashed NSEC2 records for security-aware resolvers. While authoritative name servers could internally link each name with its NSEC2 hash at zone load time, that link has to be computed on the fly by security-aware resolvers every time a query is made via those delegations. If the NSECINFO iteration count is high to deter offline dictionary attacks, those hash computations could get expensive for smaller resolvers. -- 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 Jun 4 02:34:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14548 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 02:34:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW8Cz-00068N-6u for namedroppers-data@psg.com; Fri, 04 Jun 2004 06:29:41 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW8Cy-000680-39 for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 06:29:40 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id D99BB1FF82D; Fri, 4 Jun 2004 06:29:38 +0000 (GMT) Message-ID: <40C016D1.3070107@algroup.co.uk> Date: Fri, 04 Jun 2004 07:29:37 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Miller <djm@mindrot.org> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: number games. (really NSEC2 vs dictionary attacks) References: <20040603154034.8BF7D13951@sa.vix.com> <40BFBC58.5060602@mindrot.org> In-Reply-To: <40BFBC58.5060602@mindrot.org> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Damien Miller wrote: > Paul Vixie wrote: > > >>>I also have a question about the salt field in the original spec. I still >>>am not sure it is useful. A determined attacker will just take the salt >>>value anyway and use that. Why not just have the hash be the FQDN? For >>>example: Hash(www.example.com).example.com. >> >>that looks really cool, but it doesn't change the danger. home pee cees now >>have 4GHz processors, and it's still doubling every once in a while. apple's >>"altivec" may be the first mass production example of what's about to be a >>very popular kind of technology -- maybe a million vector processors running >>insecure operating systems on 24x7 DSL lines is the right threat model here. > > > A solution to this is to make the iterations the log2 of the number of > hash rounds, rather than a counter. This better matches the (so far) > exponential increase in CPU speed. That doesn't solve the problem, but it might be a good idea anyway. 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 Jun 4 10:23:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13430 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 10:23:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWFV8-000605-WC for namedroppers-data@psg.com; Fri, 04 Jun 2004 14:16:54 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWFV6-0005zj-02 for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 14:16:52 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i54EGjc1095222; Fri, 4 Jun 2004 16:16:45 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i54EGf1x011245; Fri, 4 Jun 2004 16:16:41 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i54EGf3r011242; Fri, 4 Jun 2004 16:16:41 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 4 Jun 2004 16:16:41 +0200 (CEST) From: roy@dnss.ec X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: roy@dnss.ec, Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records In-Reply-To: <40C081A8.8030501@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406041611420.9832@elektron.atoom.net> References: <89835.1086219203@toybsd.zl2tnm.gen.nz> <40BF08C3.9060602@algroup.co.uk> <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> <40BF1585.3050108@algroup.co.uk> <Pine.LNX.4.58.0406031412171.3943@elektron.atoom.net> <40C081A8.8030501@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 4 Jun 2004, Ben Laurie wrote: > [going backwards for a moment, coz I have seen the light] > > roy@dnss.ec wrote: > > On Thu, 3 Jun 2004, Ben Laurie wrote: > >>roy@dnss.ec wrote: > >>>On Thu, 3 Jun 2004, Ben Laurie wrote: > >>> > >>> > >>> > >>>>Don Stokes wrote: > >>>> > >>>>The downside of this proposal is that currently EXISTS records are only > >>>>needed to prove closest enclosers that otherwise don't exist. You'd be > >>>>introducing them for every name in the zone - and you'd still have to > >>>>have NSEC2 records. The upside, if I understand, is that for the case of > >>>>proving existence you'd save the size of the hash of the next domain > >>>>name in the response. Not sure the upside is worth the downside. > >>> > >>> > >>>There has been an alternative proposed for the closest encloser issue. > >>>That was to add NSEC2s (instead of EXIST) for every emtpty non-terminal. > >> > >>I don't really understand the advantage of this proposal. > > > > > > With EXIST you'll have an NSEC2 record associated anyway. Why do both for > > the price of one. > > > > For instance: > > > > a.b.c A > > #a.b.c NSEC2 #... A NSEC2 RRSIG > > b.c EXIST > > #b.c NSEC2 #... EXIST NSEC2 RRSIG > > c EXIST > > #c NSEC2 #... EXIST NSEC2 RRSIG > > This is incorrect in general. EXIST records are only required for empty > non-terminals that are associated with wildcards. Then how do I give proof that there exist no wildcard between a non-empty-terminal and an empty-non-terminal ? 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 Jun 4 10:26:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13551 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 10:26:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWFbn-0006o1-6W for namedroppers-data@psg.com; Fri, 04 Jun 2004 14:23:47 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWFbl-0006nk-LX for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 14:23:45 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 9EE0B1FF82D; Fri, 4 Jun 2004 14:05:29 +0000 (GMT) Message-ID: <40C081A8.8030501@algroup.co.uk> Date: Fri, 04 Jun 2004 15:05:28 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: roy@dnss.ec Cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records References: <89835.1086219203@toybsd.zl2tnm.gen.nz> <40BF08C3.9060602@algroup.co.uk> <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> <40BF1585.3050108@algroup.co.uk> <Pine.LNX.4.58.0406031412171.3943@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406031412171.3943@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [going backwards for a moment, coz I have seen the light] roy@dnss.ec wrote: > On Thu, 3 Jun 2004, Ben Laurie wrote: >>roy@dnss.ec wrote: >>>On Thu, 3 Jun 2004, Ben Laurie wrote: >>> >>> >>> >>>>Don Stokes wrote: >>>> >>>>The downside of this proposal is that currently EXISTS records are only >>>>needed to prove closest enclosers that otherwise don't exist. You'd be >>>>introducing them for every name in the zone - and you'd still have to >>>>have NSEC2 records. The upside, if I understand, is that for the case of >>>>proving existence you'd save the size of the hash of the next domain >>>>name in the response. Not sure the upside is worth the downside. >>> >>> >>>There has been an alternative proposed for the closest encloser issue. >>>That was to add NSEC2s (instead of EXIST) for every emtpty non-terminal. >> >>I don't really understand the advantage of this proposal. > > > With EXIST you'll have an NSEC2 record associated anyway. Why do both for > the price of one. > > For instance: > > a.b.c A > #a.b.c NSEC2 #... A NSEC2 RRSIG > b.c EXIST > #b.c NSEC2 #... EXIST NSEC2 RRSIG > c EXIST > #c NSEC2 #... EXIST NSEC2 RRSIG This is incorrect in general. EXIST records are only required for empty non-terminals that are associated with wildcards. > Could simply be: > > a.b.c A > #a.b.c NSEC2 #... A NSEC2 RRSIG > #b.c NSEC2 #... NSEC2 RRSIG > #c NSEC2 #... NSEC2 RRSIG > > Your proposal introduces 4 records at every empty non-terminal > (EXIST/SIG/NSEC2/SIG), while the other proposal introduces 2 records. Yes, you are right, I managed to persuade myself that EXISTS were required because you couldn't know what the record was that created the closest encloser - that is, using NSEC, to deny a.b.c you might exhibit an RR for d.b.c and prove nonexistence of *.b.c. But since the EXISTS record would only be for b.c, you could indeed use an NSEC2 record. My counterargument would be that since EXISTS is only used in negative proofs, it can be treated as special, and so what you'd actually have is: a.b.c A #a.b.c NSEC2 #... A NSEC2 RRSIG b.c EXISTS c EXISTS (though really at least c would be shown by some other RR, like SOA). >>>Another alternative would be the hashing of individual labels, and >>>truncate hashes to accomodate size. >> >>Hash truncation is fine, so long as it is done carefully. > > > To compare, my proposal is: > > #a.#b.#c NSEC2 #.#.#. A NSEC2 RRSIG > > That saves space no ? Compared to your example, yes - compared to mine? Probably not, since #b is much bigger, generally, than b, and #c is almost certainly redundant most of the time. Neat idea, though. Worth further thought. 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 Jun 4 10:33:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13940 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 10:33:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWFie-0007dl-51 for namedroppers-data@psg.com; Fri, 04 Jun 2004 14:30:52 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWFic-0007dV-Tz for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 14:30:51 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 5C4A51FF846; Fri, 4 Jun 2004 14:30:50 +0000 (GMT) Message-ID: <40C08799.2030003@algroup.co.uk> Date: Fri, 04 Jun 2004 15:30:49 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Stokes <don@plugh.daedalus.co.nz> Cc: namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records References: <2993.1086314398@toybsd.zl2tnm.gen.nz> In-Reply-To: <2993.1086314398@toybsd.zl2tnm.gen.nz> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Don Stokes wrote: > Ben Laurie <ben@algroup.co.uk> wrote: >>The downside of this proposal is that currently EXISTS records are only >>needed to prove closest enclosers that otherwise don't exist. You'd be >>introducing them for every name in the zone - and you'd still have to >>have NSEC2 records. The upside, if I understand, is that for the case of >>proving existence you'd save the size of the hash of the next domain >>name in the response. Not sure the upside is worth the downside. > > > The point of the proposal is (a) to cut the amount of work required > for authenticated denial of RRsets in existing names using NSEC2, and > (b) to cut the traffic on the wire in both authenticated denial cases. > > The expense, as you say, is to add an additional RR and its signature to > the zone, making zone signing harder. > > Where I'm coming from with regard to (a) is that TLD zones would contain > vast numbers of insecure delegations, especially early in the game, and > every one of those insecure delegations would need to generate hashed > NSEC2 records for security-aware resolvers. While authoritative name > servers could internally link each name with its NSEC2 hash at zone load > time, that link has to be computed on the fly by security-aware > resolvers every time a query is made via those delegations. > > If the NSECINFO iteration count is high to deter offline dictionary > attacks, those hash computations could get expensive for smaller > resolvers. The general idea is that the cost of the hash computation should be similar to the cost of making a query, so although it will increase the expense for resolvers it should not be by an order of magnitude. But indeed, I take your point. Since the name exists and a query has been made for it, I can't see the harm (apart from adding an awful lot of records) in proving the lack of a DS with an EXISTS. 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 Jun 4 10:38:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14289 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 10:38:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWFmz-0008BA-Iq for namedroppers-data@psg.com; Fri, 04 Jun 2004 14:35:21 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWFmy-0008Aw-J1 for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 14:35:20 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id E018D1FF845; Fri, 4 Jun 2004 14:35:19 +0000 (GMT) Message-ID: <40C088A7.5050508@algroup.co.uk> Date: Fri, 04 Jun 2004 15:35:19 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: roy@dnss.ec Cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC2 on existing records References: <89835.1086219203@toybsd.zl2tnm.gen.nz> <40BF08C3.9060602@algroup.co.uk> <Pine.LNX.4.58.0406031325320.3943@elektron.atoom.net> <40BF1585.3050108@algroup.co.uk> <Pine.LNX.4.58.0406031412171.3943@elektron.atoom.net> <40C081A8.8030501@algroup.co.uk> <Pine.LNX.4.58.0406041611420.9832@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406041611420.9832@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit roy@dnss.ec wrote: > On Fri, 4 Jun 2004, Ben Laurie wrote: > > >>[going backwards for a moment, coz I have seen the light] >> >>roy@dnss.ec wrote: >> >>>On Thu, 3 Jun 2004, Ben Laurie wrote: >>> >>>>roy@dnss.ec wrote: >>>> >>>>>On Thu, 3 Jun 2004, Ben Laurie wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Don Stokes wrote: >>>>>> >>>>>>The downside of this proposal is that currently EXISTS records are only >>>>>>needed to prove closest enclosers that otherwise don't exist. You'd be >>>>>>introducing them for every name in the zone - and you'd still have to >>>>>>have NSEC2 records. The upside, if I understand, is that for the case of >>>>>>proving existence you'd save the size of the hash of the next domain >>>>>>name in the response. Not sure the upside is worth the downside. >>>>> >>>>> >>>>>There has been an alternative proposed for the closest encloser issue. >>>>>That was to add NSEC2s (instead of EXIST) for every emtpty non-terminal. >>>> >>>>I don't really understand the advantage of this proposal. >>> >>> >>>With EXIST you'll have an NSEC2 record associated anyway. Why do both for >>>the price of one. >>> >>>For instance: >>> >>> a.b.c A >>>#a.b.c NSEC2 #... A NSEC2 RRSIG >>> b.c EXIST >>> #b.c NSEC2 #... EXIST NSEC2 RRSIG >>> c EXIST >>> #c NSEC2 #... EXIST NSEC2 RRSIG >> >>This is incorrect in general. EXIST records are only required for empty >>non-terminals that are associated with wildcards. > > > Then how do I give proof that there exist no wildcard between a > non-empty-terminal and an empty-non-terminal ? These wildcards make my head spin. You are correct - we need each of the records (modulo my other points), but only need to _return_ one for any particular query. Apologies. 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 Jun 4 13:54:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27109 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 13:54:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWIop-000FVi-99 for namedroppers-data@psg.com; Fri, 04 Jun 2004 17:49:27 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWIom-000FUv-4G for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 17:49:24 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i54HnNW4006705 for <namedroppers@ops.ietf.org>; Fri, 4 Jun 2004 17:49:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i54HnMoo006702 for namedroppers@ops.ietf.org; Fri, 4 Jun 2004 17:49:22 GMT Date: Fri, 4 Jun 2004 17:49:22 +0000 From: bmanning@vacation.karoshi.com To: namedroppers@ops.ietf.org Subject: dns & confidentiality? Message-ID: <20040604174922.GE6604@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Now that the DNSSECbis docs are locked, loaded, and the tubes flooded, perhaps its time to review one of the basic presumptions that drove the -bis set and seemed to cause any amount of angst in some operators. should the DNS and the data it holds be considered confidential? additionally, it would seem prudent to ask... should the tools/applications used to access the DNS support confidentiality? if so, this might be worth paying attention to: http://crypto.stanford.edu/portia/workshops/2004_7.html --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 Jun 4 14:11:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28019 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 14:11:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWJ7Z-000Jz7-MP for namedroppers-data@psg.com; Fri, 04 Jun 2004 18:08:49 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWJ7V-000JyG-Sq for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 18:08:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 55EB213960 for <namedroppers@ops.ietf.org>; Fri, 4 Jun 2004 18:08:45 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? In-Reply-To: Message from bmanning@vacation.karoshi.com of "Fri, 04 Jun 2004 17:49:22 GMT." <20040604174922.GE6604@vacation.karoshi.com.> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 04 Jun 2004 18:08:45 +0000 Message-Id: <20040604180845.55EB213960@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > should the DNS and the data it holds be considered confidential? i don't know. doing so could demand a DH exchange on every query, depending on the threat model. and would demand at least some kind of work-preload for every initiator, like an expensive hash of <time,qname,qtype,qclass> to discourage zone walking. it's a much harder problem than NSEC2 addresses. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 4 14:22:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28578 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 14:22:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWJHf-000LfF-6K for namedroppers-data@psg.com; Fri, 04 Jun 2004 18:19:15 +0000 Received: from [207.65.71.19] (helo=weasel.corp.ntrg.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWJHb-000Lej-9y for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 18:19:11 +0000 Received: from [207.65.71.20] (account ehall HELO ehsco.com) by weasel.corp.ntrg.com (CommuniGate Pro SMTP 4.2b4) with ESMTP-TLS id 110038; Fri, 04 Jun 2004 13:19:09 -0500 Message-ID: <40C0BD12.6000104@ehsco.com> Date: Fri, 04 Jun 2004 13:18:58 -0500 From: "Eric A. Hall" <ehall@ehsco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? References: <20040604174922.GE6604@vacation.karoshi.com.> In-Reply-To: <20040604174922.GE6604@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 6/4/2004 12:49 PM, bmanning@vacation.karoshi.com wrote: > should the DNS and the data it holds be considered confidential? Information in DNS is only as secure as all of the points where it is cached. Seems to me that it's impossible to consider any such system as anything other than incidentally confidential. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 4 14:23:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28674 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 14:23:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWJKG-000M3s-Ao for namedroppers-data@psg.com; Fri, 04 Jun 2004 18:21:56 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWJKF-000M3S-Gk for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 18:21:55 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i54ILtW4006779; Fri, 4 Jun 2004 18:21:55 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i54ILtqE006776; Fri, 4 Jun 2004 18:21:55 GMT Date: Fri, 4 Jun 2004 18:21:54 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? Message-ID: <20040604182154.GH6604@vacation.karoshi.com.> References: <20040604174922.GE6604@vacation.karoshi.com.> <20040604180845.55EB213960@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040604180845.55EB213960@sa.vix.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jun 04, 2004 at 06:08:45PM +0000, Paul Vixie wrote: > > should the DNS and the data it holds be considered confidential? > > i don't know. doing so could demand a DH exchange on every query, depending > on the threat model. and would demand at least some kind of work-preload for > every initiator, like an expensive hash of <time,qname,qtype,qclass> to > discourage zone walking. it's a much harder problem than NSEC2 addresses. > yes it is. and i suspect that -IF- the current user base expects confidentiality, that the DNS as we know it is -DOA- and we should start on the new thing -now-. Much harder than NSEC2, which is a pretty much a translucent veil over the naked DNS. Still, its worth asking the question. --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 Jun 4 14:34:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29347 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 14:34:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWJTR-000ORT-NZ for namedroppers-data@psg.com; Fri, 04 Jun 2004 18:31:25 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWJTP-000OQE-OZ for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 18:31:23 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i52GqHZJ002420; Wed, 2 Jun 2004 12:52:17 -0400 To: roy@dnss.ec Cc: David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks References: <ANECIHCPCBDLLEJLCOPGCEGECKAA.scottr@nist.gov> <200406021032.09533.davidb@verisignlabs.com> <Pine.LNX.4.58.0406021706460.21385@elektron.atoom.net> <200406021130.36747.davidb@verisignlabs.com> <Pine.LNX.4.58.0406021822230.21385@elektron.atoom.net> From: Derek Atkins <derek@ihtfp.com> Date: Wed, 02 Jun 2004 12:52:17 -0400 In-Reply-To: <Pine.LNX.4.58.0406021822230.21385@elektron.atoom.net> (roy@dnss.ec's message of "Wed, 2 Jun 2004 18:34:45 +0200 (CEST)") Message-ID: <sjmk6ypkim6.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk roy@dnss.ec writes: >> > Say resolver makes 'efficient' use of cached NSEC records, which one >> > should be returned for a query for F, for G, and for H. >> >> Wouldn't the resolver return F for the query for F, > > Why is F more valid than A NSEC H ? Well, for one thing, SIG(F) will have a newer timestamp than SIG(A NSEC H). Second, unless A NSEC H was obtained by a query for F, the cache should not associate A NSEC H with F. I.e., if the cache has A NSEC H due to a query for E, it should not carry over that response into a query for F. -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 Jun 4 14:55:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00657 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 14:55:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWJn0-0001tm-Oj for namedroppers-data@psg.com; Fri, 04 Jun 2004 18:51:38 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWJmz-0001tU-QJ for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 18:51:37 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5913742B2 for <namedroppers@ops.ietf.org>; Fri, 4 Jun 2004 14:51:37 -0400 (EDT) Date: Fri, 04 Jun 2004 14:51:37 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? In-Reply-To: <20040604174922.GE6604@vacation.karoshi.com.> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040604185137.5913742B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 4 Jun 2004 17:49:22 +0000, Bill Manning wrote: > > Now that the DNSSECbis docs are locked, loaded, and the tubes flooded, Only almost, and it might be nice to let the WG list quiet down a bit so that folks could concentrate on the boring job of proofreading the flipping -bis docs rather than jumping right into yet another high volume debate, but I know that Bill is easily bored. :) > perhaps its time to review one of the basic presumptions that drove the > -bis set and seemed to cause any amount of angst in some operators. > > should the DNS and the data it holds be considered confidential? I suspect that the trust model would prove sufficiently complex that it would render the result, if usable at all, sufficiently different from DNS as we know it that it would be easier just to start over. I'm tempted to say, along with Rocket J. Squirrel, that "that trick never works", but I could of course be wrong. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 4 14:55:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00678 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 14:55:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWJoe-0002Ef-KD for namedroppers-data@psg.com; Fri, 04 Jun 2004 18:53:20 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWJod-0002E6-Jc for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 18:53:19 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i54IrCkZ027351 for <namedroppers@ops.ietf.org>; Fri, 4 Jun 2004 14:53:12 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i54Iqh4A011420 for <namedroppers@ops.ietf.org>; Fri, 4 Jun 2004 14:52:43 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: dns & confidentiality? Date: Fri, 4 Jun 2004 14:52:43 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGCEKICKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040604182154.GH6604@vacation.karoshi.com.> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I wonder how many of those that _do_ expect confidentiality actually need it. Or if anyone really MUST have confidentiality for IP address lookup. I guess there could be some scenarios where it is desired, but that also depends on what a user wants to keep confidential. I agree that DNS itself doesn't have the necessary features to have that now, and neither does DNSSEC/bis/ter. Something else would be needed: either hop-hop or end-end? Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > > yes it is. and i suspect that -IF- the current user > base expects confidentiality, that the DNS as we know > it is -DOA- and we should start on the new thing -now-. > Much harder than NSEC2, which is a pretty much a translucent > veil over the naked DNS. Still, its worth asking the question. > > > --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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 4 15:24:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04772 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 15:24:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWKFp-0007nK-1H for namedroppers-data@psg.com; Fri, 04 Jun 2004 19:21:25 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWKFn-0007n1-G8 for namedroppers@ops.ietf.org; Fri, 04 Jun 2004 19:21:23 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id EC025E7EA5; Fri, 4 Jun 2004 20:21:22 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? In-Reply-To: <20040604174922.GE6604@vacation.karoshi.com.> Message-Id: <20040604192122.EC025E7EA5@mx1.nominet.org.uk> Date: Fri, 4 Jun 2004 20:21:22 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bmanning@vacation.karoshi.com writes: > should the DNS and the data it holds be considered confidential? Based on our legal advice: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00687.html . . . we're obligated to make a best-effort attempt to keep the data in the DNS confidential. Which for us, practically, at the moment, means: "it's worse to expose data in the DNS via DNSSEC than to not deploy DNSSEC". :-( 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 Jun 4 20:38:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29899 for <dnsext-archive@lists.ietf.org>; Fri, 4 Jun 2004 20:38:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWP86-00072B-NH for namedroppers-data@psg.com; Sat, 05 Jun 2004 00:33:46 +0000 Received: from [32.97.182.105] (helo=e5.ny.us.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWP85-00071u-JI for namedroppers@ops.ietf.org; Sat, 05 Jun 2004 00:33:45 +0000 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i550XiQ1371440; Fri, 4 Jun 2004 20:33:44 -0400 Received: from IBMTC_S30001313.gis.net (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i550YPZL119302; Fri, 4 Jun 2004 20:34:25 -0400 Message-Id: <4.3.1.2.20040604203046.024bae28@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 04 Jun 2004 20:32:49 -0400 To: "Scott Rose" <scottr@nist.gov>, <namedroppers@ops.ietf.org> From: Danny Mayer <mayer@gis.net> Subject: RE: dns & confidentiality? In-Reply-To: <ANECIHCPCBDLLEJLCOPGCEKICKAA.scottr@nist.gov> References: <20040604182154.GH6604@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:52 PM 6/4/2004, Scott Rose wrote: >I wonder how many of those that _do_ expect confidentiality actually need >it. Or if anyone really MUST have confidentiality for IP address lookup. I >guess there could be some scenarios where it is desired, but that also >depends on what a user wants to keep confidential. The people who want confidentiality need to define EXACTLY what they mean by that, otherwise the working group will end up working towards yet another goal that doesn't satisfy their perceived needs. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Jun 5 08:43:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11259 for <dnsext-archive@lists.ietf.org>; Sat, 5 Jun 2004 08:43:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWaQk-0008He-8r for namedroppers-data@psg.com; Sat, 05 Jun 2004 12:37:46 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWaQi-0008HO-Cm for namedroppers@ops.ietf.org; Sat, 05 Jun 2004 12:37:44 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 550411FE67; Sat, 5 Jun 2004 13:37:43 +0100 (BST) Date: Sat, 05 Jun 2004 13:37:45 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Danny Mayer <mayer@gis.net>, Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: RE: dns & confidentiality? Message-ID: <E8478DDDE96F8B3391782DCC@[192.168.100.19]> In-Reply-To: <4.3.1.2.20040604203046.024bae28@pop.gis.net> References: <20040604182154.GH6604@vacation.karoshi.com.> <4.3.1.2.20040604203046.024bae28@pop.gis.net> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 04 June 2004 20:32 -0400 Danny Mayer <mayer@gis.net> wrote: >> I wonder how many of those that _do_ expect confidentiality actually need >> it. Or if anyone really MUST have confidentiality for IP address >> lookup. I guess there could be some scenarios where it is desired, but >> that also depends on what a user wants to keep confidential. > > The people who want confidentiality need to define EXACTLY what they mean > by that, otherwise the working group will end up working towards yet > another > goal that doesn't satisfy their perceived needs. Indeed. Confidentiality is a nebulous word. That might include anything up to an including: * Ensuring noone with access to the wire between server and resolver can infer anything about either the names resolved, or the results of that resolution * Ditto with respect to those with the ability to snoop caching nameservers * Requirements for clients themselves to authenticate before being given confidential data I think Paul dropped the confidentiality suggestion in as a possibility. I don't think anyone has yet argued for it, and if they do, I think it's a mostly orthogonal requirement to the enumerability problem (certainly the above type of requirements are not something Nominet is looking for to my knowledge). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Jun 5 09:15:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12636 for <dnsext-archive@lists.ietf.org>; Sat, 5 Jun 2004 09:15:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWaze-000F2P-B3 for namedroppers-data@psg.com; Sat, 05 Jun 2004 13:13:50 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWazd-000F20-Ey for namedroppers@ops.ietf.org; Sat, 05 Jun 2004 13:13:49 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i55DDfW4008789; Sat, 5 Jun 2004 13:13:41 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i55DDffo008786; Sat, 5 Jun 2004 13:13:41 GMT Date: Sat, 5 Jun 2004 13:13:41 +0000 From: bmanning@vacation.karoshi.com To: Alex Bligh <alex@alex.org.uk> Cc: Danny Mayer <mayer@gis.net>, Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? Message-ID: <20040605131341.GA8735@vacation.karoshi.com.> References: <20040604182154.GH6604@vacation.karoshi.com.> <4.3.1.2.20040604203046.024bae28@pop.gis.net> <E8478DDDE96F8B3391782DCC@[192.168.100.19]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <E8478DDDE96F8B3391782DCC@[192.168.100.19]> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Indeed. Confidentiality is a nebulous word. That might include anything > up to an including: > * Ensuring noone with access to the wire between server and resolver > can infer anything about either the names resolved, or the results of > that resolution > * Ditto with respect to those with the ability to snoop caching > nameservers > * Requirements for clients themselves to authenticate before being > given confidential data yup... > I think Paul dropped the confidentiality suggestion in as a possibility. > I don't think anyone has yet argued for it, and if they do, I think > it's a mostly orthogonal requirement to the enumerability problem > (certainly the above type of requirements are not something Nominet is > looking for to my knowledge). may or may not have been Paul (which one?) but it is certainly called out in the DNS threat model RFC. And Geoff did indicate that Nominet has received legal advice that confidentiality is required. Rock/hardPlace. > Alex --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Jun 5 11:33:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19979 for <dnsext-archive@lists.ietf.org>; Sat, 5 Jun 2004 11:33:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWd65-000FXz-0B for namedroppers-data@psg.com; Sat, 05 Jun 2004 15:28:37 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWd63-000FXP-Oo for namedroppers@ops.ietf.org; Sat, 05 Jun 2004 15:28:35 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B570A1FE70; Sat, 5 Jun 2004 16:28:34 +0100 (BST) Date: Sat, 05 Jun 2004 16:28:36 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: bmanning@vacation.karoshi.com Cc: Danny Mayer <mayer@gis.net>, Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk> Subject: Re: dns & confidentiality? Message-ID: <6F6A678A72A60383A2898927@[192.168.100.19]> In-Reply-To: <20040605131341.GA8735@vacation.karoshi.com.> References: <20040604182154.GH6604@vacation.karoshi.com.> <4.3.1.2.20040604203046.024bae28@pop.gis.net> <E8478DDDE96F8B3391782DCC@[192.168.100.19]> <20040605131341.GA8735@vacation.karoshi.com.> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 05 June 2004 13:13 +0000 bmanning@vacation.karoshi.com wrote: > And Geoff did indicate that Nominet has received legal > advice that confidentiality is required. I think (as per the referenced in Geoff's message to which you refer) it's specific confidentiality that's required on that front (i.e. of the database rather than of its components), rather than "everything must be held confidential". But away from the legal point, there's the "what do we want this protocol to do" question. Again, from Nominet's view, whilst I can see the three things I posted might be desirable features to some, they aren't something Nominet's looking for. The point of my message was to indicate what advice we had not received, and what functionality we were not seeking :-) - given "confidentiality" can mean anything to anyone. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Jun 5 21:05:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17837 for <dnsext-archive@lists.ietf.org>; Sat, 5 Jun 2004 21:05:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWlzC-000ErM-Si for namedroppers-data@psg.com; Sun, 06 Jun 2004 00:58:06 +0000 Received: from [208.218.130.13] (helo=gis.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWlz9-000EqQ-8D for namedroppers@ops.ietf.org; Sun, 06 Jun 2004 00:58:03 +0000 Received: from tecotoo.localhost ([4.156.51.14]) by mx05.gis.net; Sat, 05 Jun 2004 20:57:58 -0400 Received: from tecotoo (tecotoo [127.0.0.1]) by tecotoo.localhost (NTMail 3.03.0017/1.aaaa) with ESMTP id la000141 for <namedroppers@ops.ietf.org>; Sat, 5 Jun 2004 20:57:22 +0100 Message-Id: <4.3.1.2.20040605204812.037f2ea0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 05 Jun 2004 20:57:11 -0400 To: Alex Bligh <alex@alex.org.uk>, bmanning@vacation.karoshi.com From: Danny Mayer <mayer@gis.net> Subject: Re: dns & confidentiality? Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org In-Reply-To: <6F6A678A72A60383A2898927@[192.168.100.19]> References: <20040605131341.GA8735@vacation.karoshi.com.> <20040604182154.GH6604@vacation.karoshi.com.> <4.3.1.2.20040604203046.024bae28@pop.gis.net> <E8478DDDE96F8B3391782DCC@[192.168.100.19]> <20040605131341.GA8735@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Rcpt-To: <namedroppers@ops.ietf.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:28 AM 6/5/2004, Alex Bligh wrote: >--On 05 June 2004 13:13 +0000 bmanning@vacation.karoshi.com wrote: > >>And Geoff did indicate that Nominet has received legal >> advice that confidentiality is required. > >I think (as per the referenced in Geoff's message to which you refer) it's >specific confidentiality that's required on that front (i.e. of the >database rather than of its components), rather than "everything must be >held confidential". > >But away from the legal point, there's the "what do we want this protocol >to do" question. Again, from Nominet's view, whilst I can see the three >things I posted might be desirable features to some, they aren't something >Nominet's looking for. > >The point of my message was to indicate what advice we had not received, >and what functionality we were not seeking :-) - given "confidentiality" >can mean anything to anyone. > >Alex I raised the issue of defining "confidentiality" since it's not clear at all what that means. For example: alex registers a domain alex.co.uk with Nominet (and I'm not really picking on Alex or Nominet here). What needs to be kept confidential? Is it: a) the domain name alex.co.uk itself, in which case I would argue that by registering the domain and making it available through the parent domain, the name has been published and is available for everyone to use. Otherwise why register it in the DNS? b) He doesn't want people to know about the domain since you can find out all sorts of information via whois, in which case the problem lies with whois and not DNS. c) Doesn't want someone else walking the co.uk and getting a complete list of all domains. This could affect performance of the DNS servers due to the advent of kiddiescripts being created to do this. d) something else. Again I'm not picking on Alex or Nominet. I just want to understand exactly what they want to protect. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Jun 6 04:18:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17724 for <dnsext-archive@lists.ietf.org>; Sun, 6 Jun 2004 04:18:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWsmN-0009CH-Hz for namedroppers-data@psg.com; Sun, 06 Jun 2004 08:13:19 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWsmL-0009Bk-V0 for namedroppers@ops.ietf.org; Sun, 06 Jun 2004 08:13:18 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i568DEUB017141 for <namedroppers@ops.ietf.org>; Sun, 6 Jun 2004 10:13:14 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.11/8.12.11/Submit) id i568DD6j017140 for namedroppers@ops.ietf.org; Sun, 6 Jun 2004 10:13:13 +0200 (CEST) (envelope-from ted) Message-Id: <200406060813.i568DD6j017140@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Sun, 6 Jun 2004 10:13:13 +0200 In-Reply-To: "Danny Mayer's message as of Jun 6, 3:06" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting Danny Mayer, on Jun 6, 3:06, in "Re: dns & confidenti ..."] ... > What needs to be kept confidential? Is it: ... > b) He doesn't want people to know about the domain since you can > find out all sorts of information via whois, in which case the problem > lies with whois and not DNS. For NL it was b) and only b), and it was also recognised that, indeed, it is a whois and not a DNS problem. -- 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 Sun Jun 6 04:35:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18137 for <dnsext-archive@lists.ietf.org>; Sun, 6 Jun 2004 04:35:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWt6X-000DPi-SN for namedroppers-data@psg.com; Sun, 06 Jun 2004 08:34:09 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWt6W-000DPT-W9 for namedroppers@ops.ietf.org; Sun, 06 Jun 2004 08:34:09 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BB5D7139A3 for <namedroppers@ops.ietf.org>; Sun, 6 Jun 2004 08:34:08 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? In-Reply-To: Message from ted@NLnetLabs.nl (Ted Lindgreen) of "Sun, 06 Jun 2004 10:13:13 +0200." <200406060813.i568DD6j017140@open.nlnetlabs.nl> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 06 Jun 2004 08:34:08 +0000 Message-Id: <20040606083408.BB5D7139A3@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk red wrote: > For NL it was b) and only b), and it was also recognised that, > indeed, it is a whois and not a DNS problem. (where "b)" was non-enumeration.) non-enumeration as a baseline for what confidentiality means is instructive. the folks i've spoken to who care about this characterize it as "if you know the domain name exists you should be able to retrieve data about it, else not." and when faced with the "rrtype" question, they universally amend it to say "and if you know what rrtypes exist you should be able to ask for rdata, else not." so, confidentiality doesn't have to mean "if you know something that only a friend or customer or supplier would normally know then you can retrieve data about this domain, else not". but it probably would mean "if you're not the initiator but you happen to be able to monitor the transaction in flight, you should not learn any names or data". this is the second tricky part after non-enumerability, and seems to imply a full DH preauth between each initiator/responder pair. yow! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Jun 6 07:25:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25834 for <dnsext-archive@lists.ietf.org>; Sun, 6 Jun 2004 07:25:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWvjV-0000BQ-D4 for namedroppers-data@psg.com; Sun, 06 Jun 2004 11:22:33 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWvjU-0000B9-2c for namedroppers@ops.ietf.org; Sun, 06 Jun 2004 11:22:32 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C69531FDCB; Sun, 6 Jun 2004 12:22:30 +0100 (BST) Date: Sun, 06 Jun 2004 12:22:29 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: dns & confidentiality? Message-ID: <71F896EA375B3FF047640140@[192.168.100.19]> In-Reply-To: <20040606083408.BB5D7139A3@sa.vix.com> References: <20040606083408.BB5D7139A3@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 06 June 2004 08:34 +0000 Paul Vixie <paul@vix.com> wrote: >> For NL it was b) and only b), and it was also recognised that, >> indeed, it is a whois and not a DNS problem. > > (where "b)" was non-enumeration.) I think actually (c) was non-enumeration, but... > non-enumeration as a baseline for what confidentiality means is > instructive. the folks i've spoken to who care about this characterize it > as "if you know the domain name exists you should be able to retrieve > data about it, else not." and when faced with the "rrtype" question, they > universally amend it to say "and if you know what rrtypes exist you > should be able to ask for rdata, else not." ..and that is Nominet's concern; I don't think the rest is. > so, confidentiality doesn't have to mean "if you know something that only > a friend or customer or supplier would normally know then you can retrieve > data about this domain, else not". agreed > but it probably would mean "if you're not the initiator but you happen to > be able to monitor the transaction in flight, you should not learn any > names or data". this is the second tricky part after non-enumerability, > and seems to imply a full DH preauth between each initiator/responder > pair. yow! What this does is add privacy to the DNS transaction, as opposed to add confidentiality to the zone. (by which I mean here preventing nameservers themselves from publishing the zone in its entirety, which is what we want to achieve); this seems to me an orthogonal requirement (and not a requirement of ours, though I can see it might be something others might wish for). Why is it orthogonal? Firstly, for the practical reason that at least some of those worried about enumerability are concerned about (a) the zone as a whole (and not 'inferences' as to contents of the zone), and (b) making DNSSEC "no worse" than life with current DNS implementations. With regard to both of these points, current DNS can be snooped in flight, as can the transactions likely to follow immediately (HTTP, SMTP etc.); so it's not immediately obvious transaction privacy either fixes anything that DNSSECbis "broke", or that in practice it would actually add any privacy. Secondly, in a technical sense, it's possible to have transaction privacy without enumeration and vice-versa - i.e. there is no algorithmic linkage I can seem. Thirdly, qualitatively they just seem different to me. Fourthly, from a practical point of view, privacy is going to require a pre-auth of some sort, which is then going to bring up the question "what if I want to authorize some people and not others", and this is additional layers of protocol development well beyond NSEC2/NO/whatever. So I'm not sure the two should be linked; neither am I sure that transaction privacy isn't better addressed through (for instance) DNS over TLS (or for that matter IPSEC), which, as far as I can tell, would fully deal with this issue at the cost of a couple of sentences in a standard, but not touch on enumerability. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Jun 6 11:13:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04652 for <dnsext-archive@lists.ietf.org>; Sun, 6 Jun 2004 11:13:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWzF1-0002vK-JX for namedroppers-data@psg.com; Sun, 06 Jun 2004 15:07:19 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWzEz-0002uW-55 for namedroppers@ops.ietf.org; Sun, 06 Jun 2004 15:07:17 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 11BCB1FF82D; Sun, 6 Jun 2004 15:07:15 +0000 (GMT) Message-ID: <40C33322.4010403@algroup.co.uk> Date: Sun, 06 Jun 2004 16:07:14 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? References: <20040606083408.BB5D7139A3@sa.vix.com> In-Reply-To: <20040606083408.BB5D7139A3@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > red wrote: > > >>For NL it was b) and only b), and it was also recognised that, >>indeed, it is a whois and not a DNS problem. > > > (where "b)" was non-enumeration.) > > non-enumeration as a baseline for what confidentiality means is instructive. > the folks i've spoken to who care about this characterize it as "if you know > the domain name exists you should be able to retrieve data about it, else not." > and when faced with the "rrtype" question, they universally amend it to say > "and if you know what rrtypes exist you should be able to ask for rdata, else > not." > > so, confidentiality doesn't have to mean "if you know something that only a > friend or customer or supplier would normally know then you can retrieve > data about this domain, else not". > > but it probably would mean "if you're not the initiator but you happen to be > able to monitor the transaction in flight, you should not learn any names or > data". this is the second tricky part after non-enumerability, and seems to > imply a full DH preauth between each initiator/responder pair. yow! Hmmm, not necessarily DH. And, indeed, DH would not prevent active 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 Sun Jun 6 13:11:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09383 for <dnsext-archive@lists.ietf.org>; Sun, 6 Jun 2004 13:11:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BX18C-0004c2-On for namedroppers-data@psg.com; Sun, 06 Jun 2004 17:08:24 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BX18B-0004bm-KE for namedroppers@ops.ietf.org; Sun, 06 Jun 2004 17:08:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2292713DED for <namedroppers@ops.ietf.org>; Sun, 6 Jun 2004 17:08:23 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Sun, 06 Jun 2004 12:22:29 +0100." <71F896EA375B3FF047640140@[192.168.100.19]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 06 Jun 2004 17:08:23 +0000 Message-Id: <20040606170823.2292713DED@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > > but it probably would mean "if you're not the initiator but you happen to > > be able to monitor the transaction in flight, you should not learn any > > names or data". this is the second tricky part after non-enumerability, > > and seems to imply a full DH preauth between each initiator/responder > > pair. yow! > > What this does is add privacy to the DNS transaction, as opposed to add > confidentiality to the zone. (by which I mean here preventing nameservers > themselves from publishing the zone in its entirety, which is what we want > to achieve); this seems to me an orthogonal requirement (and not a > requirement of ours, though I can see it might be something others might > wish for). i understood that this is not one of nominet's concerns. however, if we're going to reconsider the basic design and threat model of dnssec for -TER, then it's going to be necessary to survey the community to find out what else really matters and to whom. > Why is it orthogonal? ... i agree that transaction secrecy is orthogonal to zone confidentiality, but both are part of the general field of "things dnssec doesn't do" and i expect that a proper field survey will turn up *both* as requirements for -TER. > So I'm not sure the two should be linked; neither am I sure that > transaction privacy isn't better addressed through (for instance) DNS > over TLS (or for that matter IPSEC), which, as far as I can tell, > would fully deal with this issue at the cost of a couple of sentences > in a standard, but not touch on enumerability. if privacy can be handled with tls or ipsec then so be it -- but for now, my goal is to "get everybody's concerns out onto the table." for -TER, "opt-in" might come back for another round of debate. those of you arguing for NSEC2 might by now be realizing that you should "be careful what you wish for." a reconsideration of the design goals and threat model of dnssec could draw in features beyond non-enumerability of zone data. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Jun 6 13:54:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10987 for <dnsext-archive@lists.ietf.org>; Sun, 6 Jun 2004 13:54:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BX1of-000FcE-Gy for namedroppers-data@psg.com; Sun, 06 Jun 2004 17:52:17 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BX1oe-000Fbn-0m for namedroppers@ops.ietf.org; Sun, 06 Jun 2004 17:52:16 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 332241FE67; Sun, 6 Jun 2004 18:52:15 +0100 (BST) Date: Sun, 06 Jun 2004 18:52:13 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: dns & confidentiality? Message-ID: <5D86E3AE9519E7E9551F0917@[192.168.100.19]> In-Reply-To: <20040606170823.2292713DED@sa.vix.com> References: <20040606170823.2292713DED@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 06 June 2004 17:08 +0000 Paul Vixie <paul@vix.com> wrote: > i agree that transaction secrecy is orthogonal to zone confidentiality, > but both are part of the general field of "things dnssec doesn't do" and > i expect that a proper field survey will turn up *both* as requirements > for -TER. > > if privacy can be handled with tls or ipsec then so be it -- but for now, > my goal is to "get everybody's concerns out onto the table." for -TER, > "opt-in" might come back for another round of debate. I agree we should do a proper survey etc., and I am not suggesting your question was not worth asking. We should indeed get everyone's concerns on the table. However, I think we should draw a distinction between "requirements" in the general sense, and "requirements for -ter", for at least 2 reasons: 1. Some requirements can be, should be, and/or are already addressed by things other than -ter. For instance TLS. The wonders of layered protocols mean we don't have to reinvent the wheel. 2. Even were that not the case for all such requirements, not every problem has to be solved in -ter, for precisely the same reasons you forcefully argued that not every problem has to be solved in -bis. You have argued, for instance, that NSEC2 is a significant change. However, it is nothing like as significant a change as a change to DNS (*) addressing requirement for privacy requiring pre-auth (for instance). (*) = I am distinguishing this from mere use of another layer. > those of you arguing for NSEC2 might by now be realizing that you should > "be careful what you wish for." a reconsideration of the design goals > and threat model of dnssec could draw in features beyond > non-enumerability of zone data. Those of us (well, at least one of us) arguing for NSEC2 (or more accurately arguing for non-enumerability) would in an ideal world have liked it addressed in -bis. "in an ideal world" can be taken to mean "had the issue - i.e. the threat model - been raised with sufficient volume sufficiently early". That does not necessarily mean that those same people would necessarily support extending the threat model in any (let alone every) other way. Indeed one of the benefits of reevaluating the threat model (as I think you are proposing) would be to formally discount certain extensions and document why such extensions to the design criteria should be discounted; and/or to decide and document which modifications go in which incremental stages at the start of the design process rather than midway through or at the end. So I for one am not (yet) regretting what I wish(ed) for. One as-yet-unmentioned advantage to sending DNSSECbis to the IESG as-is (over trying to fix enumerability now), is that it can only help lead to early exposure of code and thus can only increase the exposure to the protocol to peer review. And if that brings out protocol (as opposed to code) nits, and -ter is designed to be a small incremental change, then -ter can be used to fix these too. This is going to be lost if -ter turns out to be a proposal for a major rewrite. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Jun 6 16:22:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18262 for <dnsext-archive@lists.ietf.org>; Sun, 6 Jun 2004 16:22:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BX458-000MVB-JG for namedroppers-data@psg.com; Sun, 06 Jun 2004 20:17:26 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BX457-000MUu-DW for namedroppers@ops.ietf.org; Sun, 06 Jun 2004 20:17:25 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 7F76F1FF82D; Sun, 6 Jun 2004 20:17:23 +0000 (GMT) Message-ID: <40C37BD2.3000500@algroup.co.uk> Date: Sun, 06 Jun 2004 21:17:22 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh <alex@alex.org.uk> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? References: <20040606170823.2292713DED@sa.vix.com> <5D86E3AE9519E7E9551F0917@[192.168.100.19]> In-Reply-To: <5D86E3AE9519E7E9551F0917@[192.168.100.19]> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 06 June 2004 17:08 +0000 Paul Vixie <paul@vix.com> wrote: > >> i agree that transaction secrecy is orthogonal to zone confidentiality, >> but both are part of the general field of "things dnssec doesn't do" and >> i expect that a proper field survey will turn up *both* as requirements >> for -TER. >> >> if privacy can be handled with tls or ipsec then so be it -- but for now, >> my goal is to "get everybody's concerns out onto the table." for -TER, >> "opt-in" might come back for another round of debate. > > > I agree we should do a proper survey etc., and I am not suggesting > your question was not worth asking. We should indeed get everyone's > concerns on the table. > > However, I think we should draw a distinction between "requirements" > in the general sense, and "requirements for -ter", for at least 2 > reasons: > > 1. Some requirements can be, should be, and/or are already addressed > by things other than -ter. For instance TLS. The wonders of layered > protocols mean we don't have to reinvent the wheel. It isn't quite that easy - TLS is a TCP protocol, so moving to it would prohibit the use of UDP in DNS. There isn't (yet) a UDP equivalent. 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 Sun Jun 6 20:29:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27803 for <dnsext-archive@lists.ietf.org>; Sun, 6 Jun 2004 20:29:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BX7kl-000Pcl-Rl for namedroppers-data@psg.com; Mon, 07 Jun 2004 00:12:39 +0000 Received: from [61.95.66.138] (helo=mail.mel.netstarnetworks.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BX7kj-000PcE-Fo for namedroppers@ops.ietf.org; Mon, 07 Jun 2004 00:12:37 +0000 Received: from mindrot.org (35.195.20.10.dhcp.netstarnetworks.com [10.20.195.35] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id i570DmJ12844 for <namedroppers@ops.ietf.org>; Mon, 7 Jun 2004 10:13:49 +1000 Message-ID: <40C3B2EC.6040708@mindrot.org> Date: Mon, 07 Jun 2004 10:12:28 +1000 From: Damien Miller <djm@mindrot.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? References: <20040606083408.BB5D7139A3@sa.vix.com> <40C33322.4010403@algroup.co.uk> In-Reply-To: <40C33322.4010403@algroup.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Laurie wrote: > Hmmm, not necessarily DH. And, indeed, DH would not prevent active attacks. It wouldn't help against traffic analysis either. Much may be inferred by simply observing the lengths and timings of packets, let alone their destinations. -d -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 7 03:39:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29096 for <dnsext-archive@lists.ietf.org>; Mon, 7 Jun 2004 03:39:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXEcM-000Ok3-FC for namedroppers-data@psg.com; Mon, 07 Jun 2004 07:32:26 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXEcI-000OjH-F1 for namedroppers@ops.ietf.org; Mon, 07 Jun 2004 07:32:22 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 66B304FCD6; Mon, 7 Jun 2004 09:08:27 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 537484FCD1 for <namedroppers@ops.ietf.org>; Mon, 7 Jun 2004 09:08:26 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i5778Qm0023960 for <namedroppers@ops.ietf.org>; Mon, 7 Jun 2004 09:08:26 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i5778Q7o023830 for namedroppers@ops.ietf.org; Mon, 7 Jun 2004 09:08:26 +0200 Received: from [140.239.227.14] (helo=Mail.MAP-NE.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXC8k-000MWw-Sf for namedroppers@ops.ietf.org; Mon, 07 Jun 2004 04:53:42 +0000 Received: by Mail.MAP-NE.com (Postfix, from userid 105) id 8A9EC3F746; Mon, 7 Jun 2004 00:53:42 -0400 (EDT) To: namedroppers@ops.ietf.org Subject: Preventing enumeration with the CURRENT DNSSECbis specification From: "Michael A. Patton" <MAP@MAP-NE.com> Message-Id: <20040607045342.8A9EC3F746@Mail.MAP-NE.com> Date: Mon, 7 Jun 2004 00:53:42 -0400 (EDT) X-RIPE-Spam-Status: U 0.498752 / 0.0 / 0.0 / disabled X-RIPE-Signature: bdf42a17cd1910de5f6637e8f91c6e0d X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either because it was posted by a non-subscriber or because it contained to many characters (> 20000). With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please fix your subscription addresses or shorten your postings by adding links instead of attachments ] Disclaimer: I think the WG needs to concentrate on getting the current specs finished and out. I thus hesitate to add yet another idea for fixing NSEC, but felt that I needed to get this written down and out for other eyes to see before I lost the idea. So, please don't stop work on the current docs, but if you otherwise have some time, I'd appreciate any input. This is all only half-baked so far, so it's not clear how tasty it will be when it finally comes out of the oven. But, unless we finish cooking it, we'll never know. :-) It occurred to me during that semi-hallucinatory period between waking and full consciousness this morning. However, I've been thinking about it on and off for about 19 hours and it seems even better now than when it first occurred to me, so I thought I should commit it to bits. This scheme is entirely an "implementation detail" and requires no change to the protocol and docs as they presently exist. However, there is one potential improvement that can be added to the existing spec (after suitable time to finish baking) that might improve things, but it can be reasonably done later and should not hold up current work. This scheme does involve a tradeoff, but for zones that couldn't deploy DNSSEC at all without it, the tradeoff should be a no-brainer. The scheme comes in two parts: The first idea is not especially novel, I've had it in the back of my head ever since the initial discussions of NO, and it seems sufficiently obvious that I expect others have had it, too. It seems simple for implementations to have a configuration to eliminate (or possibly restrict to a small number of "debugging" hosts) direct retrieval of NSEC RRs. In normal use there is no reason to retrieve these, they only exist as a means for the zone to prove that some other queried name doesn't exist. This is analogous to the way implementations can already limit AXFR by means outside the protocol, and just applies to QTYPE=NSEC rather than QTYPE=AXFR. The reason I never mentioned it before is that, by itself, it only complicates the attacks by a small amount. The reason I mention it now is that it helps the main scheme, and was part of the inspiration for it. The inspiration was from realizing that the major problem with NSEC records is that each one gives away TWO valid names. Now, the main idea is to have an option in the auth servers that generates synthetic NSEC records for each negative answer. This NSEC would cover as small a piece of the name space as possible, in fact only the one name queried for. Furthermore both names in the NSEC are themselves invalid in essentially all cases (the "next" might accidentally be a valid name, but since it's algorithmically derived it doesn't give the attacker any information). The tradeoff comes here, this would only work if the key to sign these was online (more on this later) since you only get authenticated denial when the NSEC has an accompanying RRSIG. Say for example, you are running the server for the TLD xx. and get a query for foo.xx. which doesn't exist. You return a NSEC with foo.xx. as the owner name, _none_ of the type bits set, and the next name field set to the next _possible_ name. Thus this NSEC denies the existence of one name (well, to be pedantic it says the name exists, but that there are no RRs), and gives no information about any legal names. The thing that might seem hard is generating the next possible name, but that's simply the same name as the owner, with one additional zero byte in the first label (unless the label is already 63 bytes long, in which case increment the last byte, overflowing into earlier bytes). This name is not a host name (in fact, it's probably non-existent), so the non-ASCII character doesn't matter. You also need to generate and return an RRSIG for this NSEC, thus such a zone would need to run with (at least one) key online. Therefore, for zones that have a non-disclosure requirement, the tradeoff is between not running DNSSEC at all or running it with an online key. Presumably, since they have that requirement (and for many other reasons), they are already being very careful with security of all their auth servers, this tradeoff should be pretty simple. Any attack that could compromise the online key could have done as much damage if they hadn't deployed DNSSEC at all, and anything short of that can't compromise the secured zone, but might compromise the unsecured one. Thus while not as secure as "standard" DNSSEC, it's much better than the defalut unsecured operation and "almost" as good as full DNSSEC (operationally the same, with the extra exposure of the online key). The exposure of having an online key could even be alleviated by having multiple keys for the zone: a set that changes very slowly, is kept off-line and is used for the signing of the positive info; and a second set, changed more often, with shorter lifetime, used only for signing the NSEC responses. With this scheme, the exposure in the case of a compromise of the online key is limited by its shorter lifetime, but the bulk of the zone, signed with the longer lived and more securely held key, doesn't need to be signed any more often. There would be some additional administrative overhead to manage the extra short-lived key(s), either you need to generate and distribute the private part to all servers, or you could have one in each server that it generates itself, and then updates (with dynamic update and TSIG?) the public part at the master. The first has only one key, but requires moving the private part over the net, while the later has some added exposure from multiple keys, but never passes the private parts over the net... The one thing that might be added to the existing specs (later, not now) that would help out here is allocating one of the 14 unused flag bits in the DNSKEY RR to convey the intent of only signing NSECs. By doing this, resolvers that understand the bit would be even more immune to compromises of the online key, the compromised key could only be used for invalidating existing delegations, and would be ignored for positive data, thus eliminating the possibility of introducing new authenticated data using that key. -MAP -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 7 03:54:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29674 for <dnsext-archive@lists.ietf.org>; Mon, 7 Jun 2004 03:54:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXEup-0001z3-PL for namedroppers-data@psg.com; Mon, 07 Jun 2004 07:51:31 +0000 Received: from [192.134.4.152] (helo=maya20.nic.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXEuo-0001yi-Hk for namedroppers@ops.ietf.org; Mon, 07 Jun 2004 07:51:30 +0000 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i577pTFq1554778; Mon, 7 Jun 2004 09:51:29 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id DC777FBB4; Mon, 7 Jun 2004 09:51:28 +0200 (CEST) Date: Mon, 7 Jun 2004 09:51:28 +0200 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org Subject: Re: dns & confidentiality? Message-ID: <20040607075128.GA2586@nic.fr> References: <20040604174922.GE6604@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040604174922.GE6604@vacation.karoshi.com.> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.26-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Fri, Jun 04, 2004 at 05:49:22PM +0000, bmanning@vacation.karoshi.com <bmanning@vacation.karoshi.com> wrote a message of 19 lines which said: > should the DNS and the data it holds be considered confidential? To me, no, *but* access to one record (a typical DNS query) is *not* the same thing as bulk access to all the records (AXFR or zone walking). Many people seem to have trouble understanding the difference or are concerned only with performance problems (see Paul Vixie's example of AXFR in ".com" for a good example of why performance is not so big a problem). But the difference is not technical: with individual access, the amount of damage you can do is inferior. That's all. That why several laws (for instance, in France, the law "Informatique et Libertés" - Data processing and Freedom) have different provisions for individual access and bulk access. To summary, individual access does not need confidentiality (at least not in the current DNS framework, adding it would mean a huge change in the DNS model) but bulk access should be restrictable (ACL in BIND, for instance). If it is not restrictable, it means forcing a political decision via a technical standard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 7 04:54:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02075 for <dnsext-archive@lists.ietf.org>; Mon, 7 Jun 2004 04:54:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXFqg-000D4b-5g for namedroppers-data@psg.com; Mon, 07 Jun 2004 08:51:18 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXFqc-000D42-Rf for namedroppers@ops.ietf.org; Mon, 07 Jun 2004 08:51:15 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i573ZFBS008610; Sun, 6 Jun 2004 20:35:15 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <KNPWF43P>; Sun, 6 Jun 2004 20:35:15 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E5DBD77@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Ben Laurie'" <ben@algroup.co.uk>, Alex Bligh <alex@alex.org.uk> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: RE: dns & confidentiality? Date: Sun, 6 Jun 2004 20:35:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It isn't quite that easy - TLS is a TCP protocol, so moving > to it would > prohibit the use of UDP in DNS. There isn't (yet) a UDP equivalent. TransportLayer Security in a datagram protocol... It would not take much to add TLS like functionality though, just add a key exchange to the protocol, then use TSIG for authentication. If you need confidentiality add an AES encryption envelope, just make sure you leave enough useful information on the envelope. It could be run over UDP without problems. The main challenge would be avoiding DoS attack - although that can be mitigated by simply allowing use of stale key material if the key server is unavailable. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 7 05:19:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03314 for <dnsext-archive@lists.ietf.org>; Mon, 7 Jun 2004 05:19:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXGFg-000IDW-KD for namedroppers-data@psg.com; Mon, 07 Jun 2004 09:17:08 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXGFe-000IB2-Mp for namedroppers@ops.ietf.org; Mon, 07 Jun 2004 09:17:06 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i579Gwrd006195; Mon, 7 Jun 2004 10:16:58 +0100 (BST) To: "Michael A. Patton" <MAP@MAP-NE.com> cc: namedroppers@ops.ietf.org Subject: Re: Preventing enumeration with the CURRENT DNSSECbis specification In-Reply-To: Message from "Michael A. Patton" <MAP@MAP-NE.com> of "Mon, 07 Jun 2004 00:53:42 EDT." <20040607045342.8A9EC3F746@Mail.MAP-NE.com> Date: Mon, 07 Jun 2004 10:16:58 +0100 Message-ID: <6194.1086599818@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Disclaimer: I am not a cryptographer and therefore don't know what I'm talking about. Synthesising NSEC records and signing them on the fly seems to be a Very Bad Idea. It would allow the People In Black Hats to make a chosen cleartext attack on the key. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 7 10:12:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17565 for <dnsext-archive@lists.ietf.org>; Mon, 7 Jun 2004 10:12:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXKml-000EM6-Hk for namedroppers-data@psg.com; Mon, 07 Jun 2004 14:07:35 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXKmk-000ELp-RP for namedroppers@ops.ietf.org; Mon, 07 Jun 2004 14:07:34 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 17AE213960; Mon, 7 Jun 2004 14:07:31 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: "Michael A. Patton" <MAP@MAP-NE.com> Cc: namedroppers@ops.ietf.org Subject: Re: Preventing enumeration with the CURRENT DNSSECbis specification In-Reply-To: Message from "Michael A. Patton" <MAP@MAP-NE.com> of "Mon, 07 Jun 2004 00:53:42 -0400." <20040607045342.8A9EC3F746@Mail.MAP-NE.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 07 Jun 2004 14:07:31 +0000 Message-Id: <20040607140731.17AE213960@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk michael, the problem with this approach is precomputation. just as in normal security protocol design you don't want an attacker to be able to use precomputation, in dnssec we want the authority servers to be able to use precomputation. if we take precomputation away from the authority server, then the ddos bottleneck shifts from the network interface (or upstreams) to the cpu (or crypto engine). while online keys would be fun and i'd enjoy the challenge of generating point-NSECs on the fly rather than precomputing range-NSECs as we do now, this is just not a recommendable approach to anyone concerned about zone walking. --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 Mon Jun 7 10:49:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21491 for <dnsext-archive@lists.ietf.org>; Mon, 7 Jun 2004 10:49:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXLNe-000KjO-3w for namedroppers-data@psg.com; Mon, 07 Jun 2004 14:45:42 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXLNa-000Kj4-S8 for namedroppers@ops.ietf.org; Mon, 07 Jun 2004 14:45:39 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 52EDE55F10; Mon, 7 Jun 2004 16:45:38 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id F33834E2D6 for <namedroppers@ops.ietf.org>; Mon, 7 Jun 2004 16:45:37 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i57Ejbm0006253 for <namedroppers@ops.ietf.org>; Mon, 7 Jun 2004 16:45:37 +0200 Date: Mon, 7 Jun 2004 16:45:37 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: Working Group Process: Radio Silence Message-Id: <20040607164537.27b0d3fc.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000001 / 0.0 / 0.0 / disabled X-RIPE-Signature: 0bbda41677323797c659f0bf6989984a X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, Except for the issue on which Peter, Roy, and Jakob work we want radio silence until the DNSSECbis docs are out of the door. This is really to improve the signal to noise ratio. Please start _thinking_ about your requirements for confidentiality, preventing zone enumeration and such. Don't start _voicing_ them yet. Sit back and let the grey cells work. We would like to see those requirements discussed and enumerated on namedroppers in a few weeks (say beginning July) As for the more practical issues on NSEC2 or want to discuss "half-baked" ideas please please go to the dnssec@cafax.se list. (Which is referred to in our charter) We'll ask a volunteer to summarize the discussions that took place on this list and will take place on the cafax list once we have the requirements in place. At that point we can bring the discussion back to namedroppers. Once we have the requirement and we have a the summary of the technical pitfalls we can see where we can match requirements and solutions. This is the point where we can have a useful face-2-face in San Diego where we plan to have at least some 45 minutes allocated to this discussion. So concluding: In order to be more effective - Please hold back on "requirement discussions" - Please move _technical_ discussions on NSEC2 to dnssec@cafax.se - Please do pay attention to the "transition issue" -- Olaf & Olafur DNSEXT WG chairs -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 9 07:14:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09085 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 07:14:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY0ww-000C7Q-S5 for namedroppers-data@psg.com; Wed, 09 Jun 2004 11:08:54 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY0wv-000C6z-DF for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 11:08:53 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id BE43F1FF848 for <namedroppers@ops.ietf.org>; Wed, 9 Jun 2004 11:08:47 +0000 (GMT) Message-ID: <40C6EFBF.2010707@algroup.co.uk> Date: Wed, 09 Jun 2004 12:08:47 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Philosophy behind unsigned NS records? X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Contemplation of issues related to NSEC2 has made me wonder why NS records are not signed at the delegation point. I realise that they are not authoritative at that point, but it seems to me that there's a (small) win gained in the case where the nameservers are in a signed zone but the zone being delegated is not signed (which is probably quite a common scenario in the early days of DNSSEC). Did I miss something? 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 Wed Jun 9 09:23:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13734 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 09:23:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY2zh-0009ea-AC for namedroppers-data@psg.com; Wed, 09 Jun 2004 13:19:53 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY2zg-0009eJ-0F for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 13:19:52 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i59DISkZ011890 for <namedroppers@ops.ietf.org>; Wed, 9 Jun 2004 09:18:28 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i59DIF4A013728 for <namedroppers@ops.ietf.org>; Wed, 9 Jun 2004 09:18:15 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: "DNSEXT WG" <namedroppers@ops.ietf.org> Subject: RE: Philosophy behind unsigned NS records? Date: Wed, 9 Jun 2004 09:18:15 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGKENLCKAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <40C6EFBF.2010707@algroup.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not sure what you mean here. What would that gain us? If I get it right, a delegation to an unsecure child would look like: Answer section: blank Authority section: sub.example.com NS RRSIG (NS) Additional ns.sub.example.com A hash__sub.example.com NSEC2 bitmap w/o DS RR. There still needs to be some information about the DS, or lack thereof. I don't see what signing the NS set gains us with this. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Ben Laurie > Sent: Wednesday, June 09, 2004 7:09 AM > To: DNSEXT WG > Subject: Philosophy behind unsigned NS records? > > > Contemplation of issues related to NSEC2 has made me wonder why NS > records are not signed at the delegation point. > > I realise that they are not authoritative at that point, but it seems to > me that there's a (small) win gained in the case where the nameservers > are in a signed zone but the zone being delegated is not signed (which > is probably quite a common scenario in the early days of DNSSEC). Did I > miss something? > > 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 Wed Jun 9 11:09:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19230 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 11:09:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY4d2-0001Nt-8p for namedroppers-data@psg.com; Wed, 09 Jun 2004 15:04:36 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY4d1-0001NS-Cc for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 15:04:35 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 343D31FF845; Wed, 9 Jun 2004 15:04:34 +0000 (GMT) Message-ID: <40C72701.2090502@algroup.co.uk> Date: Wed, 09 Jun 2004 16:04:33 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? References: <ANECIHCPCBDLLEJLCOPGKENLCKAA.scottr@nist.gov> In-Reply-To: <ANECIHCPCBDLLEJLCOPGKENLCKAA.scottr@nist.gov> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > Not sure what you mean here. What would that gain us? If I get it right, a > delegation to an unsecure child would look like: > > Answer section: > blank > Authority section: > sub.example.com NS > RRSIG (NS) > Additional > ns.sub.example.com A > hash__sub.example.com NSEC2 bitmap w/o DS RR. > > There still needs to be some information about the DS, or lack thereof. I > don't see what signing the NS set gains us with this. It means that the delegation can't be spoofed. Note that the delegation could be to a nameserver in a signed domain, and so its A record could also not be spoofed. 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 Wed Jun 9 11:42:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22585 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 11:42:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY59o-0007Xi-LU for namedroppers-data@psg.com; Wed, 09 Jun 2004 15:38:28 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY59n-0007XE-HR for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 15:38:27 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i59FcCcF057976; Wed, 9 Jun 2004 17:38:13 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i59Fc8Qo027791; Wed, 9 Jun 2004 17:38:08 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i59Fc7sS027788; Wed, 9 Jun 2004 17:38:07 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 9 Jun 2004 17:38:07 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: Scott Rose <scottr@nist.gov>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? In-Reply-To: <40C72701.2090502@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406091713570.2889@elektron.atoom.net> References: <ANECIHCPCBDLLEJLCOPGKENLCKAA.scottr@nist.gov> <40C72701.2090502@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 9 Jun 2004, Ben Laurie wrote: > Scott Rose wrote: > > Not sure what you mean here. What would that gain us? If I get it right, a > > delegation to an unsecure child would look like: > > > > Answer section: > > blank > > Authority section: > > sub.example.com NS > > RRSIG (NS) > > Additional > > ns.sub.example.com A > > hash__sub.example.com NSEC2 bitmap w/o DS RR. > > > > There still needs to be some information about the DS, or lack thereof. I > > don't see what signing the NS set gains us with this. > > It means that the delegation can't be spoofed. Note that the delegation > could be to a nameserver in a signed domain, and so its A record could > also not be spoofed. A security aware caching resolver would overwrite non-authoritative signed data with authoritative unsigned data in this case. Delegation point NS records (and optional glue address records) are authoritative elsewhere, so they'd need to be signed elsewhere. The additional cost of delegation point signatures are placed on the parent, while the gain is minimal. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 9 11:48:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22984 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 11:48:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY5HA-0009G6-AK for namedroppers-data@psg.com; Wed, 09 Jun 2004 15:46:04 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY5H9-0009Fo-2A for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 15:46:03 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 09 Jun 2004 11:46:01 -0400 id 0013BB8E.40C730B9.00007769 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Wed, 9 Jun 2004 11:46:01 -0400 User-Agent: KMail/1.6.2 References: <40BDCD26.4050808@ripe.net> <9923.1086239649@toybsd.zl2tnm.gen.nz> <20040603152327.6de24e15.olaf@ripe.net> In-Reply-To: <20040603152327.6de24e15.olaf@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406091146.01973.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 03 June 2004 9:23 am, Olaf M. Kolkman wrote: > Back to this thread, I think the bottom line is that we would like our > caches to be transperant to changes in the authoritative zone. Is this > a suggestion we can all live with (taking the original text and > extending it with an explanation)., I think what we are really trying to do is to not introduce any new, surprising cache behavior. That is, even though DNSSEC permits it, we don't want caches to suddenly start negative caching differently (and more aggressively) or synthesizing wildcards on its own. > A security-aware resolver SHOULD cache each response as a single > atomic entry containing the entire answer, including the named > RRset and any associated DNSSEC RRs. The resolver SHOULD discard > the entire atomic entry when any of the RRs contained in it expire. > In most cases the appropriate cache index for the atomic entry will > be the triple <QNAME, QTYPE, QCLASS>, but in cases such as the > response form described in Section 3.1.3.2 the appropriate cache > index will be the double <QNAME,QCLASS>. > > The reason for these recommendations is that between the initial > query and the expiration of the data from the cache the > authoritative data could have been changed, for instance through > dynamic updates. > > There are two situation for which this is relevant. > > 1. By using the RRSIG record it is possible to deduce an answer is > synthesized from a wildcard. The security aware caching nameserver > could store this wildcard data and use it to generate responses to > for queries other than the name for which the answer was first > received. > > 2. NSEC RRs received to proof the nonexistence of a name could be > re-usec by the cache to proof the non-existence of any name in the > name range it spans. > > Although technically a wildcard to generate answers and an NSEC RR > can be used to proof the nonexistence of names an types during the > signature validity period, it seems prudent that that caches do not > block newly appeared data. Caches following this recommendation > will have a consistent view on the namespace. Adding this text is, IMO, better than doing nothing. However, it doesn't really address my original points, which are, essentially, that caching entire answers, while elegant, goes too far. I still think a better solution here is to explain what caches SHOULD NOT (or MUST NOT) do. If I can, I will try and submit language like this, and the WG can decide which it prefers. -- 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 Wed Jun 9 13:29:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00964 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 13:29:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY6p0-0002gv-Lr for namedroppers-data@psg.com; Wed, 09 Jun 2004 17:25:06 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY6ow-0002gA-Ez for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 17:25:02 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1C0FF13DE5 for <namedroppers@ops.ietf.org>; Wed, 9 Jun 2004 17:25:02 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 09 Jun 2004 16:04:33 +0100." <40C72701.2090502@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 09 Jun 2004 17:25:02 +0000 Message-Id: <20040609172502.1C0FF13DE5@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... > > There still needs to be some information about the DS, or lack > > thereof. I don't see what signing the NS set gains us with this. > > It means that the delegation can't be spoofed. the threat in this case is being delegated toward a serverset who can't sign its responses with the key denoted by the parent's DS. this is a denial of service attack, but it would be easier to launch one using congestion than by query-id guessing. > Note that the delegation could be to a nameserver in a signed domain, > and so its A record could also not be spoofed. none of that matters. the responding subdomain servers can either sign its responses using the key given in the parent-DS, or it can't. no amount of NS-signing by the parent will cause a third alternative to appear. at first glance there appears to be an opportunity to improve the situation by offering trusted delegations to unsecure zones. however, this just moves the query-id guessing attack down one level. if the subdomain zones are not secure, then it doesn't help that the parent-NS that delegates to them is signed and trustworthy. dnssec isn't just end-to-end, it's root-to-leaf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 9 14:17:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06357 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 14:17:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY7Yi-000CX3-Ke for namedroppers-data@psg.com; Wed, 09 Jun 2004 18:12:20 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY7Yh-000CWN-Bz for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 18:12:19 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 561741FF845; Wed, 9 Jun 2004 18:12:18 +0000 (GMT) Message-ID: <40C75301.1090004@algroup.co.uk> Date: Wed, 09 Jun 2004 19:12:17 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? References: <20040609172502.1C0FF13DE5@sa.vix.com> In-Reply-To: <20040609172502.1C0FF13DE5@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>... >>>There still needs to be some information about the DS, or lack >>>thereof. I don't see what signing the NS set gains us with this. >> >>It means that the delegation can't be spoofed. > > > the threat in this case is being delegated toward a serverset who can't sign > its responses with the key denoted by the parent's DS. this is a denial of > service attack, but it would be easier to launch one using congestion than > by query-id guessing. The assumption was that there would be no DS. >>Note that the delegation could be to a nameserver in a signed domain, >>and so its A record could also not be spoofed. > > > none of that matters. the responding subdomain servers can either sign its > responses using the key given in the parent-DS, or it can't. no amount of > NS-signing by the parent will cause a third alternative to appear. > > at first glance there appears to be an opportunity to improve the situation > by offering trusted delegations to unsecure zones. however, this just moves > the query-id guessing attack down one level. if the subdomain zones are not > secure, then it doesn't help that the parent-NS that delegates to them is > signed and trustworthy. > > dnssec isn't just end-to-end, it's root-to-leaf. Well, there may be other reasons to rely on the nameserver (or avoid spoofing thereof) - for example, it is at the other end of some IPSEC or VPN authentication, or it is inside a trusted network. 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 Wed Jun 9 14:23:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06683 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 14:23:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY7gG-000E7A-52 for namedroppers-data@psg.com; Wed, 09 Jun 2004 18:20:08 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY7gF-000E6n-5E for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 18:20:07 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 868DD19B4D7; Wed, 9 Jun 2004 14:12:12 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 56C0C19B580 for <namedroppers@ops.ietf.org>; Wed, 9 Jun 2004 14:12:10 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1751688; Wed, 09 Jun 2004 14:20:03 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020429bced05211f53@[192.136.136.83]> Date: Wed, 9 Jun 2004 14:20:10 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: Re: Philosophy behind unsigned NS records? Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (Earlier I sent this privately to Ben because my "radio" was turned off.) At 12:08 +0100 6/9/04, Ben Laurie wrote: >Contemplation of issues related to NSEC2 has made me wonder why NS records are >not signed at the delegation point. > >I realise that they are not authoritative at that point, but it seems to me >that there's a (small) win gained in the case where the nameservers are in a >signed zone but the zone being delegated is not signed (which is probably >quite a common scenario in the early days of DNSSEC). Did I miss something? RFC 2065-era assumption: only authoritative data is signed. 1) The fact that an NS exists is something established at the parent. What's in the RDATA is established by the child. So we have a split authority problem. 2) DNS does not require, so far as I know, perfect coherence between the child's version of the NS set and the parent's version. Relaxed coherence allows for "operational bumps." Being able to tolerate that is what fuels DNS's incredible ability to scale. (Systems that are too tight generally are too rigid and don't survive jolts.) The "weakness" of the NS set in the eyes of security is a great asset in the eyes of scaling. It's ironic, I know. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Jun 9 14:45:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08189 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 14:45:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY80c-000IoU-Gr for namedroppers-data@psg.com; Wed, 09 Jun 2004 18:41:10 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY80b-000IoF-QX for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 18:41:09 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A076413DDA for <namedroppers@ops.ietf.org>; Wed, 9 Jun 2004 18:41:09 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Wed, 09 Jun 2004 19:12:17 +0100." <40C75301.1090004@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 09 Jun 2004 18:41:09 +0000 Message-Id: <20040609184109.A076413DDA@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk note: since this is about clarifying the existing documents rather than about whether NSEC2 should be adopted (or what DNSSEC-TER should look like), i don't believe that the chairs' radio silence request applies. if i'm wrong, i'd like a chair to clarify the radio silence request in public. > > the threat in this case is being delegated toward a serverset who > > can't sign its responses with the key denoted by the parent's DS. > > this is a denial of service attack, but it would be easier to launch > > one using congestion than by query-id guessing. > > The assumption was that there would be no DS. if there's no ds, then there's no value added by signing anything in the delegation. > > dnssec isn't just end-to-end, it's root-to-leaf. > > Well, there may be other reasons to rely on the nameserver (or avoid > spoofing thereof) - for example, it is at the other end of some IPSEC > or VPN authentication, or it is inside a trusted network. that configuration is outside of dns proper, and is not a topic area for dnssec-bis. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 9 17:23:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24036 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 17:23:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYASM-000PW4-DQ for namedroppers-data@psg.com; Wed, 09 Jun 2004 21:17:58 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYASJ-000PVn-H8 for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 21:17:55 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A60DF19B760; Wed, 9 Jun 2004 17:09:58 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3DDFF19B6DE for <namedroppers@ops.ietf.org>; Wed, 9 Jun 2004 17:09:58 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1752505; Wed, 09 Jun 2004 17:17:54 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602042fbced2e81d1a4@[192.136.136.83]> Date: Wed, 9 Jun 2004 17:18:00 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: dns rr types Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk IANA's list of RR types has: TYPE value and meaning Reference ---------- -------------------------------------- --------- ... UINFO 100 [IANA-Reserved] UID 101 [IANA-Reserved] GID 102 [IANA-Reserved] UNSPEC 103 [IANA-Reserved] ... I don't see any mention of them in RFC 2929 (DNS-IANA considerations). Does anyone know where these are defined? Or why they are reserved? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Jun 9 18:19:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00073 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 18:19:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYBJH-000BXF-4L for namedroppers-data@psg.com; Wed, 09 Jun 2004 22:12:39 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYBJ8-000BTK-5e for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 22:12:30 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i59MCQW4028114; Wed, 9 Jun 2004 22:12:26 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i59MCQuQ028111; Wed, 9 Jun 2004 22:12:26 GMT Date: Wed, 9 Jun 2004 22:12:26 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis <edlewis@arin.net> Cc: namedroppers@ops.ietf.org Subject: Re: dns rr types Message-ID: <20040609221226.GA28097@vacation.karoshi.com.> References: <a0602042fbced2e81d1a4@[192.136.136.83]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <a0602042fbced2e81d1a4@[192.136.136.83]> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk legacy stuff. our old zones here had UNIFO/UID/GID data and the 4.9 upgrades (i think it was 4.9...) summarily dropped support for these rr types, causing me to have to edit the zone files, removing these. I'd have to poll the old timers, but the rdata for these records roughly matched the following: UINFO == "human name/account" UID == "Unix UID" GID == "Unix GID" No ID or RFC documents these bad boys. One might find more data in the old CHAOS/Athena docsets :) On Wed, Jun 09, 2004 at 05:18:00PM -0400, Edward Lewis wrote: > IANA's list of RR types has: > TYPE value and meaning Reference > ---------- -------------------------------------- --------- > ... > UINFO 100 [IANA-Reserved] > UID 101 [IANA-Reserved] > GID 102 [IANA-Reserved] > UNSPEC 103 [IANA-Reserved] > ... > > I don't see any mention of them in RFC 2929 (DNS-IANA considerations). > Does anyone know where these are defined? Or why they are reserved? > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 9 18:22:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00386 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 18:22:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYBOu-000CCF-JC for namedroppers-data@psg.com; Wed, 09 Jun 2004 22:18:28 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYBOj-000CB4-U4 for namedroppers@ops.ietf.org; Wed, 09 Jun 2004 22:18:18 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 30FFEA8B4 for <namedroppers@ops.ietf.org>; Wed, 9 Jun 2004 22:17:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.11/8.12.11) with ESMTP id i59MHf74016990; Thu, 10 Jun 2004 08:17:41 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200406092217.i59MHf74016990@drugs.dv.isc.org> To: Edward Lewis <edlewis@arin.net> Cc: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: dns rr types In-reply-to: Your message of "Wed, 09 Jun 2004 17:18:00 -0400." <a0602042fbced2e81d1a4@[192.136.136.83]> Date: Thu, 10 Jun 2004 08:17:41 +1000 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > IANA's list of RR types has: > TYPE value and meaning Reference > ---------- -------------------------------------- --------- > ... > UINFO 100 [IANA-Reserved] > UID 101 [IANA-Reserved] > GID 102 [IANA-Reserved] > UNSPEC 103 [IANA-Reserved] > ... > > I don't see any mention of them in RFC 2929 (DNS-IANA considerations). > > Does anyone know where these are defined? Or why they are reserved? They are reserved because they existed in BIND 4. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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/> -- 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 Wed Jun 9 23:29:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15764 for <dnsext-archive@lists.ietf.org>; Wed, 9 Jun 2004 23:29:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGBv-0000RZ-UR for namedroppers-data@psg.com; Thu, 10 Jun 2004 03:25:23 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYGBt-0000QT-1L for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 03:25:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6047A13DDA for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 03:25:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: dns rr types In-Reply-To: Message from bmanning@vacation.karoshi.com of "Wed, 09 Jun 2004 22:12:26 GMT." <20040609221226.GA28097@vacation.karoshi.com.> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Jun 2004 03:25:20 +0000 Message-Id: <20040610032520.6047A13DDA@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > legacy stuff. our old zones here had UNIFO/UID/GID data and the 4.9 > upgrades (i think it was 4.9...) summarily dropped support for these > rr types, causing me to have to edit the zone files, removing these. right. since there was no rfc documenting them, i took them out of bind. > I'd have to poll the old timers, ... mike schwartz was the originator of UNSPEC. only dunlap or karels could answer for the rest. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 03:55:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10975 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 03:55:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYKIL-000NoT-3z for namedroppers-data@psg.com; Thu, 10 Jun 2004 07:48:17 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYKIK-000NoB-12 for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 07:48:16 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 5E22319641; Thu, 10 Jun 2004 09:48:14 +0200 (CEST) Date: Thu, 10 Jun 2004 09:48:14 +0200 (CEST) From: Jakob Schlyter <jakob@rfc.se> To: "Olaf M. Kolkman" <olaf@ripe.net>, =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= <ogud@ogud.com> Cc: IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Evaluating DNSSEC transition mechanisms In-Reply-To: <20040603161757.2c386dd7.olaf@ripe.net> Message-ID: <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> References: <20040603161757.2c386dd7.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have just submitted our draft on 'Evaluating DNSSEC transition mechanisms' to the Internet Drafts editor for publication. while it's being processed, it can also be found at the following URL: http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-dnssec-trans-00.txt 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 Thu Jun 10 04:03:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11242 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 04:03:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYKSd-000Otv-E0 for namedroppers-data@psg.com; Thu, 10 Jun 2004 07:58:55 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYKSc-000Otf-Aw for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 07:58:54 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id B9ABF55C6F; Thu, 10 Jun 2004 09:58:53 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 699D955C6E for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 09:58:53 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5A7wrm0016307 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 09:58:53 +0200 Date: Thu, 10 Jun 2004 09:58:53 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: IETF document publication process tweaks. Message-Id: <20040610095853.27795d44.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.041175 / 0.0 / 0.0 / disabled X-RIPE-Signature: 09ef82197b34cbdaf144f327c851a7fb X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, Without shame I follow Dave Meyer's example (in DNSOP) and forward this nice summary. --Olaf > From: Bill Sommerfeld <sommerfeld@east.sun.com> > To: ietf-ssh@NetBSD.org > Subject: IETF document publication process tweaks. > Date: Tue, 08 Jun 2004 19:55:39 -0400 > > For those of you who don't subscribe to IETF-announce, you should be > aware that the IESG has once again revised the procedures for > Internet-Draft submission. > > - The old ID-Nits list is now the "ID Checklist", > http://www.ietf.org/ID-Checklist.html > > - There is also now a script available which provides an "internet > draft lint" tool, which checks for conformance with many of the > mechanical aspects of these new checklists. See: > http://ietf.levkowetz.com/tools/idnits/ > > - In addition, with the publication of RFC 3667 and RFC 3668, which > supersede RFC2026, there now also newly rototilled draft template > boilerplate/copyright/IPR notice/etc.; > > A new version of the xml2rfc toolkit is available at > http://xml.resource.org/ which includes the new boilerplate. While > use of xml2rfc is not required, it is strongly encouraged.. > > As working group chair, I'm responsible for checking all drafts > against the checklist. Help save you and me time by checking them > first before sending them in.. > > - Bill -- Olaf DNSEXT co-chair ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 07:09:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19284 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 07:09:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYNNV-000FUi-4D for namedroppers-data@psg.com; Thu, 10 Jun 2004 11:05:49 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYNNM-000FSV-74 for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 11:05:40 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 12FF54EDB7; Thu, 10 Jun 2004 12:46:22 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8BD6751F94 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 12:46:21 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5AAkLm0019859 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 12:46:21 +0200 Date: Thu, 10 Jun 2004 12:46:21 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: Re: Working Group Process: Radio Silence Message-Id: <20040610124621.5118e8fa.olaf@ripe.net> In-Reply-To: <20040607164537.27b0d3fc.olaf@ripe.net> References: <20040607164537.27b0d3fc.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: b7e59803cce0b30a8bc0cb8b218987e1 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Colleagues, Somebody privately commented on our previous announcement: > Hi. I don't understand this. Is the intention really that no > discussion about WG document (e.g., DNSSECbis) is to occur on the WG > list, except for the NSEC-alt issue (which should be taken to > dnssec@cafax.se)? I have re-read your post several times, and I can't > come to any other conclusion. It is not our intention to move _all_ discussion away from namedroppers. The "radio silence" message was only mend to apply to the discussions on zone enumeration prevention, NSEC2 and related matters on which hundreds of mails where posted over the last 2 weeks. After receiving the message above I reread the original mail; Its language was too restrictive. So this is the deal. - Except for discussion of http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-dnssec-trans-00.txt all discussion about the prevention of zone enumeration and NSEC2 is deferred. We'll open this topic of discussion once DNSSEC-bis is at the IESG. At that time we'll start with formulating the requirements. If you want to discuss possible solutions, baked and half-baked, please use dnssec@cafax.se (a majordomo list). At that point in time we'll look for volunteers to bring relevant summaries from that list to namedroppers. - There is _no_ radio-silence on other topics. Your last minute nits on DNSSEC bis are welcome and feel free to discuss any other item that is within the scope of DNSEXT. Sorry for possible confusion, please do not hesitate to ask questions if this message did not clarify. --Olaf DNSEXT Co-Chair. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 07:26:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19871 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 07:26:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYNdz-000Gwy-A0 for namedroppers-data@psg.com; Thu, 10 Jun 2004 11:22:51 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYNdx-000Gwh-Kx for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 11:22:49 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 307611FF845; Thu, 10 Jun 2004 11:22:48 +0000 (GMT) Message-ID: <40C84487.2090108@algroup.co.uk> Date: Thu, 10 Jun 2004 12:22:47 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? References: <20040609184109.A076413DDA@sa.vix.com> In-Reply-To: <20040609184109.A076413DDA@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > note: since this is about clarifying the existing documents rather than > about whether NSEC2 should be adopted (or what DNSSEC-TER should look like), > i don't believe that the chairs' radio silence request applies. if i'm > wrong, i'd like a chair to clarify the radio silence request in public. Indeed - the motivation for the question was that I couldn't find any explanation in the documents. It might be a good idea to say something about it. >>>the threat in this case is being delegated toward a serverset who >>>can't sign its responses with the key denoted by the parent's DS. >>>this is a denial of service attack, but it would be easier to launch >>>one using congestion than by query-id guessing. >> >>The assumption was that there would be no DS. > > if there's no ds, then there's no value added by signing anything in the > delegation. > >>>dnssec isn't just end-to-end, it's root-to-leaf. >> >>Well, there may be other reasons to rely on the nameserver (or avoid >>spoofing thereof) - for example, it is at the other end of some IPSEC >>or VPN authentication, or it is inside a trusted network. > > that configuration is outside of dns proper, and is not a topic area for > dnssec-bis. I'm not sure what you're saying here - do you mean it shouldn't be discussed at all w.r.t. DNSSEC, or do you mean that it isn't relevant to finalising the docset? 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 Thu Jun 10 10:29:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10705 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 10:29:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYQTs-0009Xu-QW for namedroppers-data@psg.com; Thu, 10 Jun 2004 14:24:36 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYQTq-0009XH-2U for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 14:24:34 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0459213DE9 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 14:24:32 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Thu, 10 Jun 2004 12:22:47 +0100." <40C84487.2090108@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Jun 2004 14:24:32 +0000 Message-Id: <20040610142432.0459213DE9@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > > dnssec isn't just end-to-end, it's root-to-leaf. > > > Well, there may be other reasons to rely on the nameserver (or avoid > > > spoofing thereof) - for example, it is at the other end of some IPSEC > > > or VPN authentication, or it is inside a trusted network. > > that configuration is outside of dns proper, and is not a topic area for > > dnssec-bis. > I'm not sure what you're saying here - do you mean it shouldn't be > discussed at all w.r.t. DNSSEC, or do you mean that it isn't relevant to > finalising the docset? i think that the use of dns over non-ip networks like tunnels is not described anywhere, and so the dnssec-bis protocol and docset has no reason to mention the configuration you've described. it's the same as NAT. there's no rfc that describes dns response rewriting by NAT boxes, and so, dnssec-bis behaves as though such rewriting doesn't occur. this may be a bad thing, and it may be that there should be rfc's about "implications of nat on dns" and "implications of private secure tunnels on dns" and so on. but today there are no such, and the dnssec-bis design team would be foolish to try to cover undefined working conditions. note that the lack of signatures on nonauthoritative delegation NS RRsets has simplified the design, and changing it in the 11th hour isn't an option because of the impact such a change will have on other parts of the model. if it's to be changed, then it's really a dnssec-ter issue. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 10:43:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11621 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 10:43:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYQiH-000BF6-2N for namedroppers-data@psg.com; Thu, 10 Jun 2004 14:39:29 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYQiF-000BEp-7B for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 14:39:27 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.11/8.12.11/Debian-3) with ESMTP id i5AEdNua007143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 16:39:24 +0200 To: namedroppers@ops.ietf.org Subject: DNSKEY flags field From: Simon Josefsson <jas@extundo.com> X-Hashcash: 0:040610:namedroppers@ops.ietf.org:8761856bf44a8da8 Date: Thu, 10 Jun 2004 16:39:22 +0200 Message-ID: <ilufz9332at.fsf@latte.josefsson.org> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello. I think the flags field of DNSKEY could be improved to facilitate future revisions. The dnssec-records says in 2.1.1: Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon creation of the DNSKEY RR, and MUST be ignored upon reception. Always ignoring unknown bits remove the possibility of using the flags field as an upgrade path in future revisions of DNSSEC. What do people think about changing the above to: Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon creation of the DNSKEY RR, and bits 0-6 MUST be ignored upon reception, and non-zero values in bits 8-14 MUST cause the DNSKEY to be considered invalid for purposes of RRSIG validation. This would allow DNSSECter to use bits 0-6 for non-critical signaling of new features, and to use bits 8-14 for critical signaling of new features. Of course, if after more consideration, it is realized that using the flags field is not a reliable way to signal features DNSSECter want to communicate, then EDNS or some other solution can be used instead. But adopting the above text would make it possible to have this option open for DNSSECter. What do you think? Thanks, Simon PS. This message was reposted here because my post to dnssec@cafax.se appear to have neither arrived, bounced or generated a moderation notify. If you receive duplicates, I apologize. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 11:18:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13015 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 11:18:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYRG7-000FcU-5O for namedroppers-data@psg.com; Thu, 10 Jun 2004 15:14:27 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYRG6-000FcE-0Y for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 15:14:26 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5AFELmM070477 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 17:14:22 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5AFEGXQ019590 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 17:14:16 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5AFEFY7019587 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 17:14:16 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 10 Jun 2004 17:14:15 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms In-Reply-To: <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> Message-ID: <Pine.LNX.4.58.0406101705070.2889@elektron.atoom.net> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 10 Jun 2004, Jakob Schlyter wrote: > I have just submitted our draft on 'Evaluating DNSSEC transition > mechanisms' to the Internet Drafts editor for publication. while it's > being processed, it can also be found at the following URL: > > http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-dnssec-trans-00.txt To kickstart discussion, this is what we recommend: The authors recommend that the working group commits to and starts work on a partial TCR, allowing graceful transition towards a future version of NSEC. Meanwhile, to accomodate the need for an immediate but temporal solution against zone-traversal, we recommend On-Demand NSEC synthesis. This approach does not require any mandatory changes to DNSSEC-bis, does not violate the protocol and fulfills the requirements. As a side effect, it moves the cost of implementation and deployment to the users (zone owners) of this mechanism. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 11:37:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13806 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 11:37:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYRZd-000ITu-25 for namedroppers-data@psg.com; Thu, 10 Jun 2004 15:34:37 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYRZb-000ITe-CD for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 15:34:36 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 4725119B7BA; Thu, 10 Jun 2004 11:26:25 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5AEC619B7B8; Thu, 10 Jun 2004 11:26:24 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1755469; Thu, 10 Jun 2004 11:34:33 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020431bcee2fb29e74@[192.136.136.83]> In-Reply-To: <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> Date: Thu, 10 Jun 2004 11:34:42 -0400 To: Jakob Schlyter <jakob@rfc.se> From: Edward Lewis <edlewis@arin.net> Subject: Re: Evaluating DNSSEC transition mechanisms Cc: "Olaf M. Kolkman" <olaf@ripe.net>, =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= <ogud@ogud.com>, IETF DNSEXT WG <namedroppers@ops.ietf.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ## Evaluating DNSSEC Transition Mechanisms ## draft-ietf-dnsext-dnssec-trans-00.txt ## 2.1 Mechanisms Updating DNSSEC-bis ## ## 2.1.1 Dynamic NSEC Synthesis ## ## This proposal assumes that NSEC RRs and the authenticating RRSIG will ## be generated dynamically to just cover the (non existent) query name. ## The owner name is (the) one preceding the name queried for, the Next ## Owner Name Field has the value of the Query Name Field + 1 (first ## successor in canonical ordering). A separate key (the normal ZSK or a ## separate ZSK per authoritative server) would be used for RRSIGs on ## NSEC RRs. This is a defense against enumeration, though it has the ## presumption of online signing. To protect off-line signed data from exposure of the on-line private key, you have to require that the key signing non-auth denial data ALWAYS be different from the other zone data. If you don't, all data is vulnerable because of the on-line key, making the distinction worthless. (This idea was tried a long time ago, see the "signatory" field in the KEY RR flags in RFC 2065, section 3.3.) ## 2.1.1.2 Limitations I've been told that performing public key crypto on the fly is still prohibitively costly. It would be good if someone who knows more about this added some hard data to that. ## 2.1.2 Add Versioning/Subtyping to Current NSEC ## ## 2.1.2.1 Coexistence and Migration ## ## Since the versioning is done inside the NSEC RR, different versions ## may coexist. However, depending on future methods, that may or may ## not be useful inside a single zone. Resolvers cannot ask for specific ## NSEC versions but may be able to indicate version support by means of ## a to be defined EDNS option bit. That would be a violation of the RR set rules in RFC 2181. Servers can't break up RR sets. I'd strongly recommend making a zone stick to one version, otherwise the semantics really get sticky for very little return. You need to define the way in which older-era clients deal with the absence of older-era NSEC records in a zone, if the server is unwilling to make use of the older-era version. ## 2.1.2.2 Limitations One limitation is that in the dns-choices draft, subtyping is strongly discouraged. There are reasons documented there. Also, there is a strong push to limit subtyping for applications - why encourage it for DNSSEC? The latter isn't a first-order issue, the limitations documented in Patrick and Rob's draft are. ## 2.1.2.4 Cons I think "clean and clear" are not the right words. E.g., we had subtyping in the KEY RR and that went nowhere. We need to learn from out mistakes. ## 2.1.2.5 Pros ## ## Does not introduce an iteration to DNSSEC while providing a clear and ## clean migration strategy. I disagree with that - the very need to do what's in the previous section is an iteration. ## 2.1.3 Type Bit Map NSEC Indicator ## 2.1.4 New Apex Type ## 2.1.4.2 Limitations Requires special processing - to be included in responses as needed. ## 2.1.4.4 Cons This proposal has died before, in 1999. (SEC RR) ## 2.1.5 NSEC White Lies ## 2.1.5.5 Pros ## ## Hardly any amendments to DNSSEC-bis. Operational "trick" that is ## available anyway. Although I think this is an absurd proposal, I'd be curious about the operational "trick". Absurd ideas need to be documented so we don't revisit them. (Signatory bits, subtyping, SEC RR, to name a few.) ## 2.1.6 NSEC Optional via DNSSKEY Flag ## ## A new DNSKEY may be defined to declare NSEC optional per zone. You can't have "optional" authenticated denial. It's either on or off. Perhaps the intent is that it is optional to use - and this has to be specified in-line with the verification process (DS or DNSKEY record). How (much) does this differ from the opt-in proposal? ## 2.2 Mechanisms not Updating DNSSEC-bis ## ## 2.2.1 Partial Type-code and Signal Rollover That sounds like an update to DNSSECbis. (Replacing it...) ## 2.2.1.2 Limitations Does not take into account the interaction between newer era servers and older era clients, assuming the newer era servers can't down-version their responses. ## 2.2.2 A Complete Type-code and Signal Rollover This assumes that newer era servers are capable of talking both old-era and new-era (multiple for all eras) DNSSEC. I.e., that any server that is supposed to speak only new NSEC is willing to speak old NSEC too. My assumption is that the motivation to use a new NSEC is that the old NSEC is abhorrent to the administrator. If that's true, then the old-era zone must appear unsecured (as opposed to giving away the information). A side effect is that resolvers need to know what era a key is from. If I install a trusted key for the root that matches the "new-era" in an old-era resolver, problems ensue. We've seen that in testbeds and is what gave rise to the first TCR. ## 2.2.2.1 Coexistence and Migration ## ## Both spaces can co-exist. They can be made completely orthogonal. But are a burden on operations, or at least a potential burden. How to I tell my parent to gimme a DS but not a DS2? An admin will have to support all orthogonal security spaces until they are unwilling to support the older era fan base. ## 2.2.3 Unknown Algorithm in RRSIG ## 3. Recommendation ## ## The authors recommend that the working group commits to and starts ## work on a partial TCR, allowing graceful transition towards a future ## version of NSEC. Meanwhile, to accommodate the need for an ## immediately, temporary, solution against zone-traversal, we recommend ## On-Demand NSEC synthesis. Is on-demand NSEC synthesis (specifically signing it's RRSIG) achievable? Would (not) a DOS attack be trivial? Now time for some rambling... I do think that zone enumeration is a problem, but not a privacy problem. This is based on "attacks" that use expected and dictionary-like attacks on domains to hit them with email and/or other directed traffic. So I think we do need to think about the issue. I'm increasingly skeptical that there is a good solution to the migration problem though. Besides recent reactions to the issue, having re-read the SEC RR stuff, I realize I've had this concern since the late 90's. One big reason for the SEC RR was to version NXT. The only possibility for migration into the future seems to me to follow the accepted idea of key roll over (super-cession) in which data is offered up in both old and new styles for some time. The dual-mode time is needed because of the slow adoption rate of data through caches and code through enterprises. But, with authenticated denial we have two strikes against us. The reason for going forward is that the old style is unacceptable. And you can't make authenticated denial records optional - that makes it too easy to attack them. I think. I think that if there is to be a defense against zone enumeration, then the NSEC as defined is DOA and is not worth adopting. Can we drop it now and later add the feature? Well, no, thanks to the DS RR. We need to have authenticated denial to tie the tree (islands of security) together. I doubt that a TCR will help. The only reason is worked this time is that no one is using the old DNSSEC. Anyone signing zones according to 2535 is not ever going to coexist with current-era code. Resolvers won't understand the difference in the trusted keys, and nothing has an understanding of the DS record. I really wish that we could do on the fly signing of responses for "no data" and "name error." To do that thought we need a NSK (negative signing key) to go along with ZSK and KSK. I just don't see how we can define old-era resolvers (DNSSECbis) to ever handle any new (unforeseen) versions of NSEC assuming that the new code won't back down to the old-era. How do the old-era resolvers authenticate new-era records? (How should they know to panic? How should they know which way to panic?) Aye, aye, aye, aye, aye... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Jun 10 11:40:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13935 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 11:40:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYRcv-000Ix1-PY for namedroppers-data@psg.com; Thu, 10 Jun 2004 15:38:01 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYRcv-000Iwo-1y for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 15:38:01 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id EBF5819B7C2; Thu, 10 Jun 2004 11:29:50 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 8E99719B7C2; Thu, 10 Jun 2004 11:29:50 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1755479; Thu, 10 Jun 2004 11:38:00 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020432bcee308cd16a@[192.136.136.83]> In-Reply-To: <ilufz9332at.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> Date: Thu, 10 Jun 2004 11:38:08 -0400 To: Simon Josefsson <jas@extundo.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:39 +0200 6/10/04, Simon Josefsson wrote: >What do you think? This is more or less what silly state began to try to do. Define looking at the bits that shouldn't matter to see if a "panic because it's the future and I don't know what to do" mode is to be entered. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Jun 10 11:58:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15356 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 11:58:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYRv3-000LMA-2I for namedroppers-data@psg.com; Thu, 10 Jun 2004 15:56:45 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYRv1-000LLp-8a for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 15:56:44 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BYRuz-000486-00 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 17:56:41 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 17:56:41 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 17:56:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Thu, 10 Jun 2004 17:56:38 +0200 Lines: 17 Message-ID: <ilubrjr2yq1.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:9cyveCNh1P86N+CCMwR9s+duniQ= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > At 16:39 +0200 6/10/04, Simon Josefsson wrote: >>What do you think? > > This is more or less what silly state began to try to do. Define > looking at the bits that shouldn't matter to see if a "panic because > it's the future and I don't know what to do" mode is to be entered. A "panic button" already exists in DNSKEY -- if DNSSECter specify use of a protocol field != 3, old resolvers will reject those DNSKEYs, for RRSIG validation purposes. Using the Flags Field appeared to me like a cleaner solution, considering the original use of the protocol field. With my text this option would be available. 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 Thu Jun 10 12:21:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16572 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 12:21:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYSFr-000Ni2-MQ for namedroppers-data@psg.com; Thu, 10 Jun 2004 16:18:15 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYSFq-000Nho-DS for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 16:18:14 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id F0B101FF848 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 16:18:12 +0000 (GMT) Message-ID: <40C889C3.5050609@algroup.co.uk> Date: Thu, 10 Jun 2004 17:18:11 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: issues with draft-ietf-dnsext-dnssec-trans-00.txt X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "2.1.1.4 Cons Unbalanced cost is a ground for DDoS. Though this protects against enumeration, it is not really a path for versioning." This should also mention the security risk of the requirement for an online key. "2.1.2.2 Limitations There are no technical limitations, though it will cause delay to allow testing of the (currently unknown) new NSEC interpretation. Since the versioning and signaling is done inside the NSEC RR, future methods will likely be restricted to a single RR type authenticated denial (as opposed to e.g. NSEC-alt, which currently proposes three RR types)." Note sure I understand this - the presence of v2 of NSEC would signal that there are also NSECINFO and EXISTS records, wouldn't it? 2.2.2.4 Cons Spello: role -> roll "3. Conclusion The authors recommend that the working group commits to and starts work on a partial TCR, allowing gracefull transition towards a future version of NSEC. Meanwhile, to accomodate the need for an immediately, temporary, solution against zone-traversal, we recommend On-Demand NSEC synthesis." We (that is, Nominet) can't at present imagine how we could deploy this. The problems we see are: a) Invitation to DoS us, suggesting we'd need to investigate crypto offload devices. b) Changes to software required, and hence a long period of validation and testing. c) Exposure of private keys. This sounds no easier to deploy in practice than NSEC2 would be, even if it didn't have problems that appear to make it unworkable in any case. 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 Thu Jun 10 12:27:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16982 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 12:27:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYSM3-000Od5-Na for namedroppers-data@psg.com; Thu, 10 Jun 2004 16:24:39 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYSM1-000OcW-VV for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 16:24:38 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5AGOV8W071083 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 18:24:32 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5AGORXn020955 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 18:24:27 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5AGOP5F020952 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 18:24:26 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 10 Jun 2004 18:24:25 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms In-Reply-To: <a06020431bcee2fb29e74@[192.136.136.83]> Message-ID: <Pine.LNX.4.58.0406101746070.2889@elektron.atoom.net> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,OPT_IN, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Just to be clear, we don't propose these mechanisms, they're just there. What we _do_ recommend (propose) is partial TCR++. More comments inline. On Thu, 10 Jun 2004, Edward Lewis wrote: > ## Evaluating DNSSEC Transition Mechanisms > ## draft-ietf-dnsext-dnssec-trans-00.txt > > ## 2.1 Mechanisms Updating DNSSEC-bis > ## > ## 2.1.1 Dynamic NSEC Synthesis > ## > ## This proposal assumes that NSEC RRs and the authenticating RRSIG will > ## be generated dynamically to just cover the (non existent) query name. > ## The owner name is (the) one preceding the name queried for, the Next > ## Owner Name Field has the value of the Query Name Field + 1 (first > ## successor in canonical ordering). A separate key (the normal ZSK or a > ## separate ZSK per authoritative server) would be used for RRSIGs on > ## NSEC RRs. This is a defense against enumeration, though it has the > ## presumption of online signing. > > To protect off-line signed data from exposure of the on-line private key, > you have to require that the key signing non-auth denial data ALWAYS be > different from the other zone data. If you don't, all data is vulnerable > because of the on-line key, making the distinction worthless. (This idea > was tried a long time ago, see the "signatory" field in the KEY RR flags > in RFC 2065, section 3.3.) Okay, -01 will include this text. > ## 2.1.1.2 Limitations > > I've been told that performing public key crypto on the fly is still > prohibitively costly. It would be good if someone who knows more about > this added some hard data to that. Okay. Someone send text pls. > ## 2.1.2.2 Limitations > > One limitation is that in the dns-choices draft, subtyping is strongly > discouraged. There are reasons documented there. Also, there is a strong > push to limit subtyping for applications - why encourage it for DNSSEC? > The latter isn't a first-order issue, the limitations documented in Patrick > and Rob's draft are. There are no encouragements here !!! see my first comment above. > ## 2.1.3 Type Bit Map NSEC Indicator > ## 2.1.4 New Apex Type > ## 2.1.4.2 Limitations > > Requires special processing - to be included in responses as needed. > > ## 2.1.4.4 Cons > > This proposal has died before, in 1999. (SEC RR) Will include. > ## 2.1.6 NSEC Optional via DNSSKEY Flag > ## > ## A new DNSKEY may be defined to declare NSEC optional per zone. > > You can't have "optional" authenticated denial. It's either on or off. > Perhaps the intent is that it is optional to use - and this has to be > specified in-line with the verification process (DS or DNSKEY record). > > How (much) does this differ from the opt-in proposal? This is not opt-in........ > ## 2.2 Mechanisms not Updating DNSSEC-bis > ## > ## 2.2.1 Partial Type-code and Signal Rollover > > That sounds like an update to DNSSECbis. (Replacing it...) No, not at all. Different versions. Unless ofcourse you'd see IPv6 as a replacement op IPv4. Both can coexist, no ? > ## 2.2.1.2 Limitations > > Does not take into account the interaction between newer era servers and > older era clients, assuming the newer era servers can't down-version their > responses. Does too ! :-) dnssec-ter falls back to dns, not to dnssec-bis in case newer era servers babble with older era clients. > ## 2.2.2 A Complete Type-code and Signal Rollover > > This assumes that newer era servers are capable of talking both old-era and > new-era (multiple for all eras) DNSSEC. I.e., that any server that is > supposed to speak only new NSEC is willing to speak old NSEC too. See my previous comment. > My assumption is that the motivation to use a new NSEC is that the old NSEC > is abhorrent to the administrator. If that's true, then the old-era zone > must appear unsecured (as opposed to giving away the information). You got it mister ! And I learned a new word ! > ## 2.2.2.1 Coexistence and Migration > ## > ## Both spaces can co-exist. They can be made completely orthogonal. > > But are a burden on operations, or at least a potential burden. How to I tell > my parent to gimme a DS but not a DS2? You don't. Parent has either for a delegation. old-era-resolver will ignore DS2 and mark the delegation usigned due to absence of DS. new > ## 3. Recommendation > ## > ## The authors recommend that the working group commits to and starts > ## work on a partial TCR, allowing graceful transition towards a future > ## version of NSEC. Meanwhile, to accommodate the need for an > ## immediately, temporary, solution against zone-traversal, we recommend > ## On-Demand NSEC synthesis. > > Is on-demand NSEC synthesis (specifically signing it's RRSIG) achievable? Yes. It would be trivial. > Would (not) a DOS attack be trivial? Yes, a cypto DOS attack would be a little more trivial then just plain query storms, sure. > Now time for some rambling... Oh, goody ;-) > I do think that zone enumeration is a problem, but not a privacy problem. > This is based on "attacks" that use expected and dictionary-like attacks on > domains to hit them with email and/or other directed traffic. So I think > we do need to think about the issue. > > I'm increasingly skeptical that there is a good solution to the migration > problem though. Besides recent reactions to the issue, having re-read the > SEC RR stuff, I realize I've had this concern since the late 90's. One > big reason for the SEC RR was to version NXT. > > The only possibility for migration into the future seems to me to follow > the accepted idea of key roll over (super-cession) in which data is offered > up in both old and new styles for some time. The dual-mode time is needed > because of the slow adoption rate of data through caches and code through > enterprises. > > But, with authenticated denial we have two strikes against us. The reason > for going forward is that the old style is unacceptable. And you can't > make authenticated denial records optional - that makes it too easy to > attack them. > > I think. > > I think that if there is to be a defense against zone enumeration, then > the NSEC as defined is DOA and is not worth adopting. Can we drop it now > and later add the feature? Well, no, thanks to the DS RR. We need to > have authenticated denial to tie the tree (islands of security) together. > > I doubt that a TCR will help. The only reason is worked this time is that > no one is using the old DNSSEC. Anyone signing zones according to 2535 is > not ever going to coexist with current-era code. Resolvers won't understand > the difference in the trusted keys, and nothing has an understanding of the > DS record. > > I really wish that we could do on the fly signing of responses for "no data" > and "name error." To do that thought we need a NSK (negative signing key) to > go along with ZSK and KSK. > > I just don't see how we can define old-era resolvers (DNSSECbis) to ever > handle any new (unforeseen) versions of NSEC assuming that the new code > won't back down to the old-era. How do the old-era resolvers authenticate > new-era records? (How should they know to panic? How should they know which > way to panic?) Are you suggesting we don't yet publish -bis. Hold the code. Rewrite NSEC ? My current thinking is that partial TCR is still the best long-term solution. If folk can't wait for that, use on-demand-nsec-signing. ymmv. 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 Thu Jun 10 12:29:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17133 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 12:29:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYSOM-000P1z-F5 for namedroppers-data@psg.com; Thu, 10 Jun 2004 16:27:02 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYSOL-000P1Y-5g for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 16:27:01 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 43D251FF848; Thu, 10 Jun 2004 16:27:00 +0000 (GMT) Message-ID: <40C88BD3.3010304@algroup.co.uk> Date: Thu, 10 Jun 2004 17:26:59 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? References: <20040610142432.0459213DE9@sa.vix.com> In-Reply-To: <20040610142432.0459213DE9@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>>>dnssec isn't just end-to-end, it's root-to-leaf. > > >>>>Well, there may be other reasons to rely on the nameserver (or avoid >>>>spoofing thereof) - for example, it is at the other end of some IPSEC >>>>or VPN authentication, or it is inside a trusted network. > > >>>that configuration is outside of dns proper, and is not a topic area for >>>dnssec-bis. > > >>I'm not sure what you're saying here - do you mean it shouldn't be >>discussed at all w.r.t. DNSSEC, or do you mean that it isn't relevant to >>finalising the docset? > > > i think that the use of dns over non-ip networks like tunnels is not > described anywhere, and so the dnssec-bis protocol and docset has no > reason to mention the configuration you've described. it's the same > as NAT. there's no rfc that describes dns response rewriting by NAT > boxes, and so, dnssec-bis behaves as though such rewriting doesn't > occur. this may be a bad thing, and it may be that there should be > rfc's about "implications of nat on dns" and "implications of private > secure tunnels on dns" and so on. but today there are no such, and > the dnssec-bis design team would be foolish to try to cover undefined > working conditions. > > note that the lack of signatures on nonauthoritative delegation NS RRsets > has simplified the design, and changing it in the 11th hour isn't an > option because of the impact such a change will have on other parts of > the model. if it's to be changed, then it's really a dnssec-ter issue. I was not suggesting it should be changed in dnssec-bis, but I do think it should be explained and possibly also mentioned in the security considerations. 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 Thu Jun 10 12:31:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17230 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 12:31:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYSPn-000PGh-Kv for namedroppers-data@psg.com; Thu, 10 Jun 2004 16:28:31 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYSPW-000PE3-EB for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 16:28:14 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 98BFE19B454; Thu, 10 Jun 2004 12:20:03 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 10F9419B3FB; Thu, 10 Jun 2004 12:20:03 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1755733; Thu, 10 Jun 2004 12:28:13 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020436bcee382f9bbc@[192.136.136.83]> In-Reply-To: <ilubrjr2yq1.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> Date: Thu, 10 Jun 2004 12:28:22 -0400 To: Simon Josefsson <jas@extundo.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:56 +0200 6/10/04, Simon Josefsson wrote: >Edward Lewis <edlewis@arin.net> writes: > >> At 16:39 +0200 6/10/04, Simon Josefsson wrote: >>>What do you think? >> >> This is more or less what silly state began to try to do. Define >> looking at the bits that shouldn't matter to see if a "panic because >> it's the future and I don't know what to do" mode is to be entered. > >A "panic button" already exists in DNSKEY -- if DNSSECter specify use >of a protocol field != 3, old resolvers will reject those DNSKEYs, for >RRSIG validation purposes. Using the Flags Field appeared to me like >a cleaner solution, considering the original use of the protocol >field. With my text this option would be available. What your text is doing is bringing the flags definition in line with the protocol field - telling the verifier to ignore keys that don't fit the narrowly defined contents they are allowed to have. It's good to see the specifications have commonality across the sections. The problem is that this is not sufficient to provide a base for a migration strategy. What's missing are instructions on what to do if all keys present fail the tests? Should the verifier log this instance as a note to the administrator that perhaps the verifier code has fallen behind in version and needs to be replaced? Should the verifier just assume that there is no available DNSSEC verification data for the zone and thus treat it as unsigned? What does a resolver do when it tries to load a trusted key that has a protocol field != 3 or flag bits not 0 in the right places? What if a verifier starts in a zone with acceptable keys, sees a (child's) DS set with acceptable algorithms, but finds only a DNSKEY set (upon descending into the child) with unacceptable bits? How is that DNSKEY set signed? Can the signature be validated? If not, how do you know that the DNSKEY set of all unacceptable keys is not a malicious insertion? I think the problem (and I'm off on a tangent now) is that you have to make the verifier be able to realize at the DS RR set that the child will have no acceptable keys for me - at the point where I can verify the "end of understandable security" while still being secure enough to trust it. And the server has to be able to understand that even if I do present secure data, a client unable to understand it will fall back to assuming the server has no security. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Thu Jun 10 12:35:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17556 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 12:35:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYSTM-000Psv-FK for namedroppers-data@psg.com; Thu, 10 Jun 2004 16:32:12 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYSTL-000Psa-He for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 16:32:11 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 206B41FF845; Thu, 10 Jun 2004 16:32:09 +0000 (GMT) Message-ID: <40C88D07.3040700@algroup.co.uk> Date: Thu, 10 Jun 2004 17:32:07 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edward Lewis <edlewis@arin.net> Cc: Jakob Schlyter <jakob@rfc.se>, "Olaf M. Kolkman" <olaf@ripe.net>, =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= <ogud@ogud.com>, IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> In-Reply-To: <a06020431bcee2fb29e74@[192.136.136.83]> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > I've been told that performing public key crypto on the fly is still > prohibitively costly. It would be good if someone who knows more about > this added some hard data to that. A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50 1024 bit RSA signatures a second and less than 10 2048 bit signatures. 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 Thu Jun 10 12:42:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18137 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 12:42:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYSYU-0000ik-11 for namedroppers-data@psg.com; Thu, 10 Jun 2004 16:37:30 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYSYS-0000iB-8L for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 16:37:28 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i5AGbMrd023057; Thu, 10 Jun 2004 17:37:22 +0100 (BST) To: Ben Laurie <ben@algroup.co.uk> cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Thu, 10 Jun 2004 17:18:11 BST." <40C889C3.5050609@algroup.co.uk> Date: Thu, 10 Jun 2004 17:37:22 +0100 Message-ID: <23055.1086885442@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> writes: Ben> Note sure I understand this - the presence of v2 of NSEC Ben> would signal that there are also NSECINFO and EXISTS records, Ben> wouldn't it? Not necessarily. Who can say now what NSECv2 will finally look like or predict how many new RR types it'll need? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 13:19:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20208 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 13:19:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYT9f-0006CR-RK for namedroppers-data@psg.com; Thu, 10 Jun 2004 17:15:55 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYT9f-0006C6-2J for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 17:15:55 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DD5A413951 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 17:15:54 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Thu, 10 Jun 2004 17:26:59 +0100." <40C88BD3.3010304@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Jun 2004 17:15:54 +0000 Message-Id: <20040610171554.DD5A413951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > i think that the use of dns over non-ip networks like tunnels is not > > described anywhere, and so the dnssec-bis protocol and docset has no > > reason to mention the configuration you've described. it's the same > > as NAT. ... and the dnssec-bis design team would be foolish to try > > to cover undefined working conditions. > ... but I do think it should be explained and possibly also mentioned > in the security considerations. why is that, exactly? should we also mention that it won't work over sneaker-net or avian-net, or after global thermonuclear war? i'm not *just* being peevish, i'm trying to point out that there are a lot of actual, potential, or imaginable circumstances under which dnssec-bis would be unusable or inapplicable. why is this particular one worthy of specific mention in the document? some years ago an earlier instance of IAB gave us a "statement regarding the end-to-end nature of internet communications" or some such. i thought it was a mistake, since even at that time, real internet communications used very different models than the one described in that statement. but the one thing that statement gave us was well defined starting conditions for subsequent (or even previous) protocol specifications. using dnssec to get a secure path from some trust anchor (like the root, maybe, someday) to some delegation point, where the NS RR was trustworthy but the A RR maybe or maybe not so and the zone definitely not, on the basis that perhaps some validators will have out-of-band methods of trusting the communications with or content received from the servers for such zones, is so far away from dnssec-bis's "starting conditions" that you might just as well talk about how dnssec-bis would work for harry potter if his wand spoke tcp/ip. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 13:41:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21040 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 13:41:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYTUe-00096R-3u for namedroppers-data@psg.com; Thu, 10 Jun 2004 17:37:36 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYTUd-00096D-7M for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 17:37:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8020F13DDA for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 17:37:34 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: synthesis in -ter; HEREIS draft-vixie-dnssec-ter-01.txt X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Jun 2004 17:37:34 +0000 Message-Id: <20040610173734.8020F13DDA@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk oh hell. i let myself be fooled by the radio silence and by my private e-mail to at least one of the "dnssec transition mechanism" subcommittee, into thinking that i didn't need to push out an updated version of this draft that was absent the synthesis section (formerly 2.5). HEREIS -01: DNSEXT Working Group Paul Vixie INTERNET-DRAFT ISC <draft-vixie-dnssec-ter-01.txt> June 2004 Extending DNSSEC-BIS (DNSSEC-TER) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As the DNSSEC-BIS document set goes to press, we find that the design goals for DNSSEC have shifted somewhat in the ten years of its preproduction. This memo lists some possible new directions for DNSSEC-TER, and also, some methods by which DNSSEC-TER could first coexist with, and possibly replace, DNSSEC-BIS. 1 - Rationale and Scope 1.1. DNSSEC-BIS, which took ten years to evolve, is widely considered to be a working solution for end to end DNS data authenticity. However, the threat model which drove the design of DNSSEC and DNSSEC-BIS fails to address issues of great interest to some members of the community, for example, domain name confidentiality. Expires December 2004 [Page 1] INTERNET-DRAFT DNSSEC-TER June 2004 1.2. Without proposing any specific new features, this memo will lay out an upgrade path whereby DNSSEC-TER could first coexist with, and then possibly replace DNSSEC-BIS, with no loss of functionality for DNSSEC- BIS adopters. The method used has been called a "type code roll" or TCR. 1.3. The goal of this memo is not to specify DNSSEC-TER itself, but rather, to describe the method by which it can be developed and deployed, compatibly with an existing DNSSEC-BIS installed base. 2 - New Signalling, New Metadata 2.1. Since DNSSEC-BIS already depends on EDNS due to message size increases, it is safe to depend on EDNS to carry a new DNSSEC-TER flag. The meaning of this flag would be, generally, "when I say I want DNSSEC metadata in the response to this query, I can handle, and prefer, DNSSEC-TER metadata." 2.2. DNSSEC-TER might define new metadata records (for example, DS2, NSEC2, RRSIG2, and/or DNSKEY2), but will not redefine the meaning or format of existing DNSSEC-BIS metadata records due to the risk of these records becoming separated from the DNSSEC-TER tag that tells how to interpret them. 2.3. EDNS is a hop by hop protocol, carrying meaning only between an initiator and a responder. A caching forwarder who can process both DNSSEC-TER and DNSSEC-BIS will "tag" its security metadata using the "DNSSEC-TER data is wanted" status of the query which causes that metadata to enter the cache. If cached data exists but was fetched without (or with) this tag, and a query arrives with (or without) the "DNSSEC-TER wanted" flag, then the new query will have to be forwarded upstream toward the authority servers, and the result (even if negative) will be cached and used separately. This behaviour has the effect of promoting the "DNSSEC-TER" wanted flag from hop-by-hop to end-to-end. 2.4. If an authority server or caching recursive server is asked for DNSSEC-TER metadata but only has DNSSEC-BIS metadata available, then DNSSEC-BIS data will be sent. Thus, a requestor who is capable of handling DNSSEC-TER metadata records should ask for DNSSEC-TER first, and then fall back to DNSSEC-BIS if necessary. This optimizes for the eventual case when the installed base of DNSSEC-BIS has completely upgraded to DNSSEC-TER. An initiator is not permitted to assume, from the lack of a DNSSEC-TER response, that either that server or that zone does not in general support DNSSEC-TER. Expires December 2004 [Page 2] INTERNET-DRAFT DNSSEC-TER June 2004 2.5. A zone signer and/or authority server might choose to support both DNSSEC-BIS and DNSSEC-TER, or only DNSSEC-BIS, or only DNSSEC-TER. It is expected that a validating recursive server, or a caching recursive server, will support either DNSSEC-BIS alone (as is the case today), or both DNSSEC-BIS and DNSSEC-TER, but never DNSSEC-TER alone. 3 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671, IETF DNSIND, September 1998 4 - Author's Address Paul Vixie Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 +1.650.423.1301 <vixie@isc.org> 3557*VIX Expires December 2004 [Page 3] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 15:30:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26437 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 15:30:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYVAv-00006L-Lc for namedroppers-data@psg.com; Thu, 10 Jun 2004 19:25:21 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYVAu-000067-Kg for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 19:25:20 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 9056F1FE67; Thu, 10 Jun 2004 20:25:19 +0100 (BST) Date: Thu, 10 Jun 2004 20:25:14 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org> Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <518CC372ADAC1DF1914790E2@[192.168.100.19]> In-Reply-To: <40C889C3.5050609@algroup.co.uk> References: <40C889C3.5050609@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 10 June 2004 17:18 +0100 Ben Laurie <ben@algroup.co.uk> wrote: > "2.1.1.4 Cons > > Unbalanced cost is a ground for DDoS. Though this protects against > enumeration, it is not really a path for versioning." > > This should also mention the security risk of the requirement for an > online key. Which you could add are of particular concern where not all secondaries are under the same administrative control as the primary (whereas with DNSSEC-bis this is irrelevant) 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 Thu Jun 10 15:37:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26688 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 15:37:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYVJ6-0000vG-9N for namedroppers-data@psg.com; Thu, 10 Jun 2004 19:33:48 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYVJ5-0000ux-Eg for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 19:33:47 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 873141FE67; Thu, 10 Jun 2004 20:33:46 +0100 (BST) Date: Thu, 10 Jun 2004 20:33:41 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: DNSEXT WG <namedroppers@ops.ietf.org> Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <B211BDC326E5FE10E3E32687@[192.168.100.19]> In-Reply-To: <40C889C3.5050609@algroup.co.uk> References: <40C889C3.5050609@algroup.co.uk> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 3. Recommendation > > The authors recommend that the working group commits to and starts > work on a partial TCR, allowing gracefull transition towards a future > version of NSEC. Meanwhile, to accomodate the need for an > immediately, temporary, solution against zone-traversal, we recommend > On-Demand NSEC synthesis. This may be stating the obvious, but some things this draft proposes are in the nature of transition mechanisms of the protocol (e.g. TCR), and some are in the nature of "things that can be done by those operators who find enumberation problematic". For completeness, one thing in the latter category that is not found in the draft but can be done by such operators is "stick with non-sec DNS", and I suspect, where synthesis is not practical, this may be the workaround of choice until -ter is available; the advantages/disadvantages etc. sections should be obvious. 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 Thu Jun 10 15:46:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27306 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 15:46:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYVRu-0002DC-G1 for namedroppers-data@psg.com; Thu, 10 Jun 2004 19:42:54 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYVRt-0002Co-IO for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 19:42:53 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 08F1319668; Thu, 10 Jun 2004 21:42:50 +0200 (CEST) Date: Thu, 10 Jun 2004 21:42:49 +0200 (CEST) From: Jakob Schlyter <jakob@rfc.se> To: Ben Laurie <ben@algroup.co.uk> Cc: Edward Lewis <edlewis@arin.net>, "Olaf M. Kolkman" <olaf@ripe.net>, =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= <ogud@ogud.com>, IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms In-Reply-To: <40C88D07.3040700@algroup.co.uk> Message-ID: <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 10 Jun 2004, Ben Laurie wrote: > A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50 1024 bit > RSA signatures a second and less than 10 2048 bit signatures. a decent crypto accelerator can do 4000+ 1024-bit RSA sigs/sec. 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 Thu Jun 10 15:58:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28043 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 15:58:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYVc3-0003IY-Jn for namedroppers-data@psg.com; Thu, 10 Jun 2004 19:53:23 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYVc2-0003ID-7x for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 19:53:22 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27673; Thu, 10 Jun 2004 15:53:04 -0400 (EDT) Message-Id: <200406101953.PAA27673@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-trans-00.txt Date: Thu, 10 Jun 2004 15:53:04 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Evaluating DNSSEC Transition Mechanisms Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-trans-00.txt Pages : 14 Date : 2004-6-10 This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-trans-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-10161714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-trans-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-10161714.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 Thu Jun 10 16:04:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28370 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 16:04:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYVjD-0004Q5-PV for namedroppers-data@psg.com; Thu, 10 Jun 2004 20:00:47 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYVjC-0004Pn-Ty for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 20:00:47 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id D121019668; Thu, 10 Jun 2004 22:00:43 +0200 (CEST) Date: Thu, 10 Jun 2004 22:00:42 +0200 (CEST) From: Jakob Schlyter <jakob@rfc.se> To: Ben Laurie <ben@algroup.co.uk> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <40C889C3.5050609@algroup.co.uk> Message-ID: <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> References: <40C889C3.5050609@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 10 Jun 2004, Ben Laurie wrote: > We (that is, Nominet) can't at present imagine how we could deploy this. The > problems we see are: > > a) Invitation to DoS us, suggesting we'd need to investigate crypto offload > devices. yes, crypto offload devices are needed. and if the crypto stuff performs close the normal query processing, DoS doesn't really count. if you add rate limiting and such to this, it's not be a problem. > b) Changes to software required, and hence a long period of validation and > testing. I believe adding support for on-demand nsec is way cheaper then adding support for any form of nsec2. > c) Exposure of private keys. you would use a separate set of keys for on-demand nsec signing. > This sounds no easier to deploy in practice than NSEC2 would be, even if > it didn't have problems that appear to make it unworkable in any case. easier for whom? nsec2 has to be deployed everywhere and not just at the nominet nameservers. if you can't deploy something based on nsec, waiting for nsec2 is always an option. if your domain holders care to wait that is. 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 Thu Jun 10 16:15:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28754 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 16:15:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYVuA-0005sH-RQ for namedroppers-data@psg.com; Thu, 10 Jun 2004 20:12:06 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYVu1-0005qd-SF for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 20:11:58 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5AKBbUZ072787; Thu, 10 Jun 2004 22:11:38 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5AKBXqF024953; Thu, 10 Jun 2004 22:11:33 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5AKBWpu024950; Thu, 10 Jun 2004 22:11:32 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 10 Jun 2004 22:11:32 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Jakob Schlyter <jakob@rfc.se> cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, "Olaf M. Kolkman" <olaf@ripe.net>, =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= <ogud@ogud.com>, IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms In-Reply-To: <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> Message-ID: <Pine.LNX.4.58.0406102148580.2889@elektron.atoom.net> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 10 Jun 2004, Jakob Schlyter wrote: > On Thu, 10 Jun 2004, Ben Laurie wrote: > > > A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50 1024 bit > > RSA signatures a second and less than 10 2048 bit signatures. > > a decent crypto accelerator can do 4000+ 1024-bit RSA sigs/sec. Would you really want to use 1024-bit RSA for those short-lived denial of existence records, which have a TTL of SOA minimum and prolly a sig-lifetime that is equally low (in the order of minutes, instead of days) ? 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 Thu Jun 10 16:19:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28861 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 16:19:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYVxW-0006JJ-51 for namedroppers-data@psg.com; Thu, 10 Jun 2004 20:15:34 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYVxU-0006IS-9N for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 20:15:33 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i5AKFLbs020544; Thu, 10 Jun 2004 16:15:21 -0400 To: Jakob Schlyter <jakob@rfc.se> Cc: Ben Laurie <ben@algroup.co.uk>, Edward Lewis <edlewis@arin.net>, "Olaf M. Kolkman" <olaf@ripe.net>, =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= <ogud@ogud.com>, IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> From: Derek Atkins <warlord@MIT.EDU> Date: Thu, 10 Jun 2004 16:15:21 -0400 In-Reply-To: <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> (Jakob Schlyter's message of "Thu, 10 Jun 2004 21:42:49 +0200 (CEST)") Message-ID: <sjmk6yf5fvq.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jakob Schlyter <jakob@rfc.se> writes: > On Thu, 10 Jun 2004, Ben Laurie wrote: > >> A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50 >> 1024 bit RSA signatures a second and less than 10 2048 bit >> signatures. > > a decent crypto accelerator can do 4000+ 1024-bit RSA sigs/sec. > > jakob My laptop, a 2-year-old Thinkpad, can do 145 1024-bit RSA private-key operations per second using the openssl library: sign verify sign/s verify/s rsa 512 bits 0.0015s 0.0001s 673.1 6759.4 rsa 1024 bits 0.0068s 0.0004s 148.0 2565.7 rsa 2048 bits 0.0392s 0.0012s 25.5 826.5 rsa 4096 bits 0.2589s 0.0041s 3.9 246.7 A $400 dell that I just bought a couple months ago is significantly faster (about 200 1024 sigs/sec): sign verify sign/s verify/s rsa 512 bits 0.0010s 0.0001s 995.4 11585.9 rsa 1024 bits 0.0050s 0.0003s 201.8 3878.2 rsa 2048 bits 0.0293s 0.0009s 34.1 1146.5 rsa 4096 bits 0.1998s 0.0031s 5.0 322.2 If the server starts getting resource constrained genering NSEC records it can always just implement RED and return SERVFAIL ;) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 16:28:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29079 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 16:28:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYW7B-0007UR-SA for namedroppers-data@psg.com; Thu, 10 Jun 2004 20:25:33 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYW7A-0007U0-PF for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 20:25:33 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5AKPGuO072899; Thu, 10 Jun 2004 22:25:17 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5AKPAJw025242; Thu, 10 Jun 2004 22:25:10 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5AKPAXf025239; Thu, 10 Jun 2004 22:25:10 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 10 Jun 2004 22:25:10 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Derek Atkins <warlord@MIT.EDU> cc: IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms In-Reply-To: <sjmk6yf5fvq.fsf@dogbert.ihtfp.org> Message-ID: <Pine.LNX.4.58.0406102223180.2889@elektron.atoom.net> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> <sjmk6yf5fvq.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 10 Jun 2004, Derek Atkins wrote: > Jakob Schlyter <jakob@rfc.se> writes: > > > On Thu, 10 Jun 2004, Ben Laurie wrote: > > > >> A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50 > >> 1024 bit RSA signatures a second and less than 10 2048 bit > >> signatures. > > > > a decent crypto accelerator can do 4000+ 1024-bit RSA sigs/sec. > > > > jakob > > My laptop, a 2-year-old Thinkpad, can do 145 1024-bit RSA private-key > operations per second using the openssl library: > > sign verify sign/s verify/s > rsa 512 bits 0.0015s 0.0001s 673.1 6759.4 > rsa 1024 bits 0.0068s 0.0004s 148.0 2565.7 > rsa 2048 bits 0.0392s 0.0012s 25.5 826.5 > rsa 4096 bits 0.2589s 0.0041s 3.9 246.7 > > A $400 dell that I just bought a couple months ago is significantly > faster (about 200 1024 sigs/sec): > > sign verify sign/s verify/s > rsa 512 bits 0.0010s 0.0001s 995.4 11585.9 > rsa 1024 bits 0.0050s 0.0003s 201.8 3878.2 > rsa 2048 bits 0.0293s 0.0009s 34.1 1146.5 > rsa 4096 bits 0.1998s 0.0031s 5.0 322.2 > > If the server starts getting resource constrained genering NSEC > records it can always just implement RED and return SERVFAIL ;) I just received a private message stating their nitrox-II-cn2560 accelerator card can do about 40.000 1024-bit RSA ops/sec. I think we're done with subject now, are we ? 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 Thu Jun 10 17:14:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00560 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 17:14:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYWoc-000Cz9-RJ for namedroppers-data@psg.com; Thu, 10 Jun 2004 21:10:26 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYWob-000Cyl-LB for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 21:10:25 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 10 Jun 2004 17:10:24 -0400 id 00142AFC.40C8CE40.000031A7 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Thu, 10 Jun 2004 17:10:24 -0400 User-Agent: KMail/1.6.2 References: <40BDCD26.4050808@ripe.net> <20040603152327.6de24e15.olaf@ripe.net> <200406091146.01973.davidb@verisignlabs.com> In-Reply-To: <200406091146.01973.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406101710.24434.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 09 June 2004 11:46 am, David Blacka wrote: > I still think a better solution here is to explain what caches SHOULD NOT > (or MUST NOT) do. If I can, I will try and submit language like this, and > the WG can decide which it prefers. Here is what I have come up with: The use of DNSSEC exposes more information about a zone than was previously available to resolvers. In particular, DNSSEC exposes the existence of wildcard records within a zone via RRSIG records, and non-existence of names via NSEC records. To avoid unexpected and undesirable side-effects, a security-aware resolver SHOULD NOT make special use of this additional information. Security-aware resolvers SHOULD NOT use received NSEC records for negative caching purposes beyond that specified by [RFC 2308]. For example, if a resolver receives an NSEC record as part of a response indicating that a given QNAME did not exist, the resolver SHOULD only return that NSEC record when queried directly for the NSEC record by name (e.g., via QTYPE=NSEC or QTYPE=ANY), or when answering a query for the original QNAME, QCLASS, and QTYPE. In addition, security-aware resolvers SHOULD NOT attempt to perform wildcard synthesis on behalf of a different authoritative server. What do you folks 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 Thu Jun 10 17:27:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01005 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 17:27:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYX2e-000Ep1-HX for namedroppers-data@psg.com; Thu, 10 Jun 2004 21:24:56 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYX2b-000Eob-SL for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 21:24:53 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7AF2213DF0 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 21:24:53 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms In-Reply-To: Message from Derek Atkins <warlord@MIT.EDU> of "Thu, 10 Jun 2004 16:15:21 -0400." <sjmk6yf5fvq.fsf@dogbert.ihtfp.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Jun 2004 21:24:53 +0000 Message-Id: <20040610212453.7AF2213DF0@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If the server starts getting resource constrained genering NSEC > records it can always just implement RED and return SERVFAIL ;) i'm glad you put a ";)" symbol on that, indicating that you're joking, because otherwise someone would have to explain what bimodality is and why it's bad to let an attacker control one's mode. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 17:47:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01670 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 17:47:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYXLs-000H9t-7g for namedroppers-data@psg.com; Thu, 10 Jun 2004 21:44:48 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYXLo-000H93-9j for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 21:44:45 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BYXLn-0001hc-00 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 23:44:43 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 23:44:43 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 23:44:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Date: Thu, 10 Jun 2004 23:44:40 +0200 Lines: 27 Message-ID: <iluy8mv84vr.fsf@latte.josefsson.org> References: <40C889C3.5050609@algroup.co.uk> <518CC372ADAC1DF1914790E2@[192.168.100.19]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:sIkZ66o997Fan3NWvb7eURPiC/U= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Alex Bligh <alex@alex.org.uk> writes: > --On 10 June 2004 17:18 +0100 Ben Laurie <ben@algroup.co.uk> wrote: > >> "2.1.1.4 Cons >> >> Unbalanced cost is a ground for DDoS. Though this protects against >> enumeration, it is not really a path for versioning." >> >> This should also mention the security risk of the requirement for an >> online key. > > Which you could add are of particular concern where not all secondaries > are under the same administrative control as the primary (whereas > with DNSSEC-bis this is irrelevant) I think this point should be emphasized more. With the solution dnssec-trans appear to propose, it is not enough to transfer a zone file to a secondary, you must also transfer the private keys to all secondaries, and keep the keys synchronized. That is not a trivial problem. It is complicated further by considering the lose trust zone administrators often have on the organizations running their slave servers. Typically they do not have any secure communication channels between them. 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 Thu Jun 10 17:55:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02496 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 17:55:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYXUA-000IGk-P5 for namedroppers-data@psg.com; Thu, 10 Jun 2004 21:53:22 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYXUA-000IGV-4H for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 21:53:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AE2AD13951 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 21:53:21 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Thu, 10 Jun 2004 20:33:41 +0100." <B211BDC326E5FE10E3E32687@[192.168.100.19]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Jun 2004 21:53:21 +0000 Message-Id: <20040610215321.AE2AD13951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... For completeness, one thing in the latter category that is not > found in the draft but can be done by such operators is "stick with > non-sec DNS", and I suspect, where synthesis is not practical, this > may be the workaround of choice until -ter is available; the > advantages/disadvantages etc. sections should be obvious. for operators of enterprise zones this is a practical alternative. for operators of delegation-only or delegation-mostly zones where the subzones are held by "registrants", this alternative is only practical if most of those registrants are happy to be disconnected from dnssec in this way. that's one of the driving forces behind the several known variants of "islands of security", including the ihren-manning-kolkman "perl goo" and also including conrad-vixie-kosters-weiler "dlv" (which is present, though in an incomplete and as-yet-undocumented form, in 9.3.0-betaNN). it's necessary, before an operator selects the "just don't bother with dnssec until -ter comes out" alternative, to find out what impact that will have (if any) on subdomain holders might care more about dnssec than their superzone operator does. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 18:04:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02957 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 18:04:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYXcn-000Joz-V6 for namedroppers-data@psg.com; Thu, 10 Jun 2004 22:02:17 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYXcn-000Joe-8l for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 22:02:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CE6BE13951 for <namedroppers@ops.ietf.org>; Thu, 10 Jun 2004 22:02:16 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: Message from Simon Josefsson <jas@extundo.com> of "Thu, 10 Jun 2004 23:44:40 +0200." <iluy8mv84vr.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 10 Jun 2004 22:02:16 +0000 Message-Id: <20040610220216.CE6BE13951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> This should also mention the security risk of the requirement for an > >> online key. > > > > Which you could add are of particular concern where not all > > secondaries are under the same administrative control as the primary > > (whereas with DNSSEC-bis this is irrelevant) > > I think this point should be emphasized more. With the solution > dnssec-trans appear to propose, it is not enough to transfer a zone > file to a secondary, you must also transfer the private keys to all > secondaries, and keep the keys synchronized. That is not a trivial > problem. and yet, this is a subset variation on what the ihren-manning-kolkman "perl goo" does, and so this approach ought not be discounted on the sole basis of its nontriviality. it's possible that many nameserver administrators will already be doing some kind of outofband keyrollover. > It is complicated further by considering the lose trust zone > administrators often have on the organizations running their slave > servers. Typically they do not have any secure communication channels > between them. actually, typically these days, they do have such a secure channel, in the form of a shared TSIG key used to control/authenticate AXFR/IXFR. (an upcoming tool from isc leverages this trust relationship with what we're calling a "metazone", which is why your statement caught my eye.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 10 18:32:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04856 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 18:32:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYY2K-000N1a-Pl for namedroppers-data@psg.com; Thu, 10 Jun 2004 22:28:40 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYY2K-000N1N-0c for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 22:28:40 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 36D6E1FE67; Thu, 10 Jun 2004 23:28:39 +0100 (BST) Date: Thu, 10 Jun 2004 23:28:41 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, DNSEXT WG <namedroppers@ops.ietf.org> Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <87FC7D046DE077407A1FEAD4@[192.168.100.22]> In-Reply-To: <20040610215321.AE2AD13951@sa.vix.com> References: <20040610215321.AE2AD13951@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 10 June 2004 21:53 +0000 Paul Vixie <paul@vix.com> wrote: > for operators of enterprise zones this is a practical alternative. for > operators of delegation-only or delegation-mostly zones where the subzones > are held by "registrants", this alternative is only practical if most of > those registrants are happy to be disconnected from dnssec in this way. Sure - I wasn't make a policy point, I was just making the point that draft-ietf-dnsext-dnssec-trans-00.txt omitted this possibility. Clearly it has both pros (no alteration to -bis, implementation is hardly difficult!) and cons (um, no DNSSEC functionality). 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 Thu Jun 10 18:49:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05241 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 18:49:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYYK8-000P1e-SF for namedroppers-data@psg.com; Thu, 10 Jun 2004 22:47:04 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYYK7-000P1N-UP for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 22:47:04 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 088261FE67; Thu, 10 Jun 2004 23:47:03 +0100 (BST) Date: Thu, 10 Jun 2004 23:47:05 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org> Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <FB383A6F98176BFAD7B438AA@[192.168.100.22]> In-Reply-To: <518CC372ADAC1DF1914790E2@[192.168.100.19]> References: <40C889C3.5050609@algroup.co.uk> <518CC372ADAC1DF1914790E2@[192.168.100.19]> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (with apologies for replying to myself) --On 10 June 2004 20:25 +0100 Alex Bligh <alex@alex.org.uk> wrote: > Which you could add are of particular concern where not all secondaries > are under the same administrative control as the primary (whereas > with DNSSEC-bis this is irrelevant) Hmmm... a random late night thought: would it be possible: 1. For the primary to sign the zone itself, with pre-synthesized NSEC records adjacent to all "real" records (which I am guessing would remove a substantial amount of load), then 2. either a) the secondaries synthesize only the remaining NSEC records (which perhaps could be prioritized differently in terms of response time); or b) the secondaries forward such remaining NSEC requests to one (or or more) primaries or false primaries under the administrative control of the zone operator (removing the need for key distribution). I am considering the ccTLD case where it is relatively common for some but not all secondaries to be under the administrative control of the zone operator. 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 Thu Jun 10 19:36:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06744 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 19:36:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYZ2N-0005fj-8i for namedroppers-data@psg.com; Thu, 10 Jun 2004 23:32:47 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYZ2L-0005fC-F8 for namedroppers@ops.ietf.org; Thu, 10 Jun 2004 23:32:46 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id LAA25384 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 11:32:44 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i5ANWhfw034434 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 11:32:43 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: NSEC synthesis and the NSEC Next Domain Name field From: Don Stokes <don@plugh.daedalus.co.nz> Date: Fri, 11 Jun 2004 11:32:43 +1200 Message-ID: <34433.1086910363@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Folks, If one is to synthesise NSEC records, either online, or staticly in "NSEC white lies" the recent draft put it, what should one place in the Next Domain Name field of the NSEC record? As things stand, it appears that given a name "x.example.", then the very next name that could be created in given the canonical ordering rules would be "\001.x.example.". However, that doesn't sit nicely (although this might not be a problem) when x.example is a delegation; one doesn't really want "fake" NSEC records pointing at subdomains that don't exist, e.g. x.example. NS ns1.example.com. NS ns2.example.com. NSEC \001.x.example. NS RRSIG NSEC as \001.x.example is out of bailiwick. The "next" name at the same level as x.example would be "x\001.example.". What happens if you get: x.example. NSEC x.example. ... Could replaying that NSEC record be used to (e.g.) forge a denial of y.example.? What I'm looking for is a standard, canonical way of saying, "this name, and only this name, does not exist", preferably without reference to other data. Is this a special case for the NSEC Next Domain Name field, or can it reliably be fudged? Could the field be given a value that meant "there is no next domain name field; this NSEC only refers to the name queried"? -- 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 Thu Jun 10 22:49:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13293 for <dnsext-archive@lists.ietf.org>; Thu, 10 Jun 2004 22:49:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYc1S-0005QW-L1 for namedroppers-data@psg.com; Fri, 11 Jun 2004 02:44:02 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYc1R-0005QG-Iu for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 02:44:01 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5B2ehWa063380 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 02:40:46 GMT (envelope-from roy+dated+1089507225.f83a5d@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5B2edso012265 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 03:40:39 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5B0t0MT061155 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 01:56:15 +0100 (BST) (envelope-from roy+dated+1089507225.f83a5d@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5B0rjEV061150 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 01:53:45 +0100 (BST) (envelope-from roy+dated+1089507225.f83a5d@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 11 Jun 2004 01:53:45 +0100 (BST) Message-ID: <16585.664.987120.394778@giles.gnomon.org.uk> Date: Fri, 11 Jun 2004 01:53:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Online signing (was: Evaluating DNSSEC transition mechanisms) In-Reply-To: <Pine.LNX.4.58.0406102148580.2889@elektron.atoom.net> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> <Pine.LNX.4.58.0406102148580.2889@elektron.atoom.net> X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami <roy@gnomon.org.uk> X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Roy" == Roy Arends <roy@dnss.ec> writes: Roy> Would you really want to use 1024-bit RSA for those Roy> short-lived denial of existence records, which have a TTL of Roy> SOA minimum and prolly a sig-lifetime that is equally low (in Roy> the order of minutes, instead of days) ? Apologies if parts of this breach radio silence, but it feels on topic given the recommendation of online signing in the proposal we're discussing... Please take this offline if you want to discuss the details of what I suggest (rather than the transition implications). If I were architecting a system with online signing, I agree that I would go for really short key lifetimes to allow me to safely use shorter keys than I'd otherwise need to -- I'd roll over hourly if not more frequently. This in turn implies automated rollover, and hence the keys that sign those keys must also be online. So we'd need a key heirarchy where the short term online keys are signed by a long term online key which is in turn signed by a potentially offline key (probably the ZSK, which is of course in turn signed by the KSK). And you'd want a mechanism to prevent either of the online keys being used as a normal ZSK. I don't think you can achieve this directly within the current DNSSECbis (which is not to say the current proposal is a bad idea; just that DNSSECbis doesn't currently provide an optimal framework for online signing). Is there an easy way of adding such a key heirarchy to DNSSECbis later? As a slight aside, if I were architecting such a system from scratch, I'd be inclined to consider combining it with Bloom filters, and only signing denials where there was a collision in the Bloom filter -- in other cases the Bloom filter itself could be used to prove non-existence. I'm reasonably confident that the combination of these two measures would make the computational overhead of online signing a non-issue for a normal query load, and they'd remove the concerns of offline dictionary attacks. Whether or not they'd be adequate to deal with DoS scenarios is less obvious to me... I realize we're in radio silence about the details of DNSSECter, so I don't want to get into a detailed discussion about this idea. I mention it only because I haven't seen such an idea mentioned, and if we're seriously considering online signing then it's worth bearing in mind the possible shapes that a DNSSECter based on online signing might take to help inform the current extensibility analysis... -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 Jun 11 00:15:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15426 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 00:15:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYdOx-000Gd0-JT for namedroppers-data@psg.com; Fri, 11 Jun 2004 04:12:23 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYdOw-000Gck-Jy for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 04:12:22 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 363EF42B2 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 00:12:19 -0400 (EDT) Date: Fri, 11 Jun 2004 00:12:19 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: dns rr types In-Reply-To: <20040609221226.GA28097@vacation.karoshi.com.> References: <a0602042fbced2e81d1a4@192.136.136.83> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040611041219.363EF42B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 9 Jun 2004 22:12:26 +0000, Bill Manning wrote: > > legacy stuff. our old zones here had UNIFO/UID/GID data and the 4.9 > upgrades (i think it was 4.9...) summarily dropped support for these > rr types, causing me to have to edit the zone files, removing these. > > I'd have to poll the old timers, but the rdata for these records roughly > matched the following: > > UINFO == "human name/account" > UID == "Unix UID" > GID == "Unix GID" > > No ID or RFC documents these bad boys. One might find more data in the > old CHAOS/Athena docsets :) I suppose one would need to have lived through the 1980s at MIT to understand why the phrase "Chaos/Athena" is so hilarious. My recollection is that these RR types date back to the era when BIND 4 was still being maintained at UC Berkeley, and may have originated at UCB itself. It's unlikely that they came from MIT's Project Athena, which did indeed use DNS to distribute such data, but did so via Hesiod TXT RRs in the HS class. It's -very- unlikely that this had anything to do with Chaosnet, among other reasons, because there were never that many Chaosnet Unix machines to begin with, and as far as I know the Unix Chaosnet code base never made the jump from host tables to 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 Jun 11 00:38:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15977 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 00:38:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYdlC-000Iaa-1i for namedroppers-data@psg.com; Fri, 11 Jun 2004 04:35:22 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYdlA-000IaG-V3 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 04:35:21 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i5B4ZFiC016535; Thu, 10 Jun 2004 21:35:15 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <KNPYJC7X>; Thu, 10 Jun 2004 21:35:15 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E5DBDAC@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Rob Austein'" <sra@isc.org>, namedroppers@ops.ietf.org Subject: RE: dns rr types Date: Thu, 10 Jun 2004 21:35:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It's unlikely that they came from MIT's Project Athena, which did > indeed use DNS to distribute such data, but did so via Hesiod TXT RRs > in the HS class. It's -very- unlikely that this had anything to do > with Chaosnet, among other reasons, because there were never that many > Chaosnet Unix machines to begin with, and as far as I know the Unix > Chaosnet code base never made the jump from host tables to DNS. A precedent for use of TXT RRs for signalling... The Genera codebase did make the jump... or at least it tried to I gave up and hard coded the host table but I spent some time trying to make this work for the Whitehouse machines first. There did seem to be some code on the other end. Whether it was debugged before symbolics exploded is anyone's guess. The explosion occurred long before I worked on 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 Jun 11 03:38:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04298 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 03:38:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYgX3-000BB9-Bh for namedroppers-data@psg.com; Fri, 11 Jun 2004 07:32:57 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYgX2-000BAu-Fv for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 07:32:56 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 0D43955E07; Fri, 11 Jun 2004 09:32:56 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C23A24FF19 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 09:32:55 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5B7Wtm0030099 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 09:32:55 +0200 Date: Fri, 11 Jun 2004 09:32:55 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: Prupose of draft-ietf-dnsext-dnssec-trans-00.txt Message-Id: <20040611093255.5bb9e93b.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.061124 / 0.0 / 0.0 / disabled X-RIPE-Signature: b970d9436c20d40415322d0e6bbde7e4 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, This is to try to set the focus for the discussion. We now have an inventory of several ways to introduce prevention of zone enumeration. The question is if with this set of ways forward we can ship DNSSEC-bis without closing the doors on ourselves. We do not want to select the actual solution now, we want to make sure if we do not close the door on ourselves. If you think we are closing the door on ourselves by shipping DNSSEC-bis as is than please speak up (as Simon Josefsson did in the "DNSKEY flags field" thread). The drafts is for our 'corporate memory' and to help us when we work on the zone enumeration later. We do not have to have a perfectly cooked version before DNSSEC-bis ships. Please try to work towards the common goal of getting DNSSEC-bis to the IESG in a good shape without closing the door on future work on prevention of zone enumeration. -- Olaf DNSEXT co-chair. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 04:01:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05245 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 04:01:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYgw7-000DcS-RR for namedroppers-data@psg.com; Fri, 11 Jun 2004 07:58:51 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYgw4-000Dc5-Vi for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 07:58:49 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id B1FCE55E30; Fri, 11 Jun 2004 09:57:44 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5BECD55E1A; Fri, 11 Jun 2004 09:57:44 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5B7vim0005862; Fri, 11 Jun 2004 09:57:44 +0200 Date: Fri, 11 Jun 2004 09:57:44 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Edward Lewis <edlewis@arin.net> Cc: jas@extundo.com, namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Message-Id: <20040611095744.39b826ab.olaf@ripe.net> In-Reply-To: <a06020436bcee382f9bbc@[192.136.136.83]> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 93dfcd9f21099ab4955a80a295dbb216 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 10 Jun 2004 12:28:22 -0400 Edward Lewis <edlewis@arin.net> wrote: > > I think the problem (and I'm off on a tangent now) is that you have > to make the verifier be able to realize at the DS RR set that the > child will have no acceptable keys for me - at the point where I can > verify the "end of understandable security" while still being secure > enough to trust it. > One of the things you have to take into account is the signature strip attack (there was a long thread on that under one of the questions, Weiler started that one if I recall well.). You have to decide, as soon as you receive the DNSKEY RRset, which keys the data MUST be signed with in order to not be bogus. So you have to ordonate something like "If any of the secure entry poin into the zone (either the DS RRs or trust anchors) points to DNSKEY RRs in the apex with all zero values in bits 8-14 than any RRset in the zone MUST have at least one RRSIG generated by an all-zero keys, RRsets not signed by an RRSIG generated by an all-zero key are to be treated as bogus." In addition you have to say that if you find non-zero bit keys you treat the zone as insecure. "If none the secure entry point into the zone point to DNSKEY RRs in the apex with non-zero values in bits 8-14 than the zone may be treated as insecure." -- Olaf No hats Playing with bits at this stage is stepping on corner-case ground. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 04:38:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07131 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 04:38:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYhUi-000GX2-LT for namedroppers-data@psg.com; Fri, 11 Jun 2004 08:34:36 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYhUg-000GWj-Ma for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 08:34:35 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5B8YQ9m080498; Fri, 11 Jun 2004 10:34:27 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5B8YLMZ005594; Fri, 11 Jun 2004 10:34:21 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5B8YL1W005591; Fri, 11 Jun 2004 10:34:21 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 11 Jun 2004 10:34:21 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Roy Badami <roy@gnomon.org.uk> cc: namedroppers@ops.ietf.org Subject: Re: Online signing (was: Evaluating DNSSEC transition mechanisms) In-Reply-To: <16585.664.987120.394778@giles.gnomon.org.uk> Message-ID: <Pine.LNX.4.58.0406111021380.2889@elektron.atoom.net> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> <Pine.LNX.4.58.0406102148580.2889@elektron.atoom.net> <16585.664.987120.394778@giles.gnomon.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Roy Badami wrote: > As a slight aside, if I were architecting such a system from scratch, > I'd be inclined to consider combining it with Bloom filters, and only > signing denials where there was a collision in the Bloom filter -- in > other cases the Bloom filter itself could be used to prove > non-existence. > > I'm reasonably confident that the combination of these two measures > would make the computational overhead of online signing a non-issue > for a normal query load, and they'd remove the concerns of offline > dictionary attacks. Whether or not they'd be adequate to deal with > DoS scenarios is less obvious to me... > > I realize we're in radio silence about the details of DNSSECter, so I > don't want to get into a detailed discussion about this idea. I > mention it only because I haven't seen such an idea mentioned, and if > we're seriously considering online signing then it's worth bearing in > mind the possible shapes that a DNSSECter based on online signing > might take to help inform the current extensibility analysis... Bloom filters in DNSSEC is not new. SMB introduced them: www.research.att.com/~smb/papers/draft-bellovin-dnsext-bloomfilt-00.txt The combination with ad-hoc signing of synthesised NSEC where otherwise it would have been a false positive is new. Anyway, I think crypto acceleration cards ops/sec are currently faster then a DNSSEC capable aparatus can serve in q/sec. I hope the assumptions one might have about a crypto-driven DDoS attack is hereby tuned to a non-issue. 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 Jun 11 04:38:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07149 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 04:38:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYhX8-000GkL-95 for namedroppers-data@psg.com; Fri, 11 Jun 2004 08:37:06 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYhX7-000Gk6-9K for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 08:37:05 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id D0BF21FF845; Fri, 11 Jun 2004 08:37:03 +0000 (GMT) Message-ID: <40C96F2F.2040108@algroup.co.uk> Date: Fri, 11 Jun 2004 09:37:03 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Reid <jim@rfc1035.com> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <23055.1086885442@gromit.rfc1035.com> In-Reply-To: <23055.1086885442@gromit.rfc1035.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Reid wrote: >>>>>>"Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > > Ben> Note sure I understand this - the presence of v2 of NSEC > Ben> would signal that there are also NSECINFO and EXISTS records, > Ben> wouldn't it? > > Not necessarily. Who can say now what NSECv2 will finally look like or > predict how many new RR types it'll need? I don't see why that matters - a resolver that understood NSECv2 would also understand the other RR types, and one that didn't, err, wouldn't. -- 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 Jun 11 04:44:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07366 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 04:43:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYhcX-000HKl-QC for namedroppers-data@psg.com; Fri, 11 Jun 2004 08:42:41 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYhcW-000HKW-G4 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 08:42:41 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 9E5AF1FF845; Fri, 11 Jun 2004 08:42:39 +0000 (GMT) Message-ID: <40C9707E.8090001@algroup.co.uk> Date: Fri, 11 Jun 2004 09:42:38 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Philosophy behind unsigned NS records? References: <20040610171554.DD5A413951@sa.vix.com> In-Reply-To: <20040610171554.DD5A413951@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>i think that the use of dns over non-ip networks like tunnels is not >>>described anywhere, and so the dnssec-bis protocol and docset has no >>>reason to mention the configuration you've described. it's the same >>>as NAT. ... and the dnssec-bis design team would be foolish to try >>>to cover undefined working conditions. > > >>... but I do think it should be explained and possibly also mentioned >>in the security considerations. > > why is that, exactly? should we also mention that it won't work over > sneaker-net or avian-net, or after global thermonuclear war? i'm not > *just* being peevish, i'm trying to point out that there are a lot of > actual, potential, or imaginable circumstances under which dnssec-bis > would be unusable or inapplicable. why is this particular one worthy > of specific mention in the document? The fact that delegated NS records are not signed opens them up to spoofing, which is a security consideration. Explaining why they are not signed is just being friendly to people not party to discussions on this list. > some years ago an earlier instance of IAB gave us a "statement regarding > the end-to-end nature of internet communications" or some such. i thought > it was a mistake, since even at that time, real internet communications > used very different models than the one described in that statement. but > the one thing that statement gave us was well defined starting conditions > for subsequent (or even previous) protocol specifications. > > using dnssec to get a secure path from some trust anchor (like the root, > maybe, someday) to some delegation point, where the NS RR was trustworthy > but the A RR maybe or maybe not so and the zone definitely not, on the > basis that perhaps some validators will have out-of-band methods of > trusting the communications with or content received from the servers for > such zones, is so far away from dnssec-bis's "starting conditions" that > you might just as well talk about how dnssec-bis would work for harry > potter if his wand spoke tcp/ip. I was giving examples of why someone might care, not suggesting that these examples should be important to, or even documented by, dnssec-bis. 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 Jun 11 04:48:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07581 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 04:48:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYhg4-000Hg3-Uj for namedroppers-data@psg.com; Fri, 11 Jun 2004 08:46:20 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYhg3-000Hfm-VJ for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 08:46:20 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 3A36D1FF845; Fri, 11 Jun 2004 08:46:19 +0000 (GMT) Message-ID: <40C9715A.7020600@algroup.co.uk> Date: Fri, 11 Jun 2004 09:46:18 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: synthesis in -ter; HEREIS draft-vixie-dnssec-ter-01.txt References: <20040610173734.8020F13DDA@sa.vix.com> In-Reply-To: <20040610173734.8020F13DDA@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > oh hell. i let myself be fooled by the radio silence and by my private > e-mail to at least one of the "dnssec transition mechanism" subcommittee, > into thinking that i didn't need to push out an updated version of this > draft that was absent the synthesis section (formerly 2.5). HEREIS -01: I like this proposal. 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 Jun 11 04:53:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07781 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 04:53:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYhlN-000IMq-Tj for namedroppers-data@psg.com; Fri, 11 Jun 2004 08:51:49 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYhlM-000IML-Lk for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 08:51:49 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id B2BA81FF845; Fri, 11 Jun 2004 08:51:47 +0000 (GMT) Message-ID: <40C972A3.6010603@algroup.co.uk> Date: Fri, 11 Jun 2004 09:51:47 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> Cc: Derek Atkins <warlord@MIT.EDU>, IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Evaluating DNSSEC transition mechanisms References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> <sjmk6yf5fvq.fsf@dogbert.ihtfp.org> <Pine.LNX.4.58.0406102223180.2889@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406102223180.2889@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Thu, 10 Jun 2004, Derek Atkins wrote: > > >>Jakob Schlyter <jakob@rfc.se> writes: >> >> >>>On Thu, 10 Jun 2004, Ben Laurie wrote: >>> >>> >>>>A mid-range (that is, in the vicinity of 1GHz) P4 can do around 50 >>>>1024 bit RSA signatures a second and less than 10 2048 bit >>>>signatures. >>> >>>a decent crypto accelerator can do 4000+ 1024-bit RSA sigs/sec. >>> >>> jakob >> >>My laptop, a 2-year-old Thinkpad, can do 145 1024-bit RSA private-key >>operations per second using the openssl library: >> >> sign verify sign/s verify/s >>rsa 512 bits 0.0015s 0.0001s 673.1 6759.4 >>rsa 1024 bits 0.0068s 0.0004s 148.0 2565.7 >>rsa 2048 bits 0.0392s 0.0012s 25.5 826.5 >>rsa 4096 bits 0.2589s 0.0041s 3.9 246.7 >> >>A $400 dell that I just bought a couple months ago is significantly >>faster (about 200 1024 sigs/sec): >> >> sign verify sign/s verify/s >>rsa 512 bits 0.0010s 0.0001s 995.4 11585.9 >>rsa 1024 bits 0.0050s 0.0003s 201.8 3878.2 >>rsa 2048 bits 0.0293s 0.0009s 34.1 1146.5 >>rsa 4096 bits 0.1998s 0.0031s 5.0 322.2 >> >>If the server starts getting resource constrained genering NSEC >>records it can always just implement RED and return SERVFAIL ;) > > I just received a private message stating their nitrox-II-cn2560 > accelerator card can do about 40.000 1024-bit RSA ops/sec. > > I think we're done with subject now, are we ? In the sense that we know that crypto accelerators would be necessary, and that one exists of sufficient power (though not, as far as I can see, availability in a useful form) but unknown cost, then yes. 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 Jun 11 04:58:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07936 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 04:58:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYhpY-000IwO-NB for namedroppers-data@psg.com; Fri, 11 Jun 2004 08:56:08 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYhpX-000Ive-97 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 08:56:07 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 735CA1FF845; Fri, 11 Jun 2004 08:56:06 +0000 (GMT) Message-ID: <40C973A5.4020706@algroup.co.uk> Date: Fri, 11 Jun 2004 09:56:05 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakob Schlyter <jakob@rfc.se> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> In-Reply-To: <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jakob Schlyter wrote: > On Thu, 10 Jun 2004, Ben Laurie wrote: > >> We (that is, Nominet) can't at present imagine how we could deploy >> this. The problems we see are: >> >> a) Invitation to DoS us, suggesting we'd need to investigate crypto >> offload devices. > > > yes, crypto offload devices are needed. and if the crypto stuff performs > close the normal query processing, DoS doesn't really count. if you add > rate limiting and such to this, it's not be a problem. Rate limiting _is_ a problem since it causes lack of service. >> b) Changes to software required, and hence a long period of validation >> and testing. > > I believe adding support for on-demand nsec is way cheaper then adding > support for any form of nsec2. I'll let you know what I believe when I've finished adding nsec2 support. >> c) Exposure of private keys. > > you would use a separate set of keys for on-demand nsec signing. How would that help? It would necessarily be a valid key for signing anything. >> This sounds no easier to deploy in practice than NSEC2 would be, even >> if it didn't have problems that appear to make it unworkable in any case. > > easier for whom? nsec2 has to be deployed everywhere and not just at the > nominet nameservers. Good point. Of course, for most people it is merely a matter of linking in a new version of the resolver library. 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 Jun 11 05:02:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08064 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 05:02:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYhuA-000JkF-UT for namedroppers-data@psg.com; Fri, 11 Jun 2004 09:00:54 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYhuA-000Jjq-1M for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 09:00:54 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 3EAC91FF845; Fri, 11 Jun 2004 09:00:53 +0000 (GMT) Message-ID: <40C974C4.1010302@algroup.co.uk> Date: Fri, 11 Jun 2004 10:00:52 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Stokes <don@plugh.daedalus.co.nz> Cc: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field References: <34433.1086910363@toybsd.zl2tnm.gen.nz> In-Reply-To: <34433.1086910363@toybsd.zl2tnm.gen.nz> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Don Stokes wrote: > What happens if you get: > > x.example. NSEC x.example. ... That proves that x.example. does exist and doesn't prove that anything doesn't exist. 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 Jun 11 05:05:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08169 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 05:05:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYhx1-000KAS-Te for namedroppers-data@psg.com; Fri, 11 Jun 2004 09:03:51 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYhx0-000KAA-TC for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 09:03:51 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 5BCD61FF846; Fri, 11 Jun 2004 09:03:49 +0000 (GMT) Message-ID: <40C97574.7000709@algroup.co.uk> Date: Fri, 11 Jun 2004 10:03:48 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> Cc: Roy Badami <roy@gnomon.org.uk>, namedroppers@ops.ietf.org Subject: Re: Online signing References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> <Pine.LNX.4.58.0406102148580.2889@elektron.atoom.net> <16585.664.987120.394778@giles.gnomon.org.uk> <Pine.LNX.4.58.0406111021380.2889@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406111021380.2889@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > I hope the assumptions one might have about a crypto-driven DDoS attack > is hereby tuned to a non-issue. I can't agree that having to deploy expensive crypto accelerators makes anything a non-issue. What I would agree is that it makes it a soluble issue. 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 Jun 11 05:23:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08662 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 05:23:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYiDG-000Ll8-Il for namedroppers-data@psg.com; Fri, 11 Jun 2004 09:20:38 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYiDF-000Lkp-EJ for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 09:20:37 +0000 Received: from [10.10.4.23] (nat-got.guide.se [195.100.50.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 3399119668; Fri, 11 Jun 2004 11:20:36 +0200 (CEST) In-Reply-To: <40C973A5.4020706@algroup.co.uk> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> Content-Transfer-Encoding: 7bit Cc: DNSEXT WG <namedroppers@ops.ietf.org> From: Jakob Schlyter <jakob@rfc.se> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Date: Fri, 11 Jun 2004 11:20:40 +0200 To: Ben Laurie <ben@algroup.co.uk> X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> a) Invitation to DoS us, suggesting we'd need to investigate crypto >>> offload devices. >> yes, crypto offload devices are needed. and if the crypto stuff >> performs close the normal query processing, DoS doesn't really count. >> if you add rate limiting and such to this, it's not be a problem. > > Rate limiting _is_ a problem since it causes lack of service. crypto performance outperforms query processing with a decent hardware accelerator. >>> c) Exposure of private keys. >> you would use a separate set of keys for on-demand nsec signing. > > How would that help? It would necessarily be a valid key for signing > anything. yes, but only the private key used for on-demand nsec have to be distributed to all authoritative nameservers. 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 Jun 11 05:59:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09482 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 05:59:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYimQ-000PQF-Bp for namedroppers-data@psg.com; Fri, 11 Jun 2004 09:56:58 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYimO-000PPt-Ib for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 09:56:57 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5B9ukFJ081045; Fri, 11 Jun 2004 11:56:48 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5B9ugXD006943; Fri, 11 Jun 2004 11:56:42 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5B9uf2H006940; Fri, 11 Jun 2004 11:56:42 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 11 Jun 2004 11:56:41 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: Roy Badami <roy@gnomon.org.uk>, namedroppers@ops.ietf.org Subject: Re: Online signing In-Reply-To: <40C97574.7000709@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406111109400.2889@elektron.atoom.net> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <40C88D07.3040700@algroup.co.uk> <Pine.OSX.4.60.0406102133430.14544@criollo.schlyter.se> <Pine.LNX.4.58.0406102148580.2889@elektron.atoom.net> <16585.664.987120.394778@giles.gnomon.org.uk> <Pine.LNX.4.58.0406111021380.2889@elektron.atoom.net> <40C97574.7000709@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Ben Laurie wrote: > Roy Arends wrote: > > I hope the assumptions one might have about a crypto-driven DDoS attack > > is hereby tuned to a non-issue. > > I can't agree that having to deploy expensive crypto accelerators makes > anything a non-issue. What I would agree is that it makes it a soluble > issue. Sun commercial grade crypto accelerator 1000 board, part number x6762a, currently costs around 2K euro (1339 GBP). A single board is capable around 4300 ops/sec for 1024-bit RSA. 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 Jun 11 06:17:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10526 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 06:17:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYj4K-0001jn-UA for namedroppers-data@psg.com; Fri, 11 Jun 2004 10:15:28 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYj4K-0001jZ-22 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 10:15:28 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5BAFPWa042436 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 10:15:26 GMT (envelope-from roy+dated+1089540922.641b5b@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5BAFNso014274 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 11:15:24 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5BAFN2U063901 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 11:15:23 +0100 (BST) (envelope-from roy+dated+1089540922.641b5b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5BAFNEA063900 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 11:15:23 +0100 (BST) (envelope-from roy+dated+1089540922.641b5b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Fri, 11 Jun 2004 11:15:21 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16585.34361.303467.126494@giles.gnomon.org.uk> Date: Fri, 11 Jun 2004 11:15:21 +0100 To: Ben Laurie <ben@algroup.co.uk> Cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: <40C974C4.1010302@algroup.co.uk> References: <34433.1086910363@toybsd.zl2tnm.gen.nz> <40C974C4.1010302@algroup.co.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Ben" == Ben Laurie <ben@algroup.co.uk> writes: >> What happens if you get: >> >> x.example. NSEC x.example. ... Ben> That proves that x.example. does exist and doesn't prove that Ben> anything doesn't exist. I thought it proves that nothing else in the zone exists. The canonical ordering is circular, so if the next RR is yourself, it means there are no other RRs... -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 Jun 11 06:22:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10693 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 06:22:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYj8l-0002GQ-Ua for namedroppers-data@psg.com; Fri, 11 Jun 2004 10:20:03 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYj8k-0002Fj-J8 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 10:20:02 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i5BAJvK15744; Fri, 11 Jun 2004 12:19:57 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5BAJvSj080058; Fri, 11 Jun 2004 12:19:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406111019.i5BAJvSj080058@givry.rennes.enst-bretagne.fr> From: Francis Dupont <Francis.Dupont@enst-bretagne.fr> To: Roy Arends <roy@dnss.ec> cc: Ben Laurie <ben@algroup.co.uk>, Roy Badami <roy@gnomon.org.uk>, namedroppers@ops.ietf.org Subject: Re: Online signing In-reply-to: Your message of Fri, 11 Jun 2004 11:56:41 +0200. <Pine.LNX.4.58.0406111109400.2889@elektron.atoom.net> Date: Fri, 11 Jun 2004 12:19:57 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: Sun commercial grade crypto accelerator 1000 board, part number x6762a, currently costs around 2K euro (1339 GBP). A single board is capable around 4300 ops/sec for 1024-bit RSA. => you can buy it for lower price at Broadcom or at some integrators: http://www.broadcom.com/products/product.php?product_id=CryptoNetX+SSL4000 http://www.interfacemasters.com/products/nic/niagara2100pc-5/index.html BTW I have two CryptoNetX IPS200A in DELL small servers so if someone has a benchmark proposal... Regards Francis.Dupont@enst-bretagne.fr PS: IMHO 64-bit CPUs are a more efficient way. The only very fine thing you can get only with crypto boards is not-ridiculous bandwith random number generators, i.e., no more hard choice between bad quality or very low bandwith (/dev/urandom or /dev/random). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 06:35:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11279 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 06:35:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYjLQ-0003OM-Us for namedroppers-data@psg.com; Fri, 11 Jun 2004 10:33:08 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYjLN-0003Nx-UU for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 10:33:06 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id D3A281FF845; Fri, 11 Jun 2004 10:33:04 +0000 (GMT) Message-ID: <40C98A60.7050304@algroup.co.uk> Date: Fri, 11 Jun 2004 11:33:04 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakob Schlyter <jakob@rfc.se> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> In-Reply-To: <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jakob Schlyter wrote: >>>> c) Exposure of private keys. >>> >>> you would use a separate set of keys for on-demand nsec signing. >> >> How would that help? It would necessarily be a valid key for signing >> anything. > > yes, but only the private key used for on-demand nsec have to be > distributed to all authoritative nameservers. Yes, but when it is compromised, the key can be used to spoof any record type. -- 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 Jun 11 06:36:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11321 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 06:36:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYjN9-0003Wq-0K for namedroppers-data@psg.com; Fri, 11 Jun 2004 10:34:55 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYjN5-0003WS-01 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 10:34:51 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 3A49B1FF845; Fri, 11 Jun 2004 10:34:50 +0000 (GMT) Message-ID: <40C98AC9.7080603@algroup.co.uk> Date: Fri, 11 Jun 2004 11:34:49 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Badami <roy@gnomon.org.uk> Cc: Don Stokes <don@plugh.daedalus.co.nz>, namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field References: <34433.1086910363@toybsd.zl2tnm.gen.nz> <40C974C4.1010302@algroup.co.uk> <16585.34361.303467.126494@giles.gnomon.org.uk> In-Reply-To: <16585.34361.303467.126494@giles.gnomon.org.uk> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Badami wrote: >>>>>>"Ben" == Ben Laurie <ben@algroup.co.uk> writes: > > > >> What happens if you get: > >> > >> x.example. NSEC x.example. ... > > Ben> That proves that x.example. does exist and doesn't prove that > Ben> anything doesn't exist. > > I thought it proves that nothing else in the zone exists. The > canonical ordering is circular, so if the next RR is yourself, it > means there are no other RRs... You may be right. -- 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 Jun 11 06:43:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11846 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 06:43:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYjTY-0004m2-Gk for namedroppers-data@psg.com; Fri, 11 Jun 2004 10:41:32 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYjTX-0004lZ-9Z for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 10:41:31 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id WAA28304 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 22:41:30 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i5BAfTfw066677 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 22:41:30 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: Your message of "Fri, 11 Jun 2004 11:15:21 +0100." <16585.34361.303467.126494@giles.gnomon.org.uk> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Fri, 11 Jun 2004 22:41:29 +1200 Message-ID: <66675.1086950489@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ben writes: > >> x.example. NSEC x.example. ...> > Ben> That proves that x.example. does exist and doesn't prove that > Ben> anything doesn't exist. Well, as Roy states: >I thought it proves that nothing else in the zone exists. The >canonical ordering is circular, so if the next RR is yourself, it >means there are no other RRs... but if there's nothing (else) there, the current drafts say there shouldn't be an NSEC record. NSEC records should show up only when there's something to talk about... I wasn't being very clear, and was conflating two separate issues. So I'll have another go. Assume that one wishes to generate static NSEC records for all names that do exist, but without a traversable NSEC chain. Assume too that we want to do authenticated denial on the fly for those that don't. Firstly, for the names that DO exist, what should I put in the Next Domain Name field of the NSEC record to say, "this is the NSEC record for the name you asked for, but this NSEC does not cover any other possible record"? Secondly, if I am to generate signed negative responses on the fly to cover names that DO NOT exist, what would those records look like? Can we fudge NSEC in some way to provide on-the-fly authenticated denial, (and allow for that capability within DNSSEC-bis), or do we need some kind of "signed NXDOMAIN" response in DNSSEC-ter? -- 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 Jun 11 06:43:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11895 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 06:43:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYjTq-0004nW-5k for namedroppers-data@psg.com; Fri, 11 Jun 2004 10:41:50 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYjTp-0004nH-4z for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 10:41:49 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5BAfhHh081356; Fri, 11 Jun 2004 12:41:44 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BAfdms007879; Fri, 11 Jun 2004 12:41:39 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BAfdIt007876; Fri, 11 Jun 2004 12:41:39 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 11 Jun 2004 12:41:39 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <40C973A5.4020706@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Ben Laurie wrote: > Jakob Schlyter wrote: > > > On Thu, 10 Jun 2004, Ben Laurie wrote: > > > > c) Exposure of private keys. > > > > you would use a separate set of keys for on-demand nsec signing. > > How would that help? It would necessarily be a valid key for signing > anything. I use transaction signatures between my authoritative nameservers. That implies I have online private or secret keys. Issues with online private or secret keys are highly overrated, should be kept in perspective and terms like 'Exposure of private keys.' are mere propaganda. You probably ment 'Exposure to private keys', but then, that is the service that is offered :-). Dynamic NSEC synthesis is currently the middle ground to satisfy both sides of the spectrum where one side wants to deploy DNSSEC-bis as-is, and the other side wants to deploy DNSSEC with defense against zone-traversal. This middle-ground would be temporal until an upgrade is available per Vixie's dnssec-ter proposal, where, again, both side of the spectrum are satisfied. I stick with the short and long term recommendation in the draft. I hope it reaches consensus, so we can move on. 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 Jun 11 06:56:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13534 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 06:56:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYjgf-0006Ju-At for namedroppers-data@psg.com; Fri, 11 Jun 2004 10:55:05 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYjge-0006Jf-Dw for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 10:55:04 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 7D4621FE67; Fri, 11 Jun 2004 11:55:03 +0100 (BST) Date: Fri, 11 Jun 2004 11:55:04 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Jakob Schlyter <jakob@rfc.se>, Ben Laurie <ben@algroup.co.uk> Cc: DNSEXT WG <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <116E49C95CA73E39BBB12EF9@[192.168.100.22]> In-Reply-To: <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 11 June 2004 11:20 +0200 Jakob Schlyter <jakob@rfc.se> wrote: >> Rate limiting _is_ a problem since it causes lack of service. > > crypto performance outperforms query processing with a decent hardware > accelerator. I am not disputing the point that this is a soluble issue but I am not sure your point above captures the full picture. Many large zones are now using anycast DNS (Nominet included). In this environment there could be far more actual secondary machines than there are secondaries listed in the zonefile (2 of Nominet's secondaries are provided by UltraDNS for example). Therefore EACH secondary machine needs to have crypto accelerator hardware which outpaces its ability to process queries (not each listed secondary nameserver). So whilst the issue is soluble, it's soluble at cost (both financial, and administrative - e.g. truckroll). This is afterall why one of the original goals of DNSSEC was to avoid the need for online realtime signing. 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 Jun 11 08:00:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15837 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 08:00:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYkdV-000BZl-D1 for namedroppers-data@psg.com; Fri, 11 Jun 2004 11:55:53 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYkdS-000BZD-9h for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 11:55:52 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5BBtf6O081906; Fri, 11 Jun 2004 13:55:42 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BBtbu6009024; Fri, 11 Jun 2004 13:55:37 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BBtZq2009021; Fri, 11 Jun 2004 13:55:37 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 11 Jun 2004 13:55:35 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Alex Bligh <alex@alex.org.uk> cc: Jakob Schlyter <jakob@rfc.se>, Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <116E49C95CA73E39BBB12EF9@[192.168.100.22]> Message-ID: <Pine.LNX.4.58.0406111307370.2889@elektron.atoom.net> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> <116E49C95CA73E39BBB12EF9@[192.168.100.22]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Alex Bligh wrote: > I am not disputing the point that this is a soluble issue but I am not sure > your point above captures the full picture. Many large zones are now using > anycast DNS (Nominet included). In this environment there could be far more > actual secondary machines than there are secondaries listed in the zonefile > (2 of Nominet's secondaries are provided by UltraDNS for example). > Therefore EACH secondary machine needs to have crypto accelerator hardware > which outpaces its ability to process queries (not each listed secondary > nameserver). So whilst the issue is soluble, it's soluble at cost (both > financial, and administrative - e.g. truckroll). This is afterall why one > of the original goals of DNSSEC was to avoid the need for online realtime > signing. The cost of crypto-accelerator cards are a tiny fraction of the overall DNSSEC deployment, support, production and management cost. The investment in crypto-hardware is simply a three-year write-off, just like the hardware its installed on. Nominet charges 5 GBP per registration per year . With over 5M registrations, that would be an annual turnaround of 25M GBP excluding membership fees and non-membership registration fees. A raise of .001 GBP on the 5 GBP registration covers 10 crypto-cards of 1500 GBP thank you very much. 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 Jun 11 08:00:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15873 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 08:00:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYkeb-000BhT-HD for namedroppers-data@psg.com; Fri, 11 Jun 2004 11:57:01 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYkea-000BhB-IG for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 11:57:00 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5BBuukZ002632 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 07:56:56 -0400 Received: from lapdancer (asynce002.nist.gov [129.6.31.2]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i5BBuo4A003893 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 07:56:51 -0400 (EDT) Message-ID: <000001c44fab$561316b0$021f0681@lapdancer> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <34433.1086910363@toybsd.zl2tnm.gen.nz> Subject: Re: NSEC synthesis and the NSEC Next Domain Name field Date: Thu, 10 Jun 2004 21:21:37 -0400 Organization: NIST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would suggest the next domain name be the apex - indicating it is the last canonical name in the zone. Yes, it isn't true, but caches should be fabricating non-existance responses for non-authoritative data anyway. Scott ----- Original Message ----- From: "Don Stokes" <don@plugh.daedalus.co.nz> To: <namedroppers@ops.ietf.org> Sent: Thursday, June 10, 2004 7:32 PM Subject: NSEC synthesis and the NSEC Next Domain Name field > > Folks, > > If one is to synthesise NSEC records, either online, or staticly in > "NSEC white lies" the recent draft put it, what should one place in the > Next Domain Name field of the NSEC record? > > As things stand, it appears that given a name "x.example.", then the > very next name that could be created in given the canonical ordering > rules would be "\001.x.example.". > > However, that doesn't sit nicely (although this might not be a problem) > when x.example is a delegation; one doesn't really want "fake" NSEC > records pointing at subdomains that don't exist, e.g. > > x.example. NS ns1.example.com. > NS ns2.example.com. > NSEC \001.x.example. NS RRSIG NSEC > > as \001.x.example is out of bailiwick. The "next" name at the same > level as x.example would be "x\001.example.". > > What happens if you get: > > x.example. NSEC x.example. ... > > Could replaying that NSEC record be used to (e.g.) forge a denial of > y.example.? > > What I'm looking for is a standard, canonical way of saying, "this name, > and only this name, does not exist", preferably without reference to > other data. > > Is this a special case for the NSEC Next Domain Name field, or can it > reliably be fudged? Could the field be given a value that meant "there > is no next domain name field; this NSEC only refers to the name > queried"? > > -- 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 08:25:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17831 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 08:25:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYl41-000Elg-Os for namedroppers-data@psg.com; Fri, 11 Jun 2004 12:23:17 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYl3z-000ElP-3Y for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 12:23:15 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 31D3EE7EE8; Fri, 11 Jun 2004 13:23:14 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <Pine.LNX.4.58.0406111307370.2889@elektron.atoom.net> Message-Id: <20040611122314.31D3EE7EE8@mx1.nominet.org.uk> Date: Fri, 11 Jun 2004 13:23:14 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk From: Roy Arends <roy@dnss.ec> writes: > The cost of crypto-accelerator cards are a tiny fraction of the overall > DNSSEC deployment, support, production and management cost. Even with fast crypto hardware, isn't there still a problem of significant asymmetry? Normal operational loads could be easily accommodated, but a malicious party should have no problem generating sufficient levels of queries for non-existant domain names with the DO bit set to overwhelm any practicable level of signing capacity. 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 Jun 11 08:27:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18074 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 08:27:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYl6S-000F2R-Li for namedroppers-data@psg.com; Fri, 11 Jun 2004 12:25:48 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYl6R-000F22-IK for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 12:25:47 +0000 Received: from [192.168.100.20] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B2EDF1FE67; Fri, 11 Jun 2004 13:25:46 +0100 (BST) Date: Fri, 11 Jun 2004 13:25:47 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Roy Arends <roy@dnss.ec> Cc: Jakob Schlyter <jakob@rfc.se>, Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <4CDEA9673049B147C1795422@[192.168.100.22]> In-Reply-To: <Pine.LNX.4.58.0406111307370.2889@elektron.atoom.net> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> <116E49C95CA73E39BBB12EF9@[192.168.100.22]> <Pine.LNX.4.58.0406111307370.2889@elektron.atoom.net> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy, --On 11 June 2004 13:55 +0200 Roy Arends <roy@dnss.ec> wrote: > The cost of crypto-accelerator cards are a tiny fraction of the overall > DNSSEC deployment, support, production and management cost. I think you are disagreeing with something that I am not saying. I expressly did not say the problem was insoluble. My concern was not that it couldn't be done, but that the disadvantages should be fully documented in the draft, and we should look at how to minimize the problems of synthesis where there are a large number of physical secondaries not all under the same administrative control (hence I suggested forwarding). I am quite aware that the deployment, support, production and management costs are likely to vastly exceed the hardware cost of crypto cards, and am thus surprised that you compare costs against them below. > Nominet charges 5 GBP per registration per year. With over 5M > registrations Actually 5 pounds per 2 years, closer to 4m paying registrations, and rather more than 10 secondary servers if you include uDNS, but in any case that's hardly the point. My concern is (to relate this back to draft-ietf-dnsext-dnssec-trans-00.txt) as follows: The current -trans proposals suggest that the interim deployment solution for DNSSEC that avoids enumeration requires online signing at each machine acting as a secondary. This entails: a) server software that is capable of doing it (and, in a situation where diverse software is used on secondaries) several sets of such software, possibly including development cost. b) hardware acceleration do be provided on each machine such that its signing rate exceeds the query rate c) what you characterize as "deployment, support, production and management cost". None of the above is "not doable". However, I don't feel they are fully documented in the current draft, nor do I feel the option of "doing nothing (don't deploy)" is included. That would allow us to spend all the effort, time (including development time) and money we'd spend on (a) to (c), on developing and deploying -ter. Or to put it another way, if -ter was approved ten days after -bis, there would be no point deploying lots of crypto cards and writing software to do synthesis, right? If it was ten years after, that would change things rather. 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 Jun 11 08:32:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18600 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 08:32:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYlB9-000FZ0-6c for namedroppers-data@psg.com; Fri, 11 Jun 2004 12:30:39 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYlB5-000FYD-Tu for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 12:30:36 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 6254A1FF845; Fri, 11 Jun 2004 12:01:19 +0000 (GMT) Message-ID: <40C99F0E.2050602@algroup.co.uk> Date: Fri, 11 Jun 2004 13:01:18 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> Cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Fri, 11 Jun 2004, Ben Laurie wrote: > > >>Jakob Schlyter wrote: >> >> >>>On Thu, 10 Jun 2004, Ben Laurie wrote: >> >>>>c) Exposure of private keys. >>> >>>you would use a separate set of keys for on-demand nsec signing. >> >>How would that help? It would necessarily be a valid key for signing >>anything. > > > I use transaction signatures between my authoritative nameservers. That > implies I have online private or secret keys. > > Issues with online private or secret keys are highly overrated, should be > kept in perspective and terms like 'Exposure of private keys.' are mere > propaganda. > > You probably ment 'Exposure to private keys', but then, that is the > service that is offered :-). > > Dynamic NSEC synthesis is currently the middle ground to satisfy both > sides of the spectrum where one side wants to deploy DNSSEC-bis as-is, and > the other side wants to deploy DNSSEC with defense against zone-traversal. > > This middle-ground would be temporal until an upgrade is available per > Vixie's dnssec-ter proposal, where, again, both side of the spectrum are > satisfied. > > I stick with the short and long term recommendation in the draft. I hope > it reaches consensus, so we can move on. Consensus on that point would presumably require some people willing to implement it - are there any? 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 Jun 11 09:03:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21315 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 09:03:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYlda-000IW9-Sp for namedroppers-data@psg.com; Fri, 11 Jun 2004 13:00:02 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYldY-000IUT-Fo for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 13:00:01 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5BCxoRl082309; Fri, 11 Jun 2004 14:59:51 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BCxjJD010194; Fri, 11 Jun 2004 14:59:45 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BCxhpU010191; Fri, 11 Jun 2004 14:59:44 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 11 Jun 2004 14:59:43 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Alex Bligh <alex@alex.org.uk> cc: Jakob Schlyter <jakob@rfc.se>, Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <4CDEA9673049B147C1795422@[192.168.100.22]> Message-ID: <Pine.LNX.4.58.0406111430430.2889@elektron.atoom.net> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> <116E49C95CA73E39BBB12EF9@[192.168.100.22]> <Pine.LNX.4.58.0406111307370.2889@elektron.atoom.net> <4CDEA9673049B147C1795422@[192.168.100.22]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Alex Bligh wrote: > --On 11 June 2004 13:55 +0200 Roy Arends <roy@dnss.ec> wrote: > > > The cost of crypto-accelerator cards are a tiny fraction of the overall > > DNSSEC deployment, support, production and management cost. > > I think you are disagreeing with something that I am not saying. I > expressly did not say the problem was insoluble. My concern was not that it > couldn't be done, but that the disadvantages should be fully documented in > the draft, and we should look at how to minimize the problems of synthesis > where there are a large number of physical secondaries not all under the > same administrative control (hence I suggested forwarding). I am quite > aware that the deployment, support, production and management costs are > likely to vastly exceed the hardware cost of crypto cards, and am thus > surprised that you compare costs against them below. Alex, I responded specifically to: "Many large zones are now using anycast DNS (Nominet included). In this environment there could be far more actual secondary machines than there are secondaries listed in the zonefile (2 of Nominet's secondaries are provided by UltraDNS for example). Therefore EACH secondary machine needs to have crypto accelerator hardware which outpaces its ability to process queries (not each listed secondary nameserver). So whilst the issue is soluble, it's soluble at cost (both financial, and administrative - e.g. truckroll)." The emphasis on EACH, the hint that multiple secondaries were hiding behind anycasted addresses made me think you're looking for a cost-multiplier to argue against crypto accelerator hardware. There was no hint of text in your mail that dis-advantages should be fully documented in the draft. The problem is that stupidity is infinite, therefor covering every Bad Idea including every advantage and disadvantage would be as infinite in terms of work. Since I volunteered to write, I try to put a ceiling on 'infinite'. > > Nominet charges 5 GBP per registration per year. With over 5M > > registrations > > Actually 5 pounds per 2 years, Okay. > closer to 4m paying registrations, and Oh, I got my information from: http://www.nominet.org.uk/Statistics/RegistrationStatistics/ Good to see that about 20 percent of the co.uk registrations are given away for free. Other SLD/TLDs should follow Nominets example. > rather more than 10 secondary servers if you include uDNS, but in any case > that's hardly the point. Let uDNS pay for their own shop, or get secondaries who do want to invest. > My concern is (to relate this back to draft-ietf-dnsext-dnssec-trans-00.txt) > as follows: > > The current -trans proposals suggest that the interim deployment solution > for DNSSEC that avoids enumeration requires online signing at each > machine acting as a secondary. This entails: > a) server software that is capable of doing it (and, in a situation > where diverse software is used on secondaries) several sets of > such software, possibly including development cost. > > b) hardware acceleration do be provided on each machine such that its > signing rate exceeds the query rate > > c) what you characterize as "deployment, support, production and > management cost". > > None of the above is "not doable". However, I don't feel they are > fully documented in the current draft, Current draft is informational. You don't need ANY wg-consensus to do (a)(b) and (c). You need software to do this, but it doesn't require inter-operable DNS standards. If you would like to have a set of documents that entails all the ins-outs of the synthesis hack, that can also be done without WG consensus. > nor do I feel the option of > "doing nothing (don't deploy)" is included. Okay, will include that option in the draft. Send text please. > That would allow us to spend all the effort, time (including development > time) and money we'd spend on (a) to (c), on developing and deploying > -ter. You _really_ don't need wg-consensus, permission or a letter of intent from any Standards body to do this. Honest. > Or to put it another way, if -ter was approved ten days after -bis, > there would be no point deploying lots of crypto cards and writing > software to do synthesis, right? If it was ten years after, that > would change things rather. Yes. If you want to wait for -ter, that would be the good thing. That is what we recommend in the draft ! If you can't wait that long, we recommend the synthesis hack. If you can wait that long you have the option to "doing nothing (don't deploy)" 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 Jun 11 09:12:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22679 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 09:12:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYlma-000Jeo-RV for namedroppers-data@psg.com; Fri, 11 Jun 2004 13:09:20 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYlmZ-000JeX-L4 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 13:09:20 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5BD9FET082411; Fri, 11 Jun 2004 15:09:15 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BD9Aa6010454; Fri, 11 Jun 2004 15:09:10 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BD9Aq6010451; Fri, 11 Jun 2004 15:09:10 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 11 Jun 2004 15:09:10 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <40C99F0E.2050602@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Ben Laurie wrote: > Consensus on that point would presumably require some people willing to > implement it - are there any? To implement what ? To implement the short-term solution which doesn't need ANY ietf-wg action, consensus and so forth, you'd simply buy your feature from ISC or NLnet Labs. To implement the long-term solution which does need ietf-wg action, consensus and so forth, you'd simply fund development of (pick your list from http://www.rfc.se/fpdns/ ) combined with other TLDs or interested partners who care for dnssec-ter. 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 Jun 11 09:26:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24626 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 09:26:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYm0l-000Kze-Q8 for namedroppers-data@psg.com; Fri, 11 Jun 2004 13:23:59 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYm0k-000KzR-Pj for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 13:23:59 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5BDNs8P082515; Fri, 11 Jun 2004 15:23:54 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BDNoCK010714; Fri, 11 Jun 2004 15:23:50 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BDNnwt010711; Fri, 11 Jun 2004 15:23:49 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 11 Jun 2004 15:23:49 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Geoffrey Sisson <geoff@nominet.org.uk> cc: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <20040611122314.31D3EE7EE8@mx1.nominet.org.uk> Message-ID: <Pine.LNX.4.58.0406111509560.2889@elektron.atoom.net> References: <20040611122314.31D3EE7EE8@mx1.nominet.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Geoffrey Sisson wrote: > From: Roy Arends <roy@dnss.ec> writes: > > > The cost of crypto-accelerator cards are a tiny fraction of the overall > > DNSSEC deployment, support, production and management cost. > > Even with fast crypto hardware, isn't there still a problem of > significant asymmetry? Normal operational loads could be easily > accommodated, but a malicious party should have no problem generating > sufficient levels of queries for non-existant domain names with the DO > bit set to overwhelm any practicable level of signing capacity. There are first other ceilings (like bandwith, server performance) to overcome if one suspects a possible crypto DDoS. This implies that a simple non-crypto DDoS is just as easy to deploy, and the asynchronous cost argument (for this particular use) disappears. 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 Jun 11 10:10:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01130 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 10:10:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYmgc-000PBG-Vf for namedroppers-data@psg.com; Fri, 11 Jun 2004 14:07:14 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYmga-000PAq-Sq for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 14:07:13 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BYmgZ-0008Es-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 16:07:11 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 16:07:11 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 16:07:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Fri, 11 Jun 2004 16:07:08 +0200 Lines: 46 Message-ID: <ilubrjqrxwz.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:P9WoKT12GHPZgGVcoIIZNraOu2M= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis <edlewis@arin.net> writes: > At 17:56 +0200 6/10/04, Simon Josefsson wrote: >>Edward Lewis <edlewis@arin.net> writes: >> >>> At 16:39 +0200 6/10/04, Simon Josefsson wrote: >>>>What do you think? >>> >>> This is more or less what silly state began to try to do. Define >>> looking at the bits that shouldn't matter to see if a "panic because >>> it's the future and I don't know what to do" mode is to be entered. >> >>A "panic button" already exists in DNSKEY -- if DNSSECter specify use >>of a protocol field != 3, old resolvers will reject those DNSKEYs, for >>RRSIG validation purposes. Using the Flags Field appeared to me like >>a cleaner solution, considering the original use of the protocol >>field. With my text this option would be available. > > What your text is doing is bringing the flags definition in line with > the protocol field - telling the verifier to ignore keys that don't > fit the narrowly defined contents they are allowed to have. It's good > to see the specifications have commonality across the sections. The current text says this. My proposed text split the flag bits into two parts, one part which can be ignored if unsupported, and one part which cause the entire DNSKEY to be rejected for RRSIG validation purposes. The latter is similar to sending a protocol != 3 value. > The problem is that this is not sufficient to provide a base for a > migration strategy. What's missing are instructions on what to do if > all keys present fail the tests? Should the verifier log this > instance as a note to the administrator that perhaps the verifier code > has fallen behind in version and needs to be replaced? Should the > verifier just assume that there is no available DNSSEC verification > data for the zone and thus treat it as unsigned? > > What does a resolver do when it tries to load a trusted key that has a > protocol field != 3 or flag bits not 0 in the right places? I was not trying to provide a migration strategy, just to make it possible to develop one -- one that would be cleaner than using the protocol field, which is possible with the unmodified current document. 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 Jun 11 10:31:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04444 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 10:31:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYmzB-0000uL-3d for namedroppers-data@psg.com; Fri, 11 Jun 2004 14:26:25 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYmz9-0000u5-Nh for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 14:26:24 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 52CCF1FF845; Fri, 11 Jun 2004 14:26:22 +0000 (GMT) Message-ID: <40C9C10D.8080804@algroup.co.uk> Date: Fri, 11 Jun 2004 15:26:21 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> Cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Fri, 11 Jun 2004, Ben Laurie wrote: > > >>Consensus on that point would presumably require some people willing to >>implement it - are there any? > > To implement what ? > > To implement the short-term solution which doesn't need ANY ietf-wg > action, consensus and so forth, you'd simply buy your feature from ISC or > NLnet Labs. And decide that you don't care that you are spreading your private key all over the place, and find or build a crypto accelerator that does what you need. > To implement the long-term solution which does need ietf-wg action, > consensus and so forth, you'd simply fund development of (pick your list > from http://www.rfc.se/fpdns/ ) combined with other TLDs or interested > partners who care for dnssec-ter. I am already working on an experimental implementation of NSEC2 in BIND. 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 Jun 11 10:36:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04724 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 10:36:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYn6p-0001kD-NP for namedroppers-data@psg.com; Fri, 11 Jun 2004 14:34:19 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYn6o-0001ju-Cb for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 14:34:18 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 751CB1FF845; Fri, 11 Jun 2004 14:34:17 +0000 (GMT) Message-ID: <40C9C2E9.9000007@algroup.co.uk> Date: Fri, 11 Jun 2004 15:34:17 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> Cc: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field References: <34433.1086910363@toybsd.zl2tnm.gen.nz> <000001c44fab$561316b0$021f0681@lapdancer> In-Reply-To: <000001c44fab$561316b0$021f0681@lapdancer> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > I would suggest the next domain name be the apex - indicating it is the last > canonical name in the zone. > > Yes, it isn't true, but caches should be fabricating non-existance responses > for non-authoritative data anyway. "shouldn't", surely? I was also coming to the conclusion that a pair of records of the form: x.example. NSEC example. example. NSEC x.example. could be used to deny anything (except example. or x.example.), without causing other problems - apart, of course, from giving an attacker a method of denying any name's existence. Or would just: example. NSEC example. suffice? Cheers, Ben. > > Scott > > > ----- Original Message ----- > From: "Don Stokes" <don@plugh.daedalus.co.nz> > To: <namedroppers@ops.ietf.org> > Sent: Thursday, June 10, 2004 7:32 PM > Subject: NSEC synthesis and the NSEC Next Domain Name field > > > >>Folks, >> >>If one is to synthesise NSEC records, either online, or staticly in >>"NSEC white lies" the recent draft put it, what should one place in the >>Next Domain Name field of the NSEC record? >> >>As things stand, it appears that given a name "x.example.", then the >>very next name that could be created in given the canonical ordering >>rules would be "\001.x.example.". >> >>However, that doesn't sit nicely (although this might not be a problem) >>when x.example is a delegation; one doesn't really want "fake" NSEC >>records pointing at subdomains that don't exist, e.g. >> >>x.example. NS ns1.example.com. >>NS ns2.example.com. >>NSEC \001.x.example. NS RRSIG NSEC >> >>as \001.x.example is out of bailiwick. The "next" name at the same >>level as x.example would be "x\001.example.". >> >>What happens if you get: >> >>x.example. NSEC x.example. ... >> >>Could replaying that NSEC record be used to (e.g.) forge a denial of >>y.example.? >> >>What I'm looking for is a standard, canonical way of saying, "this name, >>and only this name, does not exist", preferably without reference to >>other data. >> >>Is this a special case for the NSEC Next Domain Name field, or can it >>reliably be fudged? Could the field be given a value that meant "there >>is no next domain name field; this NSEC only refers to the name >>queried"? >> >>-- 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/> >> > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- 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 Jun 11 10:37:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04796 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 10:37:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYn7X-0001rg-Dp for namedroppers-data@psg.com; Fri, 11 Jun 2004 14:35:03 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYn7W-0001qN-1d for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 14:35:02 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i5BEYw4S028485; Fri, 11 Jun 2004 10:34:58 -0400 To: "Scott Rose" <scottr@nist.gov> Cc: <namedroppers@ops.ietf.org> Subject: Re: NSEC synthesis and the NSEC Next Domain Name field References: <34433.1086910363@toybsd.zl2tnm.gen.nz> <000001c44fab$561316b0$021f0681@lapdancer> From: Derek Atkins <derek@ihtfp.com> Date: Fri, 11 Jun 2004 10:34:58 -0400 In-Reply-To: <000001c44fab$561316b0$021f0681@lapdancer> (Scott Rose's message of "Thu, 10 Jun 2004 21:21:37 -0400") Message-ID: <sjm4qpi40z1.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" <scottr@nist.gov> writes: > I would suggest the next domain name be the apex - indicating it is the last > canonical name in the zone. > > Yes, it isn't true, but caches should be fabricating non-existance responses > for non-authoritative data anyway. That unfortunately enables replay attacks if a "bad cache" gets in your path or an attacker can guess your query txn id. > Scott -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 Jun 11 10:50:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07466 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 10:50:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYnKG-0003V7-2D for namedroppers-data@psg.com; Fri, 11 Jun 2004 14:48:12 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYnKE-0003Us-MN for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 14:48:11 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BYnKD-0000VC-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 16:48:09 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 16:48:09 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 16:48:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Fri, 11 Jun 2004 16:48:05 +0200 Lines: 51 Message-ID: <ilu7juerw0q.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Xsj7rFDM9E7rko7umuxw7T2LHlU= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> writes: > On Thu, 10 Jun 2004 12:28:22 -0400 > Edward Lewis <edlewis@arin.net> wrote: >> >> I think the problem (and I'm off on a tangent now) is that you have >> to make the verifier be able to realize at the DS RR set that the >> child will have no acceptable keys for me - at the point where I can >> verify the "end of understandable security" while still being secure >> enough to trust it. >> > > > One of the things you have to take into account is the signature strip > attack (there was a long thread on that under one of the questions, > Weiler started that one if I recall well.). > > You have to decide, as soon as you receive the DNSKEY RRset, which > keys the data MUST be signed with in order to not be bogus. > > So you have to ordonate something like "If any of the secure entry poin > into the zone (either the DS RRs or trust anchors) points to DNSKEY > RRs in the apex with all zero values in bits 8-14 than any RRset in > the zone MUST have at least one RRSIG generated by an all-zero keys, > RRsets not signed by an RRSIG generated by an all-zero key are to be > treated as bogus." > > In addition you have to say that if you find non-zero bit keys you treat > the zone as insecure. > > "If none the secure entry point into the zone point to DNSKEY RRs in > the apex with non-zero values in bits 8-14 than the zone may be treated as > insecure." I believe none if those discussions are required, or even useful. By the same argument, do you also believe that the document describe what should happen when the protocol field is not 3? Essentially, I don't see the difference between when a DNSKEY is invalid because the protocol field is not 3, and when (with my proposed text) bits 8-14 are non-zero. If the WG prefer having only the Protocol Field available for use in future revisions, then fine. My suggestion was based on the thought that it would be cleaner to have the Bit Field available for this purpose too. If the intention is not to use the Protocol Field for future revision, then the field serve no purpose and I believe it should be removed. 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 Jun 11 11:45:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12172 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 11:45:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYoAk-000BTE-Vq for namedroppers-data@psg.com; Fri, 11 Jun 2004 15:42:26 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYoAj-000BSq-CJ for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 15:42:25 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id BDCA019B709; Fri, 11 Jun 2004 11:42:15 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 1053E19B6FE; Fri, 11 Jun 2004 11:42:15 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1759902; Fri, 11 Jun 2004 11:42:23 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020404bcef7c93b348@[192.136.136.83]> In-Reply-To: <20040611095744.39b826ab.olaf@ripe.net> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> Date: Fri, 11 Jun 2004 11:42:32 -0400 To: "Olaf M. Kolkman" <olaf@ripe.net> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: Edward Lewis <edlewis@arin.net>, jas@extundo.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:57 +0200 6/11/04, Olaf M. Kolkman wrote: >On Thu, 10 Jun 2004 12:28:22 -0400 >Edward Lewis <edlewis@arin.net> wrote: >> >> I think the problem (and I'm off on a tangent now) is that you have >> to make the verifier be able to realize at the DS RR set that the >> child will have no acceptable keys for me - at the point where I can >> verify the "end of understandable security" while still being secure >> enough to trust it. >> >One of the things you have to take into account is the signature strip >attack (there was a long thread on that under one of the questions, >Weiler started that one if I recall well.). I think that's a different issue from my point, but is related. Validation of the data begins with 1) the data and 2) an expectation of what is to be present to come to believe the data. Let's begin with the topic of on-line signing of dynamically generated data denial responses (authenticated denial). If there's to be on-line signing, then there's an on-line key. Such a key is more vulnerable than off-line keys. So, if we want to continue to rely on off-line signing for safety, we need to set expectations about what key is used where. If we decide to propose on-line signing of negative answers, then we will have to specify that: - If the zone subscribes to this notion - The key signing a positive answer (with data) has to be a key that is indicated to be off-line - The key signing the key set has to be indicated as off-line - The key signing the negative answer may be indicated as on-line If you don't provide the above, then the protocol is vulnerable to an exposure of the private key that leads to someone signing a long-RRSIG-validation and high TTL version of an illicit key set and thus being able to send data around signed by one of the illicit keys. This relates to signature stripping because the verifier needs to determine if it has sufficient data to prove the answer. What the verifier needs to be able to get is a RRSIG for an answer that shows the right kind of key was used. The right kind of key could be "any key if the zone does not have any key on-line or an off-line key if the zone has keys on-line." The verifier needs to be able to see that in the data it gets - that's the expectation. If an RRSIG is stripped that would demonstrate that, then the verifier is correct to be suspicious and take corrective action. >You have to decide, as soon as you receive the DNSKEY RRset, which >keys the data MUST be signed with in order to not be bogus. > >So you have to ordonate something like "If any of the secure entry poin I have to admit that "ordonate" is not in my version of the English dictionary. ;) And I can't find a verb that is close to the spelling you have. (I.e., huh?) >into the zone (either the DS RRs or trust anchors) points to DNSKEY >RRs in the apex with all zero values in bits 8-14 than any RRset in >the zone MUST have at least one RRSIG generated by an all-zero keys, >RRsets not signed by an RRSIG generated by an all-zero key are to be >treated as bogus." > >In addition you have to say that if you find non-zero bit keys you treat >the zone as insecure. > >"If none the secure entry point into the zone point to DNSKEY RRs in >the apex with non-zero values in bits 8-14 than the zone may be treated as >insecure." I don't think that's the right "rule." Let's say that my verifier is able to understand the security of the zone example.com. I.e., I understand the semantics of all the set bits in the zone's DNSKEY's, RRSIG's, NSEC's. Asking for "www.newzone.example.com." A (assuming it's in a sub-delegation), I will see this in the response: Answer Authority newzone.example.com. NS ns1.newzone.example.com. newzone.example.com. NS ns2.newzone.example.com. newzone.example.com. DS <key 1> newzone.example.com. DS <key 2> newzone.example.com. RRSIG(DS) Additional I can validate the RRSIG above, proving that there's a DS key. When I issue the same answer to ns1.newzone.example.com., I get: Answer www.newzone.example.com A 222.333.444.555 www.newzone.example.com RRSIG(A) Authority Additional newzone.example.com. DNSKEY <key 1> newzone.example.com. DNSKEY <key 2> newzone.example.com. RRSIG(DNSKEY) What' happens when I find that key's 1 and 2 have bits set that I can't understand? Should I be content that these keys match the DS hashes, now concluding that there are no acceptable keys and therefore I can reasonable continue on assuming there is no security to be had? (Maybe so, maybe not.) If this is the case, should the resolver know to alert it's operator that this happened - i.e., that may it's time for a verifier upgrade? I think so because this is significantly different from this referral message (which also results in the ending of an expectation of security): Answer Authority newzone.example.com. NS ns1.newzone.example.com. newzone.example.com. NS ns2.newzone.example.com. newzone.example.com. NSEC saying no DS newzone.example.com. RRSIG(NSEC) Additional Then there's a mixed case - when some keys are acceptable, some not. The zone ought not be treated as unsigned unless the verifier has no way to expect otherwise. ... >Playing with bits at this stage is stepping on corner-case ground. Yep. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Jun 11 12:54:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16981 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 12:54:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYpEq-000LiE-Rn for namedroppers-data@psg.com; Fri, 11 Jun 2004 16:50:44 +0000 Received: from [216.140.57.247] (helo=ausspam01.ixc-comm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYpEp-000Lhp-T2 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 16:50:43 +0000 Received: from mail pickup service by ausspam01.ixc-comm.com with Microsoft SMTPSVC; Fri, 11 Jun 2004 11:45:44 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by ausspam01.ixc-comm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 Jun 2004 07:31:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkTI-0000pk-SD; Fri, 11 Jun 2004 07:45:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYVc1-0007iV-Kh for i-d-announce@megatron.ietf.org; Thu, 10 Jun 2004 15:53:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27673; Thu, 10 Jun 2004 15:53:04 -0400 (EDT) Message-Id: <200406101953.PAA27673@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 10 Jun 2004 15:53:04 -0400 Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-trans-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=unsubscribe> List-Post: <mailto:i-d-announce@ietf.org> List-Help: <mailto:i-d-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=subscribe> X-OriginalArrivalTime: 11 Jun 2004 12:31:57.0671 (UTC) FILETIME=[1617BF70:01C44FB0] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Evaluating DNSSEC Transition Mechanisms Author(s) : R. Arends, et al. Filename : draft-ietf-dnsext-dnssec-trans-00.txt Pages : 14 Date : 2004-6-10 This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-trans-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-10161714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-trans-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-10161714.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 13:32:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20069 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 13:32:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYppI-00019T-Kr for namedroppers-data@psg.com; Fri, 11 Jun 2004 17:28:24 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYppH-000197-Nc for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 17:28:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id F141413DE5 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 17:28:22 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: Online signing In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Fri, 11 Jun 2004 10:03:48 +0100." <40C97574.7000709@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Jun 2004 17:28:22 +0000 Message-Id: <20040611172822.F141413DE5@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I hope the assumptions one might have about a crypto-driven DDoS attack > > is hereby tuned to a non-issue. > > I can't agree that having to deploy expensive crypto accelerators makes > anything a non-issue. then you're having a different conversation than the rest of us. > What I would agree is that it makes it a soluble issue. anything that can be solved outofband is a nonissue for dnssec-bis @IESG. the conversation at hand is, can we send dnssec-bis to the IESG. you appear to be saying "yes", both in the above "makes it soluble" comment and in your agreement with my dnssec-ter-01 draft. any issue like "the crypto boards will cost too much" isn't relevant. any issue like "online NSEC synthesis will expose the signing key to attacks because the attacker can force the victim to do unsalted crypto" is relevant. i realize that these issues are equally near and dear to you. but they are very different from the point of view of our chairs, who only want to know if they can forward the dnssec-bis docset to the IESG. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 13:35:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20259 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 13:35:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYptZ-0001oZ-Te for namedroppers-data@psg.com; Fri, 11 Jun 2004 17:32:49 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYptZ-0001oB-50 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 17:32:49 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E268F13951 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 17:32:48 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Fri, 11 Jun 2004 13:01:18 +0100." <40C99F0E.2050602@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Jun 2004 17:32:48 +0000 Message-Id: <20040611173248.E268F13951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... Dynamic NSEC synthesis is currently the middle ground to > > satisfy both sides of the spectrum where one side wants to deploy > > DNSSEC-bis as-is, and the other side wants to deploy DNSSEC with > > defense against zone-traversal. This middle-ground would be > > temporal until an upgrade is available per Vixie's dnssec-ter > > proposal, where, again, both side of the spectrum are satisfied. I > > stick with the short and long term recommendation in the draft. I > > hope it reaches consensus, so we can move on. > > Consensus on that point would presumably require some people willing > to implement it - are there any? i don't expect isc's existing funding sources to think that this is an important topic for us to spend effort on in the short term. (the bind forum seems to be more interested in performance and documentation and usability than on advanced dnssec features, but that could change.) however, new funding would bring its own rules. so, theoretically at least, there are some people willing to implement/prototype dnssec-ter, subject only to resource availability. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 13:45:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20565 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 13:45:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYq2i-0002zR-AV for namedroppers-data@psg.com; Fri, 11 Jun 2004 17:42:16 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYq2f-0002z4-Ia for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 17:42:13 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 51BFD13951 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 17:42:13 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Fri, 11 Jun 2004 15:34:17 +0100." <40C9C2E9.9000007@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Jun 2004 17:42:13 +0000 Message-Id: <20040611174213.51BFD13951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I would suggest the next domain name be the apex - indicating it is > > the last canonical name in the zone. Yes, it isn't true, but caches > > should be fabricating non-existance responses for non-authoritative > > data anyway. there's a replay attack possible if the range of domain names between the owner and target of an NSEC is not actually known to be empty. > Or would just: > > example. NSEC example. > > suffice? this is my preference, but i admit i don't know whether the current -bis spec requires that either an NSEC owner or target name, or both, actually does exist. certainly the expectation is that the owner name exists, which is why there's a list of RRtypes in the NSEC rdata. but as to whether the validation model actually requires such existence, i don't know. would an NSEC asserting that no RRtypes were present at its owner name be valid? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 13:48:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20648 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 13:48:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYq5s-0003R8-Ip for namedroppers-data@psg.com; Fri, 11 Jun 2004 17:45:32 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYq5r-0003QR-Jy for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 17:45:31 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id AD5FD1FDCB; Fri, 11 Jun 2004 18:45:30 +0100 (BST) Date: Fri, 11 Jun 2004 18:45:29 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: Online signing Message-ID: <73E03300A1CCA6D568D24F69@[192.168.100.5]> In-Reply-To: <20040611172822.F141413DE5@sa.vix.com> References: <20040611172822.F141413DE5@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 11 June 2004 17:28 +0000 Paul Vixie <paul@vix.com> wrote: > who only want to know > if they can forward the dnssec-bis docset to the IESG. did they not ask for comments on -trans? I am assuming here that it is relevant point to make, that although the consensus on the WG is not to fix NSEC in -bis, this will likely cause certain operators not to deploy until -ter; isn't that what transition is all about? 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 Jun 11 13:59:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21655 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 13:59:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYqE5-0005C5-7n for namedroppers-data@psg.com; Fri, 11 Jun 2004 17:54:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYqE2-0005BW-CG for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 17:54:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 272BC13DED for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 17:53:58 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: Online signing In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Fri, 11 Jun 2004 18:45:29 +0100." <73E03300A1CCA6D568D24F69@[192.168.100.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Jun 2004 17:53:58 +0000 Message-Id: <20040611175358.272BC13DED@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > who only want to know if they can forward the dnssec-bis docset to > > the IESG. > > did they not ask for comments on -trans? yes. but -trans is just a straw poll on forwarding dnssec-bis to iesg, so even though it has a different name, it's the same conversation. > I am assuming here that it is relevant point to make, that although > the consensus on the WG is not to fix NSEC in -bis, this will likely > cause certain operators not to deploy until -ter; isn't that what > transition is all about? yes. but saying "deploying -bis with nsec synthesis would cause me to buy more hardware than i want given my anycast configuration" is not, in and of itself, an argument not to forward -bis. it is in fact a tacit approval since it makes the case that under known and reachable, though undesirable, circumstances, someone could deploy -bis without waiting for -ter. that's even better than "i can't deploy until -ter but i agree that there's a reasonable way of getting to -ter from -bis" which is mostly what the -trans (and -ter) authors are hoping for. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 14:06:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22121 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 14:06:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYqMV-0006ME-5b for namedroppers-data@psg.com; Fri, 11 Jun 2004 18:02:43 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYqMU-0006Lk-6A for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 18:02:42 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 5F3A51FDCB; Fri, 11 Jun 2004 19:02:41 +0100 (BST) Date: Fri, 11 Jun 2004 19:02:39 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Roy Arends <roy@dnss.ec> Cc: Jakob Schlyter <jakob@rfc.se>, Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <793F6BA324BF1F488DF10C9A@[192.168.100.5]> In-Reply-To: <Pine.LNX.4.58.0406111430430.2889@elektron.atoom.net> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> <116E49C95CA73E39BBB12EF9@[192.168.100.22]> <Pine.LNX.4.58.0406111307370.2889@elektron.atoom.net> <4CDEA9673049B147C1795422@[192.168.100.22]> <Pine.LNX.4.58.0406111430430.2889@elektron.atoom.net> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 11 June 2004 14:59 +0200 Roy Arends <roy@dnss.ec> wrote: >> nor do I feel the option of >> "doing nothing (don't deploy)" is included. > > Okay, will include that option in the draft. Send text please. How about: 2.1.7 Do not deploy DNSSEC-bis Do not deploy DNSSEC-bis; retain RFC1034/1035 non-secured nameservice until DNSSEC-ter is deployable. 2.1.7.1 Coexistence and Migration Current resolvers support and must continue to support RFC1034/1035 as must DNSSEC-bis resolvers. Assuming this requirement is cascaded to DNSSEC-ter, there will be no coexistence issues. No migration is required. 2.1.7.2 Limitations It will not be possible for resolvers to authenticate any response. 2.1.7.3 Amendments to DNSSEC-bis None required. 2.1.7.4 Cons Does not meet requirements to provide authentication. 2.1.7.5 Pros No additional software development required. No implementation burden (assuming non-bis RFC2535 has not been deployed). Operational consequences well understood. 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 Jun 11 14:09:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22210 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 14:09:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYqQb-0006wx-7W for namedroppers-data@psg.com; Fri, 11 Jun 2004 18:06:57 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYqQa-0006wb-EU for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 18:06:56 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 36DA013DDA; Fri, 11 Jun 2004 18:06:56 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: Prupose of draft-ietf-dnsext-dnssec-trans-00.txt References: <cabno7$ffm$1@sf1.isc.org> From: Paul Vixie <vixie@vix.com> Date: 11 Jun 2004 18:06:56 +0000 In-Reply-To: <cabno7$ffm$1@sf1.isc.org> Message-ID: <g3y8muotof.fsf@sa.vix.com> Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> writes: > ... > The question is if with this set of ways forward we can ship > DNSSEC-bis without closing the doors on ourselves. > > We do not want to select the actual solution now, we want to make sure > if we do not close the door on ourselves. > > If you think we are closing the door on ourselves by shipping > DNSSEC-bis as is than please speak up (as Simon Josefsson did in the > "DNSKEY flags field" thread). and did you want those of us who consider the current -trans and -ter drafts to be evidence of the possibility of moving from -bis to -ter later, and who therefore think that -bis should be sent to IESG with only editorial changes as required to answer recent document quality questions, to just stay silent? in other words, is this a positive-pressure or negative-pressure gate? -- 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 Jun 11 14:23:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22902 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 14:23:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYqbW-0008Yp-Ne for namedroppers-data@psg.com; Fri, 11 Jun 2004 18:18:14 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYqbV-0008Ya-FS for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 18:18:13 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 11 Jun 2004 14:18:12 -0400 id 00134A93.40C9F764.0000569F From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Date: Fri, 11 Jun 2004 14:18:12 -0400 User-Agent: KMail/1.6.2 References: <ilufz9332at.fsf@latte.josefsson.org> <20040611095744.39b826ab.olaf@ripe.net> <ilu7juerw0q.fsf@latte.josefsson.org> In-Reply-To: <ilu7juerw0q.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406111418.12522.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday 11 June 2004 10:48 am, Simon Josefsson wrote: > > Edward Lewis <edlewis@arin.net> wrote: > >> I think the problem (and I'm off on a tangent now) is that you have > >> to make the verifier be able to realize at the DS RR set that the > >> child will have no acceptable keys for me - at the point where I can > >> verify the "end of understandable security" while still being secure > >> enough to trust it. > I believe none if those discussions are required, or even useful. By > the same argument, do you also believe that the document describe what > should happen when the protocol field is not 3? Essentially, I don't > see the difference between when a DNSKEY is invalid because the > protocol field is not 3, and when (with my proposed text) bits 8-14 > are non-zero. If your intention is to use bits 8-14 -or- the protocol field as a transition mechanism, then yes. > If the WG prefer having only the Protocol Field available for use in > future revisions, then fine. My suggestion was based on the thought > that it would be cleaner to have the Bit Field available for this > purpose too. I do not think that the protocol field is useful for future revisions as it currently stands. > If the intention is not to use the Protocol Field for future revision, > then the field serve no purpose and I believe it should be removed. It, in fact, serves no purpose. The protocol field is there for historical reasons only. For either your proposal or the protocol field to be useful as an indicator of a future revision, the resolver behavior wrt keys in unknown protocols has to be defined...differently. -- 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 Jun 11 14:35:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23507 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 14:35:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYqpo-000ANj-0a for namedroppers-data@psg.com; Fri, 11 Jun 2004 18:33:00 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYqpm-000ANG-Qv for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 18:32:59 +0000 Received: from Puki.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.11/8.12.11) with ESMTP id i5BIWoeR014024; Fri, 11 Jun 2004 14:32:51 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040611141139.02d6aec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 11 Jun 2004 14:32:20 -0400 To: Paul Vixie <vixie@vix.com>, namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Prupose of draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <g3y8muotof.fsf@sa.vix.com> References: <cabno7$ffm$1@sf1.isc.org> <g3y8muotof.fsf@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 14:06 11/06/2004, Paul Vixie wrote: >"Olaf M. Kolkman" <olaf@ripe.net> writes: > > > ... > > The question is if with this set of ways forward we can ship > > DNSSEC-bis without closing the doors on ourselves. > > > > We do not want to select the actual solution now, we want to make sure > > if we do not close the door on ourselves. > > > > If you think we are closing the door on ourselves by shipping > > DNSSEC-bis as is than please speak up (as Simon Josefsson did in the > > "DNSKEY flags field" thread). > >and did you want those of us who consider the current -trans and -ter= drafts >to be evidence of the possibility of moving from -bis to -ter later, and= who >therefore think that -bis should be sent to IESG with only editorial= changes >as required to answer recent document quality questions, to just stay= silent? The -trans and -ter drafts document there are ways forward even if we deploy -bis. We plan on publishing one or both as Informational RFC for future reference. We chairs encourage you to either submit the -ter document as a Internet= draft or take relevant text out of the -ter document and fold it into the -trans document. What we the chairs would like is to move some of this discussion to dnssec@cafax.se (the WG alternate mailing list for half baked ideas). >in other words, is this a positive-pressure or negative-pressure gate? The chairs only apply gentle positive-pressure ;-) Discussion we encourage on namedroppers: - current set of DNSSEC-bis documents - making NSEC, DNSKEY, DS, RRSIG more robust for future use - draft-ietf-dnsext-dnssec-trans-00.txt related to errors, missing cases, clarifications of text. - Wild card clarify issues - LLMNR draft. - Interoperabilty of DNS protocol documents that are in Proposed Standard state. - Any DNS other protocol issues Discussion we preferred to take place on dnssec@cafax.se - alternatives to NSEC or the need for NSEC functionality. - unpublished draft vixie-...-ter - costs of different alternatives - Crypto issues - alternative in dnssec-trans-0x.txt to recommend. - ideas for in-protocol DNSKEY revocations - alternate validation of Trust anchors. - DNSSEC issues that are somewhere between protocol and operations. We are planning to have a two meeting slots at the next IETF in San Diego, to provide high bandwidth forum to discuss many of these ideas. We requested these slots be spaced out as much as possible to facilitate smaller groups working on ideas/analysis/testing during the meeting. =D3lafur (on behalf of Olaf) =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 Jun 11 14:55:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24400 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 14:55:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYr4c-000CBh-Cu for namedroppers-data@psg.com; Fri, 11 Jun 2004 18:48:18 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYr4Z-000CB7-D2 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 18:48:15 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 826FE1FDCB; Fri, 11 Jun 2004 19:48:14 +0100 (BST) Date: Fri, 11 Jun 2004 19:48:13 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Roy Arends <roy@dnss.ec> Cc: Jakob Schlyter <jakob@rfc.se>, Ben Laurie <ben@algroup.co.uk>, DNSEXT WG <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <90B1414324BE927DEB9A7233@[192.168.100.5]> In-Reply-To: <Pine.LNX.4.58.0406111430430.2889@elektron.atoom.net> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <9BB08674-BB88-11D8-8914-000A95821192@rfc.se> <116E49C95CA73E39BBB12EF9@[192.168.100.22]> <Pine.LNX.4.58.0406111307370.2889@elektron.atoom.net> <4CDEA9673049B147C1795422@[192.168.100.22]> <Pine.LNX.4.58.0406111430430.2889@elektron.atoom.net> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy, --On 11 June 2004 14:59 +0200 Roy Arends <roy@dnss.ec> wrote: > If you want to wait for -ter, that would be the good thing. That is what > we recommend in the draft ! If you can't wait that long, we recommend the > synthesis hack. If you can wait that long you have the option to "doing > nothing (don't deploy)" On reflection, perhaps this is the cause of our misunderstanding eachother. The draft says: > The authors recommend that the working group commits to and starts > work on a partial TCR, allowing gracefull transition towards a future > version of NSEC. Meanwhile, to accomodate the need for an > immediately, temporary, solution against zone-traversal, we recommend > On-Demand NSEC synthesis. The last sentence is perhaps a little ambiguous as to what is recommended when and to whom. Can I suggest that the sentiments in your mail would be more clearly expressed in -trans as follows: The authors recommend that the working group commits to and starts work on a partial TCR, allowing graceful transition towards a future version of NSEC to be incorporated in DNSSEC-ter. Meanwhile, for those for whom zone traversal is problematic, but who have a requirement for authenticated DNS which cannot wait for deployability of DNSSEC-ter, we recommend On-Demand NSEC synthesis. 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 Jun 11 14:59:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24597 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 14:59:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYrBo-000DU0-9X for namedroppers-data@psg.com; Fri, 11 Jun 2004 18:55:44 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYrBn-000DTV-7k for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 18:55:43 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 842B11FDCB; Fri, 11 Jun 2004 19:55:42 +0100 (BST) Date: Fri, 11 Jun 2004 19:55:41 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, Paul Vixie <vixie@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: Prupose of draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <7E3D585CBD96D7D92F3E9209@[192.168.100.5]> In-Reply-To: <6.1.0.6.2.20040611141139.02d6aec0@localhost> References: <cabno7$ffm$1@sf1.isc.org> <g3y8muotof.fsf@sa.vix.com> <6.1.0.6.2.20040611141139.02d6aec0@localhost> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Olafur, --On 11 June 2004 14:32 -0400 "=D3lafur Gudmundsson/DNSEXT co-chair"=20 <ogud@ogud.com> wrote: > Discussion we encourage on namedroppers: I am now confused. The first message said radio silence on (nearly) everything. Your co-chair's second said radio silence on NSEC2 but "feel free to discuss any other item that is within the scope of DNSEXT." And this message seems to suggest the latter are out of scope. So namedroppers is the dnsext mailing list, and -trans is a dnsext w/g draft. So is discussion on draft-ietf-dnsext-dnssec-trans-00.txt acceptable here (provided it does not touch on NSEC2) or 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 Jun 11 15:11:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22903 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 14:23:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYqcW-0008eh-On for namedroppers-data@psg.com; Fri, 11 Jun 2004 18:19:16 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYqcV-0008eK-SW for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 18:19:16 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 2AC1A1FDCB; Fri, 11 Jun 2004 19:19:15 +0100 (BST) Date: Fri, 11 Jun 2004 19:19:13 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: Online signing Message-ID: <F61F713A15F3940725895A95@[192.168.100.5]> In-Reply-To: <20040611175358.272BC13DED@sa.vix.com> References: <20040611175358.272BC13DED@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 11 June 2004 17:53 +0000 Paul Vixie <paul@vix.com> wrote: > yes. but saying "deploying -bis with nsec synthesis would cause me to > buy more hardware than i want given my anycast configuration" is not, > in and of itself, an argument not to forward -bis. it is in fact a > tacit approval since it makes the case that under known and reachable, > though undesirable, circumstances, someone could deploy -bis without > waiting for -ter. that's even better than "i can't deploy until -ter > but i agree that there's a reasonable way of getting to -ter from -bis" > which is mostly what the -trans (and -ter) authors are hoping for. For the avoidance of doubt, my argument was not (given w/g consensus etc.) that -bis should not be forwarded to IESG; my argument was that (a) -trans should be fixed to show the "wait for -ter" option (as -trans considers interim options), lest anyone get the impression that online synthesis was such a no-brainer that "don't deploy until -ter" shouldn't be considered, and (b) that the cons of synthesis should be fully documented. Neither synthesis nor "don't deploy until -ter" require of themselves any change to -bis, so if anything it's an argument *to* forward to the IESG. Re your point on funding, my current view is I would far rather put funding up to fix the issue properly (see Ben's work on NSEC2 & BIND), in terms of protocol development, proof of concept, or getting production code cut, than put funding up for synthesis; but I am listening to argument. This is what I meant by the "distraction" argument. 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 Jun 11 15:13:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25853 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 15:13:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYrPQ-000Fpf-9j for namedroppers-data@psg.com; Fri, 11 Jun 2004 19:09:48 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYrPO-000FpB-Lg for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 19:09:47 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 81EF31FF845; Fri, 11 Jun 2004 19:09:45 +0000 (GMT) Message-ID: <40CA0378.9010401@algroup.co.uk> Date: Fri, 11 Jun 2004 20:09:44 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: Online signing References: <20040611172822.F141413DE5@sa.vix.com> In-Reply-To: <20040611172822.F141413DE5@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>I hope the assumptions one might have about a crypto-driven DDoS attack >>>is hereby tuned to a non-issue. >> >>I can't agree that having to deploy expensive crypto accelerators makes >>anything a non-issue. > > then you're having a different conversation than the rest of us. > >>What I would agree is that it makes it a soluble issue. > > anything that can be solved outofband is a nonissue for dnssec-bis @IESG. > > the conversation at hand is, can we send dnssec-bis to the IESG. > > you appear to be saying "yes", both in the above "makes it soluble" comment > and in your agreement with my dnssec-ter-01 draft. > > any issue like "the crypto boards will cost too much" isn't relevant. any > issue like "online NSEC synthesis will expose the signing key to attacks > because the attacker can force the victim to do unsalted crypto" is relevant. > > i realize that these issues are equally near and dear to you. but they are > very different from the point of view of our chairs, who only want to know > if they can forward the dnssec-bis docset to the IESG. Its not clear to me that the crypto boards will even exist, but that's not the important issue, as you say. What is important is exposure of keys. However, I'm leaning towards the vastly cheaper and safer option of having a single (or two) NSEC record(s) that can be used for all denials as the interim measure of choice. 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 Jun 11 15:40:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27744 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 15:40:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYrps-000Il5-Sm for namedroppers-data@psg.com; Fri, 11 Jun 2004 19:37:08 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYrpr-000Ikp-RJ for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 19:37:08 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.12.11/8.12.11) with ESMTP id i5BJb2WV014299 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 15:37:02 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040611152812.02fc4a08@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 11 Jun 2004 15:36:59 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After reading Paul's Vixie -ter proposal http://psg.com/lists/namedroppers/namedroppers.2004/msg00967.html and Jakob, Peter and Roy's -trans list of approaches http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt Please speak up on this question to help chairs gauge consensus. thanks Olafur & Olaf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 16:26:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27743 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 15:40:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYrqU-000Ip2-Ia for namedroppers-data@psg.com; Fri, 11 Jun 2004 19:37:46 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYrqT-000Iod-Kh for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 19:37:45 +0000 Received: from Puki.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.12.11/8.12.11) with ESMTP id i5BJbWLS014302; Fri, 11 Jun 2004 15:37:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040611151636.02fd3dc8@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 11 Jun 2004 15:27:50 -0400 To: Alex Bligh <alex@alex.org.uk>, =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>, Paul Vixie <vixie@vix.com>, namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Prupose of draft-ietf-dnsext-dnssec-trans-00.txt Cc: Alex Bligh <alex@alex.org.uk> In-Reply-To: <7E3D585CBD96D7D92F3E9209@[192.168.100.5]> References: <cabno7$ffm$1@sf1.isc.org> <g3y8muotof.fsf@sa.vix.com> <6.1.0.6.2.20040611141139.02d6aec0@localhost> <7E3D585CBD96D7D92F3E9209@[192.168.100.5]> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,PORN_4 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 14:55 11/06/2004, Alex Bligh wrote: >Olafur, > >--On 11 June 2004 14:32 -0400 "=D3lafur Gudmundsson/DNSEXT co-chair"=20 ><ogud@ogud.com> wrote: > >>Discussion we encourage on namedroppers: > >I am now confused. The first message said radio silence on (nearly) >everything. Your co-chair's second said radio silence on NSEC2 but "feel >free to discuss any other item that is within the scope of DNSEXT." And >this message seems to suggest the latter are out of scope. DNSEXT WG has 2 official mailing lists, see: www.dnsext.org [1] NSEC2 and other Negative alternatives discussion should move to dnssec@cafax.se, where the subgroup of DNSEXT people interested playing with new ideas for DNSSEC is concentrated. >So namedroppers is the dnsext mailing list, and -trans is a dnsext w/g >draft. So is discussion on >draft-ietf-dnsext-dnssec-trans-00.txt >acceptable here (provided it does not touch on NSEC2) or not? As long as the discussion is about document quality or "signalling" mechanisms not the "Negative answer" mechanisms. Olafur [1] Thanks Stewart Cheshire for providing this redirect service. =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 Jun 11 16:43:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03515 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 16:43:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYsoa-0000CP-04 for namedroppers-data@psg.com; Fri, 11 Jun 2004 20:39:52 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYsoW-0000Bq-RN for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 20:39:48 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id BB4DF19B8E7; Fri, 11 Jun 2004 16:39:35 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3CC1619B8E3; Fri, 11 Jun 2004 16:39:35 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1761123; Fri, 11 Jun 2004 16:39:47 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020409bcefc73e3348@[192.136.136.83]> In-Reply-To: <Pine.LNX.4.58.0406101746070.2889@elektron.atoom.net> References: <20040603161757.2c386dd7.olaf@ripe.net> <Pine.OSX.4.60.0406100932520.5571@criollo.schlyter.se> <a06020431bcee2fb29e74@[192.136.136.83]> <Pine.LNX.4.58.0406101746070.2889@elektron.atoom.net> Date: Fri, 11 Jun 2004 16:39:56 -0400 To: Roy Arends <roy@dnss.ec> From: Edward Lewis <edlewis@arin.net> Subject: Re: Evaluating DNSSEC transition mechanisms Cc: IETF DNSEXT WG <namedroppers@ops.ietf.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:24 +0200 6/10/04, Roy Arends wrote: >Just to be clear, we don't propose these mechanisms, they're just >there. What we _do_ recommend (propose) is partial TCR++. I realized that. My comments were meant to cover things I didn't see in the commentary. >You got it mister ! And I learned a new word ! Always glad to help. >Are you suggesting we don't yet publish -bis. Hold the code. Rewrite NSEC ? Rambling means "I don't know." ;) >My current thinking is that partial TCR is still the best long-term >solution. If folk can't wait for that, use on-demand-nsec-signing. ymmv. As far as TCR being a strategy, how does a -bis era verifier detect that there is a new authenticated denial record replacing the one it expects to see? Let's say NSEC is type code X, and NSEC14 is type code Y. Y replaces X, but how does the verifier know that? Maybe because it sees a Y where there ought to be an X? Then what keeps someone from stuffing in a Z, not replacing X, but it looks like it to the verifier? (Yet another rambling argument.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Jun 11 17:32:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06783 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 17:32:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYtad-0005qB-I8 for namedroppers-data@psg.com; Fri, 11 Jun 2004 21:29:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYtac-0005pu-P0 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 21:29:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 36E8E13960 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 21:29:30 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: Online signing In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Fri, 11 Jun 2004 20:09:44 +0100." <40CA0378.9010401@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Jun 2004 21:29:30 +0000 Message-Id: <20040611212930.36E8E13960@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ..., I'm leaning towards the vastly cheaper and safer option of having > a single (or two) NSEC record(s) that can be used for all denials as the > interim measure of choice. this will open you up to replay attacks. anyone who receives one of these NSECs, signed by you and clearly covering a large range of existing names, would be able to use it along with queryid-guessing to make someone believe an existing domain name does not exist. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 17:37:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07157 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 17:37:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYtgS-0006wU-LN for namedroppers-data@psg.com; Fri, 11 Jun 2004 21:35:32 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYtgO-0006vb-Uv for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 21:35:29 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BYtgN-0007qL-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 23:35:27 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 23:35:27 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 23:35:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Fri, 11 Jun 2004 23:35:19 +0200 Lines: 66 Message-ID: <ilun039bwx4.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <20040611095744.39b826ab.olaf@ripe.net> <ilu7juerw0q.fsf@latte.josefsson.org> <200406111418.12522.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:n9kZUyYOP8Dr/PJy79iAJRinc/M= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka <davidb@verisignlabs.com> writes: > On Friday 11 June 2004 10:48 am, Simon Josefsson wrote: > >> > Edward Lewis <edlewis@arin.net> wrote: >> >> I think the problem (and I'm off on a tangent now) is that you have >> >> to make the verifier be able to realize at the DS RR set that the >> >> child will have no acceptable keys for me - at the point where I can >> >> verify the "end of understandable security" while still being secure >> >> enough to trust it. > >> I believe none if those discussions are required, or even useful. By >> the same argument, do you also believe that the document describe what >> should happen when the protocol field is not 3? Essentially, I don't >> see the difference between when a DNSKEY is invalid because the >> protocol field is not 3, and when (with my proposed text) bits 8-14 >> are non-zero. > > If your intention is to use bits 8-14 -or- the protocol field as a transition > mechanism, then yes. I don't intend to use as a fully elaborated transition mechanism, only to make it _possible_ to use it in a fully elaborated transition mechanism. Much like (I believe) the protocol field can be used for this. >> If the WG prefer having only the Protocol Field available for use in >> future revisions, then fine. My suggestion was based on the thought >> that it would be cleaner to have the Bit Field available for this >> purpose too. > > I do not think that the protocol field is useful for future revisions as it > currently stands. Why not? The current text says: The Protocol Field MUST have value 3 and the DNSKEY RR MUST be treated as invalid during signature verification if found to be some value other than 3. Given this, a future revision could depend on DNSSECbis resolvers following the above text and reject DNSKEY RRs with non-3 protocol fields. I don't think the details of how non-3 values are to be used is important, and they don't need to be described now. The above text is a vehicle for future expansion. >> If the intention is not to use the Protocol Field for future revision, >> then the field serve no purpose and I believe it should be removed. > > It, in fact, serves no purpose. The protocol field is there for historical > reasons only. As DNSSECbis is not backwards compatible with DNSSEC, this argument doesn't appear to be very convincing to me. As DNSKEY is currently defined, the field can serve a purpose in a revision, which I believe is good. If the intention is to never make use of resolver behaviour for the protocol field, then I fail to understand why the current text places requirements on DNSSECbis implementations. Every protocol requirement in the document leads to interoperability tests, which are expensive. If the specification did not include a MUST, it will be impossible to rely on any specific behaviour and it could not be used in a revision. 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 Jun 11 18:01:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09553 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 18:01:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYu2e-000AWR-Ke for namedroppers-data@psg.com; Fri, 11 Jun 2004 21:58:28 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYu2c-000AVv-H6 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 21:58:27 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BYu2b-000892-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 23:58:25 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 23:58:25 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 23:58:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Date: Fri, 11 Jun 2004 23:58:22 +0200 Lines: 26 Message-ID: <iluisdxbvup.fsf@latte.josefsson.org> References: <6.1.0.6.2.20040611152812.02fc4a08@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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:psG75cuKty6+lVLRgNz8drW6gJU= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Ólafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com> writes: > After reading Paul's Vixie -ter proposal > http://psg.com/lists/namedroppers/namedroppers.2004/msg00967.html > and Jakob, Peter and Roy's -trans list of approaches > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt > > Please speak up on this question to help chairs gauge consensus. Advancing DNSSECbis to IESG does not prevent _anything_ in the future, as specifying a backwards incompatible DNSSECter with NSEC-alt will be possible. Whether advancing the current documents to IESG will allow smooth transition to a NSEC-alt solution is a different question, and to it I would answer no. The recommendation in dnssec-trans does not meet initial expected DNSSEC design criteria -- online key, secure channel between master and slave, per-query private key operations, etc. People looking into transitioning might find it cheaper to provide bogus NSEC responses and specify their own solution, instead of adopting the recommendation. E.g., NSEC2. 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 Jun 11 18:13:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11204 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 18:13:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYuFM-000CRZ-IA for namedroppers-data@psg.com; Fri, 11 Jun 2004 22:11:36 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYuFL-000CRI-Hn for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 22:11:35 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 11 Jun 2004 18:11:33 -0400 id 0014A026.40CA2E15.000014E2 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Date: Fri, 11 Jun 2004 18:11:34 -0400 User-Agent: KMail/1.6.2 References: <ilufz9332at.fsf@latte.josefsson.org> <200406111418.12522.davidb@verisignlabs.com> <ilun039bwx4.fsf@latte.josefsson.org> In-Reply-To: <ilun039bwx4.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406111811.34513.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday 11 June 2004 5:35 pm, Simon Josefsson wrote: > > I do not think that the protocol field is useful for future revisions as > > it currently stands. > > Why not? The current text says: > > The Protocol Field MUST have value 3 and the DNSKEY RR MUST be > treated as invalid during signature verification if found to be some > value other than 3. > > Given this, a future revision could depend on DNSSECbis resolvers > following the above text and reject DNSKEY RRs with non-3 protocol > fields. I don't think the details of how non-3 values are to be used > is important, and they don't need to be described now. The above text > is a vehicle for future expansion. I will agree that current validators will reject DNSKEY RRs with non-3 protocol fields. That is the intent as I see it, anyway. As far as I can tell, the current result of publishing a signed zone with all DNSKEYs of protocol = 4 is that resolvers who think the zone should be secured will conclude that every answer from that zone is BOGUS. That just doesn't seem like a good vehicle for future expansion to me. But maybe we are talking about different forms of "expansion". > >> If the intention is not to use the Protocol Field for future revision, > >> then the field serve no purpose and I believe it should be removed. > > > > It, in fact, serves no purpose. The protocol field is there for > > historical reasons only. > > As DNSSECbis is not backwards compatible with DNSSEC, this argument > doesn't appear to be very convincing to me. As DNSKEY is currently > defined, the field can serve a purpose in a revision, which I believe > is good. I'm not arguing anything. I'm just stating what I believe to be a fact. > If the intention is to never make use of resolver behaviour for the > protocol field, then I fail to understand why the current text places > requirements on DNSSECbis implementations. Every protocol requirement > in the document leads to interoperability tests, which are expensive. > If the specification did not include a MUST, it will be impossible to > rely on any specific behaviour and it could not be used in a revision. If you were to argue for the removal of the protocol field from the DNSKEY record on the grounds that it is useless, you would get no argument from me. If you were, instead, to argue for language changes to the DNSSECbis docset to make the field more useful for something, you would also be quite welcome. If you would like to describe how to use the protocol field for a future revision with the docs as-is, you would also be quite welcome. -- 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 Jun 11 18:51:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12992 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 18:51:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYupj-000H2y-PA for namedroppers-data@psg.com; Fri, 11 Jun 2004 22:49:11 +0000 Received: from [200.155.98.42] (helo=brsaoex01.primesys.br) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYuph-000H2Z-TV for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 22:49:10 +0000 Received: from mail pickup service by brsaoex01.primesys.br with Microsoft SMTPSVC; Fri, 11 Jun 2004 19:48:56 -0300 Received: from psg.com ([147.28.0.62]) by brsaoex01.primesys.br with Microsoft SMTPSVC(5.0.2195.5329); Fri, 11 Jun 2004 16:05:41 -0300 Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYrBo-000DU0-9X for namedroppers-data@psg.com; Fri, 11 Jun 2004 18:55:44 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYrBn-000DTV-7k for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 18:55:43 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 842B11FDCB; Fri, 11 Jun 2004 19:55:42 +0100 (BST) Date: Fri, 11 Jun 2004 19:55:41 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, Paul Vixie <vixie@vix.com>, namedroppers@ops.ietf.org Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: Prupose of draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <7E3D585CBD96D7D92F3E9209@[192.168.100.5]> In-Reply-To: <6.1.0.6.2.20040611141139.02d6aec0@localhost> References: <cabno7$ffm$1@sf1.isc.org> <g3y8muotof.fsf@sa.vix.com> <6.1.0.6.2.20040611141139.02d6aec0@localhost> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-OriginalArrivalTime: 11 Jun 2004 19:05:41.0890 (UTC) FILETIME=[17397E20:01C44FE7] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Olafur, --On 11 June 2004 14:32 -0400 "=D3lafur Gudmundsson/DNSEXT co-chair"=20 <ogud@ogud.com> wrote: > Discussion we encourage on namedroppers: I am now confused. The first message said radio silence on (nearly) everything. Your co-chair's second said radio silence on NSEC2 but "feel free to discuss any other item that is within the scope of DNSEXT." And this message seems to suggest the latter are out of scope. So namedroppers is the dnsext mailing list, and -trans is a dnsext w/g draft. So is discussion on draft-ietf-dnsext-dnssec-trans-00.txt acceptable here (provided it does not touch on NSEC2) or 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/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 18:55:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13081 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 18:55:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYuty-000HnW-Mr for namedroppers-data@psg.com; Fri, 11 Jun 2004 22:53:34 +0000 Received: from [200.155.98.42] (helo=brsaoex01.primesys.br) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYutx-000Hmv-LR for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 22:53:33 +0000 Received: from mail pickup service by brsaoex01.primesys.br with Microsoft SMTPSVC; Fri, 11 Jun 2004 19:53:19 -0300 Received: from psg.com ([147.28.0.62]) by brsaoex01.primesys.br with Microsoft SMTPSVC(5.0.2195.5329); Fri, 11 Jun 2004 18:42:17 -0300 Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYtad-0005qB-I8 for namedroppers-data@psg.com; Fri, 11 Jun 2004 21:29:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYtac-0005pu-P0 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 21:29:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 36E8E13960 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 21:29:30 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: Online signing In-Reply-To: Message from Ben Laurie <ben@algroup.co.uk> of "Fri, 11 Jun 2004 20:09:44 +0100." <40CA0378.9010401@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Jun 2004 21:29:30 +0000 Message-Id: <20040611212930.36E8E13960@sa.vix.com> X-OriginalArrivalTime: 11 Jun 2004 21:42:18.0359 (UTC) FILETIME=[F7F4E070:01C44FFC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ..., I'm leaning towards the vastly cheaper and safer option of having > a single (or two) NSEC record(s) that can be used for all denials as the > interim measure of choice. this will open you up to replay attacks. anyone who receives one of these NSECs, signed by you and clearly covering a large range of existing names, would be able to use it along with queryid-guessing to make someone believe an existing domain name does not exist. -- to unsubscribe send a message to namedroppers-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 Jun 11 19:03:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13346 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 19:03:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYv0D-000J3t-Va for namedroppers-data@psg.com; Fri, 11 Jun 2004 23:00:01 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYv0C-000J2s-Ld for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 23:00:01 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 21234E7E76; Sat, 12 Jun 2004 00:00:00 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: Online signing In-Reply-To: <20040611212930.36E8E13960@sa.vix.com> Message-Id: <20040611230000.21234E7E76@mx1.nominet.org.uk> Date: Sat, 12 Jun 2004 00:00:00 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> writes: > > ..., I'm leaning towards the vastly cheaper and safer option of having > > a single (or two) NSEC record(s) that can be used for all denials as the > > interim measure of choice. > > this will open you up to replay attacks. anyone who receives one of these > NSECs, signed by you and clearly covering a large range of existing names, > would be able to use it along with queryid-guessing to make someone believe > an existing domain name does not exist. True . . . but NSEC RR replay attacks may be deeply less interesting than other DNS m{an,onkey}-in-the-middle attacks. So, many of the benefits of DNSSECbis could be realised (including operational experience) without the increased exposure of private keys which dynamic NSEC synthesis would entail. Of course this would be a -trans mechanism only; authenticated denial-of-existence is ultimately an important objective of DNSSEC. 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 Jun 11 19:24:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14130 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 19:24:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYvLQ-000Lya-Sl for namedroppers-data@psg.com; Fri, 11 Jun 2004 23:21:56 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYvLP-000Ly9-0i for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 23:21:55 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BYvLO-0000ny-00 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 01:21:54 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 01:21:54 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 01:21:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Sat, 12 Jun 2004 01:21:50 +0200 Lines: 74 Message-ID: <iluekolbrzl.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <200406111418.12522.davidb@verisignlabs.com> <ilun039bwx4.fsf@latte.josefsson.org> <200406111811.34513.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:lT8cI/IIvrnj11sNzrVHkLqtiDE= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka <davidb@verisignlabs.com> writes: > On Friday 11 June 2004 5:35 pm, Simon Josefsson wrote: > >> > I do not think that the protocol field is useful for future revisions as >> > it currently stands. >> >> Why not? The current text says: >> >> The Protocol Field MUST have value 3 and the DNSKEY RR MUST be >> treated as invalid during signature verification if found to be some >> value other than 3. >> >> Given this, a future revision could depend on DNSSECbis resolvers >> following the above text and reject DNSKEY RRs with non-3 protocol >> fields. I don't think the details of how non-3 values are to be used >> is important, and they don't need to be described now. The above text >> is a vehicle for future expansion. > > I will agree that current validators will reject DNSKEY RRs with non-3 > protocol fields. That is the intent as I see it, anyway. We agree here. > As far as I can tell, the current result of publishing a signed zone with all > DNSKEYs of protocol = 4 is that resolvers who think the zone should be > secured will conclude that every answer from that zone is BOGUS. By BOGUS, do you mean that since no valid DNSKEY were found, and consequently no RRSIGs could be verified, returned data is considered insecure? Or are you saying a DNS cache, quering for (foo.example,IN,SOA) and receiving: foo.example SOA ... foo.example RRSIG SOA ... foo.example NSEC ... foo.example DNSKEY ...protocol field 4... should reject the entire response, and return SEVRFAIL, NOERROR or something to the client? I see no ground for that behaviour. Instead, I believe the resolver should return the requested RR. It is this behaviour that I find useful in an extension. It allow for a graceful upgrade to a DNSSECter where the failure mode is a degredation to vanilla DNS, instead of error states. > That just doesn't seem like a good vehicle for future expansion to > me. But maybe we are talking about different forms of "expansion". Perhaps so, I find the above sufficient to allow future extensions. >> If the intention is to never make use of resolver behaviour for the >> protocol field, then I fail to understand why the current text places >> requirements on DNSSECbis implementations. Every protocol requirement >> in the document leads to interoperability tests, which are expensive. >> If the specification did not include a MUST, it will be impossible to >> rely on any specific behaviour and it could not be used in a revision. > > If you were to argue for the removal of the protocol field from the DNSKEY > record on the grounds that it is useless, you would get no argument from me. > If you were, instead, to argue for language changes to the DNSSECbis docset > to make the field more useful for something, you would also be quite welcome. > If you would like to describe how to use the protocol field for a future > revision with the docs as-is, you would also be quite welcome. And do you have any thoughts on the actual proposed text change that started this thread? I have no wish to change the Protocol Field. I have used the Protocol Field, in this thread, as an example of an already specified extension mechanism, since people appeared to think that my proposed change wanted to introduce a new extension mechanism. I want to introduce a cleaner way to specify the extensions, compared to using the protocol field. 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 Jun 11 19:41:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12995 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 18:51:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYund-000GiX-VL for namedroppers-data@psg.com; Fri, 11 Jun 2004 22:47:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYund-000GiB-16 for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 22:47:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AC5CE139A3 for <namedroppers@ops.ietf.org>; Fri, 11 Jun 2004 22:47:00 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> of "Fri, 11 Jun 2004 18:11:34 -0400." <200406111811.34513.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 11 Jun 2004 22:47:00 +0000 Message-Id: <20040611224700.AC5CE139A3@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As far as I can tell, the current result of publishing a signed zone with > all DNSKEYs of protocol = 4 is that resolvers who think the zone should > be secured will conclude that every answer from that zone is BOGUS. that's my reading also. > That just doesn't seem like a good vehicle for future expansion to me. agreed. the whole protocol field is worthless and illconsidered as it is. however, it can be hardcoded to 3 and left in the spec; we already abandoned "pretty" about 200,000 miles ago, and this does not even approach "dangerous". > If you were to argue for the removal of the protocol field from the > DNSKEY record on the grounds that it is useless, you would get no > argument from me. you would get an argument from me, however. it's doing no harm and there's already been some early deployment with it. before we break stiction on that early deployment we need to prove that something is actively harmful, like for example, prevents -ter from being even theoretically possible. this does not meet that standard. > If you were, instead, to argue for language changes to the DNSSECbis > docset to make the field more useful for something, you would also be > quite welcome. If you would like to describe how to use the protocol > field for a future revision with the docs as-is, you would also be > quite welcome. or if you'd just like to leave it defined as it is, that would be ok w/ me, since "useless" != "harmful". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 19:44:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14644 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 19:44:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYveb-000Ns9-5l for namedroppers-data@psg.com; Fri, 11 Jun 2004 23:41:45 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYvea-000Nrv-2O for namedroppers@ops.ietf.org; Fri, 11 Jun 2004 23:41:44 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 8B1E4E7E76; Sat, 12 Jun 2004 00:41:43 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <Pine.LNX.4.58.0406111509560.2889@elektron.atoom.net> Message-Id: <20040611234143.8B1E4E7E76@mx1.nominet.org.uk> Date: Sat, 12 Jun 2004 00:41:43 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > There are first other ceilings (like bandwith, server performance) to > overcome if one suspects a possible crypto DDoS. This implies that a > simple non-crypto DDoS is just as easy to deploy, and the asynchronous > cost argument (for this particular use) disappears. True . . . if plausible crypto acceleration solutions exist which are capable of generating 40,000 NSEC RRSIGs per second, then admittedly DoS attacks exceeding this rate would be close to exceeding other operational thresholds. With luck, the rate of improvement in respective capabilities (crypto acceleration, bandwidth, server, etc.) will not adversely affect this balance before -ter is deployable. 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 Jun 11 22:04:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19737 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 22:04:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYxov-000CNo-Pg for namedroppers-data@psg.com; Sat, 12 Jun 2004 02:00:33 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYxou-000CNV-BS for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 02:00:32 +0000 Received: from [192.168.1.13] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 11 Jun 2004 22:00:30 -0400 id 00134EF8.40CA63BE.00004901 In-Reply-To: <iluekolbrzl.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <200406111418.12522.davidb@verisignlabs.com> <ilun039bwx4.fsf@latte.josefsson.org> <200406111811.34513.davidb@verisignlabs.com> <iluekolbrzl.fsf@latte.josefsson.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <423968D0-BC14-11D8-BB81-000A95CC77E2@verisignlabs.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: David Blacka <davidb@verisignlabs.com> Subject: Re: DNSKEY flags field Date: Fri, 11 Jun 2004 22:00:20 -0400 To: Simon Josefsson <jas@extundo.com> X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jun 11, 2004, at 7:21 PM, Simon Josefsson wrote: > David Blacka <davidb@verisignlabs.com> writes: > >> As far as I can tell, the current result of publishing a signed zone >> with all >> DNSKEYs of protocol = 4 is that resolvers who think the zone should be >> secured will conclude that every answer from that zone is BOGUS. > > By BOGUS, do you mean that since no valid DNSKEY were found, and > consequently no RRSIGs could be verified, returned data is considered > insecure? Or are you saying a DNS cache, quering for > (foo.example,IN,SOA) and receiving: I believe, given the current language in the DNSSECbis documents, that SERVFAIL would be returned. I could be wrong. At best, resolver behavior in this situation is ambiguous, I think. > And do you have any thoughts on the actual proposed text change that > started this thread? I have no wish to change the Protocol Field. I > have used the Protocol Field, in this thread, as an example of an > already specified extension mechanism, since people appeared to think > that my proposed change wanted to introduce a new extension mechanism. > I want to introduce a cleaner way to specify the extensions, compared > to using the protocol field. I think that the WG should discuss the merits of different ways to move the protocol beyond DNSSECbis. Using the protocol field or unused flag bits seems like a good avenue to explore. I don't see a great deal of difference between using flags or the protocol field, however. -- 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 Jun 11 22:19:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20153 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 22:19:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYy4G-000EC1-KY for namedroppers-data@psg.com; Sat, 12 Jun 2004 02:16:24 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYy4F-000EBo-Rk for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 02:16:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 84EB613951 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 02:16:23 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> of "Fri, 11 Jun 2004 22:00:20 -0400." <423968D0-BC14-11D8-BB81-000A95CC77E2@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 12 Jun 2004 02:16:23 +0000 Message-Id: <20040612021623.84EB613951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I want to introduce a cleaner way to specify the extensions, compared > > to using the protocol field. so did i. see <draft-vixie-dnssec-ter-01.txt> for one possible alternative. > I think that the WG should discuss the merits of different ways to move the > protocol beyond DNSSECbis. Using the protocol field or unused flag bits > seems like a good avenue to explore. I don't see a great deal of > difference between using flags or the protocol field, however. the protocol field is essentially useless as specified. under no circumstances will a chance to the protocol field of DNSKEY have any effect on the rdata layout of any RR including DNSKEY, or on the content of other RRs including NSEC. ed lewis sometimes talks about "the holy Q-trinity", and his arguments are directly relevant here. to get different answers you'll have to ask different questions. to get different metadata (authority/additional) without asking a different question, you'll have to specify different flags (like "want dnssec" and "want dnssec-ter i mean"). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 11 23:46:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23172 for <dnsext-archive@lists.ietf.org>; Fri, 11 Jun 2004 23:46:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYzQi-000MMB-TG for namedroppers-data@psg.com; Sat, 12 Jun 2004 03:43:40 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYzQh-000MLp-P8 for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 03:43:40 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i5C3fxW4018539; Sat, 12 Jun 2004 03:41:59 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i5C3fw3V018536; Sat, 12 Jun 2004 03:41:58 GMT Date: Sat, 12 Jun 2004 03:41:58 +0000 From: bmanning@vacation.karoshi.com To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Cc: namedroppers@ops.ietf.org Subject: Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Message-ID: <20040612034158.GA18189@vacation.karoshi.com.> References: <6.1.0.6.2.20040611152812.02fc4a08@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.1.0.6.2.20040611152812.02fc4a08@localhost> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Fri, Jun 11, 2004 at 03:36:59PM -0400, Ólafur Gudmundsson/DNSEXT co-chair wrote: > > After reading Paul's Vixie -ter proposal > http://psg.com/lists/namedroppers/namedroppers.2004/msg00967.html > and Jakob, Peter and Roy's -trans list of approaches > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt > > Please speak up on this question to help chairs gauge consensus. > > thanks > Olafur & Olaf. presuming "radio-silence" - this is short. A: No. --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 Sat Jun 12 01:37:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28919 for <dnsext-archive@lists.ietf.org>; Sat, 12 Jun 2004 01:37:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZ17l-000A3z-MY for namedroppers-data@psg.com; Sat, 12 Jun 2004 05:32:13 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZ17k-000A3Z-0j for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 05:32:12 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id RAA32235 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 17:32:10 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i5C5WAfw038043 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 17:32:10 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: Your message of "Fri, 11 Jun 2004 17:42:13 GMT." <20040611174213.51BFD13951@sa.vix.com> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Sat, 12 Jun 2004 17:32:10 +1200 Message-ID: <38042.1087018330@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> wrote: >> Or would just: >> >> example. NSEC example. >> >> suffice? > >this is my preference, but i admit i don't know whether the current -bis >spec requires that either an NSEC owner or target name, or both, actually >does exist. certainly the expectation is that the owner name exists, which >is why there's a list of RRtypes in the NSEC rdata. but as to whether the >validation model actually requires such existence, i don't know. would an >NSEC asserting that no RRtypes were present at its owner name be valid? I don't understand. Is this in response to a query for "x.example." or "example."? If the former, then that could be used in a replay attack. I can't see anything in the current drafts that says what one should do when the Next Domain Name field is the same as the Name, other than at the zone apex. The latter situation can turn up, e.g. foo.example. SOA ... NS ... A ... NSEC foo.example. SOA NS A NSEC ... In this case, the NSEC record says, "There are these RRsets for foo.example, but there is nothing else in or below this zone." By extension, and I think some explicit wording in the -protocol doc would be required for this, one could interpret "foo.example. NSEC foo.example NSEC RRSIG" as meaning that there are no RRSETS for foo.example, *nor anything below it* other than the NSEC & RRSIG. Note that -protocol, section 2.3 states: An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name. That rule would have to be relaxed for this interpretation, or indeed to allow NSEC records to be dynamically generated at all. Note too that this approach doesn't cater for the situation where bar.foo.example. exists; the "foo.example. NSEC foo.example. NSEC RRSIG" response could be replayed to deny the existence of bar.foo.example. You'd need to respond with something like "foo.example. NSEC \001.foo.example. NSEC RRSIG" to say "just foo.example, and not anything below that". So, if one were going to generate signed NSEC records on the fly, one would have to do something like the following: For any name in the zone that exists, at zone build time, generate either: <name> NSEC <name> <existing-rrsets> NSEC RRSIG or <name> NSEC \001.<name) <existing-rrsets> NSEC RRSIG The latter case is required if there are any names below <name>, but should (must?) not be used if <name> is a delegation point. When asked for a name that does not exist, generate (on the fly), sign and return: <name> NSEC \001.<name> NSEC RRSIG unless one knows that there are no names below <name, in which case you could use <name> instead of \001.<name>. Alternatively, one could generate in all cases: <name> NSEC <null> NSEC RRSIG where <null> is an as yet undefined magic value that says, "there is no next domain name field", possibly even using one of the reserved values of the label type field, e.g a byte value of 0xA0. Is this what others are thinking for dynamic synthesis? Or have I got it all wrong? -- 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 Sat Jun 12 02:25:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13969 for <dnsext-archive@lists.ietf.org>; Sat, 12 Jun 2004 02:25:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZ1tv-000EyR-84 for namedroppers-data@psg.com; Sat, 12 Jun 2004 06:21:59 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZ1tu-000EyC-6T for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 06:21:58 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 24B4513993 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 06:21:57 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: Message from Don Stokes <don@plugh.daedalus.co.nz> of "Sat, 12 Jun 2004 17:32:10 +1200." <38042.1087018330@toybsd.zl2tnm.gen.nz> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 12 Jun 2004 06:21:57 +0000 Message-Id: <20040612062157.24B4513993@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> example. NSEC example. > > > >this is my preference, but i admit i don't know whether the current -bis > >spec requires that either an NSEC owner or target name, or both, actually > >does exist. certainly the expectation is that the owner name exists, which > >is why there's a list of RRtypes in the NSEC rdata. but as to whether the > >validation model actually requires such existence, i don't know. would an > >NSEC asserting that no RRtypes were present at its owner name be valid? > > I don't understand. Is this in response to a query for "x.example." or > "example."? If the former, then that could be used in a replay attack. it would only be for the latter, since it wouldn't cover the former's name. > I can't see anything in the current drafts that says what one should do > when the Next Domain Name field is the same as the Name, other than at > the zone apex. The latter situation can turn up, e.g. > > foo.example. SOA ... > NS ... > A ... > NSEC foo.example. SOA NS A NSEC ... > > In this case, the NSEC record says, "There are these RRsets for > foo.example, but there is nothing else in or below this zone." i know it seems that way, but actually that's not what it says at all. an nsec in a zone file says nothing. an nsec in a response says that the qname or <qname,qtype> doesn't exist and proves this by signing an NSEC RR that has an owner<--->target range which includes the qname, and an rrtype list that possibly includes the qtype. it is valid for the zone to contain: $ORIGIN foo.example. @ SOA ... NSEC A A NSEC D B A ... D NSEC @ if you ask for <qname=A,qtype#NSEC> you'll get <A NSEC D>. if you ask for <qname=B,qtype=A> you'll get <B A ...>. if you ask for <qname=B,qtype#A> you'll get <A NSEC D> again. if you ask for <qname=C> you'll get <A NSEC D> again. i guess i was just being silly earlier. of course the owner name exists, even if it's synthetic. after all, there's an NSEC there. the target name need not exist, it just has to not be below the owner name in "DNSSEC sort ordering" unless it's wrapping back around to the apex. and it really ought to be an in-baliwick name (at or below the same zone apex as the owner name). geoff sisson proposes that servers who care deeply about zone walking and who can't afford the crypto hardware nec'y for NSEC synthesis just keep a general purpose NSEC sitting around, like one at the first non-apex domain name with a target of the apex, and just use this on all NXDOMAIN responses. this clearly "proves" that all names do not exist, even if they do, but since the only valid use for such an NSEC is to validate an NXDOMAIN or NOERROR response, nobody is actually allowed to care whether the names that NSEC "proves" do not exist, actually don't exist. the danger is replay, but geoff says he's willing to trade that risk off against others. (geoff, i'm not clear on how this proposal applies to NOERROR responses.) the reason i mention all of this is, an NSEC says nothing about zone content, it's only a way to prove the nonexistence of a qname or <qname,qtype>. there can be other existing and populated names within the range given, and that's not a problem. as long as the range given "covers" the qname, then the NSEC is a valid response. i guess the single NSEC RR needed for this is just <@ NSEC @>, right? if so then it's a strange case. <A NSEC A> talks only about a single name "A", but "<@ NSEC @>" talks about all possible names below this apex. that seems like a strange exception case. perhaps <A NSEC A> should also refer to the entire zone, and your <A NSEC \001.A> example (given below) should be used to refer only to "A". > By extension, and I think some explicit wording in the -protocol doc > would be required for this, one could interpret "foo.example. NSEC > foo.example NSEC RRSIG" as meaning that there are no RRSETS for > foo.example, *nor anything below it* other than the NSEC & RRSIG. i would not interpret it that way at all. "empty nonterminals" and all. > Note that -protocol, section 2.3 states: > > An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > RRset at any particular owner name. > > That rule would have to be relaxed for this interpretation, or indeed to > allow NSEC records to be dynamically generated at all. that rule should be relaxed in any case, since it's unenforceable. to show you what i mean, consider that a synthetic NSEC RR doesn't actually exist (and indeed, due to the salting nec'y to prevent key attacks, you might not ever see the same synthesized RRSIG(NSEC) twice, even for same-qname's). if it doesn't exist, then it's not really "at any particular owner name" and so the rule is satisfied even though, between you and me and the lamp post, it's actually not. but if you can't enforce it, it's not a "rule." > Note too that this approach doesn't cater for the situation where > bar.foo.example. exists; the "foo.example. NSEC foo.example. NSEC RRSIG" > response could be replayed to deny the existence of bar.foo.example. > You'd need to respond with something like "foo.example. NSEC > \001.foo.example. NSEC RRSIG" to say "just foo.example, and not anything > below that". ouch. you're right. > So, if one were going to generate signed NSEC records on the fly, one > would have to do something like the following: > > For any name in the zone that exists, at zone build time, generate either: > > <name> NSEC <name> <existing-rrsets> NSEC RRSIG > or > <name> NSEC \001.<name) <existing-rrsets> NSEC RRSIG > > The latter case is required if there are any names below <name>, but > should (must?) not be used if <name> is a delegation point. by the resolution and validation rules as i understand them at this moment, the zone cut would trump the NSEC. in other words you'd get a delegation rather than an NXDOMAIN, and the content of the "latter case" NSEC target would never be relevant. and as before, if you can't enforce it, don't make it a rule. > When asked for a name that does not exist, generate (on the fly), sign > and return: > > <name> NSEC \001.<name> NSEC RRSIG right. > unless one knows that there are no names below <name>, in which case you > could use <name> instead of \001.<name>. maybe. it's possible that "name NSEC name" refers to the entire zone, due to the kind of wrapping that would normally only be done around the apex. > Alternatively, one could generate in all cases: > > <name> NSEC <null> NSEC RRSIG > > where <null> is an as yet undefined magic value that says, "there is no > next domain name field", possibly even using one of the reserved values > of the label type field, e.g a byte value of 0xA0. that's most intriguing. > Is this what others are thinking for dynamic synthesis? Or have I got > it all wrong? other than as noted above, i found your analysis very insightful. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Jun 12 07:48:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25440 for <dnsext-archive@lists.ietf.org>; Sat, 12 Jun 2004 07:48:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZ6vu-000IdL-L6 for namedroppers-data@psg.com; Sat, 12 Jun 2004 11:44:22 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZ6vt-000Icn-0u for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 11:44:21 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id XAA01221 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 23:44:19 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i5CBiJfw057794 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 23:44:19 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: Your message of "Sat, 12 Jun 2004 06:21:57 GMT." <20040612062157.24B4513993@sa.vix.com> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Sat, 12 Jun 2004 23:44:19 +1200 Message-ID: <57793.1087040659@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> wrote: >geoff sisson proposes that servers who care deeply about zone walking and >who can't afford the crypto hardware nec'y for NSEC synthesis just keep a >general purpose NSEC sitting around, like one at the first non-apex domain >name with a target of the apex, and just use this on all NXDOMAIN responses. >this clearly "proves" that all names do not exist, even if they do, but >since the only valid use for such an NSEC is to validate an NXDOMAIN or >NOERROR response, nobody is actually allowed to care whether the names >that NSEC "proves" do not exist, actually don't exist. the danger is >replay, but geoff says he's willing to trade that risk off against others. I'm thinking about that. It gives me the shivers, because I'm not sure about all the corner cases. For example, if a TLD has (excluding RRSIGs): example. SOA ... ... \001.example. NSEC example. NSEC RRSIG ; For denials ... foo.example. NS ns1.example.com. DS ... NSEC \001.foo.example. NS DS NSEC RRSIG ... and an attacker forges: foo.example. NS hostile.example.net. in response to a query for name.foo.example, a security aware resolver might ask <foo.example. DS ?> and be met with the "denial" NSEC: \001.example. NSEC example. NSEC RRSIG "proving" the DS doesn't exist. Now, that should also be taken as proving that the NS doesn't exist as well, invalidating the cached NS records, however, I can see buggy implementations forced by an attacker into doing this in two phases missing that and interpreting the "missing" DS as an unsecured delegation to hostile.example.net. Maybe I'm just too pessimistic. >the reason i mention all of this is, an NSEC says nothing about zone content, >it's only a way to prove the nonexistence of a qname or <qname,qtype>. >there can be other existing and populated names within the range given, >and that's not a problem. as long as the range given "covers" the qname, >then the NSEC is a valid response. I take the point about caching of NSEC records, and agree that at least in the short term, nothing more than the status of the query should be inferred from them. However, the presence of a cached NSEC record indicates the non-existence of the intervening names, and I'd like to see the door kept open to using that information in the future. Consider: if the root has a valid NSEC chain, then a forwarder faced with lots of queries for <something>.localdomain" will soon get: lk. NSEC lr. ... from the root servers and could answer all "localdomain" queries with that. Once all the corner cases are worked out, I think this could be quite valuable. Allowing NSECs to cover existing records would close the door on using cached NSECs in this way, and I think such NSECs should be disallowed from the outset. Personally, I think that DoS avoidance in NSEC synthesis, even if one doesn't have crypto gear aboard, can be achieved to a large degree by queueing all requests for records that don't exist to a low-priority NSEC synthesis process via a fixed-length queue. If the queue is full, just drop new queries on the floor. They'll get retried, probably to other servers, and the worst case is that legitimate lookups for things that don't exist anyway will time out. One would still have static NSECs for things that do exist, which are a lot more important, and appropriate caching of synthesised NSECs could also mitigate such attacks. (I'm figuring that in real life, most legitimate denials will be for a small number of domains, so a usage-weighted cache would mean that queries to common non-existent domains would get cached synthesised NSECs even if the crypto process was totally swamped.) >> By extension, and I think some explicit wording in the -protocol doc >> would be required for this, one could interpret "foo.example. NSEC >> foo.example NSEC RRSIG" as meaning that there are no RRSETS for >> foo.example, *nor anything below it* other than the NSEC & RRSIG. > >i would not interpret it that way at all. "empty nonterminals" and all. By "below" I meant below it in the tree, not in the (ordered) zone. >> For any name in the zone that exists, at zone build time, generate either: >> >> <name> NSEC <name> <existing-rrsets> NSEC RRSIG >> or >> <name> NSEC \001.<name) <existing-rrsets> NSEC RRSIG >> >> The latter case is required if there are any names below <name>, but >> should (must?) not be used if <name> is a delegation point. > >by the resolution and validation rules as i understand them at this moment, >the zone cut would trump the NSEC. in other words you'd get a delegation >rather than an NXDOMAIN, and the content of the "latter case" NSEC target >would never be relevant. and as before, if you can't enforce it, don't >make it a rule. Fair enough. Might pay to make "delegation trumps NSEC" an actual rule tho. >> Alternatively, one could generate in all cases: >> >> <name> NSEC <null> NSEC RRSIG >> >> where <null> is an as yet undefined magic value that says, "there is no >> next domain name field", possibly even using one of the reserved values >> of the label type field, e.g a byte value of 0xA0. > >that's most intriguing. It would make synthesis, or just plain lying, a lot tidier. Using the reserved label code points (01 or 10) would set a precedent, so should be thought through carefully, but if they are introduced as part of the definition of NSEC, shouldn't pose a problem. I think the effect of using 0xA0 would be to make code point 10 effectively mean "arbitrary values"; future developments might find uses for 0xA1 and so-on through to 0xBF. That still leaves code point 01 reserved. Other possibilities for <null> include: - a "magic" name, eg "NULL." Yuck. - The root. Nice and small, but might complicate things with the real root. - A compression pointer with an offset of 0, i.e. 0xC000. This "can't happen" even if compression is allowed (which it isn't in an NSEC), because the offset is relative to the start of the message, which will be the message header. Therefore 0xC000 will never turn up in a real compressed name. I think I prefer the reserved code point approach myself. -- 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 Sat Jun 12 10:48:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04193 for <dnsext-archive@lists.ietf.org>; Sat, 12 Jun 2004 10:48:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZ9hg-000ALf-Rb for namedroppers-data@psg.com; Sat, 12 Jun 2004 14:41:52 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZ9hf-000ALR-K5 for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 14:41:51 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i5CEfph4023155 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 07:41:51 -0700 (PDT) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <KNPW0AQH>; Sat, 12 Jun 2004 07:41:51 -0700 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E5DBDBB@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: namedroppers@ops.ietf.org Subject: RE: NSEC synthesis and the NSEC Next Domain Name field Date: Sat, 12 Jun 2004 07:41:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This thread on dynamic signing of NSEC records is pointless. If you tool up to do this you might as well just sign every response. That would allow the entire protocol stack to be dramatically simplified. You could even go one stage further and do ephemeral key exchange then authenticate the responses via MACs. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Don Stokes > Sent: Saturday, June 12, 2004 7:44 AM > To: namedroppers@ops.ietf.org > Subject: Re: NSEC synthesis and the NSEC Next Domain Name field > > > > Paul Vixie <paul@vix.com> wrote: > >geoff sisson proposes that servers who care deeply about > zone walking and > >who can't afford the crypto hardware nec'y for NSEC > synthesis just keep a > >general purpose NSEC sitting around, like one at the first > non-apex domain > >name with a target of the apex, and just use this on all > NXDOMAIN responses. > >this clearly "proves" that all names do not exist, even if > they do, but > >since the only valid use for such an NSEC is to validate an > NXDOMAIN or > >NOERROR response, nobody is actually allowed to care whether > the names > >that NSEC "proves" do not exist, actually don't exist. the danger is > >replay, but geoff says he's willing to trade that risk off > against others. > > I'm thinking about that. It gives me the shivers, because > I'm not sure > about all the corner cases. For example, if a TLD has (excluding > RRSIGs): > > example. SOA ... > ... > \001.example. NSEC example. NSEC RRSIG ; For denials > ... > foo.example. NS ns1.example.com. > DS ... > NSEC \001.foo.example. NS DS NSEC RRSIG > ... > > and an attacker forges: > > foo.example. NS hostile.example.net. > > in response to a query for name.foo.example, a security aware resolver > might ask <foo.example. DS ?> and be met with the "denial" NSEC: > > \001.example. NSEC example. NSEC RRSIG > > "proving" the DS doesn't exist. Now, that should also be taken as > proving that the NS doesn't exist as well, invalidating the cached NS > records, however, I can see buggy implementations forced by > an attacker > into doing this in two phases missing that and interpreting the > "missing" DS as an unsecured delegation to hostile.example.net. > > Maybe I'm just too pessimistic. > > > >the reason i mention all of this is, an NSEC says nothing > about zone content, > >it's only a way to prove the nonexistence of a qname or > <qname,qtype>. > >there can be other existing and populated names within the > range given, > >and that's not a problem. as long as the range given > "covers" the qname, > >then the NSEC is a valid response. > > I take the point about caching of NSEC records, and agree > that at least > in the short term, nothing more than the status of the query should be > inferred from them. However, the presence of a cached NSEC record > indicates the non-existence of the intervening names, and I'd like to > see the door kept open to using that information in the future. > > Consider: if the root has a valid NSEC chain, then a forwarder faced > with lots of queries for <something>.localdomain" will soon get: > > lk. NSEC lr. ... > > from the root servers and could answer all "localdomain" queries with > that. Once all the corner cases are worked out, I think this could be > quite valuable. > > Allowing NSECs to cover existing records would close the door on using > cached NSECs in this way, and I think such NSECs should be disallowed > from the outset. > > > Personally, I think that DoS avoidance in NSEC synthesis, even if one > doesn't have crypto gear aboard, can be achieved to a large degree > by queueing all requests for records that don't exist to a > low-priority > NSEC synthesis process via a fixed-length queue. If the > queue is full, > just drop new queries on the floor. They'll get retried, > probably to other > servers, and the worst case is that legitimate lookups for things that > don't exist anyway will time out. One would still have > static NSECs for > things that do exist, which are a lot more important, and appropriate > caching of synthesised NSECs could also mitigate such attacks. (I'm > figuring that in real life, most legitimate denials will be > for a small > number of domains, so a usage-weighted cache would mean that > queries to > common non-existent domains would get cached synthesised NSECs even if > the crypto process was totally swamped.) > > > >> By extension, and I think some explicit wording in the > -protocol doc > >> would be required for this, one could interpret "foo.example. NSEC > >> foo.example NSEC RRSIG" as meaning that there are no RRSETS for > >> foo.example, *nor anything below it* other than the NSEC & RRSIG. > > > >i would not interpret it that way at all. "empty > nonterminals" and all. > > By "below" I meant below it in the tree, not in the (ordered) zone. > > >> For any name in the zone that exists, at zone build time, > generate either: > >> > >> <name> NSEC <name> <existing-rrsets> NSEC RRSIG > >> or > >> <name> NSEC \001.<name) <existing-rrsets> NSEC RRSIG > >> > >> The latter case is required if there are any names below > <name>, but > >> should (must?) not be used if <name> is a delegation point. > > > >by the resolution and validation rules as i understand them > at this moment, > >the zone cut would trump the NSEC. in other words you'd get > a delegation > >rather than an NXDOMAIN, and the content of the "latter > case" NSEC target > >would never be relevant. and as before, if you can't > enforce it, don't > >make it a rule. > > Fair enough. Might pay to make "delegation trumps NSEC" an > actual rule > tho. > > >> Alternatively, one could generate in all cases: > >> > >> <name> NSEC <null> NSEC RRSIG > >> > >> where <null> is an as yet undefined magic value that says, > "there is no > >> next domain name field", possibly even using one of the > reserved values > >> of the label type field, e.g a byte value of 0xA0. > > > >that's most intriguing. > > It would make synthesis, or just plain lying, a lot tidier. > > Using the reserved label code points (01 or 10) would set a precedent, > so should be thought through carefully, but if they are introduced as > part of the definition of NSEC, shouldn't pose a problem. I think the > effect of using 0xA0 would be to make code point 10 effectively mean > "arbitrary values"; future developments might find uses for 0xA1 and > so-on through to 0xBF. That still leaves code point 01 reserved. > > Other possibilities for <null> include: > > - a "magic" name, eg "NULL." Yuck. > > - The root. Nice and small, but might complicate things with the real > root. > > - A compression pointer with an offset of 0, i.e. 0xC000. This "can't > happen" even if compression is allowed (which it isn't in an NSEC), > because the offset is relative to the start of the message, which will > be the message header. Therefore 0xC000 will never turn up in a real > compressed name. > > I think I prefer the reserved code point approach myself. > > -- 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Jun 12 12:01:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07417 for <dnsext-archive@lists.ietf.org>; Sat, 12 Jun 2004 12:01:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZAt8-000IHy-1V for namedroppers-data@psg.com; Sat, 12 Jun 2004 15:57:46 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZAt4-000IHI-NB for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 15:57:44 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7205613993 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 15:57:41 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: Message from Don Stokes <don@plugh.daedalus.co.nz> of "Sat, 12 Jun 2004 23:44:19 +1200." <57793.1087040659@toybsd.zl2tnm.gen.nz> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 12 Jun 2004 15:57:41 +0000 Message-Id: <20040612155741.7205613993@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i honestly cannot figure out whether this thread belongs on namedroppers or dnssac@cafax. apologies to our chairs if i'm getting it wrong -- no disrespect is intended. > From: Don Stokes <don@plugh.daedalus.co.nz> > > >... > >since the only valid use for such an NSEC is to validate an NXDOMAIN or > >NOERROR response, nobody is actually allowed to care whether the names > >that NSEC "proves" do not exist, actually don't exist. the danger is > >replay, but geoff says he's willing to trade that risk off against others. > > I'm thinking about that. It gives me the shivers, because I'm not sure > about all the corner cases. For example, if a TLD has (excluding > RRSIGs): > > example. SOA ... > ... > \001.example. NSEC example. NSEC RRSIG ; For denials > ... > foo.example. NS ns1.example.com. > DS ... > NSEC \001.foo.example. NS DS NSEC RRSIG > ... > > and an attacker forges: > > foo.example. NS hostile.example.net. > > in response to a query for name.foo.example, a security aware resolver > might ask <foo.example. DS ?> and be met with the "denial" NSEC: > > \001.example. NSEC example. NSEC RRSIG > > "proving" the DS doesn't exist. yes. that's part of what i meant by "replay attacks that geoff says he's willing to live with." like asimov's rules of robotics, everything depends on everything else, and if you take out something that appears innocuous, it'll probably have many unforeseen consequences, some of which are Deep. (i think it's becoming clear to me that the -trans doco won't be amended to include geoff's "one or two precomputed NSECs used for everything" scenario as one of its alternatives.) > Now, that should also be taken as proving > that the NS doesn't exist as well, invalidating the cached NS records, > however, I can see buggy implementations forced by an attacker into doing > this in two phases missing that and interpreting the "missing" DS as an > unsecured delegation to hostile.example.net. > > Maybe I'm just too pessimistic. pessimism in the pursuit of dns protocol change, or any security protocol, or in any of the former involving the latter, is a wonderful virtue. > I take the point about caching of NSEC records, and agree that at least > in the short term, nothing more than the status of the query should be > inferred from them. However, the presence of a cached NSEC record > indicates the non-existence of the intervening names, no, it doesn't. in the as-yet-undocumented DLV we use NSEC that way but only in a specific part of the domain name tree where it's known to be true. but generally in dnssec-bis, it is not the case that names in the range from an NSEC's owner to an nsec's target are being asserted as nonexistent. all an NSEC is doing is proving that the qname or <qname,qtype> is nonexistent. > and I'd like to > see the door kept open to using that information in the future. many of us would. but -bis isn't written that way, and i don't expect that we'll see a bit added to the NSEC RR saying "by the way, it's not just the <qname> or <qname,qtype> that doesn't exist, but all names after the owner and up to but not including the target also don't exist". like many good ideas, this one comes too late in the process. a half dozen times now, we have stopped the presses and rewritten this newspaper to add recent events; the result is that something that should have taken 3 years has taken 10 (and counting). > Consider: if the root has a valid NSEC chain, then a forwarder faced > with lots of queries for <something>.localdomain" will soon get: > > lk. NSEC lr. ... > > from the root servers and could answer all "localdomain" queries with > that. Once all the corner cases are worked out, I think this could be > quite valuable. again, i agree, but there are dozens of corner cases that would have to be discovered and illuminated and documented before it could be used that way, and as good as this idea is, i want to start deploying dnssec-bis in 2004. so, like many other good ideas, it'll have to wait for dnssec-ter or dns-bis. > Allowing NSECs to cover existing records would close the door on using > cached NSECs in this way, and I think such NSECs should be disallowed > from the outset. apart from all other reasons to the contrary, the fact that this is not enforceable, or even detectable as an invalid condition, means that it's not a useful protocol rule. right now a cached NSEC is usable for sending out an nxdomain from cache only if the <qname> or <qname,qtype> being answered is the same as the one that caused the NSEC to become cached in the first place, and that's all we can do and still begin -bis deployment in 2004. > Personally, I think that DoS avoidance in NSEC synthesis, even if one > doesn't have crypto gear aboard, can be achieved to a large degree > by queueing all requests for records that don't exist to a low-priority > NSEC synthesis process via a fixed-length queue. If the queue is full, > just drop new queries on the floor. They'll get retried, probably to other > servers, and the worst case is that legitimate lookups for things that > don't exist anyway will time out. this represents "modality" and it means that an attacker who wants some victim (who is not your name server) to be unable to prove the nonexistence of some name the attacker cares about, has to launch a separate early-stage attack on your zone's name servers in order to put them into "congestion mode" where queries about nonexistent names are dropped, before they launch their real attack which depends on their real victim not being able to find out that some name of the attacker's does not exist. now, while this is true of ddos in general, and a congestion attack on the upstream network links of your zone's name servers would have a similar effect, there are two important differences. one is, your zone's name server operators would not be certain that they'd been attacked. two is, normal positive questions asked during this "congestion mode" attack would still be answered. i can think of a couple of scenarios where a bad guy could benefit from this modality. we can't institutionalize it. > >by the resolution and validation rules as i understand them at this moment, > >the zone cut would trump the NSEC. in other words you'd get a delegation > >rather than an NXDOMAIN, and the content of the "latter case" NSEC target > >would never be relevant. and as before, if you can't enforce it, don't > >make it a rule. > > Fair enough. Might pay to make "delegation trumps NSEC" an actual rule tho. that's not how this works. if the "rule" is implicit or emergent based on other rules, then it's a "note" not a "rule". just to make sure people can reason their way to the side effects and have successfully done so. > >> Alternatively, one could generate in all cases: > >> > >> <name> NSEC <null> NSEC RRSIG > >> > >> where <null> is an as yet undefined magic value that says, "there is no > >> next domain name field", possibly even using one of the reserved values > >> of the label type field, e.g a byte value of 0xA0. > > > >that's most intriguing. > > It would make synthesis, or just plain lying, a lot tidier. > > Using the reserved label code points (01 or 10) would set a precedent, > so should be thought through carefully, but if they are introduced as > part of the definition of NSEC, shouldn't pose a problem. if done, this would use one of the EDNS extended label types (see RFC2671). and note that the "0 1" nonextended label type is allocated to EDNS0 now. > ... > I think I prefer the reserved code point approach myself. i think that this is definitely the part of the thread that belongs on the other mailing list (dnssec@cafax) since it has nothing to do with -bis. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Jun 12 13:39:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11478 for <dnsext-archive@lists.ietf.org>; Sat, 12 Jun 2004 13:39:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZCNc-0000pk-5v for namedroppers-data@psg.com; Sat, 12 Jun 2004 17:33:20 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZCNa-0000p7-WC for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 17:33:19 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5CHWHfk013941; Sat, 12 Jun 2004 13:32:27 -0400 Received: from lapdancer (asynce003.nist.gov [129.6.31.3]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i5CHVq4A002012; Sat, 12 Jun 2004 13:31:53 -0400 (EDT) Message-ID: <000001c450a3$4f190e70$031f0681@lapdancer> From: "Scott Rose" <scottr@nist.gov> To: "David Blacka" <davidb@verisignlabs.com>, <namedroppers@ops.ietf.org> References: <40BDCD26.4050808@ripe.net> <20040603152327.6de24e15.olaf@ripe.net> <200406091146.01973.davidb@verisignlabs.com> <200406101710.24434.davidb@verisignlabs.com> Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Fri, 11 Jun 2004 21:52:31 -0400 Organization: NIST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I can live with this text in place of the current wording in protocol draft section 4.5. It is more straight forward. Scott ----- Original Message ----- From: "David Blacka" <davidb@verisignlabs.com> To: <namedroppers@ops.ietf.org> Sent: Thursday, June 10, 2004 5:10 PM Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks > On Wednesday 09 June 2004 11:46 am, David Blacka wrote: > > > I still think a better solution here is to explain what caches SHOULD NOT > > (or MUST NOT) do. If I can, I will try and submit language like this, and > > the WG can decide which it prefers. > > Here is what I have come up with: > > The use of DNSSEC exposes more information about a zone than was > previously available to resolvers. In particular, DNSSEC exposes > the existence of wildcard records within a zone via RRSIG records, > and non-existence of names via NSEC records. To avoid unexpected > and undesirable side-effects, a security-aware resolver SHOULD NOT > make special use of this additional information. > > Security-aware resolvers SHOULD NOT use received NSEC records for > negative caching purposes beyond that specified by [RFC 2308]. For > example, if a resolver receives an NSEC record as part of a response > indicating that a given QNAME did not exist, the resolver SHOULD > only return that NSEC record when queried directly for the NSEC > record by name (e.g., via QTYPE=NSEC or QTYPE=ANY), or when > answering a query for the original QNAME, QCLASS, and QTYPE. > > In addition, security-aware resolvers SHOULD NOT attempt to perform > wildcard synthesis on behalf of a different authoritative server. > > What do you folks 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Jun 12 14:12:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13460 for <dnsext-archive@lists.ietf.org>; Sat, 12 Jun 2004 14:12:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZCwk-0004LZ-CS for namedroppers-data@psg.com; Sat, 12 Jun 2004 18:09:38 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZCwi-0004L2-26 for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 18:09:36 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BZCwh-0008KI-00 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 20:09:35 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 20:09:34 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 20:09:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Sat, 12 Jun 2004 20:09:30 +0200 Lines: 33 Message-ID: <iluk6yc8x7p.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <200406111418.12522.davidb@verisignlabs.com> <ilun039bwx4.fsf@latte.josefsson.org> <200406111811.34513.davidb@verisignlabs.com> <iluekolbrzl.fsf@latte.josefsson.org> <423968D0-BC14-11D8-BB81-000A95CC77E2@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:/+hBdsAiRZyE99Mk8xJcL1ta3Qo= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka <davidb@verisignlabs.com> writes: > On Jun 11, 2004, at 7:21 PM, Simon Josefsson wrote: > >> David Blacka <davidb@verisignlabs.com> writes: >> >>> As far as I can tell, the current result of publishing a signed >>> zone with all >>> DNSKEYs of protocol = 4 is that resolvers who think the zone should be >>> secured will conclude that every answer from that zone is BOGUS. >> >> By BOGUS, do you mean that since no valid DNSKEY were found, and >> consequently no RRSIGs could be verified, returned data is considered >> insecure? Or are you saying a DNS cache, quering for >> (foo.example,IN,SOA) and receiving: > > I believe, given the current language in the DNSSECbis documents, > that SERVFAIL would be returned. I could be wrong. At best, > resolver behavior in this situation is ambiguous, I think. Which section do base this on? Records 2.1.2 says: The Protocol Field MUST have value 3 and the DNSKEY RR MUST be treated as invalid during signature verification if found to be some value other than 3. This is rather specific as to which situations the DNSKEY should be regarded as invalid. That imply that it shouldn't be invalid for other situations, otherwise the qualification is unnecessary. But I agree it is ambiguous at best. 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 Sat Jun 12 17:22:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23574 for <dnsext-archive@lists.ietf.org>; Sat, 12 Jun 2004 17:22:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZFtr-000Pa1-3N for namedroppers-data@psg.com; Sat, 12 Jun 2004 21:18:51 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZFtq-000PZo-2V for namedroppers@ops.ietf.org; Sat, 12 Jun 2004 21:18:50 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i5CLIhrj019211 for <namedroppers@ops.ietf.org>; Sat, 12 Jun 2004 17:18:43 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040612171722.02d52fa0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Sat, 12 Jun 2004 17:18:43 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: <20040612155741.7205613993@sa.vix.com> References: <20040612155741.7205613993@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:57 12/06/2004, Paul Vixie wrote: >i honestly cannot figure out whether this thread belongs on namedroppers >or dnssac@cafax. apologies to our chairs if i'm getting it wrong -- no >disrespect is intended. dnssec@cafax.se please. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Jun 13 00:44:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10550 for <dnsext-archive@lists.ietf.org>; Sun, 13 Jun 2004 00:44:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZMmi-000CSG-Tp for namedroppers-data@psg.com; Sun, 13 Jun 2004 04:39:56 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZMmh-000CS1-00 for namedroppers@ops.ietf.org; Sun, 13 Jun 2004 04:39:56 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.11/8.12.11) with ESMTP id i5D4dHAi008175; Sun, 13 Jun 2004 06:39:45 +0200 (CEST) (envelope-from roy@dnss.ec) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BEkbCp012237; Fri, 11 Jun 2004 16:46:37 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.11/8.12.11/Debian-3) with ESMTP id i5BEkb8C012234; Fri, 11 Jun 2004 16:46:37 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Fri, 11 Jun 2004 16:46:37 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@elektron.atoom.net To: Ben Laurie <ben@algroup.co.uk> cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <40C9C10D.8080804@algroup.co.uk> Message-ID: <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> <40C9C10D.8080804@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 11 Jun 2004, Ben Laurie wrote: > Roy Arends wrote: > > > On Fri, 11 Jun 2004, Ben Laurie wrote: > > > > > >>Consensus on that point would presumably require some people willing to > >>implement it - are there any? > > > > To implement what ? > > > > To implement the short-term solution which doesn't need ANY ietf-wg > > action, consensus and so forth, you'd simply buy your feature from ISC or > > NLnet Labs. > > And decide that you don't care that you are spreading your private key > all over the place, and find or build a crypto accelerator that does > what you need. This is FUD. Did you forget that private keys or secret keys are configured in online machines to allow for secure zone-transfers ? Did you forget that SSL requires an online private key ? Did you forget that SSH requires an online private key ? What is then so enourmously special about SIG(NSEC) private keys. As an aside, Do you understand that the trans- draft and dnssec-ter draft is done SPECIFICALLY to accomodate the needs of Nominet and other interested in defense against zone-traversal IN A NON-DESTRUCTIVE way ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Jun 13 06:45:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02993 for <dnsext-archive@lists.ietf.org>; Sun, 13 Jun 2004 06:45:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZSQE-000GT0-Dh for namedroppers-data@psg.com; Sun, 13 Jun 2004 10:41:06 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZSQD-000GSh-7A for namedroppers@ops.ietf.org; Sun, 13 Jun 2004 10:41:05 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 43AC81FF845; Sun, 13 Jun 2004 10:41:04 +0000 (GMT) Message-ID: <40CC2F3F.40708@algroup.co.uk> Date: Sun, 13 Jun 2004 11:41:03 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> Cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> <40C9C10D.8080804@algroup.co.uk> <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> In-Reply-To: <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Fri, 11 Jun 2004, Ben Laurie wrote: > > >>Roy Arends wrote: >> >> >>>On Fri, 11 Jun 2004, Ben Laurie wrote: >>> >>> >>> >>>>Consensus on that point would presumably require some people willing to >>>>implement it - are there any? >>> >>>To implement what ? >>> >>>To implement the short-term solution which doesn't need ANY ietf-wg >>>action, consensus and so forth, you'd simply buy your feature from ISC or >>>NLnet Labs. >> >>And decide that you don't care that you are spreading your private key >>all over the place, and find or build a crypto accelerator that does >>what you need. > > This is FUD. > > Did you forget that private keys or secret keys are configured in online > machines to allow for secure zone-transfers ? Only on one machine, and that one I can control carefully. > Did you forget that SSL > requires an online private key ? Irrelevant: different threat model. > Did you forget that SSH requires an > online private key ? It does not require a private key that can be used without my intervention, and again, its a different threat model. > What is then so enourmously special about SIG(NSEC) > private keys. I'm not really interested in a huge digression about the design of secure systems, suffice it to say that Nominet has a variety of reasons to not want to deploy private keys on its DNS secondaries. > As an aside, > > Do you understand that the trans- draft and dnssec-ter draft is done > SPECIFICALLY to accomodate the needs of Nominet and other interested in > defense against zone-traversal IN A NON-DESTRUCTIVE way ? Of course I do - but this doesn't mean I have to agree with the first suggestion I hear, does it? I still prefer the one/two record "deny everything" solution. 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 Mon Jun 14 03:24:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10689 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 03:24:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZlfR-000Bma-1l for namedroppers-data@psg.com; Mon, 14 Jun 2004 07:14:05 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZlfO-000BmF-4d for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 07:14:04 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 89EAEAC8D; Mon, 14 Jun 2004 09:14:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 6F70FAC8B; Mon, 14 Jun 2004 09:14:00 +0200 (CEST) Date: Mon, 14 Jun 2004 09:14:00 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Ben Laurie <ben@algroup.co.uk> Cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <40CC2F3F.40708@algroup.co.uk> Message-ID: <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> <40C9C10D.8080804@algroup.co.uk> <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> <40CC2F3F.40708@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 13 Jun 2004, Ben Laurie wrote: > Roy Arends wrote: > > > This is FUD. > > > > Did you forget that private keys or secret keys are configured in online > > machines to allow for secure zone-transfers ? > > Only on one machine, and that one I can control carefully. Zone-transfers require secret keys at both ends of the transfer. > > Did you forget that SSL > > requires an online private key ? > > Irrelevant: different threat model. It is not irrelevant wrt exposure, configuration, management and control. > > Did you forget that SSH requires an > > online private key ? > > It does not require a private key that can be used without my > intervention, and again, its a different threat model. Same joke, different name. > > What is then so enourmously special about SIG(NSEC) > > private keys. > > I'm not really interested in a huge digression about the design of > secure systems, suffice it to say that Nominet has a variety of reasons > to not want to deploy private keys on its DNS secondaries. Ah, speaking for Nominet again. Handwaving like this does not help in gaining sympathy and support for one's issues. ymmv. > > As an aside, > > > > Do you understand that the trans- draft and dnssec-ter draft is done > > SPECIFICALLY to accomodate the needs of Nominet and other interested in > > defense against zone-traversal IN A NON-DESTRUCTIVE way ? > > Of course I do - but this doesn't mean I have to agree with the first > suggestion I hear, does it? > > I still prefer the one/two record "deny everything" solution. .... This says it all. Please go read the dnssec docs. In short: with that solution, one could spoof responses to "deny everything" under co.uk., AUTHENTICATED existing names, signed and existing names, 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 Mon Jun 14 03:37:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11391 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 03:37:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZlxB-000DVT-1P for namedroppers-data@psg.com; Mon, 14 Jun 2004 07:32:25 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZlx9-000DVD-Ll for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 07:32:23 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 19E6E51DD8; Mon, 14 Jun 2004 09:32:23 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id BB0DF51CEE; Mon, 14 Jun 2004 09:32:22 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5E7WM8r031531; Mon, 14 Jun 2004 09:32:22 +0200 Date: Mon, 14 Jun 2004 09:32:22 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: David Blacka <davidb@verisignlabs.com> Cc: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Message-Id: <20040614093222.2c3317df.olaf@ripe.net> In-Reply-To: <200406101710.24434.davidb@verisignlabs.com> References: <40BDCD26.4050808@ripe.net> <20040603152327.6de24e15.olaf@ripe.net> <200406091146.01973.davidb@verisignlabs.com> <200406101710.24434.davidb@verisignlabs.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.005032 / 0.0 / 0.0 / disabled X-RIPE-Signature: 311df491ea9f15b9cb14cee603de0094 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Here is what I have come up with: > > The use of DNSSEC exposes more information about a zone than was > previously available to resolvers. In particular, DNSSEC exposes > the existence of wildcard records within a zone via RRSIG records, > and non-existence of names via NSEC records. To avoid unexpected > and undesirable side-effects, a security-aware resolver SHOULD NOT > make special use of this additional information. > > Security-aware resolvers SHOULD NOT use received NSEC records for > negative caching purposes beyond that specified by [RFC 2308]. For > example, if a resolver receives an NSEC record as part of a response > indicating that a given QNAME did not exist, the resolver SHOULD > only return that NSEC record when queried directly for the NSEC > record by name (e.g., via QTYPE=NSEC or QTYPE=ANY), or when > answering a query for the original QNAME, QCLASS, and QTYPE. > > In addition, security-aware resolvers SHOULD NOT attempt to perform > wildcard synthesis on behalf of a different authoritative server. I like this. But we may want to also put language in that loosens up the reuse of an NSEC RR to proof NODATA (I remember Mark Andrews arguing for this). Maybe we can add one sentence to make the point that when an NSEC RR is provided as a proof for (RCODE=NOERROR && empty answer) (NODATA) it MAY be reused for other queries to proof the nonexistence of types for the same QNAME, QCLASS as that it was originally received. --Olaf No Hats ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 05:04:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15325 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 05:04:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZnKG-000Mma-Kt for namedroppers-data@psg.com; Mon, 14 Jun 2004 09:00:20 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZnKE-000Mlk-VG for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 09:00:19 +0000 Received: from [192.168.100.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 8DC301FDCB; Mon, 14 Jun 2004 10:00:17 +0100 (BST) Date: Mon, 14 Jun 2004 10:00:14 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Roy Arends <roy@dnss.ec>, Ben Laurie <ben@algroup.co.uk> Cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org>, Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <8D46730BFE093182A8F11F26@[192.168.100.5]> In-Reply-To: <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> <40C9C10D.8080804@algroup.co.uk> <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> <40CC2F3F.40708@algroup.co.uk> <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 14 June 2004 09:14 +0200 Roy Arends <roy@dnss.ec> wrote: > In short: with that solution, one could spoof responses to "deny > everything" under co.uk., AUTHENTICATED existing names, signed and > existing names, etc. & how is that worse than the likely alternative of "do nothing"? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 05:15:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15706 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 05:15:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZnVL-000OTA-80 for namedroppers-data@psg.com; Mon, 14 Jun 2004 09:11:47 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZnVK-000OSj-3x for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 09:11:46 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id C3F30AC8D; Mon, 14 Jun 2004 11:11:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 999ABAC8B; Mon, 14 Jun 2004 11:11:44 +0200 (CEST) Date: Mon, 14 Jun 2004 11:11:44 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Alex Bligh <alex@alex.org.uk> Cc: Ben Laurie <ben@algroup.co.uk>, Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <8D46730BFE093182A8F11F26@[192.168.100.5]> Message-ID: <Pine.BSO.4.56.0406141103540.6585@trinitario.schlyter.se> References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> <40C9C10D.8080804@algroup.co.uk> <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> <40CC2F3F.40708@algroup.co.uk> <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> <8D46730BFE093182A8F11F26@[192.168.100.5]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 14 Jun 2004, Alex Bligh wrote: > --On 14 June 2004 09:14 +0200 Roy Arends <roy@dnss.ec> wrote: > > > In short: with that solution, one could spoof responses to "deny > > everything" under co.uk., AUTHENTICATED existing names, signed and > > existing names, etc. > > & how is that worse than the likely alternative of "do nothing"? Far worse. With "do nothing" (vanilla-dns) there is the same level of spoofing/MiM behaviour wrt denial, though with the hack above, there is a signed record that must be interpreted as "deny everything", which is signed by, yes, nominet. The effect is the same, though in the latter case of "deny everything" there is a signature, created by a DNSKEY, which is bound to Nominet. Now see (for instance) algroup.co.uk authoritatively and authenticatebly denied by a record, signed by Nominet.... I also like the Do Nothing alternative, and we'll include your text in -01. 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 Mon Jun 14 05:44:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17007 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 05:44:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZnvF-0001Ye-3e for namedroppers-data@psg.com; Mon, 14 Jun 2004 09:38:33 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZnvD-0001YJ-Vm for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 09:38:32 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 3CC6C51D77; Mon, 14 Jun 2004 11:38:31 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id B1A8951E8B; Mon, 14 Jun 2004 11:38:30 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5E9cU8r010144; Mon, 14 Jun 2004 11:38:30 +0200 Date: Mon, 14 Jun 2004 11:38:30 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Simon Josefsson <jas@extundo.com> Cc: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Message-Id: <20040614113830.633a56ea.olaf@ripe.net> In-Reply-To: <iluekolbrzl.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <200406111418.12522.davidb@verisignlabs.com> <ilun039bwx4.fsf@latte.josefsson.org> <200406111811.34513.davidb@verisignlabs.com> <iluekolbrzl.fsf@latte.josefsson.org> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: * X-RIPE-Spam-Status: N 0.064287 / 1.0 / 0.0 / disabled X-RIPE-Signature: 7c905be9441e07afa16b297a9cda409f X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 12 Jun 2004 01:21:50 +0200 Simon Josefsson <jas@extundo.com> wrote: > David Blacka <davidb@verisignlabs.com> writes: > > I will agree that current validators will reject DNSKEY RRs with non-3 > > protocol fields. That is the intent as I see it, anyway. > > We agree here. > we all do :-) ... > > As far as I can tell, the current result of publishing a signed zone with all > > DNSKEYs of protocol = 4 is that resolvers who think the zone should be > > secured will conclude that every answer from that zone is BOGUS. > > By BOGUS, do you mean that since no valid DNSKEY were found, and > consequently no RRSIGs could be verified, returned data is considered > insecure? Or are you saying a DNS cache, quering for > (foo.example,IN,SOA) and receiving: > > foo.example SOA ... > foo.example RRSIG SOA ... > foo.example NSEC ... > foo.example DNSKEY ...protocol field 4... > > should reject the entire response, and return SEVRFAIL, NOERROR or > something to the client? I see no ground for that behaviour. > Instead, I believe the resolver should return the requested RR. It is > this behaviour that I find useful in an extension. It allow for a > graceful upgrade to a DNSSECter where the failure mode is a > degredation to vanilla DNS, instead of error states. > What happens is really dependend on "how" you enter the zone. If you follow a chain of trust that says "foo.example" is supposed to be secure in "protocol 3" then, by not having a "protocol 3" key to verify against you have to treat the zone as bogus. If you do not have a secure entry point (following a chain of trust of via a configured trustanchor) into the zone than the keys really are of no use and it does not matter if they are of proto 3 or 4. And your data should pass through as not being validated. IMHO this exactly as specified by the language in "proto". Protocol 4 keys are not to be used for validation: If a DS RR[*] points to a protocol 4 key than the DS RR tells us foo.example is secure, but since we have a protocol 4 key we cannot validate. Not being able to validate in a secure zone implies bogus results. > And do you have any thoughts on the actual proposed text change that > started this thread? I have no wish to change the Protocol Field. I > have used the Protocol Field, in this thread, as an example of an > already specified extension mechanism, since people appeared to think > that my proposed change wanted to introduce a new extension mechanism. > I want to introduce a cleaner way to specify the extensions, compared > to using the protocol field. IMHO, without degradation attack prevention you cannot use the field, nor the flag bits. --Olaf [*] I assume here that the DS was part of a protocol 3 chain of trust i.e. signed by a protocol 3 KEY. If the whole chain of trust is protocol 4 than the behaviour is unspecified. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 05:50:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17309 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 05:50:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZo3L-0002Mo-Uz for namedroppers-data@psg.com; Mon, 14 Jun 2004 09:46:55 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZo3K-0002MN-IA for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 09:46:55 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id E64081FF848; Mon, 14 Jun 2004 09:46:52 +0000 (GMT) Message-ID: <40CD740C.1020403@algroup.co.uk> Date: Mon, 14 Jun 2004 10:46:52 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks References: <40BDCD26.4050808@ripe.net> <20040603152327.6de24e15.olaf@ripe.net> <200406091146.01973.davidb@verisignlabs.com> <200406101710.24434.davidb@verisignlabs.com> <20040614093222.2c3317df.olaf@ripe.net> In-Reply-To: <20040614093222.2c3317df.olaf@ripe.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: >>Here is what I have come up with: >> >> The use of DNSSEC exposes more information about a zone than was >> previously available to resolvers. In particular, DNSSEC exposes >> the existence of wildcard records within a zone via RRSIG records, >> and non-existence of names via NSEC records. To avoid unexpected >> and undesirable side-effects, a security-aware resolver SHOULD NOT >> make special use of this additional information. >> >> Security-aware resolvers SHOULD NOT use received NSEC records for >> negative caching purposes beyond that specified by [RFC 2308]. For >> example, if a resolver receives an NSEC record as part of a response >> indicating that a given QNAME did not exist, the resolver SHOULD >> only return that NSEC record when queried directly for the NSEC >> record by name (e.g., via QTYPE=NSEC or QTYPE=ANY), or when >> answering a query for the original QNAME, QCLASS, and QTYPE. >> >> In addition, security-aware resolvers SHOULD NOT attempt to perform >> wildcard synthesis on behalf of a different authoritative server. > > > > I like this. > > But we may want to also put language in that loosens up the reuse of > an NSEC RR to proof NODATA (I remember Mark Andrews arguing for this). > > Maybe we can add one sentence to make the point that when an NSEC RR > is provided as a proof for (RCODE=NOERROR && empty answer) (NODATA) it > MAY be reused for other queries to proof the nonexistence of types for > the same QNAME, QCLASS as that it was originally received. Just to be clear: you mean queries with the same QNAME and QCLASS but different QTYPE can be satisfied by a cached NODATA response? A consequence of this for anyone using the NSEC kludge recently discussed is that the kludge MUST NOT be used as a response for a domain which exists but does not have the requested QTYPE - instead a correct NSEC record must be returned. And a consequence of that is that the NSEC record will need to have a faked next domain. Sigh. But at least this is workable, unlike previous proposals that have included faked next domains, since the NSEC will only be produced in response to a query involving its owner name. 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 Mon Jun 14 06:03:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18035 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 06:03:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZoGp-0004TU-Kc for namedroppers-data@psg.com; Mon, 14 Jun 2004 10:00:51 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZoGo-0004T9-HE for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 10:00:50 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id EBF4651EB4; Mon, 14 Jun 2004 12:00:49 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7D5E451E97; Mon, 14 Jun 2004 12:00:49 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5EA0n8r019428; Mon, 14 Jun 2004 12:00:49 +0200 Date: Mon, 14 Jun 2004 12:00:49 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Edward Lewis <edlewis@arin.net> Cc: jas@extundo.com, namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Message-Id: <20040614120049.59b58a4e.olaf@ripe.net> In-Reply-To: <a06020404bcef7c93b348@[192.136.136.83]> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000256 / 0.0 / 0.0 / disabled X-RIPE-Signature: 72df0047582445f8935a7108636b99fe X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > >So you have to ordonate something like "If any of the secure entry poin > I have to admit that "ordonate" is not in my version of the English > dictionary. ;) And I can't find a verb that is close to the spelling > you have. (I.e., huh?) Oh... it sounded English to me :-). I ment "ordain" ("verordoneren" in Dutch, both seem to have the same French etymology) So you have to ordain something like ... "If andy of the secure entry points > >into the zone (either the DS RRs or trust anchors) points to DNSKEY > >RRs in the apex with all zero values in bits 8-14 than any RRset in > >the zone MUST have at least one RRSIG generated by an all-zero keys, > >RRsets not signed by an RRSIG generated by an all-zero key are to be > >treated as bogus." > > > >In addition you have to say that if you find non-zero bit keys you treat > >the zone as insecure. > > > >"If none the secure entry point into the zone point to DNSKEY RRs in > >the apex with non-zero values in bits 8-14 than the zone may be treated as > >insecure." > > I don't think that's the right "rule." > > Let's say that my verifier is able to understand the security of the > zone example.com. I.e., I understand the semantics of all the set > bits in the zone's DNSKEY's, RRSIG's, NSEC's. > > Asking for "www.newzone.example.com." A (assuming it's in a > sub-delegation), I will see this in the response: > > Answer > Authority > newzone.example.com. NS ns1.newzone.example.com. > newzone.example.com. NS ns2.newzone.example.com. > newzone.example.com. DS <key 1> > newzone.example.com. DS <key 2> > newzone.example.com. RRSIG(DS) > Additional > > I can validate the RRSIG above, proving that there's a DS key. Ack.. > > When I issue the same answer to ns1.newzone.example.com., I get: > > Answer > www.newzone.example.com A 222.333.444.555 > www.newzone.example.com RRSIG(A) > Authority > Additional > newzone.example.com. DNSKEY <key 1> > newzone.example.com. DNSKEY <key 2> > newzone.example.com. RRSIG(DNSKEY) > > What' happens when I find that key's 1 and 2 have bits set that I > can't understand? Should I be content that these keys match the DS > hashes, now concluding that there are no acceptable keys and > therefore I can reasonable continue on assuming there is no security > to be had? (Maybe so, maybe not.) > Aha... this is actually a different issue. This is, if I understand you well, how you handle proto 4 keys if you only know about proto 3 (I was more worried about what happens if you know of both, ie the effect during transition). Back to your example. For argument sake let us say that keys 1 and 2 have their protocol field set to 4. And that the DS RR was signed with a protocol 3 key. A DNSSEC-bis validator cannot validate with these keys and since the zone is supposed to be secure, by virtue of the DS RRs this zone is to be marked bogus. (I the validator cannot determine the selfsignature over the keyset the sone should be marked bogus.) The language I tried to provide was to prevent 'degradation attacks'. That is, you have both protocol keys in your keyset and an attacker is stripping DNSSIGs of one of both types. For algorithm degradation attacks we have spend a lot of time in preventing this. The fact that there is an algorithm field in DS helps, I am not sure if it is crucial in preventinon of degradation attacks. Although I thought that minor language modifications would help I am changing my mind...I am starting to get more and more convinced that trying to modify flags and protocol fields now opens up a whole set of security considerations that will take far to much time to solve. I am now in favour of closing this lid and not touching protocol or the flags in DNSSEC-bis and live with them as is. -- Olaf No hats. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 06:42:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20348 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 06:42:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZopg-0008c1-8m for namedroppers-data@psg.com; Mon, 14 Jun 2004 10:36:52 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZopc-0008bC-5N for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 10:36:49 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BZopa-0008Hn-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 12:36:47 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 12:36:46 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 12:36:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Mon, 14 Jun 2004 12:36:42 +0200 Lines: 76 Message-ID: <iluacz65sud.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <200406111418.12522.davidb@verisignlabs.com> <ilun039bwx4.fsf@latte.josefsson.org> <200406111811.34513.davidb@verisignlabs.com> <iluekolbrzl.fsf@latte.josefsson.org> <20040614113830.633a56ea.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:UrtYJKg95A+S7LwJ4ctyFvgj1IA= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> writes: >> > As far as I can tell, the current result of publishing a signed zone with all >> > DNSKEYs of protocol = 4 is that resolvers who think the zone should be >> > secured will conclude that every answer from that zone is BOGUS. >> >> By BOGUS, do you mean that since no valid DNSKEY were found, and >> consequently no RRSIGs could be verified, returned data is considered >> insecure? Or are you saying a DNS cache, quering for >> (foo.example,IN,SOA) and receiving: >> >> foo.example SOA ... >> foo.example RRSIG SOA ... >> foo.example NSEC ... >> foo.example DNSKEY ...protocol field 4... >> >> should reject the entire response, and return SEVRFAIL, NOERROR or >> something to the client? I see no ground for that behaviour. >> Instead, I believe the resolver should return the requested RR. It is >> this behaviour that I find useful in an extension. It allow for a >> graceful upgrade to a DNSSECter where the failure mode is a >> degredation to vanilla DNS, instead of error states. >> > > What happens is really dependend on "how" you enter the zone. > > If you follow a chain of trust that says "foo.example" is supposed to > be secure in "protocol 3" then, by not having a "protocol 3" key to > verify against you have to treat the zone as bogus. Again, what do you mean by "bogus" in this context? I believe it should mean "insecure", i.e. downgrade to vanilla DNS. But Scott Rose thought SERVFAIL should be returned here. If there isn't agreement on the interpretation, perhaps this should be clarified. > If you do not have a secure entry point (following a chain of trust of > via a configured trustanchor) into the zone than the keys really are > of no use and it does not matter if they are of proto 3 or 4. And your > data should pass through as not being validated. Right. But I believe they should pass through. There appear to be disagreement on that. > IMHO this exactly as specified by the language in "proto". Protocol 4 > keys are not to be used for validation: If a DS RR[*] points to a > protocol 4 key than the DS RR tells us foo.example is secure, but > since we have a protocol 4 key we cannot validate. Not being able to > validate in a secure zone implies bogus results. "Bogus results" is not well defined. Do you mean resolvers are permitted to return anything it want? >> And do you have any thoughts on the actual proposed text change that >> started this thread? I have no wish to change the Protocol Field. I >> have used the Protocol Field, in this thread, as an example of an >> already specified extension mechanism, since people appeared to think >> that my proposed change wanted to introduce a new extension mechanism. >> I want to introduce a cleaner way to specify the extensions, compared >> to using the protocol field. > > > IMHO, without degradation attack prevention you cannot use the field, > nor the flag bits. I believe you can. Send two DNSKEYs: foo.example IN DNSKEY proto=3 ... foo.example IN DNSKEY proto=4 ... Are you saying that a conforming DNSSECbis resolver would reject this response and return SERVFAIL? Or should it ignore the unrecognized second DNSKEY, validate the data using the proto=3 key and (assuming verification succeed) proceed as normal? 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 Mon Jun 14 08:59:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29331 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 08:59:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZqy9-000Nm5-Aj for namedroppers-data@psg.com; Mon, 14 Jun 2004 12:53:45 +0000 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZqy8-000Nlf-32 for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 12:53:44 +0000 Received: from notes.denic.de ([192.168.0.77]) by smtp.denic.de with esmtp id 1BZqy6-0007gy-M7; Mon, 14 Jun 2004 14:53:42 +0200 In-Reply-To: <6.1.0.6.2.20040611152812.02fc4a08@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com> Cc: namedroppers@ops.ietf.org Subject: Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Marcos Sanz/Denic <sanz@denic.de> Message-ID: <OFABD5916A.F2B9E156-ONC1256EB3.0043AE64-C1256EB3.0046D0FE@denic.de> Date: Mon, 14 Jun 2004 14:53:30 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 6.0.3|September 26, 2003) at 14.06.2004 14:53:42, Serialize complete at 14.06.2004 14:53:42 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > After reading Paul's Vixie -ter proposal > http://psg.com/lists/namedroppers/namedroppers.2004/msg00967.html > and Jakob, Peter and Roy's -trans list of approaches > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt > > Please speak up on this question to help chairs gauge consensus. dnssec-trans recommends "dynamic NSEC synthesis" as a temporary solution to the walking problem. If I've gotten it right, some people have recently outspoken their preference for the "NSEC white lies" approach. However either way (cf sections 2.1.1.5 and 2.1.5.3 of dnsec-trans) requires (slight) updates to DNSSECbis. Thus my question back to the chairs: Does advancing DNSSECbis to IESG prevent incorporating these updates in the final form of DNSSECbis? I just wouldn't like to be in the position of having to deploy a temporary solution which isn't conform to IETF specifications. 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 Mon Jun 14 10:04:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03552 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 10:04:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZrym-0005Q7-PS for namedroppers-data@psg.com; Mon, 14 Jun 2004 13:58:28 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZryl-0005Pr-Ve for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 13:58:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A0C6313DE9 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 13:58:27 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Mon, 14 Jun 2004 10:00:14 +0100." <8D46730BFE093182A8F11F26@[192.168.100.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 14 Jun 2004 13:58:27 +0000 Message-Id: <20040614135827.A0C6313DE9@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > In short: with that solution, one could spoof responses to "deny > > everything" under co.uk., AUTHENTICATED existing names, signed and > > existing names, etc. > > & how is that worse than the likely alternative of "do nothing"? if you do nothing, then paranoid clients will continue to have very little confidence in spoofed data. if you use a zone-covering NSEC for all responses, then paranoid clients will have high confidence in spoofed data. not that i know of any paranoid clients, but we're all implicitly assuming that there will be some, or else we wouldn't be doing dnssec. i do not think that "a zone-covering NSEC" should be listed in -trans as one of the alternatives. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 10:23:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05255 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 10:23:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZsKX-0008mg-Fj for namedroppers-data@psg.com; Mon, 14 Jun 2004 14:20:57 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZsKW-0008m1-0X for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 14:20:56 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 1402F1FF845; Mon, 14 Jun 2004 14:20:55 +0000 (GMT) Message-ID: <40CDB446.5080500@algroup.co.uk> Date: Mon, 14 Jun 2004 15:20:54 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> Cc: Alex Bligh <alex@alex.org.uk>, Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> <40C9C10D.8080804@algroup.co.uk> <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> <40CC2F3F.40708@algroup.co.uk> <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> <8D46730BFE093182A8F11F26@[192.168.100.5]> <Pine.BSO.4.56.0406141103540.6585@trinitario.schlyter.se> In-Reply-To: <Pine.BSO.4.56.0406141103540.6585@trinitario.schlyter.se> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Mon, 14 Jun 2004, Alex Bligh wrote: > > >>--On 14 June 2004 09:14 +0200 Roy Arends <roy@dnss.ec> wrote: >> >> >>>In short: with that solution, one could spoof responses to "deny >>>everything" under co.uk., AUTHENTICATED existing names, signed and >>>existing names, etc. >> >>& how is that worse than the likely alternative of "do nothing"? > > > Far worse. > > With "do nothing" (vanilla-dns) there is the same level of spoofing/MiM > behaviour wrt denial, though with the hack above, there is a signed record > that must be interpreted as "deny everything", which is signed by, yes, > nominet. > > The effect is the same, though in the latter case of "deny everything" > there is a signature, created by a DNSKEY, which is bound to Nominet. > > Now see (for instance) algroup.co.uk authoritatively and authenticatebly > denied by a record, signed by Nominet.... > > I also like the Do Nothing alternative, and we'll include your text in > -01. In what respect is this worse? So long as Nominet make it clear that such signatures are not currently meaningful, it has no impact. 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 Mon Jun 14 10:24:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05352 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 10:24:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZsJ4-0008YL-PK for namedroppers-data@psg.com; Mon, 14 Jun 2004 14:19:26 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZsJ3-0008Y0-KF for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 14:19:26 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id B81931FF845; Mon, 14 Jun 2004 14:19:24 +0000 (GMT) Message-ID: <40CDB3EC.7040805@algroup.co.uk> Date: Mon, 14 Jun 2004 15:19:24 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> Cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> <40C9C10D.8080804@algroup.co.uk> <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> <40CC2F3F.40708@algroup.co.uk> <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> In-Reply-To: <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: >>I still prefer the one/two record "deny everything" solution. > > This says it all. Please go read the dnssec docs. Please don't assume I am an idiot, its rude. > In short: with that solution, one could spoof responses to "deny > everything" under co.uk., AUTHENTICATED existing names, signed and > existing names, etc. I know. This is no worse than the situation with unsecured DNS, surely? But it gives us a way to deploy DNSSEC in the interim without changing the spec and thus gain operational experience with it, pending the adoption of NSEC2 (or other solution to zone walking). 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 Mon Jun 14 10:28:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05743 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 10:28:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZsOG-0009CG-O3 for namedroppers-data@psg.com; Mon, 14 Jun 2004 14:24:48 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZsOF-0009Bv-FX for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 14:24:47 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 802DB1FF846; Mon, 14 Jun 2004 14:24:46 +0000 (GMT) Message-ID: <40CDB52D.5030608@algroup.co.uk> Date: Mon, 14 Jun 2004 15:24:45 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Arends <roy@dnss.ec> Cc: Jakob Schlyter <jakob@rfc.se>, DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <40C889C3.5050609@algroup.co.uk> <Pine.OSX.4.60.0406102147160.14544@criollo.schlyter.se> <40C973A5.4020706@algroup.co.uk> <Pine.LNX.4.58.0406111201040.2889@elektron.atoom.net> <40C99F0E.2050602@algroup.co.uk> <Pine.LNX.4.58.0406111425350.2889@elektron.atoom.net> <40C9C10D.8080804@algroup.co.uk> <Pine.LNX.4.58.0406111635260.2889@elektron.atoom.net> <40CC2F3F.40708@algroup.co.uk> <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> In-Reply-To: <Pine.BSO.4.56.0406140904540.6585@trinitario.schlyter.se> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Sun, 13 Jun 2004, Ben Laurie wrote: >>Roy Arends wrote: >> >>>This is FUD. >>> >>>Did you forget that private keys or secret keys are configured in online >>>machines to allow for secure zone-transfers ? >> >>Only on one machine, and that one I can control carefully. > > Zone-transfers require secret keys at both ends of the transfer. This is incorrect. >>>Did you forget that SSL >>>requires an online private key ? >> >>Irrelevant: different threat model. > > It is not irrelevant wrt exposure, configuration, management and control. > > >>>Did you forget that SSH requires an >>>online private key ? >> >>It does not require a private key that can be used without my >>intervention, and again, its a different threat model. > > > Same joke, different name. > > >>>What is then so enourmously special about SIG(NSEC) >>>private keys. >> >>I'm not really interested in a huge digression about the design of >>secure systems, suffice it to say that Nominet has a variety of reasons >>to not want to deploy private keys on its DNS secondaries. > > Ah, speaking for Nominet again. Handwaving like this does not help > in gaining sympathy and support for one's issues. ymmv. I have already mentioned the issues. My point is that you think that all systems involving private keys have the same threat model, the same risk exposure and the same solutions. You are wrong, but explaining why is not on topic for this list. 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 Mon Jun 14 11:34:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10389 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 11:34:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZtPI-000GmZ-6O for namedroppers-data@psg.com; Mon, 14 Jun 2004 15:29:56 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZtP0-000Gkr-LL for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 15:29:39 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 0C1D1E7EE6; Mon, 14 Jun 2004 16:29:37 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: <20040614135827.A0C6313DE9@sa.vix.com> Message-Id: <20040614152937.0C1D1E7EE6@mx1.nominet.org.uk> Date: Mon, 14 Jun 2004 16:29:37 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> writes: > (geoff, i'm not clear on how this proposal applies to NOERROR responses.) Yes, this would likely not work properly if there were an owner name match. There would have to be an NSEC RR associated with every authoritative owner name with a fictitious "Next Domain Field" entry. Am I correct in thinking this is the essence of the "NSEC White Lies" proposal in -trans? > > > In short: with that solution, one could spoof responses to "deny > > > everything" under co.uk., AUTHENTICATED existing names, signed and > > > existing names, etc. > > > > & how is that worse than the likely alternative of "do nothing"? > > if you do nothing, then paranoid clients will continue to have very > little confidence in spoofed data. if you use a zone-covering NSEC > for all responses, then paranoid clients will have high confidence > in spoofed data. > > not that i know of any paranoid clients, but we're all implicitly > assuming that there will be some, or else we wouldn't be doing dnssec. > > i do not think that "a zone-covering NSEC" should be listed in -trans > as one of the alternatives. Is "zone-covering NSEC" worse than "do-nothing"? In "do-nothing", NOERROR replies can be spoofed; with "zone-covering NSEC", only NXDOMAIN replies could be spoofed, which seems to have substantially less potential for damage. [ I realise "Dynamic NSEC Synthesis" is another answer, but this may require nearly as long to deploy as -ter. ] Regards Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 11:57:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11316 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 11:57:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZtmi-000JsA-F1 for namedroppers-data@psg.com; Mon, 14 Jun 2004 15:54:08 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZtmh-000Jrs-Kk for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 15:54:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 44EED13993 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 15:54:07 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: Message from geoff@nominet.org.uk (Geoffrey Sisson) of "Mon, 14 Jun 2004 16:29:37 +0100." <20040614152937.0C1D1E7EE6@mx1.nominet.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 14 Jun 2004 15:54:07 +0000 Message-Id: <20040614155407.44EED13993@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > (geoff, i'm not clear on how this proposal applies to NOERROR responses.) > > Yes, this would likely not work properly if there were an owner name > match. There would have to be an NSEC RR associated with every > authoritative owner name with a fictitious "Next Domain Field" entry. yes. > Am I correct in thinking this is the essence of the "NSEC White Lies" > proposal in -trans? i think so, yes. > > if you do nothing, then paranoid clients will continue to have very > > little confidence in spoofed data. if you use a zone-covering NSEC > > for all responses, then paranoid clients will have high confidence > > in spoofed data. > > > > not that i know of any paranoid clients, but we're all implicitly > > assuming that there will be some, or else we wouldn't be doing dnssec. > > > > i do not think that "a zone-covering NSEC" should be listed in -trans > > as one of the alternatives. > > Is "zone-covering NSEC" worse than "do-nothing"? In "do-nothing", > NOERROR replies can be spoofed; with "zone-covering NSEC", only > NXDOMAIN replies could be spoofed, which seems to have substantially > less potential for damage. security is of course not a single metric. it's rare to be able to boil the "amount of security" in two proposals down to single numbers that you can then compare and say "proposal one has more security than proposal two." however, according to the dnssec threat model as i understand it, we treat "becoming confident, due to proofs, in something which is actually not true" as having "less security" overall (or perhaps having "more insecurity") then "not being confident, due to lack of proof." therefore, "zone-covering NSEC" is worse than "do-nothing". as a potential author of a client for all this technology, i'd much rather face a condition where i know what i don't know, then one where i don't know what i 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 Mon Jun 14 11:59:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11469 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 11:59:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZtly-000JiD-5x for namedroppers-data@psg.com; Mon, 14 Jun 2004 15:53:22 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZtlw-000Jhq-L2 for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 15:53:21 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id i5EFrJld025971 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 17:53:19 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i5EFrJb01570 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 17:53:19 +0200 (MEST) Message-Id: <200406141553.i5EFrJb01570@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-reply-to: Your message of "Mon, 14 Jun 2004 16:29:37 BST." <20040614152937.0C1D1E7EE6@mx1.nominet.org.uk> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1568.1087228397.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 14 Jun 2004 17:53:18 +0200 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk geoff@nominet.org.uk (Geoffrey Sisson) wrote: > match. There would have to be an NSEC RR associated with every > authoritative owner name with a fictitious "Next Domain Field" entry. > Am I correct in thinking this is the essence of the "NSEC White Lies" > proposal in -trans? exactly. > Is "zone-covering NSEC" worse than "do-nothing"? In "do-nothing", > NOERROR replies can be spoofed; with "zone-covering NSEC", only > NXDOMAIN replies could be spoofed, which seems to have substantially > less potential for damage. This is difficult to answer as it depends on one's expectations. In "do nothing" we know it can happen, whereas in DNSSEC-bis we ``know'' it can't happen. That's why NSEC white lies needs an agreed upon signalling method which shouldn't need any new bits/flags. -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 Mon Jun 14 12:22:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12817 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 12:22:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZuAL-000OOy-LR for namedroppers-data@psg.com; Mon, 14 Jun 2004 16:18:33 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZuAK-000OON-JK for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 16:18:32 +0000 Received: from [192.168.0.5] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 980D51FE72; Mon, 14 Jun 2004 17:18:31 +0100 (BST) Date: Mon, 14 Jun 2004 17:18:30 +0100 From: Alex Bligh <alex@alex.org.uk> Reply-To: Alex Bligh <alex@alex.org.uk> To: Paul Vixie <paul@vix.com>, DNSEXT WG <namedroppers@ops.ietf.org> Cc: Alex Bligh <alex@alex.org.uk> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Message-ID: <8C8957C7854772316F2DA5FB@[192.168.0.5]> In-Reply-To: <20040614135827.A0C6313DE9@sa.vix.com> References: <20040614135827.A0C6313DE9@sa.vix.com> X-Mailer: Mulberry/3.1.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 14 June 2004 13:58 +0000 Paul Vixie <paul@vix.com> wrote: > if you do nothing, then paranoid clients will continue to have very > little confidence in spoofed data. if you use a zone-covering NSEC > for all responses, then paranoid clients will have high confidence > in spoofed data. Which is one reason why it would be good if there was some signaling that denials should not be treated as authenticated: as Peter Koch suggests: > This is difficult to answer as it depends on one's expectations. In "do > nothing" we know it can happen, whereas in DNSSEC-bis we ``know'' it can't > happen. That's why NSEC white lies needs an agreed upon signalling method > which shouldn't need any new bits/flags. even if only one particular form of zone-covering NSEC record, e.g. \001 IN NSEC \001 Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 12:53:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14582 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 12:53:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZudY-00024f-CN for namedroppers-data@psg.com; Mon, 14 Jun 2004 16:48:44 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZudX-00024L-9I for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 16:48:43 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 827EB19BBE7; Mon, 14 Jun 2004 12:47:40 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id E203119BBDF; Mon, 14 Jun 2004 12:47:39 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1770966; Mon, 14 Jun 2004 12:48:41 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020410bcf3831c2f76@[192.136.136.83]> In-Reply-To: <20040614120049.59b58a4e.olaf@ripe.net> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> <20040614120049.59b58a4e.olaf@ripe.net> Date: Mon, 14 Jun 2004 12:42:16 -0400 To: "Olaf M. Kolkman" <olaf@ripe.net> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: Edward Lewis <edlewis@arin.net>, jas@extundo.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:00 +0200 6/14/04, Olaf M. Kolkman wrote: >So you have to ordain something like ... "If andy of the secure entry points Ahh - I should have added that m-w.com didn't have a guess as to what the word was either. But, nevertheless... >Aha... this is actually a different issue. This is, if I understand >you well, how you handle proto 4 keys if you only know about proto 3 >(I was more worried about what happens if you know of both, ie the >effect during transition). Yeah, I seem them related because: 1) You start validation with data and RRSIGs. If one RRSIG indicates a key I can use and another indicating a key I can't use and we assume the first is stripped, the process is hosed. Relying on signatures to guide the validation is both an assumption of the process and danger as there's no guarantee the RRSIG's will arrive. >For argument sake let us say that keys 1 and 2 have their protocol >field set to 4. And that the DS RR was signed with a protocol 3 key. Hmm, well in this case, the validator can tell that there's a problem. It knows, verifiably, that data in the child is unverifiable even though the parent is. We've definitively hit the end of an island of security. >I am now in favour of closing this lid and not touching protocol or >the flags in DNSSEC-bis and live with them as is. Closing the lid but you have no hat. (Pun in there somewhere.) ;) I'm not so sure this would be a bad way to go. I'm not sure it has promise either, but it needs thinkin' out. It's not safe to put a DNSSEC version indicator in the RRSIGs - because they can get stripped off without notice. But, if I have data and fail to verify it but have a trusted key that is potentially "in play." The next step is to see if the data ought to be secured - and maybe there is the place where the protocol number in the key and DS can play a role. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 13:45:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17473 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 13:45:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZvR2-00090e-OY for namedroppers-data@psg.com; Mon, 14 Jun 2004 17:39:52 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZvQy-0008zx-Hq for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 17:39:48 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 14 Jun 2004 13:39:47 -0400 id 0014A71D.40CDE2E3.000027E9 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: protocol-06 section 4.5 - breaking the problem into chunks Date: Mon, 14 Jun 2004 13:39:47 -0400 User-Agent: KMail/1.6.2 References: <40BDCD26.4050808@ripe.net> <200406101710.24434.davidb@verisignlabs.com> <20040614093222.2c3317df.olaf@ripe.net> In-Reply-To: <20040614093222.2c3317df.olaf@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406141339.47555.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 14 June 2004 3:32 am, Olaf M. Kolkman wrote: > > Here is what I have come up with: > > > > The use of DNSSEC exposes more information about a zone than was > > previously available to resolvers. In particular, DNSSEC exposes > > the existence of wildcard records within a zone via RRSIG records, > > and non-existence of names via NSEC records. To avoid unexpected > > and undesirable side-effects, a security-aware resolver SHOULD NOT > > make special use of this additional information. > > > > Security-aware resolvers SHOULD NOT use received NSEC records for > > negative caching purposes beyond that specified by [RFC 2308]. For > > example, if a resolver receives an NSEC record as part of a response > > indicating that a given QNAME did not exist, the resolver SHOULD > > only return that NSEC record when queried directly for the NSEC > > record by name (e.g., via QTYPE=NSEC or QTYPE=ANY), or when > > answering a query for the original QNAME, QCLASS, and QTYPE. > > > > In addition, security-aware resolvers SHOULD NOT attempt to perform > > wildcard synthesis on behalf of a different authoritative server. > > I like this. I'm so glad :-) Do you like the last sentence? Because I'm not entirely happy with it myself. My other self-criticism of this text is that there is no concrete "why" language. There is only a very vague "to avoid unexpected and undesirable side-effects" nod in that direction. The reason why I didn't write any "why" text is that I was having a hard time coming up with it. I could use some help in this area. > But we may want to also put language in that loosens up the reuse of > an NSEC RR to proof NODATA (I remember Mark Andrews arguing for this). I did think of this. I don't remember Mark arguing for this specifically (although he may have). The main argument I remember was for being able to apply negatively cached NXDOMAIN responses to all QTYPEs, which is, of course, allowed by both this and the previous language. However, once I decided that the fundamental driving reason for this specified behavior was to not add new negative caching behavior, I decided that reusing the NSEC for NODATA responses (that is, same QNAME, QCLASS, different QTYPE) would constitute new negative caching behavior. It would mean that new RRsets added to an existing name would face negative caching behavior, and thus not be not immediately visible to some subset of resolvers. > Maybe we can add one sentence to make the point that when an NSEC RR > is provided as a proof for (RCODE=NOERROR && empty answer) (NODATA) it > MAY be reused for other queries to proof the nonexistence of types for > the same QNAME, QCLASS as that it was originally received. If we did that, we would make the first sentence of the 2nd paragraph be, in fact, wrong. Which would mean that the reasoning behind this text is wrong. Which is fine, but then the WG would have to come to agreement about what we are trying to accomplish with section 4.5. -- 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 Mon Jun 14 13:50:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17652 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 13:50:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZvWr-0009py-Co for namedroppers-data@psg.com; Mon, 14 Jun 2004 17:45:53 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZvWo-0009pK-RU for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 17:45:51 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BZvWn-0002b1-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 19:45:49 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 19:45:49 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 19:45:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Date: Mon, 14 Jun 2004 19:45:44 +0200 Lines: 66 Message-ID: <ilufz8y3uev.fsf@latte.josefsson.org> References: <20040614152937.0C1D1E7EE6@mx1.nominet.org.uk> <20040614155407.44EED13993@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:yvMOYSdjdqwKZFbLJ0Eih0eG9Gs= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> writes: >> Is "zone-covering NSEC" worse than "do-nothing"? In "do-nothing", >> NOERROR replies can be spoofed; with "zone-covering NSEC", only >> NXDOMAIN replies could be spoofed, which seems to have substantially >> less potential for damage. > > security is of course not a single metric. it's rare to be able to boil > the "amount of security" in two proposals down to single numbers that you > can then compare and say "proposal one has more security than proposal two." > > however, according to the dnssec threat model as i understand it, we treat > "becoming confident, due to proofs, in something which is actually not true" > as having "less security" overall (or perhaps having "more insecurity") then > "not being confident, due to lack of proof." > > therefore, "zone-covering NSEC" is worse than "do-nothing". I don't understand this argument. To evaluate a solution against a threat model, I believe the metric you should use is what an attacker can and cannot do, given different capabilities. Here is simple evaluation: In DNS, an active attacker can spoof anything, but positive and negative responses, and cause DoS. A passive attacker can't do much, besides perhaps gathering query id information which can be used later in an active attack, because the data sent is not confidential. In DNSSEC an active attacker can cause DoS. An active attacker cannot spoof positive responses -- any correctly implemented resolver will not be able to sign the signatures to a trusted root. An active attacker cannot spoof negative responses -- only data for which a successfully verified NSEC exist will be authenticated as non-existing. For a passive attacker the situation is similar as before, with the possible addition of being able to read ciphertext for keys she may want to crack. In DNSSEC with NSEC-lies, an active attacker can cause DoS. An active attacker cannot spoof positive responses. An active attacker can spoof negative responses, by replaying the lying NSEC. For a passive attacker the situation is similar as the previous case. If you can show that with DNSSEC-with-NSEC-lies an active attacker can spoof positive responses, you may have a case. Otherwise, I believe the conclusion is simple, if evaluated from the above perspective: DNSSEC-with-NSEC-lies is an improvement to vanilla DNS. It is possible, and useful, to go into more detail by differentiating among the capabilities of active attackers: generic active attackers, cache poisoning attackers, etc. But I believe the DNSSEC threat model include generic active attackers, so any less capable active attacker is included in the generic active attacker. > as a potential author of a client for all this technology, i'd much > rather face a condition where i know what i don't know, then one > where i don't know what i know. DNSSEC doesn't guarantee data correctness, never has. It guarantee that what you see is the same as what the publisher of the zone wants you to see. If this include lying NSEC's, this is what you will see. 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 Mon Jun 14 13:57:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17838 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 13:57:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZvfC-000B2Z-Va for namedroppers-data@psg.com; Mon, 14 Jun 2004 17:54:30 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZvfB-000B2A-UT for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 17:54:30 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 14 Jun 2004 13:54:28 -0400 id 001077C9.40CDE654.00002C11 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Date: Mon, 14 Jun 2004 13:54:29 -0400 User-Agent: KMail/1.6.2 References: <ilufz9332at.fsf@latte.josefsson.org> <20040614113830.633a56ea.olaf@ripe.net> <iluacz65sud.fsf@latte.josefsson.org> In-Reply-To: <iluacz65sud.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406141354.29107.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 14 June 2004 6:36 am, Simon Josefsson wrote: > "Olaf M. Kolkman" <olaf@ripe.net> writes: > > If you follow a chain of trust that says "foo.example" is supposed to > > be secure in "protocol 3" then, by not having a "protocol 3" key to > > verify against you have to treat the zone as bogus. > > Again, what do you mean by "bogus" in this context? I believe it > should mean "insecure", i.e. downgrade to vanilla DNS. But Scott Rose > thought SERVFAIL should be returned here. If there isn't agreement on > the interpretation, perhaps this should be clarified. The term "bogus" is defined in draft-ietf-dnsext-dnssec-intro-10, section 5, and again in -dnssec-protocol-06, section 4.3. As specified, when a validator determines that a responses is bogus, for whatever reason, it returns SERVFAIL. > > If you do not have a secure entry point (following a chain of trust of > > via a configured trustanchor) into the zone than the keys really are > > of no use and it does not matter if they are of proto 3 or 4. And your > > data should pass through as not being validated. > > Right. But I believe they should pass through. There appear to be > disagreement on that. If there is no trust anchor, then the validator has no reason to expect a the answers should be signed, and no way to validate the answer if it is. This is defined as the "Insecure" state. There is no disagreement about this. > > IMHO this exactly as specified by the language in "proto". Protocol 4 > > keys are not to be used for validation: If a DS RR[*] points to a > > protocol 4 key than the DS RR tells us foo.example is secure, but > > since we have a protocol 4 key we cannot validate. Not being able to > > validate in a secure zone implies bogus results. > > "Bogus results" is not well defined. Do you mean resolvers are > permitted to return anything it want? "Bogus" *is* well-defined. Granted, this term wasn't defined before this latest round of documents. And it hasn't displaced the term "BAD" everywhere in the docset. Maybe -intro or -protocols (or both) should define "BAD" as a synonym of "Bogus". > >> And do you have any thoughts on the actual proposed text change that > >> started this thread? I have no wish to change the Protocol Field. I > >> have used the Protocol Field, in this thread, as an example of an > >> already specified extension mechanism, since people appeared to think > >> that my proposed change wanted to introduce a new extension mechanism. > >> I want to introduce a cleaner way to specify the extensions, compared > >> to using the protocol field. > > > > IMHO, without degradation attack prevention you cannot use the field, > > nor the flag bits. > > I believe you can. Send two DNSKEYs: > > foo.example IN DNSKEY proto=3 ... > foo.example IN DNSKEY proto=4 ... > > Are you saying that a conforming DNSSECbis resolver would reject this > response and return SERVFAIL? Or should it ignore the unrecognized > second DNSKEY, validate the data using the proto=3 key and (assuming > verification succeed) proceed as normal? The latter. In this case, the validator would discard the proto=4 key for validation purposes, and thus effectively ignore RRSIGs generated by this key. If an RRset *only* had RRSIGs by the proto=4 key, it would either generate a requery for the "missing" RRSIG or consider the response bogus (or BAD, if you prefer). However, I don't know what use this case is for the purposes of DNSSEC versioning. -- 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 Mon Jun 14 14:35:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19837 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 14:35:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZwEx-000Fqn-00 for namedroppers-data@psg.com; Mon, 14 Jun 2004 18:31:27 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZwEs-000FqM-9D for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 18:31:23 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BZwEr-0003N9-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 20:31:21 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 20:31:21 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 20:31:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Mon, 14 Jun 2004 20:31:15 +0200 Lines: 60 Message-ID: <ilu7jua3sb0.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <20040614113830.633a56ea.olaf@ripe.net> <iluacz65sud.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:8zxMUCk7IqmDsUqP04RoZIA+o6I= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka <davidb@verisignlabs.com> writes: > On Monday 14 June 2004 6:36 am, Simon Josefsson wrote: >> "Olaf M. Kolkman" <olaf@ripe.net> writes: > >> > If you follow a chain of trust that says "foo.example" is supposed to >> > be secure in "protocol 3" then, by not having a "protocol 3" key to >> > verify against you have to treat the zone as bogus. >> >> Again, what do you mean by "bogus" in this context? I believe it >> should mean "insecure", i.e. downgrade to vanilla DNS. But Scott Rose >> thought SERVFAIL should be returned here. If there isn't agreement on >> the interpretation, perhaps this should be clarified. > > The term "bogus" is defined in draft-ietf-dnsext-dnssec-intro-10, section 5, > and again in -dnssec-protocol-06, section 4.3. As specified, when a > validator determines that a responses is bogus, for whatever reason, it > returns SERVFAIL. Thanks for the pointers. Where is the requirement to respond with SERVFAIL described? Or more generally, where is resolver behaviour when resolvers receive bogus data discussed? >> >> And do you have any thoughts on the actual proposed text change that >> >> started this thread? I have no wish to change the Protocol Field. I >> >> have used the Protocol Field, in this thread, as an example of an >> >> already specified extension mechanism, since people appeared to think >> >> that my proposed change wanted to introduce a new extension mechanism. >> >> I want to introduce a cleaner way to specify the extensions, compared >> >> to using the protocol field. >> > >> > IMHO, without degradation attack prevention you cannot use the field, >> > nor the flag bits. >> >> I believe you can. Send two DNSKEYs: >> >> foo.example IN DNSKEY proto=3 ... >> foo.example IN DNSKEY proto=4 ... >> >> Are you saying that a conforming DNSSECbis resolver would reject this >> response and return SERVFAIL? Or should it ignore the unrecognized >> second DNSKEY, validate the data using the proto=3 key and (assuming >> verification succeed) proceed as normal? > > The latter. Excellent! Maybe I had simply not understood how "bogus" data was to be treated. From the previous discussion I got the impression that resolvers would treat the above data as bogus. If the above work, I believe using proto=4 as a extension mechanism is possible. Just define what DNSKEY with proto=4 mean. Resolvers that do not support it, will use proto=3 and continue work, whereas resolvers that support proto=4 might use that key instead. But this just reinforce my opinion to add the text I suggested initially. If the text is adopted, we can use bit field signaling instead of protocol fields for extensions, which would be cleaner. 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 Mon Jun 14 15:08:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21406 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 15:08:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZwjt-000Jt2-4R for namedroppers-data@psg.com; Mon, 14 Jun 2004 19:03:25 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZwjr-000JsM-SB for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 19:03:24 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 55DE833C8F3; Mon, 14 Jun 2004 21:03:25 +0200 (CEST) In-Reply-To: <a06020410bcf3831c2f76@[192.136.136.83]> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> <20040614120049.59b58a4e.olaf@ripe.net> <a06020410bcf3831c2f76@[192.136.136.83]> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <82B0A58A-BE35-11D8-B05D-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: jas@extundo.com, namedroppers@ops.ietf.org From: Olaf Kolkman <olaf@ripe.net> Subject: Re: DNSKEY flags field Date: Mon, 14 Jun 2004 21:03:24 +0200 To: Edward Lewis <edlewis@arin.net> X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Hmm, well in this case, the validator can tell that there's a problem. > It knows, verifiably, that data in the child is unverifiable even > though the parent is. We've definitively hit the end of an island of > security. > I think this is incorrect, let me try to explain, The validator MUST not use proto=4 keys for validation. So the DNSKEY set cannot be validated, hence the self signature cannot be validated and the DNSKEY RRset should be marked as bogus. (That is how I read the scripture, I hope there is no ambiguity) DS does not have a proto field that could have been used to indicate that one is pointing to a proto 'n' key. So we cannot use DS to make the transition. If we allow proto=4 to be used for DNSKEY validation than we are fine we could 'hack' around this. >> I am now in favour of closing this lid and not touching protocol or >> the flags in DNSSEC-bis and live with them as is. > > Closing the lid but you have no hat. (Pun in there somewhere.) ;) my pun-o-meter is in the red :-) --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 15:16:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22359 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 15:16:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZwsn-000LAW-VR for namedroppers-data@psg.com; Mon, 14 Jun 2004 19:12:37 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZwsm-000LAE-Pf for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 19:12:37 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 14 Jun 2004 15:12:35 -0400 id 00135D72.40CDF8A3.0000417C From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Date: Mon, 14 Jun 2004 15:12:35 -0400 User-Agent: KMail/1.6.2 References: <ilufz9332at.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> <ilu7jua3sb0.fsf@latte.josefsson.org> In-Reply-To: <ilu7jua3sb0.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406141512.35693.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 14 June 2004 2:31 pm, Simon Josefsson wrote: > David Blacka <davidb@verisignlabs.com> writes: > > The term "bogus" is defined in draft-ietf-dnsext-dnssec-intro-10, section > > 5, and again in -dnssec-protocol-06, section 4.3. As specified, when a > > validator determines that a responses is bogus, for whatever reason, it > > returns SERVFAIL. > > Thanks for the pointers. Where is the requirement to respond with > SERVFAIL described? Or more generally, where is resolver behaviour > when resolvers receive bogus data discussed? In -intro-10 this is discussed later in the same section (5): This specification only defines how security aware name servers can signal non-validating stub resolvers that data was found to be bogus (using RCODE=2, "Server Failure" -- see [I-D.ietf-dnsext-dnssec-protocol]). In -protocol-06, this is stated (sort of) in section 5.5. Although that language is talking about what happens when RRSIGs do not validate, specifically. It is also mentioned briefly in section 3.2.2 in the context of the CD bit. Note to the dnssec-editors: I think that we want to make clear that SERVFAIL is returned not just when RRset fails to validate, but in all situations where "bogus" applies. This is clear (to me, anyway) from the language in -intro-10, but it is not mirrored in -protocol (that I could find). > >> Are you saying that a conforming DNSSECbis resolver would reject this > >> response and return SERVFAIL? Or should it ignore the unrecognized > >> second DNSKEY, validate the data using the proto=3 key and (assuming > >> verification succeed) proceed as normal? > > > > The latter. > > Excellent! Maybe I had simply not understood how "bogus" data was to > be treated. From the previous discussion I got the impression that > resolvers would treat the above data as bogus. If the above work, I > believe using proto=4 as a extension mechanism is possible. Just > define what DNSKEY with proto=4 mean. Resolvers that do not support > it, will use proto=3 and continue work, whereas resolvers that support > proto=4 might use that key instead. > > But this just reinforce my opinion to add the text I suggested > initially. If the text is adopted, we can use bit field signaling > instead of protocol fields for extensions, which would be cleaner. I do not see how the protocol field can be used for extensions. Maybe I just don't understand what you mean by "extensions"? In my mind, what we are driving towards are mechanisms for *non-backward-compatible* versions or extensions to DNSSEC. If the "extension" is backwards-compatible, then no signalling is needed, AFAICT. If the "extension" is not backwards compatible, then having the proto=3 present will cause DNSSEC-bis compatible resolvers to choke on the "extension", as it can't tell that this zone isn't DNSSEC-bis. All it can see is that there are irrelevant DNSKEYs and irrelevant RRSIGs. However, lets think about what happens with all zone apex keys are proto=4, and the zone is part of an island of security. So, to sorta-kinda reprise Ed's example: example.com has a secure delegation for newzone.example.com: newzone.example.com. NS ns1.newzone.example.com. newzone.example.com. NS ns2.newzone.example.com. newzone.example.com. DS <key 1> and newzone.example.com has: newzone.example.com. SOA ... RRSIG(SOA) newzone.example.com. NS ns1... NS ns2... RRSIG (NS) newzone.example.com. DNSKEY key1, proto=4 DNSKEY key2, proto=4 RRSIG(DNSKEY) a DNSSEC-bis aware resolver (i.e., unware of what proto=4 means), will have a very hard time with this, because it will a) expect newzone.example.com to be secure, and then be unable to validate anything in it. It may be able to tell that the DS in example.com corresponds to key1 in newzone, but it won't be able to validate the DNSKEY RRset in newzone (or any other RRset, for that matter). Thus will have to conclude that every answer coming from this zone is bogus. We *could* go further and specify that proto > 3 means that the DNSKEYs work the same as proto=3, thus allowing the validator to validate the zone apex DNSKEY RRset, but that, if all DNSKEYs are proto > 3, then the zone should be considered Insecure. This might work, but it requires more thought. -- 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 Mon Jun 14 15:16:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22379 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 15:16:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZwtO-000LGW-PI for namedroppers-data@psg.com; Mon, 14 Jun 2004 19:13:14 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZwtN-000LFt-M6 for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 19:13:13 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 200584EDA6; Mon, 14 Jun 2004 21:13:13 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id B47CD4EE74 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 21:13:12 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i5EJDC8r032195 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 21:13:12 +0200 Message-Id: <200406141913.i5EJDC8r032195@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: On Radio Silence, clarification. Date: Mon, 14 Jun 2004 21:13:12 +0200 From: Olaf Kolkman <olaf@ripe.net> X-RIPE-Spam-Status: N 0.052182 / 0.0 / 0.0 / disabled X-RIPE-Signature: 7eeec6c327760292ade1271227feece5 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Colleagues, First a commonplace. Mailinglists are difficult to manage, one can never tell if ones message came across just the way one intended. The lack of body-language and the fact that English is not everybodies first language does not really help in mailing list discussions. Apparently our messages are sometimes not clearly written and/or not clearly understood. If our 'process' messages confuse you, _please_ ask for clarification. Now I will try to summarize how we try to manage this discussion. Our goal is = to get DNSSEC-bis out of the door before the next cut-off with as little changes as possible = We do not want to close the door on future work that prevents zone enumeration. Our strategy is = not to solve the problem of prevention of zone enumeration now. = try to limit the discussion to what is relevant to confirm that DNSSEC-bis is ready. Implementation Our intention with the radio-silence message was that we focused on getting DNSSEC-bis done and leave the work to prevent zone enumeration for later. There was a lot of detailed technical discussion on NSEC2, on the validity of the TLD arguments and on various little sidetracks that spawned from those discussions. We wanted to defer these discussion or move them to dnssec@cafax.se so that we could focus on the transition mechanism. To prevent long discussions on the various transitions we asked a set of volunteers to make an inventory of the possible ways forward. Here we also want to prevent long discussions on _what_ is the best way forward. We want to confirm that DNSSEC-bis can be shipped with no or very little modification. Here comes the tricky bit. Some of the transition mechanisms will only work if DNSSEC-bis contains specific language (e.g the thread started by Simon ond DNSKEY flag field). Discussion on that specific language is relevant to the current discussion if not having that language is prohibitive on going forward. Way forward. = We allow for a few more days to see if we converge on the "DNSKEY flag field" discussion. = We want to get working group consensus on shipping DNSSEC-bis. Please argue if you think that shipping would close the door on future work even though we have a list of transition mechanism to choose from. Please also provide support if you think that there are ways forward and DNSSEC-bis provides hooks to go forward. We do not have to choose our way forward now. We just want to make sure we can move forward. Closing remark. We try not to confuse you, we realize we do, apologies therefore. We really intend to get the discussion focused, hear everybody, and get to get our goals (see above) accomplished. --Olaf and Olafur engineers trying to do process management. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 15:22:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22814 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 15:22:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZwyT-000M2z-8H for namedroppers-data@psg.com; Mon, 14 Jun 2004 19:18:29 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZwyS-000M2e-7b for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 19:18:28 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A99DE19B7C5; Mon, 14 Jun 2004 15:17:23 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 049ED19B5E8; Mon, 14 Jun 2004 15:17:23 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1771606; Mon, 14 Jun 2004 15:18:27 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020414bcf3a80b5a54@[192.136.136.83]> In-Reply-To: <82B0A58A-BE35-11D8-B05D-000393DA2D46@ripe.net> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> <20040614120049.59b58a4e.olaf@ripe.net> <a06020410bcf3831c2f76@[192.136.136.83]> <82B0A58A-BE35-11D8-B05D-000393DA2D46@ripe.net> Date: Mon, 14 Jun 2004 15:18:23 -0400 To: Olaf Kolkman <olaf@ripe.net> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: Edward Lewis <edlewis@arin.net>, jas@extundo.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 21:03 +0200 6/14/04, Olaf Kolkman wrote: >> Hmm, well in this case, the validator can tell that there's a problem. It >>knows, verifiably, that data in the child is unverifiable even though the >>parent is. We've definitively hit the end of an island of security. >> Before even responding to Olaf, I just went back over the intro document and noticed that it defines "island of security" a bit differently than I do - but not in a contradictory way. I've always thought of an island as being a subtree whose members are all linked through secure delegations with the root being a secure entry point. The docs say only the root of such a subtree is an "island of security." >I think this is incorrect, let me try to explain, > >The validator MUST not use proto=4 keys for validation. So the DNSKEY set >cannot be validated, hence the self signature cannot be validated and the >DNSKEY RRset should be marked as bogus. (That is how I read the scripture, I >hope there is no ambiguity) For DNSSECbis, this is clear. >DS does not have a proto field that could have been used to indicate that one >is pointing to a proto 'n' key. So we cannot use DS to make the transition. If I said otherwise, I was confusing the protocol field with the algorithm field. >If we allow proto=4 to be used for DNSKEY validation than we are fine we could >'hack' around this. It wouldn't be so much of a hack if we defined protocol 42 to be DNSSECter. DNSSECbis would simple be unable to deal with these keys, letting them fall into the bogus category. Going back to the assumption that I am dealing with a zone that is written in DNSSECbis and DNSSECter, and I only understand DNSSECbis, I should still see a DS RRset signed with a key designated as DNSSECbis protocol. I then have hashes that I ought to be able to apply to the the set of keys at the child, even if they are written in DNSSECter. I should be able to validate them via the hash, therefore concluding what I read is true - that these are all DNSSSECter keys. At that point, I think it's safe to conclude that I've hit the boundary of a DNSSECbis island of security (my version), to use the -intro, I've fallen from a DNSSECbis island of security through some zones, into a zone with no security. Instead of SERVFAIL, I return this as unsigned data to someone asking for verified data. If this approach can stand up, I'd prefer it than having to deal with the bits of the key flags, for the sake of simplicity. (Lot of if's there.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 15:33:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23757 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 15:33:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZxAs-000Nii-9h for namedroppers-data@psg.com; Mon, 14 Jun 2004 19:31:18 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZxAp-000Ni6-0I for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 19:31:15 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i5EJU2dr000654; Mon, 14 Jun 2004 15:30:02 -0400 To: Simon Josefsson <jas@extundo.com> Cc: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <20040614152937.0C1D1E7EE6@mx1.nominet.org.uk> <20040614155407.44EED13993@sa.vix.com> <ilufz8y3uev.fsf@latte.josefsson.org> From: Derek Atkins <derek@ihtfp.com> Date: Mon, 14 Jun 2004 15:30:01 -0400 In-Reply-To: <ilufz8y3uev.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 14 Jun 2004 19:45:44 +0200") Message-ID: <sjmn036ym2u.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson <jas@extundo.com> writes: > If you can show that with DNSSEC-with-NSEC-lies an active attacker can > spoof positive responses, you may have a case. Otherwise, I believe > the conclusion is simple, if evaluated from the above perspective: > DNSSEC-with-NSEC-lies is an improvement to vanilla DNS. They cannot forge a new positive response to replace the real positive response, but they can replay the lying-NSEC and cause the recipient to believe authentically that there is no positive response to their query even when it exists. All they need to do is make sure the NSEC replay is received and suppress the positive response. So I suppose this is just a DoS attack, but it's a DoS attack that does not exist in normal DNSSec (nor with DNSSec with real-time signed NSEC). In other words, an attacker could effectively authentically deny the existence of all nodes in your zone covered by the lying NSEC records. > It is possible, and useful, to go into more detail by differentiating > among the capabilities of active attackers: generic active attackers, > cache poisoning attackers, etc. But I believe the DNSSEC threat model > include generic active attackers, so any less capable active attacker > is included in the generic active attacker. This is correct. >> as a potential author of a client for all this technology, i'd much >> rather face a condition where i know what i don't know, then one >> where i don't know what i know. > > DNSSEC doesn't guarantee data correctness, never has. It guarantee > that what you see is the same as what the publisher of the zone wants > you to see. If this include lying NSEC's, this is what you will see. Right, but with lying NSEC you are not guaranteed that you'll receive all the data. A real positive response could be dropped in transit, and with normal DNSSec you can detect this, but with lying NSEC you cannot. > Regards, > Simon -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 Mon Jun 14 15:51:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24627 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 15:51:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZxQN-000PYR-Pn for namedroppers-data@psg.com; Mon, 14 Jun 2004 19:47:19 +0000 Received: from [193.0.3.26] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZxQM-000PY2-G5 for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 19:47:18 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 1B8C533C961; Mon, 14 Jun 2004 21:47:22 +0200 (CEST) In-Reply-To: <a06020414bcf3a80b5a54@[192.136.136.83]> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> <20040614120049.59b58a4e.olaf@ripe.net> <a06020410bcf3831c2f76@[192.136.136.83]> <82B0A58A-BE35-11D8-B05D-000393DA2D46@ripe.net> <a06020414bcf3a80b5a54@[192.136.136.83]> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <A63E6F40-BE3B-11D8-B05D-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman <olaf@ripe.net> Subject: Re: DNSKEY flags field Date: Mon, 14 Jun 2004 21:47:20 +0200 To: Edward Lewis <edlewis@arin.net> X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> If we allow proto=4 to be used for DNSKEY validation than we are fine >> we could >> 'hack' around this. > > It wouldn't be so much of a hack if we defined protocol 42 to be > DNSSECter. DNSSECbis would simple be unable to deal with these keys, > letting them fall into the bogus category. > > Going back to the assumption that I am dealing with a zone that is > written in DNSSECbis and DNSSECter, and I only understand DNSSECbis, I > should still see a DS RRset signed with a key designated as DNSSECbis > protocol. I then have hashes that I ought to be able to apply to the > the set of keys at the child, even if they are written in DNSSECter. > I should be able to validate them via the hash, therefore concluding > what I read is true - that these are all DNSSSECter keys. > > At that point, I think it's safe to conclude that I've hit the > boundary of a DNSSECbis island of security (my version), to use the > -intro, I've fallen from a DNSSECbis island of security through some > zones, into a zone with no security. > > Instead of SERVFAIL, I return this as unsigned data to someone asking > for verified data. > > If this approach can stand up, I'd prefer it than having to deal with > the bits of the key flags, for the sake of simplicity. (Lot of if's > there.) > You are about to convince me but one thing that worries me a crypto vulnerability. Crypto is not my field of expertise and I maybe heading to circular reasoning. So to really understand if there is a problem there I would appreciate a pointer on how difficult it is to generate a SHA1 hash collision if you have a number of fixed bits and a number of completely random bits that are used as an argument. ( What I am trying to understand is how easy it would be for 'the bad guys' to create a DNSKEY RR with the appropriate flags, algorithm and protocol field (that are all fixed) and a public key field that has no restrictions whatsoever. The only requirement would be that it matches the parental DS RR, there would be no need for the key blob to be an actual public key which makes the space in which you try to locate the hash collision easier to scan. You would always be able to use such a key to perform a DOS attack, we know that. But you do not want to be able to use such a completely random key to go from a secured to a in-secured world. ) Pointers are appreciated off-list. --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 Mon Jun 14 15:54:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24686 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 15:54:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZxSv-000PqA-2v for namedroppers-data@psg.com; Mon, 14 Jun 2004 19:49:57 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZxSt-000Ppu-Kd for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 19:49:55 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id AF24F19B5E5; Mon, 14 Jun 2004 15:48:50 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 27B3E19B356; Mon, 14 Jun 2004 15:48:50 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1771744; Mon, 14 Jun 2004 15:49:54 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020415bcf3b0e16c2b@[192.136.136.83]> In-Reply-To: <200406141512.35693.davidb@verisignlabs.com> References: <ilufz9332at.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> <ilu7jua3sb0.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> Date: Mon, 14 Jun 2004 15:49:52 -0400 To: David Blacka <davidb@verisignlabs.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:12 -0400 6/14/04, David Blacka wrote: >a DNSSEC-bis aware resolver (i.e., unware of what proto=4 means), will >have a very hard time with this, because it will a) expect >newzone.example.com to be secure, and then be unable to validate >anything in it. It may be able to tell that the DS in example.com >corresponds to key1 in newzone, but it won't be able to validate the >DNSKEY RRset in newzone (or any other RRset, for that matter). Thus >will have to conclude that every answer coming from this zone is >bogus. > >We *could* go further and specify that proto > 3 means that the >DNSKEYs work the same as proto=3, thus allowing the validator to >validate the zone apex DNSKEY RRset, but that, if all DNSKEYs are >proto > 3, then the zone should be considered Insecure. This might >work, but it requires more thought. Tossing out this - how safe is it to assume that if the hash in a DS RR matches the DNSKEY RR with proto=4, that the DNSKEY RR is genuine? Even if the RRSIG over the DNSKEY set indicates keys that are all proto=4? Ahh - we lose the ability to detect signatures out of time. I know we've kicked around the utility of signing the DNSKEY RRset in light of the DS RR hash. The reason the signatures are still relevant is because they are the only means the child has to limit the time the key set is "validate-able." (The DS RR is also signed and thus time limited, but this time limit is supplied by the parent.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 15:54:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24735 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 15:54:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZxVK-0000E7-5w for namedroppers-data@psg.com; Mon, 14 Jun 2004 19:52:26 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZxVJ-0000Do-4u for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 19:52:25 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 3249619B5E5; Mon, 14 Jun 2004 15:51:20 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B64C219B356; Mon, 14 Jun 2004 15:51:19 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1771759; Mon, 14 Jun 2004 15:52:24 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020416bcf3b217b507@[192.136.136.83]> In-Reply-To: <A63E6F40-BE3B-11D8-B05D-000393DA2D46@ripe.net> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> <20040614120049.59b58a4e.olaf@ripe.net> <a06020410bcf3831c2f76@[192.136.136.83]> <82B0A58A-BE35-11D8-B05D-000393DA2D46@ripe.net> <a06020414bcf3a80b5a54@[192.136.136.83]> <A63E6F40-BE3B-11D8-B05D-000393DA2D46@ripe.net> Date: Mon, 14 Jun 2004 15:52:21 -0400 To: Olaf Kolkman <olaf@ripe.net> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 21:47 +0200 6/14/04, Olaf Kolkman wrote: >You are about to convince me but one thing that worries me a crypto >vulnerability. The same thing worries me. And, after reading David's note, I recalled that with out the verifiable signature, the child zone has no way to state a signature validation period over the key set. The rest of your note is also a concern of mine... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 16:05:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25623 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 16:05:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZxfz-000211-GH for namedroppers-data@psg.com; Mon, 14 Jun 2004 20:03:27 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZxfy-00020f-HX for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 20:03:26 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1218442B2 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 16:03:22 -0400 (EDT) Date: Mon, 14 Jun 2004 16:03:21 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: <a06020415bcf3b0e16c2b@[192.136.136.83]> References: <ilufz9332at.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> <ilu7jua3sb0.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> <a06020415bcf3b0e16c2b@192.136.136.83> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040614200322.1218442B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 14 Jun 2004 15:49:52 -0400, Ed Lewis wrote: > > Tossing out this - how safe is it to assume that if the hash in a DS > RR matches the DNSKEY RR with proto=4, that the DNSKEY RR is genuine? > Even if the RRSIG over the DNSKEY set indicates keys that are all > proto=4? Define "genuine". Seriously. Properly signed DS is an attestation by the parent that it believes that the child has asked to have this signed key hash listed and that listing this signed key hash doesn't violate the parent's (unknown, not part of protocol) policies. Further deponant sayeth not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 16:11:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26099 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 16:11:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZxjm-0002dd-MR for namedroppers-data@psg.com; Mon, 14 Jun 2004 20:07:22 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZxjl-0002dH-Fc for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 20:07:21 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 14 Jun 2004 16:07:19 -0400 id 001382DB.40CE0577.00004FA9 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Date: Mon, 14 Jun 2004 16:07:20 -0400 User-Agent: KMail/1.6.2 References: <ilufz9332at.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> <a06020415bcf3b0e16c2b@[192.136.136.83]> In-Reply-To: <a06020415bcf3b0e16c2b@[192.136.136.83]> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406141607.20606.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 14 June 2004 3:49 pm, Edward Lewis wrote: > Tossing out this - how safe is it to assume that if the hash in a DS > RR matches the DNSKEY RR with proto=4, that the DNSKEY RR is genuine? > Even if the RRSIG over the DNSKEY set indicates keys that are all > proto=4? I suppose it is fairly safe. My thinking is that if it wasn't (if Olaf's crypto concerns were actually a concern, then DS is problematic already). > Ahh - we lose the ability to detect signatures out of time. I know > we've kicked around the utility of signing the DNSKEY RRset in light > of the DS RR hash. The reason the signatures are still relevant is > because they are the only means the child has to limit the time the > key set is "validate-able." (The DS RR is also signed and thus time > limited, but this time limit is supplied by the parent.) This is an issue. A bigger issue, in my mind, is that a validator would *only* trust that key. You would be unable to chain that trust to a ZSK, for example. Very annoying. -- 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 Mon Jun 14 16:25:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27335 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 16:25:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZxxu-0004QS-JR for namedroppers-data@psg.com; Mon, 14 Jun 2004 20:21:58 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZxxq-0004Q2-QI for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 20:21:55 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BZxxq-0005ZY-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 22:21:54 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 22:21:54 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 22:21:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt Date: Mon, 14 Jun 2004 22:21:49 +0200 Lines: 32 Message-ID: <ilur7sh3n6q.fsf@latte.josefsson.org> References: <20040614152937.0C1D1E7EE6@mx1.nominet.org.uk> <20040614155407.44EED13993@sa.vix.com> <ilufz8y3uev.fsf@latte.josefsson.org> <sjmn036ym2u.fsf@dogbert.ihtfp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:6nmpx0euSKv9nW3ST28GvnJmLjc= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Derek Atkins <derek@ihtfp.com> writes: > Simon Josefsson <jas@extundo.com> writes: > >> If you can show that with DNSSEC-with-NSEC-lies an active attacker can >> spoof positive responses, you may have a case. Otherwise, I believe >> the conclusion is simple, if evaluated from the above perspective: >> DNSSEC-with-NSEC-lies is an improvement to vanilla DNS. > > They cannot forge a new positive response to replace the real positive > response, but they can replay the lying-NSEC and cause the recipient > to believe authentically that there is no positive response to their > query even when it exists. All they need to do is make sure the NSEC > replay is received and suppress the positive response. So I suppose > this is just a DoS attack, but it's a DoS attack that does not exist > in normal DNSSec (nor with DNSSec with real-time signed NSEC). But compared with vanilla DNS, the situation is the same. So I couldn't follow how DNSSEC with lying NSEC's is worse than vanilla DNS. Compared to full DNSSEC, naturally DNSSEC with lying NSEC is worse, but I doubt anyone thought otherwise. Of course, being able to spoof that something doesn't exist is worse than one might first assume; missing MX records can redirect e-mail. Thanks, Simon PS. There were at least two typos in my post quoted above; `but positive and negative' should have been `both positive and negative', and `sign the signatures to a trusted root' should of course have been `verify ...'. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 16:46:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00217 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 16:46:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZyJ7-00071a-9o for namedroppers-data@psg.com; Mon, 14 Jun 2004 20:43:53 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZyJ6-00071E-3o for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 20:43:52 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5EKegFL007731 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 16:40:48 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i5EK4c4A014050 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 16:04:38 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: protocol-06 section 4.5 - breaking the problem into chunks Date: Mon, 14 Jun 2004 16:04:38 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGAECMCLAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200406141339.47555.davidb@verisignlabs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka > On Monday 14 June 2004 3:32 am, Olaf M. Kolkman wrote: > > > Here is what I have come up with: > > > > > > The use of DNSSEC exposes more information about a zone than was > > > previously available to resolvers. In particular, DNSSEC exposes > > > the existence of wildcard records within a zone via RRSIG records, > > > and non-existence of names via NSEC records. To avoid unexpected > > > and undesirable side-effects, a security-aware resolver SHOULD NOT > > > make special use of this additional information. > > > > > > Security-aware resolvers SHOULD NOT use received NSEC records for > > > negative caching purposes beyond that specified by [RFC 2308]. For > > > example, if a resolver receives an NSEC record as part of a response > > > indicating that a given QNAME did not exist, the resolver SHOULD > > > only return that NSEC record when queried directly for the NSEC > > > record by name (e.g., via QTYPE=NSEC or QTYPE=ANY), or when > > > answering a query for the original QNAME, QCLASS, and QTYPE. > > > > > > In addition, security-aware resolvers SHOULD NOT attempt to perform > > > wildcard synthesis on behalf of a different authoritative server. > > > > I like this. > > I'm so glad :-) > > Do you like the last sentence? Because I'm not entirely happy > with it myself. > > My other self-criticism of this text is that there is no concrete "why" > language. There is only a very vague "to avoid unexpected and > undesirable > side-effects" nod in that direction. > That may be good enough. We can also add something along the lines stating that caches are not able to generate positive wildcard (and negative) responses with complete accuracy, so it is best up to the cache to contact the authoritative server and be as transparent as possible. Or something like that. Scott > > -- > 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/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 16:53:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00908 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 16:53:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZyQA-00088i-Pi for namedroppers-data@psg.com; Mon, 14 Jun 2004 20:51:10 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZyQ9-000881-LS for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 20:51:09 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E2DC419B370; Mon, 14 Jun 2004 16:50:03 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 2E33219B44E; Mon, 14 Jun 2004 16:50:02 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1772125; Mon, 14 Jun 2004 16:51:07 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020419bcf3bcb53202@[192.136.136.83]> In-Reply-To: <20040614200322.1218442B2@thrintun.hactrn.net> References: <ilufz9332at.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> <ilu7jua3sb0.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> <a06020415bcf3b0e16c2b@192.136.136.83> <20040614200322.1218442B2@thrintun.hactrn.net> Date: Mon, 14 Jun 2004 16:46:10 -0400 To: Rob Austein <sra@isc.org> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Genuine - meaning that the match of the DNSKEY proto=4 and the DS hash is not the result of a malicious party's insertion of data. Let's put the question another way. This is a question, I'm seeking ideas. I begin with a trusted key that I do not question, it's "configured." I use it to verify, in the DNSSEC sense, down the tree to a DS RR (set). I now pick up a DNSKEY RR and find that it matches the DS's RR set. How much to I gain by finding out that the DNSKEY set also matches the signature generated by one of the private keys corresponding to the set? What are the chances it'll fail the signature check? So, by genuine, I mean, the DNSKEY was used to generate the DS RR's hash for it, and not some other public key that was crafted to match the hash. (Does this make sense? I barely makes sense to me.) At 16:03 -0400 6/14/04, Rob Austein wrote: >At Mon, 14 Jun 2004 15:49:52 -0400, Ed Lewis wrote: >> >> Tossing out this - how safe is it to assume that if the hash in a DS >> RR matches the DNSKEY RR with proto=4, that the DNSKEY RR is genuine? >> Even if the RRSIG over the DNSKEY set indicates keys that are all >> proto=4? > >Define "genuine". Seriously. > >Properly signed DS is an attestation by the parent that it believes >that the child has asked to have this signed key hash listed and that >listing this signed key hash doesn't violate the parent's (unknown, >not part of protocol) policies. Further deponant sayeth not. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 17:01:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01777 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 17:01:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZyWm-0009LL-Qd for namedroppers-data@psg.com; Mon, 14 Jun 2004 20:58:00 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZyWi-0009Kg-Vx for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 20:57:57 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A802313951 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 20:57:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: Message from Alex Bligh <alex@alex.org.uk> of "Mon, 14 Jun 2004 17:18:30 +0100." <8C8957C7854772316F2DA5FB@[192.168.0.5]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 14 Jun 2004 20:57:56 +0000 Message-Id: <20040614205756.A802313951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > if you do nothing, then paranoid clients will continue to have very > > little confidence in spoofed data. if you use a zone-covering NSEC > > for all responses, then paranoid clients will have high confidence > > in spoofed data. > > Which is one reason why it would be good if there was some signaling > that denials should not be treated as authenticated: ... if you want non-authenticated denial, maybe you should just leave out the NSEC altogether. putting your signature on one that covers names which actually exist, and then leaking that signed "lie" to the universe, where others could replay or misinterpret it out of context, seems like a huge mistake to 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 Mon Jun 14 17:09:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02384 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 17:09:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZyfB-000B0D-BA for namedroppers-data@psg.com; Mon, 14 Jun 2004 21:06:41 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZyf8-000Azh-CZ for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 21:06:38 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A761F42B2 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 17:06:37 -0400 (EDT) Date: Mon, 14 Jun 2004 17:06:37 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: <a06020419bcf3bcb53202@[192.136.136.83]> References: <ilufz9332at.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> <ilu7jua3sb0.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> <a06020415bcf3b0e16c2b@192.136.136.83> <20040614200322.1218442B2@thrintun.hactrn.net> <a06020419bcf3bcb53202@192.136.136.83> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040614210637.A761F42B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 14 Jun 2004 16:46:10 -0400, Ed Lewis wrote: > > So, by genuine, I mean, the DNSKEY was used to generate the DS RR's > hash for it, and not some other public key that was crafted to match > the hash. To the extent that I understand the basic criteria for a cryptographic hash function, if it is possible to find "some other public key crafted to match the hash", there's something seriously wrong with the hash algorithm (or someone has broken the hash algorithm, which amounts to the same thing). If you want a better answer, ask a cryptographer. :) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 17:10:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02638 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 17:10:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZyh7-000BIr-3O for namedroppers-data@psg.com; Mon, 14 Jun 2004 21:08:41 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZyh3-000BI5-9X for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 21:08:37 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id CE67A13971 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 21:08:36 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: zone-covering NSEC ranges -- "which is it?" X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 14 Jun 2004 21:08:36 +0000 Message-Id: <20040614210836.CE67A13971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i asked this in an earlier message but it was lost in the haze of a larger discussion. here are two NSEC RRs, more or less. #1: @ NSEC (SOA NS ...) @ #2: X NSEC (...) X there are two visible differences between them: one says there's an SOA and NS at the ownername (@), the other does not (X). and one's owner and target names are "@" (the zone apex) and the other's owner and target name is "X" (not the zone apex). those familiar with the specs consider the first one to be a way of expressing the nonexistence of any names other than the zone apex. in other words it covers the whole zone, all possible names. why? there are two possible answers. for my own edification i'd like to clarify which one applies, and for others' edification i might end up asking that the dnssec-bis docset be amended to clarify this point. the first possible answer to "why does @-NSEC-@ cover all possible names?" is that the target name is @, and it's a special case indicating that all names from the owner name through the end of the zone are in the range. the second possible answer to "why does @-NSEC-@ cover all possible names?" is that the target name equals the owner name, indicating a null range, which in some kind of "serial number arithmetic" kind of way "wraps around." if we select the first possible answer, then "X-NSEC-X" does not speak for all possible names in the same way "@-NSEC-@" does. if we select the second possible answer, then "X-NSEC-X", for any value of X including @ or any other, speaks for all possible names. which is 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 Mon Jun 14 17:26:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03820 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 17:26:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZyw2-000D4A-2r for namedroppers-data@psg.com; Mon, 14 Jun 2004 21:24:06 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZyw1-000D3u-4F for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 21:24:05 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 0EE0819B411; Mon, 14 Jun 2004 17:22:59 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 4994119B514; Mon, 14 Jun 2004 17:22:58 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1772375; Mon, 14 Jun 2004 17:24:03 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020403bcf3c76ad092@[192.136.136.83]> In-Reply-To: <20040614210836.CE67A13971@sa.vix.com> References: <20040614210836.CE67A13971@sa.vix.com> Date: Mon, 14 Jun 2004 17:24:01 -0400 To: Paul Vixie <paul@vix.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: zone-covering NSEC ranges -- "which is it?" Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I like the second possible answer. The first answer is "special case" and I loathe those. The second answer is based on a concept in use elsewhere (serial number arithmetic, signature lifetimes). At 21:08 +0000 6/14/04, Paul Vixie wrote: >i asked this in an earlier message but it was lost in the haze of a larger >discussion. here are two NSEC RRs, more or less. > >#1: @ NSEC (SOA NS ...) @ > >#2: X NSEC (...) X > >there are two visible differences between them: one says there's an SOA and >NS at the ownername (@), the other does not (X). and one's owner and target >names are "@" (the zone apex) and the other's owner and target name is "X" >(not the zone apex). > >those familiar with the specs consider the first one to be a way of expressing >the nonexistence of any names other than the zone apex. in other words it >covers the whole zone, all possible names. > >why? there are two possible answers. for my own edification i'd like to >clarify which one applies, and for others' edification i might end up asking >that the dnssec-bis docset be amended to clarify this point. > >the first possible answer to "why does @-NSEC-@ cover all possible names?" >is that the target name is @, and it's a special case indicating that all >names from the owner name through the end of the zone are in the range. > >the second possible answer to "why does @-NSEC-@ cover all possible names?" >is that the target name equals the owner name, indicating a null range, >which in some kind of "serial number arithmetic" kind of way "wraps around." > >if we select the first possible answer, then "X-NSEC-X" does not speak for >all possible names in the same way "@-NSEC-@" does. > >if we select the second possible answer, then "X-NSEC-X", for any value of >X including @ or any other, speaks for all possible names. > >which is 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/> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 17:34:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04483 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 17:34:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZz3S-000EBm-7Y for namedroppers-data@psg.com; Mon, 14 Jun 2004 21:31:46 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZz3P-000EBJ-FX for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 21:31:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3839313993 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 21:31:43 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Mon, 14 Jun 2004 17:24:01 -0400." <a06020403bcf3c76ad092@[192.136.136.83]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 14 Jun 2004 21:31:43 +0000 Message-Id: <20040614213143.3839313993@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I like the second possible answer. The first answer is "special case" and > I loathe those. The second answer is based on a concept in use elsewhere > (serial number arithmetic, signature lifetimes). one additional thing to note is that in my example, @ and X have different numbers of labels, since X would be a subdomain of @. therefore, "wrapping" could mean "all domain names ending in the shared owner/target name, including that name" and probably does. but where does it say that in the -bis docset? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 17:48:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05148 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 17:48:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZzGl-000FpZ-NS for namedroppers-data@psg.com; Mon, 14 Jun 2004 21:45:31 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZzGi-000FpA-OD for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 21:45:28 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5ELjPWa034029 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 21:45:27 GMT (envelope-from roy+dated+1089841521.ab689a@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5ELjLso001134 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 22:45:23 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5ELjLkD085729 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 22:45:21 +0100 (BST) (envelope-from roy+dated+1089841521.ab689a@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5ELjL4i085728 for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 22:45:21 +0100 (BST) (envelope-from roy+dated+1089841521.ab689a@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Mon, 14 Jun 2004 22:45:21 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16590.7280.612012.311865@giles.gnomon.org.uk> Date: Mon, 14 Jun 2004 22:45:20 +0100 To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: zone-covering NSEC ranges -- "which is it?" In-Reply-To: <20040614210836.CE67A13971@sa.vix.com> References: <20040614210836.CE67A13971@sa.vix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Paul" == Paul Vixie <paul@vix.com> writes: Paul> the second possible answer to "why does @-NSEC-@ cover all Paul> possible names?" is that the target name equals the owner Paul> name, indicating a null range, which in some kind of "serial Paul> number arithmetic" kind of way "wraps around." I had been assuming the second possible answer, given that RFC2535 said (5.1): There is a potential problem with the last NXT in a zone as it wants to have an owner name which is the last existing name in canonical 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 NXT in a zone. However it appears that DNSSECbis makes no similar statement about a circular name space. -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 Mon Jun 14 17:50:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05198 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 17:50:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZzJX-000G6m-If for namedroppers-data@psg.com; Mon, 14 Jun 2004 21:48:23 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZzJU-000G6K-Qg for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 21:48:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7DD5A13971 for <namedroppers@ops.ietf.org>; Mon, 14 Jun 2004 21:48:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> of "Mon, 14 Jun 2004 22:45:20 +0100." <16590.7280.612012.311865@giles.gnomon.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 14 Jun 2004 21:48:20 +0000 Message-Id: <20040614214820.7DD5A13971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I had been assuming the second possible answer, given that RFC2535 > said (5.1): > > There is a potential problem with the last NXT in a zone as it > wants to have an owner name which is the last existing name in > canonical 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 NXT in a zone. > > However it appears that DNSSECbis makes no similar statement about a > circular name space. not only that, the circularity is only by mention, not in fact. it does not say that putting your own owner name in as the target name works; rather, that the zone name (or apex, or @ in my example) is special cased. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 19:41:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13021 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 19:41:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Ba11p-000432-Ex for namedroppers-data@psg.com; Mon, 14 Jun 2004 23:38:13 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Ba11n-00042V-Hs for namedroppers@ops.ietf.org; Mon, 14 Jun 2004 23:38:12 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id LAA15260 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 11:38:10 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i5ENcAfw063711 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 11:38:10 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" In-Reply-To: Your message of "Mon, 14 Jun 2004 21:08:36 GMT." <20040614210836.CE67A13971@sa.vix.com> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Tue, 15 Jun 2004 11:38:10 +1200 Message-ID: <63710.1087256290@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie <paul@vix.com> wrote: >i asked this in an earlier message but it was lost in the haze of a larger >discussion. here are two NSEC RRs, more or less. > >#1: @ NSEC (SOA NS ...) @ > >#2: X NSEC (...) X > >there are two visible differences between them: one says there's an SOA and >NS at the ownername (@), the other does not (X). and one's owner and target >names are "@" (the zone apex) and the other's owner and target name is "X" >(not the zone apex). > >those familiar with the specs consider the first one to be a way of >expressing >the nonexistence of any names other than the zone apex. in other words it >covers the whole zone, all possible names. > >why? there are two possible answers. for my own edification i'd like to >clarify which one applies, and for others' edification i might end up asking >that the dnssec-bis docset be amended to clarify this point. > >the first possible answer to "why does @-NSEC-@ cover all possible names?" >is that the target name is @, and it's a special case indicating that all >names from the owner name through the end of the zone are in the range. > >the second possible answer to "why does @-NSEC-@ cover all possible names?" >is that the target name equals the owner name, indicating a null range, >which in some kind of "serial number arithmetic" kind of way "wraps around." > >if we select the first possible answer, then "X-NSEC-X" does not speak for >all possible names in the same way "@-NSEC-@" does. > >if we select the second possible answer, then "X-NSEC-X", for any value of >X including @ or any other, speaks for all possible names. > >which is it? I rather like the idea that X NSEC X covers all just X and all its subdomains (with appropriate processing where X is a delegation point). That generalises nicely to @ NSEC @ as well. To generalise further, if the Next Domain Name field is less than or equal to the owner name, then one can assume that the owner name is the last subdomain of the name specified as the next domain name. Thus: x.y.example. NSEC y.example. ... denies z.y.example and z.z.y.example, regardless of whether y.example is a zone apex or not. The lovely part of this approach is that you don't actually have to consider the zone cut when checking if a name is between the owner and next domain name in an NSEC; the only special case is when the owner name is a delegation point. If you have a "proper" NSEC chain, this happens anyway, it's just that the wrap happens at the bottom of the zone and wraps to the apex. But there's nothing stopping one wrapping tighter than that if appropriate. The only corner case to consider is where the NSEC points outside the zone, e.g. x.example. SOA ... y.x.example. NSEC example. ... This MUST NOT be treated as a denial for z.example. This isn't an issue in the normal case, since you won't be trusting stuff signed from within x.example when querying z.example, but anything aggressively using NSECs will need to be aware of that one. -- 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 Mon Jun 14 20:40:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16098 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 20:40:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Ba1x6-000AS4-SA for namedroppers-data@psg.com; Tue, 15 Jun 2004 00:37:24 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Ba1x5-000ARo-T0 for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 00:37:24 +0000 Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i5F0bKHj018198; Mon, 14 Jun 2004 20:37:20 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i5F0bJOn023637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jun 2004 20:37:20 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i5F0bJfB015175; Mon, 14 Jun 2004 20:37:19 -0400 Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt From: Greg Hudson <ghudson@MIT.EDU> To: Paul Vixie <paul@vix.com> Cc: DNSEXT WG <namedroppers@ops.ietf.org> In-Reply-To: <20040614205756.A802313951@sa.vix.com> References: <20040614205756.A802313951@sa.vix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1087259839.25930.402.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 14 Jun 2004 20:37:19 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2004-06-14 at 16:57, Paul Vixie wrote: > if you want non-authenticated denial, maybe you should just leave out > the NSEC altogether. I think at that point you may as well not answer the question. If your zone has a key, an unsigned response looks like an attack, and should be discarded. I kind of like the deny-the-whole-zone NSEC response, personally. The denial replay attack seems like a relatively mild practical consequence. (Of course, I think it's much better to have real NSEC records and a zone file available for FTP, and I think most of the arguments against doing that are horribly off the mark, but I'm willing to take it as axiomatic that some zones will find denying enumeration more important than having good security against spoofing attacks.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Jun 14 23:22:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00915 for <dnsext-archive@lists.ietf.org>; Mon, 14 Jun 2004 23:22:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Ba4T4-0000iu-4A for namedroppers-data@psg.com; Tue, 15 Jun 2004 03:18:34 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Ba4T2-0000iQ-LO for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 03:18:33 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id PAA16287 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 15:18:31 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i5F3IVfw080495 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 15:18:31 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt In-Reply-To: Your message of "Mon, 14 Jun 2004 22:21:49 +0200." <ilur7sh3n6q.fsf@latte.josefsson.org> From: Don Stokes <don@plugh.daedalus.co.nz> Date: Tue, 15 Jun 2004 15:18:31 +1200 Message-ID: <80494.1087269511@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson <jas@extundo.com> wrote: >Of course, being able to spoof that something doesn't exist is worse >than one might first assume; missing MX records can redirect e-mail. MX is the obvious case where spoofed authenticated denial could be used in a non-DoS attack. Anything that has some kind of fall-back will be vulnerable, including use of search lists for partial name lookups, low-priority SRV records etc. -- 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 Tue Jun 15 04:00:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00603 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 04:00:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Ba8lV-0001aw-PY for namedroppers-data@psg.com; Tue, 15 Jun 2004 07:53:53 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Ba8lT-0001ab-Dl for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 07:53:52 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id ED5D2AC8B; Tue, 15 Jun 2004 09:53:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id EC2E7AC8A; Tue, 15 Jun 2004 09:53:49 +0200 (CEST) Date: Tue, 15 Jun 2004 09:53:49 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" In-Reply-To: <20040614214820.7DD5A13971@sa.vix.com> Message-ID: <Pine.BSO.4.56.0406150950420.12159@trinitario.schlyter.se> References: <20040614214820.7DD5A13971@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 14 Jun 2004, Paul Vixie wrote: > > I had been assuming the second possible answer, given that RFC2535 > > said (5.1): > > > > There is a potential problem with the last NXT in a zone as it > > wants to have an owner name which is the last existing name in > > canonical 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 NXT in a zone. > > > > However it appears that DNSSECbis makes no similar statement about a > > circular name space. > > not only that, the circularity is only by mention, not in fact. it does > not say that putting your own owner name in as the target name works; > rather, that the zone name (or apex, or @ in my example) is special cased. -records draft: 4.1.1 The Next Domain Name Field The Next Domain Name field contains the owner name of the next authoritative owner name in the canonical ordering of the zone; see * Section 6.1 for an explanation of canonical ordering. The value of * the Next Domain Name field in the last NSEC record in the zone is the * name of the zone apex (the owner name of the zone's SOA RR). The circularity is by fact, and @ NSEC @ is by implication: If the last NSEC record is the only (i.e. also the first, or APEX) NSEC, it has its owner name in the Next Domain Name field. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 04:40:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02533 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 04:40:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Ba9RK-0005d8-GX for namedroppers-data@psg.com; Tue, 15 Jun 2004 08:37:06 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Ba9RJ-0005cg-Gm for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 08:37:05 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id DEAD84E2F2; Tue, 15 Jun 2004 10:37:04 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8B1434E1B9; Tue, 15 Jun 2004 10:37:04 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5F8b48r001749; Tue, 15 Jun 2004 10:37:04 +0200 Date: Tue, 15 Jun 2004 10:37:04 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" Message-Id: <20040615103704.678a2dfc.olaf@ripe.net> In-Reply-To: <20040614210836.CE67A13971@sa.vix.com> References: <20040614210836.CE67A13971@sa.vix.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.015336 / 0.0 / 0.0 / disabled X-RIPE-Signature: 726884002fc69ec19f07113d2e5010a4 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 14 Jun 2004 21:08:36 +0000 Paul Vixie <paul@vix.com> wrote: > i asked this in an earlier message but it was lost in the haze of a larger > discussion. here are two NSEC RRs, more or less. > > #1: @ NSEC (SOA NS ...) @ > > #2: X NSEC (...) X > > there are two visible differences between them: one says there's an SOA and > NS at the ownername (@), the other does not (X). and one's owner and target > names are "@" (the zone apex) and the other's owner and target name is "X" > (not the zone apex). > > Having read the other mails. The mention of circularity is unambiguously mentioned in records 4.1.1. The value of the Next Domain Name field in the last NSEC record in the zone is the name of the zone apex Per definition the apex alway exists. Now asume that besides the apex there is only one other record 'X' in the zone, that record X will always have X NSEC @, independent of the amout of labels in X. '@ NSEC @' is just the extreme for X nearing @. It is not a special protocol case it is the special case of a 1-name-only zone. This also implies that for all X where X NSEC X, X is the apex of a zone and white lies will need to be treated as special cases. special cases->special treatment->new corner cases->more delay. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 06:35:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09097 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 06:35:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaBEW-000Hab-Oh for namedroppers-data@psg.com; Tue, 15 Jun 2004 10:32:00 +0000 Received: from [131.174.93.58] (helo=hermes.uci.kun.nl) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaBEV-000HaJ-Dt for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 10:31:59 +0000 Received: from NLnetLabs.nl (vhe-410064.sshn.net [195.169.215.155]) by hermes.uci.kun.nl (PMDF V6.2-X17 #30689) with ESMTP id <0HZC00MHYIMG7S@hermes.uci.kun.nl> for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 12:32:40 +0200 (MEST) Date: Tue, 15 Jun 2004 12:32:50 +0000 From: Jelte Jansen <jelte@NLnetLabs.nl> Subject: Re: DNSKEY flags field In-reply-to: <A63E6F40-BE3B-11D8-B05D-000393DA2D46@ripe.net> To: namedroppers@ops.ietf.org Message-id: <40CEEC72.7070801@NLnetLabs.nl> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.5 (X11/20040602) References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> <20040614120049.59b58a4e.olaf@ripe.net> <a06020410bcf3831c2f76@[192.136.136.83]> <82B0A58A-BE35-11D8-B05D-000393DA2D46@ripe.net> <a06020414bcf3a80b5a54@[192.136.136.83]> <A63E6F40-BE3B-11D8-B05D-000393DA2D46@ripe.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf Kolkman wrote: > > Crypto is not my field of expertise and I maybe heading to circular > reasoning. So to really understand if there is a problem there I would > appreciate a pointer on how difficult it is to generate a SHA1 hash > collision if you have > a number of fixed bits and a number of completely random bits that are > used as an argument. > I am replying to the list, since you do not seem to be the only one who worries about this. Note that I am not a mathematician and therefore also not a real cryptographer, but I do interest myself in these matters :) A good hash function has the following properties: 1) The hash value is completely determined by the complete input. I.e. all bits in the input are used and there are no external sources. 2) The function distributes the 'uniformly' input values over the complete set of possible hash values (the number of collisions for each 3) The function generates very different values for nearly identical inputs (avalanche property: if you change 1 bit in the input, about half of the output bits should change, and it should not be predictable which bits. SHA1 is known to have this property). Combining 2 and 3, it is at least as hard (if at all possible) to find a collision with a number of fixed bits in the input value than it would be to completely brute-force towards a collision (your chances of finding one are equally reduced as your search space). For a limited input size, there might not even be a collision in the set of inputs you have left. Note that I do not have any numbers on it, but I believe they would come in handy both as a way to be sure and as a way to come up with nice expiration times and ttl's. I could try to make some, but I think there are people more suitable to do that than I am. Assuming that SHA1 is a good hashing algorithm (and I do not know of any attacks against it, which is about the only validation you can have in crypto, so it probably is), I think that forging collisions is not a problem here. Jelte -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 06:53:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09844 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 06:53:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaBWe-000K2y-Vu for namedroppers-data@psg.com; Tue, 15 Jun 2004 10:50:44 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaBWd-000K2X-2C for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 10:50:44 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5FAoeWa018394 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 10:50:41 GMT (envelope-from roy+dated+1089888637.0c723b@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5FAocso004476 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 11:50:39 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5FAob27089087 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 11:50:37 +0100 (BST) (envelope-from roy+dated+1089888637.0c723b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5FAobWV089086 for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 11:50:37 +0100 (BST) (envelope-from roy+dated+1089888637.0c723b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 15 Jun 2004 11:50:32 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16590.54392.325819.742708@giles.gnomon.org.uk> Date: Tue, 15 Jun 2004 11:50:32 +0100 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" In-Reply-To: <20040615103704.678a2dfc.olaf@ripe.net> References: <20040614210836.CE67A13971@sa.vix.com> <20040615103704.678a2dfc.olaf@ripe.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Olaf" == Olaf M Kolkman <olaf@ripe.net> writes: Olaf> The mention of circularity is unambiguously mentioned in Olaf> records 4.1.1. Olaf> The value of the Next Domain Name field in the last NSEC Olaf> record in the zone is the name of the zone apex I disagree that it is unambiguous. It is perfectly possible to read the above paragraph as indicating that the last NSEC record in the zone is a special case. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 07:23:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10641 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 07:23:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaBzU-000NAb-L1 for namedroppers-data@psg.com; Tue, 15 Jun 2004 11:20:32 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaBzR-000NA6-WB for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 11:20:30 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i5FBKMrd007384; Tue, 15 Jun 2004 12:20:23 +0100 (BST) To: Jelte Jansen <jelte@NLnetLabs.nl> cc: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: Message from Jelte Jansen <jelte@NLnetLabs.nl> of "Tue, 15 Jun 2004 12:32:50 -0000." <40CEEC72.7070801@NLnetLabs.nl> Date: Tue, 15 Jun 2004 12:20:22 +0100 Message-ID: <7383.1087298422@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Jelte" == Jelte Jansen <jelte@NLnetLabs.nl> writes: Jelte> Assuming that SHA1 is a good hashing algorithm (and I do Jelte> not know of any attacks against it, which is about the only Jelte> validation you can have in crypto, so it probably is), I Jelte> think that forging collisions is not a problem here. Once upon a time, the world thought that MD5 collisions were unlikely. And before that ISTR the same thing being said about a Snefru or some other Merkle(?) hash algorithm. So it would be prudent to assume that one day someone will find SHA collisions, however unlikely that seems to be today. That scenario should however be closed off by allowing for new hash/crypto algorithms to be introduced for DNSSEC: ie SHA-N is "stronger" than SHA-(N-1). Please remember too that just because no attacks have been published, doesn't mean they don't exist. The inventors of DES said they knew about differential cryptanalysis (or at least NSA hinted at it) 20-odd years before Biham and Shamir invented 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 Tue Jun 15 08:05:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12250 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 08:05:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaCbk-0001Sm-K3 for namedroppers-data@psg.com; Tue, 15 Jun 2004 12:00:04 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaCbj-0001SE-D2 for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 12:00:03 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 5F1281FF848; Tue, 15 Jun 2004 12:00:00 +0000 (GMT) Message-ID: <40CEE4BF.1060209@algroup.co.uk> Date: Tue, 15 Jun 2004 12:59:59 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olaf Kolkman <olaf@ripe.net> Cc: Edward Lewis <edlewis@arin.net>, namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> <20040614120049.59b58a4e.olaf@ripe.net> <a06020410bcf3831c2f76@[192.136.136.83]> <82B0A58A-BE35-11D8-B05D-000393DA2D46@ripe.net> <a06020414bcf3a80b5a54@[192.136.136.83]> <A63E6F40-BE3B-11D8-B05D-000393DA2D46@ripe.net> In-Reply-To: <A63E6F40-BE3B-11D8-B05D-000393DA2D46@ripe.net> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf Kolkman wrote: > >>> If we allow proto=4 to be used for DNSKEY validation than we are fine >>> we could >>> 'hack' around this. >> >> >> It wouldn't be so much of a hack if we defined protocol 42 to be >> DNSSECter. DNSSECbis would simple be unable to deal with these keys, >> letting them fall into the bogus category. >> >> Going back to the assumption that I am dealing with a zone that is >> written in DNSSECbis and DNSSECter, and I only understand DNSSECbis, I >> should still see a DS RRset signed with a key designated as DNSSECbis >> protocol. I then have hashes that I ought to be able to apply to the >> the set of keys at the child, even if they are written in DNSSECter. >> I should be able to validate them via the hash, therefore concluding >> what I read is true - that these are all DNSSSECter keys. >> >> At that point, I think it's safe to conclude that I've hit the >> boundary of a DNSSECbis island of security (my version), to use the >> -intro, I've fallen from a DNSSECbis island of security through some >> zones, into a zone with no security. >> >> Instead of SERVFAIL, I return this as unsigned data to someone asking >> for verified data. >> >> If this approach can stand up, I'd prefer it than having to deal with >> the bits of the key flags, for the sake of simplicity. (Lot of if's >> there.) >> > > You are about to convince me but one thing that worries me a crypto > vulnerability. > > Crypto is not my field of expertise and I maybe heading to circular > reasoning. So to really understand if there is a problem there I would > appreciate a pointer on how difficult it is to generate a SHA1 hash > collision if you have > a number of fixed bits and a number of completely random bits that are > used as an argument. > > ( What I am trying to understand is how easy it would be for 'the bad > guys' to create a DNSKEY RR with the appropriate flags, algorithm and > protocol field (that are all fixed) and a public key field that has no > restrictions whatsoever. The only requirement would be that it matches > the parental DS RR, there would be no need for the key blob to be an > actual public key which makes the space in which you try to locate the > hash collision easier to scan. The answer is "impossibly hard". The expected number of keys you would have to try before you found a collision with a particular existing key is 2^159 (10^39). I'm not sure I understand the argument that the key blob needn't be a real public key, but it doesn't matter - 10^39 random blobs is sufficient defence. 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 Tue Jun 15 08:07:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12346 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 08:07:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaCeP-0001tG-7Y for namedroppers-data@psg.com; Tue, 15 Jun 2004 12:02:49 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaCeO-0001sn-8Q for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 12:02:48 +0000 Received: from algroup.co.uk (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 2284B1FF845; Tue, 15 Jun 2004 12:02:47 +0000 (GMT) Message-ID: <40CEE566.7050105@algroup.co.uk> Date: Tue, 15 Jun 2004 13:02:46 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> Cc: DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt References: <20040614205756.A802313951@sa.vix.com> In-Reply-To: <20040614205756.A802313951@sa.vix.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>if you do nothing, then paranoid clients will continue to have very >>>little confidence in spoofed data. if you use a zone-covering NSEC >>>for all responses, then paranoid clients will have high confidence >>>in spoofed data. >> >>Which is one reason why it would be good if there was some signaling >>that denials should not be treated as authenticated: ... > > > if you want non-authenticated denial, maybe you should just leave out > the NSEC altogether. putting your signature on one that covers names > which actually exist, and then leaking that signed "lie" to the universe, > where others could replay or misinterpret it out of context, seems like > a huge mistake to me. This would work for me - but will resolvers be happy with such a response? 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 Tue Jun 15 08:10:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12579 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 08:10:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaCj9-0002kh-Pn for namedroppers-data@psg.com; Tue, 15 Jun 2004 12:07:43 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaCj8-0002kR-SP for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 12:07:43 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 3BC264E118; Tue, 15 Jun 2004 14:07:42 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D22CF6DD4C; Tue, 15 Jun 2004 14:07:41 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5FC7f8r015178; Tue, 15 Jun 2004 14:07:41 +0200 Date: Tue, 15 Jun 2004 14:07:41 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Roy Badami <roy@gnomon.org.uk> Cc: paul@vix.com, namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" Message-Id: <20040615140741.136bad2f.olaf@ripe.net> In-Reply-To: <16590.54392.325819.742708@giles.gnomon.org.uk> References: <20040614210836.CE67A13971@sa.vix.com> <20040615103704.678a2dfc.olaf@ripe.net> <16590.54392.325819.742708@giles.gnomon.org.uk> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.002849 / 0.0 / 0.0 / disabled X-RIPE-Signature: 0053c63dc8bc113929fb8974488e103a X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 15 Jun 2004 11:50:32 +0100 Roy Badami <roy@gnomon.org.uk> wrote: > >>>>> "Olaf" == Olaf M Kolkman <olaf@ripe.net> writes: > > Olaf> The mention of circularity is unambiguously mentioned in > Olaf> records 4.1.1. > > Olaf> The value of the Next Domain Name field in the last NSEC > Olaf> record in the zone is the name of the zone apex > > I disagree that it is unambiguous. It is perfectly possible to read > the above paragraph as indicating that the last NSEC record in the > zone is a special case. > > -roy > Sorry Roy, I do not see an ambiguity. The result of reading the text as a 'special case' is that the name-chain is circular. Note also that reading "special case" does not change my argument that the only name for which X NSEC X can exists is for X==@. A different way of formulating that argument is that the only name for which the NSEC RR points to the apex is the last name in the zone (the special case above). As a concequence if the owner name of the NSEC that points to the apex is the apex itself there are no other names in that domain. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 08:37:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14224 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 08:37:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaD8H-0005mB-L8 for namedroppers-data@psg.com; Tue, 15 Jun 2004 12:33:41 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaD8G-0005lv-Ob for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 12:33:40 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5FCXcWa059732 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 12:33:39 GMT (envelope-from roy+dated+1089894814.02929b@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5FCXZso004868 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 13:33:37 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5FCXYbe089626 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 13:33:34 +0100 (BST) (envelope-from roy+dated+1089894814.02929b@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5FCXYRm089620 for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 13:33:34 +0100 (BST) (envelope-from roy+dated+1089894814.02929b@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 15 Jun 2004 13:33:33 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16590.60572.709440.630675@giles.gnomon.org.uk> Date: Tue, 15 Jun 2004 13:33:32 +0100 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: Roy Badami <roy@gnomon.org.uk>, paul@vix.com, namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" In-Reply-To: <20040615140741.136bad2f.olaf@ripe.net> References: <20040614210836.CE67A13971@sa.vix.com> <20040615103704.678a2dfc.olaf@ripe.net> <16590.54392.325819.742708@giles.gnomon.org.uk> <20040615140741.136bad2f.olaf@ripe.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Olaf" == Olaf M Kolkman <olaf@ripe.net> writes: Olaf> Note also that reading "special case" does not change my Olaf> argument that the only name for which X NSEC X can exists is Olaf> for X==@. I agree that the question is academic if X NSEC X is only allowed at the apex. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 09:30:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16930 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 09:30:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaDwK-000BT7-UD for namedroppers-data@psg.com; Tue, 15 Jun 2004 13:25:24 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaDwJ-000BSh-Gx for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 13:25:24 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i5FDPFrd007505; Tue, 15 Jun 2004 14:25:15 +0100 (BST) To: Roy Badami <roy@gnomon.org.uk> cc: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> of "Tue, 15 Jun 2004 11:50:32 BST." <16590.54392.325819.742708@giles.gnomon.org.uk> Date: Tue, 15 Jun 2004 14:25:15 +0100 Message-ID: <7504.1087305915@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Badami <roy@gnomon.org.uk> writes: Olaf> The mention of circularity is unambiguously mentioned in Olaf> records 4.1.1. Olaf> The value of the Next Domain Name field in the last NSEC Olaf> record in the zone is the name of the zone apex Roy> I disagree that it is unambiguous. It is perfectly possible Roy> to read the above paragraph as indicating that the last NSEC Roy> record in the zone is a special case. In that case, please contribute text that clarifies your perceived ambiguity. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 09:42:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17634 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 09:42:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaEAP-000D5j-9a for namedroppers-data@psg.com; Tue, 15 Jun 2004 13:39:57 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaEAM-000D5P-6g for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 13:39:54 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 36E2919B590; Tue, 15 Jun 2004 09:38:36 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 887B219B570; Tue, 15 Jun 2004 09:38:35 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1775147; Tue, 15 Jun 2004 09:39:52 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020405bcf4aaa2cb07@[192.168.1.100]> In-Reply-To: <16590.60572.709440.630675@giles.gnomon.org.uk> References: <20040614210836.CE67A13971@sa.vix.com> <20040615103704.678a2dfc.olaf@ripe.net> <16590.54392.325819.742708@giles.gnomon.org.uk> <20040615140741.136bad2f.olaf@ripe.net> <16590.60572.709440.630675@giles.gnomon.org.uk> Date: Tue, 15 Jun 2004 09:39:50 -0400 To: Roy Badami <roy@gnomon.org.uk> From: Edward Lewis <edlewis@arin.net> Subject: Re: zone-covering NSEC ranges -- "which is it?" Cc: "Olaf M. Kolkman" <olaf@ripe.net>, Roy Badami <roy@gnomon.org.uk>, paul@vix.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think there are three ways to treat X NSEC X, X != @... 1) It follows the rule for serial arithmetic of names, in line with @ NSEC @, and hinted at by the docs. (*Hinted*) -- but then X NSEC X implies @ does not exist, which we know isn't true 2) It is a special case of the NSEC span saying that "I declare nothing about the rest of the zone." -- but this is not congruent with @ NSEC @, and this makes it a special case 3) Disallow it except at the apex -- this makes it a special case (Did I leave anything out?) It looks like we're caught between a non-sense place and a special case (again). (Why are we trying to solve this again?) Perhaps, looking at #1, we aren't really dealing with "serial name arithmetic" after all. I had always assumed we were, going back to drawings I made in the 90's of the "NXT ring." If not, then "NSEC @" is just a special case of indicating "until the end of the zone." If "NSEC @" is the special case of "the end", X NSEC X makes no (semantic) sense and probably shouldn't be accepted on input (load, update) to an authoritative server. At 13:33 +0100 6/15/04, Roy Badami wrote: >>>>>> "Olaf" == Olaf M Kolkman <olaf@ripe.net> writes: > > Olaf> Note also that reading "special case" does not change my > Olaf> argument that the only name for which X NSEC X can exists is > Olaf> for X==@. > >I agree that the question is academic if X NSEC X is only allowed at >the apex. > > -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/> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 09:53:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18323 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 09:53:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaEJl-000ECS-Ki for namedroppers-data@psg.com; Tue, 15 Jun 2004 13:49:37 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaEJi-000EBf-E5 for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 13:49:34 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 15 Jun 2004 09:49:32 -0400 id 001379E4.40CEFE6C.00004EBC From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" Date: Tue, 15 Jun 2004 09:49:33 -0400 User-Agent: KMail/1.6.2 References: <20040614210836.CE67A13971@sa.vix.com> <20040615103704.678a2dfc.olaf@ripe.net> In-Reply-To: <20040615103704.678a2dfc.olaf@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406150949.33378.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 15 June 2004 4:37 am, Olaf M. Kolkman wrote: > On Mon, 14 Jun 2004 21:08:36 +0000 > > Paul Vixie <paul@vix.com> wrote: > > i asked this in an earlier message but it was lost in the haze of a > > larger discussion. here are two NSEC RRs, more or less. > > > > #1: @ NSEC (SOA NS ...) @ > > > > #2: X NSEC (...) X > > > > there are two visible differences between them: one says there's an SOA > > and NS at the ownername (@), the other does not (X). and one's owner > > and target names are "@" (the zone apex) and the other's owner and target > > name is "X" (not the zone apex). > > Having read the other mails. > > The mention of circularity is unambiguously mentioned in records 4.1.1. > > The value of the Next Domain Name field in the last NSEC record in > the zone is the name of the zone apex > special cases->special treatment->new corner cases->more delay. I will note that -protocol-06 is missing language for handling this last record NSEC case. From -protocol-06, section 5.4: o If the requested RR name would appear after an authenticated NSEC RR's owner name and before the name listed in that NSEC RR's Next Domain Name field according to the canonical DNS name order defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with the requested name exist in the zone. (This is the first sentence of the second bullet in this section. I couldn't find any other more relevant text in the draft). This may present an Opportunity to define the interpretation of this case of NSEC records in a way advantageous to a "white lies" strategy. Or perhaps not. -- 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 Tue Jun 15 10:01:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18673 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 10:01:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaEOD-000Eoq-Mk for namedroppers-data@psg.com; Tue, 15 Jun 2004 13:54:13 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaEOC-000Eob-O2 for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 13:54:12 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id AA05519B77E; Tue, 15 Jun 2004 09:52:54 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id EF27819B77E; Tue, 15 Jun 2004 09:52:53 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1775241; Tue, 15 Jun 2004 09:54:11 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020406bcf4acb747dc@[192.168.1.100]> In-Reply-To: <40CEEC72.7070801@NLnetLabs.nl> References: <ilufz9332at.fsf@latte.josefsson.org> <a06020432bcee308cd16a@[192.136.136.83]> <ilubrjr2yq1.fsf@latte.josefsson.org> <a06020436bcee382f9bbc@[192.136.136.83]> <20040611095744.39b826ab.olaf@ripe.net> <a06020404bcef7c93b348@[192.136.136.83]> <20040614120049.59b58a4e.olaf@ripe.net> <a06020410bcf3831c2f76@[192.136.136.83]> <82B0A58A-BE35-11D8-B05D-000393DA2D46@ripe.net> <a06020414bcf3a80b5a54@[192.136.136.83]> <A63E6F40-BE3B-11D8-B05D-000393DA2D46@ripe.net> <40CEEC72.7070801@NLnetLabs.nl> Date: Tue, 15 Jun 2004 09:50:17 -0400 To: Jelte Jansen <jelte@NLnetLabs.nl> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:32 +0000 6/15/04, Jelte Jansen wrote: >Olaf Kolkman wrote: >> Crypto is not my field of expertise and I maybe heading to >>circular reasoning. So to really understand if there is a problem >>there I would appreciate a pointer on how difficult it is to >>generate a SHA1 hash collision if you have >> a number of fixed bits and a number of completely random bits that >>are used as an argument. >> > >I am replying to the list, since you do not seem to be the only one >who worries about this. > >Note that I am not a mathematician and therefore also not a real >cryptographer, but I do interest myself in these matters :) > >A good hash function has the following properties: Crypto, shmipto. Okay, I'm satisfied that the DS hash of a key is about as good as a "proof" of a key's validity as any RRSIG out there. I.e., if the DS hash passes for a DNSKEY RR, checking the RRSIG(DNSKEY) doesn't get you that much more "crypto-security." Yes, more checks are better than less checks (usually), but there's a point where we are being too perfect. However, the issue remains that if you don't validate the RRSIG you don't get to validate the child zone's signature validation period. (This is the only reason why I didn't try *at all* to get us to *not* sign the DNSKEY RR set after we studied the DS RR.) I think the real question still is: if I can validate the DS RR can I can conclude an "end of useful" security because the DNSKEY RR's in the child are unusable to me? It's yes, if you are willing to accept the parent's RRSIG validity time as important, it's no if you want to hear from the child. Maybe it is yes. If the parent has a DS RR set that is now valid, and points to bad keys (in the eyes of the resolver), but the child has a fresher set that has some good keys - can the resolver ever make use of them? I think not, because there's no reason the resolver will get "pointed" to the "good" keys in a verifiable manner. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 10:57:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23503 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 10:57:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaFIH-000LYG-E8 for namedroppers-data@psg.com; Tue, 15 Jun 2004 14:52:09 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaFIE-000LXb-AJ for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 14:52:06 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 15 Jun 2004 10:52:05 -0400 id 0014B19B.40CF0D15.000061D6 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Date: Tue, 15 Jun 2004 10:52:05 -0400 User-Agent: KMail/1.6.2 References: <ilufz9332at.fsf@latte.josefsson.org> <40CEEC72.7070801@NLnetLabs.nl> <a06020406bcf4acb747dc@[192.168.1.100]> In-Reply-To: <a06020406bcf4acb747dc@[192.168.1.100]> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406151052.05500.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 15 June 2004 9:50 am, Edward Lewis wrote: > I think the real question still is: if I can validate the DS RR can I > can conclude an "end of useful" security because the DNSKEY RR's in > the child are unusable to me? So... If I (being a security-aware resolver/validator) have: * followed a secure delegation (that is, I found and verified one or more DS records), * then, when I fetch the child's DNSKEY RRset, I am able to match *all* of the DS records in hand to DNSKEY RRs, * yet none of them are usable (i.e., proto=4). I am thinking that one could securely conclude that this was the intent of the zone publisher and thus am comfortable treating this delegation as an Insecure delegation. Another way to ask this question: Is there any way for an attacker to downgrade a zone using this technique? I am presuming that the childs DNSKEY RRset is unable to be validated, although that may not matter greatly. I can see that if, for instance, one did not require that all of the DS records match proto>3 keys, you would have a problem: the parent could have one DS record for a proto=4 key and one for a proto=3 key, and that attacker could have stripped (or altered) the childs proto=3 key, thus downgrading the zone. > It's yes, if you are willing to accept the parent's RRSIG validity > time as important, it's no if you want to hear from the child. > Maybe it is yes. If the parent has a DS RR set that is now valid, > and points to bad keys (in the eyes of the resolver), but the child > has a fresher set that has some good keys - can the resolver ever > make use of them? I think not, because there's no reason the > resolver will get "pointed" to the "good" keys in a verifiable > manner. I think that you are correct. So far, using proto>3 (or Simon's DNSKEY flags) looks somewhat promising to me as an alternate way to do DNSSEC-ter. I will note that this technique might (slightly) increase the complexity of the validator. Without this technique, a validator will always be able to determine the security status of the child just by looking at the parent's delegation point. With this technique, it would have to be able to make this distinction after fetching the child's DNSKEY set. I cannot tell if this would present a problem. -- 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 Tue Jun 15 11:34:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27284 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 11:34:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaFth-0000ke-Go for namedroppers-data@psg.com; Tue, 15 Jun 2004 15:30:49 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaFtg-0000k0-6x for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 15:30:48 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5FFUjWa025462 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 15:30:46 GMT (envelope-from roy+dated+1089905442.e928ec@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5FFUgso005619 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 16:30:44 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5FFUg7d090735 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 16:30:42 +0100 (BST) (envelope-from roy+dated+1089905442.e928ec@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5FFUgju090734 for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 16:30:42 +0100 (BST) (envelope-from roy+dated+1089905442.e928ec@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Tue, 15 Jun 2004 16:30:05 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16591.5628.937613.73424@giles.gnomon.org.uk> Date: Tue, 15 Jun 2004 16:30:04 +0100 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: Roy Badami <roy@gnomon.org.uk>, paul@vix.com, namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" In-Reply-To: <20040615140741.136bad2f.olaf@ripe.net> References: <20040614210836.CE67A13971@sa.vix.com> <20040615103704.678a2dfc.olaf@ripe.net> <16590.54392.325819.742708@giles.gnomon.org.uk> <20040615140741.136bad2f.olaf@ripe.net> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Olaf" == Olaf M Kolkman <olaf@ripe.net> writes: Olaf> The mention of circularity is unambiguously mentioned in Olaf> records 4.1.1. >> Olaf> The value of the Next Domain Name field in the last NSEC Olaf> record in the zone is the name of the zone apex >> I disagree that it is unambiguous. It is perfectly possible >> to read the above paragraph as indicating that the last NSEC >> record in the zone is a special case. Olaf> Sorry Roy, I do not see an ambiguity. Ok, the two interpretations I see are: 1. The Next Domain Name field _normally_ contains the owner name of the next RRset in canonical ordering. But the paragraph you quote overrides that, and says that in the case of the last owner name in the zone, the Next Domain Name field contains the apex name (by implication _instead_ of containing the next owner name). There is hence no implication that the apex actually _is_ the next owner name in canonical ordering. 2. The Next Domain Name field _always_ contains the owner name of the next RRset in canonical ordering. Therefore by stating that the Next Domain Name field contains the apex name, you implicitly state that the apex is the next name in canonical ordering. As you point out, the distinction is immaterial unless it is deemed meaningful to have X NSEC X where X =/= @ (or X NSEC Y where Y precedes X in canonical ordering but Y is not @). Jim> In that case, please contribute text that clarifies your Jim> perceived ambiguity. It's not clear that there's a need, or that there is consensus as to which of the two above interpretations is desired... -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 11:38:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27553 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 11:38:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaFya-0001Lf-Op for namedroppers-data@psg.com; Tue, 15 Jun 2004 15:35:52 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaFyZ-0001LP-UA for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 15:35:52 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 9339219B530; Tue, 15 Jun 2004 11:34:32 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 0E77219B4D6; Tue, 15 Jun 2004 11:34:32 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1775673; Tue, 15 Jun 2004 11:35:50 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020410bcf4c63240a3@[192.168.1.100]> In-Reply-To: <200406151052.05500.davidb@verisignlabs.com> References: <ilufz9332at.fsf@latte.josefsson.org> <40CEEC72.7070801@NLnetLabs.nl> <a06020406bcf4acb747dc@[192.168.1.100]> <200406151052.05500.davidb@verisignlabs.com> Date: Tue, 15 Jun 2004 11:35:46 -0400 To: David Blacka <davidb@verisignlabs.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:52 -0400 6/15/04, David Blacka wrote: >So far, using proto>3 (or Simon's DNSKEY flags) looks somewhat >promising to me as an alternate way to do DNSSEC-ter. I will note >that this technique might (slightly) increase the complexity of the >validator. Without this technique, a validator will always be able to >determine the security status of the child just by looking at the >parent's delegation point. With this technique, it would have to be >able to make this distinction after fetching the child's DNSKEY set. >I cannot tell if this would present a problem. Referring to the last sentence first, I think it's acceptable because going to the child means you are going closer to the authority. And it's no worse that the case of "bad algorithms." I think we might be able to have no more complexity in the (design of the) validator. This is based on the observation that the case of (proto > 3) keys is the same as the case of (proto = 3 && algorithm != ones-I-understand). Note: This is an uneducated view of someone that has not written a validator in eons. (I know we "require" mandatory to implement, but a validator's code will have to deal with the situation that the set has no mandatory to implement keys - because "mandatory to implement" does not mean "mandatory to use.") -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 11:42:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27828 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 11:42:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaG2b-0001ni-AE for namedroppers-data@psg.com; Tue, 15 Jun 2004 15:40:01 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaG2Z-0001mm-Tm for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 15:40:00 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i5FFdVP12373 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 15 Jun 2004 11:39:45 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5FFdV36002269 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Jun 2004 11:39:31 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5FFdT4t002266; Tue, 15 Jun 2004 11:39:30 -0400 To: David Blacka <davidb@verisignlabs.com> cc: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> of "Tue, 15 Jun 2004 10:52:05 EDT." <200406151052.05500.davidb@verisignlabs.com> References: <ilufz9332at.fsf@latte.josefsson.org> <40CEEC72.7070801@NLnetLabs.nl> <a06020406bcf4acb747dc@[192.168.1.100]> <200406151052.05500.davidb@verisignlabs.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Tue, 15 Jun 2004 11:39:29 -0400 Message-ID: <2265.1087313969@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Blacka <davidb@verisignlabs.com> writes: >> I think the real question still is: if I can validate the DS RR >> can I can conclude an "end of useful" security because the DNSKEY >> RR's in the child are unusable to me? David> So... If I (being a security-aware resolver/validator) have: David> * followed a secure delegation (that is, I found and David> verified one or more DS records), David> * then, when I fetch the child's DNSKEY RRset, I am able to David> match *all* of the DS records in hand to DNSKEY RRs, The "in hand" worries me. I assume you verified all of the DS records that there were. Are there possibly DNSKEY RRs which have no corresponding DS record left? David> I am thinking that one could securely conclude that this was David> the intent of the zone publisher and thus am comfortable David> treating this delegation as an Insecure delegation. I think so too. David> Another way to ask this question: Is there any way for an David> attacker to downgrade a zone using this technique? An attacker can remove one of the DS records, but the DNSSIG(DS) will catch that. An attacker can remove one of the DNSKEY records, but you said you matched each DS to a record, so that would be detected. If you found a KSK, the DNSSIG(DNSKEY) would prove that too. David> I am presuming that the childs DNSKEY RRset is unable to be David> validated, although that may not matter greatly. Depends upon how pathological a situation you want to deal with. David> I can see that if, for instance, one did not require that all David> of the DS records match proto>3 keys, you would have a David> problem: the parent could have one DS record for a proto=4 David> key and one for a proto=3 key, and that attacker could have David> stripped (or altered) the childs proto=3 key, thus David> downgrading the zone. Won't that fail the DS hash though? (I guess I need to review what DS hashes) David> technique, a validator will always be able to determine the David> security status of the child just by looking at the parent's David> delegation point. With this technique, it would have to be David> able to make this distinction after fetching the child's David> DNSKEY set. I cannot tell if this would present a problem. If we say this soon, I think we are okay. No flag days in upgrading software to be more careful. - -- ] "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 iQCVAwUBQM8YL4qHRg3pndX9AQES5QP/QxG7MWj+5ErefvdU/NcZxr157n/RtpZQ keVfMkxljYIOLO/AaLxlM/NXDkF5V9+B0nbO1ti4F7oJOVzxz8xifAUVxYHpWdzB 8QME5+pqtgEXEIp1Y3ZLgHWFG+UlEI0auUXDxXBuftHmkxY7htH6qcZsRwPVddmq rHebMI833NE= =DcWq -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 11:51:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28518 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 11:51:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaGAu-00031J-OR for namedroppers-data@psg.com; Tue, 15 Jun 2004 15:48:36 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaGAr-00030Q-Bj for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 15:48:33 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id C69474EC56; Tue, 15 Jun 2004 17:29:47 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 65C924E74B; Tue, 15 Jun 2004 17:29:47 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5FFTl8r014938; Tue, 15 Jun 2004 17:29:47 +0200 Date: Tue, 15 Jun 2004 17:29:47 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: David Blacka <davidb@verisignlabs.com> Cc: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" Message-Id: <20040615172947.6dd2bc04.olaf@ripe.net> In-Reply-To: <200406150949.33378.davidb@verisignlabs.com> References: <20040614210836.CE67A13971@sa.vix.com> <20040615103704.678a2dfc.olaf@ripe.net> <200406150949.33378.davidb@verisignlabs.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000037 / 0.0 / 0.0 / disabled X-RIPE-Signature: e65bf37e6e864bb72ae602045bdc045d X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 15 Jun 2004 09:49:33 -0400 > > I will note that -protocol-06 is missing language for handling this last > record NSEC case. From -protocol-06, section 5.4: > > o If the requested RR name would appear after an authenticated NSEC > RR's owner name and before the name listed in that NSEC RR's Next > Domain Name field according to the canonical DNS name order > defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with > the requested name exist in the zone. > > (This is the first sentence of the second bullet in this section. I couldn't > find any other more relevant text in the draft). > > This may present an Opportunity to define the interpretation of this case of > NSEC records in a way advantageous to a "white lies" strategy. Or perhaps > not. Other angle into the discussion, it is indeed getting a little academic. Given that you would want to use X NSEC X for 'white lies'. Do you need changes to DNSSEC-bis? The question is what to do, following DNSSEC-bis when you receive an X NSEC X whith a signature that is not generated with a key X DNSKEY but with a key Y DNSKEY where Y is closer to the root. Can you verify that record? Sure, if there is no DS (or an NSEC RR that proves its nonexistence) between Y and X you can use signatures generated by Y. There is a valid chain of trust. But the record would also tell me, strictly speaking there are no subdomains below X. Two things I had to think of. = Caching of NSECs Think of the other thread on protocol-06 section 4.5 where we are trying to be as liberal as we can with respect to reuse of cached NSEC records. There we say that if you re-use NSEC RRs to proof anything about other names than for the <QNAME, QCLASS, QTYPE> you orriginally queried for you are in for problems (it is SHOULD NOT language). In other words you should not reuse the X NSEC X to proof the existence of Z in a subdomain of X. The specs are fine. = Replay attack. Can an attacker abuse the parental X NSEC X in a replay attack against a resolver querying for a subzone of X. ( foo.co.uk NSEC foo.co.uk exists in co.uk www.foo.co.uk exists and is secured. client queries for www.foo.co.uk client receives a spoofed NXDOMAIN with foo.co.uk NSEC foo.co.uk DNSSIG by co.uk ) In theory this spoof would work with DNSSEC-bis. But we have a hook to deal with it. You can tell from which side of the delegation point the NSEC RR was received. That is you can make a distinction between white lies and authoritative non-existence of subdomains by looking at the SOA bit in the NSEC type bitmap. So you have to specify the white lie as a special case in order to prevent a replay attack. Something like Validators receiving "X NSEC X" records MUST only use these records for the nonexistence of names below X if the SOA bit of the NSEC RR bitmap is set. will need to go into the specs. I think this means that 'white lies' cannot be deployed withouth a change to DNSSEC-bis. Is the change you would need significant enough in terms of security analysis, code changes, etc to try and _not_ persue it (?). -- Olaf No Hats ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 12:00:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29111 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 12:00:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaGID-0004TV-PS for namedroppers-data@psg.com; Tue, 15 Jun 2004 15:56:09 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaGIC-0004TA-Qs for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 15:56:09 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 31C3F19B4EE; Tue, 15 Jun 2004 11:54:49 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 6B3D319B34E; Tue, 15 Jun 2004 11:54:48 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1775755; Tue, 15 Jun 2004 11:56:07 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020411bcf4ca4835dd@[192.168.1.100]> In-Reply-To: <16591.5628.937613.73424@giles.gnomon.org.uk> References: <20040614210836.CE67A13971@sa.vix.com> <20040615103704.678a2dfc.olaf@ripe.net> <16590.54392.325819.742708@giles.gnomon.org.uk> <20040615140741.136bad2f.olaf@ripe.net> <16591.5628.937613.73424@giles.gnomon.org.uk> Date: Tue, 15 Jun 2004 11:56:05 -0400 To: Roy Badami <roy@gnomon.org.uk> From: Edward Lewis <edlewis@arin.net> Subject: Re: zone-covering NSEC ranges -- "which is it?" Cc: "Olaf M. Kolkman" <olaf@ripe.net>, Roy Badami <roy@gnomon.org.uk>, paul@vix.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:30 +0100 6/15/04, Roy Badami wrote: >Ok, the two interpretations I see are: > >1. The Next Domain Name field _normally_ contains the owner name of > the next RRset in canonical ordering. But the paragraph you quote > overrides that, and says that in the case of the last owner name in > the zone, the Next Domain Name field contains the apex name (by > implication _instead_ of containing the next owner name). There is > hence no implication that the apex actually _is_ the next owner > name in canonical ordering. > >2. The Next Domain Name field _always_ contains the owner name of the > next RRset in canonical ordering. Therefore by stating that the > Next Domain Name field contains the apex name, you implicitly state > that the apex is the next name in canonical ordering. > I agree with Roy's point here. As much as I liked the idea of serial number arithmetic rules applying, we know there's an exception because the apex exists. Therefore trying to apply serial number principles is not correct. >As you point out, the distinction is immaterial unless it is deemed >meaningful to have X NSEC X where X =/= @ (or X NSEC Y where Y >precedes X in canonical ordering but Y is not @). > > Jim> In that case, please contribute text that clarifies your > Jim> perceived ambiguity. > >It's not clear that there's a need, or that there is consensus as to >which of the two above interpretations is desired... What I like about Roy's presentation is that he stresses "_normally_" and "_always_". The only reason that we are talking about this is a proposed contortion of the intent of the record to retro-fit in a new requirement. The ambiguity isn't the problem, it's the contortion that's the issue. I think the problem isn't the specifications. The problem is that we are trying to "lie" with NSEC's to achieve obfuscation, something the NSEC wasn't built to do originally. Tying threads together, I think it's more promising to define what a verifier does to proto != 3 keys and then leave obfuscation (name hiding) to something in proto = 4 of DNSSEC that is designed to do just that. I think that's more promising than trying to haggle over the meaning of "X NSEC X." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 12:17:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29796 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 12:17:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaGYz-0006Zv-Fo for namedroppers-data@psg.com; Tue, 15 Jun 2004 16:13:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaGYy-0006Zh-NJ for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 16:13:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8982913951 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 16:13:27 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> of "Tue, 15 Jun 2004 10:52:05 -0400." <200406151052.05500.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 15 Jun 2004 16:13:27 +0000 Message-Id: <20040615161327.8982913951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So... If I (being a security-aware resolver/validator) have: > > * followed a secure delegation (that is, I found and verified one or > more DS records), > > * then, when I fetch the child's DNSKEY RRset, I am able to match > *all* of the DS records in hand to DNSKEY RRs, > > * yet none of them are usable (i.e., proto=4). > > I am thinking that one could securely conclude that this was the > intent of the zone publisher and thus am comfortable treating this > delegation as an Insecure delegation. > > I am presuming that the childs DNSKEY RRset is unable to be > validated, although that may not matter greatly. that's a tautology. you won't be able to use the keys necessary to validate the self-signature on the keys. so in fact, the inability to validate the dnskey rrset will be the driving issue. > Another way to ask this question: Is there any way for an attacker to > downgrade a zone using this technique? i don't think so. > I can see that if, for instance, one did not require that all of the > DS records match proto>3 keys, you would have a problem: the parent > could have one DS record for a proto=4 key and one for a proto=3 key, > and that attacker could have stripped (or altered) the childs proto=3 > key, thus downgrading the zone. that's similar to all forms of "can corrupt the secure part of the zone" attacks, and isn't new with (proto>3). > > It's yes, if you are willing to accept the parent's RRSIG validity > > time as important, it's no if you want to hear from the child. > > > Maybe it is yes. If the parent has a DS RR set that is now valid, > > and points to bad keys (in the eyes of the resolver), but the child > > has a fresher set that has some good keys - can the resolver ever > > make use of them? I think not, because there's no reason the > > resolver will get "pointed" to the "good" keys in a verifiable > > manner. > > I think that you are correct. me too. but it's worth noting that this is a protocol failing, not an attack vector. > So far, using proto>3 (or Simon's DNSKEY flags) looks somewhat > promising to me as an alternate way to do DNSSEC-ter. I will note > that this technique might (slightly) increase the complexity of the > validator. Without this technique, a validator will always be able to > determine the security status of the child just by looking at the > parent's delegation point. With this technique, it would have to be > able to make this distinction after fetching the child's DNSKEY set. > I cannot tell if this would present a problem. i think it's a problem, and it leads me to the opposite conclusion. the proto field is worthless for -trans, simply because not every metadata rr has it. by the time you've gone looking for the information you need to know to determine whether you should trust what you saw, you already had to trust it to do the looking, so what you find is a wider source of possible failures, but not a wider source of possible successes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 12:30:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00725 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 12:30:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaGlO-00083u-Sy for namedroppers-data@psg.com; Tue, 15 Jun 2004 16:26:18 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaGlN-00083f-Te for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 16:26:18 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 1EC4819B68C; Tue, 15 Jun 2004 12:07:50 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 660E919B34E; Tue, 15 Jun 2004 12:07:49 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1775812; Tue, 15 Jun 2004 12:09:08 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020412bcf4ccf1d59a@[192.168.1.100]> In-Reply-To: <2265.1087313969@marajade.sandelman.ottawa.on.ca> References: <ilufz9332at.fsf@latte.josefsson.org> <40CEEC72.7070801@NLnetLabs.nl> <a06020406bcf4acb747dc@[192.168.1.100]> <200406151052.05500.davidb@verisignlabs.com> <2265.1087313969@marajade.sandelman.ottawa.on.ca> Date: Tue, 15 Jun 2004 12:09:06 -0400 To: Michael Richardson <mcr@sandelman.ottawa.on.ca> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: David Blacka <davidb@verisignlabs.com>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:39 -0400 6/15/04, Michael Richardson wrote: > The "in hand" worries me. For good reason. > I assume you verified all of the DS records that there were. I assume that we begin with: one RRSIG(DS) has verified the DS set, and that for each DS RR in the set, a corresponding DNSKEY was found. (Whether there are other DNSKEYs present or absent(stripped) or not ...) > Are there possibly DNSKEY RRs which have no corresponding DS record >left? They wouldn't do any good. Members of the DNSKEY set that are not referred to by the DS RR set are not acceptable entry points. What's to keep an attacker from adding a DNSKEY I can grok and adding an RRSIG(DNSKEY) to "prove it." ... > An attacker can remove one of the DS records, but the DNSSIG(DS) will >catch that. Most certainly. > An attacker can remove one of the DNSKEY records, but you said you >matched each DS to a record, so that would be detected. If you found a >KSK, the DNSSIG(DNSKEY) would prove that too. Not necessarily, but I think it's an interpretation thing. E.g., Lets say that the DS set as pointers to A, B, C, and the DNSKEY set at the authoritative servers has A, B, C, D. If D is stripped, I can't tell without a useable RRSIG(DNSKEY). If C is stripped, the DS is sufficient to detect that. > David> I am presuming that the childs DNSKEY RRset is unable to be > David> validated, although that may not matter greatly. > > Depends upon how pathological a situation you want to deal with. That would happen if the validator can't process A, B, C keys, even if D is understandable. > David> I can see that if, for instance, one did not require that all > David> of the DS records match proto>3 keys, you would have a > David> problem: the parent could have one DS record for a proto=4 > David> key and one for a proto=3 key, and that attacker could have > David> stripped (or altered) the childs proto=3 key, thus > David> downgrading the zone. > > Won't that fail the DS hash though? > (I guess I need to review what DS hashes) The DS hash "points" to a DNSKEY RR. So, we can line up the "proven" by parent keys. > > David> technique, a validator will always be able to determine the > David> security status of the child just by looking at the parent's > David> delegation point. With this technique, it would have to be > David> able to make this distinction after fetching the child's > David> DNSKEY set. I cannot tell if this would present a problem. > > If we say this soon, I think we are okay. > No flag days in upgrading software to be more careful. I beginning to think that this, which I think is merely an extension of the problem of mismatched algorithms, is a promising way to go forward. But, note that DNSSECbis era (proto=3) will treat the "enhanced" proto=4 zones as unsecured. But that's the verifier's problem, not the servers'! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 13:02:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29806 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 12:17:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaGZ2-0006aI-5R for namedroppers-data@psg.com; Tue, 15 Jun 2004 16:13:32 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaGZ0-0006a0-Py for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 16:13:31 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 15 Jun 2004 12:08:29 -0400 id 0010B201.40CF1EFD.00007A1E From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: zone-covering NSEC ranges -- "which is it?" Date: Tue, 15 Jun 2004 12:08:29 -0400 User-Agent: KMail/1.6.2 References: <20040614210836.CE67A13971@sa.vix.com> <200406150949.33378.davidb@verisignlabs.com> <20040615172947.6dd2bc04.olaf@ripe.net> In-Reply-To: <20040615172947.6dd2bc04.olaf@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406151208.29850.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 15 June 2004 11:29 am, Olaf M. Kolkman wrote: > On Tue, 15 Jun 2004 09:49:33 -0400 > > > I will note that -protocol-06 is missing language for handling this last > > record NSEC case. From -protocol-06, section 5.4: > > > > o If the requested RR name would appear after an authenticated NSEC > > RR's owner name and before the name listed in that NSEC RR's Next > > Domain Name field according to the canonical DNS name order > > defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with > > the requested name exist in the zone. > > > > (This is the first sentence of the second bullet in this section. I > > couldn't find any other more relevant text in the draft). > > > > This may present an Opportunity to define the interpretation of this case > > of NSEC records in a way advantageous to a "white lies" strategy. Or > > perhaps not. > > Other angle into the discussion, it is indeed getting a little > academic. Given that you would want to use X NSEC X for 'white > lies'. Do you need changes to DNSSEC-bis? I personally have no stake in the 'white lies' scheme. I merely pointed out that there might be an opportunity to add some language here that might make it easier to do. To be clear, though, I *do* believe that language needs to be added to section 5.4 to handle the X-NSEC-@ case. Whether or not this language allows for things like X-NSEC-X is up to the WG. The default should be in the spirit of 2535, however, like: If the requested RR name would appear after an authenticated NSEC RR's owner name and before the name listed in that NSEC RR's Next Domain Name field according to the canonical DNS name order defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with the requested name exist in the zone. Or, if the Next Domain Name field is the zonename (thus indicating that the NSEC's owner name is the last name in the zone's canonical ordering), then if the request RR name would appear after the NSEC's owner name, no RRsets with the requested name exist in the zone. That might be a bit too clumisly said, however. -- 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 Tue Jun 15 14:46:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07982 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 14:46:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaIsQ-000MTp-2F for namedroppers-data@psg.com; Tue, 15 Jun 2004 18:41:42 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaIsD-000MSE-Tj for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 18:41:30 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 3C84C19B36B; Tue, 15 Jun 2004 14:40:08 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 837B019B395; Tue, 15 Jun 2004 14:40:07 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1776622; Tue, 15 Jun 2004 14:41:28 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020413bcf4e707f29f@[192.168.1.100]> In-Reply-To: <20040615161327.8982913951@sa.vix.com> References: <20040615161327.8982913951@sa.vix.com> Date: Tue, 15 Jun 2004 14:39:35 -0400 To: Paul Vixie <paul@vix.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:13 +0000 6/15/04, Paul Vixie wrote: >i think it's a problem, and it leads me to the opposite conclusion. the >proto field is worthless for -trans, simply because not every metadata rr >has it. by the time you've gone looking for the information you need to >know to determine whether you should trust what you saw, you already had >to trust it to do the looking, so what you find is a wider source of >possible failures, but not a wider source of possible successes. I'm not following your logic. Let's say I start by getting an answer RR set and the RRSIG(s). I go off and ask for the DNSKEY RR for each RRSIG interatively - let's say the retrieval is recursive. So, when I get a return from the function to get the DNSKEY identified by the RRSIG, I get either success and then validate the signature, or I get a failure. (If successful, I break the iterations.) If there are no acceptable DNSKEYs to use after all iterations, there's no validation to be done. (Note that the key specified in the RRSIG need not be in the same *domain* as the answer, I might "chase" it if my local policy so allows.) But all is not lost, I perhaps there was no "security to be expected" to begin with. So, I look to my trusted keys, choose the closest enclosing one for the query and follow it down the zone cuts to my data. It makes no sense to go to a more general encloser as I presumably only configure keys I can make sense of. (I'm not espousing this to be the way to write the code, it's just an algorithm. The details between algorithm and implementation might hold the missing link that prevents me from following the logic above.) What I would expect to find (looking at the closest trusted key to the answer) is an island of security "relative to me, my capabilities and policy." There are keys of my chosen algorithms, and of my chosen protocol version(s), etc. As I descend through or from (depending on what you consider the island to be) the island via zone cuts, I'll either get to the desired zone or find an "end of security" relative to me (the verifier). If I get to the data I want, well something fubar'ed earlier and I might be able to do validation after all. If I find the "end of security," I can conclude that finding no key for any signature wasn't a problem. "End of security" might be running out of protocol={me} or algorithm={what I can do} or just a NSEC saying there's no DS set. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 17:23:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17458 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 17:23:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaLBN-000BnO-Bw for namedroppers-data@psg.com; Tue, 15 Jun 2004 21:09:25 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaLBI-000Bmb-Tx for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 21:09:22 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BaLBH-0003Nc-00 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 23:09:19 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 23:09:19 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 23:09:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: DNSKEY flags field Date: Tue, 15 Jun 2004 23:09:14 +0200 Lines: 82 Message-ID: <iluisds8r5x.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> <ilu7jua3sb0.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:QbiCCXd+tH/cyg3YZZ9bVHKLC9s= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka <davidb@verisignlabs.com> writes: > On Monday 14 June 2004 2:31 pm, Simon Josefsson wrote: >> David Blacka <davidb@verisignlabs.com> writes: > >> > The term "bogus" is defined in draft-ietf-dnsext-dnssec-intro-10, section >> > 5, and again in -dnssec-protocol-06, section 4.3. As specified, when a >> > validator determines that a responses is bogus, for whatever reason, it >> > returns SERVFAIL. >> >> Thanks for the pointers. Where is the requirement to respond with >> SERVFAIL described? Or more generally, where is resolver behaviour >> when resolvers receive bogus data discussed? > > In -intro-10 this is discussed later in the same section (5): > > This specification only defines how security aware name servers can > signal non-validating stub resolvers that data was found to be > bogus (using RCODE=2, "Server Failure" -- see > [I-D.ietf-dnsext-dnssec-protocol]). Thanks. This is CD=0, right? Stub resolvers do not want to validate DNSKEY's, so if the DNSKEY is proto=3 or proto=4, they wouldn't care. I'm more interested in how the name server for the stub resolver behave. > In -protocol-06, this is stated (sort of) in section 5.5. Although > that language is talking about what happens when RRSIGs do not > validate, specifically. It is also mentioned briefly in section > 3.2.2 in the context of the CD bit. I think this is getting to the core of the issue. Can we assume that name servers will not treat responses with both DNSKEY proto=3 and proto=4 as BAD? If so, I believe we have an migration path to a DNSSECter in proto=4 (or, as I prefer, via bits 8-14). > Note to the dnssec-editors: I think that we want to make clear that > SERVFAIL is returned not just when RRset fails to validate, but in all > situations where "bogus" applies. This is clear (to me, anyway) from > the language in -intro-10, but it is not mirrored in -protocol (that I > could find). Just make sure responses with partial bogus and partial good DNSKEYs will not be regarded as bogus, but instead good. > I do not see how the protocol field can be used for extensions. Maybe > I just don't understand what you mean by "extensions"? Yes, I haven't been clear. Let me try one idea of what I'm envisioning. I'm seeing proto=4 (or "critical bits") as a vehicle for a migration mechanism to DNSSECter, at end nodes, which can work smoothly with only DNSSECbis deployed in the infrastructure. If a DNSSECter use the same RRs, with the same owner names, and DNSSECbis resolvers will happily ignore proto=4 DNSKEYs as long as they see working proto=3 DNSKEYs, they will forward the proto=4 DNSKEYs (together with the proto=3 which it itself understand) to any clients (since it is needed by DNSSECbis client to verify the DNSKEY RRset RRSIG). If, eventually, the client understand DNSSECter, it can validate the response using DNSSECter instead of DNSSECbis, even though all middle name servers didn't understand DNSSECter. Is this any more clear? I understand I haven't made this point clear, but this has only been one aspect of things, and not the most important that I thought of to describe at first. There may be more modifications required to get this working. E.g., to NSEC. Perhaps something like this: alfa.example IN DNSKEY proto=3 ... alfa.example IN DNSKEY proto=4 ... alfa.example IN NSEC alfa.example A MX RRSIG NSEC alfa.example IN NSEC H(beta.example.org A MX RRSIG A DNSSECbis client would be happy (although negative data can be spoofed), and DNSSECter clients would be happy (and using the hashed NSEC approach, could detect negative spoof attempts -- _without_ permitting zone walking). 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 Tue Jun 15 17:23:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17486 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 17:23:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaLDy-000C5D-Jj for namedroppers-data@psg.com; Tue, 15 Jun 2004 21:12:06 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaLDv-000C4D-OJ for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 21:12:03 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 4A60219B3D7; Tue, 15 Jun 2004 17:10:40 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B959C19B3B0; Tue, 15 Jun 2004 17:10:39 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1777192; Tue, 15 Jun 2004 17:12:02 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602041bbcf5152fc42f@[192.168.1.100]> In-Reply-To: <a06020413bcf4e707f29f@[192.168.1.100]> References: <20040615161327.8982913951@sa.vix.com> <a06020413bcf4e707f29f@[192.168.1.100]> Date: Tue, 15 Jun 2004 17:11:59 -0400 To: Edward Lewis <edlewis@arin.net> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSKEY flags field Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:39 -0400 6/15/04, Edward Lewis wrote: >(Note that the key specified in the RRSIG need not be in the same *domain* as >the answer, I might "chase" it if my local policy so allows.) When I wrote that - in the back of my mind is this in the -records draft: # 3.1.7 The Signer's Name Field # # The Signer's Name field value identifies the owner name of the DNSKEY # RR which a validator should use to validate this signature. The # Signer's Name field MUST contain the name of the zone of the covered # RRset. ... Zeroth - there's a should there, in small letters. s/should/is supposed to/ First I can't believe that's in the records draft - it seems to be a restriction on validation, which would be protocol. (There are other things that fall into the "why would this be a records consideration" but aren't all that important.) Second, aren't validators allowed to be bound by local policy in this manner? Can't we have out of domain signers of data? (I know we've hashed this around before, but if there was a reason to leave this restriction in, where's the summary text of the previous rehashing? Besides the archives, I mean.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 17:40:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18260 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 17:40:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaLPZ-000DdO-Ph for namedroppers-data@psg.com; Tue, 15 Jun 2004 21:24:05 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaLPZ-000Dd8-0F for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 21:24:05 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 651CF19B82F; Tue, 15 Jun 2004 17:22:41 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 9ACE119B82F for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 17:22:39 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1777242; Tue, 15 Jun 2004 17:24:02 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602041cbcf518f6a6bc@[192.168.1.100]> Date: Tue, 15 Jun 2004 17:24:00 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: IANA registry issue Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Attemping protocol=4 is made hard by this in the IANA considerations of the -records document: KEY Protocol Values: [RFC2535] created an IANA Registry for KEY Protocol Values, but [RFC3445] re-assigned all values other than 3 to reserved and closed this IANA registry. The registry remains closed, and all KEY and DNSKEY records are required to have Protocol Octet value of 3. PS - namedroppers seems awfully quiet this afternoon... ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 18:31:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22881 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 18:31:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaMFq-000Jg5-2T for namedroppers-data@psg.com; Tue, 15 Jun 2004 22:18:06 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaMFo-000Jfg-NN for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 22:18:04 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 15 Jun 2004 18:18:03 -0400 id 00104EC1.40CF759B.00006065 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: IANA registry issue Date: Tue, 15 Jun 2004 18:18:03 -0400 User-Agent: KMail/1.6.2 References: <a0602041cbcf518f6a6bc@[192.168.1.100]> In-Reply-To: <a0602041cbcf518f6a6bc@[192.168.1.100]> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406151818.03460.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 15 June 2004 5:24 pm, Edward Lewis wrote: > Attemping protocol=4 is made hard by this in the IANA considerations > of the -records document: > > KEY Protocol Values: [RFC2535] created an IANA Registry for KEY > Protocol Values, but [RFC3445] re-assigned all values other than 3 > to reserved and closed this IANA registry. The registry remains > closed, and all KEY and DNSKEY records are required to have > Protocol Octet value of 3. I think before we attempt to jump this hurdle, we need to determine if 1) signaling DNSSEC-ter in DNSKEY is feasible (so far, looks like to me), and 2) desirable. That is, would using proto=4 or DNSKEY flag bits as a signaling mechanism be better than TCR? Then we can figure out whether or not we wish to revive that IANA registry or do something else. > PS - namedroppers seems awfully quiet this afternoon... ;) Sorry, man. -- 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 Tue Jun 15 18:54:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23365 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 18:54:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaMaC-000Lf3-QX for namedroppers-data@psg.com; Tue, 15 Jun 2004 22:39:08 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaMaB-000Lei-Oj for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 22:39:07 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 15 Jun 2004 18:39:06 -0400 id 0014A5CB.40CF7A8B.000063EE From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field Date: Tue, 15 Jun 2004 18:39:06 -0400 User-Agent: KMail/1.6.2 References: <ilufz9332at.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> <iluisds8r5x.fsf@latte.josefsson.org> In-Reply-To: <iluisds8r5x.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406151839.06858.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 15 June 2004 5:09 pm, Simon Josefsson wrote: > David Blacka <davidb@verisignlabs.com> writes: > > This specification only defines how security aware name servers can > > signal non-validating stub resolvers that data was found to be > > bogus (using RCODE=2, "Server Failure" -- see > > [I-D.ietf-dnsext-dnssec-protocol]). > > Thanks. This is CD=0, right? Stub resolvers do not want to validate > DNSKEY's, so if the DNSKEY is proto=3 or proto=4, they wouldn't care. > I'm more interested in how the name server for the stub resolver > behave. Right, CD=0. > Just make sure responses with partial bogus and partial good DNSKEYs > will not be regarded as bogus, but instead good. I do not believe so. As long as the validator can establish a chain of trust using the proto=3 keys, that fact that it throws out the proto=4 keys is not an issue (unless you have some RRsets only signed with the proto=4 keys, in which case "legacy" validators will consider them bogus). > > I do not see how the protocol field can be used for extensions. Maybe > > I just don't understand what you mean by "extensions"? > > Yes, I haven't been clear. Let me try one idea of what I'm > envisioning. > > I'm seeing proto=4 (or "critical bits") as a vehicle for a migration > mechanism to DNSSECter, at end nodes, which can work smoothly with > only DNSSECbis deployed in the infrastructure. > > If a DNSSECter use the same RRs, with the same owner names, and > DNSSECbis resolvers will happily ignore proto=4 DNSKEYs as long as > they see working proto=3 DNSKEYs, they will forward the proto=4 > DNSKEYs (together with the proto=3 which it itself understand) to any > clients (since it is needed by DNSSECbis client to verify the DNSKEY > RRset RRSIG). If, eventually, the client understand DNSSECter, it can > validate the response using DNSSECter instead of DNSSECbis, even > though all middle name servers didn't understand DNSSECter. Is this > any more clear? I understand I haven't made this point clear, but > this has only been one aspect of things, and not the most important > that I thought of to describe at first. > > There may be more modifications required to get this working. E.g., > to NSEC. Perhaps something like this: > > alfa.example IN DNSKEY proto=3 ... > alfa.example IN DNSKEY proto=4 ... > alfa.example IN NSEC alfa.example A MX RRSIG NSEC > alfa.example IN NSEC H(beta.example.org A MX RRSIG > > A DNSSECbis client would be happy (although negative data can be > spoofed), and DNSSECter clients would be happy (and using the hashed > NSEC approach, could detect negative spoof attempts -- _without_ > permitting zone walking). An interesting concept. Until this, I had not envisioned a form of DNSSEC-ter that would simultaneously be backwards compatible with DNSSEC-bis. Although, I am not convinced that we can get this to work. It would be interesting to try, however. What Ed and I have been discussing is, essentially, the possibility of using proto=4 to introduce a non-backwards compatible form of DNSSEC-ter, as an alternative to doing typecode rollover. This would require, IMHO, minor language changes to the -protocol document. -- 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 Tue Jun 15 18:55:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23395 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 18:55:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaMfv-000MF2-Mp for namedroppers-data@psg.com; Tue, 15 Jun 2004 22:45:03 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaMfv-000MEp-0N for namedroppers@ops.ietf.org; Tue, 15 Jun 2004 22:45:03 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A913113993 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 22:45:02 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: IANA registry issue In-Reply-To: Message from David Blacka <davidb@verisignlabs.com> of "Tue, 15 Jun 2004 18:18:03 -0400." <200406151818.03460.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 15 Jun 2004 22:45:02 +0000 Message-Id: <20040615224502.A913113993@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... we need to determine if 1) signaling DNSSEC-ter in DNSKEY is > feasible (so far, looks like to me), and 2) desirable. That is, would > using proto=4 or DNSKEY flag bits as a signaling mechanism be better > than TCR? > > Then we can figure out whether or not we wish to revive that IANA > registry or do something else. on the one hand, yes and no. it's borderline feasible, but not desireable. (and since this isn't dnssec@cafax.se, i don't have to explain my reasons.) on the other hand, the decision as to whether to revive the closed iana registry for dnssec protocol identifiers can come much later, after the decision of which transition mechanism is right for bis->ter. right now all we have to decide is whether there IS a way to go bis->ter; we don't have to actually select one, and we don't need to reopen an IANA registry for 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 Tue Jun 15 21:06:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29129 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 21:06:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaOl3-0009JQ-G5 for namedroppers-data@psg.com; Wed, 16 Jun 2004 00:58:29 +0000 Received: from [69.10.132.76] (helo=willow.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaOl2-0009Iz-4k for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 00:58:28 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by willow.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5G0wJDA011333 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 01:58:27 +0100 Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5G0wFso008214 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 01:58:16 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5G0wEZ7094141 for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 01:58:14 +0100 (BST) (envelope-from roy+dated+1089939494.06b5f3@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5G0wEAS094140 for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 01:58:14 +0100 (BST) (envelope-from roy+dated+1089939494.06b5f3@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 16 Jun 2004 01:58:13 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16591.39717.248000.236641@giles.gnomon.org.uk> Date: Wed, 16 Jun 2004 01:58:13 +0100 To: Roy Badami <roy@gnomon.org.uk> Cc: Simon Josefsson <jas@extundo.com>, namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: <16591.39278.643239.740099@giles.gnomon.org.uk> References: <ilufz9332at.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> <ilu7jua3sb0.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> <iluisds8r5x.fsf@latte.josefsson.org> <16591.39278.643239.740099@giles.gnomon.org.uk> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (willow.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Simon> NSEC alfa.example IN NSEC H(beta.example.org A MX RRSIG Roy> Is that meant to imply that you're hashing the target name Roy> but not the owner name? It's not immediately obvious to my Roy> how that would work either to achieve authenitcated denial or Roy> to prevent zone walking... Oops, sorry, forget I asked that (or at least don't reply on namedroppers) since that would be dragging this thread into radio silence territory (sorry, mea culpa) -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 21:26:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00335 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 21:26:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaP6L-000BlF-AH for namedroppers-data@psg.com; Wed, 16 Jun 2004 01:20:29 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaP6I-000Bky-3G for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 01:20:26 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5G0ovWa045474 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 00:50:59 GMT (envelope-from roy+dated+1089939055.0ce26c@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5G0ouso008203 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 01:50:57 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5G0otEq094099 for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 01:50:55 +0100 (BST) (envelope-from roy+dated+1089939055.0ce26c@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5G0otc0094098 for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 01:50:55 +0100 (BST) (envelope-from roy+dated+1089939055.0ce26c@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 16 Jun 2004 01:50:55 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16591.39278.643239.740099@giles.gnomon.org.uk> Date: Wed, 16 Jun 2004 01:50:54 +0100 To: Simon Josefsson <jas@extundo.com> Cc: namedroppers@ops.ietf.org Subject: Re: DNSKEY flags field In-Reply-To: <iluisds8r5x.fsf@latte.josefsson.org> References: <ilufz9332at.fsf@latte.josefsson.org> <200406141354.29107.davidb@verisignlabs.com> <ilu7jua3sb0.fsf@latte.josefsson.org> <200406141512.35693.davidb@verisignlabs.com> <iluisds8r5x.fsf@latte.josefsson.org> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes: Simon> NSEC alfa.example IN NSEC H(beta.example.org A MX RRSIG Is that meant to imply that you're hashing the target name but not the owner name? It's not immediately obvious to my how that would work either to achieve authenitcated denial or to prevent zone walking... -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 21:29:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00620 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 21:29:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaPBz-000CAe-F0 for namedroppers-data@psg.com; Wed, 16 Jun 2004 01:26:19 +0000 Received: from [69.10.132.76] (helo=willow.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaPBy-000CAO-4z for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 01:26:18 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by willow.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5G1QFDA011417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 02:26:17 +0100 Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5G1QDso008385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 02:26:14 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5G1QDpk094229 for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 02:26:13 +0100 (BST) (envelope-from roy+dated+1089941173.3ad040@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5G1QD2I094228 for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 02:26:13 +0100 (BST) (envelope-from roy+dated+1089941173.3ad040@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 16 Jun 2004 02:26:12 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16591.41396.6849.490196@giles.gnomon.org.uk> Date: Wed, 16 Jun 2004 02:26:12 +0100 To: David Blacka <davidb@verisignlabs.com> Cc: namedroppers@ops.ietf.org Subject: Editorial nit re last NSEC in zone (was: zone-covering NSEC ranges -- "which is it?") In-Reply-To: <200406151208.29850.davidb@verisignlabs.com> References: <20040614210836.CE67A13971@sa.vix.com> <200406150949.33378.davidb@verisignlabs.com> <20040615172947.6dd2bc04.olaf@ripe.net> <200406151208.29850.davidb@verisignlabs.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami <roy@gnomon.org.uk> X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (willow.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "David" == David Blacka <davidb@verisignlabs.com> writes: David> To be clear, though, I *do* believe that language needs to David> be added to section 5.4 to handle the X-NSEC-@ case. As someone coming to these documents (relatively) anew, I agree that from an editorial point of view -protocol should mention this too (perhaps in 5.4 or probably in 2.3) The instruction in -protocol 2.3 to refer to -records for a precise description is not entirely helpful given -records section 4 instucts the reader to refer to -protocol for a precise description. I realize that between the two documents they contain a complete description of what the NSEC records in a signed zone should contain, but it really shouldn't be this difficult for the reader... If it's going to be all done by cross-references it should at least reference a section rather than an entire RFC... If the WG concensus is that the DNSSEC design is based on the idea of a circular canonical ordering, then I think it would be helpful to state so in -records section 6, too. The end-of-zone behaviour is currently hidden away in a seemingly throwaway remark in -records 4.1.1. I think this would be confusing to anyone coming to DNSSECbis who hadn't read RFC2535... -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 22:13:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02443 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 22:13:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaPry-000H1u-Bd for namedroppers-data@psg.com; Wed, 16 Jun 2004 02:09:42 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaPrx-000H1a-H9 for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 02:09:41 +0000 Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5G29cWa036493 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 02:09:39 GMT (envelope-from roy+dated+1089943777.9783f2@gnomon.org.uk) Received: from giles.gnomon.org.uk (giles.gnomon.org.uk [192.168.1.6]) by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5G29cso008556 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 03:09:38 +0100 Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5G29bMV094707 for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 03:09:37 +0100 (BST) (envelope-from roy+dated+1089943777.9783f2@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5G29bWQ094706 for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 03:09:37 +0100 (BST) (envelope-from roy+dated+1089943777.9783f2@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 16 Jun 2004 03:09:37 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16591.44001.120320.135088@giles.gnomon.org.uk> Date: Wed, 16 Jun 2004 03:09:37 +0100 To: namedroppers@ops.ietf.org Subject: Editorial nit: location of canonical ordering definition X-Mailer: VM 7.18 under Emacs 21.3.1 From: Roy Badami <roy@gnomon.org.uk> X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My gut feeling is that -records sections 6 should be transplanted wholesale into -protocol instead. The canonical ordering isn't anything to do with the records per se, and to my mind in very much part of the protocol.... I realize this is a subjective issue, and others may disagree. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Jun 15 22:38:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03356 for <dnsext-archive@lists.ietf.org>; Tue, 15 Jun 2004 22:38:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaQGa-000J3H-4I for namedroppers-data@psg.com; Wed, 16 Jun 2004 02:35:08 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaQGZ-000J2y-8B for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 02:35:07 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4B36342B2 for <namedroppers@ops.ietf.org>; Tue, 15 Jun 2004 22:35:06 -0400 (EDT) Date: Tue, 15 Jun 2004 22:35:06 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: Editorial nit: location of canonical ordering definition In-Reply-To: <16591.44001.120320.135088@giles.gnomon.org.uk> References: <16591.44001.120320.135088@giles.gnomon.org.uk> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040616023506.4B36342B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 16 Jun 2004 03:09:37 +0100, Roy Badami wrote: > > My gut feeling is that -records sections 6 should be transplanted > wholesale into -protocol instead. The canonical ordering isn't > anything to do with the records per se, and to my mind in very much > part of the protocol.... > > I realize this is a subjective issue, and others may disagree. <hat editor=off just-another-bozo=on> I disagree. The cannoical ordering definitions are required to understand what goes in the RDATA fields of the RRSIG and NSEC RR types defined in -records. In particular: section 6.1 is required to understand section 4.1.1, and sections 6.2 and 6.3 are required to understand section 3.1.8.1. </hat> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 16 02:15:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16906 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 02:15:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaTeG-000CzL-Um for namedroppers-data@psg.com; Wed, 16 Jun 2004 06:11:48 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaTeG-000Cz5-1g for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 06:11:48 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7E35613993 for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 06:11:47 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: back to: zone-covering NSEC ranges -- "which is it?" In-Reply-To: Message from Roy Badami <roy@gnomon.org.uk> of "Wed, 16 Jun 2004 02:26:12 +0100." <16591.41396.6849.490196@giles.gnomon.org.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 16 Jun 2004 06:11:47 +0000 Message-Id: <20040616061147.7E35613993@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > If the WG concensus is that the DNSSEC design is based on the idea of > a circular canonical ordering, ... i don't think there's consensus on this yet. not "informed" consensus at any rate. circularity is mentioned, and a target name of @ is given as an example. however, there's nothing in this thread, or the documents that i can find, that describes $ORIGIN example.com. @ IN SOA ... NSEC Q Q NSEC P as denying the existence of names from Q to S wrapping through @. in other words if it really is a circular namespace then "Q NSEC P" denies O, R, and so on. and it's not clear that "Q NSEC Q" doesn't deny P, R, and etc, since ownername==targetname. and it's not clear whether "Q NSEC P" denies @ or not. targetname of @ seems very much special cased in the current docs. lastly, the target name should have to be in-balliwick. right now it would be legal to say "Q NSEC Z.NET." but it's completely unclear what it would mean. these are probably editorial issues; consensus -- informed consensus, that is -- will likely not be long in coming, once the right questions are asked. note that i do not consider them to have been asked correctly yet, by me or by anybody else in the thread that erupted from my weekend inquiry about this. (if we really mean circularity, then we need "Q NSEC P" as one of our examples and we need to explain what it means. and the other stuff i mention above.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 16 02:32:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02274 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 02:32:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaTug-000EFK-9U for namedroppers-data@psg.com; Wed, 16 Jun 2004 06:28:46 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaTuf-000EF7-HC for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 06:28:45 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5EEFF13993 for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 06:28:45 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: back to: zone-covering NSEC ranges -- "which is it?" In-Reply-To: Message from Paul Vixie <paul@vix.com> of "Wed, 16 Jun 2004 06:11:47 GMT." <20040616061147.7E35613993@sa.vix.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 16 Jun 2004 06:28:45 +0000 Message-Id: <20040616062845.5EEFF13993@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > $ORIGIN example.com. > @ IN SOA ... > NSEC Q > Q NSEC P > > as denying the existence of names from Q to S wrapping through @. "from Q to P wrapping through @", i meant. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 16 10:59:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03316 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 10:59:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaV5Y-000KO2-07 for namedroppers-data@psg.com; Wed, 16 Jun 2004 07:44:04 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaV5W-000KNn-JC for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 07:44:02 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 0927B4E19B; Wed, 16 Jun 2004 09:44:02 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id B0F594E08F; Wed, 16 Jun 2004 09:44:01 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5G7i18r023659; Wed, 16 Jun 2004 09:44:01 +0200 Date: Wed, 16 Jun 2004 09:44:01 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: back to: zone-covering NSEC ranges -- "which is it?" Message-Id: <20040616094401.72b097f0.olaf@ripe.net> In-Reply-To: <20040616062845.5EEFF13993@sa.vix.com> References: <20040616061147.7E35613993@sa.vix.com> <20040616062845.5EEFF13993@sa.vix.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 4ee69ca410d5c06fb24c9379d50a10c9 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 16 Jun 2004 06:28:45 +0000 Paul Vixie <paul@vix.com> wrote: > > $ORIGIN example.com. > > @ IN SOA ... > > NSEC Q > > Q NSEC P > > > > as denying the existence of names from Q to S wrapping through @. > > "from Q to P wrapping through @", i meant. Paul, I think circular canonical ordering has never been a point of discussion. It was described more explicit in 2535 and we have never ever challenged canonical ordering. As far as I am concerned circular canonical ordering is an editorial matter; it needs to be made more explicit. (I appreciate that Roy, as a new reader, saw an ambiguity). From the cirular canonical ordering and the fact a zone always has an apex you can deduce that Q NSEC P is simply invalid unless P equals the apex, just as X NSEC X is invalid unless X equals the apex and the zone is empty. I think that DNSSEC-bis leaves behaviour for Q NSEC P where P is not the apex unspecified. It may even be useful for a zone owner to generate such records and a validator may do useful thinks with these records, on the other hand you have to consider that synthesized NSEC RRs can be used in replay attacks as I argued for the X NSEC X case. If you do not want replay attacks to be harmfull (because you want white lies) than go and change the 'security state machine' by changing the specs and experience the pain. -- Olaf No Hats (but tempted to put one on 'during' the first paragraph.) ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 16 11:42:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11826 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 11:42:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BacQY-000G6M-Cu for namedroppers-data@psg.com; Wed, 16 Jun 2004 15:34:14 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BacQX-000G63-0W for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 15:34:13 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i5GFYCeP020945; Wed, 16 Jun 2004 11:34:12 -0400 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: back to: zone-covering NSEC ranges -- "which is it?" References: <20040616061147.7E35613993@sa.vix.com> <20040616062845.5EEFF13993@sa.vix.com> <20040616094401.72b097f0.olaf@ripe.net> From: Derek Atkins <derek@ihtfp.com> Date: Wed, 16 Jun 2004 11:34:12 -0400 In-Reply-To: <20040616094401.72b097f0.olaf@ripe.net> (Olaf M. Kolkman's message of "Wed, 16 Jun 2004 09:44:01 +0200") Message-ID: <sjmr7sfv7nv.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> writes: > It may even be useful for a zone owner to > generate such records and a validator may do useful thinks with these > records, on the other hand you have to consider that synthesized NSEC > RRs can be used in replay attacks as I argued for the X NSEC X case. > > If you do not want replay attacks to be harmfull (because you want > white lies) than go and change the 'security state machine' by > changing the specs and experience the pain. This seems to argue that X NSEC X should be specified to cover exactly one name (X), except for the special case of X = @. I don't believe that X NSEC X is a white lie -- indeed, if you are trying to implement on-the-fly NXDOMAIN signing, what _ARE_ you supposed to use for the 'next domain' entry in an on-the-fly NSEC? -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 Wed Jun 16 12:01:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14144 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 12:01:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bacly-000IZg-5R for namedroppers-data@psg.com; Wed, 16 Jun 2004 15:56:22 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Baclw-000IZH-K6 for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 15:56:21 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id 96F17E7E94; Wed, 16 Jun 2004 16:56:19 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: back to: zone-covering NSEC ranges -- "which is it?" In-Reply-To: <sjmr7sfv7nv.fsf@dogbert.ihtfp.org> Message-Id: <20040616155619.96F17E7E94@mx1.nominet.org.uk> Date: Wed, 16 Jun 2004 16:56:19 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Derek Atkins <derek@ihtfp.com> writes: > This seems to argue that X NSEC X should be specified to cover exactly > one name (X), except for the special case of X = @. I don't believe > that X NSEC X is a white lie -- indeed, if you are trying to implement > on-the-fly NXDOMAIN signing, what _ARE_ you supposed to use for the > 'next domain' entry in an on-the-fly NSEC? You could have "X NSEC X+1" where X+1 is the next possible owner name in cannonical sort order, e.g. a.example. NSEC a-.example. or even a.example. NSEC a\000.example. In this case, if the owner name were the last possible owner name in sort order, it would point back to the apex. 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 Wed Jun 16 12:23:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16873 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 12:23:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bad8i-000LBz-Ga for namedroppers-data@psg.com; Wed, 16 Jun 2004 16:19:52 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bad8f-000LBU-DQ for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 16:19:49 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id EF62719B521; Wed, 16 Jun 2004 12:18:11 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 7FD9D19B4F1; Wed, 16 Jun 2004 12:18:11 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1780406; Wed, 16 Jun 2004 12:19:48 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602040ebcf622dc1712@[192.136.136.83]> In-Reply-To: <sjmr7sfv7nv.fsf@dogbert.ihtfp.org> References: <20040616061147.7E35613993@sa.vix.com> <20040616062845.5EEFF13993@sa.vix.com> <20040616094401.72b097f0.olaf@ripe.net> <sjmr7sfv7nv.fsf@dogbert.ihtfp.org> Date: Wed, 16 Jun 2004 12:19:45 -0400 To: Derek Atkins <derek@ihtfp.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: back to: zone-covering NSEC ranges -- "which is it?" Cc: "Olaf M. Kolkman" <olaf@ripe.net>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:34 -0400 6/16/04, Derek Atkins wrote: >This seems to argue that X NSEC X should be specified to cover exactly >one name (X), except for the special case of X = @. I don't believe >that X NSEC X is a white lie -- indeed, if you are trying to implement >on-the-fly NXDOMAIN signing, what _ARE_ you supposed to use for the >'next domain' entry in an on-the-fly NSEC? If the next name field in the NSEC is defined to be the next name in the zone, then generating on-the-fly "X NSEC X" (where there is another name in the zone) *is* a "white" lie. More accurately, an abuse of the protocol. If you are to implement on-the-fly RCODE='name error' signing, then you don't need the NSEC approach of showing a next name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Jun 16 12:49:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19396 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 12:49:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BadXW-000OJ8-FP for namedroppers-data@psg.com; Wed, 16 Jun 2004 16:45:30 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BadXV-000OIk-HH for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 16:45:29 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EE9D442B2 for <namedroppers@ops.ietf.org>; Wed, 16 Jun 2004 12:45:28 -0400 (EDT) Date: Wed, 16 Jun 2004 12:45:28 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: back to: zone-covering NSEC ranges -- "which is it?" In-Reply-To: <20040616061147.7E35613993@sa.vix.com> References: <roy@gnomon.org.uk> <16591.41396.6849.490196@giles.gnomon.org.uk> <20040616061147.7E35613993@sa.vix.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040616164528.EE9D442B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm not comfortable with this X NSEC X thing, for two reasons: a) As far as I can tell, the answer to the question "is it circular or is X NSEC @ a special case?" is "mu". The only case where the circularity mattered in RFC 2535 for X NXT Y was Y = @, because in all other cases, Y > X, by definition. b) Defining X NSEC X to be a statement just about X would require treating @ NSEC @ as a special 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 Wed Jun 16 13:07:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21685 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 13:07:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Badoe-0004mv-8w for namedroppers-data@psg.com; Wed, 16 Jun 2004 17:03:12 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Badod-0004mW-3o for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 17:03:11 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 16 Jun 2004 13:03:09 -0400 id 00149E86.40D07D4D.00006680 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: issue with draft-ietf-dnsext-dnssec-trans-00.txt section 2.2.3 Date: Wed, 16 Jun 2004 13:03:10 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200406161303.10074.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I apologize for not bringing this up earlier. Or, perhaps, for bringing it up at all ;-) I do not think the language in section 2.2.3.2 is entirely correct: Validating resolvers agnostic of new interpretation will treat the NSEC RRset as "not signed". This affects wildcard and non-existence proof, as well as proof for (un)secured delegations. Also, all positive signatures (RRSIGs on RRSets other than DS, NSEC) appear insecure/bogus to an old validator. Specifically, the second sentence. If the validator is considering the zone unsigned (i.e., Insecure), how will anything in the zone appear to be "bogus"? This language appears to contradict the language in the intro to this section (2.2.3). I will also note that I think I've tested this behavior with the only implementation I had at the time: a bind 9.3 snapshot, and, as far as I could tell, it worked as expected. That is, everything resolved and appeared to be insecure. The algorithm version space is split for each future version of DNSSEC. Violation of the 'modular components' concept. We use the 'validator' to protect the 'resolver' from unknown interpretations. The first sentence of this paragraph appears to be true, but the second sentence doesn't make much sense to me. a) I don't know what the 'modular components' concept is, exactly, and b) if I were to guess what it meant, I would still think that this was wrong: the whole exercise here is confined to the 'validator' function, AFAICT. -- 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 Wed Jun 16 14:15:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25955 for <dnsext-archive@lists.ietf.org>; Wed, 16 Jun 2004 14:15:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Baeqd-000CLV-Q8 for namedroppers-data@psg.com; Wed, 16 Jun 2004 18:09:19 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Baeqc-000CKy-2X for namedroppers@ops.ietf.org; Wed, 16 Jun 2004 18:09:18 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id F1B92AC8B; Wed, 16 Jun 2004 20:09:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id EE148AC8A; Wed, 16 Jun 2004 20:09:16 +0200 (CEST) Date: Wed, 16 Jun 2004 20:09:16 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: David Blacka <davidb@verisignlabs.com> Cc: namedroppers@ops.ietf.org Subject: Re: issue with draft-ietf-dnsext-dnssec-trans-00.txt section 2.2.3 In-Reply-To: <200406161303.10074.davidb@verisignlabs.com> Message-ID: <Pine.BSO.4.56.0406161951180.14287@trinitario.schlyter.se> References: <200406161303.10074.davidb@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 16 Jun 2004, David Blacka wrote: > I apologize for not bringing this up earlier. Or, perhaps, for bringing it up > at all ;-) > > I do not think the language in section 2.2.3.2 is entirely correct: > > Validating resolvers agnostic of new interpretation will treat the > NSEC RRset as "not signed". This affects wildcard and non-existence > proof, as well as proof for (un)secured delegations. Also, all > positive signatures (RRSIGs on RRSets other than DS, NSEC) appear > insecure/bogus to an old validator. > > Specifically, the second sentence. If the validator is considering the zone > unsigned (i.e., Insecure), how will anything in the zone appear to be > "bogus"? This language appears to contradict the language in the intro to > this section (2.2.3). Yep, we'll delete bogus. > I will also note that I think I've tested this behavior with the only > implementation I had at the time: a bind 9.3 snapshot, and, as far as I could > tell, it worked as expected. That is, everything resolved and appeared to be > insecure. > > The algorithm version space is split for each future version of > DNSSEC. Violation of the 'modular components' concept. We use the > 'validator' to protect the 'resolver' from unknown interpretations. > > The first sentence of this paragraph appears to be true, but the second > sentence doesn't make much sense to me. a) I don't know what the 'modular > components' concept is, exactly, and b) if I were to guess what it meant, I > would still think that this was wrong: the whole exercise here is confined to > the 'validator' function, AFAICT. Modular concept as in validator/resolver/server/cache. What I ment to say here is that the unknown algorithm is used as signal to a validator that now the resolver should not use interpretation class 'NSEC' but interpretation class 'NSEC-Alt'. But, I guess the discussion of where that functionality belongs is academic. Remember from the -intro doc that a validator and a resolver might not be single component, hence modular. It is still a hack though, it uses a field which purpose is to indicate a specific signature algorithm as a signal for NSEC interpretation. Bogus is gone in -01 and I'll try to ameliorate language on 'modular concept'. Thanks, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 03:33:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07052 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 03:33:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BarK7-000Dcr-Mo for namedroppers-data@psg.com; Thu, 17 Jun 2004 07:28:35 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BarK6-000Dcb-7a for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 07:28:34 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 264E5AC8B; Thu, 17 Jun 2004 09:28:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id ECDEAAC8A for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 09:28:32 +0200 (CEST) Date: Thu, 17 Jun 2004 09:28:32 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: rrsig(qtype) Message-ID: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an alternative online signing proposal: Deny existence for QTYPE,QNAME,QCLASS by responding with empty answer section and RRSIG in authority section, which is dynamically generated and has signature field value: sign(RRSIG_RDATA). example: Dynamic No Data Error A "NODATA" response. The RRSIG proves that the requested RR type does not exist. ;; Header: QR AA DO RCODE=0 ;; ;; Question mail.example. IN MX ;; Answer ;; (empty) ;; Authority mail.example. 600 IN RRSIG MX 5 1 600 20040609183619 ( 20040609183019 37223 example. ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h .. jV7j86HyQgM5e7+miRAz8V01b0I= ) ;; Additional ;; (empty) 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 Thu Jun 17 04:17:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08714 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 04:17:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bas0j-000IIK-Hm for namedroppers-data@psg.com; Thu, 17 Jun 2004 08:12:37 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bas0i-000II3-Ex for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 08:12:36 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D98B64E615; Thu, 17 Jun 2004 10:12:35 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7EEA34E5E3 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 10:12:35 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5H8CM8r010397 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 10:12:22 +0200 Date: Thu, 17 Jun 2004 10:12:22 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Message-Id: <20040617101222.36d52f24.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-RIPE-Spam-Status: N 0.006834 / 0.0 / 0.0 / disabled X-RIPE-Signature: e923bc805613ae3a6bbaee27996cbf5a X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable In http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01033.html =D3lafur Gudmundsson wrote: >After reading Paul's Vixie -ter proposal >http://psg.com/lists/namedroppers/namedroppers.2004/msg00967.html >and Jakob, Peter and Roy's -trans list of approaches >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt > >Please speak up on this question to help chairs gauge consensus. The question being: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? There has not been enough clear statements, we are looking for support, please help us out. We need to be able document that there is consensus that forwarding DNSSEC-bis does not close the door on NSEC2, NSEC-alt or other methods denial of existence that prevent zone enumeration. Please respond either on the mailing list or in a e-mail to both chairs. Following are the changes the chairs are aware off and will be done before documents are forward to IESG: 1. Caching issue brought up by David Blacka. 2. Make it clearer that name space in NSEC records is circular. 3. Minor text clarifications brought up. Issues that are not resolved yet: 1. Division of flag bits, as proposed by Simon Josefsson 2. Need for special cases in NSEC records processing for white lies/on-line signing. Speak out if you think these items need or need not be resolved. If you think these items need to be resolved than contribute with text that can go into the document. If there is no obvious consensus on support for these proposals, they will not be taken into account. We need to move forward. If not, we will not make the cut-off date, run into the holiday season and it will be mid September before we have had any progress. =D3lafur and Olaf=20 DNSEXT Co-Chairs -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 04:40:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10354 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 04:40:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BasNN-000Kg1-7g for namedroppers-data@psg.com; Thu, 17 Jun 2004 08:36:01 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BasNL-000Kfk-Ns for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 08:36:00 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id D8DF2AC8A; Thu, 17 Jun 2004 10:35:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id D7B64AC88; Thu, 17 Jun 2004 10:35:58 +0200 (CEST) Date: Thu, 17 Jun 2004 10:35:58 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> Message-ID: <Pine.BSO.4.56.0406171031340.18684@trinitario.schlyter.se> References: <20040617101222.36d52f24.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Olaf M. Kolkman wrote: > Issues that are not resolved yet: > 2. Need for special cases in NSEC records processing for > white lies/on-line signing. I've just send an alternative for on-line signing that obsoletes the need for NSEC or similar records. (see mail with rrsig(qname)). I'd like to keep current NSEC 'clean' of hacks. 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 Thu Jun 17 05:03:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11535 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 05:03:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Baske-000NB7-Sv for namedroppers-data@psg.com; Thu, 17 Jun 2004 09:00:04 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Baskd-000NAW-Ph for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 09:00:03 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id B702FAC8B; Thu, 17 Jun 2004 10:37:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id B183EAC8A; Thu, 17 Jun 2004 10:37:13 +0200 (CEST) Date: Thu, 17 Jun 2004 10:37:13 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> Message-ID: <Pine.BSO.4.56.0406171036300.18684@trinitario.schlyter.se> References: <20040617101222.36d52f24.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Olaf M. Kolkman wrote: > The question being: > Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? No. It does not preven NSEC-alt in the 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 Thu Jun 17 07:19:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19609 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 07:19:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bauqd-000B7N-BO for namedroppers-data@psg.com; Thu, 17 Jun 2004 11:14:23 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bauqb-000B76-UI for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 11:14:22 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 5AD554E51F; Thu, 17 Jun 2004 13:14:21 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 16EFA4E476; Thu, 17 Jun 2004 13:14:21 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i5HBED8r026330; Thu, 17 Jun 2004 13:14:16 +0200 Message-Id: <200406171114.i5HBED8r026330@birch.ripe.net> To: Simon Josefsson <jas@extundo.com> Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1 In-reply-to: Your message of Thu, 17 Jun 2004 13:05:29 +0200. <ilud63yfnra.fsf@latte.josefsson.org> References: <ilud63yfnra.fsf@latte.josefsson.org> From: Olaf Kolkman <OKolkman@ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Thu, 17 Jun 2004 13:14:13 +0200 X-RIPE-Spam-Status: N 0.006994 / 0.0 / 0.0 / disabled X-RIPE-Signature: 71955f2a147698a246062516dbc29f13 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Simon, * Right now, yes. But why prevent a possible future use of it? Unless * there is a good reason, that is. And if there is a good reason, I * believe the reason should be stated, to explain the protocol * requirement. To prevent long academic discussion it would be nice if you would propose text that can be cut-n-paste into the documents. People can than state if they consent or not consent with the proposed text. --Olaf (trying to speed things up) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 07:56:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21383 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 07:56:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BavRu-000Egs-TU for namedroppers-data@psg.com; Thu, 17 Jun 2004 11:52:54 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BavRt-000EgN-0w for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 11:52:53 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.11/8.12.11/Debian-5) with ESMTP id i5HBqjVx018950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 17 Jun 2004 13:52:46 +0200 To: Olaf Kolkman <OKolkman@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1 References: <ilud63yfnra.fsf@latte.josefsson.org> <200406171114.i5HBED8r026330@birch.ripe.net> From: Simon Josefsson <jas@extundo.com> X-Hashcash: 0:040617:OKolkman@ripe.net:73289b73bb1060fe X-Hashcash: 0:040617:namedroppers@ops.ietf.org:53a44330474e316b Date: Thu, 17 Jun 2004 13:52:44 +0200 In-Reply-To: <200406171114.i5HBED8r026330@birch.ripe.net> (Olaf Kolkman's message of "Thu, 17 Jun 2004 13:14:13 +0200") Message-ID: <ilu1xkeflkj.fsf@latte.josefsson.org> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf Kolkman <OKolkman@ripe.net> writes: > Hi Simon, > > * Right now, yes. But why prevent a possible future use of it? Unless > * there is a good reason, that is. And if there is a good reason, I > * believe the reason should be stated, to explain the protocol > * requirement. > > To prevent long academic discussion it would be nice if you would propose > text that can be cut-n-paste into the documents. > > People can than state if they consent or not consent with the proposed text. Hello. I suggest to remove this sentence: DNSKEY RRs MUST NOT appear at delegation points. In section 2.1. Doing so would imply that any DNSKEY RRs at delegation points are treated the same as any other DNSKEY at unexpected locations: they are ignored. If people believe the requirement serve a useful purpose, I think the reason should be stated. In general, a DNSKEY placed at a location not expected by resolvers is ignored. The resolver will never try to get such DNSKEYs, and if it somehow receive them, it will not use it for validation, because using them isn't part of the validation algorithm in DNSSECbis. Why is it important to treat DNSKEYs at delegation points differently? With the current text, it appears as if resolvers faced with a DNSKEY at the delegation point can regard the entire parent zone as bogus, since it contain RRs which violate protocol requirements. Resolvers could also ignore the DNSKEY RR. But the latter is what I propose the specification should do, as well. 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 Thu Jun 17 07:57:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21537 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 07:57:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BavTO-000ErU-5Z for namedroppers-data@psg.com; Thu, 17 Jun 2004 11:54:26 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BavTM-000Er5-L4 for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 11:54:25 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 917F91FF845; Thu, 17 Jun 2004 11:54:23 +0000 (GMT) Message-ID: <40D1866F.2040308@algroup.co.uk> Date: Thu, 17 Jun 2004 12:54:23 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? References: <20040617101222.36d52f24.olaf@ripe.net> In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Olaf M. Kolkman wrote: > In http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01033.html > Ólafur Gudmundsson wrote: > > >After reading Paul's Vixie -ter proposal > >http://psg.com/lists/namedroppers/namedroppers.2004/msg00967.html > >and Jakob, Peter and Roy's -trans list of approaches > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt > > > >Please speak up on this question to help chairs gauge consensus. > > The question being: > Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? > > There has not been enough clear statements, we are looking for > support, please help us out. > > We need to be able document that there is consensus that forwarding > DNSSEC-bis does not close the door on NSEC2, NSEC-alt or other methods > denial of existence that prevent zone enumeration. > > Please respond either on the mailing list or in a e-mail to both > chairs. > > Following are the changes the chairs are aware off and will > be done before documents are forward to IESG: > > 1. Caching issue brought up by David Blacka. > 2. Make it clearer that name space in NSEC records is circular. > 3. Minor text clarifications brought up. > > Issues that are not resolved yet: > 1. Division of flag bits, as proposed by Simon Josefsson > 2. Need for special cases in NSEC records processing for > white lies/on-line signing. It may be worth clarifying in the text, but it isn't clear to me that anything special is needed for the @ NSEC @ white lie. My reasoning is this: a) 4.1.1 states: "The Next Domain Name field contains the owner name of the next authoritative owner name in the canonical ordering of the zone" b) 4.1.1 also states: "The value of the Next Domain Name field in the last NSEC record in the zone is the name of the zone apex" Therefore @ NSEC @ quite clearly means that there are no authoritative owner names other than @ in the zone. X NSEC X where X is not @ is also clearly illegal: X cannot be the next authoritative owner name - either there is another name, Y, which comes after X, in which case X NSEC Y would be correct, or X is the last name in the zone, in which case the record should be X NSEC @. It also seems to me, unless I'm missing something, that @ NSEC @ will come up in circumstances where it is not a lie, for example in zones where there is nothing but glue, and all subdomains are not secure. So, resolvers had better handle this case without exploding, or there's a problem. Again, this might be worth clarifying in the text. We could add to 4.1.1: "Note that a consequence of these rules is that an NSEC record owned by the apex of the zone and containing the apex as the Next Domain Name indicates that the zone contains no authoritative names other than the apex." 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 Thu Jun 17 08:00:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22139 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 08:00:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BavWy-000FLZ-2t for namedroppers-data@psg.com; Thu, 17 Jun 2004 11:58:08 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BavWx-000FLG-3C for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 11:58:07 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5HBvxC0002910 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 07:57:59 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i5HBvS4A005556 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 07:57:29 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1 Date: Thu, 17 Jun 2004 07:57:29 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGCEGBCLAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <200406171114.i5HBED8r026330@birch.ripe.net> Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For reference, KEY RRs (back before TCR) was discussed as a formal DNSSECbis question (Q11): http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01143.html Something might be able to be pulled out of the thread. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf Kolkman > Sent: Thursday, June 17, 2004 7:14 AM > To: Simon Josefsson > Cc: namedroppers@ops.ietf.org > Subject: Re: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1 > > > > Hi Simon, > > * Right now, yes. But why prevent a possible future use of it? Unless > * there is a good reason, that is. And if there is a good reason, I > * believe the reason should be stated, to explain the protocol > * requirement. > > To prevent long academic discussion it would be nice if you would propose > text that can be cut-n-paste into the documents. > > People can than state if they consent or not consent with the > proposed text. > > > --Olaf > (trying to speed things up) > > > -- > to unsubscribe send a message to namedroppers-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 Thu Jun 17 08:08:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22760 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 08:08:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaveO-000GMC-FG for namedroppers-data@psg.com; Thu, 17 Jun 2004 12:05:48 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaveN-000GLo-2T for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 12:05:47 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 132B0AC8D; Thu, 17 Jun 2004 14:05:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id DB920AC8B; Thu, 17 Jun 2004 14:05:45 +0200 (CEST) Date: Thu, 17 Jun 2004 14:05:45 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Simon Josefsson <jas@extundo.com> Cc: Olaf Kolkman <OKolkman@ripe.net>, namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1 In-Reply-To: <ilu1xkeflkj.fsf@latte.josefsson.org> Message-ID: <Pine.BSO.4.56.0406171401320.18684@trinitario.schlyter.se> References: <ilud63yfnra.fsf@latte.josefsson.org> <200406171114.i5HBED8r026330@birch.ripe.net> <ilu1xkeflkj.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Simon Josefsson wrote: > Olaf Kolkman <OKolkman@ripe.net> writes: > > > Hi Simon, > > > > * Right now, yes. But why prevent a possible future use of it? Unless > > * there is a good reason, that is. And if there is a good reason, I > > * believe the reason should be stated, to explain the protocol > > * requirement. > > > > To prevent long academic discussion it would be nice if you would propose > > text that can be cut-n-paste into the documents. > > > > People can than state if they consent or not consent with the proposed text. > > Hello. I suggest to remove this sentence: > > DNSKEY RRs MUST NOT appear at delegation points. > > In section 2.1. Doing so would imply that any DNSKEY RRs at > delegation points are treated the same as any other DNSKEY at > unexpected locations: they are ignored. > > If people believe the requirement serve a useful purpose, I think the > reason should be stated. > > In general, a DNSKEY placed at a location not expected by resolvers is > ignored. The resolver will never try to get such DNSKEYs, and if it > somehow receive them, it will not use it for validation, because using > them isn't part of the validation algorithm in DNSSECbis. Why is it > important to treat DNSKEYs at delegation points differently? > > With the current text, it appears as if resolvers faced with a DNSKEY > at the delegation point can regard the entire parent zone as bogus, > since it contain RRs which violate protocol requirements. Resolvers > could also ignore the DNSKEY RR. But the latter is what I propose the > specification should do, as well. I totally agree with Simon, There is nothing special in DNSKEY, nor is there in TXT or INFO records. All are prohibited at delegation points, and ignored by resolvers. 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 Thu Jun 17 09:22:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28102 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 09:22:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bawlk-000Oed-Mb for namedroppers-data@psg.com; Thu, 17 Jun 2004 13:17:28 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bawlj-000OeO-L1 for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 13:17:27 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E27DD19B599; Thu, 17 Jun 2004 09:15:34 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 6A2F019B3F8; Thu, 17 Jun 2004 09:15:34 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1783557; Thu, 17 Jun 2004 09:17:26 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020401bcf747c9f989@[192.168.1.100]> In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> References: <20040617101222.36d52f24.olaf@ripe.net> Date: Thu, 17 Jun 2004 09:11:43 -0400 To: "Olaf M. Kolkman" <olaf@ripe.net> From: Edward Lewis <edlewis@arin.net> Subject: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I need to re-read -protocol before saying what I was going to say. At 10:12 +0200 6/17/04, Olaf M. Kolkman wrote: >Following are the changes the chairs are aware off and will >be done before documents are forward to IESG: > > 1. Caching issue brought up by David Blacka. > 2. Make it clearer that name space in NSEC records is circular. Is the space circular? I used to think so, but am less convinced now than a week ago. > 3. Minor text clarifications brought up. > >Issues that are not resolved yet: > 1. Division of flag bits, as proposed by Simon Josefsson Or the role of the protocol field. I think Simon's onto something, but I think that using the flag bits is too complicated and there's that lovely protocol field begging to be used. > 2. Need for special cases in NSEC records processing for > white lies/on-line signing. I think the "white lies" thing is an aberration of the protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 09:43:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29102 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 09:43:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bax8g-000106-LX for namedroppers-data@psg.com; Thu, 17 Jun 2004 13:41:10 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bax8f-0000zk-3J for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 13:41:09 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5HDf2C0024265 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 09:41:02 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i5HDes4A013502 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 09:40:55 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Date: Thu, 17 Jun 2004 09:40:55 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGMEGECLAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <a06020401bcf747c9f989@[192.168.1.100]> Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Edward Lewis > > I need to re-read -protocol before saying what I was going to say. > > At 10:12 +0200 6/17/04, Olaf M. Kolkman wrote: > >Following are the changes the chairs are aware off and will > >be done before documents are forward to IESG: > > > > 1. Caching issue brought up by David Blacka. > > 2. Make it clearer that name space in NSEC records is circular. > > Is the space circular? I used to think so, but am less convinced now > than a week ago. > So am I. I don't believe it was intended to be circular as it is written. The @ was put simply to mark the end of the namespace covered by the NSEC chain. If the WG desires it to be circular to accomdate something, that is a spec change. > > 3. Minor text clarifications brought up. > > > >Issues that are not resolved yet: > > 1. Division of flag bits, as proposed by Simon Josefsson > > Or the role of the protocol field. I think Simon's onto something, > but I think that using the flag bits is too complicated and there's > that lovely protocol field begging to be used. > > > 2. Need for special cases in NSEC records processing for > > white lies/on-line signing. > > I think the "white lies" thing is an aberration of the protocol. I think so too, but having X nsec @ would be perferable, especially since the spec also forbids cachings from using NSECs to formulate new non-existence response. Scott > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > "I can't go to Miami. I'm expecting calls from telemarketers." - > Grandpa Simpson. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 09:52:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29545 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 09:52:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaxHq-000223-U1 for namedroppers-data@psg.com; Thu, 17 Jun 2004 13:50:38 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaxHp-00021f-VK for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 13:50:38 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 3E473AC8B; Thu, 17 Jun 2004 15:50:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 20EA2AC8A; Thu, 17 Jun 2004 15:50:37 +0200 (CEST) Date: Thu, 17 Jun 2004 15:50:36 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Scott Rose <scottr@nist.gov> Cc: namedroppers@ops.ietf.org Subject: RE: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? In-Reply-To: <ANECIHCPCBDLLEJLCOPGMEGECLAA.scottr@nist.gov> Message-ID: <Pine.BSO.4.56.0406171546420.18684@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGMEGECLAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Scott Rose wrote: > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org > > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Edward Lewis > > > > I need to re-read -protocol before saying what I was going to say. > > > > At 10:12 +0200 6/17/04, Olaf M. Kolkman wrote: > > >Following are the changes the chairs are aware off and will > > >be done before documents are forward to IESG: > > > > > > 1. Caching issue brought up by David Blacka. > > > 2. Make it clearer that name space in NSEC records is circular. > > > > Is the space circular? I used to think so, but am less convinced now > > than a week ago. > > > > So am I. I don't believe it was intended to be circular as it is written. > The @ was put simply to mark the end of the namespace covered by the NSEC > chain. If the WG desires it to be circular to accomdate something, that is > a spec change. It was never ment to make namespace circular, it was ment to deny data after the last owner-name. This was the only way to signal 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 Thu Jun 17 10:38:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05460 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 10:38:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaxxH-0006tj-Jh for namedroppers-data@psg.com; Thu, 17 Jun 2004 14:33:27 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaxxG-0006tK-FZ for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 14:33:26 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i5HEXHMi013235; Thu, 17 Jun 2004 10:33:17 -0400 To: Roy Arends <roy@dnss.ec> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) References: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> From: Derek Atkins <derek@ihtfp.com> Date: Thu, 17 Jun 2004 10:33:17 -0400 In-Reply-To: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> (Roy Arends's message of "Thu, 17 Jun 2004 09:28:32 +0200 (CEST)") Message-ID: <sjmbrjiqmoi.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Can you be more explicit about what's actually signed in this proposal? You clearly need to make the signature bound to the actual asked question. But "sign(RRSIG_RDATA)" is not sufficient in my mind to explain what's included in the signature in this response, nor sufficient to bind the RRSIG to this particular question. I do like this approach.... -derek Roy Arends <roy@dnss.ec> writes: > This is an alternative online signing proposal: > > Deny existence for QTYPE,QNAME,QCLASS by responding with empty answer > section and RRSIG in authority section, which is dynamically generated and > has signature field value: sign(RRSIG_RDATA). > > example: > > Dynamic No Data Error > > A "NODATA" response. The RRSIG proves that the requested RR type does > not exist. > > ;; Header: QR AA DO RCODE=0 > ;; > ;; Question > mail.example. IN MX > > ;; Answer > ;; (empty) > > ;; Authority > mail.example. 600 IN RRSIG MX 5 1 600 20040609183619 ( > 20040609183019 37223 example. > ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h > .. > jV7j86HyQgM5e7+miRAz8V01b0I= ) > > ;; Additional > ;; (empty) > > Roy -- 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 Thu Jun 17 10:43:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06092 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 10:43:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bay45-0007dr-DC for namedroppers-data@psg.com; Thu, 17 Jun 2004 14:40:29 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bay43-0007da-O3 for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 14:40:28 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bay42-0004Nh-00 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 16:40:26 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 16:40:26 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 16:40:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1 Date: Thu, 17 Jun 2004 16:40:20 +0200 Lines: 70 Message-ID: <ilullimdz8r.fsf@latte.josefsson.org> References: <200406171114.i5HBED8r026330@birch.ripe.net> <ANECIHCPCBDLLEJLCOPGCEGBCLAA.scottr@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:F5UfTvX4MViQERSH3NsRmNSFA8Q= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk FYI, that issue, and the related Q8, was closed in http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01474.html With the motivation: Q8 - Should the apex allow zone KEY RRs only? *CLOSED: Consensus seems to be no restrictions at all on KEY RR placement in a zone * besides, DNSKEY are the zone keys now. ... Q11 - KEY RRs at delegation point. CLOSED: DNSKEY/KEY would be glue. Not a DNSSEC issue about what to allow as non-auth glue. Local policy about serving and accepting unsigned data would dictate. I'm arguing for the same resolution now. Regards, Simon "Scott Rose" <scottr@nist.gov> writes: > For reference, KEY RRs (back before TCR) was discussed as a formal DNSSECbis > question (Q11): > > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01143.html > > Something might be able to be pulled out of the thread. > > Scott > >> -----Original Message----- >> From: owner-namedroppers@ops.ietf.org >> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf Kolkman >> Sent: Thursday, June 17, 2004 7:14 AM >> To: Simon Josefsson >> Cc: namedroppers@ops.ietf.org >> Subject: Re: draft-ietf-dnsext-dnssec-protocol-06.txt section 2.1 >> >> >> >> Hi Simon, >> >> * Right now, yes. But why prevent a possible future use of it? Unless >> * there is a good reason, that is. And if there is a good reason, I >> * believe the reason should be stated, to explain the protocol >> * requirement. >> >> To prevent long academic discussion it would be nice if you would propose >> text that can be cut-n-paste into the documents. >> >> People can than state if they consent or not consent with the >> proposed text. >> >> >> --Olaf >> (trying to speed things up) >> >> >> -- >> to unsubscribe send a message to namedroppers-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/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 11:08:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08408 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 11:08:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BayRC-000B2i-Og for namedroppers-data@psg.com; Thu, 17 Jun 2004 15:04:22 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BayRB-000B2N-N8 for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 15:04:22 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i5HF4KW4024816; Thu, 17 Jun 2004 15:04:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i5HF4IjO024813; Thu, 17 Jun 2004 15:04:18 GMT Date: Thu, 17 Jun 2004 15:04:18 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis <edlewis@arin.net> Cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Message-ID: <20040617150418.GB24766@vacation.karoshi.com.> References: <20040617101222.36d52f24.olaf@ripe.net> <a06020401bcf747c9f989@[192.168.1.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <a06020401bcf747c9f989@[192.168.1.100]> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > 2. Make it clearer that name space in NSEC records is circular. > > Is the space circular? I used to think so, but am less convinced now > than a week ago. why am i thinking of 802.5 here? in general, I beleive that the -bis docset should be released. nothing prevents future change from occuring. --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 Thu Jun 17 11:10:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08588 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 11:10:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BayTa-000BN3-Rf for namedroppers-data@psg.com; Thu, 17 Jun 2004 15:06:50 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BayTX-000BMU-8Y for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 15:06:47 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 343D2AC8B; Thu, 17 Jun 2004 17:06:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id F0BF4AC88; Thu, 17 Jun 2004 17:06:45 +0200 (CEST) Date: Thu, 17 Jun 2004 17:06:45 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Derek Atkins <derek@ihtfp.com> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <sjmbrjiqmoi.fsf@dogbert.ihtfp.org> Message-ID: <Pine.BSO.4.56.0406171647140.18684@trinitario.schlyter.se> References: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> <sjmbrjiqmoi.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Derek Atkins wrote: > Can you be more explicit about what's actually signed in this > proposal? You clearly need to make the signature bound to the actual > asked question. But "sign(RRSIG_RDATA)" is not sufficient in my mind > to explain what's included in the signature in this response, nor > sufficient to bind the RRSIG to this particular question. Sign(RRSIG_RDATA) assumed that owner name was a field in RRSIG_RDATA, which is not the case. I should have said sign(RRSIG_RDATA | QNAME | QCLASS) where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the Signature field excluded. This RRSIG RDATA has QTYPE in the type covered field. Presented as said in my previous mail (empty answer, rrsig in auth), it can then be interpreted as an authenticated denial for QNAME,QTYPE,QCLASS. 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 Thu Jun 17 11:19:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09344 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 11:19:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaycC-000CQw-Cj for namedroppers-data@psg.com; Thu, 17 Jun 2004 15:15:44 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bayc9-000CQY-0l for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 15:15:41 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bayc8-00054o-00 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 17:15:40 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 17:15:40 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 17:15:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson <jas@extundo.com> Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Date: Thu, 17 Jun 2004 17:15:35 +0200 Lines: 32 Message-ID: <ilud63ydxm0.fsf@latte.josefsson.org> References: <20040617101222.36d52f24.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:NEm3cxAPIUHUSsrSQ/9hS7+HdPQ= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> writes: > Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? I already answered, but as "yes" or "no" sounds more like opinions than technically motivated answers, here is something I believe would complicate NSEC-alt in the future if DNSSECbis is advanced. Section 2.3: Each owner name in the zone which has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. The process for constructing the NSEC RR for a given name is described in [I-D.ietf-dnsext-dnssec-records]. The behaviour for when the MUST is not followed, such as if lying NSEC is used, are not described. It is conceivable that a validating resolver treat missing NSEC's for authoritative data in a zone as a protocol error, and label the zone as bogus, and return SERVFAIL to a CD=0 client. Depending on how resolvers implement the above requirement, this might prevent lying NSEC. It might simplify migration if the presence of NSEC RR was not a protocol requirements, but instead the validation logic simply returned "insecure" (for questions with positive answers) or "bogus" (for questions with negative answers) when a NSEC is missing. This would be a larger change, so I'm not proposing to do this, just that it can be considered. 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 Thu Jun 17 11:25:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09919 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 11:25:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BayiB-000DBN-W4 for namedroppers-data@psg.com; Thu, 17 Jun 2004 15:21:55 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BayiB-000DB7-4e for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 15:21:55 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i5HFLrXB013630; Thu, 17 Jun 2004 11:21:53 -0400 To: Roy Arends <roy@dnss.ec> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) References: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> <sjmbrjiqmoi.fsf@dogbert.ihtfp.org> <Pine.BSO.4.56.0406171647140.18684@trinitario.schlyter.se> From: Derek Atkins <derek@ihtfp.com> Date: Thu, 17 Jun 2004 11:21:53 -0400 In-Reply-To: <Pine.BSO.4.56.0406171647140.18684@trinitario.schlyter.se> (Roy Arends's message of "Thu, 17 Jun 2004 17:06:45 +0200 (CEST)") Message-ID: <sjmu0xap5v2.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > Sign(RRSIG_RDATA) assumed that owner name was a field in RRSIG_RDATA, > which is not the case. I should have said sign(RRSIG_RDATA | QNAME | > QCLASS) where RRSIG_RDATA is the wire format of the RRSIG RDATA fields > with the Signer's Name field in canonical form and the Signature field > excluded. This RRSIG RDATA has QTYPE in the type covered field. > > Presented as said in my previous mail (empty answer, rrsig in auth), it > can then be interpreted as an authenticated denial for > QNAME,QTYPE,QCLASS. Thank you. I believe that sign(RRSIG_RDATA | QNAME | QCLASS) does provide an authenticated denial for QNAME/QTYPE/QCLASS because it'll be a sig over empty data, but still depend on the name/type/class. I'm certainly in favor of this proposal. -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 Thu Jun 17 11:28:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10105 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 11:28:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Baylr-000Dj0-PF for namedroppers-data@psg.com; Thu, 17 Jun 2004 15:25:43 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Baylq-000Die-RH for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 15:25:43 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2998042B2 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 11:25:42 -0400 (EDT) Date: Thu, 17 Jun 2004 11:25:42 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> References: <20040617101222.36d52f24.olaf@ripe.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040617152542.2998042B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 17 Jun 2004 10:12:22 +0200, Olaf Kolkman wrote: > > The question being: > Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Advancing DNSSECbis does not prevent NSEC-alt in the future. Plenty of type codes left in the registry. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 11:36:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10708 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 11:36:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaysP-000Ehz-4N for namedroppers-data@psg.com; Thu, 17 Jun 2004 15:32:29 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaysO-000Ehi-6M for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 15:32:28 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 6247BAC8D; Thu, 17 Jun 2004 17:32:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 49022AC8B; Thu, 17 Jun 2004 17:32:27 +0200 (CEST) Date: Thu, 17 Jun 2004 17:32:26 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Derek Atkins <derek@ihtfp.com> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <sjmu0xap5v2.fsf@dogbert.ihtfp.org> Message-ID: <Pine.BSO.4.56.0406171729210.18684@trinitario.schlyter.se> References: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> <sjmbrjiqmoi.fsf@dogbert.ihtfp.org> <Pine.BSO.4.56.0406171647140.18684@trinitario.schlyter.se> <sjmu0xap5v2.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Derek Atkins wrote: > Roy Arends <roy@dnss.ec> writes: > > > Sign(RRSIG_RDATA) assumed that owner name was a field in RRSIG_RDATA, > > which is not the case. I should have said sign(RRSIG_RDATA | QNAME | > > QCLASS) where RRSIG_RDATA is the wire format of the RRSIG RDATA fields > > with the Signer's Name field in canonical form and the Signature field > > excluded. This RRSIG RDATA has QTYPE in the type covered field. > > > > Presented as said in my previous mail (empty answer, rrsig in auth), it > > can then be interpreted as an authenticated denial for > > QNAME,QTYPE,QCLASS. > > Thank you. I believe that sign(RRSIG_RDATA | QNAME | QCLASS) does > provide an authenticated denial for QNAME/QTYPE/QCLASS because it'll > be a sig over empty data, but still depend on the name/type/class. > > I'm certainly in favor of this proposal Okay, d'you think it is appropriate for -trans ? 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 Thu Jun 17 11:37:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10798 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 11:37:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bayu0-000Eyj-5M for namedroppers-data@psg.com; Thu, 17 Jun 2004 15:34:08 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Baytr-000EwI-9i for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 15:33:59 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E607C19B3C6; Thu, 17 Jun 2004 11:32:04 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 7769F19B33D; Thu, 17 Jun 2004 11:32:04 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1783998; Thu, 17 Jun 2004 11:33:58 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a0602040abcf76a2700df@[192.136.136.83]> In-Reply-To: <20040617152542.2998042B2@thrintun.hactrn.net> References: <20040617101222.36d52f24.olaf@ripe.net> <20040617152542.2998042B2@thrintun.hactrn.net> Date: Thu, 17 Jun 2004 11:33:56 -0400 To: Rob Austein <sra@isc.org> From: Edward Lewis <edlewis@arin.net> Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:25 -0400 6/17/04, Rob Austein wrote: >At Thu, 17 Jun 2004 10:12:22 +0200, Olaf Kolkman wrote: >> >> The question being: >> Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? > >Advancing DNSSECbis does not prevent NSEC-alt in the future. > >Plenty of type codes left in the registry. My concern is "how burned" will DNSSECbis installations be when DNSSECbis++ comes out. (That's why I need to reread -protocol.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 12:02:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13434 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 12:02:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BazEz-000ICo-69 for namedroppers-data@psg.com; Thu, 17 Jun 2004 15:55:49 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BazEy-000ICE-63 for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 15:55:48 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i5HFtYti013957; Thu, 17 Jun 2004 11:55:34 -0400 To: Roy Arends <roy@dnss.ec> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) References: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> <sjmbrjiqmoi.fsf@dogbert.ihtfp.org> <Pine.BSO.4.56.0406171647140.18684@trinitario.schlyter.se> <sjmu0xap5v2.fsf@dogbert.ihtfp.org> <Pine.BSO.4.56.0406171729210.18684@trinitario.schlyter.se> From: Derek Atkins <derek@ihtfp.com> Date: Thu, 17 Jun 2004 11:55:34 -0400 In-Reply-To: <Pine.BSO.4.56.0406171729210.18684@trinitario.schlyter.se> (Roy Arends's message of "Thu, 17 Jun 2004 17:32:26 +0200 (CEST)") Message-ID: <sjmhdtap4ax.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends <roy@dnss.ec> writes: > Okay, d'you think it is appropriate for -trans ? If -trans is suggesting real-time signatures for people who don't want NSEC, then yes I think it's appropriate for -trans. Does it require any changes to bis for proper resolver interpretation of this answer? (I believe the answer to this question is "no", but it's something that needs to be asked). > Roy -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 Thu Jun 17 12:18:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15425 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 12:18:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BazWB-000KaS-AI for namedroppers-data@psg.com; Thu, 17 Jun 2004 16:13:35 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BazWA-000KZu-1g for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 16:13:34 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6C16242B2 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 12:13:33 -0400 (EDT) Date: Thu, 17 Jun 2004 12:13:33 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: TCR In-Reply-To: <a0602040abcf76a2700df@[192.136.136.83]> References: <20040617101222.36d52f24.olaf@ripe.net> <20040617152542.2998042B2@thrintun.hactrn.net> <a0602040abcf76a2700df@192.136.136.83> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040617161333.6C16242B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Subject changed to avoid cluttering chairs' query thread] At Thu, 17 Jun 2004 11:33:56 -0400, Ed Lewis wrote: > > At 11:25 -0400 6/17/04, Rob Austein wrote: > > > >Advancing DNSSECbis does not prevent NSEC-alt in the future. > > > >Plenty of type codes left in the registry. > > My concern is "how burned" will DNSSECbis installations be when > DNSSECbis++ comes out. (That's why I need to reread -protocol.) They wouldn't be burned at all by a full TCR. They wouldn't be part of the DNSSECter universe until they upgrade to software that understands DNSSECter, but that's the way the bagel bends. See the definition of "Proposed Standard". When considering the arguments for and against full TCR, note that, in principle, it is not strictly necessary to have multiple keys for each trust anchor simply because one has multiple KEY-like RR types. That is, one might choose to present the same keying material in more than one KEY-like RR type, so long as the only significant difference between the RR types were the RR type code itself. Whether this approach would allow us to simplify the trust anchor problem during a hypothetical migration from DNSSECbis to DNSSECter remains to be seen, but I suspect that it would at least be worth investigating. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 12:25:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16268 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 12:25:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BazeC-000Lc0-9I for namedroppers-data@psg.com; Thu, 17 Jun 2004 16:21:52 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Baze9-000LbZ-0g for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 16:21:49 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 14621AC8A; Thu, 17 Jun 2004 18:21:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 10044AC88; Thu, 17 Jun 2004 18:21:48 +0200 (CEST) Date: Thu, 17 Jun 2004 18:21:47 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Derek Atkins <derek@ihtfp.com> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <sjmhdtap4ax.fsf@dogbert.ihtfp.org> Message-ID: <Pine.BSO.4.56.0406171818190.18684@trinitario.schlyter.se> References: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> <sjmbrjiqmoi.fsf@dogbert.ihtfp.org> <Pine.BSO.4.56.0406171647140.18684@trinitario.schlyter.se> <sjmu0xap5v2.fsf@dogbert.ihtfp.org> <Pine.BSO.4.56.0406171729210.18684@trinitario.schlyter.se> <sjmhdtap4ax.fsf@dogbert.ihtfp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Derek Atkins wrote: > Roy Arends <roy@dnss.ec> writes: > > > Okay, d'you think it is appropriate for -trans ? > > If -trans is suggesting real-time signatures for people who don't want > NSEC, then yes I think it's appropriate for -trans. Yes. -trans is suggesting real-time signatures as a measure against zone-traversal until dnssec-ter has arrived. For the rest, there is dnssec-ter, or the DoNothing option. > Does it require any changes to bis for proper resolver interpretation of > this answer? (I believe the answer to this question is "no", but it's > something that needs to be asked). Well, hmmm, it is a response-type that dnssec-bis resolvers do not yet swallow. I think the changes to -bis are minimal to allow this. 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 Thu Jun 17 12:30:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16577 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 12:30:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BaziG-000MGt-Fs for namedroppers-data@psg.com; Thu, 17 Jun 2004 16:26:04 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaziF-000MGY-BY for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 16:26:03 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 17 Jun 2004 12:26:02 -0400 id 0013527A.40D1C61A.000049A4 From: David Blacka <davidb@verisignlabs.com> Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Date: Thu, 17 Jun 2004 12:26:02 -0400 User-Agent: KMail/1.6.2 References: <20040617101222.36d52f24.olaf@ripe.net> In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406171226.02178.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 17 June 2004 4:12 am, Olaf M. Kolkman wrote: > The question being: > Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Well, we certainly know *a* way to implement NSEC-alt in the future. What I am concerned about is that we don't know if that way is the "best" way. I think we would be doing ourselves a disservice if we do not try to understand the pros and cons of a number of different transition strategies before submitting the DNSSEC-bis documents to the IESG. In my mind, the central property of a transition mechanism is that it is able to protect "legacy" validators from non-backwards-compatible changes to DNSSEC. I believe that a full typecode rollover would fulfill this requirement, but so would other, possibly less onerous mechanisms. And these other mechanisms might require some minor language changes. -- 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 Thu Jun 17 12:36:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17418 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 12:36:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BazoP-000N3V-Qr for namedroppers-data@psg.com; Thu, 17 Jun 2004 16:32:25 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BazoE-000N2P-Rg for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 16:32:15 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5HGW6C0005169 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 12:32:06 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i5HGVa4A002471 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 12:31:36 -0400 (EDT) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: RE: rrsig(qtype) Date: Thu, 17 Jun 2004 12:31:36 -0400 Message-ID: <ANECIHCPCBDLLEJLCOPGGEGMCLAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <sjmhdtap4ax.fsf@dogbert.ihtfp.org> Importance: Normal X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Derek Atkins > > > Roy Arends <roy@dnss.ec> writes: > > > Okay, d'you think it is appropriate for -trans ? > > If -trans is suggesting real-time signatures for people who don't want > NSEC, then yes I think it's appropriate for -trans. Does it require > any changes to bis for proper resolver interpretation of this answer? > (I believe the answer to this question is "no", but it's something > that needs to be asked). > I believe it does require some spec change. Now RRSIGs are being used to provide non-existent responses, instead of just providing origin authentication and data integrity. Not major overhauls, but changes. And signaling non-signed delegations might need some clarification (if this scheme is used). It would look something like this (if I am not mistaken): Question: www.example.com Ans: Auth: example.com. NS somehost example.com RRSIG(DS) signer-.com Add: somehost A 10.10.10.1 It sounds like an possibly viable option. One that could be added to the DNSSECbis->DNSSECter draft. 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 Thu Jun 17 13:49:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26993 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 13:49:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb0vL-0005D9-LS for namedroppers-data@psg.com; Thu, 17 Jun 2004 17:43:39 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb0vJ-0005Cq-Vg for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 17:43:38 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id AF7E8AC8A; Thu, 17 Jun 2004 19:43:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 80D31AC88; Thu, 17 Jun 2004 19:43:36 +0200 (CEST) Date: Thu, 17 Jun 2004 19:43:36 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Scott Rose <scottr@nist.gov> Cc: namedroppers@ops.ietf.org Subject: RE: rrsig(qtype) In-Reply-To: <ANECIHCPCBDLLEJLCOPGGEGMCLAA.scottr@nist.gov> Message-ID: <Pine.BSO.4.56.0406171930140.18684@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGGEGMCLAA.scottr@nist.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Scott Rose wrote: > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org > > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Derek Atkins > > > > > > Roy Arends <roy@dnss.ec> writes: > > > > > Okay, d'you think it is appropriate for -trans ? > > > > If -trans is suggesting real-time signatures for people who don't want > > NSEC, then yes I think it's appropriate for -trans. Does it require > > any changes to bis for proper resolver interpretation of this answer? > > (I believe the answer to this question is "no", but it's something > > that needs to be asked). > > > > I believe it does require some spec change. Now RRSIGs are being used to > provide non-existent responses, instead of just providing origin > authentication and data integrity. Not major overhauls, but changes. Yes. > And signaling non-signed delegations might need some clarification (if this > scheme is used). It would look something like this (if I am not mistaken): > > Question: www.example.com > > Ans: > > Auth: > example.com. NS somehost > example.com RRSIG(DS) signer-.com > Add: > somehost A 10.10.10.1 Exactly. > It sounds like an possibly viable option. One that could be added to the > DNSSECbis->DNSSECter draft. Okay 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 Thu Jun 17 14:15:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00932 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 14:15:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb1Mj-0008js-Rw for namedroppers-data@psg.com; Thu, 17 Jun 2004 18:11:57 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb1Mi-0008jb-Q3 for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 18:11:56 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 7567319B868; Thu, 17 Jun 2004 14:10:00 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id E6D2419B6D9; Thu, 17 Jun 2004 14:09:59 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1784541; Thu, 17 Jun 2004 14:11:55 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020411bcf78c04f07b@[192.136.136.83]> In-Reply-To: <20040617161333.6C16242B2@thrintun.hactrn.net> References: <20040617101222.36d52f24.olaf@ripe.net> <20040617152542.2998042B2@thrintun.hactrn.net> <a0602040abcf76a2700df@192.136.136.83> <20040617161333.6C16242B2@thrintun.hactrn.net> Date: Thu, 17 Jun 2004 14:11:37 -0400 To: Rob Austein <sra@isc.org> From: Edward Lewis <edlewis@arin.net> Subject: Re: TCR Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:13 -0400 6/17/04, Rob Austein wrote: >between the RR types were the RR type code itself. Whether this >approach would allow us to simplify the trust anchor problem during a >hypothetical migration from DNSSECbis to DNSSECter remains to be seen, >but I suspect that it would at least be worth investigating. I'd like to agree, but I have a nagging suspicion. On the one hand there is the point about what Proposed Standard means. In that case, rolling to new versions is a non-issue. Trusted keys for islands "deep" in the zone I suspect are easily handled too. It's "what if there's a DNSSECbis key for the root" or some other top zone? Maybe - what if we discourage a key from being distributed (operationally) for the root until we get to Draft Standard? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 14:16:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01002 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 14:16:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb1La-0008d2-RU for namedroppers-data@psg.com; Thu, 17 Jun 2004 18:10:46 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb1LZ-0008ch-0Z for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 18:10:45 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4ECD942B2 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 14:10:44 -0400 (EDT) Date: Thu, 17 Jun 2004 14:10:44 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <Pine.BSO.4.56.0406171930140.18684@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGGEGMCLAA.scottr@nist.gov> <Pine.BSO.4.56.0406171930140.18684@trinitario.schlyter.se> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040617181044.4ECD942B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk General issue with sign-on-the-fly, not limited to Roy's proposal. What happens to the data-producer to data-consumer end-to-end trust model with these online signing models? Is the response cachable? Is this the thin edge of a conversion of DNSSEC from object security into channel security? Color me concerned about depth of water and strength of undertow. Note that while DNSSEC combined with dynamic update shared some of these properties, the conceptual model in that case is that the data producer for DNSSEC purposes is what RFC 2136 calls the "primary master server". That is, in the dynamic update case there are (at least) two separate trust relationships: one is between the update client and the primary master server for the dynamic update protocol; the other is between the dynamic update engine (which has been configured to act on behalf of the zone admin) and the DNSSEC validator. I do not (yet?) understand what the trust relationships look like in these sign-on-the-fly-to-avoid-real-NSEC proposals. Who is trusting whom to do what? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 15:09:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05705 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:09:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2AV-000FJC-Ne for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:03:23 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2AR-000FIN-Pe for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:03:20 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 54A9BAC88; Thu, 17 Jun 2004 21:03:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 242C8AC87; Thu, 17 Jun 2004 21:03:18 +0200 (CEST) Date: Thu, 17 Jun 2004 21:03:17 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Rob Austein <sra@isc.org> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <20040617181044.4ECD942B2@thrintun.hactrn.net> Message-ID: <Pine.BSO.4.56.0406172022560.18684@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGGEGMCLAA.scottr@nist.gov> <Pine.BSO.4.56.0406171930140.18684@trinitario.schlyter.se> <20040617181044.4ECD942B2@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Rob Austein wrote: > General issue with sign-on-the-fly, not limited to Roy's proposal. > > What happens to the data-producer to data-consumer end-to-end trust > model with these online signing models? Is the response cachable? Is > this the thin edge of a conversion of DNSSEC from object security into > channel security? Since the response would be a negative response in all aspects, its just as cachable as any other negative response. This is undoubtedly object security, not channel security. The proposal is to sign a non-existent object. A none existent object is logically an object with name type class, neg-ttl, no rdata. That is what is signed. > Color me concerned about depth of water and strength of undertow. > > Note that while DNSSEC combined with dynamic update shared some of > these properties, the conceptual model in that case is that the data > producer for DNSSEC purposes is what RFC 2136 calls the "primary > master server". That is, in the dynamic update case there are (at > least) two separate trust relationships: one is between the update > client and the primary master server for the dynamic update protocol; > the other is between the dynamic update engine (which has been > configured to act on behalf of the zone admin) and the DNSSEC > validator. > > I do not (yet?) understand what the trust relationships look like in > these sign-on-the-fly-to-avoid-real-NSEC proposals. > > Who is trusting whom to do what? A primary master trusts(1) the update client to update zone. A DNSSEC validator trusts(2) the master-in-zone-mode-B to update zone. A DNSSEC validator trusts(3) the signing oracle at the master to sign empty objects. (1) The trust is established by message authentication (rfc3007) using either TSIG or SIG(0) (2) Since a DNSSEC validator is oblivious that a zone is subject to secure dynamic update, trust is established by standard DNSSEC operation. The trust between the primary master and the 'dynamic update engine' is done oob, or might be converged to a single elephant. (3) The trust is established by DNSSEC operation (if DNSSEC-bis is ammended to trust signed epty objects) Since (2) and (3) have different properties (signed objects with data vs signed objects without data) different keys could be used (not required). 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 Thu Jun 17 15:11:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06056 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:11:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2Ei-000Fwl-4s for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:07:44 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2Eg-000FwK-SS for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:07:43 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id D6D43AC88; Thu, 17 Jun 2004 21:07:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id B5073AC87; Thu, 17 Jun 2004 21:07:41 +0200 (CEST) Date: Thu, 17 Jun 2004 21:07:41 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Scott Rose <scottr@nist.gov> Cc: namedroppers@ops.ietf.org Subject: RE: rrsig(qtype) In-Reply-To: <Pine.BSO.4.56.0406171930140.18684@trinitario.schlyter.se> Message-ID: <Pine.BSO.4.56.0406171954310.18684@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGGEGMCLAA.scottr@nist.gov> <Pine.BSO.4.56.0406171930140.18684@trinitario.schlyter.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Roy Arends wrote: > On Thu, 17 Jun 2004, Scott Rose wrote: > > > And signaling non-signed delegations might need some clarification (if this > > scheme is used). It would look something like this (if I am not mistaken): > > > > Question: www.example.com > > > > Ans: > > > > Auth: > > example.com. NS somehost > > example.com RRSIG(DS) signer-.com > > Add: > > somehost A 10.10.10.1 > > Exactly. Here is the full list of response types. Note that RRSIG(any) is introduced here, signalling no type exist for name to imply existence of empty non-terminals, where with NSEC you'd think in 'closest match'. Name Error An authoritative name error. The special RRSIG RRs prove that the name does not exist and that no covering wildcard exists. ;; Header: QR AA DO RCODE=3 ;; ;; Question ml.example. IN A ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ... example. 3600 RRSIG SOA ... ml.example. 600 RRSIG ANY ... *.example. 600 RRSIG ANY ... ;; Additional ;; (empty) No Data Error A "NODATA" response. The special RRSIG RR proves that the name exists and that the requested RR type does not. ;; Header: QR AA DO RCODE=0 ;; ;; Question ns1.example. IN MX ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ... example. 3600 RRSIG SOA ... ns1.example. 600 RRSIG MX ... ;; Additional ;; (empty) Referral to Unsigned Zone Referral to an unsigned zone. The special RRSIG RR proves that no DS RR for this delegation exists in the parent zone. ;; Header: QR DO RCODE=0 ;; ;; Question mc.b.example. IN MX ;; Answer ;; (empty) ;; Authority b.example. 3600 IN NS ns1.b.example. b.example. 3600 IN NS ns2.b.example. b.example. 600 RRSIG DS .. ;; Additional ns1.b.example. 3600 IN A 192.0.2.7 ns2.b.example. 3600 IN A 192.0.2.8 Wildcard Expansion A successful query which was answered via wildcard expansion. The label count in the answer's RRSIG RR indicates that a wildcard RRset was expanded to produce this response, and the special RRSIG RR proves that no closer match exists in the zone. ;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN MX ;; Answer a.z.w.example. 3600 IN MX 1 ai.example. a.z.w.example. 3600 RRSIG MX 5 2 ... ;; Authority example. 3600 NS ns1.example. example. 3600 NS ns2.example. example. 3600 RRSIG NS .. z.w.example. 600 RRSIG ANY .. a.z.w.example. 600 RRSIG ANY .. ;; Additional ai.example. 3600 IN A ... ai.example. 3600 RRSIG A ... ai.example. 3600 AAAA ... ai.example. 3600 RRSIG AAAA ... Wildcard No Data Error A "NODATA" response for a name covered by a wildcard. The special RRSIG RRs prove that the matching wildcard name does not have any RRs of the requested type and that no closer match exists in the zone. ;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN AAAA ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ... example. 3600 RRSIG SOA ... z.w.example. 600 RRSIG ANY ... *.w.example. 600 RRSIG AAAA ... ;; Additional ;; (empty) DS Child Zone No Data Error A "NODATA" response for a QTYPE=DS query which was mistakenly sent to a name server for the child zone. ;; Header: QR AA DO RCODE=0 ;; ;; Question example. IN DS ;; Answer ;; (empty) ;; Authority example. 3600 IN SOA ... example. 3600 RRSIG SOA ... example. 600 RRSIG DS ... ;; Additional ;; (empty) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 15:14:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06475 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:14:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2GX-000GEW-NS for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:09:37 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2GW-000GDt-Gu for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:09:36 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id i5HJ9Qqf004233 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 15:09:30 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.1.0.6.2.20040616223651.02d08b40@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Wed, 16 Jun 2004 23:03:21 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: back to: zone-covering NSEC ranges -- "which is it?" In-Reply-To: <20040616164528.EE9D442B2@thrintun.hactrn.net> References: <roy@gnomon.org.uk> <16591.41396.6849.490196@giles.gnomon.org.uk> <20040616061147.7E35613993@sa.vix.com> <20040616164528.EE9D442B2@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.43 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:45 16/06/2004, Rob Austein wrote: >I'm not comfortable with this X NSEC X thing, for two reasons: > >a) As far as I can tell, the answer to the question "is it circular or > is X NSEC @ a special case?" is "mu". The only case where the > circularity mattered in RFC 2535 for X NXT Y was Y = @, because in > all other cases, Y > X, by definition. > >b) Defining X NSEC X to be a statement just about X would require > treating @ NSEC @ as a special case. <just a regular wg-member> @ NSEC @ with SOA bit set zone @ has only records at apex and here is the list. X NSEC X (w/o SOA bit set) is IMHO a REAL BAD IDEA. It says name X exits and has following types, this is not what you want to communicate as it may confuse resolvers. It is perfectly valid for a validating resolver to return to client RCODE=0 with empty answer, rather than the intended RCODE=3. What should be done in this case is pred(X) NSEC succ(X) where pred(X) is a name that is: close to X and does not exist sorts before X and succ(X) close to X and does not exist sorts after X In this case there are no special cases, resolver that only looks at the owner name when there is a match does not get confused. example: pred("amazon") == amazom\376\376\376\376 succ("amazon") == amazon\001\001\001\001 or pred("amazon") == amazom\200 succ("amazon") == amazon\037 Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 15:15:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06623 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:15:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2HK-000GNz-Fy for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:10:26 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2HJ-000GNT-FS for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:10:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 28B1013951 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 19:10:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: Message from Roy Arends <roy@dnss.ec> of "Thu, 17 Jun 2004 17:06:45 +0200." <Pine.BSO.4.56.0406171647140.18684@trinitario.schlyter.se> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 17 Jun 2004 19:10:25 +0000 Message-Id: <20040617191025.28B1013951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Presented as said in my previous mail (empty answer, rrsig in auth), it > can then be interpreted as an authenticated denial for QNAME,QTYPE,QCLASS. but not for <qname,qclass> as in authenticated rcode=3? would that become possible if we used qtype=NULL or qtype=ANY as a special case? (note that i'm very concerned about another aspect of this, but i want to answer that part separately.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 15:21:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07204 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:21:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2M0-000H6t-Am for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:15:16 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2Lz-000H6Y-EB for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:15:15 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 128C213DE9 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 19:15:15 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: Message from Roy Arends <roy@dnss.ec> of "Thu, 17 Jun 2004 18:21:47 +0200." <Pine.BSO.4.56.0406171818190.18684@trinitario.schlyter.se> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 17 Jun 2004 19:15:15 +0000 Message-Id: <20040617191515.128C213DE9@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i promised to speak separately about my larger concerns about this approach: > > > Okay, d'you think it is appropriate for -trans ? > > > > If -trans is suggesting real-time signatures for people who don't want > > NSEC, then yes I think it's appropriate for -trans. > > Yes. -trans is suggesting real-time signatures as a measure against > zone-traversal until dnssec-ter has arrived. For the rest, there is > dnssec-ter, or the DoNothing option. do you mean you intend to modify -bis to require that initiators be able to recognize this form of on-the-fly denial of existence if responders wish to avoid the precomputed-NSEC method? things that would require changes to the entire installed based in order to be effective belong in -bis rather than in -trans. (and it doesn't even belong in -trans unless it also provides an way to encode authenticated nonexistence of <qname,qclass> not just <...,qtype>.) > > Does it require any changes to bis for proper resolver interpretation of > > this answer? (I believe the answer to this question is "no", but it's > > something that needs to be asked). > > Well, hmmm, it is a response-type that dnssec-bis resolvers do not yet > swallow. I think the changes to -bis are minimal to allow this. i think you're wrong, and that the changes would have to go through considerable review, analysis, modelling, and testing before i'd feel comfortable approving 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 Thu Jun 17 15:23:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07482 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:23:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2PV-000Hcd-L6 for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:18:53 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2PU-000HcO-SL for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:18:52 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8A5DD13971 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 19:18:52 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: TCR In-Reply-To: Message from Edward Lewis <edlewis@arin.net> of "Thu, 17 Jun 2004 14:11:37 -0400." <a06020411bcf78c04f07b@[192.136.136.83]> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 17 Jun 2004 19:18:52 +0000 Message-Id: <20040617191852.8A5DD13971@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It's "what if there's a DNSSECbis key for the root" or some other top zone? > > Maybe - what if we discourage a key from being distributed (operationally) > for the root until we get to Draft Standard? semantically, that boils down to "dnssec-bis is not dnssec, use it for small experiments only, we'll have -ter for you in a year or two." let's be very careful about actually making statements equivalent to that. (the above is only a proposal, not a statement, so we're ok so far... but the day is young.) ((herding cats would be easier. this is like trying to get a bunch of puppies into a bag, without a twist-tie and without rocks.)) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 15:31:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08006 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:31:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2YQ-000Ivn-3w for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:28:06 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2YO-000IvI-TF for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:28:05 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id E390CAC88; Thu, 17 Jun 2004 21:28:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id C80AFAC87; Thu, 17 Jun 2004 21:28:03 +0200 (CEST) Date: Thu, 17 Jun 2004 21:28:03 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <20040617191025.28B1013951@sa.vix.com> Message-ID: <Pine.BSO.4.56.0406172127450.18684@trinitario.schlyter.se> References: <20040617191025.28B1013951@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Paul Vixie wrote: > > Presented as said in my previous mail (empty answer, rrsig in auth), it > > can then be interpreted as an authenticated denial for QNAME,QTYPE,QCLASS. > > but not for <qname,qclass> as in authenticated rcode=3? would that become > possible if we used qtype=NULL or qtype=ANY as a special case? qtype=any 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 Thu Jun 17 15:43:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08534 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:43:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2ja-000KGL-VN for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:39:38 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2jZ-000KG0-VK for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:39:38 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id B185842B2 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 15:39:36 -0400 (EDT) Date: Thu, 17 Jun 2004 15:39:36 -0400 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <Pine.BSO.4.56.0406172022560.18684@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGGEGMCLAA.scottr@nist.gov> <Pine.BSO.4.56.0406171930140.18684@trinitario.schlyter.se> <20040617181044.4ECD942B2@thrintun.hactrn.net> <Pine.BSO.4.56.0406172022560.18684@trinitario.schlyter.se> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040617193936.B185842B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 17 Jun 2004 21:03:17 +0200 (CEST), Roy Arends wrote: > > Since the response would be a negative response in all aspects, its just > as cachable as any other negative response. This is undoubtedly object > security, not channel security. The proposal is to sign a non-existent > object. A none existent object is logically an object with name type > class, neg-ttl, no rdata. That is what is signed. > ... > A DNSSEC validator trusts(3) the signing oracle at the master to sign > empty objects. >... > (3) The trust is established by DNSSEC operation (if DNSSEC-bis is > ammended to trust signed epty objects) The point (which no doubt I expressed badly) is that yes, indeed, this looks just like object security to the DNSSEC validator, but the trust relationship is significantly different, since the "signing oracle" might be any of the authoritative name server for the zone (which isn't the case for dynamic update). Perhaps it will turn out to be the case that the folks most likely to use a sign-on-the-fly hack also operate all of the authoritative name servers for their zones, in which case the distinction between trusting the zone admin and trusting the authoritative server admin is moot, because they're the same entity. But at the very least we need to document what sign-on-the-fly does to the trust model so that people tempted to use it will understand the issue. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 15:43:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08552 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 15:43:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb2k6-000KJt-A0 for namedroppers-data@psg.com; Thu, 17 Jun 2004 19:40:10 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb2k5-000KJb-20 for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 19:40:09 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id AFB83AC88; Thu, 17 Jun 2004 21:40:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 84FC8AC87; Thu, 17 Jun 2004 21:40:07 +0200 (CEST) Date: Thu, 17 Jun 2004 21:40:06 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <20040617191515.128C213DE9@sa.vix.com> Message-ID: <Pine.BSO.4.56.0406172128220.18684@trinitario.schlyter.se> References: <20040617191515.128C213DE9@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Paul Vixie wrote: > i promised to speak separately about my larger concerns about this approach: > > > > > Okay, d'you think it is appropriate for -trans ? > > > > > > If -trans is suggesting real-time signatures for people who don't want > > > NSEC, then yes I think it's appropriate for -trans. > > > > Yes. -trans is suggesting real-time signatures as a measure against > > zone-traversal until dnssec-ter has arrived. For the rest, there is > > dnssec-ter, or the DoNothing option. > > do you mean you intend to modify -bis to require that initiators be able > to recognize this form of on-the-fly denial of existence if responders > wish to avoid the precomputed-NSEC method? Not entirely. If the change would be minimal (and it seems that is not the case), I would recommend to change -bis. But if it would delay -bis for more then the currently expected editorial/clarification delay it would not be worth it. > things that would require changes to the entire installed based in order > to be effective belong in -bis rather than in -trans. I agree. > (and it doesn't even belong in -trans unless it also provides an way to > encode authenticated nonexistence of <qname,qclass> not just <...,qtype>.) rrsig(any). > > > Does it require any changes to bis for proper resolver interpretation of > > > this answer? (I believe the answer to this question is "no", but it's > > > something that needs to be asked). > > > > Well, hmmm, it is a response-type that dnssec-bis resolvers do not yet > > swallow. I think the changes to -bis are minimal to allow this. > > i think you're wrong, and that the changes would have to go through > considerable review, analysis, modelling, and testing before i'd feel > comfortable approving them. I understand your concern. I've been through all the response types containing NSECs, and it is indeed not trivial, though much less complex, since the denial is explicit instead of implicit. In any case, it is a protocol change. The whole rrsig(qtype) is imho a working concept as a defense against zone-traversal, but it is too late for -bis and too early for -ter. I won't stuff it in -trans and bring it up after -ter. 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 Thu Jun 17 16:11:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10336 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 16:11:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb370-000Nmn-SD for namedroppers-data@psg.com; Thu, 17 Jun 2004 20:03:50 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb36r-000Nl9-90 for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 20:03:42 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 77278AC8A; Thu, 17 Jun 2004 22:03:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 57FC5AC88; Thu, 17 Jun 2004 22:03:40 +0200 (CEST) Date: Thu, 17 Jun 2004 22:03:40 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: Rob Austein <sra@isc.org> Cc: namedroppers@ops.ietf.org Subject: Re: rrsig(qtype) In-Reply-To: <20040617193936.B185842B2@thrintun.hactrn.net> Message-ID: <Pine.BSO.4.56.0406172147350.18684@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGGEGMCLAA.scottr@nist.gov> <Pine.BSO.4.56.0406171930140.18684@trinitario.schlyter.se> <20040617181044.4ECD942B2@thrintun.hactrn.net> <Pine.BSO.4.56.0406172022560.18684@trinitario.schlyter.se> <20040617193936.B185842B2@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 17 Jun 2004, Rob Austein wrote: > At Thu, 17 Jun 2004 21:03:17 +0200 (CEST), Roy Arends wrote: > > > > Since the response would be a negative response in all aspects, its just > > as cachable as any other negative response. This is undoubtedly object > > security, not channel security. The proposal is to sign a non-existent > > object. A none existent object is logically an object with name type > > class, neg-ttl, no rdata. That is what is signed. > > ... > > A DNSSEC validator trusts(3) the signing oracle at the master to sign > > empty objects. > >... > > (3) The trust is established by DNSSEC operation (if DNSSEC-bis is > > ammended to trust signed epty objects) > > The point (which no doubt I expressed badly) is that yes, indeed, this > looks just like object security to the DNSSEC validator, but the trust > relationship is significantly different, since the "signing oracle" > might be any of the authoritative name server for the zone (which > isn't the case for dynamic update). Yes, don't compare it to dynupdate. I do understand the comparison to transaction signatures and indeed, the thick wall in between deteriorates to a thin line. Especially since in practise, zone-admin will use a zone-key _per_server_ which makes trust relationship really vague. > Perhaps it will turn out to be the case that the folks most likely to > use a sign-on-the-fly hack also operate all of the authoritative name > servers for their zones, in which case the distinction between > trusting the zone admin and trusting the authoritative server admin is > moot, because they're the same entity. Yes. > But at the very least we need to document what sign-on-the-fly does to > the trust model so that people tempted to use it will understand the > issue. Yes. One side-note. There have been several interim solutions as a defense against zone-enumeration. Online signing of malformed nsec is just one. I really start to like Alex Bligh' do nothing option as an interim. All other interim proposals seem hacky. 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 Thu Jun 17 19:28:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25743 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 19:28:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb6Dq-000Nc8-5D for namedroppers-data@psg.com; Thu, 17 Jun 2004 23:23:06 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb6Do-000Nbs-Sd for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 23:23:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5HMrZax004240 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 18:53:35 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA59ayqi; Thu, 17 Jun 04 18:53:33 -0400 Received: from [157.185.80.164] (filbert [10.66.1.10]) by tislabs.com (8.12.9/8.12.9) with ESMTP id i5HMsWt2004071; Thu, 17 Jun 2004 18:54:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: mundy@127.0.0.1 Message-Id: <p06110401bcf7d1b9666e@[157.185.80.164]> In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> References: <20040617101222.36d52f24.olaf@ripe.net> Date: Thu, 17 Jun 2004 18:55:41 -0400 To: "Olaf M. Kolkman" <olaf@ripe.net> From: Russ Mundy <mundy@tislabs.com> Subject: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 10:12 AM +0200 6/17/04, Olaf M. Kolkman wrote: ---------------------------------- snip --------------------------------- > >The question being: >Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? No, advancing these now does NOT prevent NSEC-alt (or other changes) in the future. =46olks that use implementations of RFC's that are Proposed Standards should expect to have the specs change. I now have one signed zone operating with a currently available implementation and would like to field additional signed zones to have more operational experience. I also have some good sized customers that have a signed zone experiment underway and these users would very much like to see DNSSECbis get published as RFCs. > >There has not been enough clear statements, we are looking for >support, please help us out. Certainly will. I would very much like to see the DNSSECbis go forward now (sooner as opposed to later). Folks that I know who want to use this now want to do so even if they need to make some changes later. It's not easy to make some changes but others come more or less for 'free' with the normal upgrade of new software so even though some future changes may be needed, they would much rather have DNSSECbis go to RFCs sooner rather than later (even if change is needed later). > >We need to be able document that there is consensus that forwarding >DNSSEC-bis does not close the door on NSEC2, NSEC-alt or other methods >denial of existence that prevent zone enumeration. I don't know of any reason why publishing DNSSECbis would close that door nor have I seen any convincing description of one on the list. Additionally, changes to specs at the Proposed Standard level should be consider 'normal' per the established IETF standards process (per para 4.1.1, BCP-9/RFC-2026). Although the focus of much of the WG discussion lately has been on possible changes to NSEC, operational use of implementations of the current specs may well identify other changes that will need to be incorporated. This should be viewed as normal and a feature of the IETF process (BCP-9/RFC-2026) - we should use the 'feature' not fight it. We (the working group) should make well engineered, intelligent choices for the current specifications to allow for future change but potential requirement(s) for future change should _not_ keep the current specifications from moving forward. > >Please respond either on the mailing list or in a e-mail to both >chairs. > >Following are the changes the chairs are aware off and will >be done before documents are forward to IESG: > > 1. Caching issue brought up by David Blacka. > 2. Make it clearer that name space in NSEC records is circular. > 3. Minor text clarifications brought up. This is a Good Thing. > >Issues that are not resolved yet: > 1. Division of flag bits, as proposed by Simon Josefsson > 2. Need for special cases in NSEC records processing for > white lies/on-line signing. Publish what's ready now, work these requirement/issues in the WG and publish RFCs as needed to update (change) in the future what needs to be published now. After all, the specs are at the Proposed level where (according to BCP-9) change should be expected. If it turns out that changes are not needed, then we're that much closer to being able to advance things to the Draft level. > >Speak out if you think these items need or need not be resolved. If >you think these items need to be resolved than contribute with text >that can go into the document. If there is no obvious consensus on >support for these proposals, they will not be taken into account. I certainly agree that there is not a consensus on how to resolve the two issues identified above but I also think that we should forward the documents to the IESG as soon as the listed clarifications are completed. As long as we are committed to address these issues (and others that might arise) in a reasonable time-frame, individuals with concerns about identified issues should be able to expect the WG to address them and develop changes that might be required in some reasonable time period - the real key being 'reasonable time period'. > >We need to move forward. If not, we will not make the cut-off date, >run into the holiday season and it will be mid September before we >have had any progress. > > > =D3lafur and Olaf > DNSEXT Co-Chairs > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> Russ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Jun 17 21:23:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03358 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 21:23:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb825-0009V5-5s for namedroppers-data@psg.com; Fri, 18 Jun 2004 01:19:05 +0000 Received: from [213.248.199.19] (helo=mx1.nominet.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb823-0009Us-Pn for namedroppers@ops.ietf.org; Fri, 18 Jun 2004 01:19:04 +0000 Received: by mx1.nominet.org.uk (Postfix, from userid 65536) id AF4CDE7E5D; Fri, 18 Jun 2004 02:19:02 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> Message-Id: <20040618011902.AF4CDE7E5D@mx1.nominet.org.uk> Date: Fri, 18 Jun 2004 02:19:02 +0100 (BST) From: geoff@nominet.org.uk (Geoffrey Sisson) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" <olaf@ripe.net> writes: > >Please speak up on this question to help chairs gauge consensus. > > The question being: > Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? A: I'm persuaded that -ter represents a viable roadmap to NSEC-alt, so I now think the DNSSECbis docset can go to the IESG without the introduction of any version/MBZ fields. Roy's rrsig(qtype) proposal looks promising and, unless any killer corner cases are found, I would favour changes to the DNSSECbis docset which would make this option available to anyone who might want/have to do on-the-fly signing. This should not be interpreted to mean that Nominet might not still use NSEC white lies. 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 Thu Jun 17 22:37:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06830 for <dnsext-archive@lists.ietf.org>; Thu, 17 Jun 2004 22:37:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb9CG-000G7p-5e for namedroppers-data@psg.com; Fri, 18 Jun 2004 02:33:40 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb9CF-000G7c-3a for namedroppers@ops.ietf.org; Fri, 18 Jun 2004 02:33:39 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id AE73F19B6AC; Thu, 17 Jun 2004 22:31:36 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3DB5E19B692; Thu, 17 Jun 2004 22:31:36 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1786003; Thu, 17 Jun 2004 22:33:38 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020401bcf803be9de0@[192.168.1.100]> In-Reply-To: <20040617191852.8A5DD13971@sa.vix.com> References: <20040617191852.8A5DD13971@sa.vix.com> Date: Thu, 17 Jun 2004 22:33:32 -0400 To: Paul Vixie <paul@vix.com> From: Edward Lewis <edlewis@arin.net> Subject: Re: TCR Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >semantically, that boils down to "dnssec-bis is not dnssec, use it for >small experiments only, we'll have -ter for you in a year or two." That struck me too as I sent it. >let's be very careful about actually making statements equivalent to that. >(the above is only a proposal, not a statement, so we're ok so far... but >the day is young.) 'Zactly. Given experience, it's probably wise to just say "here is the spec" and let the community figure out what to do (or not) with it. Right now I kind of like using the proto field of the DNSKEY to "signal" a new method, recognizing there are other approaches out there. Given the tenor that this is just a Proposed Standard and all that it entails, I think we might as well push the docs as they are. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 18 01:51:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14841 for <dnsext-archive@lists.ietf.org>; Fri, 18 Jun 2004 01:51:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbCC4-0006a6-7D for namedroppers-data@psg.com; Fri, 18 Jun 2004 05:45:40 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbCC2-0006Za-KQ for namedroppers@ops.ietf.org; Fri, 18 Jun 2004 05:45:39 +0000 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.12.11/8.12.11) with ESMTP id i5I5jbDf022622 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Fri, 18 Jun 2004 07:45:37 +0200 (CEST) Received: (from leinen@localhost) by diotima.switch.ch (8.12.11/8.12.11/Submit) id i5I5jaeb022621; Fri, 18 Jun 2004 07:45:36 +0200 (CEST) Received: from chx400.switch.ch ([130.59.10.2]) by central.switch.ch with esmtp (Exim 3.20 #1) id 1Bb6JI-00040N-00; Fri, 18 Jun 2004 01:28:44 +0200 Received: from psg.com ([147.28.0.62]) by chx400.switch.ch with esmtp (Exim 3.20 #1) id 1Bb6JI-0004V1-00; Fri, 18 Jun 2004 01:28:44 +0200 Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bb6Dq-000Nc8-5D for namedroppers-data@psg.com; Thu, 17 Jun 2004 23:23:06 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb6Do-000Nbs-Sd for namedroppers@ops.ietf.org; Thu, 17 Jun 2004 23:23:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5HMrZax004240 for <namedroppers@ops.ietf.org>; Thu, 17 Jun 2004 18:53:35 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA59ayqi; Thu, 17 Jun 04 18:53:33 -0400 Received: from [157.185.80.164] (filbert [10.66.1.10]) by tislabs.com (8.12.9/8.12.9) with ESMTP id i5HMsWt2004071; Thu, 17 Jun 2004 18:54:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: mundy@127.0.0.1 Message-Id: <p06110401bcf7d1b9666e@[157.185.80.164]> In-Reply-To: <20040617101222.36d52f24.olaf@ripe.net> References: <20040617101222.36d52f24.olaf@ripe.net> Date: Thu, 17 Jun 2004 18:55:41 -0400 To: "Olaf M. Kolkman" <olaf@ripe.net> From: Russ Mundy <mundy@tislabs.com> Subject: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 10:12 AM +0200 6/17/04, Olaf M. Kolkman wrote: ---------------------------------- snip --------------------------------- > >The question being: >Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? No, advancing these now does NOT prevent NSEC-alt (or other changes) in the future. =46olks that use implementations of RFC's that are Proposed Standards should expect to have the specs change. I now have one signed zone operating with a currently available implementation and would like to field additional signed zones to have more operational experience. I also have some good sized customers that have a signed zone experiment underway and these users would very much like to see DNSSECbis get published as RFCs. > >There has not been enough clear statements, we are looking for >support, please help us out. Certainly will. I would very much like to see the DNSSECbis go forward now (sooner as opposed to later). Folks that I know who want to use this now want to do so even if they need to make some changes later. It's not easy to make some changes but others come more or less for 'free' with the normal upgrade of new software so even though some future changes may be needed, they would much rather have DNSSECbis go to RFCs sooner rather than later (even if change is needed later). > >We need to be able document that there is consensus that forwarding >DNSSEC-bis does not close the door on NSEC2, NSEC-alt or other methods >denial of existence that prevent zone enumeration. I don't know of any reason why publishing DNSSECbis would close that door nor have I seen any convincing description of one on the list. Additionally, changes to specs at the Proposed Standard level should be consider 'normal' per the established IETF standards process (per para 4.1.1, BCP-9/RFC-2026). Although the focus of much of the WG discussion lately has been on possible changes to NSEC, operational use of implementations of the current specs may well identify other changes that will need to be incorporated. This should be viewed as normal and a feature of the IETF process (BCP-9/RFC-2026) - we should use the 'feature' not fight it. We (the working group) should make well engineered, intelligent choices for the current specifications to allow for future change but potential requirement(s) for future change should _not_ keep the current specifications from moving forward. > >Please respond either on the mailing list or in a e-mail to both >chairs. > >Following are the changes the chairs are aware off and will >be done before documents are forward to IESG: > > 1. Caching issue brought up by David Blacka. > 2. Make it clearer that name space in NSEC records is circular. > 3. Minor text clarifications brought up. This is a Good Thing. > >Issues that are not resolved yet: > 1. Division of flag bits, as proposed by Simon Josefsson > 2. Need for special cases in NSEC records processing for > white lies/on-line signing. Publish what's ready now, work these requirement/issues in the WG and publish RFCs as needed to update (change) in the future what needs to be published now. After all, the specs are at the Proposed level where (according to BCP-9) change should be expected. If it turns out that changes are not needed, then we're that much closer to being able to advance things to the Draft level. > >Speak out if you think these items need or need not be resolved. If >you think these items need to be resolved than contribute with text >that can go into the document. If there is no obvious consensus on >support for these proposals, they will not be taken into account. I certainly agree that there is not a consensus on how to resolve the two issues identified above but I also think that we should forward the documents to the IESG as soon as the listed clarifications are completed. As long as we are committed to address these issues (and others that might arise) in a reasonable time-frame, individuals with concerns about identified issues should be able to expect the WG to address them and develop changes that might be required in some reasonable time period - the real key being 'reasonable time period'. > >We need to move forward. If not, we will not make the cut-off date, >run into the holiday season and it will be mid September before we >have had any progress. > > > =D3lafur and Olaf > DNSEXT Co-Chairs > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: <http://ops.ietf.org/lists/namedroppers/> Russ -- to unsubscribe send a message to namedroppers-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 Jun 18 04:38:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06474 for <dnsext-archive@lists.ietf.org>; Fri, 18 Jun 2004 04:38:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbEoY-000MGW-0M for namedroppers-data@psg.com; Fri, 18 Jun 2004 08:33:34 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbEoW-000MGI-Ti for namedroppers@ops.ietf.org; Fri, 18 Jun 2004 08:33:33 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 2F3214E32F; Fri, 18 Jun 2004 10:31:14 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CCF7B4E16E; Fri, 18 Jun 2004 10:31:13 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5I8VD8r014300; Fri, 18 Jun 2004 10:31:13 +0200 Date: Fri, 18 Jun 2004 10:31:13 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Roy Arends <roy@dnss.ec> Cc: namedroppers@ops.ietf.org Subject: Out of scope. rrsig(qtype) Message-Id: <20040618103113.11939d82.olaf@ripe.net> In-Reply-To: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> References: <Pine.BSO.4.56.0406170924590.18684@trinitario.schlyter.se> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 70da1f5b6ce691f4b47fba246d73fa5d X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 17 Jun 2004 09:28:32 +0200 (CEST) Roy Arends <roy@dnss.ec> wrote: > This is an alternative online signing proposal: Please move this to dnssec@cafax.se and report back to namedroppers when the idea has been cooked and the changes in the security model are ironed out. Please concentrate on DNSSEC-bis and the possible minor changes that are needed in the light of allowing _a_ viable transition. Even though this alternative is related to trans we should try not to widen the discussion by introducing new ideas that need in depth analysis. The question on the table is can DNSSEC-bis be shipped without closing the door &c &c &c -- Olaf DNSSEXT Co-Chair ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 18 06:25:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11248 for <dnsext-archive@lists.ietf.org>; Fri, 18 Jun 2004 06:25:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbGT5-0006ft-9Q for namedroppers-data@psg.com; Fri, 18 Jun 2004 10:19:31 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbGT4-0006fd-4U for namedroppers@ops.ietf.org; Fri, 18 Jun 2004 10:19:30 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8DB0A4E412; Fri, 18 Jun 2004 12:19:29 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 365044E162; Fri, 18 Jun 2004 12:19:29 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5IAJT8r025822; Fri, 18 Jun 2004 12:19:29 +0200 Date: Fri, 18 Jun 2004 12:19:29 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Roy Arends <roy@dnss.ec> Cc: scottr@nist.gov, namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? Message-Id: <20040618121929.29672ec4.olaf@ripe.net> In-Reply-To: <Pine.BSO.4.56.0406171546420.18684@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGMEGECLAA.scottr@nist.gov> <Pine.BSO.4.56.0406171546420.18684@trinitario.schlyter.se> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.002889 / 0.0 / 0.0 / disabled X-RIPE-Signature: 7da5d2f0f9292bc1c3c4dc4ee156e2ee X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It was never ment to make namespace circular, it was ment to deny data > after the last owner-name. This was the only way to signal that. I observe that you reach this conclusion without any reference to any of the documents while Ben just quoted two sentences from 4.1.1 that to me provides a description of a circular zone. I am also inclined to refer back to 2535 5.1 that explicitly states This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NXT in a zone. In order to unambiguously proof the non-existence of names the NSEC chain was designed the way it was. Creating holes in the NSEC chain changes the security model and is a change to the initial requirement for unambiguous denial of existence. I therefore think that 'circularity' either needs mention (by using the language from 2535 5.1) or we need the language as is. It is a purely editorial issue. Something that occurred to me when reading the thread an that relates more to Simon's reply... We have to face that the specs where written without considering that the zonesigner would provide "lies" about the structure of the zone. The spec describe the zonesigners behaviors (how the NSEC RR chain should be constructed) and it is implicitly assumed the zonesigner can be trusted. Changing the implicit assumption that the zonesigner does not lie about the zone structure is touching on the fundamental design of DNSSEC, we _will_ open up corner cases. Maybe we should make the implicit assumption more explicit. -- Olaf hat in hand. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Jun 18 07:04:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13288 for <dnsext-archive@lists.ietf.org>; Fri, 18 Jun 2004 07:04:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbH6a-000ALQ-GA for namedroppers-data@psg.com; Fri, 18 Jun 2004 11:00:20 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbH6Z-000AKV-Bs for namedroppers@ops.ietf.org; Fri, 18 Jun 2004 11:00:19 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 9BA81AC8A; Fri, 18 Jun 2004 12:38:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 9A517AC88; Fri, 18 Jun 2004 12:38:22 +0200 (CEST) Date: Fri, 18 Jun 2004 12:38:22 +0200 (CEST) From: Roy Arends <roy@dnss.ec> X-X-Sender: roy@trinitario.schlyter.se To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: scottr@nist.gov, namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? In-Reply-To: <20040618121929.29672ec4.olaf@ripe.net> Message-ID: <Pine.BSO.4.56.0406181225500.3393@trinitario.schlyter.se> References: <ANECIHCPCBDLLEJLCOPGMEGECLAA.scottr@nist.gov> <Pine.BSO.4.56.0406171546420.18684@trinitario.schlyter.se> <20040618121929.29672ec4.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 18 Jun 2004, Olaf M. Kolkman wrote: > > It was never ment to make namespace circular, it was ment to deny data > > after the last owner-name. This was the only way to signal that. > > I observe that you reach this conclusion without any reference to > any of the documents while Ben just quoted two sentences from 4.1.1 > that to me provides a description of a circular zone. I never said it wasn't circular... > I am also inclined to refer back to 2535 5.1 that explicitly states > > This is handled by treating the name space as circular and putting > the zone name in the RDATA of the last NXT in a zone. > > In order to unambiguously proof the non-existence of names the NSEC > chain was designed the way it was. And this is what rfc 2535 says preceding your quote: There is a potential problem with the last NXT in a zone as it wants to have an owner name which is the last existing name in canonical 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. Hence my conclusion: it was ment to deny data after the last owner-name. The property of circularity was not the primary design, it was a solution to an exception. > Creating holes in the NSEC chain changes the security model and is a > change to the initial requirement for unambiguous denial of existence. Absolutely. > I therefore think that 'circularity' either needs mention (by using > the language from 2535 5.1) or we need the language as is. It is a > purely editorial issue. Precisely, send text. 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 Jun 18 08:18:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16392 for <dnsext-archive@lists.ietf.org>; Fri, 18 Jun 2004 08:18:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BbIG4-000Gze-KQ for namedroppers-data@psg.com; Fri, 18 Jun 2004 12:14:12 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BbIG0-000GzI-DO for namedroppers@ops.ietf.org; Fri, 18 Jun 2004 12:14:08 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id B2D391FF845; Fri, 18 Jun 2004 11:48:47 +0000 (GMT) Message-ID: <40D2D69F.6000600@algroup.co.uk> Date: Fri, 18 Jun 2004 12:48:47 +0100 From: Ben Laurie <ben@algroup.co.uk> User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: Roy Arends <roy@dnss.ec>, scottr@nist.gov, namedroppers@ops.ietf.org Subject: Re: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future? References: <ANECIHCPCBDLLEJLCOPGMEGECLAA.scottr@nist.gov> <Pine.BSO.4.56.0406171546420.18684@trinitario.schlyter.se> <20040618121929.29672ec4.olaf@ripe.net> In-Reply-To: <20040618121929.29672ec4.olaf@ripe.net> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf M. Kolkman wrote: > Changing the implicit assumption that the zonesigner does not lie > about the zone structure is touching on the fundamental design of > DNSSEC, we _will_ open up corner cases. > > Maybe we should make the implicit assumption more explicit. You can fix that by making a small change to the first sentence of para 2 of section 4: "Because every authoritative name in a zone must be part of the NSEC chain, NSEC RRs must be present for names containing a CNAME RR." becomes: "Because every authoritative name in a zone MUST be part of the NSEC chain, NSEC RRs must be present for names containing a CNAME RR." This makes white lies non-compliant, though I believe that other language in the spec ensures that it is a non-compliance that will work (modulo resolvers getting clever). I suspect that in order to be ready for dnssec-ter, Nominet will want to use white lies despite their non-compliance, and it would be friendly to legitimise this use. Perhaps add this sentence, "However, a zone MAY instead include a single NSEC record containing the apex as both owner and Next Domain Name in order to work around zone-walking issues with NSEC". Also, in security considerations, you would then need: "If a zone uses the workaround for zone walking detailed in section 4, it is vulnerable to replay attacks denying the existence of any name in the zone". 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 nv33134@yahoo.com Sat Jun 19 02:51:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05877 for <dnsext-archive@ietf.org>; Sat, 19 Jun 2004 02:51:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbZhP-0005UB-R0 for dnsext-archive@ietf.org; Sat, 19 Jun 2004 02:51:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbZfO-0004ej-00 for dnsext-archive@ietf.org; Sat, 19 Jun 2004 02:49:31 -0400 Received: from [211.173.127.252] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1BbZcF-0003IZ-00; Sat, 19 Jun 2004 02:46:26 -0400 From: "Apelo a João Paulo II:" <nv33134@yahoo.com> To: disman@ietf.org Subject: Livrai o Brasil da ação maléfica da esquerda católica! . fer X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1BbZcF-0003IZ-00@ietf-mx> Date: Sat, 19 Jun 2004 02:46:26 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.1 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_YAHOO_RCVD,FROM_ENDS_IN_NUMS,HTML_40_50, HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING,MAILTO_SUBJ_REMOVE, MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,SUBJ_HAS_SPACES, SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.7 AWL AWL: Auto-whitelist adjustment <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <TITLE>c0406tfpjpbrres2

(ref.: cle) Está permitida a reprodução total ou parcial desta notícia; não é necessário citar a fonte: Atualidade Brasileira

A João Paulo II: "Livrai o Brasil da ação maléfica da esquerda católica!"

Filial apelo do Brasil pacífico e laborioso, angustiado pelo eclodir de conflitos que poderão levar o País a uma sangrenta guerra social

CIDADE DO VATICANO (AB) - É com preocupação que nosso povo, pacífico, laborioso e religioso, assiste ao eclodir de conflitos que poderão levá-lo a uma sangrenta guerra social. Muitos desses conflitos crescem pela agitação de sacerdotes e leigos da "esquerda católica", que apoiam soluções violentas para os problemas sociais e que contam com a omissão, quando não com o apoio ostensivo, de Prelados dos mais altos na Hierarquia eclesiástica brasileira.

É o que afirma, em extensa mensagem que acaba de chegar a S.S. João Paulo II, a Associação dos Fundadores da TFP - Tradição, Família e Propriedade (para receber gratuitamente, por e-mail, o texto completo, de 12 páginas, da carta a S.S. João Paulo II, clique no link: CartaJoaoPauloII:TextoCompletoGratuito).

Sob a égide da "esquerda católica", com a colaboração da Comissão Pastoral da Terra (CPT) e do Conselho Indigenista Missionário (CIMI) - órgãos da Conferencia Nacional dos Bispos Católicos (CNBB) - se articulam os tentáculos da ação subversiva, para encaminhar o País pelas sendas da miséria e da fome, acrescenta a carta. O próximo passo poderá ser uma guerrilha rural que leve ao Brasil a uma situação similar à da Colômbia. O quadro se vê agravado pela presença da "esquerda católica" no atual governo, cujos membros ocupam postos-chave a partir dos quais desenvolvem uma ação em prol da luta de classes.

A missiva faz referência a livros do Prof. Plinio Corrêa de Oliveira nos quais o autor denunciou a esquerda eclesiástica encastoada na CNBB, como sendo a força capaz de contaminar a opinião pública brasileira, pacata e conservadora, com as febricitações da demagogia revolucionária (Prof.Plinio:EnviarMaisInfo).

E conclui com um apelo: Santo Padre, não permitais que, em nome da Igreja, leigos, religiosos e até altos eclesiásticos conduzam nossa Pátria, que nasceu sob o signo da Cruz, para uma fratricida guerra social, tão avessa ao espírito cristão e à índole bondosa de nosso povo! Ouvi, Santo Padre, o apelo filial e angustiado que Vos dirigimos: "Salvai o Brasil da ação maléfica da esquerda católica!"

040611AB - Atualidade Brasileira

LINKS:

CartaJoaoPauloII:MinhaAdesão (ao clicar neste link, favor acrescentar nome completo, cidade e RG ou CIC; seu e-mail será impresso e enviado a Roma, junto com as demais adesões recebidas; pode incluir nomes e dados de familiares, amigos e colegas de trabalho, com o prévio consentimento destes)

CartaJoaoPauloII:Concordo ---- Discordo ---- EmTermos (em qualquer das três opções, escreva, de preferência, nome, cidade e RG ou CIC)

CartaJoaoPauloII:TextoCompletoGratuitoPorE-Mail

TELEFONES DE CONTATO:

Associação dos Fundadores da TFP - Tradição Família Propriedade

Tels.: (011) 3822-3241 (011) 3661-8545

Rua Avaré, 359 - 01243-030 - Bairro Pacaembu - São Paulo (SP)

POSTDATA 1:

Está no prelo o livreto "Pastoral da Terra e MST incendeiam o Brasil" (20 capítulos breves, 56 pp.). Para receber gratuitamente, por e-mail, o Índice e a Introdução, clique em:

Livro:DesejoReceberIntroGratuitamentePorE-Mail

Para adquirir a edição impressa, clique no seguinte link, incluindo nome, endereço postal e telefone de contato, e receberá as instruções de pagamento (valor do exemplar, correio incluído: R$ 10,00)

Livro:DesejoAdquirirPorCorreio

POSTDATA 2:

Para conhecer detalhes inéditos das atuais estratégias da "esquerda católica" no Brasil e em outros países, sugerimos a leitura de 5 e-Books a respeito do Fórum Social Mundial de Porto Alegre (2001-2002-2003), do Fórum Social Brasileiro de Belo Horizonte (2003) e do Fórum Social Mundial de Bombay (2004). Receba via e-mail, links para fazer download gratuito dos 5 e-Books, clicando em:

ForumSocial:e-BooksGratuitos

LINK DE REMOÇÃO:

Retirar Caso já tiver efetuado anteriormente, sem sucesso, o pedido de remoção, lhe solicitamos o enorme favor de copiar e nos enviar na íntegra o denominado "Código Fonte da Mensagem", para nossos técnicos poderem verificar a qual e-mail, exatamente, lhe escrevemos, e assim tirá-lo imediatamente do Address Book. Clique acima da mensagem com o botão direito do "mouse", depois em "Propriedades", "Detalhes" e "Código Fonte". Solicitamos desculpas pelos inconvenientes ocasionados.

A difusão desta mensagem e seu conteúdo são de exclusiva responsabilidade da agência Atualidade Brasileira.

 From owner-namedroppers@ops.ietf.org Mon Jun 21 15:43:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21176 for ; Mon, 21 Jun 2004 15:43:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcUaT-000LTk-Af for namedroppers-data@psg.com; Mon, 21 Jun 2004 19:36:13 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcUaS-000LTV-6U for namedroppers@ops.ietf.org; Mon, 21 Jun 2004 19:36:12 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 21 Jun 2004 15:35:24 -0400 id 0014017F.40D7387C.00006481 From: David Blacka Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: concerns with TCR as a transition mechanism Date: Mon, 21 Jun 2004 15:36:09 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200406211536.09144.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It occurs to me that a mechanism for transitioning from DNSSECbis to DNSSECter MUST prevent existing DNSSECbis resolvers from "choking" on newly deployed DNSSECter zones, but it also SHOULD allow DNSSECter zones to secure delegate to DNSSECbis zone, and SHOULD allow DNSSECbis zones to secure delegate DNSSECter zones. It also occurs to me that a full type code rollover would probably not be able to do the last part: allow secure delegations from DNSSECbis zones to DNSSECter zones. If this is true, then for a zone to upgrade to DNSSECter, it would have to wait until its parent upgrades, or start its own island of security. This seems to me that it might have the effect of chilling adoption of DNSSECbis, or chilling the adoption of DNSSECter, depending upon where you stood. I also note that, although we've done a TCR before (i.e., RFC 3755), the circumstances were different in that we essentially had no installed base of DNSSEC-semel (rfc 2535) to coexist with. That is, all the TCR had to do was shield legacy resolvers, which it does. Paul's partial TCR proposal (which I could be mis-remembering) uses EDNS0 signalling to (presumably) allow all of the MUST and SHOULD behaviors outlined above. But, I also remember that when we were coming up with the DNSSECbis TCR, EDNS0 signalling was suggested and rejected. If we were uncomfortable with it then, why wouldn't we be uncomfortable with it now? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 21 17:07:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29572 for ; Mon, 21 Jun 2004 17:07:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcVve-0005vB-Ff for namedroppers-data@psg.com; Mon, 21 Jun 2004 21:02:10 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcVvc-0005uq-Q8 for namedroppers@ops.ietf.org; Mon, 21 Jun 2004 21:02:09 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id DD8C019B34C; Mon, 21 Jun 2004 16:58:59 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 4970F19B3A4; Mon, 21 Jun 2004 16:58:59 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1798042; Mon, 21 Jun 2004 17:02:07 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200406211536.09144.davidb@verisignlabs.com> References: <200406211536.09144.davidb@verisignlabs.com> Date: Mon, 21 Jun 2004 17:02:04 -0400 To: David Blacka From: Edward Lewis Subject: Re: concerns with TCR as a transition mechanism Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [off-list] 'cuz I don't have answer to your question... I really agree with your points, and I'm glad you are asking the question. It kinda goes along with the thought I threw out that maybe we ought not encourage the dissemination of a trusted key until whatever hits Draft Standard. Maybe not explicitly, but I meant what I think you mean here. If you get my drift... At 15:36 -0400 6/21/04, David Blacka wrote: >It occurs to me that a mechanism for transitioning from DNSSECbis to DNSSECter >MUST prevent existing DNSSECbis resolvers from "choking" on newly deployed >DNSSECter zones, but it also SHOULD allow DNSSECter zones to secure delegate >to DNSSECbis zone, and SHOULD allow DNSSECbis zones to secure delegate >DNSSECter zones. > >It also occurs to me that a full type code rollover would probably not be able >to do the last part: allow secure delegations from DNSSECbis zones to >DNSSECter zones. > >If this is true, then for a zone to upgrade to DNSSECter, it would have to >wait until its parent upgrades, or start its own island of security. This >seems to me that it might have the effect of chilling adoption of DNSSECbis, >or chilling the adoption of DNSSECter, depending upon where you stood. > >I also note that, although we've done a TCR before (i.e., RFC 3755), the >circumstances were different in that we essentially had no installed base of >DNSSEC-semel (rfc 2535) to coexist with. That is, all the TCR had to do was >shield legacy resolvers, which it does. > >Paul's partial TCR proposal (which I could be mis-remembering) uses EDNS0 >signalling to (presumably) allow all of the MUST and SHOULD behaviors >outlined above. But, I also remember that when we were coming up with the >DNSSECbis TCR, EDNS0 signalling was suggested and rejected. If we were >uncomfortable with it then, why wouldn't we be uncomfortable with it now? > >-- >David Blacka >Sr. Engineer VeriSign Applied Research > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 21 20:24:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19546 for ; Mon, 21 Jun 2004 20:24:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcZ0v-0003UB-KA for namedroppers-data@psg.com; Tue, 22 Jun 2004 00:19:49 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcZ0t-0003Tc-GE for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 00:19:48 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E332719B35B; Mon, 21 Jun 2004 20:16:34 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 2CA7219B402; Mon, 21 Jun 2004 20:16:34 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1798524; Mon, 21 Jun 2004 20:19:43 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <200406211536.09144.davidb@verisignlabs.com> Date: Mon, 21 Jun 2004 20:19:30 -0400 To: Edward Lewis From: Edward Lewis Subject: Re: concerns with TCR as a transition mechanism Cc: David Blacka , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry for missposting. I was trying to be off-list because I really didn't have time to say more intelligent than "me too." But since I did...I too am concerned about TCR not providing backwards compatibility. But I don't think that it's a problem unique to TCR. Any transition method that tries to provide backwards compatibility will imply code size creep - DNSSECtis code bases would need to have DNSSECbis abilities (whether or not used) if we don't want to "hang" DNSSECbis adoption efforts. Hence my "drift" about being tempted to not issue trusted keys until Draft Standard. I don't want to encourage that, but, what's the choice between more code, a flag day, delay? That's something I just don't have time to give thought to now. At 17:02 -0400 6/21/04, Edward Lewis wrote: >[off-list] 'cuz I don't have answer to your question... > >I really agree with your points, and I'm glad you are asking the >question. It kinda goes along with the thought I threw out that >maybe we ought not encourage the dissemination of a trusted key >until whatever hits Draft Standard. Maybe not explicitly, but I >meant what I think you mean here. > >If you get my drift... > >At 15:36 -0400 6/21/04, David Blacka wrote: >>It occurs to me that a mechanism for transitioning from DNSSECbis >>to DNSSECter >>MUST prevent existing DNSSECbis resolvers from "choking" on newly deployed >>DNSSECter zones, but it also SHOULD allow DNSSECter zones to secure delegate >>to DNSSECbis zone, and SHOULD allow DNSSECbis zones to secure delegate >>DNSSECter zones. >> >>It also occurs to me that a full type code rollover would probably >>not be able >>to do the last part: allow secure delegations from DNSSECbis zones to >>DNSSECter zones. >> >>If this is true, then for a zone to upgrade to DNSSECter, it would have to >>wait until its parent upgrades, or start its own island of security. This >>seems to me that it might have the effect of chilling adoption of DNSSECbis, >>or chilling the adoption of DNSSECter, depending upon where you stood. >> >>I also note that, although we've done a TCR before (i.e., RFC 3755), the >>circumstances were different in that we essentially had no installed base of >>DNSSEC-semel (rfc 2535) to coexist with. That is, all the TCR had to do was >>shield legacy resolvers, which it does. >> >>Paul's partial TCR proposal (which I could be mis-remembering) uses EDNS0 >>signalling to (presumably) allow all of the MUST and SHOULD behaviors >>outlined above. But, I also remember that when we were coming up with the >>DNSSECbis TCR, EDNS0 signalling was suggested and rejected. If we were >>uncomfortable with it then, why wouldn't we be uncomfortable with it now? >> >>-- >>David Blacka >>Sr. Engineer VeriSign Applied Research >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-703-227-9854 >ARIN Research Engineer > >"I can't go to Miami. I'm expecting calls from telemarketers." - >Grandpa Simpson. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 21 21:10:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22736 for ; Mon, 21 Jun 2004 21:10:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcZlD-0009OO-3k for namedroppers-data@psg.com; Tue, 22 Jun 2004 01:07:39 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcZl9-0009Nk-TG for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 01:07:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 281E913DF7 for ; Tue, 22 Jun 2004 01:07:35 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: concerns with TCR as a transition mechanism In-Reply-To: Message from David Blacka of "Mon, 21 Jun 2004 15:36:09 -0400." <200406211536.09144.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 22 Jun 2004 01:07:35 +0000 Message-Id: <20040622010735.281E913DF7@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > It occurs to me that a mechanism for transitioning from DNSSECbis to > DNSSECter MUST prevent existing DNSSECbis resolvers from "choking" on > newly deployed DNSSECter zones, but it also SHOULD allow DNSSECter > zones to secure delegate to DNSSECbis zone, and SHOULD allow DNSSECbis > zones to secure delegate DNSSECter zones. that last part's the killer. by "-ter zone" and "-bis zone" i'll assume that you mean "zones for which only one kind of dnssec metadata is available." this is an important point because some here have said that we might do a partial TCR, such as only RRSIG and NSEC, and leave DS and DNSKEY as they are but use a different protocol number. i don't think that approach has merit, but the existence of that debate means we have to say very precisely what we mean by "-bis zone" and "-ter" zone. so, by my interpretation of what you meant, you're asking that it become possible for a zone to use -bis even though its parent uses -ter -- and that's ok by my draft's current language, which is: 2.5. A zone signer and/or authority server might choose to support both DNSSEC-BIS and DNSSEC-TER, or only DNSSEC-BIS, or only DNSSEC-TER. It is expected that a validating recursive server, or a caching recursive server, will support either DNSSEC-BIS alone (as is the case today), or both DNSSEC-BIS and DNSSEC-TER, but never DNSSEC-TER alone. the problem creeps in on that third requirement (quoted earlier above) -- because a zone served by only -bis software will not recognize signalling bits for -ter, and probably will not even be able to load zones that contain -ter metadata (for example, DS2). so, my basic assumption has been that the "-ter transition" would flow from the trust anchor(s) "downward". (ed, your concerns about codesize creep should have come in immediate response to -ter draft, since section 2.5 quoted above makes it clear that now that i've got more RAM in my digital camera than was present in the whole state of california at the time i used my first timeshared computer, i don't consider codesize creep to be an important issue.) > It also occurs to me that a full type code rollover would probably not > be able to do the last part: allow secure delegations from DNSSECbis > zones to DNSSECter zones. right. just so. > If this is true, then for a zone to upgrade to DNSSECter, it would > have to wait until its parent upgrades, or start its own island of > security. This seems to me that it might have the effect of chilling > adoption of DNSSECbis, or chilling the adoption of DNSSECter, > depending upon where you stood. since i've been expecting -ter to be a different protocol than -bis, with its own metadata and its own signalling model and perhaps a different threat model, i don't see it as chilling at all. people who need -bis's features will deploy it. based upon their success or failure, and upon the quality of -ter when it's proposed, people who need -ter features will deploy it. delegation-only or delegation-mostly (collectively "non-leaf") zone operators will presumably be as actively necessary to -ter's deployment as to -bis's, and they will deploy -ter on the same basis -- if their subdomain-holding "customers" ask for it. > I also note that, although we've done a TCR before (i.e., RFC 3755), > the circumstances were different in that we essentially had no > installed base of DNSSEC-semel (rfc 2535) to coexist with. That is, > all the TCR had to do was shield legacy resolvers, which it does. there was a moderate installed based of 2535 resolvers. there was no trust anchor at the root zone, and that's why the previous TCR was light-weight. for -ter, we will have to shield new resolvers from old metadata, because otherwise even EDNS wouldn't be large enough to hold the response-o-grams (since they might end up containing both -bis AND -ter metadata). > Paul's partial TCR proposal (which I could be mis-remembering) uses > EDNS0 signalling to (presumably) allow all of the MUST and SHOULD > behaviors outlined above. But, I also remember that when we were > coming up with the DNSSECbis TCR, EDNS0 signalling was suggested and > rejected. If we were uncomfortable with it then, why wouldn't we be > uncomfortable with it now? again, there was no trust anchor, and the installed base of 2535-style authority servers was negligible. there was no need to shield new resolvers from the old metadata, as there presumably will be when -ter deploys (since we're hoping that there's a moderate or large -bis installed based by then.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 21 22:13:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25470 for ; Mon, 21 Jun 2004 22:13:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcaj5-000GoH-Qp for namedroppers-data@psg.com; Tue, 22 Jun 2004 02:09:31 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcaj4-000Gnt-OK for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 02:09:31 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B792119B489; Mon, 21 Jun 2004 22:06:17 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 36A1119B405; Mon, 21 Jun 2004 22:06:17 -0400 (EDT) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.83]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1798742; Mon, 21 Jun 2004 22:09:28 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20040622010735.281E913DF7@sa.vix.com> References: <20040622010735.281E913DF7@sa.vix.com> Date: Mon, 21 Jun 2004 22:09:22 -0400 To: Paul Vixie From: Edward Lewis Subject: Re: concerns with TCR as a transition mechanism Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Now that I feel compelled to be involved because I can't keep my private mailings private, I'm missing my sitcoms. At 1:07 +0000 6/22/04, Paul Vixie wrote: ...stuff in reply to David... I suppose that with tools we can make serving both (all) dialects possible - I don't want to have to manage a second set of keys for the new dialect. (Will reusing key material be a crypto-problem?) Assuming that -ter operators want that because the NSEC is a problem, that means that we need to solve the faux-NSEC problem so that a -ter-only zone can say there's no DS for -bis verifiers at unsecured delegation points. I suppose that at this point, the question is whether or not the -bis docs prevent any "-ter." It seems they don't, so long as the faux-NSEC thing is hammered out. Whether a specific "-ter" (ever) emerges, then it'll undergo scrutiny. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I can't go to Miami. I'm expecting calls from telemarketers." - Grandpa Simpson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 21 22:44:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26985 for ; Mon, 21 Jun 2004 22:44:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcbCN-000K1S-26 for namedroppers-data@psg.com; Tue, 22 Jun 2004 02:39:47 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcbCK-000K18-MX for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 02:39:44 +0000 Received: from fury.blacka.com ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 21 Jun 2004 22:38:53 -0400 id 0014D6FB.40D79BBD.00004248 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: concerns with TCR as a transition mechanism Date: Mon, 21 Jun 2004 22:39:42 -0400 User-Agent: KMail/1.6.1 References: <20040622010735.281E913DF7@sa.vix.com> In-Reply-To: <20040622010735.281E913DF7@sa.vix.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200406212239.42577.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 21 June 2004 9:07 pm, Paul Vixie wrote: > > It occurs to me that a mechanism for transitioning from DNSSECbis to > > DNSSECter MUST prevent existing DNSSECbis resolvers from "choking" on > > newly deployed DNSSECter zones, but it also SHOULD allow DNSSECter > > zones to secure delegate to DNSSECbis zone, and SHOULD allow DNSSECbis > > zones to secure delegate DNSSECter zones. > > that last part's the killer. by "-ter zone" and "-bis zone" i'll assume > that you mean "zones for which only one kind of dnssec metadata is > available." I do not see an advantage for a zone to publish with both sets of metadata. In fact, if -ter is attempting to solve the problem we think, there would be a great disadvantage to publishing both. > this is an important point because some here have said that > we might do a partial TCR, such as only RRSIG and NSEC, and leave DS and > DNSKEY as they are but use a different protocol number. i don't think > that approach has merit, You haven't explained *why* that approach does not have merit. This topic is in scope. > but the existence of that debate means we have > to say very precisely what we mean by "-bis zone" and "-ter" zone. so, > by my interpretation of what you meant, you're asking that it become > possible for a zone to use -bis even though its parent uses -ter -- and > that's ok by my draft's current language, which is: Full TCR (with no other signalling) can do this, I think. I'm not worried about this, I'm worried about the reverse. > the problem creeps in on that third requirement (quoted earlier above) -- > because a zone served by only -bis software will not recognize signalling > bits for -ter, and probably will not even be able to load zones that > contain -ter metadata (for example, DS2). so, my basic assumption has been > that the "-ter transition" would flow from the trust anchor(s) "downward". Not the most flexible assumption, IMHO. > > It also occurs to me that a full type code rollover would probably not > > be able to do the last part: allow secure delegations from DNSSECbis > > zones to DNSSECter zones. > > right. just so. > > > If this is true, then for a zone to upgrade to DNSSECter, it would > > have to wait until its parent upgrades, or start its own island of > > security. This seems to me that it might have the effect of chilling > > adoption of DNSSECbis, or chilling the adoption of DNSSECter, > > depending upon where you stood. > > since i've been expecting -ter to be a different protocol than -bis, with > its own metadata and its own signalling model and perhaps a different > threat model, i don't see it as chilling at all. people who need -bis's > features will deploy it. based upon their success or failure, and upon the > quality of -ter when it's proposed, people who need -ter features will > deploy it. delegation-only or delegation-mostly (collectively "non-leaf") > zone operators will presumably be as actively necessary to -ter's > deployment as to -bis's, and they will deploy -ter on the same basis -- if > their subdomain-holding "customers" ask for it. You may have missed my point. How does the "non-leaf" zone operator deploy -ter when, say, the root hasn't? Or when their ccTLD hasn't? Would you force them to start their own island of security, or would you commit to getting the root signed with -ter as soon as possible? Wouldn't transition just be *easier* if a zone signed using -bis could securely delegate to a zone signed with -ter? > > I also note that, although we've done a TCR before (i.e., RFC 3755), > > the circumstances were different in that we essentially had no > > installed base of DNSSEC-semel (rfc 2535) to coexist with. That is, > > all the TCR had to do was shield legacy resolvers, which it does. > > there was a moderate installed based of 2535 resolvers. there was no trust > anchor at the root zone, and that's why the previous TCR was light-weight. > for -ter, we will have to shield new resolvers from old metadata, because > otherwise even EDNS wouldn't be large enough to hold the response-o-grams > (since they might end up containing both -bis AND -ter metadata). Yeah, I don't see this happening. It is clear that you and I have different mental models for what the world of DNSSEC-ter looks like. Perhaps I will post what my model is, and you can tell me why I'm wrong. > > Paul's partial TCR proposal (which I could be mis-remembering) uses > > EDNS0 signalling to (presumably) allow all of the MUST and SHOULD > > behaviors outlined above. But, I also remember that when we were > > coming up with the DNSSECbis TCR, EDNS0 signalling was suggested and > > rejected. If we were uncomfortable with it then, why wouldn't we be > > uncomfortable with it now? > > again, there was no trust anchor, and the installed base of 2535-style > authority servers was negligible. there was no need to shield new > resolvers from the old metadata, as there presumably will be when -ter > deploys (since we're hoping that there's a moderate or large -bis installed > based by then.) Well, I'll ask the question in a more straightforward manner. Are we comfortable using EDNS0 signalling? My memory of discussions leading up to 3755 was that we were not, but why not always seemed sort of hazy. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 00:08:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00975 for ; Tue, 22 Jun 2004 00:08:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BccWb-0003J7-KH for namedroppers-data@psg.com; Tue, 22 Jun 2004 04:04:45 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BccWa-0003Ip-Ks for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 04:04:44 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6429F42B2 for ; Tue, 22 Jun 2004 00:04:43 -0400 (EDT) Date: Tue, 22 Jun 2004 00:04:43 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: concerns with TCR as a transition mechanism In-Reply-To: <200406212239.42577.davidb@verisignlabs.com> References: <20040622010735.281E913DF7@sa.vix.com> <200406212239.42577.davidb@verisignlabs.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040622040443.6429F42B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 21 Jun 2004 22:39:42 -0400, David Blacka wrote: > ... > Well, I'll ask the question in a more straightforward manner. Are we > comfortable using EDNS0 signalling? I'm less confident in it than I am in TCR (see below). > My memory of discussions leading up to 3755 was that we were not, but why not > always seemed sort of hazy. Header bit signalling is basicly a hop-by-hop thing, whereas type code signalling is more of an end to end thing. As I recall, we concluded that the original requestor's intent was more likely to survive passage through a twisty little maze of forwarders, caches, and so forth via type code signalling than via header bit signalling. YMMV. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 04:53:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18717 for ; Tue, 22 Jun 2004 04:53:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcgte-0009B8-0G for namedroppers-data@psg.com; Tue, 22 Jun 2004 08:44:50 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcgta-0009An-RH for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 08:44:46 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Tue, 22 Jun 2004 04:44:36 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004062204443620166 ; Tue, 22 Jun 2004 04:44:36 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 22 Jun 2004 04:44:36 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE105118@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Edward Lewis'" Cc: namedroppers@ops.ietf.org Subject: RE: concerns with TCR as a transition mechanism Date: Tue, 22 Jun 2004 04:42:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Ed-- Trying to reply only to one part of a much more significant message: > I suppose that with tools we can make serving both (all) dialects > possible - I don't want to have to manage a second set of keys for > the new dialect. (Will reusing key material be a crypto-problem?) Re-using key material will not inherently be a "crypto-problem"-- given that the plaintext to be signed will be slightly different, the problem is that the crypto "lifetime" of the key will decrease at something approximating half the "lifetime" (effectivity period) that would otherwise be expected [0]--all of a sudden one is signing (basically) twice as much data so by certain attacks the key would be expected to be attackable in ~half the time. However, that would be expected to be a surmountable problem. I agree with you that if -bis and -ter are both actively used in the field simultaneously (which I would expect) then for a maximally compliant system I would prefer to use the same keying material for signed DNS in both systems. I think it's a realistic goal, although I invite comments in case I missed the bus on something... --Rip [0] Based on all I know of currently published cryptanalysis attacks on the algorithms in question. If someone's got more data, please provide it. Yes, there may be some interesting differential cryptanalysis attacks possible based on the fact that the two sets of plaintext will be _real_real_ similar with only very slight differences--but for now I'm throwing those out because I don't think they will be significantly more productive than the "joe average" attacks against a known plaintext for these algorithms. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 05:02:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19231 for ; Tue, 22 Jun 2004 05:02:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bch4j-000Aci-Ba for namedroppers-data@psg.com; Tue, 22 Jun 2004 08:56:17 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bch4h-000AcF-9p for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 08:56:15 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Bch4g-0000Ah-00 for ; Tue, 22 Jun 2004 10:56:14 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2004 10:56:14 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2004 10:56:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: dnssec-records ISSUE: don't make NSEC a protocol requirement Date: Tue, 22 Jun 2004 10:56:09 +0200 Lines: 50 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:i022TonTQZd2CJLeRLA7mPLnZTA= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (I'm trying to get some issues entered into the issue tracker, since they might be lost in the flood of messages on the list otherwise..) Transition to DNSSEC-ter difficulty caused by DNSSEC-bis requirement for NSEC. name: Simon Josefsson email: jas@extundo.com Date: June 22 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01161.html Type: T Priority: W Document: draft-ietf-dnsext-dnssec-records-08 Section: 2.3 Rationale/Explanation of issue: Recent posts make it clear that people believe DNSSEC-ter and DNSSEC-bis is intended to co-exist. If DNSSEC-ter is supposed to solve the zone walking issue, I don't think this will be possible given current text in DNSSEC-bis. It says: Each owner name in the zone which has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. The process for constructing the NSEC RR for a given name is described in [I-D.ietf-dnsext-dnssec-records]. So any zone not including NSEC's for all owner names violate the protocol, and a DNSSEC-bis resolver somehow detecting this situation is allowed to regard the zone as bogus. Requested change: The simple part is to change MUST into SHOULD above, and add the following security consideration: When NSEC's are not provided for all owner names in a zone, perhaps to prevent zone walking, resolvers will not be able to verify negative proofs. Further, if a all-inclusive NSEC is added, it may be used in a replay attack to prove non-existence of existing names. The document must also require behaviour on resolvers that encounter absent NSEC's, and this is where it get complicated. I proposed something like: If a resolver do not receive expected NSEC's to a query, it MUST NOT assume the zone is bogus, but instead assume negative proofs are absent. But there may be other changes needed as well. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 05:12:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19790 for ; Tue, 22 Jun 2004 05:12:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BchIN-000CsE-3l for namedroppers-data@psg.com; Tue, 22 Jun 2004 09:10:23 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BchIM-000Cs0-1m for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 09:10:22 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BchIL-0000Sp-00 for ; Tue, 22 Jun 2004 11:10:21 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2004 11:10:21 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2004 11:10:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Date: Tue, 22 Jun 2004 11:10:15 +0200 Lines: 35 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:zn4XeY6UkIfZeJt93RBct12M5OU= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSKEY's are forbidden at delegation points, for unclear reasons. name: Simon Josefsson email: jas@extundo.com Date: 22 June 2004 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01150.html Type: T Priority: W Document: draft-ietf-dnsext-dnssec-protocol-06 Section: 2.1 Rationale/Explanation of issue: DNSKEY's are disallowed at delegation points in DNSSEC-bis: DNSKEY RRs MUST NOT appear at delegation points. I propose to remove this requirement, as I haven't seen a technical motivation for it. If there indeed is a technical motivation, I think it should be stated in connection with the requirement. See the URL above for more discussion. This issue was resolved, I believe, the way I proposed, when this was discussed for the KEY record. It appears as if the decision was reverted in DNSSEC-bis. See: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01158.html Requested change: Drop sentence from section 2.1: DNSKEY RRs MUST NOT appear at delegation points. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 05:31:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21893 for ; Tue, 22 Jun 2004 05:31:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BchZN-000Eyw-1Z for namedroppers-data@psg.com; Tue, 22 Jun 2004 09:27:57 +0000 Received: from [193.0.2.52] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BchZM-000Eyc-5Q for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 09:27:56 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 7CA0D340026; Tue, 22 Jun 2004 11:28:13 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B566FC0-C42E-11D8-BC8F-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Re: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Date: Tue, 22 Jun 2004 11:28:12 +0200 To: Simon Josefsson X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Issue is created in the issue tracker. As issue 6 see https://roundup.machshav.com/dnsext/ Please reply in thread. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 05:31:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21916 for ; Tue, 22 Jun 2004 05:31:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcha1-000F4l-Pr for namedroppers-data@psg.com; Tue, 22 Jun 2004 09:28:37 +0000 Received: from [193.0.2.52] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcha0-000F47-Sf for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 09:28:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 279EC34003D; Tue, 22 Jun 2004 11:28:54 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93E659CA-C42E-11D8-BC8F-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement Date: Tue, 22 Jun 2004 11:28:53 +0200 To: Simon Josefsson X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Issue is created in the issue tracker. As issue 5 see https://roundup.machshav.com/dnsext/ Please reply in thread. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 06:00:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23910 for ; Tue, 22 Jun 2004 06:00:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bci1d-000IUy-Hl for namedroppers-data@psg.com; Tue, 22 Jun 2004 09:57:09 +0000 Received: from [193.0.2.52] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bci1c-000IUi-FD for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 09:57:08 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id C29C13400D2; Tue, 22 Jun 2004 11:57:22 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8DB01EFE-C432-11D8-BC8F-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement Date: Tue, 22 Jun 2004 11:57:21 +0200 To: Simon Josefsson X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > If a resolver do not receive expected NSEC's to a query, it MUST > NOT assume the zone is bogus, but instead assume negative proofs > are absent. > With reference to http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01188.html The specifications are written in such a way that signer and server behavior lead to an unambiguous state when verifying. One of the implicit assumptions in the specs is that the signer will not lie about the zone content. This proposal tries to allow for the signer to lie. You must be able to unambiguously determine the security state even when RRsets are stripped from your packets. The language you are proposing does not, IMHO, allow for that. Since this proposal fundamentally alters the security model I am opposed to this change. However, 'bogus' comes in many shapes and forms, you may be in 'bogus' state because the crypto failed, because your signature expired, because you did not get expected data. Intro section 5 contains language that allows to 'deal' with the many states of 'bogus' later (!). --Olaf No Hats -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 06:19:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25556 for ; Tue, 22 Jun 2004 06:19:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BciKB-000KrO-UG for namedroppers-data@psg.com; Tue, 22 Jun 2004 10:16:19 +0000 Received: from [80.91.224.249] (helo=main.gmane.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BciK8-000Kqc-0d for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 10:16:16 +0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BciK7-00027X-00 for ; Tue, 22 Jun 2004 12:16:15 +0200 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2004 12:16:15 +0200 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2004 12:16:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Simon Josefsson Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement Date: Tue, 22 Jun 2004 12:16:11 +0200 Lines: 35 Message-ID: References: <8DB01EFE-C432-11D8-BC8F-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:t6/6CACeOtk5mkvClJH25Fay8yo= X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf Kolkman writes: >> >> If a resolver do not receive expected NSEC's to a query, it MUST >> NOT assume the zone is bogus, but instead assume negative proofs >> are absent. >> > > > With reference to > http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01188.html > > The specifications are written in such a way that signer and server > behavior lead to an unambiguous state when verifying. One of the > implicit assumptions in the specs is that the signer will not lie > about the zone content. This proposal tries to allow for the signer to > lie. > > You must be able to unambiguously determine the security state even > when RRsets are stripped from your packets. The language you are > proposing does not, IMHO, allow for that. > > Since this proposal fundamentally alters the security model I am > opposed to this change. How can DNSSEC-ter coexist or be backwards compatible with DNSSEC-bis, if DNSSEC-bis require NSEC's to exist for all names? Should the conclusion be that DNSSEC-ter, if it is supposed to solve the zone walking issue, cannot coexist with DNSSEC-bis? I agree the text you quoted would be insufficient, but it was a starting point for more thorough proposals. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 07:24:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01152 for ; Tue, 22 Jun 2004 07:24:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcjIL-0001vz-3v for namedroppers-data@psg.com; Tue, 22 Jun 2004 11:18:29 +0000 Received: from [193.0.2.52] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcjIJ-0001vf-Qp for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 11:18:28 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 14A6734020F; Tue, 22 Jun 2004 13:18:45 +0200 (CEST) In-Reply-To: References: <8DB01EFE-C432-11D8-BC8F-000393DA2D46@ripe.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement Date: Tue, 22 Jun 2004 13:18:44 +0200 To: Simon Josefsson X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Hi Simon, > How can DNSSEC-ter coexist or be backwards compatible with DNSSEC-bis, > if DNSSEC-bis require NSEC's to exist for all names? Should the > conclusion be that DNSSEC-ter, if it is supposed to solve the zone > walking issue, cannot coexist with DNSSEC-bis? > It can, but only if you indicate in some secure way that the verifier should not expect NSECs, and that is the whole point of the transition mechanism. How to securely signal that NSECs are not to be expected but that they are either not present or that their semantics have changed. IMHO this can be done with an algorithm roll and with TCR, maybe by other ways. Both do not need textual changes. > I agree the text you quoted would be insufficient, but it was a > starting point for more thorough proposals. I highly appreciate the effort, but I think that this particular proposal touches upon the core design and are therefore not small modifications but a big design change. Can we not just agree not to go down this particular road? --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 10:21:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11751 for ; Tue, 22 Jun 2004 10:21:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcm2Y-000P7K-CM for namedroppers-data@psg.com; Tue, 22 Jun 2004 14:14:22 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcm2X-000P5d-4F for namedroppers@ops.ietf.org; Tue, 22 Jun 2004 14:14:21 +0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i5MEEKE1028496; Tue, 22 Jun 2004 10:14:20 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i5MEEJoM017142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Jun 2004 10:14:20 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i5MEEI8M013782; Tue, 22 Jun 2004 10:14:18 -0400 Subject: RE: concerns with TCR as a transition mechanism From: Greg Hudson To: "Loomis, Rip" Cc: namedroppers@ops.ietf.org In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE105118@US-Columbia-CIST.mail.saic.com> References: <4E25ECBBC03F874CBAD03399254ADFDE105118@US-Columbia-CIST.mail.saic.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1087913658.12585.150.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 22 Jun 2004 10:14:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2004-06-22 at 04:42, Loomis, Rip wrote: > Re-using key material will not inherently be a "crypto-problem"-- > given that the plaintext to be signed will be slightly different, > the problem is that the crypto "lifetime" of the key will decrease > at something approximating half the "lifetime" (effectivity period) > that would otherwise be expected [0]--all of a sudden one is signing > (basically) twice as much data so by certain attacks the key would > be expected to be attackable in ~half the time. The idea that one would want to rotate keys twice as often because I'm signing twice as much data is pretty misguided, I think. It only matters if the signing algorithm you're using is broken in a particular way, such that the key is more likely to be discovered through a known-plaintext attack than through the usual forms of leakage--compromised hosts, compromised people, or sloppy key management. To borrow from Shneier, by deploying DNSSEC, you've built up some earthworks (key management) and then driven a single giant stake into the ground (the cryptosystem) somewhere in the middle. The security of your system does not depend on the height of the giant stake. Note that a signing algorithm is particularly interested in defending against known-plaintext attacks, since the attacker generally has no shortage of plaintexts to work with. A cipher which is subject to a known-plaintext attack is at somewhat less risk, since the attacker may or may not have access to any plaintexts, but a cipher is still considered broken if there is a known-plaintext attack against it with a practical number of plaintexts. The situation gets fuzzier when you get into chosen-plaintext and chosen-ciphertext attacks, which is why NO records start to get a little bit worrisome. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 20:26:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17154 for ; Tue, 22 Jun 2004 20:26:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcvYe-000NLy-Ck for namedroppers-data@psg.com; Wed, 23 Jun 2004 00:24:08 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcvYd-000NLf-JW for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 00:24:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 503C013E1A for ; Wed, 23 Jun 2004 00:24:07 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: concerns with TCR as a transition mechanism In-Reply-To: Message from Rob Austein of "Tue, 22 Jun 2004 00:04:43 -0400." <20040622040443.6429F42B2@thrintun.hactrn.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Jun 2004 00:24:07 +0000 Message-Id: <20040623002407.503C013E1A@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > My memory of discussions leading up to 3755 was that we were not, > > but why not always seemed sort of hazy. > > Header bit signalling is basicly a hop-by-hop thing, whereas type code > signalling is more of an end to end thing. As I recall, we concluded > that the original requestor's intent was more likely to survive > passage through a twisty little maze of forwarders, caches, and so > forth via type code signalling than via header bit signalling. YMMV. that's a different issue. for -bis, we decided not to roll the request bit and just roll the response rrtypes. for -ter, i'm expecting that we will have to roll both. in section 2.3, i propose a specific method by which hop-by-hop request signalling is "promoted" to end-to-end. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 20:26:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17232 for ; Tue, 22 Jun 2004 20:26:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcvVq-000N4Z-SQ for namedroppers-data@psg.com; Wed, 23 Jun 2004 00:21:14 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcvVn-000N45-Pi for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 00:21:13 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B27BC13E01 for ; Wed, 23 Jun 2004 00:21:08 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: concerns with TCR as a transition mechanism In-Reply-To: Message from David Blacka of "Mon, 21 Jun 2004 22:39:42 -0400." <200406212239.42577.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Jun 2004 00:21:08 +0000 Message-Id: <20040623002108.B27BC13E01@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: David Blacka > > I do not see an advantage for a zone to publish with both sets of metadata. > In fact, if -ter is attempting to solve the problem we think, there would be > a great disadvantage to publishing both. depends on what you mean by "publish". my current -ter draft suggests that new/different EDNS signalling will solicit -ter metadata, which if available would supercede the return of -bis metadata. (see section 2.1.) so, any zone owner who wanted to continue to serve the -bis validator community could (and probably would) "publish" both kinds of metadata during the transition period, which is likely to be five to ten years in duration. whether they use the same key data or different key data depends local policy. (DNSKEY may or may not be one of the types that has to be rolled, but even without rolling it, it's possible to publish more than one key at a name and use them for different purposes.) > > this is an important point because some here have said that > > we might do a partial TCR, such as only RRSIG and NSEC, and leave DS and > > DNSKEY as they are but use a different protocol number. i don't think > > that approach has merit, > > You haven't explained *why* that approach does not have merit. This > topic is in scope. during the recent discussion of protocol fields i got a little lost in the details. but since we don't have to decide which type codes will roll (or indeed if any of them will roll) in order to decide that -bis can be made into -ter at some later date, i disagree that the discussion is in-scope. i do agree in principle that a partial TCR would be less eventful than a full TCR, and that it may turn out to be possible to keep the existing in-tree DNSKEY data and/or DNSKEY RR format, and that if we can do this it would be preferrable to a full TCR. but none of that matters right now. what's "in-scope" at the moment is whether -bis constrains -ter so strongly that we had better not let it go to iesg after all. for that purpose, it's only nec'y that we describe a workable "most expensive case" and then decide whether it's too expensive or won't work. if a workable "most expensive case" is something we're willing to sign off on as a working group, then we still have total freedom to invent something less expensive for "actual -ter." > > ... so, my basic assumption has been that the "-ter transition" > > would flow from the trust anchor(s) "downward". > > Not the most flexible assumption, IMHO. i'm just painting a bookend for the shelf. you don't have to love it, and you don't have to agree that we're forced to do it that way. you just have to decide whether you could live with it if nothing better is invented, in case nothing better is in fact ever invented. > > ... delegation-only or delegation-mostly (collectively "non-leaf") > > zone operators will presumably be as actively necessary to -ter's > > deployment as to -bis's, and they will deploy -ter on the same basis > > -- if their subdomain-holding "customers" ask for it. > > You may have missed my point. How does the "non-leaf" zone operator > deploy -ter when, say, the root hasn't? Or when their ccTLD hasn't? i think i answered exactly your point, but apparently i missed, so i'll try again. the non-leaf zone operator could be in the exact same position at the beginning of -ter deployment as they are today at the beginning of -bis deployment -- and that is, they're waiting for a useful trust anchor and a useful path from that trust anchor to their own keys. > Would you force them to start their own island of security, or would > you commit to getting the root signed with -ter as soon as possible? today, neither. for all we know, -ter will not require DS RRs or anything like DS RRs, and trust anchors will be connected to zone keys by some method other than delegation paths. see the abstract, and sections 1.1, 1.2, and 1.3 of . > Wouldn't transition just be *easier* if a zone signed using -bis could > securely delegate to a zone signed with -ter? yes, of course it would. and if we can find a way to attach those rocket boosters to this pig, then it will fly just like you're saying. but that's for the -ter designers to work out (which may or may not include you and i.) > It is clear that you and I have different mental models for what the > world of DNSSEC-ter looks like. Perhaps I will post what my model is, > and you can tell me why I'm wrong. it sounds as if yours is a lot more specific than mine. i don't have one! all i know is, the worst case will work, and at a price i expect both the -bis installed base (if any) and the zonewalk-averse crowd would be willing and able to pay. i hope that something a lot better than TCR will be invented but that's not the topic i'm addressing today because it doesn't affect this working group's decision as to whether or not to forward these documents to iesg or not. > ... > Well, I'll ask the question in a more straightforward manner. Are we > comfortable using EDNS0 signalling? as a worst case? yes. i could live with it. but i'm not sure that the designers of -ter (who may or may not include you and i) will not invent something better. so, i'll ask my question in a more straightforward manner, too. are we comfortable with the current -ter draft as a worst case, and does the current -trans draft adequately describe the pitfalls available to us? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 20:33:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17473 for ; Tue, 22 Jun 2004 20:33:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bcvg6-000OFU-DV for namedroppers-data@psg.com; Wed, 23 Jun 2004 00:31:50 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bcvg5-000OFG-Ki for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 00:31:49 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 411AD13E01 for ; Wed, 23 Jun 2004 00:31:49 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement In-Reply-To: Message from Olaf Kolkman of "Tue, 22 Jun 2004 11:57:21 +0200." <8DB01EFE-C432-11D8-BC8F-000393DA2D46@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Jun 2004 00:31:49 +0000 Message-Id: <20040623003149.411AD13E01@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > If a resolver do not receive expected NSEC's to a query, it MUST > > NOT assume the zone is bogus, but instead assume negative proofs > > are absent. > > You must be able to unambiguously determine the security state even > when RRsets are stripped from your packets. The language you are > proposing does not, IMHO, allow for that. > > Since this proposal fundamentally alters the security model I am > opposed to this change. i agree. anyone who publishes a static NSEC that covers names which do in fact actually exist, is not following the -bis protocol. to the extent that they do this and find that it works out well for them, then we can call it a "successful loophole". but it's not reasonable to change the spec to allow this, without a lot more analysis and testing than this working group has time (or motivation) to perform right now. it's possible that we can widen this loophole a bit without changing the security model, by strengthening the "you should not use the NSEC for synthetic negative caching" text which is already present in the specs. what would be best, though, is if implementors either followed the -bis specs completely (avoiding loopholes), or waited for -ter. since it's possible to synthesize NSEC with a target range that only covers the qname, and it's possible to deploy hardware devices to speed up the crypto in this case, and it's possible to rate-limit negative responses in a way that hurts noone but the zone owner and the subdomain holders, i consider -bis deployable even by folks who are allergic to zonewalking. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 22 22:14:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24264 for ; Tue, 22 Jun 2004 22:14:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BcxCr-0009iw-L4 for namedroppers-data@psg.com; Wed, 23 Jun 2004 02:09:45 +0000 Received: from [66.45.230.132] (helo=spike.gnomon.org.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcxCo-0009iS-Ep for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 02:09:42 +0000 Received: from giles.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162]) by spike.gnomon.org.uk (8.12.10/8.12.10) with ESMTP id i5N1sjRC025509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jun 2004 01:54:45 GMT (envelope-from roy+dated+1090547685.ef1d44@gnomon.org.uk) Received: from giles.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by giles.gnomon.org.uk (8.12.11/8.12.11) with ESMTP id i5N1sjdG061579 for ; Wed, 23 Jun 2004 02:54:45 +0100 (BST) (envelope-from roy+dated+1090547685.ef1d44@giles.gnomon.org.uk) Received: (from roy@localhost) by giles.gnomon.org.uk (8.12.11/8.12.11/Submit) id i5N1sjLE061578 for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 02:54:45 +0100 (BST) (envelope-from roy+dated+1090547685.ef1d44@giles.gnomon.org.uk) Received: by giles.gnomon.org.uk (tmda-sendmail, from uid 559); Wed, 23 Jun 2004 02:54:44 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16600.58083.887087.314665@giles.gnomon.org.uk> Date: Wed, 23 Jun 2004 02:54:43 +0100 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement In-Reply-To: <20040623003149.411AD13E01@sa.vix.com> References: <8DB01EFE-C432-11D8-BC8F-000393DA2D46@ripe.net> <20040623003149.411AD13E01@sa.vix.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Roy Badami X-Primary-Address: roy@gnomon.org.uk Received-SPF: pass (spike.gnomon.org.uk: 81.100.86.162 is authenticated by a trusted mechanism) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Paul" == Paul Vixie writes: Paul> what would be best, though, is if implementors either Paul> followed the -bis specs completely (avoiding loopholes), or Paul> waited for -ter. since it's possible to synthesize NSEC Paul> with a target range that only covers the qname [...] Not without violating -bis, given the current intent of -bis is clearly to prohibit having NSEC records for owner names that wouldn't otherwise have any RRs (-protocol 2.3) So I think such an approach falls into the same loophole category... If we want to legitimise such an approach we'd have to replace both MUST NOTs in -protocol 2.3 para 3 with SHOULD NOTs. -roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 02:40:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13307 for ; Wed, 23 Jun 2004 02:40:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd1Ms-000Dx3-5Z for namedroppers-data@psg.com; Wed, 23 Jun 2004 06:36:22 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd1Mr-000Dwo-9W for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 06:36:21 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 411B342B2 for ; Wed, 23 Jun 2004 02:36:20 -0400 (EDT) Date: Wed, 23 Jun 2004 02:36:20 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement In-Reply-To: References: <8DB01EFE-C432-11D8-BC8F-000393DA2D46@ripe.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040623063620.411B342B2@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I do not support this proposal, because it looks like a nontrivial change to the DNSSECbis security model. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 05:25:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10767 for ; Wed, 23 Jun 2004 05:25:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd3y8-0009w1-IY for namedroppers-data@psg.com; Wed, 23 Jun 2004 09:23:00 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd3y7-0009vl-H9 for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 09:22:59 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 298E71FF846; Wed, 23 Jun 2004 09:22:58 +0000 (GMT) Message-ID: <40D94BEF.2050807@algroup.co.uk> Date: Wed, 23 Jun 2004 10:22:55 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Greg Hudson Cc: Rip Loomis , namedroppers@ops.ietf.org Subject: Re: concerns with TCR as a transition mechanism References: <4E25ECBBC03F874CBAD03399254ADFDE105118@US-Columbia-CIST.mail.saic.com> <1087913658.12585.150.camel@egyptian-gods.mit.edu> In-Reply-To: <1087913658.12585.150.camel@egyptian-gods.mit.edu> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Hudson wrote: > Note that a signing algorithm is particularly interested in defending > against known-plaintext attacks, since the attacker generally has no > shortage of plaintexts to work with. A cipher which is subject to a > known-plaintext attack is at somewhat less risk, since the attacker may > or may not have access to any plaintexts, but a cipher is still > considered broken if there is a known-plaintext attack against it with a > practical number of plaintexts. The situation gets fuzzier when you get > into chosen-plaintext and chosen-ciphertext attacks, which is why NO > records start to get a little bit worrisome. Except that you aren't really choosing the plaintext, since it is hashed before signing. Not that I see why NO records are any more chosen than any other record type. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 05:40:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11574 for ; Wed, 23 Jun 2004 05:40:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd4DG-000Bc4-Gs for namedroppers-data@psg.com; Wed, 23 Jun 2004 09:38:38 +0000 Received: from [217.155.92.105] (helo=scuzzy.ben.algroup.co.uk) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd4DF-000Bbn-HQ for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 09:38:37 +0000 Received: from [193.133.15.100] (eandbwin.ben.algroup.co.uk [193.133.15.100]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id A00541FF846; Wed, 23 Jun 2004 09:38:36 +0000 (GMT) Message-ID: <40D94F9C.9040506@algroup.co.uk> Date: Wed, 23 Jun 2004 10:38:36 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement References: <20040623003149.411AD13E01@sa.vix.com> In-Reply-To: <20040623003149.411AD13E01@sa.vix.com> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > what would be best, though, is if implementors either followed the -bis > specs completely (avoiding loopholes), or waited for -ter. since it's > possible to synthesize NSEC with a target range that only covers the > qname, This is also in violation of the protocol, surely, since both the owner and next domain fields would not exist. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 09:36:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00672 for ; Wed, 23 Jun 2004 09:36:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd7pw-000GYB-VJ for namedroppers-data@psg.com; Wed, 23 Jun 2004 13:30:48 +0000 Received: from [212.16.99.49] (helo=burp.tkv.asdf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd7pv-000GXv-E9 for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 13:30:48 +0000 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) with ESMTP id i5NDUUF1026250; Wed, 23 Jun 2004 16:30:30 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11/8.12.11/Debian-3) id i5NDUUqZ026247; Wed, 23 Jun 2004 16:30:30 +0300 Date: Wed, 23 Jun 2004 16:30:30 +0300 Message-Id: <200406231330.i5NDUUqZ026247@burp.tkv.asdf.org> From: Markku Savela To: namedroppers@ops.ietf.org cc: llmnr-editors@internaut.com Subject: draft-ietf-dnsext-mdns-31.txt X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk While reading section "2.4. Unicast queries and responses", I think it might be clearer with few added (+) and deleted (-) lines. This is just for consideration. Idea is make it clear from upfront that UNICAST == TCP use! ---------------------------------------------------------- 2.4. Unicast queries and responses Unicast queries SHOULD be sent when: [a] A sender repeats a query after it received a response with the TC bit set to the previous LLMNR multicast query, or [b] The sender queries for a PTR RR of a fully formed IP address within the "in-addr.arpa" or "ip6.arpa" zones. - A responder receiving a unicast query MUST send the response with a - source address set to the destination address field of the IP header - of the query causing the response. - [above is unnecessary statement, because it is implicitly true - when using TCP!] - Unicast LLMNR queries MUST be sent using TCP. Senders MUST support + Unicast LLMNR queries MUST be done using TCP and the responses MUST + be sent using the same connection as the query. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries. - Responses to TCP unicast LLMNR queries MUST be sent using TCP, using . the same connection as the query. If the sender of a TCP query + If the sender of a TCP query receives a response to that query not using TCP, the response MUST be silently discarded. Unicast UDP queries MUST be silently discarded. If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). ---------------------------------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 10:17:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01668 for ; Wed, 23 Jun 2004 10:17:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bd8WS-000Nbp-Eo for namedroppers-data@psg.com; Wed, 23 Jun 2004 14:14:44 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bd8WR-000Nba-Ms for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 14:14:43 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6192113951 for ; Wed, 23 Jun 2004 14:14:43 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dnssec-records ISSUE: don't make NSEC a protocol requirement In-Reply-To: Message from Ben Laurie of "Wed, 23 Jun 2004 10:38:36 +0100." <40D94F9C.9040506@algroup.co.uk> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Jun 2004 14:14:43 +0000 Message-Id: <20040623141443.6192113951@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > what would be best, though, is if implementors either followed the -bis > > specs completely (avoiding loopholes), or waited for -ter. this is still my position. > > since it's possible to synthesize NSEC with a target range that only > > covers the qname, > > This is also in violation of the protocol, surely, since both the owner and > next domain fields would not exist. yes, sorry. i forgot where we'd gotten to last time we explored this. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 12:55:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13125 for ; Wed, 23 Jun 2004 12:55:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdAyw-000LXf-PC for namedroppers-data@psg.com; Wed, 23 Jun 2004 16:52:18 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdAyv-000LXM-Do for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 16:52:17 +0000 Received: from pinion.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 23 Jun 2004 12:52:16 -0400 id 0014E04B.40D9B540.000054B9 From: David Blacka Organization: VeriSign, Inc. To: namedroppers@ops.ietf.org Subject: Re: concerns with TCR as a transition mechanism Date: Wed, 23 Jun 2004 12:52:15 -0400 User-Agent: KMail/1.6.2 References: <20040623002108.B27BC13E01@sa.vix.com> In-Reply-To: <20040623002108.B27BC13E01@sa.vix.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200406231252.16203.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 22 June 2004 8:21 pm, Paul Vixie wrote: > > From: David Blacka > > > > I do not see an advantage for a zone to publish with both sets of > > metadata. In fact, if -ter is attempting to solve the problem we think, > > there would be a great disadvantage to publishing both. > > depends on what you mean by "publish". my current -ter draft suggests > that new/different EDNS signaling will solicit -ter metadata, which if > available would supersede the return of -bis metadata. (see section 2.1.) By "publish" I mean: make available on the Internet. Which I think is a fairly normal usage of the term. My logic for my statement above goes something like this: * DNSSECter exists because DNSSECbis is unacceptable for some zone owners. * If I am one of those zone owners, publishing -bis metadata defeats the purpose of creating DNSSECter. * If I am not one of those zone owners, why should I publish -ter metadata? What I was forgetting, I think, was that zone owners who make available both -bis and -ter metadata are motivated to do so because 1) they can live with (or are quite happy with) -bis, but their children need -ter. So, under your proposal, some (most?) parent zones would (essentially) sign their zones twice, with -bis and -ter, to allow for a clear trust path for their -ter-only children. I do not mean this as a criticism. > > > this is an important point because some here have said that > > > we might do a partial TCR, such as only RRSIG and NSEC, and leave DS > > > and DNSKEY as they are but use a different protocol number. i don't > > > think that approach has merit, > > > > You haven't explained *why* that approach does not have merit. This > > topic is in scope. > > during the recent discussion of protocol fields i got a little lost in the > details. but since we don't have to decide which type codes will roll (or > indeed if any of them will roll) in order to decide that -bis can be made > into -ter at some later date, i disagree that the discussion is > in-scope. What I am trying to get at is the concept that we might want explore and describe other, non-worse-case transition plans. The reason why I feel that this discussion is in scope is that some of these other plans might require some language changes to DNSSECbis. I guess I'm disagreeing with the concept that because we've discovered *one* way to move from -bis to -ter, the conversation must then be over. I will agree, certainly, that we shouldn't spend an indefinite amount of time exploring other transition plans, but we shouldn't dismiss the possibility out of hand, either. When I attempt to get you (Paul) to comment in more detail as to why using the DNSKEY protocol field does not have merit, what I am trying to do is to get you to convince me to stop wasting my time on it. > > Wouldn't transition just be *easier* if a zone signed using -bis could > > securely delegate to a zone signed with -ter? > > yes, of course it would. and if we can find a way to attach those rocket > boosters to this pig, then it will fly just like you're saying. but that's > for the -ter designers to work out (which may or may not include you and > i.) You imply that this behavior would be difficult to achieve. In my mind it is not. Or more precisely, it *may* not be difficult. > > It is clear that you and I have different mental models for what the > > world of DNSSEC-ter looks like. Perhaps I will post what my model is, > > and you can tell me why I'm wrong. I think I misspoke a little, here. What I was really trying to describe is the model of how DNSSECter (which is unknown) interacts with DNSSECbis, not what DNSSECter is or is not. And we all have some sort of model for that. > it sounds as if yours is a lot more specific than mine. i don't have one! > all i know is, the worst case will work, and at a price i expect both the > -bis installed base (if any) and the zonewalk-averse crowd would be willing > and able to pay. i hope that something a lot better than TCR will be > invented but that's not the topic i'm addressing today because it doesn't > affect this working group's decision as to whether or not to forward these > documents to iesg or not. If we can propose a "better way", but it requires some minor language changes to DNSSECbis, then wouldn't that affect the decision to forward? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 15:41:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10142 for ; Wed, 23 Jun 2004 15:41:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdDYW-000O0a-OV for namedroppers-data@psg.com; Wed, 23 Jun 2004 19:37:12 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdDYG-000NyO-IR for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 19:36:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B9E8A13E1A for ; Wed, 23 Jun 2004 19:36:55 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: "Net pioneer predicts web future" (BBC) X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Jun 2004 19:36:55 +0000 Message-Id: <20040623193655.B9E8A13E1A@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk says: The net is only in the Bronze Age of evolution, according to the pioneer who invented the Domain Name System (DNS). In 1983, Dr Paul Mockapetris created the now familiar system which gives net pages names such as ".com" and ".co". ... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 15:56:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11477 for ; Wed, 23 Jun 2004 15:56:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdDoB-00006S-QE for namedroppers-data@psg.com; Wed, 23 Jun 2004 19:53:23 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdDnm-000Pzp-Uc for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 19:52:58 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 71A0A13E10 for ; Wed, 23 Jun 2004 19:52:58 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: concerns with TCR as a transition mechanism In-Reply-To: Message from David Blacka of "Wed, 23 Jun 2004 12:52:15 -0400." <200406231252.16203.davidb@verisignlabs.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 23 Jun 2004 19:52:58 +0000 Message-Id: <20040623195258.71A0A13E10@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > By "publish" I mean: make available on the Internet. Which I think is > a fairly normal usage of the term. > ... > What I was forgetting, I think, was that zone owners who make > available both -bis and -ter metadata are motivated to do so because > 1) they can live with (or are quite happy with) -bis, but their > children need -ter. yes, i think so. > > during the recent discussion of protocol fields i got a little lost > > in the details. but since we don't have to decide which type codes > > will roll (or indeed if any of them will roll) in order to decide > > that -bis can be made into -ter at some later date, i disagree that > > the discussion is in-scope. > > What I am trying to get at is the concept that we might want explore > and describe other, non-worse-case transition plans. The reason why I > feel that this discussion is in scope is that some of these other > plans might require some language changes to DNSSECbis. i think we have to presume that there aren't until we come up with one. > I guess I'm disagreeing with the concept that because we've discovered > *one* way to move from -bis to -ter, the conversation must then be > over. I will agree, certainly, that we shouldn't spend an indefinite > amount of time exploring other transition plans, but we shouldn't > dismiss the possibility out of hand, either. i understand. > When I attempt to get you (Paul) to comment in more detail as to why > using the DNSKEY protocol field does not have merit, what I am trying > to do is to get you to convince me to stop wasting my time on it. it might not be a waste of time. but i don't think we're going to be able to propose relaxations or tightenings of the -bis spec based on non-concrete designs, and i don't think we have enough time in the current -bis window to come up with a "concrete enough" design. even apparently-simple relaxation proposals like "make NSEC optional" end up touching a hundred small other parts of the design. the model is self- consistent at the moment and there's almost no such thing as a small change. (one of us also noted recently that "we have 11 years of history showing that we do not know how to change the dnssec design quickly.") > If we can propose a "better way", but it requires some minor language > changes to DNSSECbis, then wouldn't that affect the decision to forward? yes. but the time window is of fixed size, and the problem is not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 23 16:52:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16713 for ; Wed, 23 Jun 2004 16:52:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdEf0-000838-Nz for namedroppers-data@psg.com; Wed, 23 Jun 2004 20:47:58 +0000 Received: from [32.97.182.101] (helo=e1.ny.us.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdEed-0007yn-TK for namedroppers@ops.ietf.org; Wed, 23 Jun 2004 20:47:36 +0000 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i5NKlY32408898 for ; Wed, 23 Jun 2004 16:47:34 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i5NKmg0r116074 for ; Wed, 23 Jun 2004 16:48:42 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.10/8.12.11) with ESMTP id i5NKlXFW026124 for ; Wed, 23 Jun 2004 16:47:34 -0400 Received: from IBMTC_S30001313.gis.net ([9.22.26.62]) by d01av01.pok.ibm.com (8.12.10/8.12.11) with ESMTP id i5NKlMqA025419; Wed, 23 Jun 2004 16:47:27 -0400 Message-Id: <4.3.1.2.20040623164605.00c1c720@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 23 Jun 2004 16:47:05 -0400 To: Paul Vixie , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: "Net pioneer predicts web future" (BBC) In-Reply-To: <20040623193655.B9E8A13E1A@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:36 PM 6/23/2004, Paul Vixie wrote: > says: > >The net is only in the Bronze Age of evolution, according to the pioneer >who invented the Domain Name System (DNS). > >In 1983, Dr Paul Mockapetris created the now familiar system which gives >net pages names such as ".com" and ".co". And for half of that time we've been trying to get DNSSEC designed and implemented... Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 05:17:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18139 for ; Thu, 24 Jun 2004 05:17:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdQFY-000NHR-Qu for namedroppers-data@psg.com; Thu, 24 Jun 2004 09:10:28 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdQEC-000N2u-8S for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 09:09:04 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 6056355CD4; Thu, 24 Jun 2004 11:08:32 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C30CE55CAD; Thu, 24 Jun 2004 11:08:30 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5O98U8r002438; Thu, 24 Jun 2004 11:08:30 +0200 Date: Thu, 24 Jun 2004 11:08:30 +0200 From: "Olaf M. Kolkman" To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Message-Id: <20040624110830.44b02a96.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 5fa686f04b1935b806ec402737d38415 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Drop sentence from section 2.1: > > DNSKEY RRs MUST NOT appear at delegation points. > This seems to be in the spirit of the Q-8 and Q-11. I would replace the above sentence with something like: DNSKEY RRs appearing above the delegation point are non-authoritative. Maybe even make it explicit that the above means that one is dealing with glue and the DNSKEY RRs should not be signed by the parent. -- Olaf No hats. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 10:17:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16197 for ; Thu, 24 Jun 2004 10:17:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdUwz-0006N8-7A for namedroppers-data@psg.com; Thu, 24 Jun 2004 14:11:37 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdUwf-0006KM-Nr for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 14:11:17 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5OEBDC0013424 for ; Thu, 24 Jun 2004 10:11:13 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i5OEAa4A004670 for ; Thu, 24 Jun 2004 10:10:36 -0400 (EDT) From: "Scott Rose" To: Subject: RE: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Date: Thu, 24 Jun 2004 10:10:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040624110830.44b02a96.olaf@ripe.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf M. Kolkman > > > > Drop sentence from section 2.1: > > > > DNSKEY RRs MUST NOT appear at delegation points. > > > > This seems to be in the spirit of the Q-8 and Q-11. > > I would replace the above sentence with something like: > > DNSKEY RRs appearing above the delegation point are non-authoritative. > I like that text added in addition to dropping the "MUST NOT" language in Section 2.1 I don't see anything wrong in text reminding that glue is non-authoritative - especially when it deals with DNSSEC stuff like keys. Put it this way: Does anyone not want this text added in addition to dropping the "MUST NOT"? Scott > Maybe even make it explicit that the above means that one is dealing > with glue and the DNSKEY RRs should not be signed by the parent. > > > > -- Olaf > No hats. > > > > ---------------------------------| Olaf M. Kolkman > ---------------------------------| RIPE NCC > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 10:28:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17352 for ; Thu, 24 Jun 2004 10:28:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdV8C-00083Z-GS for namedroppers-data@psg.com; Thu, 24 Jun 2004 14:23:12 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdV81-00082S-W2 for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 14:23:02 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 6B8D956851; Thu, 24 Jun 2004 07:22:45 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.1.1.1.2.20040624101617.030b0ec0@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 24 Jun 2004 10:23:01 -0400 To: "Olaf M. Kolkman" , Simon Josefsson From: Mike StJohns Subject: Re: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Cc: namedroppers@ops.ietf.org In-Reply-To: <20040624110830.44b02a96.olaf@ripe.net> References: <20040624110830.44b02a96.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:08 AM 6/24/2004, Olaf M. Kolkman wrote: > > Drop sentence from section 2.1: > > > > DNSKEY RRs MUST NOT appear at delegation points. > > > >This seems to be in the spirit of the Q-8 and Q-11. > >I would replace the above sentence with something like: > > DNSKEY RRs appearing above the delegation point are non-authoritative. DNSKEY RRs appearing above the delegation points are non-authoritative, extraneous and MUST NOT be used to determine the validity of any DNSSEC trust chain. >Maybe even make it explicit that the above means that one is dealing >with glue and the DNSKEY RRs should not be signed by the parent. > > > >-- Olaf > No hats. > > > >---------------------------------| Olaf M. Kolkman >---------------------------------| RIPE NCC > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 10:31:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17721 for ; Thu, 24 Jun 2004 10:31:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdVC9-0008Xi-4Z for namedroppers-data@psg.com; Thu, 24 Jun 2004 14:27:17 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdVBq-0008Vc-Ch for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 14:26:58 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 7B00256887; Thu, 24 Jun 2004 07:26:42 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.1.1.1.2.20040624102319.03111ec0@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 24 Jun 2004 10:26:58 -0400 To: "Olaf M. Kolkman" , Simon Josefsson From: Mike StJohns Subject: Re: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Cc: namedroppers@ops.ietf.org In-Reply-To: <6.1.1.1.2.20040624101617.030b0ec0@localhost> References: <20040624110830.44b02a96.olaf@ripe.net> <6.1.1.1.2.20040624101617.030b0ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry - should have also said: This needs to be in the form of what the resolver does when it sees weird things, rather than a prohibition on the server putting the things there. While its true the parent should sign these, from time to time someone will and we need to be clear on what the behavior of the resolver needs to be. At 10:23 AM 6/24/2004, Mike StJohns wrote: >At 05:08 AM 6/24/2004, Olaf M. Kolkman wrote: > >> > Drop sentence from section 2.1: >> > >> > DNSKEY RRs MUST NOT appear at delegation points. >> > >> >>This seems to be in the spirit of the Q-8 and Q-11. >> >>I would replace the above sentence with something like: >> >> DNSKEY RRs appearing above the delegation point are non-authoritative. > >DNSKEY RRs appearing above the delegation points are non-authoritative, >extraneous and MUST NOT be used to determine the validity of any DNSSEC >trust chain. > > >>Maybe even make it explicit that the above means that one is dealing >>with glue and the DNSKEY RRs should not be signed by the parent. >> >> >> >>-- Olaf >> No hats. >> >> >> >>---------------------------------| Olaf M. Kolkman >>---------------------------------| RIPE NCC >> >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 11:04:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20037 for ; Thu, 24 Jun 2004 11:04:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdViy-000DDN-Ll for namedroppers-data@psg.com; Thu, 24 Jun 2004 15:01:12 +0000 Received: from [193.0.2.52] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdVin-000DBs-Cy for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 15:01:01 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 2AA6F358D63; Thu, 24 Jun 2004 17:01:20 +0200 (CEST) In-Reply-To: <6.1.1.1.2.20040624102319.03111ec0@localhost> References: <20040624110830.44b02a96.olaf@ripe.net> <6.1.1.1.2.20040624101617.030b0ec0@localhost> <6.1.1.1.2.20040624102319.03111ec0@localhost> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58B50948-C5EF-11D8-8C8B-000393DA2D46@ripe.net> Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Re: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Date: Thu, 24 Jun 2004 17:01:18 +0200 To: Mike StJohns X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mike, On Jun 24, 2004, at 4:26 PM, Mike StJohns wrote: > > Sorry - should have also said: > > This needs to be in the form of what the resolver does when it sees > weird things, rather than a prohibition on the server putting the > things there. While its true the parent should sign these, from time > to time someone will and we need to be clear on what the behavior of > the resolver needs to be. > I am loosing you with "While it is true the parent should sign these"... The parent is not authoritative for glue record, these DNSKEY RRs are not to be signed by the parent. > DNSKEY RRs appearing above the delegation points are > non-authoritative, extraneous and MUST NOT be used to determine the > validity of any DNSSEC trust chain. > I do agree with your language though. (I was about to argue that the MUST NOT should be a SHOULD NOT but I refrain because a allowing for 'glue' DNSKEY and RRSIGs both with the childs owner name but added as glue by the parent is probably a bad idea) --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 11:10:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20332 for ; Thu, 24 Jun 2004 11:10:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdVpB-000E9S-1q for namedroppers-data@psg.com; Thu, 24 Jun 2004 15:07:37 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdVor-000E5j-Uc for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 15:07:18 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i5OF78C0028796 for ; Thu, 24 Jun 2004 11:07:08 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i5OF6W4A018305 for ; Thu, 24 Jun 2004 11:06:32 -0400 (EDT) From: "Scott Rose" To: Subject: RE: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Date: Thu, 24 Jun 2004 11:06:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <6.1.1.1.2.20040624102319.03111ec0@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Mike StJohns > Sent: Thursday, June 24, 2004 10:27 AM How about adding text: DNSKEY RRs appearing above the delegation point are non-authoritative cannot be used for validation of RRSIGs by validators unless the DNSKEY RRs also meet the requirments in Section 5. - or change the "cannot" to SHOULD NOT/MUST NOT to make it more forceful? Scott > > > > Sorry - should have also said: > > This needs to be in the form of what the resolver does when it sees weird > things, rather than a prohibition on the server putting the things > there. While its true the parent should sign these, from time to time > someone will and we need to be clear on what the behavior of the resolver > needs to be. > > At 10:23 AM 6/24/2004, Mike StJohns wrote: > > >At 05:08 AM 6/24/2004, Olaf M. Kolkman wrote: > > > >> > Drop sentence from section 2.1: > >> > > >> > DNSKEY RRs MUST NOT appear at delegation points. > >> > > >> > >>This seems to be in the spirit of the Q-8 and Q-11. > >> > >>I would replace the above sentence with something like: > >> > >> DNSKEY RRs appearing above the delegation point are > non-authoritative. > > > >DNSKEY RRs appearing above the delegation points are non-authoritative, > >extraneous and MUST NOT be used to determine the validity of any DNSSEC > >trust chain. > > > > > >>Maybe even make it explicit that the above means that one is dealing > >>with glue and the DNSKEY RRs should not be signed by the parent. > >> > >> > >> > >>-- Olaf > >> No hats. > >> > >> > >> > >>---------------------------------| Olaf M. Kolkman > >>---------------------------------| RIPE NCC > >> > >> > >>-- > >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >>the word 'unsubscribe' in a single line as the message text body. > >>archive: > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 11:28:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21423 for ; Thu, 24 Jun 2004 11:28:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdW5o-000GVE-QX for namedroppers-data@psg.com; Thu, 24 Jun 2004 15:24:48 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdW5V-000GTh-G7 for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 15:24:29 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 7058356887; Thu, 24 Jun 2004 08:24:13 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <6.1.1.1.2.20040624112007.0335a898@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 24 Jun 2004 11:24:29 -0400 To: Olaf Kolkman From: Mike StJohns Subject: Re: dnssec-protocol ISSUE: permit DNSKEY's at all owner names Cc: Simon Josefsson , namedroppers@ops.ietf.org In-Reply-To: <58B50948-C5EF-11D8-8C8B-000393DA2D46@ripe.net> References: <20040624110830.44b02a96.olaf@ripe.net> <6.1.1.1.2.20040624101617.030b0ec0@localhost> <6.1.1.1.2.20040624102319.03111ec0@localhost> <58B50948-C5EF-11D8-8C8B-000393DA2D46@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:01 AM 6/24/2004, Olaf Kolkman wrote: >Hi Mike, > > >On Jun 24, 2004, at 4:26 PM, Mike StJohns wrote: > >> >>Sorry - should have also said: >> >>This needs to be in the form of what the resolver does when it sees weird >>things, rather than a prohibition on the server putting the things >>there. While its true the parent should sign these, from time to time >>someone will and we need to be clear on what the behavior of the resolver >>needs to be. > > >I am loosing you with "While it is true the parent should sign these"... >The parent is not authoritative for glue record, these DNSKEY RRs are not >to be signed by the parent. Typo: "While it is true the parent SHOULDN'T sign these" from time to time someone is going to do it by mistake or for other weird purposes. >>DNSKEY RRs appearing above the delegation points are non-authoritative, >>extraneous and MUST NOT be used to determine the validity of any DNSSEC >>trust chain. > >I do agree with your language though. > >(I was about to argue that the MUST NOT should be a SHOULD NOT but I >refrain because a allowing for 'glue' DNSKEY and RRSIGs both with the >childs owner name but added as glue by the parent is probably a bad idea) MUST NOT is correct. This is not a matter of implementation guidance, but of proper functioning. A DS based DNSSEC implementation can't properly deal with a DNSKEY record of the same name occurring above and below a delegation point. The one above the delegation point (e.g. in the parent) is extraneous and must be ignored. >--Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 11:40:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22110 for ; Thu, 24 Jun 2004 11:40:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdWHk-000I3Q-BD for namedroppers-data@psg.com; Thu, 24 Jun 2004 15:37:08 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BdWHP-000I17-KY for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 15:36:48 +0000 Received: (qmail 60997 invoked from network); 24 Jun 2004 15:36:15 -0000 Received: from yahoobb219001188048.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.48) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jun 2004 15:36:15 -0000 Message-ID: <40DAF641.3000906@necom830.hpcl.titech.ac.jp> Date: Fri, 25 Jun 2004 00:41:53 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Secure DNS actually is not so secure. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DSBL, RCVD_IN_NJABL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS,US_DOLLARS_3 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all; I think all the secure DNS documents should make it explicite that secure DNS actually is not so secure. That is, if a zone shared by a client and a server (e.g. the root zone) is compromized, secure DNS is also compromized. You might think that CAs are much more secure than ISPs. But it is not. Thus, it is equally likely that some ISP between a server and a client is compromized ant some CA between a server and a client is compromized. It should be noted that, if secure DNS is relied upon for monetary transactions that its certificate has authority to perform $1,000 transaction without consulting someone managing upper limit of credential of the certificate, the attacker can use the certificate 1,000 times a second from 1,000 different locations for 1,000 seconds to 1,000,000 or 1,000,000,000, which means there is $1,000,000,000,000 of economical benefit/damage, which is large enough to seduce employees of the largest CAs or, worse, terrorists. That is, it is mandately that certificates need confirmation everytime it is used, which negete the merit of public keys over shared keys. So, why do we bother to have secure DNS? Masataka Ohta Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 12:17:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24689 for ; Thu, 24 Jun 2004 12:17:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdWr0-000NIs-GN for namedroppers-data@psg.com; Thu, 24 Jun 2004 16:13:34 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdWqp-000NHH-LT for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 16:13:23 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Thu, 24 Jun 2004 12:13:08 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.6.45) with SMTP id M2004062412130703597 ; Thu, 24 Jun 2004 12:13:07 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 24 Jun 2004 12:13:08 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE105138@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Masataka Ohta'" , namedroppers@ops.ietf.org Subject: RE: Secure DNS actually is not so secure. Date: Thu, 24 Jun 2004 12:10:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,US_DOLLARS_3 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ohta-san: > I think all the secure DNS documents should make it > explicite that secure DNS actually is not so secure. I don't think that any reasonable person sees "security" as a binary or black-and-white item any more. Any security enhancement potentially still has flaws, and there is no realistic method for perfect security. That does not mean that security enhancements in general are not worthwhile (although some individual ones may be more trouble than they are worth, for some people, in some situations). Is there a specific piece of text you would like to see added to a specific document or documents? Please make a concrete suggestion and I'm sure that the WG will consider it. > That is, if a zone shared by a client and a server (e.g. > the root zone) is compromized, secure DNS is also compromized. I'm not sure I understand your terminology for "compromise". A server or set of servers could be compromised which would allow an attacker to modify the zone and/or to utilize/steal any private keys stored on that server. Is that what you mean by a compromise of the zone? If so, then in a case where the DNSSECbis zone-signing and key-signing keys are both stored "offline" (on a well-secured system with no direct inbound access from external systems or from the authoritative name servers for the zone), then "compromise of the zone" would seem to me to be a much harder problem. An attacker might compromise the authoritative servers, but any changes to the zone would be unsigned-- unless the offline signers were also compromised (or the ZSKs were stored online and were compromised). The recovery from this, for a well-run In any case, *right now* a DNS zone that has one or more servers compromised is in trouble. DNSSEC _does_ provide both a reduced probability that an attacker could usefully change the zone data, and a better ability for a zone administrator to discover that the zone data has been changed. However, DNSSEC is (in my opinion) really much more designed to address the security of data in transit on-the-wire or in storage on a caching server rather than data in storage on the authoritative server. > You might think that CAs are much more secure than ISPs. > But it is not. Again I'm not sure I understand your terminology. Could you give me an example of the CAs and ISPs of which you speak? I'm aware of several major ISPs that have had real internal security problems but no well-known CA that's had anything close to the same level of problems. > Thus, it is equally likely that some ISP between a server > and a client is compromized ant some CA between a server > and a client is compromized. > > It should be noted that, if secure DNS is relied upon for > monetary transactions that its certificate has > authority to perform $1,000 transaction without consulting > someone managing upper limit of credential of the certificate, > the attacker can use the certificate 1,000 times a second from > 1,000 different locations for 1,000 seconds to 1,000,000 or > 1,000,000,000, which means there is $1,000,000,000,000 of > economical benefit/damage, which is large enough to seduce > employees of the largest CAs or, worse, terrorists. I personally have no expectation that the security provided by DNSSEC will ever be relied upon as the sole authenticating factor for any financial transaction. Anyone who so relies does so (in my opinion) at their own peril. Of course, right now today there are folks who have done (or believe they have done) a risk assessment that allows them to use only an e-mail with no signature as a commitment for a contractual change. For those folks, DNSSEC can't make things any worse (not that I can see, anyway). > That is, it is mandately that certificates need confirmation > everytime it is used, which negete the merit of public keys > over shared keys. Comparing the problems of securely distributing and managing shared keys with the same issues for public keys, given large enterprises with which I have some familiarity, tells me that you are wrong. Could you please be more specific? > So, why do we bother to have secure DNS? There are an entire set of reasons for the DNS Security Extensions which have been well documented in this mailing list's archives, but which you have not mentioned above. Not quite sure why you believe that the above arguments are useful. For my part, I believe that DNSSECbis will be very useful to a large number of users to reduce risk from a specific set of attacks--attacks that I can mount today using readily available tools. *That* is why we're bothering to work on DNSSEC. Very Respectfully, Rip Loomis // SAIC (but of course, speaking only for myself) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 12:46:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27926 for ; Thu, 24 Jun 2004 12:46:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXJ4-0001Pi-Ji for namedroppers-data@psg.com; Thu, 24 Jun 2004 16:42:34 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXI6-0001Fn-ID for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 16:41:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0F35813DF7 for ; Thu, 24 Jun 2004 16:41:34 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: dnssec-protocol ISSUE: permit DNSKEY's at all owner names In-Reply-To: Message from "Scott Rose" of "Thu, 24 Jun 2004 11:06:32 -0400." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 24 Jun 2004 16:41:34 +0000 Message-Id: <20040624164134.0F35813DF7@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > How about adding text: i'm uncomfortable with this case-by-case discussion of rrtypes above a delegation point. the way the base dns protocol works is that "an NS RRset at a zone bottom is (a) nonauthoritative and (b) cannot be usefully accompanied by any other data." the way rfc2535 changed this is hard to describe, and now irrelevant. the way dnssec-bis changed this is to add two words "except NSEC and DS" to (b) above. we do not need to mention that DNSKEY shouldn't appear "above the cut", and if we do then some future reader of the document might incorrectly infer that since we said this about DNSKEY but didn't say it about A or TXT or MX, that "the intent of the framers" is that all rrtypes not described as ``can't appear above the cut'' must in fact be able to appear above the cut." that is NOT our intent, so let's not imply it! can we just explain that While DNSSEC-BIS specifies the placement of two new RRsets, NSEC and DS, in the parent zone above zone cuts, this is an exception to the general prohibition against putting data in the parent zone above a zone cut, and the general prohibition remains in effect. See RFC 1034. and not go into this on an rrtype-by-rrtype basis? re: > DNSKEY RRs appearing above the delegation point are non-authoritative > cannot be used for validation of RRSIGs by validators unless the > DNSKEY RRs also meet the requirments in Section 5. > > - or change the "cannot" to SHOULD NOT/MUST NOT to make it more forceful? > > Scott > > > Sorry - should have also said: > > > > This needs to be in the form of what the resolver does when it sees weird > > things, rather than a prohibition on the server putting the things > > there. While its true the parent should sign these, from time to time > > someone will and we need to be clear on what the behavior of the resolver > > needs to be. > > > > >> > Drop sentence from section 2.1: > > >> > > > >> > DNSKEY RRs MUST NOT appear at delegation points. > > >> > > > >> > > >>This seems to be in the spirit of the Q-8 and Q-11. > > >> > > >>I would replace the above sentence with something like: > > >> > > >> DNSKEY RRs appearing above the delegation point are > > >> non-authoritative. > > > > > >DNSKEY RRs appearing above the delegation points are non-authoritative, > > >extraneous and MUST NOT be used to determine the validity of any DNSSEC > > >trust chain. > > > > > >>Maybe even make it explicit that the above means that one is dealing > > >>with glue and the DNSKEY RRs should not be signed by the parent. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 24 12:54:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28822 for ; Thu, 24 Jun 2004 12:54:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BdXS2-000316-6F for namedroppers-data@psg.com; Thu, 24 Jun 2004 16:51:50 +0000 Received: from [18.7.7.80] (helo=biscayne-one-station.mit.edu) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdXRE-0002sG-7u for namedroppers@ops.ietf.org; Thu, 24 Jun 2004 16:51:00 +0000 Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i5OGov4E020251; Thu, 24 Jun 2004 12:50:57 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i5OGosOn016003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jun 2004 12:50:56 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i5OGorpu006727; Thu, 24 Jun 2004 12:50:53 -0400 Subject: Re: Secure DNS actually is not so secure. From: Greg Hudson To: Masataka Ohta Cc: namedroppers@ops.ietf.org In-Reply-To: <40DAF641.3000906@necom830.hpcl.titech.ac.jp> References: <40DAF641.3000906@necom830.hpcl.titech.ac.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1088095849.24763.10.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 24 Jun 2004 12:50:53 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2004-06-24 at 11:41, Masataka Ohta wrote: > I think all the secure DNS documents should make it explicite > that secure DNS actually is not so secure. [...] > So, why do we bother to have secure DNS? What's the point of bringing this up ten years into the process, just before a last call? It's not like we haven't known about this aspect of the security model all along. djb levelled the criticism years ago (http://cr.yp.to/djbdns/forgery.html) and suggested "nyms", which punt to the security of the channel through which you get the domain name; that hasn't caught on either. > Thus, it is equally likely that some ISP between a server > and a client is compromized ant some CA between a server > and a client is compromized. DNS-spoofing does not require a compromised ISP. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 28 02:23:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11265 for ; Mon, 28 Jun 2004 02:23:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BepQb-0001UU-IV for namedroppers-data@psg.com; Mon, 28 Jun 2004 06:15:41 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BepQT-0001Ts-Cv for namedroppers@ops.ietf.org; Mon, 28 Jun 2004 06:15:33 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id C75B95DCE9; Mon, 28 Jun 2004 08:15:15 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6289E5DCDE for ; Mon, 28 Jun 2004 08:15:15 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i5S6FF8r030487 for ; Mon, 28 Jun 2004 08:15:15 +0200 Date: Mon, 28 Jun 2004 08:15:15 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSSEC-bis: DONE. Message-Id: <20040628081515.423ea66d.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000006 / 0.0 / 0.0 / disabled X-RIPE-Signature: c8fa7bf27ceff1319fca359b1b3d07f9 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, Time to wrap up. DNSSEC-bis will go through one final iteration of editing and will then be shipped to the IESG. The chairs point of view is that there is consensus on shipping the DNSSEC-bis docs without the need for modifications to allow for a smooth transition to a system of denial of existence that does allow for more privacy. Some of the proposals to allow for 'more space' for transition have not gathered consensus. Below is a somewhat detailed explanation on how and/or why reached a conclusion on some of the major issues related to future transitions. - DNSKEY Flag; specifying behavior for certain settings of the protocol fields and keyflag field (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00955.html) and - nssec-records ISSUE: don't make NSEC a protocol requirement (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01199.html) The WG members have argued that both these proposals may cause changes in the security model. There is _no_ consensus on the fact that these proposals will _not_ cause problems. In fact, for the nsec-records issue there seems to be consensus that the proposal will cause problems. From the discussion on the mailing list the chairs are convinced that these changes can not be adopted without actually testing the proposals in a workshop environment. There is no time for this. To provide the one line summary: There is no rough consensus for forwarding and there is no time to continue working on these issues. - Concerns with TCR as a transition mechanism (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01191.html) This discussion concluded with the sense that although the proposed TCR mechanism may not be that flexible, it provides a way forward for the expected deployment path. - dnssec-protocol ISSUE: permit DNSKEY's at all owner names (http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01200.html) There is consensus that the specification should not limit where DNSKEY RRs are to appear. The text provided in http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01229.html seems to phrase the 'exceptions' properly. We realise that if we would allow for more time, time to think, time to modify the docs, time to modify code and time to test the code, we may have been able to come up with the perfect transition mechanism for any variety of future DNSSEC bis. We think the WG realises with us that the WG does not have that time. --- We would like to thank the working group for their positive and constructive attitude towards overcoming this hurdle. A number of people, we do not mention names to avoid missing people, have been successful in keeping the discussion focused, bringing solid technical arguments to the table and finding minor inconsistencies in the docs even after last call. --- We allow the editors to make the last modifications and publish a new revision. These revisions will be send to the IESG shortly (order day-days) after they appeared in the drafts repository. There will not be any last call. --- You will see the documents shipped to the IESG with a short writeup. (cf. http://www.mip4.org/2004/draft-writeup-items.html). We have assumed during this process that everybody in the group is aware of RFC3668 and we are not in for late surprises with respect to IPR disclosure. --Olaf and Olafur DNSEXT chairs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 28 15:32:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25631 for ; Mon, 28 Jun 2004 15:32:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bf1mO-000B4K-4w for namedroppers-data@psg.com; Mon, 28 Jun 2004 19:27:00 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bf1m6-000B3C-8O for namedroppers@ops.ietf.org; Mon, 28 Jun 2004 19:26:42 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25189; Mon, 28 Jun 2004 15:26:39 -0400 (EDT) Message-Id: <200406281926.PAA25189@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-31.txt Date: Mon, 28 Jun 2004 15:26:39 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-31.txt Pages : 26 Date : 2004-6-28 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-31.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-31.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-31.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-6-28151029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-31.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-31.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151029.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 29 15:33:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11720 for ; Tue, 29 Jun 2004 15:33:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfOGE-0002f0-Ca for namedroppers-data@psg.com; Tue, 29 Jun 2004 19:27:18 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfOG9-0002eT-Rq for namedroppers@ops.ietf.org; Tue, 29 Jun 2004 19:27:14 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11259; Tue, 29 Jun 2004 15:27:11 -0400 (EDT) Message-Id: <200406291927.PAA11259@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-32.txt Date: Tue, 29 Jun 2004 15:27:11 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-32.txt Pages : 26 Date : 2004-6-29 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-32.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-32.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-32.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-6-29145252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-32.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-32.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-29145252.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 30 09:24:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15944 for ; Wed, 30 Jun 2004 09:24:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfeyt-000B0i-9j for namedroppers-data@psg.com; Wed, 30 Jun 2004 13:18:31 +0000 Received: from [220.108.251.21] (helo=delta.noi.kre.to) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfeyr-000B0R-M6 for namedroppers@ops.ietf.org; Wed, 30 Jun 2004 13:18:30 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i5U8K2jV004920; Wed, 30 Jun 2004 15:20:02 +0700 (ICT) From: Robert Elz To: Don Stokes cc: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: <34433.1086910363@toybsd.zl2tnm.gen.nz> References: <34433.1086910363@toybsd.zl2tnm.gen.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jun 2004 15:20:02 +0700 Message-ID: <7532.1088583602@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, RCVD_IN_DYNABLOCK,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 11 Jun 2004 11:32:43 +1200 From: Don Stokes Message-ID: <34433.1086910363@toybsd.zl2tnm.gen.nz> I haven't been reading the list for the past few weeks, and am attempting to catch up. | as \001.x.example is out of bailiwick. The "next" name at the same | level as x.example would be "x\001.example.". This is a minor point, but I saw this, and didn't see it corrected (though I have not yet read all of the messages since this one), and I'd like to try and avoid one more piece of DNS folklore being developed, that everyone "simply knows" but which is incorrect... The "next" name in this sense from x.example would be \000.x.example not \001.x.example - or if you prefer, \000.x.example sorts between x.example and \001.x.example. The same is true for x\000.example (wrt x.example and x\001.example of course). There's nothing in the DNS spec that prohibits the use of the nul character in labels, and 0 is clearly < 1 (but greater than absent). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 30 19:52:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29998 for ; Wed, 30 Jun 2004 19:52:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfomF-0004oX-4c for namedroppers-data@psg.com; Wed, 30 Jun 2004 23:46:07 +0000 Received: from [203.96.144.16] (helo=gw.zl2tnm.gen.nz) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfomC-0004nx-Ji for namedroppers@ops.ietf.org; Wed, 30 Jun 2004 23:46:05 +0000 Received: from toybsd.zl2tnm.gen.nz (toybsd.zl2tnm.gen.nz [192.168.1.14]) by gw.zl2tnm.gen.nz (8.9.3/8.9.3) with ESMTP id LAA29975 for ; Thu, 1 Jul 2004 11:46:03 +1200 Received: from toybsd.zl2tnm.gen.nz (don@localhost [127.0.0.1]) by toybsd.zl2tnm.gen.nz (8.12.9/8.12.9) with ESMTP id i5UNk3fw094557 for ; Thu, 1 Jul 2004 11:46:03 +1200 (NZST) (envelope-from don@toybsd.zl2tnm.gen.nz) To: namedroppers@ops.ietf.org Subject: Re: NSEC synthesis and the NSEC Next Domain Name field In-Reply-To: Your message of "Wed, 30 Jun 2004 15:20:02 +0700." <7532.1088583602@munnari.OZ.AU> From: Don Stokes Date: Thu, 01 Jul 2004 11:46:03 +1200 Message-ID: <94556.1088639163@toybsd.zl2tnm.gen.nz> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz wrote: >The "next" name in this sense from x.example would be \000.x.example >not \001.x.example - or if you prefer, \000.x.example sorts between >x.example and \001.x.example. True -- and I was aware of that. However, I'm also fully aware of the fact that a heck of a lot of software out there is not as eight-bit clean as one might imagine, especially as far as nuls are concerned. After all, nuls are so rare and library routines that deal with nul-terminated strings so common that someone's eventually going to get bitten where it hurts by that. But yes, if one was codifying NSEC lies, one could use \000 and tell everyone writing DNS software that has to deal with NSEC that this is going to happen and they need to worry about it. -- 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: