From owner-namedroppers@ops.ietf.org Tue Oct 1 06:20:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05982 for ; Tue, 1 Oct 2002 06:20:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wJp0-00087y-00 for namedroppers-data@psg.com; Tue, 01 Oct 2002 03:00:06 -0700 Received: from randy by psg.com with local (Exim 3.36 #1) id 17wJou-00087H-00 for namedroppers@ops.ietf.org; Tue, 01 Oct 2002 03:00:00 -0700 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Tue, 01 Oct 2002 03:00:00 -0700 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. 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. 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, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. 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 --- 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. -- to unsubscribe send a message to namedroppers-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 Oct 3 07:42:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03181 for ; Thu, 3 Oct 2002 07:42:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17x3ws-000Ldq-00 for namedroppers-data@psg.com; Thu, 03 Oct 2002 04:15:18 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17x3wp-000Lde-00 for namedroppers@ops.ietf.org; Thu, 03 Oct 2002 04:15:15 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 95B3C44D3; Thu, 3 Oct 2002 13:15:12 +0200 (CEST) Date: Thu, 3 Oct 2002 13:15:12 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: negative caching support Message-ID: <20021003111512.GA12928@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, RFC 1034 mentions the following about negative response caching: The method is that a name server may add an SOA RR to the additional section of a response when that response is authoritative. The SOA must be that of the zone which was the source of the authoritative data in the answer section, or name error if applicable. The MINIMUM field of the SOA controls the length of time that the negative result may be cached. However, bind 8 and 9 add the SOA RR to the authority section. In the interest of interoperability, what do you suggest an authoritive DNS implementation should do? Follow the RFC or bind? Regards, bert hubert PowerDNS -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-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 Oct 3 08:02:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03721 for ; Thu, 3 Oct 2002 08:02:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17x4U7-000MIH-00 for namedroppers-data@psg.com; Thu, 03 Oct 2002 04:49:39 -0700 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 17x4Ty-000MHk-00 for namedroppers@ops.ietf.org; Thu, 03 Oct 2002 04:49:30 -0700 Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with ESMTP id g93BnSv19929; Thu, 3 Oct 2002 13:49:28 +0200 (MEST) Received: from localhost (pk@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id g93BnSG09149; Thu, 3 Oct 2002 13:49:28 +0200 (MEST) Message-Id: <200210031149.g93BnSG09149@komagatake.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: komagatake.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: komagatake.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: negative caching support In-reply-to: Your message of "Thu, 03 Oct 2002 13:15:12 +0200." <20021003111512.GA12928@outpost.ds9a.nl> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Thu, 03 Oct 2002 13:49:28 +0200 From: Peter Koch X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In the interest of interoperability, what do you suggest an authoritive DNS > implementation should do? Follow the RFC or bind? Follow both. RFC 1034 was updated by RFC 2308. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 3 08:24:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04338 for ; Thu, 3 Oct 2002 08:23:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17x4gP-000MYH-00 for namedroppers-data@psg.com; Thu, 03 Oct 2002 05:02:21 -0700 Received: from draco.cus.cam.ac.uk ([131.111.8.18]) by psg.com with esmtp (Exim 3.36 #1) id 17x4gL-000MY6-00 for namedroppers@ops.ietf.org; Thu, 03 Oct 2002 05:02:17 -0700 Received: from cet1 by draco.cus.cam.ac.uk with local (Exim 4.10) id 17x4gK-0004FN-00; Thu, 03 Oct 2002 13:02:16 +0100 Subject: Re: negative caching support To: ahu@ds9a.nl (bert hubert) Date: Thu, 3 Oct 2002 13:02:16 +0100 (BST) Cc: namedroppers@ops.ietf.org In-Reply-To: <20021003111512.GA12928@outpost.ds9a.nl> from "bert hubert" at Oct 3, 2 01:15:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ahu@ds9a.nl (bert hubert) writes: > RFC 1034 mentions the following about negative response caching: > > The method is that a name server may add an SOA RR to the additional > section of a response when that response is authoritative. The SOA must > be that of the zone which was the source of the authoritative data in > the answer section, or name error if applicable. The MINIMUM field of > the SOA controls the length of time that the negative result may be > cached. > > However, bind 8 and 9 add the SOA RR to the authority section. RFC 1034 section 4.3.4, which you quote, is *explicitly* obsoleted by RFC 2308. > In the interest of interoperability, what do you suggest an authoritive DNS > implementation should do? Follow the RFC or bind? If anyone seriously imagines they can create a new DNS server implementation by looking only at RFC 1034-5, and not bothering about all those tedious updating RFCs until later (if at all), they are out of their tiny minds! 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: From owner-namedroppers@ops.ietf.org Thu Oct 3 08:41:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04801 for ; Thu, 3 Oct 2002 08:41:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17x54P-000N4I-00 for namedroppers-data@psg.com; Thu, 03 Oct 2002 05:27:09 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17x54L-000N3n-00 for namedroppers@ops.ietf.org; Thu, 03 Oct 2002 05:27:05 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 87DD744D2; Thu, 3 Oct 2002 14:27:04 +0200 (CEST) Date: Thu, 3 Oct 2002 14:27:04 +0200 From: bert hubert To: Chris Thompson Cc: namedroppers@ops.ietf.org Subject: Re: negative caching support Message-ID: <20021003122704.GA13976@outpost.ds9a.nl> References: <20021003111512.GA12928@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Oct 03, 2002 at 01:02:16PM +0100, Chris Thompson wrote: > If anyone seriously imagines they can create a new DNS server implementation > by looking only at RFC 1034-5, and not bothering about all those tedious > updating RFCs until later (if at all), they are out of their tiny minds! Your needlessly abusive candour is appreciated. We did in fact search newer rfcs but not thoroughly enough. Thanks. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-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 Oct 3 14:22:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29205 for ; Thu, 3 Oct 2002 14:22:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17xAPh-00056o-00 for namedroppers-data@psg.com; Thu, 03 Oct 2002 11:09:29 -0700 Received: from adsl-065-081-097-145.sip.bna.bellsouth.net ([65.81.97.145] helo=freedom.bboy.net) by psg.com with smtp (Exim 3.36 #1) id 17xAPe-00056Z-00 for namedroppers@ops.ietf.org; Thu, 03 Oct 2002 11:09:26 -0700 Received: by freedom.bboy.net (iris/0.35:4); 3 Oct 2002 18:09:21 +0000 Received: from secure.bboy.net (HELO freedom.bboy.net) (192.168.1.1) by freedom.bboy.net (iris/0.35:4/relay) with SMTP id 4 for ; 3 Oct 2002 18:09:20 +0000 Date: Thu, 3 Oct 2002 13:09:19 -0500 From: Don Moore To: namedroppers@ops.ietf.org Subject: Re: negative caching support Message-Id: <20021003130919.30651037.bboy@bboy.net> In-Reply-To: References: <20021003111512.GA12928@outpost.ds9a.nl> X-Mailer: Sylpheed version 0.8.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Chris, > If anyone seriously imagines they can create a new DNS server > implementation by looking only at RFC 1034-5, and not bothering about > all those tedious updating RFCs until later (if at all), they are out > of their tiny minds! What a constructive comment! Unfortunately, some of us are busy writing new DNS server implementations, instead of putting down the same. How proud you must be to have committed to memory the (if the BIND9 "doc" directory is any indication) 65 working drafts and 65 RFC's pertinent to DNS. You can help actual implementors by being our doc boy! Bert, > In the interest of interoperability, what do you suggest an > authoritive DNS implementation should do? Follow the RFC or bind? I pretty much always try to match BIND's behavior, mostly due to the number of registries worldwide that depend on server behavior to exactly mimic BIND. I think there are at least a few that will refuse to register a domain if the authoritative server does not return a SOA RR in the Authority. IIRC, .nl is a good example. -- Don (http://mydns.bboy.net/) -- "I never knew words could be so confusing," Milo said to Tock as he bent down to scratch the dog's ear. "Only when you use a lot to say a little," answered Tock. -- Norton Juster, _The Phantom Tollbooth_ -- to unsubscribe send a message to namedroppers-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 Oct 3 15:04:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01311 for ; Thu, 3 Oct 2002 15:04:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17xB6f-0006WJ-00 for namedroppers-data@psg.com; Thu, 03 Oct 2002 11:53:53 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17xB6b-0006W8-00 for namedroppers@ops.ietf.org; Thu, 03 Oct 2002 11:53:49 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 6564F44F2; Thu, 3 Oct 2002 20:53:48 +0200 (CEST) Date: Thu, 3 Oct 2002 20:53:48 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: Re: negative caching support Message-ID: <20021003185348.GB21050@outpost.ds9a.nl> References: <20021003111512.GA12928@outpost.ds9a.nl> <20021003130919.30651037.bboy@bboy.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021003130919.30651037.bboy@bboy.net> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Oct 03, 2002 at 01:09:19PM -0500, Don Moore wrote: > I pretty much always try to match BIND's behavior, mostly due to > the number of registries worldwide that depend on server behavior to > exactly mimic BIND. I think there are at least a few that will refuse > to register a domain if the authoritative server does not return a SOA > RR in the Authority. IIRC, .nl is a good example. .nl does not check that. They do however block registrations for SOA hostmasters with a '.' in the local-part... We updated pdns today (at 11AM EST) to include the SOA according to the RFC Chris mentioned and we think we notice a marked drop in query load: http://mrtg-us.powerdns.com So this appears to be a good idea. Sadly, DENIC for example demands a 40.000 second SOA minimum which is a bit much for negative caching. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-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 Oct 3 21:12:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10060 for ; Thu, 3 Oct 2002 21:12:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17xGm9-0002Tb-00 for namedroppers-data@psg.com; Thu, 03 Oct 2002 17:57:05 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17xGm5-0002TQ-00 for namedroppers@ops.ietf.org; Thu, 03 Oct 2002 17:57:01 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 2FA59137F06; Thu, 3 Oct 2002 17:57:01 -0700 (PDT) To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: negative caching support In-Reply-To: Message from bert hubert of "Thu, 03 Oct 2002 20:53:48 +0200." <20021003185348.GB21050@outpost.ds9a.nl> Date: Thu, 03 Oct 2002 17:57:01 -0700 Message-ID: <47521.1033693021@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "bert" == bert hubert writes: bert> So this appears to be a good idea. Sadly, DENIC for example bert> demands a 40.000 second SOA minimum which is a bit much for bert> negative caching. Why? Long TTLs are a very good thing IMO, even for negative answers. Large TTLs should only present a problem when people don't plan and co-ordinate their DNS changes very well. For instance, by dropping the TTL on a server a decent interval before the box gets renumbered. And anyway, what's stopping someone changing their SOA values after DENIC has done their pre-registration check and delegated the zone? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 4 04:48:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26278 for ; Fri, 4 Oct 2002 04:48:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17xNrT-000LUk-00 for namedroppers-data@psg.com; Fri, 04 Oct 2002 01:31:03 -0700 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 17xNrP-000LUV-00 for namedroppers@ops.ietf.org; Fri, 04 Oct 2002 01:30:59 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with SMTP id g948Uvv10857 for ; Fri, 4 Oct 2002 10:30:57 +0200 (MEST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id KAA17720; Fri, 4 Oct 2002 10:30:57 +0200 Message-Id: <200210040830.KAA17720@grimsvotn.TechFak.Uni-Bielefeld.DE> To: namedroppers@ops.ietf.org Subject: Re: negative caching support In-reply-to: Your message of "Thu, 03 Oct 2002 17:57:01 PDT." <47521.1033693021@shell.nominum.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Fri, 04 Oct 2002 10:30:57 +0200 From: Peter Koch X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid wrote: > Why? Long TTLs are a very good thing IMO, even for negative answers. while there have been different statements even for the effectiveness of positive caching in the past, the gain of negative caching lies within shorter time frames. It helps with 'insisting' resolvers and applications (at least that's what I've seen on a server with lots of IN-ADDR.ARPA zones). > Large TTLs should only present a problem when people don't plan and > co-ordinate their DNS changes very well. For instance, by dropping the > TTL on a server a decent interval before the box gets renumbered. Sure, but you can't decrease the TTL on particular negative answers in advance. > And anyway, what's stopping someone changing their SOA values after > DENIC has done their pre-registration check and delegated the zone? Nothing, unfortunately. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 4 06:32:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27815 for ; Fri, 4 Oct 2002 06:32:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17xPfB-000NjJ-00 for namedroppers-data@psg.com; Fri, 04 Oct 2002 03:26:29 -0700 Received: from smtp.denic.de ([194.246.96.22]) by psg.com with esmtp (Exim 3.36 #1) id 17xPf8-000Nj8-00 for namedroppers@ops.ietf.org; Fri, 04 Oct 2002 03:26:26 -0700 Received: from notes.denic.de (denics15.denic.de [194.246.96.18]) by smtp.denic.de with esmtp id 17xPes-00060I-00; Fri, 4 Oct 2002 12:26:11 +0200 Subject: Re: Re: negative caching support To: ahu@ds9a.nl Cc: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Marcos Sanz/Denic" Date: Fri, 4 Oct 2002 12:26:17 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.10 |March 22, 2002) at 04.10.2002 12:26:11 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA27815 On 04.10.2002 02:57 Jim Reid wrote: > > >>>>> "bert" == bert hubert writes: > > bert> So this appears to be a good idea. Sadly, DENIC for example > bert> demands a 40.000 second SOA minimum which is a bit much for > bert> negative caching. Actually, any value between 180 and 345600 is accepted. > And anyway, what's stopping someone changing their SOA values after > DENIC has done their pre-registration check and delegated the zone? Nothing. Thatīs the reason why I am a defender of unannounced periodical checkings.. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 4 07:40:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29354 for ; Fri, 4 Oct 2002 07:40:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17xQdD-000CiK-00 for namedroppers-data@psg.com; Fri, 04 Oct 2002 04:28:31 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17xQd7-000Ci9-00 for namedroppers@ops.ietf.org; Fri, 04 Oct 2002 04:28:25 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28697; Fri, 4 Oct 2002 07:26:22 -0400 (EDT) Message-Id: <200210041126.HAA28697@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-01.txt Date: Fri, 04 Oct 2002 07:26:22 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** 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 : KEY RR Key Signing (KS) Flag Author(s) : O. Kolkman, J. Schlyter Filename : draft-ietf-dnsext-keyrr-key-signing-flag-01.txt Pages : 7 Date : 2002-10-3 With the DS record [1] the concept of key signing and zone signing keys has been introduced. Key signing keys are the keys that sign the keyset only. In general, key signing keys are the keys that are pointed to by DS records and are the first keys to be used when following a chain of trust into the zone. The key signing keys only sign the KEY RRset at the apex of a zone, zone signing keys sign all data in a zone. We propose a flag to distinguish the key signing key from other keys in the KEY RR set during DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-keyrr-key-signing-flag-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-3145855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-3145855.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 4 09:08:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02395 for ; Fri, 4 Oct 2002 09:08:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17xS1m-0002yy-00 for namedroppers-data@psg.com; Fri, 04 Oct 2002 05:57:58 -0700 Received: from mailgw2.technion.ac.il ([132.68.238.35]) by psg.com with esmtp (Exim 3.36 #1) id 17xS1g-0002yf-00 for namedroppers@ops.ietf.org; Fri, 04 Oct 2002 05:57:53 -0700 Received: by mailgw2.technion.ac.il (Postfix, from userid 60999) id 3CF1F36E34; Fri, 4 Oct 2002 15:57:22 +0300 (IDT) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 367D136E34 for ; Fri, 4 Oct 2002 15:57:20 +0300 (IDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA07700 for ietf-123-outbound.07@ietf.org; Fri, 4 Oct 2002 07:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA07384 for ; Fri, 4 Oct 2002 07:28:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28697; Fri, 4 Oct 2002 07:26:22 -0400 (EDT) Message-Id: <200210041126.HAA28697@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-01.txt Date: Fri, 04 Oct 2002 07:26:22 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * 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 : KEY RR Key Signing (KS) Flag Author(s) : O. Kolkman, J. Schlyter Filename : draft-ietf-dnsext-keyrr-key-signing-flag-01.txt Pages : 7 Date : 2002-10-3 With the DS record [1] the concept of key signing and zone signing keys has been introduced. Key signing keys are the keys that sign the keyset only. In general, key signing keys are the keys that are pointed to by DS records and are the first keys to be used when following a chain of trust into the zone. The key signing keys only sign the KEY RRset at the apex of a zone, zone signing keys sign all data in a zone. We propose a flag to distinguish the key signing key from other keys in the KEY RR set during DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-keyrr-key-signing-flag-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-3145855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-3145855.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 Oct 15 07:44:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27154 for ; Tue, 15 Oct 2002 07:44:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181PwE-000PQG-00 for namedroppers-data@psg.com; Tue, 15 Oct 2002 04:32:38 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 181PwC-000PQ4-00 for namedroppers@ops.ietf.org; Tue, 15 Oct 2002 04:32:36 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26416; Tue, 15 Oct 2002 07:30:25 -0400 (EDT) Message-Id: <200210151130.HAA26416@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-03.txt Date: Tue, 15 Oct 2002 07:30:24 -0400 X-Spam-Status: No, hits=3.4 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,OPT_IN,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC Opt-in Author(s) : R. Arends, M. Kosters, D. Blacka Filename : draft-ietf-dnsext-dnssec-opt-in-03.txt Pages : 21 Date : 2002-10-14 In RFC 2535, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an 'Opt-In' model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-opt-in-03.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-opt-in-03.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: <2002-10-14142106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-14142106.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 Oct 15 18:07:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17115 for ; Tue, 15 Oct 2002 18:07:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181Zb6-000GVg-00 for namedroppers-data@psg.com; Tue, 15 Oct 2002 14:51:28 -0700 Received: from h140.s251.netsol.com ([216.168.251.140] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #2) id 181Zb4-000GTO-00 for namedroppers@ops.ietf.org; Tue, 15 Oct 2002 14:51:26 -0700 Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id C7C6F224BE; Tue, 15 Oct 2002 17:50:55 -0400 (EDT) To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dnssec-opt-in-03 From: David Blacka Message-ID: Date: Tue, 15 Oct 2002 17:50:55 -0400 Lines: 20 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Informed Management, i386-mandrake-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.5 required=5.0 tests=OPT_IN,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The latest revision of the opt-in draft is now in the drafts repository: This version attempts to address all of the open issues with opt-in, at least as we understood them. This boiled down to: * use of the AD bit with opt-in, * clarifications about wildcards and opt-in, * some more explicit language describing the changes to the validation process, and * some language to make it explicit that like DS, opt-in is not backwards compatible with 2535. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 17 07:51:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07029 for ; Thu, 17 Oct 2002 07:51:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1828vz-000EWG-00 for namedroppers-data@psg.com; Thu, 17 Oct 2002 04:35:23 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 1828vp-000EVr-00 for namedroppers@ops.ietf.org; Thu, 17 Oct 2002 04:35:13 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06293; Thu, 17 Oct 2002 07:33:01 -0400 (EDT) Message-Id: <200210171133.HAA06293@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-delegation-signer-10.txt Date: Thu, 17 Oct 2002 07:33:00 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * 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 : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-10.txt Pages : 14 Date : 2002-10-16 The delegation signer (DS) resource record is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and the implications of this record on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC1035, RFC2535, RFC3008 and RFC3090. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-delegation-signer-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-16152706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-16152706.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 21 13:31:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07235 for ; Mon, 21 Oct 2002 13:31:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183gAI-000LyB-00 for namedroppers-data@psg.com; Mon, 21 Oct 2002 10:16:30 -0700 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #2) id 183gAG-000Lxz-00 for namedroppers@ops.ietf.org; Mon, 21 Oct 2002 10:16:28 -0700 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Mon, 21 Oct 2002 13:16:16 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002102113161612720 for ; Mon, 21 Oct 2002 13:16:16 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Oct 2002 13:17:29 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E6803B957E9@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-opt-in-03 Date: Mon, 21 Oct 2002 13:16:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Status: No, hits=-3.1 required=5.0 tests=EXCHANGE_SERVER,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A few comments against > opt-in-03.txt> not specifically CC'd to the authors since I believe they all read this list rather regularly...followed by some questions (for the entire WG) related to this draft. 1. Section 2, first paragraph. Authors' choice of words: "For these zones, the costs of maintaining the NXT record chain may not be relative to the gain of cryptographically securing delegations to unsigned zones." Everything's relative IMHO. Perhaps you meant: "For these zones, the costs of maintaining the NXT record chain may be extremely high, relative to the gain of cryptographically securing delegations to unsigned zones." 2. Section 3, third paragraph. Authors' choice of words: "Using Opt-In, the existence or non-existence of insecure delegations is not asserted by the tagged NXT records." is confusing--too many negatives IMHO. Might it be clearer with the following sentence instead? "In a zone containing Opt-In tagged NXT records, the existence or non-existence of insecure delegations is asserted only by the records themselves (and their presence within a range covered by the tagged NXT records, rather than by the tagged NXT records themselves." I'm not sure if that's actually any easier to understand, but I think that the original text is too difficult to understand as it stands. (It gets a little easier if someone reads the next few paragraphs and comes back, but that's not how most of us process information.) Other than those very minor points, this looks to be a correct and complete statement of opt-in as it stands. Could someone from the DNS "directorate", or anyone else who's keeping score, please speak up and let the WG know whether this addresses the issues previously raised with the opt-in drafts? I'm not a DNS software coder/implementer, and it still looks as though the handling/caching/searching of opt-in tagged NXT records could be "interesting". From the perspective of pushing DNSSEC forward, though, I recommend that the WG take a good hard look at this and then make a clear decision very soon. Is there a timetable to finalize discussion, such as "face-to-face at Atlanta, followed by WG last call if appropriate"??? I note that in almost a week since the I-D was posted, there's been no discussion of it on public forums...unless I missed one. I can't raise any specific security objections to opt-in as proposed (other than vague "this complicates the security model...I think" objections), and I do believe that without it we'll have a hard time getting DNSSEC functionally deployed to protect the entire hierarchy. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 22 05:16:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09488 for ; Tue, 22 Oct 2002 05:16:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183uyc-000Bs6-00 for namedroppers-data@psg.com; Tue, 22 Oct 2002 02:05:26 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 183uya-000Brd-00 for namedroppers@ops.ietf.org; Tue, 22 Oct 2002 02:05:24 -0700 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id g9M95DnZ010052 for ; Tue, 22 Oct 2002 11:05:13 +0200 Date: Tue, 22 Oct 2002 11:05:13 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. Message-Id: <20021022110513.34b93869.olaf@ripe.net> In-Reply-To: <20020920174749.66e929e4.olaf@ripe.net> References: <20020920174749.66e929e4.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: NONE ; -1012 X-Spam-Status: No, hits=-11.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to invite some feedback/comments on this draft before presenting it in Atlanta. Note, if this is to be implemented it will need to piggy-back on on the DS transition as it is not backwards compatible with RFC2535 specs. > Below is a link to a document describing an optimization to the > wildcard algorithm resulting in the need for only 1 NXT/SIG for when > there are no wildcards in the zone. Even if there are wildcards in the > zone 1 NXT/SIG may be sufficient. > > http://www.ripe.net/DISI/Notes/draft-olaf-dnsext-dnssec-wildcard-optimization-00.txt --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-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 Oct 22 11:53:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23368 for ; Tue, 22 Oct 2002 11:53:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18418i-000IU2-00 for namedroppers-data@psg.com; Tue, 22 Oct 2002 08:40:16 -0700 Received: from bulkregister-ldap.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #2) id 18418h-000ISr-00 for namedroppers@ops.ietf.org; Tue, 22 Oct 2002 08:40:15 -0700 Received: from pinion.admin.cto.netsol.com (h140.s251.netsol.com [216.168.251.140]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 22 Oct 2002 11:39:43 -0400 Content-Type: text/plain; charset="iso-8859-1" From: David Blacka Organization: Verisign, Inc. To: "Loomis, Rip" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-opt-in-03 Date: Tue, 22 Oct 2002 11:39:42 -0400 User-Agent: KMail/1.4.3 References: <3C1E3607B37295439F7C409EFBA08E6803B957E9@US-Columbia-CIST.mail.saic.com> In-Reply-To: <3C1E3607B37295439F7C409EFBA08E6803B957E9@US-Columbia-CIST.mail.saic.com> MIME-Version: 1.0 Message-Id: <200210221139.42672.davidb@verisignlabs.com> X-Spam-Status: No, hits=-8.9 required=5.0 tests=IN_REP_TO,NOSPAM_INC,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA23368 On Monday 21 October 2002 01:16 pm, Loomis, Rip wrote: > A few comments against > > > > opt-in-03.txt> > > not specifically CC'd to the authors since I believe they > all read this list rather regularly...followed by some questions > (for the entire WG) related to this draft. > > 1. Section 2, first paragraph. Authors' choice of words: > "For these zones, the costs of maintaining the NXT record > chain may not be relative to the gain of cryptographically > securing delegations to unsigned zones." > > Everything's relative IMHO. Perhaps you meant: > "For these zones, the costs of maintaining the NXT record > chain may be extremely high, relative to the gain of > cryptographically securing delegations to unsigned zones." Yes, this sounds good to me. > 2. Section 3, third paragraph. Authors' choice of words: > "Using Opt-In, the existence or non-existence of insecure > delegations is not asserted by the tagged NXT records." > > is confusing--too many negatives IMHO. Might it be clearer > with the following sentence instead? > "In a zone containing Opt-In tagged NXT records, the existence > or non-existence of insecure delegations is asserted only by > the records themselves (and their presence within a range > covered by the tagged NXT records, rather than by the tagged > NXT records themselves." > > I'm not sure if that's actually any easier to understand, > but I think that the original text is too difficult to understand > as it stands. (It gets a little easier if someone reads the > next few paragraphs and comes back, but that's not how most > of us process information.) I agree that the original text is difficult to understand. I will work on better wording for it, if I don't use yours. -- 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 Oct 22 16:12:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02737 for ; Tue, 22 Oct 2002 16:12:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1845AP-0002Tu-00 for namedroppers-data@psg.com; Tue, 22 Oct 2002 12:58:17 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 1845AN-0002Tb-00 for namedroppers@ops.ietf.org; Tue, 22 Oct 2002 12:58:15 -0700 Received: from isi.edu (pool-138-88-1-183.res.east.verizon.net [138.88.1.183]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9MJwBC02362; Tue, 22 Oct 2002 12:58:12 -0700 (PDT) Message-ID: <3DB5ADD8.3000407@isi.edu> Date: Tue, 22 Oct 2002 15:58:16 -0400 From: Daniel Massey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. References: <20020920174749.66e929e4.olaf@ripe.net> <20021022110513.34b93869.olaf@ripe.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG,X_OSIRU_DUL, X_OSIRU_DUL_FH version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I think this a very good idea and I would also like to propose a minor change.... what if the NTA bit says no wildcards apply to the name space covered by this NXT (rather than saying no wildcards in this zone) An initial pass came up with some very minor concerns: - with the per zone bit, various TTL/caching and misconfig scenarios can occur where one NXT in the zone has the bit set and another NXT does not - with the per zone bit, zones that use wildcards are screwed even if the wildcard only covers a very small part of the zone - the semantics of the NXT change slightly. conceptually the NXT was saying something about a particular namespace region. now with the per zone bit it says something about a namespace region and something about the zone. So suppose instead the NTA bit just says that no wildcard applies in the NXT's namespace. For example, a.example.com NXT c.example.com +NTA bit says "no names exist between a.example.com and c.example.com AND no wildcards apply for names between a.example.com and c.example.com". This is the only NXT you need to send to prove b.example.com does not exisist (and it works even if the zone contains *.d.example.com) Dan Olaf M. Kolkman wrote: >I'd like to invite some feedback/comments on this draft before >presenting it in Atlanta. Note, if this is to be implemented it will >need to piggy-back on on the DS transition as it is not backwards >compatible with RFC2535 specs. > > > > > >> Below is a link to a document describing an optimization to the >> wildcard algorithm resulting in the need for only 1 NXT/SIG for when >> there are no wildcards in the zone. Even if there are wildcards in the >> zone 1 NXT/SIG may be sufficient. >> >> http://www.ripe.net/DISI/Notes/draft-olaf-dnsext-dnssec-wildcard-optimization-00.txt >> >> > > > >--------------------------------------------| Olaf M. Kolkman > | www.ripe.net/disi > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 22 17:06:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04590 for ; Tue, 22 Oct 2002 17:06:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18464X-0005BO-00 for namedroppers-data@psg.com; Tue, 22 Oct 2002 13:56:17 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 18464W-0005BA-00 for namedroppers@ops.ietf.org; Tue, 22 Oct 2002 13:56:16 -0700 Received: from isi.edu (pool-138-88-1-183.res.east.verizon.net [138.88.1.183]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9MKu9C13309; Tue, 22 Oct 2002 13:56:09 -0700 (PDT) Message-ID: <3DB5BB6D.9020408@isi.edu> Date: Tue, 22 Oct 2002 16:56:13 -0400 From: Daniel Massey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Massey CC: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. References: <20020920174749.66e929e4.olaf@ripe.net> <20021022110513.34b93869.olaf@ripe.net> <3DB5ADD8.3000407@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.5 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_AND_TO_SAME_2,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG,X_OSIRU_DUL, X_OSIRU_DUL_FH version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Massey wrote: > Hi, > > I think this a very good idea and I would also like to propose a minor > change.... what if the NTA bit says no wildcards apply to the name > space covered by this NXT (rather than saying no wildcards in this > zone) ignore my "minor change" since I misunderstood when the bit is set. This draft is a very good idea as is and helps greatly with wildcard processing. Thanks, Dan -- to unsubscribe send a message to namedroppers-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 Oct 23 11:59:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21968 for ; Wed, 23 Oct 2002 11:59:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Nhx-000HZz-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 08:46:09 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 184Nhu-000HZn-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 08:46:07 -0700 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g9NFh7D63045; Wed, 23 Oct 2002 11:43:07 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021022211849.027780a0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 23 Oct 2002 11:45:36 -0400 To: "Olaf M. Kolkman" , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSSEC wildcard optimization. In-Reply-To: <20021022110513.34b93869.olaf@ripe.net> References: <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:05 2002-10-22, Olaf M. Kolkman wrote: >I'd like to invite some feedback/comments on this draft before >presenting it in Atlanta. Note, if this is to be implemented it will >need to piggy-back on on the DS transition as it is not backwards >compatible with RFC2535 specs. > 1. Overloading the SIG bit, in my mind is a "BAD" idea. I think it is a better design for humans and software to explicitly state that wild card may apply in the gap between the left hand side name and the right hand side name of an NXT. We have plenty of bits to use including the following undocumented type codes EID 31 Endpoint Identifier [Patton] NIMLOC 32 Nimrod Locator [Patton] ATMA 34 ATM Address [Dobrowski] SINK 40 SINK [Eastlake] 2. I think the bit should have a more explicit name say "WILD" or "WILDC", NTAS looks like misspelled NAT. 3. The document does not address at all the issues for dynamic zones that have wild cards. In this case a creation/deletion of a name can require the resigning of many NXT records. 4. RFC1035 wild card algorithm is unclear and needs clarification, publishing this protocol change without fixing the specification is not prudent, and I encourage the authors on taking on the clarification effort. 5. There is a significant misunderstanding in the community on how wildcards apply. At a DNSSEC workshop at ARIN earlier this month for DNS administrators at ISP's, I polled the room about expected answers in the following setup *.foo MX a.foo A Q: a.foo. MX Majority of people answering thought wildcard applied. Q: b.a.foo MX ? slim majority of the people that answered said that the expanded wild card applied. Correct answer is wild card does NOT apply in either case. Based on this and other evidence that I have indicates that wild card usage is to large extent based on misunderstanding. There are examples where wild card MX records are used to create mail domains that exist without any DNS records such as eng.sun.com. Thus if the misunderstanding is corrected and we explain to the few application communities that are using wild cards in a legit way to push names out of DNS, what the DNS problems are, maybe we can make wildcards go away. Furthermore a simple tool that populates a zone with MX records at all names that have address will be more within community expectations than wild card is. 6. Overall, IFF wildcards are needed then something like this will help DNSSEC a lot. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 23 13:02:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25545 for ; Wed, 23 Oct 2002 13:01:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Oh9-000KcV-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 09:49:23 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #2) id 184Ogd-000Kbu-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 09:48:51 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g9NGmhGO003676; Wed, 23 Oct 2002 18:48:44 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g9NGmhJj003672; Wed, 23 Oct 2002 18:48:43 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 23 Oct 2002 18:48:42 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: "Olaf M. Kolkman" , Subject: Re: DNSSEC wildcard optimization. In-Reply-To: <5.1.1.6.2.20021022211849.027780a0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Spam-Status: No, hits=-9.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id NAA25545 On Wed, 23 Oct 2002, Ólafur Guðmundsson wrote: > At 05:05 2002-10-22, Olaf M. Kolkman wrote: > > >I'd like to invite some feedback/comments on this draft before > >presenting it in Atlanta. Note, if this is to be implemented it will > >need to piggy-back on on the DS transition as it is not backwards > >compatible with RFC2535 specs. > > 1. Overloading the SIG bit, in my mind is a "BAD" idea. > I think it is a better design for humans and software to explicitly > state that wild card may apply in the gap between the left hand side > name and the right hand side name of an NXT. We have plenty of bits > to use including the following undocumented type codes > EID 31 Endpoint Identifier [Patton] > NIMLOC 32 Nimrod Locator [Patton] > ATMA 34 ATM Address [Dobrowski] > SINK 40 SINK [Eastlake] Sure, we can also request a new, previously unused type code, if that clears the path a little. Plenty left. > 2. I think the bit should have a more explicit name say "WILD" or "WILDC", > NTAS looks like misspelled NAT. That new typecode can be called "WILD" or "WILDC". > 3. The document does not address at all the issues for dynamic zones > that have wild cards. In this case a creation/deletion of a name can > require the resigning of many NXT records. I'll look into that one. I imagine the costs are larger then dynups in dnssec zones without wcard optimization. I don't really know. > 4. RFC1035 wild card algorithm is unclear and needs clarification, > publishing this protocol change without fixing the specification is not > prudent, and I encourage the authors on taking on the clarification effort. > > 5. There is a significant misunderstanding in the community on how > wildcards apply. At a DNSSEC workshop at ARIN earlier this month for > DNS administrators at ISP's, I polled the room about expected answers > in the following setup > *.foo MX > a.foo A > > Q: a.foo. MX > Majority of people answering thought wildcard applied. > > Q: b.a.foo MX ? > slim majority of the people that answered said that the > expanded wild card applied. > > Correct answer is wild card does NOT apply in either case. > > Based on this and other evidence that I have indicates that wild card > usage is to large extent based on misunderstanding. > There are examples where wild card MX records are used to create mail > domains that exist without any DNS records such as eng.sun.com. > Thus if the misunderstanding is corrected and we explain to the few > application communities that are using wild cards in a legit way > to push names out of DNS, what the DNS problems are, maybe we can make > wildcards go away. Furthermore a simple tool that populates a zone > with MX records at all names that have address will be more within > community expectations than wild card is. The draft proposes optimization, not a textbook definition how wildcards work, definitly not on why one might use them, though I agree that the 1034/5 description of wildcards left room for improvement. > 6. Overall, IFF wildcards are needed then something like this will help > DNSSEC a lot. Yes. 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 Oct 23 14:23:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28329 for ; Wed, 23 Oct 2002 14:23:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Pwz-000OyP-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 11:09:49 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #2) id 184Pww-000Oy1-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 11:09:47 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3D7B318E8 for ; Wed, 23 Oct 2002 14:09:45 -0400 (EDT) Date: Wed, 23 Oct 2002 14:09:45 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. In-Reply-To: <5.1.1.6.2.20021022211849.027780a0@localhost> References: <20020920174749.66e929e4.olaf@ripe.net> <20021022110513.34b93869.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021023180945.3D7B318E8@thrintun.hactrn.net> X-Spam-Status: No, hits=-9.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 23 Oct 2002 11:45:36 -0400, Olafur Gudmundsson wrote: > > 1. Overloading the SIG bit, in my mind is a "BAD" idea. > I think it is a better design for humans and software to explicitly > state that wild card may apply in the gap between the left hand side > name and the right hand side name of an NXT. We have plenty of bits > to use including the following undocumented type codes > EID 31 Endpoint Identifier [Patton] > NIMLOC 32 Nimrod Locator [Patton] > ATMA 34 ATM Address [Dobrowski] > SINK 40 SINK [Eastlake] At the risk of suggesting something insufficiently baroque: If overloading the SIG code is bad, then please just allocate a brand new type code for this purpose and have done with it. ["Don't tug on that, you never know what it might be attached to."] -- to unsubscribe send a message to namedroppers-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 Oct 23 14:46:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29497 for ; Wed, 23 Oct 2002 14:46:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184QPS-0000j8-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 11:39:14 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 184QPO-0000ir-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 11:39:11 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9NId8Ym093862; Wed, 23 Oct 2002 14:39:08 -0400 (EDT) Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA02997; Wed, 23 Oct 2002 14:39:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <20021022110513.34b93869.olaf@ripe.net> References: <20020920174749.66e929e4.olaf@ripe.net> <20021022110513.34b93869.olaf@ripe.net> Date: Wed, 23 Oct 2002 14:38:59 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: DNSSEC wildcard optimization. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.7 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:05 +0200 10/22/02, Olaf M. Kolkman wrote: >I'd like to invite some feedback/comments on this draft before Be careful what you wish for. I have a few problems with the draft, although I think y'alls are on to something. I think the first thing that should be cleared up is that: It would be good for the signer to indicate that for an NXT's span, no wildcard match is available. (Need to clarify what a "span" is.) Ignoring opt-in for the time being, when an NXT is generated (whether by the off-line signer or the dynamic update signer), the signer can reliably determine what wildcard applies to the span of the names involved. E.g.: ownername NXT nextname typemap There are two kinds of names that don't *explicitly* exist between ownername and nextname (both of which do explicitly exist in the zone). One kind is subdomains of ownername and the other kind is sibling domains. The distinction is that if there is a wildcard that would cover the non-explicit sibling domains in the range the same wildcard would not cover the non-explicit subdomains of ownername. There is the special case of the ownername being a wildcard itself, in which the same wildcard (=ownername) covers both kinds of non-explicit names. So, it seems to me (and this is open to discussion) that the signer has the information to determine what wildcard applies to the range ownername - nextname. If this is the case, a resolver could reliably determine whether to expect a wild card - because the signer indicates one and the queryname is not a subdomain of the ownername. (Is it true that only one wildcard will apply to all the sibling domains between the ownername and nextname? Is this different if the ownername is also a wildcard?) I think that the above concept needs to be better defined in the draft. That is, assuming that the above concept is correct. (Discussion?) Where I would like the text to be beefed up is to discuss the role of signing in determining whether a wildcard would apply on names between ownername and nextname. Then there needs to be a discussion on what happens when preparing a response - i.e., once the server sees the indication that there is no wildcard, it can exit the 1034 algorithm. Finally, there should be a discussion on how resolvers treat the presence/abscence of the indication of wildcards. Next topic: how to indicate the presence or absence of applicable wildcards. Usurping yet another bit in the typemap is getting to be the port-80 of transport protocols. We have three low-valued bits to play with - 0, NXT, and SIG. If opt-in flys, it takes one of the three. I think 0 has someother reserved value waiting it. This proposal is saying the last of these bits is to be taken. There's a cultural antipathy towards using the last bit in our community, usually for good reason. Yet another topic: The draft should discuss the implication of dynamic updates on this. Yes, there's no significant impact but it should be stated that the signing process (in a signed, dynamic update zone) will have to regenerate the NXT's anyway. In addition to dynamic update, it would be interesting to run this proposal through the opt-in decision making process. (I had a chat with David Blacka last week on opt-in that hasn't yet been fully processed.) A question: What is a NXT dname (end of section 2)? We should stick to the owner name, next name, and query name terms. And, while I'm at it, another comment: In the examples, there should be one set of examples showing the "normal" no-wildcard case. Then a zone with the one wildcard (a la * MX ...). And then a hairier example (as you have) showing cases where a wildcard gets blocked from application. In summary - I am always skeptical to any optimization attempts at first. Whenever you are adding an optimization you are inherently complicating the architecture and implementation. At times the cost of the complication is offset by the gain in performance - but this isn't always so. So a skeptical eye is needed first. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 23 15:35:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02368 for ; Wed, 23 Oct 2002 15:35:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RBq-0003ul-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 12:29:14 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 184RBK-0003qm-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 12:28:42 -0700 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9NJSKnZ001211; Wed, 23 Oct 2002 21:28:20 +0200 Message-Id: <200210231928.g9NJSKnZ001211@birch.ripe.net> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. In-reply-to: Your message of Wed, 23 Oct 2002 11:45:36 EDT. <5.1.1.6.2.20021022211849.027780a0@localhost> References: <5.1.1.6.2.20021022211849.027780a0@localhost> From: Olaf Kolkman X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Wed, 23 Oct 2002 21:28:20 +0200 X-RIPE-Spam-Status: NONE ; -1005 X-Spam-Status: No, hits=-5.4 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * 1. Overloading the SIG bit, in my mind is a "BAD" idea. * I think it is a better design for humans and software to explicitly * state that wild card may apply in the gap between the left hand side * name and the right hand side name of an NXT. We have plenty of bits * to use including the following undocumented type codes * EID 31 Endpoint Identifier [Patton] * NIMLOC 32 Nimrod Locator [Patton] * ATMA 34 ATM Address [Dobrowski] * SINK 40 SINK [Eastlake] * By introducing a new type one looses the packet size optimization as described in section 1.2: o Packet size of answers reduce in most common cases; for the root zone the authority section only contains 1 NXT RR with associated SIGs instead of two NXT RRs with associated SIGs. Note that the extra NXT RR without the optimization of the new RR-TYPE will need to come with 1 or more SIG RRs. I think that that warrants the 'overloading' of the SIG in the NXT bitmap. Out of curiosity: Why is overloading the SIG bit a "BAD" idea? Why is it worse than overloading the NXT bit? * 2. I think the bit should have a more explicit name say "WILD" or "WILDC", * NTAS looks like misspelled NAT. Agreed, seems the DNS protocol is running out of acronyms :-). What about NOWILD, if it is set there are no wildcards, which is more intuitive than WILD. I welcome other ideas. * 3. The document does not address at all the issues for dynamic zones * that have wild cards. In this case a creation/deletion of a name can * require the resigning of many NXT records. I will add a section on dynamic zones. In short: When adding a regular name dynamically you do not need to modify/generate more NXT rrs than in the non-optimized set. You just need to change the previous NXT nxt-name to point to the name just inserted and you will have to do determine if the NTAS bit needs to be set for the new RR. If one adds wildcards dynamically then you have to possibly modify a larger number of NXT RRs. Those NXT RR can be identified as described in the 2nd paragraph of section 2. If adding wildcards dynamically is allowed by the protocol (an I don't think there are any restrictions there) then I guess there is a choice to not set the optimization bit at all for the zone and that choice needs to be made explicit in the draft. * * 4. RFC1035 wild card algorithm is unclear and needs clarification, * publishing this protocol change without fixing the specification is not * prudent, and I encourage the authors on taking on the clarification effort. * Agreed. * 5. There is a significant misunderstanding in the community on how * wildcards apply. I agree with that, I remember it took me a long time to fully understand what was happening, and it is still a difficult topic to explain clearly during courses. But the understanding and (ab)use of wildcards are outside the scope of the draft. The draft assumes that wildcards and DNSSEC go hand-in-hand. * * 6. Overall, IFF wildcards are needed then something like this will help * DNSSEC a lot. Has the discussion on that conditional ever converged? --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 Wed Oct 23 17:08:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05536 for ; Wed, 23 Oct 2002 17:08:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184SZF-000AHx-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 13:57:29 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 184SZC-000AHL-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 13:57:26 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9NKvNYm001761; Wed, 23 Oct 2002 16:57:23 -0400 (EDT) Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA02983; Wed, 23 Oct 2002 16:57:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <20020920174749.66e929e4.olaf@ripe.net> <20021022110513.34b93869.olaf@ripe.net> Date: Wed, 23 Oct 2002 16:57:11 -0400 To: Edward Lewis , "Olaf M. Kolkman" From: Edward Lewis Subject: more on Re: DNSSEC wildcard optimization. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.0 required=5.0 tests=FROM_AND_TO_SAME_6,IN_REP_TO,OPT_IN,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A look at opt-in and this. Olaf asked for some more clarity in my comments, I thought I'd bring this to the list: I just want to go through the mental exercise of thinking how opt-in impacts this. E.g., *.b.com TXT signed (opt-in) a.b.com NS signed d.b.com NS signed e.b.com NS unsigned (opt-out) g.b.com NS signed QNAME=c.e.b.com -> no wildcard vs. QNAME=c.f.b.com -> wildcard but both are covered by the same "d.b.com NXT g.b.com opt-in." Does this NXT indicate wildcard or no wildcard? There is a conflict between name existence and opt-in signing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 23 17:14:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05678 for ; Wed, 23 Oct 2002 17:14:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Sgg-000Avu-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 14:05:10 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 184Sg8-000ArX-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 14:04:37 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g9NKwHE63586; Wed, 23 Oct 2002 16:58:17 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Wed, 23 Oct 2002 16:58:17 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Olaf Kolkman cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. In-Reply-To: <200210231928.g9NJSKnZ001211@birch.ripe.net> Message-ID: <20021023164653.G63518-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Olaf Kolkman wrote: > > > * 1. Overloading the SIG bit, in my mind is a "BAD" idea. > * I think it is a better design for humans and software to explicitly > * state that wild card may apply in the gap between the left hand side > * name and the right hand side name of an NXT. We have plenty of bits > * to use including the following undocumented type codes > * EID 31 Endpoint Identifier [Patton] > * NIMLOC 32 Nimrod Locator [Patton] > * ATMA 34 ATM Address [Dobrowski] > * SINK 40 SINK [Eastlake] > * > > > By introducing a new type one looses the packet size optimization as described > in section 1.2: > > > o Packet size of answers reduce in most common cases; for the root > zone the authority section only contains 1 NXT RR with associated > SIGs instead of two NXT RRs with associated SIGs. > > > Note that the extra NXT RR without the optimization of the new RR-TYPE > will need to come with 1 or more SIG RRs. I think that that warrants > the 'overloading' of the SIG in the NXT bitmap. > This does not follow, the same rules apply, if WILD is set there is possibly matching Wild card ==> requires multiple NXT if qname does not match name on NXT. if WILD not set there is no wildcard match possible thus no need for more NXT's > Out of curiosity: Why is overloading the SIG bit a "BAD" idea? Why is it > worse than overloading the NXT bit? > It is not as bad because no NXT bit implies that the NXT matching rules have changed, in this case the the NXT bitmap is expressing if other NXT's are needed. > > * 2. I think the bit should have a more explicit name say "WILD" or "WILDC", > * NTAS looks like misspelled NAT. > > Agreed, seems the DNS protocol is running out of acronyms :-). What > about NOWILD, if it is set there are no wildcards, which is more > intuitive than WILD. I welcome other ideas. I think it is better to say "Something else may match" than "Nothing else matches", personal preference. > > > * 3. The document does not address at all the issues for dynamic zones > * that have wild cards. In this case a creation/deletion of a name can > * require the resigning of many NXT records. > > I will add a section on dynamic zones. In short: > > When adding a regular name dynamically you do not need to > modify/generate more NXT rrs than in the non-optimized set. You just > need to change the previous NXT nxt-name to point to the name just > inserted and you will have to do determine if the NTAS bit needs to be > set for the new RR. > > If one adds wildcards dynamically then you have to possibly modify a s+add wildcards+adds/deletes wildcard sets+ > larger number of NXT RRs. Those NXT RR can be identified as described > in the 2nd paragraph of section 2. > > If adding wildcards dynamically is allowed by the protocol (an I don't > think there are any restrictions there) then I guess there is a choice > to not set the optimization bit at all for the zone and that choice > needs to be made explicit in the draft. yes it is allowed. > > * > * 4. RFC1035 wild card algorithm is unclear and needs clarification, > * publishing this protocol change without fixing the specification is not > * prudent, and I encourage the authors on taking on the clarification effort. > * > > Agreed. > > > * 5. There is a significant misunderstanding in the community on how > * wildcards apply. > > I agree with that, I remember it took me a long time to fully > understand what was happening, and it is still a difficult topic to > explain clearly during courses. But the understanding and (ab)use of > wildcards are outside the scope of the draft. The draft assumes that > wildcards and DNSSEC go hand-in-hand. > > * > * 6. Overall, IFF wildcards are needed then something like this will help > * DNSSEC a lot. > > Has the discussion on that conditional ever converged? > It degenerates into a flame war each time :-( Someone needs to take the time to write "The case against wildcards in DNS" or "How to live happily without DNS wildcards" We need to determine REAL SOON if this effort is important enough to be included in the Opt-in/DS/AD-secure flag day (or any subset of them). Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 23 18:04:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06887 for ; Wed, 23 Oct 2002 18:04:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184TQN-000Eo8-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 14:52:23 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 184TQK-000Enw-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 14:52:20 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA15177; Wed, 23 Oct 2002 17:52:18 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA17359; Wed, 23 Oct 2002 17:52:15 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id RAA28901; Wed, 23 Oct 2002 17:52:15 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA01211; Wed, 23 Oct 2002 17:52:15 -0400 (EDT) To: Edward Lewis Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: more on Re: DNSSEC wildcard optimization. References: <20020920174749.66e929e4.olaf@ripe.net> <20021022110513.34b93869.olaf@ripe.net> Date: 23 Oct 2002 17:52:14 -0400 In-Reply-To: Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-11.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > A look at opt-in and this. Olaf asked for some more clarity in my > comments, I thought I'd bring this to the list: > > I just want to go through the mental exercise of thinking how opt-in > impacts this. E.g., > > *.b.com TXT signed (opt-in) > a.b.com NS signed > d.b.com NS signed > e.b.com NS unsigned (opt-out) > g.b.com NS signed > > QNAME=c.e.b.com -> no wildcard vs. > QNAME=c.f.b.com -> wildcard > > but both are covered by the same "d.b.com NXT g.b.com opt-in." Does > this NXT indicate wildcard or no wildcard? There is a conflict > between name existence and opt-in signing. The flag indicates "wildcard POSSIBLE" or "wildcard NOT POSSIBLE". If the "wildcard POSSIBLE" is set, and you have opt-in, then you still have this ambiguity. However, if you have the "wildcard NOT possible" bit set, then QNAME=c.e.b.com would return the NS record, and QNAME=c.f.b.com would return NXDOMAIN. -derek PS: I should note that you don't specify which particular NXT records are 'opt-in' vs. 'non-opt-in'. The only one you specify is the wildcard. You don't say whether d.b.com. NXT g.b.com. is opt-in or not. -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 23 18:41:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07282 for ; Wed, 23 Oct 2002 18:41:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184U7X-000ITd-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 15:36:59 -0700 Received: from bulkregister-ldap.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #2) id 184U72-000IQY-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 15:36:28 -0700 Received: from pinion.admin.cto.netsol.com (h140.s251.netsol.com [216.168.251.140]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Wed, 23 Oct 2002 18:35:56 -0400 Content-Type: text/plain; charset="iso-8859-1" From: David Blacka Organization: Verisign, Inc. To: Edward Lewis , "Olaf M. Kolkman" Subject: Re: more on Re: DNSSEC wildcard optimization. Date: Wed, 23 Oct 2002 18:35:55 -0400 User-Agent: KMail/1.4.3 Cc: namedroppers@ops.ietf.org References: <20020920174749.66e929e4.olaf@ripe.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <200210231835.55599.davidb@verisignlabs.com> X-Spam-Status: No, hits=-8.9 required=5.0 tests=IN_REP_TO,NOSPAM_INC,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA07282 On Wednesday 23 October 2002 04:57 pm, Edward Lewis wrote: > A look at opt-in and this. Olaf asked for some more clarity in my > comments, I thought I'd bring this to the list: > > I just want to go through the mental exercise of thinking how opt-in > impacts this. E.g., > > *.b.com TXT signed (opt-in) > a.b.com NS signed > d.b.com NS signed > e.b.com NS unsigned (opt-out) > g.b.com NS signed > > QNAME=c.e.b.com -> no wildcard vs. > QNAME=c.f.b.com -> wildcard > > but both are covered by the same "d.b.com NXT g.b.com opt-in." Does > this NXT indicate wildcard or no wildcard? There is a conflict > between name existence and opt-in signing. What conflict? If the NXT is Opt-In, it does not matter what the NOWILD (or whatever it is called) flag is. At least if the wildcard processing rules in the opt-in-03 draft are correct. -- 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 Oct 23 18:56:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07503 for ; Wed, 23 Oct 2002 18:56:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184UNy-000K07-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 15:53:58 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 184UNw-000Jvk-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 15:53:56 -0700 Received: by shell.nominum.com (Postfix, from userid 1411) id 51EB0137F02; Wed, 23 Oct 2002 15:53:26 -0700 (PDT) To: =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: DNSSEC wildcard optimization. References: <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> From: Bob Halley Date: 23 Oct 2002 15:53:26 -0700 In-Reply-To: <5.1.1.6.2.20021022211849.027780a0@localhost> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=-9.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA07503 Ólafur Guðmundsson writes: > 4. RFC1035 wild card algorithm is unclear and needs clarification, > publishing this protocol change without fixing the specification is not > prudent, and I encourage the authors on taking on the clarification effort. What is unclear? > Based on this and other evidence that I have indicates that wild card > usage is to large extent based on misunderstanding. > There are examples where wild card MX records are used to create mail > domains that exist without any DNS records such as eng.sun.com. > Thus if the misunderstanding is corrected and we explain to the few > application communities that are using wild cards in a legit way > to push names out of DNS, what the DNS problems are, maybe we can make > wildcards go away. Some people are confused, certainly. But I find it very hard to believe that most uses of wildcards are erroneous or unwarranted. Wildcards can be made to work with DNSSEC as it is. Why don't we just leave features like wildcards that people are already using in, stop adding more features, and let it deploy? Removing wildcards from DNSSEC will discourage and delay deployment. /Bob -- to unsubscribe send a message to namedroppers-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 Oct 23 19:17:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07718 for ; Wed, 23 Oct 2002 19:17:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Ufy-000LPh-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 16:12:34 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 184Ufw-000LNh-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 16:12:32 -0700 Received: from [192.168.1.210] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 706B7137F02; Wed, 23 Oct 2002 16:12:01 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 23 Oct 2002 16:13:56 -0700 Subject: Re: DNSSEC wildcard optimization. From: David Conrad To: =?ISO-8859-1?B?02xhZnVyIEd18A==?=mundsson , Olaf Kolkman , namedroppers Message-ID: In-Reply-To: <5.1.1.6.2.20021022211849.027780a0@localhost> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-Spam-Status: No, hits=-8.1 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_ENTOURAGE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA07718 Olafur, On 10/23/02 8:45 AM, "Ólafur Guðmundsson" wrote: > 1. Overloading the SIG bit, in my mind is a "BAD" idea. Modifying the DNSSEC specs in non-backwards compatible ways _yet again_ is a "BAD" idea. Can we please stop? I would personally like to see DNSSEC deployed in my lifetime. > Thus if the misunderstanding is corrected and we explain to the few > application communities that are using wild cards in a legit way > to push names out of DNS, what the DNS problems are, maybe we can make > wildcards go away. Don't be silly. Wildcards are seen as providing useful functionality. Attempts to remove them, regardless of the validity of the attempt, will get dragged down into non-terminating IETF politics. Given wildcards exist, any attempt to remove them from DNSSEC will simply mean disincentives for DNSSEC deployment. We do NOT need more disincentives to deploying DNSSEC. Can we please stop? I would personally like to see DNSSEC deployed in my lifetime. I guess it would be too much to ask that if someone is going to propose modifications to the DNSSEC specifications that those modifications MUST be backwards compatible with the evolved (?) form of DNSSEC+DS? By the way, just where is 2535bis? Thanks, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 23 22:56:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14768 for ; Wed, 23 Oct 2002 22:56:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Y0J-000Dgm-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 19:45:47 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #2) id 184Y0G-000DgL-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 19:45:45 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g9O2jbGO014569; Thu, 24 Oct 2002 04:45:37 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g9O2jaZZ014565; Thu, 24 Oct 2002 04:45:36 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 24 Oct 2002 04:45:35 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Bob Halley cc: "Olaf M. Kolkman" , =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= , Subject: Re: DNSSEC wildcard optimization. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Spam-Status: No, hits=-9.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id WAA14768 On 23 Oct 2002, Bob Halley wrote: > Ólafur Guðmundsson writes: > > > 4. RFC1035 wild card algorithm is unclear and needs clarification, > > publishing this protocol change without fixing the specification is not > > prudent, and I encourage the authors on taking on the clarification effort. > > What is unclear? It is not 1034/5 that is unclear, though the 2535 description of handling secure wildcards is unclear. Last time I looked a widely known implementation of a DNS server did not get secure wildcards right. You tell me what is unclear. > Wildcards can be made to work with DNSSEC as it is. Why don't we just > leave features like wildcards that people are already using in, > stop adding more features, and let it deploy? Removing wildcards > from DNSSEC will discourage and delay deployment. Since non-implemented secure wildcards is currently the default, how is it that not implementing secure wildcards will delay or discourage deployment ? Why isn't it implemented by now ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 23 23:45:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15751 for ; Wed, 23 Oct 2002 23:45:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Yi0-000H6t-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 20:30:56 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 184Yhw-000H6B-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 20:30:54 -0700 Received: by shell.nominum.com (Postfix, from userid 1411) id 6C412137F02; Wed, 23 Oct 2002 20:30:52 -0700 (PDT) To: Roy Arends Cc: "Olaf M. Kolkman" , =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= , Subject: Re: DNSSEC wildcard optimization. References: From: Bob Halley Date: 23 Oct 2002 20:30:52 -0700 In-Reply-To: Message-ID: Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-10.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy Arends writes: > > What is unclear? > > It is not 1034/5 that is unclear, though the 2535 description of handling > secure wildcards is unclear. Last time I looked a widely known > implementation of a DNS server did not get secure wildcards right. When I was working on BIND 9, we didn't implement them not because we didn't understand the spec or because the spec was deficient, but because we didn't know how to do an efficient algorithm in the presense of bitstring labels, and didn't have the schedule time to figure that out and cope with the extra validator complexity that wildcards cause. Bitstring labels are gone, and so the "obvious" wildcard proof generation algorithms are now fine. We have implemented the generation and validation of DNSSEC wildcard proof in Nominum's proprietary nameservers. Wildcards have often been a thorn in my side as an implementor; we implmented them because people use them to solve real problems. Adding similar functionality to BIND 9 is just programming; it's not a standards issue. > You tell me what is unclear. I'm not having a problem with the RFCs; it's not my place to guess what other people find unclear or deficient. > Since non-implemented secure wildcards is currently the default, how is it > that not implementing secure wildcards will delay or discourage deployment Because people *use* wildcards for legimate purposes. Telling someone "You can secure your zone, but you'll have to change the way you handle mail because the secure DNS does not support wildcards." is going to present real world operational challenges to people who might otherwise convert. I'm saying: implement wildcards everywhere, stop messing with the specs, and let things deploy. /Bob -- to unsubscribe send a message to namedroppers-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 Oct 24 02:29:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27690 for ; Thu, 24 Oct 2002 02:29:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184bHi-0003yT-00 for namedroppers-data@psg.com; Wed, 23 Oct 2002 23:15:58 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 184bHg-0003uJ-00 for namedroppers@ops.ietf.org; Wed, 23 Oct 2002 23:15:56 -0700 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9O6FHnZ008007; Thu, 24 Oct 2002 08:15:17 +0200 Message-Id: <200210240615.g9O6FHnZ008007@birch.ripe.net> To: David Conrad cc: =?ISO-8859-1?B?02xhZnVyIEd18A==?=mundsson , namedroppers Subject: Re: DNSSEC wildcard optimization. In-reply-to: Your message of Wed, 23 Oct 2002 16:13:56 PDT. References: From: Olaf Kolkman X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Thu, 24 Oct 2002 08:15:17 +0200 X-RIPE-Spam-Status: NONE ; -987 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Conrad writes: * * Modifying the DNSSEC specs in non-backwards compatible ways _yet again_ is a * "BAD" idea. * * Can we please stop? I would personally like to see DNSSEC deployed in my * lifetime. I think that the draft brings considerable optimizations for the common case of zones without wildards. If there would not have been a cut of date I would not have brought it to the table. Either it flies with opt-in/DS or it does not fly at all. DNSSEC should fly, preferably yesterday, but I think this helps interpreting denial of existence of wildcards for both operators and in code. * > Thus if the misunderstanding is corrected and we explain to the few * > application communities that are using wild cards in a legit way * > to push names out of DNS, what the DNS problems are, maybe we can make * > wildcards go away. * * Don't be silly. * * Wildcards are seen as providing useful functionality. Attempts to remove * them, regardless of the validity of the attempt, will get dragged down into * non-terminating IETF politics. * * Given wildcards exist, any attempt to remove them from DNSSEC will simply * mean disincentives for DNSSEC deployment. We do NOT need more disincentives * to deploying DNSSEC. This draft is not about removing wildcards from DNSSEC. It is about making the processing of denial of existence easier, somewhat faster and reduce packet size in the common case. Wildcards should not be removed from the DNS protocol just to make DNSSEC fly. --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 Oct 24 04:40:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29353 for ; Thu, 24 Oct 2002 04:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184dPD-000BPX-00 for namedroppers-data@psg.com; Thu, 24 Oct 2002 01:31:51 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 184dPB-000BP7-00 for namedroppers@ops.ietf.org; Thu, 24 Oct 2002 01:31:50 -0700 Received: from [192.168.1.210] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 79742137F02; Thu, 24 Oct 2002 01:31:47 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 23 Oct 2002 21:51:39 -0700 Subject: Re: DNSSEC wildcard optimization. From: David Conrad To: Roy Arends , Bob Halley Cc: Olaf Kolkman , =?ISO-8859-1?B?02xhZnVyIEd18A==?=mundsson , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-6.6 required=5.0 tests=DATE_IN_PAST_03_06,INVALID_MSGID,IN_REP_TO, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_ENTOURAGE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10/23/02 7:45 PM, "Roy Arends" wrote: > It is not 1034/5 that is unclear, though the 2535 description of handling > secure wildcards is unclear. Last time I looked a widely known > implementation of a DNS server did not get secure wildcards right. There is a difference between getting something wrong because of vagueness with specs and not implementing it. For various reasons, we did not have time to implement secure wildcards in BIND. It wasn't a question of not understanding what to implement. > You tell me what is unclear. I believe Olafur has asserted (and others have indicated agreement) that the specification is unclear, not Bob. Those folks should be the ones to indicate what they found to be unclear. > Since non-implemented secure wildcards is currently the default, In one implementation. > how is it > that not implementing secure wildcards will delay or discourage deployment It is yet again screwing around with the DNSSEC specifications. How does anyone expect any significant deployment or even implementation of specifications if people continue to screw around with those specs, particularly in non-backwards compatible ways? Can we please stop? I'd like to see DNSSEC deployed in my lifetime. > ? Why isn't it implemented by now ? It has been, just not in BIND. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 24 10:16:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09185 for ; Thu, 24 Oct 2002 10:16:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184iSI-00050a-00 for namedroppers-data@psg.com; Thu, 24 Oct 2002 06:55:22 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 184iSG-00050O-00 for namedroppers@ops.ietf.org; Thu, 24 Oct 2002 06:55:20 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA07015; Thu, 24 Oct 2002 09:55:16 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA23038; Thu, 24 Oct 2002 09:55:15 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA27537; Thu, 24 Oct 2002 09:55:14 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA02921; Thu, 24 Oct 2002 09:55:14 -0400 (EDT) To: Olaf Kolkman Cc: David Conrad , =?iso-8859-1?q?=D3lafur_Gu=F0mundsson?= , namedroppers From: Derek Atkins Subject: Re: DNSSEC wildcard optimization. References: <200210240615.g9O6FHnZ008007@birch.ripe.net> Date: 24 Oct 2002 09:55:14 -0400 In-Reply-To: <200210240615.g9O6FHnZ008007@birch.ripe.net> Message-ID: Lines: 78 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-7.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05, TO_BE_REMOVED_REPLY,USER_AGENT,X_OSIRU_OPEN_RELAY version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I happen to agree with Olaf here. The issue with wildcard processing is that in the _NORMAL_ case (i.e. a zone without wildcards) you need to ALWAYS provide not only the proof of non-existence of the QNAME but ALSO proof of non-existence of the wildcard. Indeed, you need to provide both proofs in ALL responses. If we can (quickly, before DS goes out) agree on an optimization for wildcards it would ease the network issues, because in the "normal" case you can just send the proof of non-existence of your QNAME with a flag that says "and there is no wildcard either". If we cannot agree on an optimization, then we are forever required to send multiple NXT/SIG records for all responses, or we must remove wildcard support. -derek Olaf Kolkman writes: > David Conrad writes: > * > * Modifying the DNSSEC specs in non-backwards compatible ways _yet again_ is a > * "BAD" idea. > * > * Can we please stop? I would personally like to see DNSSEC deployed in my > * lifetime. > > > I think that the draft brings considerable optimizations for the > common case of zones without wildards. If there would not have been a > cut of date I would not have brought it to the table. Either it flies > with opt-in/DS or it does not fly at all. > > DNSSEC should fly, preferably yesterday, but I think this helps > interpreting denial of existence of wildcards for both operators and > in code. > > * > Thus if the misunderstanding is corrected and we explain to the few > * > application communities that are using wild cards in a legit way > * > to push names out of DNS, what the DNS problems are, maybe we can make > * > wildcards go away. > * > * Don't be silly. > * > * Wildcards are seen as providing useful functionality. Attempts to remove > * them, regardless of the validity of the attempt, will get dragged down into > * non-terminating IETF politics. > * > * Given wildcards exist, any attempt to remove them from DNSSEC will simply > * mean disincentives for DNSSEC deployment. We do NOT need more disincentives > * to deploying DNSSEC. > > This draft is not about removing wildcards from DNSSEC. It is about > making the processing of denial of existence easier, somewhat faster > and reduce packet size in the common case. > > Wildcards should not be removed from the DNS protocol just to make DNSSEC > fly. > > > --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: -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 24 13:13:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16184 for ; Thu, 24 Oct 2002 13:13:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184lPw-000InM-00 for namedroppers-data@psg.com; Thu, 24 Oct 2002 10:05:08 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 184lPu-000Imo-00 for namedroppers@ops.ietf.org; Thu, 24 Oct 2002 10:05:06 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9OH4xYm038188; Thu, 24 Oct 2002 13:04:59 -0400 (EDT) Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA07247; Thu, 24 Oct 2002 13:04:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> Date: Thu, 24 Oct 2002 12:50:23 -0400 To: Bob Halley , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= From: Edward Lewis Subject: Re: DNSSEC wildcard optimization. Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Status: No, hits=-7.9 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16184 At 15:53 -0700 10/23/02, Bob Halley wrote: >Ólafur Guðmundsson writes: > >> 4. RFC1035 wild card algorithm is unclear and needs clarification, >> publishing this protocol change without fixing the specification is not >> prudent, and I encourage the authors on taking on the clarification effort. > >What is unclear? Perhaps the fact that the algorithm is in RFC 1034. ;) >Some people are confused, certainly. But I find it very hard to >believe that most uses of wildcards are erroneous or unwarranted. Amen. If we can settle on a means to indicate in the NXT whether a span of names is or is not covered by a wildcard, then I see the wildcards in DNSSEC as a trivial problem. During the signing process, the signer knows what exists between an NXT's ownername and the nextname in the NXT RDATA. There are three possibilities floating now: non-existent names that are subdomains of ownername, which cannot ever be matched by a wildcard. unsecured delegations (per the opt-in proposal) which exist but are not secured. (I'll defer a discussion on this implication to below.) non-existent names that are siblings of the ownername, which are eligible for a wildcard match, if one exists. If one does, the signer can determine which applies - so the NXT can indicate definitively yes or definitively no IF there is a wildcard to be expected. The latter case I think is pretty clear - if the wildcard isn't at one label up, there still is a need to prove it's not there before accepting a higher wildcard. As far as unsecured delegations as per opt-in, there's a conflict between signed wildcards and unsecured names that is hanging out there, begging for more analysis and discussion. But, neglecting opt-in, I'm beginning to be ever more convinced that wildcards and dnssec are not a problem. I think it's best to defer the opt-in rathole to a new thread so as to not screw up threaded mail readers on this just yet. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 24 17:00:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23475 for ; Thu, 24 Oct 2002 17:00:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184ovB-0009zO-00 for namedroppers-data@psg.com; Thu, 24 Oct 2002 13:49:37 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 184ov9-0009zA-00 for namedroppers@ops.ietf.org; Thu, 24 Oct 2002 13:49:35 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9OKnWYm049736 for ; Thu, 24 Oct 2002 16:49:32 -0400 (EDT) Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA25826 for ; Thu, 24 Oct 2002 16:49:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> Date: Thu, 24 Oct 2002 16:49:24 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: DNSSEC wildcard optimization. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-9.1 required=5.0 tests=GAPPY_TEXT,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The author of this is obviously a moron. (I bet that got y'alls attention.) At 12:50 -0400 10/24/02, Edward Lewis wrote: > non-existent names that are subdomains of ownername, which cannot > ever be matched by a wildcard. > > unsecured delegations (per the opt-in proposal) which exist but are > not secured. (I'll defer a discussion on this implication to below.) > > non-existent names that are siblings of the ownername, which are > eligible for a wildcard match, if one exists. If one does, the signer > can determine which applies - so the NXT can indicate definitively > yes or definitively no IF there is a wildcard to be expected. After chatting VoPOTS with Olaf, I realized I missed a case - a wild card may apply to just some of the siblings. E.g. looking at a zone with this in it. *.c a.b.c f a.b.c has the following non-existent labels in the span before f: z.a.b.c -- a subdomain blocked from *.c b.b.c -- a sibling of a.b.c that matches *.c d -- a sibling of a.b.c that does not match *.c Although the signer knows whether *, *.c or *.b.c is present and how much of the a.b.c to f span is covered by a wildcard, the signer can't anticipate the query name in advance when calculating a.b.c's NXT RR. There's no algorithmic way to determine from just the query name, owner name, and the so-called WILDC bit over what part of the span a wildcard match applies. Ergo - you can only way "there is definitely no wildcard" or there is "possibly a wildcard." And ergo again, opt-in isn't going to create a special case. Perhaps we should eliminate multi-label zones from DNS. (Just kidding folks.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 05:24:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16728 for ; Fri, 25 Oct 2002 05:24:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1850Tm-000Ho0-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 02:10:06 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 1850Tk-000Hml-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 02:10:04 -0700 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9P99VnZ027796; Fri, 25 Oct 2002 11:09:31 +0200 Message-Id: <200210250909.g9P99VnZ027796@birch.ripe.net> To: namedroppers@ops.ietf.org, dnsop@cafax.se cc: disi@ripe.net Subject: FYI: ISP BGPDNS WG report Date: Fri, 25 Oct 2002 11:09:31 +0200 From: Olaf Kolkman X-RIPE-Spam-Status: NONE ; -989 X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk FYI The following message posted to the RPSEC mailinglist may also be of interest to these groups. http://www1.ietf.org/mail-archive/working-groups/rpsec/current/msg00220.html It contains a copy of the report from one of the sub-groups spawned by the US Government's initiative to examine security of the Internet among other information infrastructures. This sub-group worked on ISP BGP and DNS Security and the report is a decent articulation of the of the issues. I can't take either credit or blame for this document. Nothing new or earth-shattering, I think, but of interest.' --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 Fri Oct 25 07:34:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20588 for ; Fri, 25 Oct 2002 07:34:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1852ee-0004in-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 04:29:28 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 1852ec-0004iZ-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 04:29:26 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19715; Fri, 25 Oct 2002 07:27:06 -0400 (EDT) Message-Id: <200210251127.HAA19715@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-03.txt Date: Fri, 25 Oct 2002 07:27:06 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, M. Larson, D. Massey, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-03.txt Pages : 19 Date : 2002-10-24 The Domain Name System Security Extensions (DNSSEC) provide data origin authentication and data integrity. This document introduces these extensions and describes their capabilities and limitations. The services that the security extensions provide and do not provide are discussed. Lastly, the group of documents that describe the DNS security extensions and their interrelationships is discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-03.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: <2002-10-24141950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24141950.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 08:40:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22870 for ; Fri, 25 Oct 2002 08:40:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1853dP-000Avn-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 05:32:15 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 1853dN-000Auy-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 05:32:13 -0700 Received: from [192.168.1.29] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E8173137F0A; Fri, 25 Oct 2002 05:32:10 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 25 Oct 2002 05:34:08 -0700 Subject: Re: DNSSEC wildcard optimization. From: David Conrad To: Olaf Kolkman Cc: =?ISO-8859-1?B?02xhZnVyIEd18A==?=mundsson , namedroppers Message-ID: In-Reply-To: <200210240615.g9O6FHnZ008007@birch.ripe.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-6.5 required=5.0 tests=INVALID_MSGID,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_ENTOURAGE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf, > I think that the draft brings considerable optimizations for the > common case of zones without wildards. I do not disagree that your draft can provide optimizations. My concern is that the corner cases not addressed in your draft (e.g., ddns) will require additional iterations before we can be confident it doesn't have weird side effects. Should the new DNSSEC wait for those iterations to complete? I'm also worried about _any_ additional complexity within the server -- optimizing tends to add special cases and code shortcuts. DNSSEC is already far too complex, as we all know. Finally, at least with both opt-in and DS, I know of implementations. Has anyone implemented your proposal yet? > This draft is not about removing wildcards from DNSSEC. Right. I was addressing Olafur's comments. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 09:45:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24726 for ; Fri, 25 Oct 2002 09:45:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1854dp-000Hf8-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 06:36:45 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1854dm-000HeP-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 06:36:42 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9PDacYm076019; Fri, 25 Oct 2002 09:36:38 -0400 (EDT) Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA19952; Fri, 25 Oct 2002 09:36:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 25 Oct 2002 09:31:40 -0400 To: David Conrad , Olaf Kolkman From: Edward Lewis Subject: Re: DNSSEC wildcard optimization. Cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:34 -0700 10/25/02, David Conrad wrote: let your = "Olaf" >I do not disagree that your draft can provide optimizations. My concern is >that the corner cases not addressed in your draft (e.g., ddns) will require >additional iterations before we can be confident it doesn't have weird side >effects. Should the new DNSSEC wait for those iterations to complete? I've thought about dynamic update. Whether an NXT RR is generated by a static signer or a dynamic update signer, the environment is the same. (Especially because during a dynamic update process, the zone is temporarily static as the operation is considered atomic.) CNAME's aren't an issue - no matter how it is implemented. The generation of the no wildcard indication is done statically, and not in the motion of a query/response activity. >I'm also worried about _any_ additional complexity within the server -- >optimizing tends to add special cases and code shortcuts. DNSSEC is already >far too complex, as we all know. Without having implemented anything, the complexity rises: 1) In the static signer, having to do a wildcard "search" 2) In the dynamic update signer, the same as above Complexity is argurable in: 1) The server, checks for the no-wildcard indication but may no longer have to perform the wildcard search 2) The resolver, the same as above - but the savings are greater as there's also no need to worry about validating the NXT's proving there's no wildcard. 3) The protocol, the indicator format is an issue to me still, and causes some repercussions that I still think need addressing. But the average message will have to contain fewer records (no NXT to prove the no-wildcard case). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 10:03:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25424 for ; Fri, 25 Oct 2002 10:03:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1854wJ-000K9J-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 06:55:51 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1854wH-000K96-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 06:55:49 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9PDtmYm076625 for ; Fri, 25 Oct 2002 09:55:48 -0400 (EDT) Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA22697 for ; Fri, 25 Oct 2002 09:55:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Fri, 25 Oct 2002 09:55:42 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wildcard optimization - another topic Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.4 required=5.0 tests=OPT_IN,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In the draft the no wildcard/possible wildcard information is encoded into the value of the SIG bit. This mimics the choice in opt-in of using the NXT bit. Two problems - the relationship between the NXT and opt-in is a bit (no pun intended) stronger than the SIG and wildcards. Also, if we do this, we run out of "easily overloaded" bits in the type bit map. The next proposal is to use the type bits for the "bogus" types. I mean, what's the chance you'll see an MB record ever again? Another choice is to create new bit values in the type bit map just for indicating "whatever." There are a few consequences of this. One is that if the bit positions used are low in number (e.g., 49, 50, etc.), then IANA had better be warned to never issue any type codes of that value. (This is true of any number chosen.) If the numbers chosen are higher, like around the metatypes (ANY), then bit 0 has to be turned on - which says the bit map uses an alternate encoding for values over 128. Then there is the option of scraping NXT and replacing it with a new record that has an explicit flags field before the type bit map. Hey - it's an option. It looks like there is a requirement that the NXT has flags, a requirement not known in the old days. The question is: will we honor the requirement, and if so, will we settle for having the flags be intermixed with the type bit map, or do we set aside a separate location for them? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 11:08:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27649 for ; Fri, 25 Oct 2002 11:08:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1855uS-0001LC-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 07:58:00 -0700 Received: from dhcp3253.nanog26.merit.net ([192.35.167.253] helo=roam.psg.com ident=exim) by psg.com with esmtp (Exim 3.36 #2) id 1855uQ-0001L0-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 07:57:58 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 1855uL-000HfS-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 07:57:53 -0700 Mime-Version: 1.0 Message-Id: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Date: Fri, 25 Oct 2002 10:37:12 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: KEY RR Key Signing (KS) Flag Cc: Edward Lewis X-Spam-Status: No, hits=-5.1 required=5.0 tests=RESENT_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In the draft there is mention of requiring the parent to maintain a history of KEY RR's used by children to generate DS RR's. This is done to guard against successful replay attacks that might reset the DS RR set to an older version. Requiring the parent to maintain a history will likely lead to an unstable situation. How long a history may need to exist is hard to determine, and the storage needed for this is somewhat linear to the length of time in the history. (Actually, sublinear initially as the number of signed children will grow - considering that today, the number of DS'd children is roughly 0.00.) I would suggest that moving the discussion of automating rollover be removed from this draft anyway, so I won't comment further on this. (Just because the KS "enables" this doesn't mean it is responsible for proper rollover technique.) The rest are all editorial comments. Throughout the doc: The terms "key-signing key" and "zone-signing key" should be hyphenated. This is from a local "Mr. Language Person." Section 1: "Key Signing Key flag" -> Key-Signing Key (KSK) flag Section 2: "The bit 15th bit" -> lose the first bit. Section 4: "Using the flag a key rollover can be automated." -> The flag enables key rollover to be automated. Also, note that "if the bit is changed, the cryptographic key data in the RDATA assumes a new DNS indentity because the bit is used in calculating the footprint." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 11:08:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27667 for ; Fri, 25 Oct 2002 11:08:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1855tE-0001Fx-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 07:56:44 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1855tB-0001FY-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 07:56:42 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9PEufYm079550 for ; Fri, 25 Oct 2002 10:56:41 -0400 (EDT) Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA06657; Fri, 25 Oct 2002 10:56:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Fri, 25 Oct 2002 10:45:16 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Handling of Unknown DNS RR Types Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.0 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In section 4 and section 7 the subject of domain name treatment in the RDATA pops up. In the section 4 the context is message compression, in section 7 the context is DNSSEC processing. The two paragraphs treat the list of considered types differently. In Section 4, there's a reference to 1035-defined types plus a list of newer ones. In section 7, the entire list is explicit. The lists aren't the same - e.g., A6 and DNAME are in section 7 and not 4. (Perhaps for good reason.) HINFO appears in the section 7 list twice. Is there a need to mention which types are class agnostic and which are class "IN" only? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 11:29:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28404 for ; Fri, 25 Oct 2002 11:29:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1856H2-0004DF-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 08:21:20 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1856Gv-0004Bp-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 08:21:13 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9PFLDYm080666 for ; Fri, 25 Oct 2002 11:21:13 -0400 (EDT) Received: from [192.149.252.228] ([192.149.252.228]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA11115 for ; Fri, 25 Oct 2002 11:21:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: Date: Fri, 25 Oct 2002 11:11:57 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Limiting the Scope of the KEY RR Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.0 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Editorial comments: "out" appears under the title. Sect 2.1 "another type data" - "of" is missing. Point 3: "They are authenticated according to different rules." Not true - but "they play different roles in authentication." I.e., as application keys and zone keys can be in the same set, and the set is authenticated together, there is no difference in the way an application key and a zone key are authenticated. The difference is that the application key is not authorized to authenticate anything else - specifically a key set containing a zone key. Explanation of point 2: "PGP key" is a misnomer. PGP certificates hold RSA, DSA keys (and probably others). Explanation of point 6: In key@parent, parent would be responsible to hold apex application keys of child. This is missed - that a fault at the parent could damage applications (even if there is no damage to DNS). Last parts of Sect 3: The term KEY is used. Probably should be consistent and say KEY RR, or use the lower case key to refer to whats in the RDATA. Sect 6 uses "KEY record" -> KEY RR. Sect 7, IANA. Does not mention the changes to the flag bits. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 11:46:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29000 for ; Fri, 25 Oct 2002 11:46:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1856YS-0006Fv-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 08:39:20 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1856YP-0006FI-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 08:39:17 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9PFdGYm081445 for ; Fri, 25 Oct 2002 11:39:16 -0400 (EDT) Received: from [192.149.252.228] ([192.149.252.228]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA14563; Fri, 25 Oct 2002 11:39:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: Date: Fri, 25 Oct 2002 11:39:13 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Delegation Signer Resource Record Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.0 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Section 1 - isn't there an NLnet Labs report on SIG/KEY@parent? "Storing the KEY RRset at the parent simplifies the communication." to Storing the KEY RR set at the parent was thought to simplify the communication. ^ ^^^^^^^^^^^^^^^ "Given these (and what other?) reasons, SIG/KEY@parent isn't any better than SIG/KEY@child." I'm beginning to think that the last paragraph in 1 isn't really needed. End of sect 2.1 Requiring two sig validations is no different than what happens in lateral signing. The DS doesn't require two sig validations in all cases - if the DS points to the ZSK, there's no KSK, no need to check the self-signed key. Sect 2.2. What if the response is an answer and not a referral? (Ie the server is authoritative for parent and child.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 12:43:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01333 for ; Fri, 25 Oct 2002 12:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1857MK-000D32-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 09:30:52 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 1857MI-000D2o-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 09:30:50 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id ED7E637A1C9 for ; Fri, 25 Oct 2002 16:30:49 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEC wildcard optimization. In-Reply-To: Message from David Conrad of "Fri, 25 Oct 2002 05:34:08 MST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 25 Oct 2002 16:30:49 +0000 Message-Id: <20021025163049.ED7E637A1C9@as.vix.com> X-Spam-Status: No, hits=-5.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_LOCALPART_EQ_REAL version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... Should the new DNSSEC wait for those iterations to complete? Why not? It waits for every other good idea anybody thinks of at the last possible second before "deployment". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 12:56:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02009 for ; Fri, 25 Oct 2002 12:56:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1857gX-000G4E-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 09:51:45 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 1857gV-000Fxn-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 09:51:43 -0700 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9PGp6nZ006713; Fri, 25 Oct 2002 18:51:06 +0200 Message-Id: <200210251651.g9PGp6nZ006713@birch.ripe.net> To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: KEY RR Key Signing (KS) Flag In-reply-to: Your message of Fri, 25 Oct 2002 10:37:12 EDT. References: From: Olaf Kolkman X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Fri, 25 Oct 2002 18:51:06 +0200 X-RIPE-Spam-Status: NONE ; -996 X-Spam-Status: No, hits=-5.4 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_08_13 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for your comments, one question back though Edward Lewis writes: * In the draft there is mention of requiring the parent to maintain a * history of KEY RR's used by children to generate DS RR's. This is * done to guard against successful replay attacks that might reset the * DS RR set to an older version. * * Requiring the parent to maintain a history will likely lead to an * unstable situation. How long a history may need to exist is hard to * determine, and the storage needed for this is somewhat linear to the * length of time in the history. (Actually, sublinear initially as the * number of signed children will grow - considering that today, the * number of DS'd children is roughly 0.00.) * * I would suggest that moving the discussion of automating rollover be * removed from this draft anyway, so I won't comment further on this. * (Just because the KS "enables" this doesn't mean it is responsible * for proper rollover technique.) I see what you mean... but.. In the security section I've added the reference to the 'old key' to avoid people making mistakes, i.e. to document an attack vector on (mis)use of the keyflag. I think that sort of information belongs in the security section. Maintaining history is a way to cope with that attack vector. Note that you only have to maintain history of the key most recently used (the key which was in the keyset to authenticate the new key with). I refer to that key as the key used 'previously', maybe there is a better word that does not refer to all keys that where used in the past, suggestions from "Mr Language Person" are welcome :-). * The rest are all editorial comments. Thanks... --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 Fri Oct 25 13:59:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04804 for ; Fri, 25 Oct 2002 13:59:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1858XP-000No9-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 10:46:23 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1858XN-000Nnw-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 10:46:21 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9PHkKYm087757; Fri, 25 Oct 2002 13:46:20 -0400 (EDT) Received: from [192.149.252.228] ([192.149.252.228]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA12491; Fri, 25 Oct 2002 13:46:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200210251651.g9PGp6nZ006713@birch.ripe.net> References: <200210251651.g9PGp6nZ006713@birch.ripe.net> Date: Fri, 25 Oct 2002 13:46:17 -0400 To: Olaf Kolkman , Edward Lewis From: Edward Lewis Subject: Re: KEY RR Key Signing (KS) Flag Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:51 +0200 10/25/02, Olaf Kolkman wrote: >I see what you mean... but.. There's that word "but" again... >In the security section I've added the reference to the 'old key' to >avoid people making mistakes, i.e. to document an attack vector on >(mis)use of the keyflag. I think that sort of information belongs in >the security section. > >Maintaining history is a way to cope with that attack vector. Note >that you only have to maintain history of the key most recently used >(the key which was in the keyset to authenticate the new key with). I >refer to that key as the key used 'previously', maybe there is a >better word that does not refer to all keys that where used in the >past, suggestions from "Mr Language Person" are welcome :-). There are three ways in which a registry may use a copy of a KEY RR (that has been used to make a DS RR). One is to regenerate the DS RR. I'd stipulate that this isn't necessary - you can re-sign the previously produced DS RR with the new key. If the registry maintains and backups of the current DS RR's, there is no need to have the KEY RR's hang around. Two is to validate the submission of a new KEY RR set for DS RR-ization. Whether this is necessary is dependent on registry policy - if the update requests are authenticated via a non-DNS method, the KEY RR is needed, what is needed is (most likely) the certificate holding the public key of the registrant (or registar to be more general). Three is to detect any "looping" through the keys. This implies a history of more than one KEY RR generation, which is something you'd want to avoid having in a distributed system. It is also conceivable that the registrant meant to reuse an old key (as part of some bad advice from their security team or going back to an uncompromised key). For the third case, I'd place the impetus on the client to make sure the parent has the right DS RR set for the client. If we can maintain that all flows initiate from the child upwards instead of having the parent initiating anything, the system will be more modular and scaleable. I.e., the child notifies the parent that there is a new keyset, parent gets it. The child verifies that the parent has processed the keyset and (perhaps) alters the keyset and notifies the parent again. So, if there's a problem, the child notices by verifying what the parent has, senses an error and notifies the parent. That's the paradigm I think will be the most stable, even if it seems that the parent isn't doing much hand holding. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 14:34:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05924 for ; Fri, 25 Oct 2002 14:34:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1859AV-0003Cc-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 11:26:47 -0700 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #2) id 1859AR-0003CL-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 11:26:43 -0700 Received: from guam.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id g9PIQft22919; Fri, 25 Oct 2002 11:26:41 -0700 (PDT) Received: (from gson@localhost) by guam.araneus.fi (8.11.6/8.11.6) id g9PIOAV03759; Fri, 25 Oct 2002 11:24:10 -0700 (PDT) Date: Fri, 25 Oct 2002 11:24:10 -0700 (PDT) Message-Id: <200210251824.g9PIOAV03759@guam.araneus.fi> To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Handling of Unknown DNS RR Types In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-12.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > In section 4 and section 7 the subject of domain name treatment in > the RDATA pops up. In the section 4 the context is message > compression, in section 7 the context is DNSSEC processing. > > The two paragraphs treat the list of considered types differently. > In Section 4, there's a reference to 1035-defined types plus a list > of newer ones. In section 7, the entire list is explicit. The lists > aren't the same - e.g., A6 and DNAME are in section 7 and not 4. > (Perhaps for good reason.) Yes, this is deliberate and stems from the fact that the interoperability issues of compression and DNSSEC canonicalization are fundamentally different. With compression, you can take a "be conservative in what you send and liberal in what you receive" approach, since there is no harm in the receiving party supporting decompression of more record types than the sending party will compress. The draft takes advantage of this to maximize interoperability, by allowing compression only of record types that existing servers are known to be able to decompress, and by recommending that servers be capable of decompressing all types that existing servers are known to compress (whether that compression is considered correct or not). In DNSSEC processing, on the other hand, the two parties must agree exactly on which types are subject to downcasing and which are not; anything else will cause signature validation to fail. This means there has to be a flag day, and to maximize interoperability, that flag day should be such that the downcasing rules for RR types that have already been deployed do not change. Therefore, the draft makes the set of RR types subject to downcasing as large as possible given the state of standardization at the time of the draft's initial publication, using RFC2931 as the flag day. > HINFO appears in the section 7 list twice. That's a typo - thanks for pointing it out. > Is there a need to mention which types are class agnostic and which > are class "IN" only? I don't think the unknown-rrs draft is the right place to do that. This is already part of the specification of each individual RR type, which an implementor must already be familiar with to correctly implement the type, and duplicating this information in the unknown-rrs draft would introduce a risk of inconsistency. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 14:45:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06347 for ; Fri, 25 Oct 2002 14:45:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1859LM-0004ky-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 11:38:00 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #2) id 1859LK-0004kD-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 11:37:59 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 5F52152A7; Fri, 25 Oct 2002 20:37:57 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 701181DF6; Fri, 25 Oct 2002 20:37:55 +0200 (MEST) Date: Fri, 25 Oct 2002 20:37:08 +0200 (CEST) From: Jakob Schlyter To: Edward Lewis Cc: Olaf Kolkman , Subject: Re: KEY RR Key Signing (KS) Flag In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Edward Lewis wrote: > One is to regenerate the DS RR. I'd stipulate that this isn't > necessary - you can re-sign the previously produced DS RR with the > new key. If the registry maintains and backups of the current DS > RR's, there is no need to have the KEY RR's hang around. the registry might want to keep the KEYs in the unlikely event someone decides we should change the digest algorithm. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 15:07:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07031 for ; Fri, 25 Oct 2002 15:07:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1859fb-0008Bp-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 11:58:55 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 1859fZ-0008Bc-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 11:58:53 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9PIwnYm092034; Fri, 25 Oct 2002 14:58:49 -0400 (EDT) Received: from [192.149.252.228] ([192.149.252.228]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA28276; Fri, 25 Oct 2002 14:58:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: References: Date: Fri, 25 Oct 2002 14:58:46 -0400 To: Jakob Schlyter , Edward Lewis From: Edward Lewis Subject: Re: KEY RR Key Signing (KS) Flag Cc: Olaf Kolkman , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:37 +0200 10/25/02, Jakob Schlyter wrote: >the registry might want to keep the KEYs in the unlikely event someone >decides we should change the digest algorithm. In that case, the DS draft should make such a suggestion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 16:20:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10120 for ; Fri, 25 Oct 2002 16:20:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185AmN-000IJu-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 13:09:59 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 185AmL-000IJh-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 13:09:57 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9PK9pYm096416 for ; Fri, 25 Oct 2002 16:09:51 -0400 (EDT) Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA17599; Fri, 25 Oct 2002 16:09:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Fri, 25 Oct 2002 16:09:47 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: ahh, the dreaded opt-in discussion again Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.4 required=5.0 tests=OPT_IN,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sooner or later, it has to come to this, sigh. (Let's see how many spam filters reject a message about opt-in.) Last week I had a discussion with David Blacka about opt-in. During the discussion the following observation was made: In an opt-in zone, a signed wildcard is vulnerable. There is a conflict between domains that are opt-out and a signed wildcard. Of course, the opt-out domains are vulnerable to anything, but that is no different that today. Signed wildcards, which are supposed to be protected can be made to appear to not apply. E.g., Let's say I have the following names in my zone: * -- signed (synonymous with opt-in) dele-a -- signed dele-b -- unsigned (eg opt-out) dele-d -- signed You will notice that there is no dele-c, that name would match the wildcard. If QNAME=dele-c, you should see an answer: dele-c ANSWER="*" dele-c SIG (ANSWER) dele-a NXT dele-d with opt-out names dele-a SIG (NXT) But you could see the following illegal answer: dele-c ANSWER=bogus match dele-a NXT dele-d with opt-out names dele-a SIG (NXT) Of course, if QNAME=dele-b, I should get: dele-b ANSWER=dele-b's data dele-a NXT dele-d with opt-out names dele-a SIG (NXT) but I could get this illicit answer: dele-b ANSWER="*" dele-b SIG (ANSWER) dele-a NXT dele-d with opt-out names dele-a SIG (NXT) Of course, dele-b is vulnerable to attack because it is unsigned, but in the latter case, it looks like the answer is signed. The problem lies in that the explicit presence of a name trumps whether a name is opt-in. Another part of the problem is that DNSSEC signatures do not cover the substitution of the QNAME in the wildcard match in the ownername. It is a simple replay attack to take an existing copy of a wildcard expansion and throw in the latest QNAME and reply with that. Debate: do we just live with this because "who in their right mind would use BOTH wildcards AND opt-in in the SAME zone?" Or do we try to fix this? Or do we kill opt-in? Later on, we had a long discussion on whether this means that there's never a reason to try and prove the nonexistence of wildcards in NXDOMAIN responses. Hey, what's the value of proving the wildcard doesn't exist if it's been undermined anyway? Another observation made was that opt-in will only work if it is restricted to delegations. This is related to the presence of a wildcard. If nondelegations can be opted out, then we could have an opt-out wildcard that itself isn't a delegation. (Opt out wildcard delegations are legal but quite odd. There's little reason to worry about them.) In this case, all NXT's in the scope of the wildcard have to be marked as opt-out capable NXT's. (Because the wildcard makes all possible domains in the scope of the wildcard present. If there were *.com, then there'd never be an NXDOMAIN from .com.) (I think I'm missing a part of the argument here. Perhaps someone I spoke to can chime in, or remind me privately. I don't want to hold this up anymore than I have.) On to the more immediate draft... Another observation is that when a query is answered, there are three outcomes: an answer, a signed NXT denial, or a traditional no answer. Now, an answer can be signed (opt-in) or not, but in either case it's an answer. The reason I'm mentioning this is that I'm trying to find if there's some patter to opt-in that might make it easy to identify corner cases. (The three way pattern also appeared in the kinds of delegations in an opt-in zone - secured, unsecured, and opt-out. The middle one has no DS RR but has an NXT RR.) Nit: In the definition for delegation - a delegation in a response isn't always a referral. That's a definition thing, I can have delegation information in the answer section (QTYPE="any", as in dig @a.gtld arin.net any). Section 3.1.3: "For both non-existent name (NXDOMAIN) responses and Opt-In insecure delegation responses, servers MUST NOT return negative wildcard proof records when the query name (qname) is covered by an Opt-In tagged NXT record." That sentence is a problem. Besides a MUST->SHOULD change, I'd rearrange it to this: For non-existent name (NXDOMAIN) responses when the query name (qname) is covered by an Opt-In tagged NXT record, servers SHOULD NOT return negative wildcard proof records. (This harks back to the undermined signed wildcards.) For Opt-In insecure delegation responses, there shouldn't be a need to even consider any wildcard proofs. I'm assuming that the response is positive. Section 3.2.4.: sending a non-existent name (NXDOMAIN) response where the covering NXT is tagged as Opt-In, unless the NXT record's owner name equals the qname. The "unless" part can be dropped. If you are sending NXDOMAIN, qname cannot equal any owner name. If server policy is to trust what's on it's disk, is it allowed to set AD (as according to the AD bit draft)? Personally, I'd rather see the AD bit be twisted to point to the presence of OPT records detailing the status of RR sets in the message - the alleged SMB proposal. Note: Maybe I have the proposal wrong, the only way I've heard of it is through "the telephone game." Opt-in is beginning to seem more like a Quality of Service of DNS. QOS for bandwidth has problems - as Randy Bush said at a DARPA PI meeting panel last January, QoS means dropping packets in favor of other packets. The problem is that dropping packets is not what providers are there for. (I may have part of this wrong, the essence is that QoS in bandwidth services runs counter to the aim of the service.) There have been attempts in the past to achieve in DNSSEC what opt-in is trying to do. Experimental zones were around for a while, but became problematic. Being able to change signing keys - even converting to a NULL key - was around for a while. Each time we've tried this before, it didn't work out because we couldn't make the verification process simple enough. However, it would be wrong to say that the previous failed attempts to have partially signed zones means that opt-in is doomed. A lot of DNSSEC as defined back then has been rewritten having undergone wider review. I'll refrain typing in the ascii art of the opt-in decision tree. I don't think that it would as helpful now, and it's not worth the time yet... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 17:11:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12129 for ; Fri, 25 Oct 2002 17:11:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185Bcc-000LlR-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 14:03:58 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 185BcZ-000LlC-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 14:03:55 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA28094; Fri, 25 Oct 2002 17:03:54 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA09253; Fri, 25 Oct 2002 17:03:54 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA16357; Fri, 25 Oct 2002 16:58:34 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA06336; Fri, 25 Oct 2002 16:58:34 -0400 (EDT) To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: ahh, the dreaded opt-in discussion again References: Date: 25 Oct 2002 16:58:34 -0400 In-Reply-To: Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-10.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: This is true. Roy and I were looking at this problem in Yokohama. I don't have a good suggestion for a way around this. I think the opt-in proponents would say "the zone administrator may shoot themselves in the foot if they wish, so they should be educated about the risks of using opt-in and wildcards." > Another observation made was that opt-in will only work if it is > restricted to delegations. This is related to the presence of a > wildcard. Luckily we agreed long ago to make this restriction. :) -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 17:34:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12962 for ; Fri, 25 Oct 2002 17:34:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185Byc-000MzD-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 14:26:42 -0700 Received: from bulkregister-ldap.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #2) id 185ByZ-000Mz1-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 14:26:40 -0700 Received: from pinion.admin.cto.netsol.com (h140.s251.netsol.com [216.168.251.140]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Fri, 25 Oct 2002 17:26:38 -0400 Content-Type: text/plain; charset="iso-8859-1" From: David Blacka Organization: Verisign, Inc. To: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: ahh, the dreaded opt-in discussion again Date: Fri, 25 Oct 2002 17:26:37 -0400 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <200210251726.37527.davidb@verisignlabs.com> X-Spam-Status: No, hits=-8.9 required=5.0 tests=IN_REP_TO,NOSPAM_INC,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12962 On Friday 25 October 2002 04:09 pm, Edward Lewis wrote: > Sooner or later, it has to come to this, sigh. > > (Let's see how many spam filters reject a message about opt-in.) > > Last week I had a discussion with David Blacka about opt-in. During > the discussion the following observation was made: > > In an opt-in zone, a signed wildcard is vulnerable. There is a > conflict between domains that are opt-out and a signed wildcard. Of > course, the opt-out domains are vulnerable to anything, but that is > no different that today. Signed wildcards, which are supposed to be > protected can be made to appear to not apply. > Debate: do we just live with this because "who in their right mind > would use BOTH wildcards AND opt-in in the SAME zone?" Or do we try > to fix this? Or do we kill opt-in? I don't think there is a problem with using opt-in and wildcards in the same zone. If using opt-in is acceptable, then the fact that wildcards could be spoofed away should not bother you. This is a natural consequence of opt-in allowing attackers to insert, modify, or delete insecure names within the opt-in span. (If an attacker inserts an insecure name, then it blocks the wildcard. If the attacker removes an insecure name, then the wildcard will look ok.) If you *depend* on the wildcard not being able to be spoofed away, don't use opt-in. But there are probably many uses of wildcards that don't require that level of security. Actually, I can't think of any uses that would require this level of security, but I have a hard time thinking up real uses for wildcards period. Ed, the problem you are having is a human perception problem, not a protocol problem. Because the wildcard record has a signature record, you as a DNSSEC research have an expectation that it can't be spoofed away. But software implementing opt-in wouldn't have that expectation. > Later on, we had a long discussion on whether this means that there's > never a reason to try and prove the nonexistence of wildcards in > NXDOMAIN responses. Hey, what's the value of proving the wildcard > doesn't exist if it's been undermined anyway? > > Another observation made was that opt-in will only work if it is > restricted to delegations. This is related to the presence of a > wildcard. I'm not positive that this is true, but it doesn't matter. The proposal on the table is delegation only, so why burn brain cycles thinking about non-delegation-only opt-in? > On to the more immediate draft... > > Another observation is that when a query is answered, there are three > outcomes: an answer, a signed NXT denial, or a traditional no answer. > Now, an answer can be signed (opt-in) or not, but in either case it's > an answer. The reason I'm mentioning this is that I'm trying to find > if there's some patter to opt-in that might make it easy to identify > corner cases. (The three way pattern also appeared in the kinds of > delegations in an opt-in zone - secured, unsecured, and opt-out. The > middle one has no DS RR but has an NXT RR.) > > Nit: In the definition for delegation - a delegation in a response > isn't always a referral. That's a definition thing, I can have > delegation information in the answer section (QTYPE="any", as in dig > @a.gtld arin.net any). Sure. I buy that. How about that a delegation in a response *may* be called a referral? or is sometimes called a referral? > Section 3.1.3: "For both non-existent name (NXDOMAIN) > responses and Opt-In insecure delegation responses, servers MUST NOT > return negative wildcard proof records when the query name (qname) is > covered by an Opt-In tagged NXT record." > > That sentence is a problem. Besides a MUST->SHOULD change, I'd > rearrange it to this: > > For non-existent name (NXDOMAIN) responses when the query name > (qname) is covered by an Opt-In tagged NXT record, servers SHOULD NOT > return negative wildcard proof records. (This harks back to the > undermined signed wildcards.) Ok. > For Opt-In insecure delegation responses, there shouldn't be a need > to even consider any wildcard proofs. I'm assuming that the response > is positive. > > Section 3.2.4.: > sending a non-existent name (NXDOMAIN) response where the covering > NXT is tagged as Opt-In, unless the NXT record's owner name equals > the qname. > > The "unless" part can be dropped. If you are sending NXDOMAIN, qname > cannot equal any owner name. Good point. > Opt-in is beginning to seem more like a Quality of Service of DNS. > QOS for bandwidth has problems - as Randy Bush said at a DARPA PI > meeting panel last January, QoS means dropping packets in favor of > other packets. The problem is that dropping packets is not what > providers are there for. (I may have part of this wrong, the essence > is that QoS in bandwidth services runs counter to the aim of the > service.) I don't think this analogy works. Denial of existence of non-existant names (which is essentially what you give up with opt-in) is not exactly DNSSEC's core mission. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 18:13:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13700 for ; Fri, 25 Oct 2002 18:13:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185CWe-000Opa-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 15:01:52 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 185CWc-000OpC-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 15:01:50 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 682D537A1C4 for ; Fri, 25 Oct 2002 22:01:46 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: ahh, the dreaded opt-in discussion again In-Reply-To: Message from David Blacka of "Fri, 25 Oct 2002 17:26:37 -0400." <200210251726.37527.davidb@verisignlabs.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 25 Oct 2002 22:01:46 +0000 Message-Id: <20021025220146.682D537A1C4@as.vix.com> X-Spam-Status: No, hits=-3.9 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Opt-in is beginning to seem more like a Quality of Service of DNS. ... > > I don't think this analogy works. Denial of existence of non-existant > names (which is essentially what you give up with opt-in) is not > exactly DNSSEC's core mission. It's not (yet?) possible to say what is or is not DNSSEC's "core mission." In other words, there are likely to be folks who need secure NXDOMAIN to help detect spoofing in other applications or layers, and to them, DNSSEC without secure denial of existence would add no value, and so they might claim secure NXDOMAIN as being exactly DNSSEC's core mission. Until and unless we have some kind of consensus around some kind of threat model and applicability statement and mission statement, DNSSEC's "core mission" is whatever people think it is or want it to be. In that light, it's amazing that we're stalled so far from where we began. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Oct 25 19:59:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16049 for ; Fri, 25 Oct 2002 19:59:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185EFK-0003p6-00 for namedroppers-data@psg.com; Fri, 25 Oct 2002 16:52:06 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #2) id 185EFH-0003oQ-00 for namedroppers@ops.ietf.org; Fri, 25 Oct 2002 16:52:03 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EB67B18E8 for ; Fri, 25 Oct 2002 19:51:59 -0400 (EDT) Date: Fri, 25 Oct 2002 19:51:59 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: ahh, the dreaded opt-in discussion again In-Reply-To: <20021025220146.682D537A1C4@as.vix.com> References: <200210251726.37527.davidb@verisignlabs.com> <20021025220146.682D537A1C4@as.vix.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021025235200.EB67B18E8@thrintun.hactrn.net> X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I hope to get an updated version of draft-ietf-dnsext-dns-threats out next week. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 27 14:11:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08539 for ; Sun, 27 Oct 2002 14:11:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185sVP-000J3c-00 for namedroppers-data@psg.com; Sun, 27 Oct 2002 10:51:23 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 185sVN-000J3O-00 for namedroppers@ops.ietf.org; Sun, 27 Oct 2002 10:51:21 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9RIpKYm081477; Sun, 27 Oct 2002 13:51:20 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA20655; Sun, 27 Oct 2002 13:51:19 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200210251726.37527.davidb@verisignlabs.com> References: <200210251726.37527.davidb@verisignlabs.com> Date: Sun, 27 Oct 2002 13:19:39 -0500 To: David Blacka , Edward Lewis , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: ahh, the dreaded opt-in discussion again Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:26 -0400 10/25/02, David Blacka wrote: >Ed, the problem you are having is a human perception problem, not a protocol >problem. Because the wildcard record has a signature record, you as a DNSSEC >research have an expectation that it can't be spoofed away. But software >implementing opt-in wouldn't have that expectation. Let's not get personal. I just stated the observation that (goals of a) signed wildcards and (implications of) opt-in conflict. I don't think I was drawing any conclusions, I certainly didn't intend to do so in the message. >I'm not positive that this is true, but it doesn't matter. The proposal on >the table is delegation only, so why burn brain cycles thinking about >non-delegation-only opt-in? To make sure we are making the right engineering decisions, and that the process is properly recorded for posterity. >Sure. I buy that. How about that a delegation in a response *may* be called >a referral? or is sometimes called a referral? I'm not sure why this is significant. (What is meant by "a delegation in a response?" The NS RRset?) If you are trying to define a referral message, then just do that - a response with no answer records, and NS RRset (plus DNSSEC records) in the authority. (Minimum definition - not accounting for glue in additional.) >> Opt-in is beginning to seem more like a Quality of Service of DNS. > >I don't think this analogy works. Denial of existence of non-existant names >(which is essentially what you give up with opt-in) is not exactly DNSSEC's >core mission. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Oct 27 16:11:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09844 for ; Sun, 27 Oct 2002 16:11:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185uZQ-0000tl-00 for namedroppers-data@psg.com; Sun, 27 Oct 2002 13:03:40 -0800 Received: from bulkregister-ldap.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #2) id 185uZO-0000nL-00 for namedroppers@ops.ietf.org; Sun, 27 Oct 2002 13:03:38 -0800 Received: from verisignlabs.com (piston.dyn.verisignlabs.com [68.48.27.14]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by cliffie.verisignlabs.com with esmtp; Sun, 27 Oct 2002 16:03:06 -0500 Date: Sun, 27 Oct 2002 16:03:05 -0500 Subject: Re: ahh, the dreaded opt-in discussion again Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: namedroppers@ops.ietf.org To: Edward Lewis From: David Blacka In-Reply-To: Message-Id: <7C97CE36-E9EF-11D6-9B47-000393A3322E@verisignlabs.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, October 27, 2002, at 01:19 PM, Edward Lewis wrote: > Let's not get personal. I just stated the observation that (goals of > a) signed wildcards and (implications of) opt-in conflict. I don't > think I was drawing any conclusions, I certainly didn't intend to do > so in the message. I apologize. My only point was that this conflict is not a protocol-level ambiguity. >> I'm not positive that this is true, but it doesn't matter. The >> proposal on >> the table is delegation only, so why burn brain cycles thinking about >> non-delegation-only opt-in? > > To make sure we are making the right engineering decisions, and that > the process is properly recorded for posterity. I'm not sure where you are going with this. >> Sure. I buy that. How about that a delegation in a response *may* >> be called >> a referral? or is sometimes called a referral? > > I'm not sure why this is significant. (What is meant by "a delegation > in a response?" The NS RRset?) It isn't significant. From the draft: delegation: refers to a NS RRset with a name different from the current zone apex (non-zone-apex), signifying a delegation to a subzone. So, yes, it is the NS RRset. > If you are trying to define a referral message, then just do that - a > response with no answer records, and NS RRset (plus DNSSEC records) in > the authority. (Minimum definition - not accounting for glue in > additional.) The only reason to link delegation to referral is so that the document may refer to them interchangeably. The whole reference to "referral" could be removed, since it is probably generally understood what one is. Or the a more explicit definition could be used, like the one you suggest. Whichever is clearer. So which? -- 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 Sun Oct 27 16:52:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10264 for ; Sun, 27 Oct 2002 16:52:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185vDH-0003O4-00 for namedroppers-data@psg.com; Sun, 27 Oct 2002 13:44:51 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 185vDG-0003Ns-00 for namedroppers@ops.ietf.org; Sun, 27 Oct 2002 13:44:50 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9RLinYm086580; Sun, 27 Oct 2002 16:44:49 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA13534; Sun, 27 Oct 2002 16:44:47 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <7C97CE36-E9EF-11D6-9B47-000393A3322E@verisignlabs.com> References: <7C97CE36-E9EF-11D6-9B47-000393A3322E@verisignlabs.com> Date: Sun, 27 Oct 2002 13:43:59 -0800 To: David Blacka , Edward Lewis From: Edward Lewis Subject: Re: ahh, the dreaded opt-in discussion again Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.7 required=5.0 tests=IN_REP_TO,OPT_IN,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:03 -0500 10/27/02, David Blacka wrote: >... this conflict is not a protocol-level ambiguity. Yeah, it's clearly an aspect of the proposal, not an issue in it. But this aspect may make some people uncomfortable with the proposal. I'm not insinuating that I'm uncomfortable with this aspect. Just making the fact that the conflict between signed wildcards and opt-in a little bit more obvious to those that might have a strong opinion. >I'm not sure where you are going with this. E.g., a lot of times we go over the same ideas again and again. (Deferred dynamic delete, to pick an example not related to opt-in.) It's good to allow the next generation of proposers to see why previous attempts failed. >The only reason to link delegation to referral is so that the document may >refer to them interchangeably. The whole reference to "referral" could be >removed, since it is probably generally understood what one is. Or the a more >explicit definition could be used, like the one you suggest. Whichever is >clearer. So which? Referrals and delegations are two very different things, so I would discourage interchanging them. A referral is an interpretation of a response message. A delegation is an administrative boundary in DNS, with that term overloaded to mean the RR sets at a domain name that is a boundary. So, if you can avoid the use of the two interchangably, that's good, and hence there's no need to include the definition. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 28 09:44:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11640 for ; Mon, 28 Oct 2002 09:44:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Avv-000CSS-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 06:31:59 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 186Avs-000COb-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 06:31:57 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id g9SEVPnZ017777 for ; Mon, 28 Oct 2002 15:31:25 +0100 Date: Mon, 28 Oct 2002 15:31:25 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DS and cache transparency. Message-Id: <20021028153125.7823066f.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: NONE ; -991 X-Spam-Status: No, hits=-2.2 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I wonder if the discussion on DS and cache transparency ever was concluded (and what the conclusion is). The problem is that with DS a non-DNSSEC aware cache may try to query the child zone for a DS RR. This sets architectural constraints for deployment of DNSSEC i.e. DNSSEC aware servers throughout the line of sight from resolver to authoritative server. One of the proposed solutions to solve this was by performing some label-magic so that the parent would be authoritative for the data. e.g. by including a NULL byte in the label or by using more comprehensible underscores. My question is did we ever consciously decide to live with the architectural constraints or is there still work to do on defining the label magic? --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-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 Oct 28 12:30:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19903 for ; Mon, 28 Oct 2002 12:30:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186DbR-000M2y-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 09:23:01 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #2) id 186DbH-000M2k-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 09:22:51 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1B39D18E3 for ; Mon, 28 Oct 2002 12:22:30 -0500 (EST) Date: Mon, 28 Oct 2002 12:22:30 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DS and cache transparency. In-Reply-To: <20021028153125.7823066f.olaf@ripe.net> References: <20021028153125.7823066f.olaf@ripe.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021028172230.1B39D18E3@thrintun.hactrn.net> X-Spam-Status: No, hits=-9.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 28 Oct 2002 15:31:25 +0100, Olaf Kolkman wrote: > > My question is did we ever consciously decide to live with the > architectural constraints or is there still work to do on defining the > label magic? I'd rather live with the constraints and avoid the label voodoo. -- to unsubscribe send a message to namedroppers-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 Oct 28 13:14:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21795 for ; Mon, 28 Oct 2002 13:14:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186EKY-000OYO-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 10:09:38 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 186EKU-000OYC-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 10:09:35 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 4DB8D37A1C9 for ; Mon, 28 Oct 2002 18:09:34 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DS and cache transparency. In-Reply-To: Message from Rob Austein of "Mon, 28 Oct 2002 12:22:30 EST." <20021028172230.1B39D18E3@thrintun.hactrn.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 28 Oct 2002 18:09:34 +0000 Message-Id: <20021028180934.4DB8D37A1C9@as.vix.com> X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > My question is did we ever consciously decide to live with the > > architectural constraints or is there still work to do on defining the > > label magic? > > I'd rather live with the constraints and avoid the label voodoo. strongly agreed. -- to unsubscribe send a message to namedroppers-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 Oct 28 13:51:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24329 for ; Mon, 28 Oct 2002 13:51:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Es7-0000Qn-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 10:44:19 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 186Es5-0000Qb-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 10:44:17 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9SIiEYm042651; Mon, 28 Oct 2002 13:44:14 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA09450; Mon, 28 Oct 2002 13:44:12 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20021028180934.4DB8D37A1C9@as.vix.com> References: <20021028180934.4DB8D37A1C9@as.vix.com> Date: Mon, 28 Oct 2002 10:44:12 -0800 To: Paul Vixie , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: DS and cache transparency. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-10.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> > My question is did we ever consciously decide to live with the >> > architectural constraints or is there still work to do on defining the >> > label magic? >> >> I'd rather live with the constraints and avoid the label voodoo. > >strongly agreed. me too -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 28 14:20:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25578 for ; Mon, 28 Oct 2002 14:20:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186FKK-00029q-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 11:13:28 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 186FKI-00028I-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 11:13:26 -0800 Received: from ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9SJCtnZ008732 for ; Mon, 28 Oct 2002 20:12:55 +0100 Message-Id: <200210281912.g9SJCtnZ008732@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: Re: DS and cache transparency. In-reply-to: Your message of Mon, 28 Oct 2002 10:44:12 PST. References: From: Olaf Kolkman X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Mon, 28 Oct 2002 20:12:55 +0100 X-RIPE-Spam-Status: NONE ; -1010 X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> > My question is did we ever consciously decide to live with the >> > architectural constraints or is there still work to do on defining the >> > label magic? >> >> I'd rather live with the constraints and avoid the label voodoo. Perfect... Should the 'only DNSSEC in line of sight" constrain be made explicit in the DS draft? --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 Mon Oct 28 14:46:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26531 for ; Mon, 28 Oct 2002 14:46:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Fhz-0003Xa-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 11:37:55 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 186Fhx-0003Wv-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 11:37:53 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g9SJYDD76443; Mon, 28 Oct 2002 14:34:13 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021028143526.01bbee40@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 28 Oct 2002 14:37:18 -0500 To: Olaf Kolkman , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DS and cache transparency. In-Reply-To: <200210281912.g9SJCtnZ008732@birch.ripe.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:12 2002-10-28, Olaf Kolkman wrote: > >> > My question is did we ever consciously decide to live with the > >> > architectural constraints or is there still work to do on defining the > >> > label magic? > >> > >> I'd rather live with the constraints and avoid the label voodoo. > >Perfect... > >Should the 'only DNSSEC in line of sight" constrain be made explicit >in the DS draft? This is applies not just to DS but all DNSSEC Records and should be mentioned in the DNSSEC-bis protocol document. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 28 18:01:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03064 for ; Mon, 28 Oct 2002 18:01:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Ily-000CzC-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 14:54:14 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 186Ilw-000Cys-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 14:54:12 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g9SMoTZ76822; Mon, 28 Oct 2002 17:50:29 -0500 (EST) (envelope-from ogud@ogud.com) Date: Mon, 28 Oct 2002 17:50:29 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: Delegation Signer Resource Record In-Reply-To: Message-ID: <20021028173714.Y76759-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Edward Lewis wrote: > Section 1 - isn't there an NLnet Labs report on SIG/KEY@parent? > > "Storing the KEY RRset at the parent simplifies the communication." to > Storing the KEY RR set at the parent was thought to simplify the > communication. > ^ ^^^^^^^^^^^^^^^ applied > "Given these (and what other?) reasons, SIG/KEY@parent isn't any > better than SIG/KEY@child." Applied > > I'm beginning to think that the last paragraph in 1 isn't really needed. I agree, KEY restict eliminates the need for this paragraph. Paragrpah gone. > > End of sect 2.1 > > Requiring two sig validations is no different than what happens in > lateral signing. The DS doesn't require two sig validations in all > cases - if the DS points to the ZSK, there's no KSK, no need to check > the self-signed key. sorry, you are wrong, DS requires two validations one for DS set and one for KEY set. > > Sect 2.2. > > What if the response is an answer and not a referral? (Ie the server > is authoritative for parent and child.) > The server must know to look for DS in the parent zone as stated in section "Special processing for DS queries. thanks for the comments I will push new version out late tomorrow if there are no more comments. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 28 19:18:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04915 for ; Mon, 28 Oct 2002 19:18:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Jx3-000GjV-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 16:09:45 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 186Jx0-000Gj6-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 16:09:42 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9T09bYm070722; Mon, 28 Oct 2002 19:09:37 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA13319; Mon, 28 Oct 2002 19:09:36 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20021028173714.Y76759-100000@hlid.dc.ogud.com> References: <20021028173714.Y76759-100000@hlid.dc.ogud.com> Date: Mon, 28 Oct 2002 15:56:13 -0800 To: Olafur Gudmundsson , Edward Lewis From: Edward Lewis Subject: Re: Delegation Signer Resource Record Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-10.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:50 -0500 10/28/02, Olafur Gudmundsson wrote: >sorry, you are wrong, DS requires two validations > one for DS set and one for KEY set. parent: @ KEY1 KEY2 SIG(KEY) by KEY1 child DS(KEY3) SIG(DS) by KEY2 child: @ SOA SIG(SOA) by KEY3 KEY3 Why must KEY3 be signed? I know that if "SIG(KEY3) by KEY3" exists, you get a warm and fuzzy feeling, but is it's existence a MUST? >> >> Sect 2.2. >> >> What if the response is an answer and not a referral? (Ie the server >> is authoritative for parent and child.) >> > >The server must know to look for DS in the parent zone as stated in >section "Special processing for DS queries. E.g., I issue: dig @a.root-servers.net 128.in-addr.arpa. soa Do I get the DS for arpa and in-addr.arpa in the referral? I'm asking in the context of this text in 2.2: # If DS RRset is present: # parent NS RRset # DS and SIG(DS) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 28 21:35:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07839 for ; Mon, 28 Oct 2002 21:35:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186M5p-000NLI-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 18:26:57 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 186M5l-000NL3-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 18:26:53 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g9T2N1w77149; Mon, 28 Oct 2002 21:23:02 -0500 (EST) (envelope-from ogud@ogud.com) Date: Mon, 28 Oct 2002 21:23:01 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: Delegation Signer Resource Record In-Reply-To: Message-ID: <20021028211646.B77130-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Edward Lewis wrote: > At 17:50 -0500 10/28/02, Olafur Gudmundsson wrote: > >sorry, you are wrong, DS requires two validations > > one for DS set and one for KEY set. > > parent: > @ KEY1 > KEY2 > SIG(KEY) by KEY1 > child DS(KEY3) > SIG(DS) by KEY2 > > child: > @ SOA > SIG(SOA) by KEY3 > KEY3 > > Why must KEY3 be signed? I know that if "SIG(KEY3) by KEY3" exists, > you get a warm and fuzzy feeling, but is it's existence a MUST? So, other bogus can not insert other keys into the KEY set and then use them to sign data generated by the attacker. Having the child KEY set signed by a "known key" whole reason, DNSSEC is about providing data integrity and authentication. > > >> > >> Sect 2.2. > >> > >> What if the response is an answer and not a referral? (Ie the server > >> is authoritative for parent and child.) > >> > > > >The server must know to look for DS in the parent zone as stated in > >section "Special processing for DS queries. > > E.g., I issue: > > dig @a.root-servers.net 128.in-addr.arpa. soa > > Do I get the DS for arpa and in-addr.arpa in the referral? I'm > asking in the context of this text in 2.2: > > # If DS RRset is present: > # parent NS RRset > # DS and SIG(DS) Only the one it is returning NS records for. In this case 128.in-addr.arpa. NS [and DS set]. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 28 22:55:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09409 for ; Mon, 28 Oct 2002 22:55:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186NO7-0001gP-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 19:49:55 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 186NO5-0001f7-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 19:49:53 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA08493; Mon, 28 Oct 2002 22:49:51 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA06005; Mon, 28 Oct 2002 22:46:57 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id WAA25084; Mon, 28 Oct 2002 22:46:56 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id WAA15670; Mon, 28 Oct 2002 22:46:56 -0500 (EST) To: Olafur Gudmundsson Cc: Edward Lewis , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Delegation Signer Resource Record References: <20021028211646.B77130-100000@hlid.dc.ogud.com> Date: 28 Oct 2002 22:46:55 -0500 In-Reply-To: <20021028211646.B77130-100000@hlid.dc.ogud.com> Message-ID: Lines: 44 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-12.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olafur Gudmundsson writes: > On Mon, 28 Oct 2002, Edward Lewis wrote: > > > At 17:50 -0500 10/28/02, Olafur Gudmundsson wrote: > > >sorry, you are wrong, DS requires two validations > > > one for DS set and one for KEY set. > > > > parent: > > @ KEY1 > > KEY2 > > SIG(KEY) by KEY1 > > child DS(KEY3) > > SIG(DS) by KEY2 > > > > child: > > @ SOA > > SIG(SOA) by KEY3 > > KEY3 > > > > Why must KEY3 be signed? I know that if "SIG(KEY3) by KEY3" exists, > > you get a warm and fuzzy feeling, but is it's existence a MUST? > > So, other bogus can not insert other keys into the KEY set and then use > them to sign data generated by the attacker. > Having the child KEY set signed by a "known key" whole reason, DNSSEC is > about providing data integrity and authentication. Yes, but KEY3 _IS_ signed -- through the DS in the parent. An attacker couldn't supply a "KEY4" because it would not be tied into the parent's DS hierarchy. OTOH, note that if you _DO_ have a KEY4 in the child zone you _DO_ require a "SIG(KEY) by KEY3" record... So it may be easier to always include it "just in case". However KEY3 can certainly stand "alone" without a self-signature -- it's validity is certified by the DS/SIG(DS) in the parent. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 28 23:08:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09775 for ; Mon, 28 Oct 2002 23:08:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186NdV-0002UW-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 20:05:49 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 186NdT-0002UK-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 20:05:47 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g9T41sB77334; Mon, 28 Oct 2002 23:01:54 -0500 (EST) (envelope-from ogud@ogud.com) Date: Mon, 28 Oct 2002 23:01:54 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Derek Atkins cc: Edward Lewis , Subject: Re: Delegation Signer Resource Record In-Reply-To: Message-ID: <20021028225251.T77313-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 28 Oct 2002, Derek Atkins wrote: > Olafur Gudmundsson writes: > > > On Mon, 28 Oct 2002, Edward Lewis wrote: > > > > > At 17:50 -0500 10/28/02, Olafur Gudmundsson wrote: > > > >sorry, you are wrong, DS requires two validations > > > > one for DS set and one for KEY set. > > > > > > parent: > > > @ KEY1 > > > KEY2 > > > SIG(KEY) by KEY1 > > > child DS(KEY3) > > > SIG(DS) by KEY2 > > > > > > child: > > > @ SOA > > > SIG(SOA) by KEY3 > > > KEY3 > > > > > > Why must KEY3 be signed? I know that if "SIG(KEY3) by KEY3" exists, > > > you get a warm and fuzzy feeling, but is it's existence a MUST? > > > > So, other bogus can not insert other keys into the KEY set and then use > > them to sign data generated by the attacker. > > Having the child KEY set signed by a "known key" whole reason, DNSSEC is > > about providing data integrity and authentication. > > Yes, but KEY3 _IS_ signed -- through the DS in the parent. An > attacker couldn't supply a "KEY4" because it would not be tied into > the parent's DS hierarchy. The whole point of DS is to simplify and minimize communication about KEY's between parent and child. IFF DS is used as a signature for KEY's in the child keyset we are in exactly same position as SIG@parent. > > OTOH, note that if you _DO_ have a KEY4 in the child zone you _DO_ > require a "SIG(KEY) by KEY3" record... So it may be easier to always > include it "just in case". However KEY3 can certainly stand "alone" > without a self-signature -- it's validity is certified by the > DS/SIG(DS) in the parent. > Bingo, you got it. Without signature KEY3 can not enable/authorize other KEY such as short lived zone signing keys. It is MUCH simpler for a protocol to have one rule that applies everywhere with no special cases. Thus for flexibility reasons lets keep the signature on KEY set in all cases even when the DS set points to ALL the keys in the set. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Oct 28 23:48:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10577 for ; Mon, 28 Oct 2002 23:48:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186ODl-0004Tp-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 20:43:17 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 186ODj-0004Td-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 20:43:15 -0800 Received: from isi.edu (dhcp1238.nanog26.merit.net [192.35.165.238]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9T4h2C00808; Mon, 28 Oct 2002 20:43:02 -0800 (PST) Message-ID: <3DBE11D5.43F86F01@isi.edu> Date: Mon, 28 Oct 2002 23:43:01 -0500 From: Dan Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Olafur Gudmundsson CC: Derek Atkins , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Delegation Signer Resource Record References: <20021028225251.T77313-100000@hlid.dc.ogud.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.5 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_05_08,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur Gudmundsson wrote: > > OTOH, note that if you _DO_ have a KEY4 in the child zone you _DO_ > > require a "SIG(KEY) by KEY3" record... So it may be easier to always > > include it "just in case". However KEY3 can certainly stand "alone" > > without a self-signature -- it's validity is certified by the > > DS/SIG(DS) in the parent. > > > > Bingo, you got it. Without signature KEY3 can not enable/authorize > other KEY such as short lived zone signing keys. > It is MUCH simpler for a protocol to have one rule that applies > everywhere with no special cases. > Thus for flexibility reasons lets keep the signature on KEY set in > all cases even when the DS set points to ALL the keys in the set. > > Olafur > I strongly agree with Olafur on this. The main point of DS was to simplify operations and separate parent/child key management functions. It is technically correct that you could authenticate KEY3 with just the DS, but doing this creates special cases for key rollovers and essentially starts re-introducing key management issues that DS was designed to remove. Dan -- to unsubscribe send a message to namedroppers-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 Oct 29 00:05:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10967 for ; Tue, 29 Oct 2002 00:05:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186OSV-0005JX-00 for namedroppers-data@psg.com; Mon, 28 Oct 2002 20:58:31 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 186OSA-0005JJ-00 for namedroppers@ops.ietf.org; Mon, 28 Oct 2002 20:58:10 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 99D3B37A1C4 for ; Tue, 29 Oct 2002 04:58:09 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Delegation Signer Resource Record In-Reply-To: Message from Derek Atkins of "28 Oct 2002 22:46:55 EST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 29 Oct 2002 04:58:09 +0000 Message-Id: <20021029045809.99D3B37A1C4@as.vix.com> X-Spam-Status: No, hits=-6.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Yes, but KEY3 _IS_ signed -- through the DS in the parent. An > attacker couldn't supply a "KEY4" because it would not be tied into > the parent's DS hierarchy. during the time that some important parents are not signed (. and COM) a lot of us are just exchanging public keys for static configuration, and thus learning of signitude by means other than DS RRs. > OTOH, note that if you _DO_ have a KEY4 in the child zone you _DO_ > require a "SIG(KEY) by KEY3" record... So it may be easier to always > include it "just in case". However KEY3 can certainly stand "alone" > without a self-signature -- it's validity is certified by the > DS/SIG(DS) in the parent. i think things should be self-signed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 29 09:59:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07276 for ; Tue, 29 Oct 2002 09:59:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186XaL-0003dD-00 for namedroppers-data@psg.com; Tue, 29 Oct 2002 06:43:13 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 186XaA-0003ZN-00 for namedroppers@ops.ietf.org; Tue, 29 Oct 2002 06:43:03 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA20577; Tue, 29 Oct 2002 09:42:49 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA12528; Tue, 29 Oct 2002 09:42:46 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA12643; Tue, 29 Oct 2002 09:42:45 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA16882; Tue, 29 Oct 2002 09:42:45 -0500 (EST) To: Dan Massey Cc: Olafur Gudmundsson , Edward Lewis , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Delegation Signer Resource Record References: <20021028225251.T77313-100000@hlid.dc.ogud.com> <3DBE11D5.43F86F01@isi.edu> Date: 29 Oct 2002 09:42:45 -0500 In-Reply-To: <3DBE11D5.43F86F01@isi.edu> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-8.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_05_08,USER_AGENT, X_OSIRU_OPEN_RELAY version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dan Massey writes: > Olafur Gudmundsson wrote: > > > > OTOH, note that if you _DO_ have a KEY4 in the child zone you _DO_ > > > require a "SIG(KEY) by KEY3" record... So it may be easier to always > > > include it "just in case". However KEY3 can certainly stand "alone" > > > without a self-signature -- it's validity is certified by the > > > DS/SIG(DS) in the parent. > > > > > > > Bingo, you got it. Without signature KEY3 can not enable/authorize > > other KEY such as short lived zone signing keys. > > It is MUCH simpler for a protocol to have one rule that applies > > everywhere with no special cases. > > Thus for flexibility reasons lets keep the signature on KEY set in > > all cases even when the DS set points to ALL the keys in the set. > > > > Olafur > > > > I strongly agree with Olafur on this. The main point of DS was to > simplify operations and separate parent/child key management > functions. It is technically correct that you could authenticate > KEY3 with just the DS, but doing this creates special cases for > key rollovers and essentially starts re-introducing key management > issues that DS was designed to remove. Oh, I agree COMPLETELY agree that you should always have two keys at a zone apex (ZKS and KSK).. I was just: a) pointing out that it _could_ be done, and b) playing devil's advcoate for Ed's position > Dan -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 29 11:45:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12604 for ; Tue, 29 Oct 2002 11:45:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186ZML-0008j7-00 for namedroppers-data@psg.com; Tue, 29 Oct 2002 08:36:53 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 186ZMI-0008in-00 for namedroppers@ops.ietf.org; Tue, 29 Oct 2002 08:36:50 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9TGaeYm085489; Tue, 29 Oct 2002 11:36:41 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA19593; Tue, 29 Oct 2002 11:36:38 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3DBE11D5.43F86F01@isi.edu> References: <20021028225251.T77313-100000@hlid.dc.ogud.com> <3DBE11D5.43F86F01@isi.edu> Date: Tue, 29 Oct 2002 08:36:42 -0800 To: Dan Massey , Olafur Gudmundsson From: Edward Lewis Subject: Re: Delegation Signer Resource Record Cc: Derek Atkins , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-8.0 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:43 -0500 10/28/02, Dan Massey wrote: >KEY3 with just the DS, but doing this creates special cases for >key rollovers and essentially starts re-introducing key management >issues that DS was designed to remove. Yeah, but: 1) The comment launching this is that "the DS RR does not require an additional validation when calculating an authentication chain" contrary to the cited text passage. (Okay, so the requirement that the KEY RR set must be self-signed means that the above is true, but is the requirement necessary?) What is causing the extra calculation is an operational consideration that is being implicitly laid upon the use of the DS RR. Nowhere do we require that their must be a distinction between the KSK and ZSK. We've just assumed it in our workshops, which have examined primarily registry zones[1]. 2) Requiring a separation between ZSK and KSK because of our limited experience in the workshops is short sighted. Recommending it for registry zones is a good thing, but for leaf zones, it may prove to be overkill. E.g., for cs.myuniv.edu to lab.cs.myuniv.edu, there's probably no need to have an extra key. "May prove to be" - I don't know if anyone has bothered to test the DS RR in that situation. [1] Registry zone = a zone that is predominately filled by numerous delegations and little other authoritative data. This is not restricted to the root and tld's, but they are prime examples. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 29 11:46:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12708 for ; Tue, 29 Oct 2002 11:46:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186ZMD-0008if-00 for namedroppers-data@psg.com; Tue, 29 Oct 2002 08:36:45 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 186ZMA-0008i5-00 for namedroppers@ops.ietf.org; Tue, 29 Oct 2002 08:36:43 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9TGabYm085483; Tue, 29 Oct 2002 11:36:37 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA19582; Tue, 29 Oct 2002 11:36:36 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20021028211646.B77130-100000@hlid.dc.ogud.com> References: <20021028211646.B77130-100000@hlid.dc.ogud.com> Date: Tue, 29 Oct 2002 08:35:04 -0800 To: Olafur Gudmundsson , Edward Lewis From: Edward Lewis Subject: Re: Delegation Signer Resource Record Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-10.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Okay - there's "A secure zone MUST contain a self-signed KEY RRset at its apex." in the draft. This means that the DS RR approach will always incur the extra SIG check. (But the question remains - is it necessary?) At 21:23 -0500 10/28/02, Olafur Gudmundsson wrote: >> Why must KEY3 be signed? I know that if "SIG(KEY3) by KEY3" exists, >> you get a warm and fuzzy feeling, but is it's existence a MUST? > >So, other bogus can not insert other keys into the KEY set and then use >them to sign data generated by the attacker. If there KEYX is a bogus key, and it is slipped into the KEY RR set, so long as the DS(KEY3) does not point to a SIG(KEY) by KEYX, what's the problem? >Having the child KEY set signed by a "known key" whole reason, DNSSEC is >about providing data integrity and authentication. But the DS refers to a specific key. And, if the attacker could forge a SIG(KEY by KEY3 that does cover {KEY3, KEYX}, the attacker might as well just forge SIG(DATA) by KEY3. I don't think that the SIG(KEY) is needed if there's just one KEY RR in a set that is referred to by a DS RR. >> Do I get the DS for arpa and in-addr.arpa in the referral? I'm >> asking in the context of this text in 2.2: >> >> # If DS RRset is present: >> # parent NS RRset >> # DS and SIG(DS) > >Only the one it is returning NS records for. >In this case 128.in-addr.arpa. NS [and DS set]. > > Olafur Then specify that only the DS RR set of the (what's the term?) zone in the referral is sent. Or open this up to requiring that all DS RR's at the server are to be returned. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 29 12:10:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14293 for ; Tue, 29 Oct 2002 12:10:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Zk8-0009uc-00 for namedroppers-data@psg.com; Tue, 29 Oct 2002 09:01:28 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 186Zk5-0009uQ-00 for namedroppers@ops.ietf.org; Tue, 29 Oct 2002 09:01:26 -0800 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g9TGvbD79018; Tue, 29 Oct 2002 11:57:38 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021029113010.018fe478@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 29 Oct 2002 11:42:00 -0500 To: Bob Halley From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSSEC wildcard optimization. Cc: namedroppers@ops.ietf.org In-Reply-To: References: <5.1.1.6.2.20021022211849.027780a0@localhost> <20020920174749.66e929e4.olaf@ripe.net> <20020920174749.66e929e4.olaf@ripe.net> <5.1.1.6.2.20021022211849.027780a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=-6.6 required=5.0 tests=IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14293 At 17:53 2002-10-23, Bob Halley wrote: >Ólafur Guðmundsson writes: > > > 4. RFC1035 wild card algorithm is unclear and needs clarification, > > publishing this protocol change without fixing the specification is not > > prudent, and I encourage the authors on taking on the clarification effort. > >What is unclear? Take following example *.foo c.b.foo. There is no RR at name b.foo. does the wildcard match a.b.foo or does the presence in of b.foo in c.b.foo terminate the wild card matching rule ? > > Based on this and other evidence that I have indicates that wild card > > usage is to large extent based on misunderstanding. > > There are examples where wild card MX records are used to create mail > > domains that exist without any DNS records such as eng.sun.com. > > Thus if the misunderstanding is corrected and we explain to the few > > application communities that are using wild cards in a legit way > > to push names out of DNS, what the DNS problems are, maybe we can make > > wildcards go away. > >Some people are confused, certainly. But I find it very hard to >believe that most uses of wildcards are erroneous or unwarranted. How many people out there do * MX ... and think they do not have to put MX records at every host name ? (answer: a lot). >Wildcards can be made to work with DNSSEC as it is. Why don't we just >leave features like wildcards that people are already using in, >stop adding more features, and let it deploy? Removing wildcards >from DNSSEC will discourage and delay deployment. I buy this argument but, The only new features being discussed are "DS" and "opt-in", there is one clarification ("AD-secure"), one usage restriction "key-restrict" and one optimization "wildcard presence signaling" You are the one that got the AD ball rolling by forcing me and Brian to write that one. DS was caused by operational difficulties, Key-restrict motivation is to separate DNS operation from other uses of KEY's (simplification), Opt-in is about choice (or lack there off). Once we have these all nailed down (I hope by end of November) there MUST be a feature freeze in DNSSEC for a while. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Oct 29 13:26:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17878 for ; Tue, 29 Oct 2002 13:26:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186aqh-000DRt-00 for namedroppers-data@psg.com; Tue, 29 Oct 2002 10:12:19 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 186aqf-000DRg-00 for namedroppers@ops.ietf.org; Tue, 29 Oct 2002 10:12:17 -0800 Received: from isi.edu (dhcp1238.nanog26.merit.net [192.35.165.238]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9TIC9C20650; Tue, 29 Oct 2002 10:12:09 -0800 (PST) Message-ID: <3DBECF79.FDE87025@isi.edu> Date: Tue, 29 Oct 2002 13:12:10 -0500 From: Dan Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Derek Atkins CC: Olafur Gudmundsson , Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Delegation Signer Resource Record References: <20021028225251.T77313-100000@hlid.dc.ogud.com> <3DBE11D5.43F86F01@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.1 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Derek Atkins wrote: > > Oh, I agree COMPLETELY agree that you should always have two keys > at a zone apex (ZKS and KSK).. I was just: > a) pointing out that it _could_ be done, and > b) playing devil's advcoate for Ed's position Understood. I also agree with you that technically the authentication path would work. My concern is that I don't see any good reason to do it. In this case, the advantage seems to be avoiding one signature check during SOME cases. We know it doesn't apply during KEY roll-over (unless you do some ugly operations that basically take us back to previous approaches and motivated the addition of DS). And its not just roll-over, there are a number of other corner cases here concerning SIG lifetimes and other operations. In my view, this is optimizing a specific scenario that could occur sometime (but would not occur using any possible operations that people testing the stuff have been able to use/recommend) and all this is done the expense is the overall design architecture. But perhaps there aren't enough options, corner cases, and extra knobs already in DNSSEC... :) Dan -- to unsubscribe send a message to namedroppers-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 Oct 29 13:45:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18869 for ; Tue, 29 Oct 2002 13:45:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186bGs-000EpO-00 for namedroppers-data@psg.com; Tue, 29 Oct 2002 10:39:22 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 186bGp-000Ep9-00 for namedroppers@ops.ietf.org; Tue, 29 Oct 2002 10:39:19 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9TIdEYm089696; Tue, 29 Oct 2002 13:39:14 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA09848; Tue, 29 Oct 2002 13:39:12 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3DBECF79.FDE87025@isi.edu> References: <20021028225251.T77313-100000@hlid.dc.ogud.com> <3DBE11D5.43F86F01@isi.edu> <3DBECF79.FDE87025@isi.edu> Date: Tue, 29 Oct 2002 10:39:14 -0800 To: Dan Massey , Derek Atkins From: Edward Lewis Subject: Re: Delegation Signer Resource Record Cc: Olafur Gudmundsson , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-8.6 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Diverging from the original topic of whether there should be text that the DS RR requires an extra SIG check -or- if the extra SIG check is just an artifact of our operational choice: I was asked at a workshop if the ZSK-KSK approach was required or recommended. Truthfully, I don't know what the situation is. Are we going to go down the road of mandating operational considerations at this stage of protocol development? Minding that the context of this mailing list is protocol, not operations. I don't want to come across as being unhappy with the ZSK-KSK approach, especially in the registry zones, but I've seen little consideration further down the tree. At 13:12 -0500 10/29/02, Dan Massey wrote: >Understood. I also agree with you that technically the authentication >path would work. My concern is that I don't see any good reason to do it. My sense from the person posing the question is that having to fumble with more than one key when it seems one would do the trick is the reason to use a ZSK=KSK approach. Yes, for registry (formal delegations) zones the consideration is not just operational simplicity at the child but the interface. But in less formal situations where graceful rollover isn't as hard to pull off (parent and child share all authoritative servers, for example), is the need to separate into KSK's and ZSK's a protocol/operational requirement (MUST)? >In this case, the advantage seems to be avoiding one signature check >during SOME cases. We know it doesn't apply during KEY roll-over Lessening the number of keys in the directory is one other advantage, along with not having to handle as many (kinds of) keys. >(unless you do some ugly operations that basically take us back to previous >approaches and motivated the addition of DS). And its not just roll-over, >there are a number of other corner cases here concerning SIG lifetimes and >other operations. In my view, this is optimizing a specific scenario that >could >occur sometime (but would not occur using any possible operations that >people testing the stuff have been able to use/recommend) and all >this is done When folks mention "corner cases" please illustrate what you mean. We've already had an issue with the use of the phrase and perceived stonewalling. Please document any corner case you want to cite. >the expense is the overall design architecture. But perhaps there aren't >enough >options, corner cases, and extra knobs already in DNSSEC... :) Then let's work to reduce them. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 30 02:17:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22878 for ; Wed, 30 Oct 2002 02:17:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186mvY-0009Vy-00 for namedroppers-data@psg.com; Tue, 29 Oct 2002 23:06:08 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 186mvV-0009VW-00 for namedroppers@ops.ietf.org; Tue, 29 Oct 2002 23:06:05 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id g9U74hnZ017427; Wed, 30 Oct 2002 08:04:43 +0100 Date: Wed, 30 Oct 2002 08:04:43 +0100 From: "Olaf M. Kolkman" To: Edward Lewis Cc: masseyd@ISI.EDU, ogud@ogud.com, derek@ihtfp.com, edlewis@arin.net, namedroppers@ops.ietf.org Subject: Re: Delegation Signer Resource Record Message-Id: <20021030080443.0eb20184.olaf@ripe.net> In-Reply-To: References: <20021028225251.T77313-100000@hlid.dc.ogud.com> <3DBE11D5.43F86F01@isi.edu> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: NONE ; -1004 X-Spam-Status: No, hits=-7.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit But isn't it the case that the SIG over the DS implements the parent's policy and the SIG over the KSK implements the childs policy wrt to signature expiration? If you leave out the validation over the KSK you can not check on the childs policy. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-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 Oct 30 06:24:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09486 for ; Wed, 30 Oct 2002 06:24:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186qry-000KhC-00 for namedroppers-data@psg.com; Wed, 30 Oct 2002 03:18:42 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 186qrw-000Kh0-00 for namedroppers@ops.ietf.org; Wed, 30 Oct 2002 03:18:40 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08366; Wed, 30 Oct 2002 06:16:16 -0500 (EST) Message-Id: <200210301116.GAA08366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-protocol-00.txt Date: Wed, 30 Oct 2002 06:16:16 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Protocol Modifications for the DNS Security Extensions Author(s) : R. Arends et al. Filename : draft-ietf-dnsext-dnssec-protocol-00.txt Pages : 32 Date : 2002-10-29 This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that provide source authentication for the DNS. This document describes the DNSSEC protocol modifications. The concept of zone signing is introduced and the zone format is modified to include KEY, SIG, NXT, and DS resource records. If a resolver indicates support for DNSSEC, the response process is modified to include the appropriate KEY, SIG, NXT, and DS resource records. These resource records are used by the resolver to authenticate the response. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-protocol-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-protocol-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: <2002-10-29124409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-29124409.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 Oct 30 10:54:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21388 for ; Wed, 30 Oct 2002 10:54:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186uyp-00076R-00 for namedroppers-data@psg.com; Wed, 30 Oct 2002 07:42:03 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #2) id 186uyn-000769-00 for namedroppers@ops.ietf.org; Wed, 30 Oct 2002 07:42:01 -0800 Received: from isi.edu (dhcp1238.nanog26.merit.net [192.35.165.238]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9UFfrC26119; Wed, 30 Oct 2002 07:41:53 -0800 (PST) Message-ID: <3DBFFDC2.CA4E7F2C@isi.edu> Date: Wed, 30 Oct 2002 10:41:54 -0500 From: Dan Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Edward Lewis , ogud@ogud.com, derek@ihtfp.com, namedroppers@ops.ietf.org Subject: Re: Delegation Signer Resource Record References: <20021028225251.T77313-100000@hlid.dc.ogud.com> <3DBE11D5.43F86F01@isi.edu> <20021030080443.0eb20184.olaf@ripe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.7 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,TO_BE_REMOVED_REPLY, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit right. so here's one place where we start to get into more corner cases. suppose you don't require the child SIG as Ed suggests and suppose you have an authenticated DS case 1: there is no SIG at the child - implies no child policy, you accept key case 2: there is a valid SIG at the child - do you have to use it Problem how do you know the child SIG exists or not? if no child SIG received, do you check an NXT to prove it doesn't exist?? (note you just added a check and the point was to remove a check on the SIG). So do we really need this "optimization"? Note also that no where are we saying you must use KSK-ZSK approach. You can use only one key if you want or build any policy you want, the only requirement is the child keyset MUST be self signed. Dan "Olaf M. Kolkman" wrote: > But isn't it the case that the SIG over the DS implements the parent's policy and > the SIG over the KSK implements the childs policy wrt to signature expiration? > > If you leave out the validation over the KSK you can not check on the childs policy. > > --Olaf > > --------------------------------------------| Olaf M. Kolkman > | www.ripe.net/disi > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Oct 30 12:24:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27086 for ; Wed, 30 Oct 2002 12:24:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186wTa-000CXP-00 for namedroppers-data@psg.com; Wed, 30 Oct 2002 09:17:54 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 186wTY-000CX7-00 for namedroppers@ops.ietf.org; Wed, 30 Oct 2002 09:17:52 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9UHHhYm021751; Wed, 30 Oct 2002 12:17:43 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA22296; Wed, 30 Oct 2002 12:17:42 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3DBFFDC2.CA4E7F2C@isi.edu> References: <20021028225251.T77313-100000@hlid.dc.ogud.com> <3DBE11D5.43F86F01@isi.edu> <20021030080443.0eb20184.olaf@ripe.net> <3DBFFDC2.CA4E7F2C@isi.edu> Date: Wed, 30 Oct 2002 09:17:40 -0800 To: Dan Massey , "Olaf M. Kolkman" From: Edward Lewis Subject: Re: Delegation Signer Resource Record Cc: Edward Lewis , ogud@ogud.com, derek@ihtfp.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-11.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,TO_BE_REMOVED_REPLY version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The SIG(KEY) at the child is the only way in which the child can make any statement about the crypto-freshness of the key (private/public pair). Although there is no requirement that an authoritative server verify the signature in the SIG RR, the server is required to check the validity period before responding to a non-CD bit request. Without the SIG (KEY), there is no way a zone can express the crypto-freshness of a key. The SIG validity period on the SIG(DS) is a function of the freshness of the parent's zone key, not the child's. Even if a child zone's management breaks down and fails to refresh their key, the DS RR will be maintained and the SIG (DS) will be continually refreshed. But once the SIG (KEY) falls out of time, KEY RR will no longer be validated/distributed, resulting in a hard failure - which is what is desired when it comes time to debug the problem. So there is a need for the SIG (KEY) record. It doesn't provide crypto-protection, but it does protect against a breakdown in the process of refreshing the key or resigning the zone. (Note: this has an implication for signed dynamic update zones, which currently still don't have a process for resigning data that isn't updated.) At 10:41 -0500 10/30/02, Dan Massey wrote: >right. > >so here's one place where we start to get into more >corner cases. suppose you don't require the child SIG >as Ed suggests and suppose you have an authenticated >DS > case 1: there is no SIG at the child > - implies no child policy, you accept key > case 2: there is a valid SIG at the child > - do you have to use it > >Problem how do you know the child SIG exists or not? > if no child SIG received, do you check an NXT to > prove it doesn't exist?? (note you just added a check > and the point was to remove a check on the SIG). > >So do we really need this "optimization"? Note also that no >where are we saying you must use KSK-ZSK approach. You >can use only one key if you want or build any policy you want, >the only requirement is the child keyset MUST be self signed. > >Dan > >"Olaf M. Kolkman" wrote: > >> But isn't it the case that the SIG over the DS implements the >>parent's policy and >> the SIG over the KSK implements the childs policy wrt to signature >>expiration? >> >> If you leave out the validation over the KSK you can not check on >>the childs policy. >> >> --Olaf >> >> --------------------------------------------| Olaf M. Kolkman >> | www.ripe.net/disi >> >> -- >> to 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 -- to unsubscribe send a message to namedroppers-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 Oct 30 16:42:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14039 for ; Wed, 30 Oct 2002 16:42:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1870Mx-0001QE-00 for namedroppers-data@psg.com; Wed, 30 Oct 2002 13:27:19 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 1870Mv-0001PS-00 for namedroppers@ops.ietf.org; Wed, 30 Oct 2002 13:27:18 -0800 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g9ULNED82097; Wed, 30 Oct 2002 16:23:14 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20021029154104.0282a0c0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 30 Oct 2002 16:26:19 -0500 To: Edward Lewis , Dan Massey From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Delegation Signer Resource Record Cc: namedroppers@ops.ietf.org In-Reply-To: References: <3DBECF79.FDE87025@isi.edu> <20021028225251.T77313-100000@hlid.dc.ogud.com> <3DBE11D5.43F86F01@isi.edu> <3DBECF79.FDE87025@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-9.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:39 2002-10-29, Edward Lewis wrote: >Diverging from the original topic of whether there should be text that the >DS RR requires an extra SIG check -or- if the extra SIG check is just an >artifact of our operational choice: > >I was asked at a workshop if the ZSK-KSK approach was required or >recommended. Not required, when I started this draft I saw DS enable of this approach and mentioned it in passing. With each month passing I think that KSK-ZSK is a good approach especially in cases where DNS operation is outscored. If I had to pick a RFC2119 keyword to describe this MAY is the strongest one I would use. > Truthfully, I don't know what the situation is. Are we going to go down > the road of mandating operational considerations at this stage of > protocol development? Minding that the context of this mailing list is > protocol, not operations. I could not agree more. >At 13:12 -0500 10/29/02, Dan Massey wrote: >>Understood. I also agree with you that technically the authentication >>path would work. My concern is that I don't see any good reason to do it. > >My sense from the person posing the question is that having to fumble with >more than one key when it seems one would do the trick is the reason to >use a ZSK=KSK approach. Yes, for registry (formal delegations) zones the >consideration is not just operational simplicity at the child but the >interface. But in less formal situations where graceful rollover isn't as >hard to pull off (parent and child share all authoritative servers, for >example), is the need to separate into KSK's and ZSK's a >protocol/operational requirement (MUST)? There are going to be many zones that will only use only one KEY, but I hope the larger ones will consider using multiple keys. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 06:30:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13658 for ; Thu, 31 Oct 2002 06:30:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187DKJ-000Lu0-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 03:17:27 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 187DKG-000Ltb-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 03:17:24 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13175; Thu, 31 Oct 2002 06:15:00 -0500 (EST) Message-Id: <200210311115.GAA13175@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-reid-ipv6ok-00.txt Date: Thu, 31 Oct 2002 06:14:59 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Indicating Resolver Support for AAAA Records Author(s) : J. Reid, S. Woolf Filename : draft-reid-ipv6ok-00.txt Pages : 4 Date : 2002-10-30 In order to simplify the deployment of AAAA records in the DNS, name servers should only perform automatic inclusion of these RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-reid-ipv6ok-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-reid-ipv6ok-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-reid-ipv6ok-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: <2002-10-30170344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-reid-ipv6ok-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-reid-ipv6ok-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-30170344.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 09:03:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19616 for ; Thu, 31 Oct 2002 09:03:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187Fmb-00040d-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 05:54:49 -0800 Received: from netbusters.com ([207.8.219.204] helo=www.netbusters.com) by psg.com with esmtp (Exim 3.36 #2) id 187FmZ-00040Q-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 05:54:47 -0800 Received: by www.netbusters.com (Postfix, from userid 513) id 7B1921829; Thu, 31 Oct 2002 08:54:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by www.netbusters.com (Postfix) with ESMTP id 79936372C for ; Thu, 31 Oct 2002 08:54:46 -0500 (EST) Date: Thu, 31 Oct 2002 08:54:46 -0500 (EST) From: Donald Eastlake 3rd X-X-Sender: dee3@netbusters.com To: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-trade-srv-higher-services-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="Boundary_(ID_KBwqxdVS0iXWjXTfMcRtIQ)" Content-ID: X-Spam-Status: No, hits=1.9 required=5.0 tests=MIME_NULL_BLOCK,MIME_SUSPECT_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.41 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --Boundary_(ID_KBwqxdVS0iXWjXTfMcRtIQ) Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Members of this working group may be interested in the draft announced below. I have also contacted the authors of RFC 2782 and the comments I have received from them have been generally favorable. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com ---------- Forwarded message ---------- Date: Thu, 31 Oct 2002 06:14:03 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: ietf-trade@lists.elistx.com Subject: I-D ACTION:draft-ietf-trade-srv-higher-services-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : DNS SRV Location of Higher Level Services Author(s) : D. Eastlake Filename : draft-ietf-trade-srv-higher-services-00.txt Pages : 7 Date : 2002-10-30 DNS naming conventions specified in RFC 2782 are extended to higher level services and a registry created for the tokens used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-srv-higher-services-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-trade-srv-higher-services-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-trade-srv-higher-services-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. --Boundary_(ID_KBwqxdVS0iXWjXTfMcRtIQ) Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_R4ercdFoxdPcFYgYbu6+7g)" Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --Boundary_(ID_R4ercdFoxdPcFYgYbu6+7g) Content-Type: MESSAGE/EXTERNAL-BODY; SERVER="mailserv@ietf.org"; ACCESS-TYPE=mail-server Content-ID: --Boundary_(ID_R4ercdFoxdPcFYgYbu6+7g) Content-Type: MESSAGE/EXTERNAL-BODY; DIRECTORY=internet-drafts; ACCESS-TYPE=anon-ftp; SITE="ftp.ietf.org"; NAME="draft-ietf-trade-srv-higher-services-00.txt" Content-ID: --Boundary_(ID_R4ercdFoxdPcFYgYbu6+7g)-- --Boundary_(ID_KBwqxdVS0iXWjXTfMcRtIQ)-- -- to unsubscribe send a message to namedroppers-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 Oct 31 09:21:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20499 for ; Thu, 31 Oct 2002 09:21:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187G3d-0004zZ-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 06:12:25 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #2) id 187G3a-0004zJ-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 06:12:22 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 09:12:14 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002103109121411065 ; Thu, 31 Oct 2002 09:12:14 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 09:12:01 -0500 Message-Id: <3C1E3607B37295439F7C409EFBA08E6803B95812@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: =?iso-8859-1?Q?=27=D3lafur_Gu=F0mundsson=27?= Cc: namedroppers@ops.ietf.org Subject: RE: Delegation Signer Resource Record Date: Thu, 31 Oct 2002 09:12:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There are going to be many zones that will only use only one > KEY [have separate ZSK and KSK for DS], but I hope > the larger ones will consider using multiple keys. I think that many of the smaller ones will end up using multiple keys as well--anyone who wants to do dynamic update of a signed zone will need to keep at least *some* of the keying material online. Keeping only the ZSK on the authoritative master, and keeping the KSK on an off-line signing system, seems to be the best compromise right now to support re-signing a zone following dynamic update. At the most, though, the DS protocol/standard document should recommend the use of two separate keys, rather than requiring it. An operational BCP should probably discuss the issues like dynamic update of secure zones. -- Rip Loomis Senior Systems Security Engineer SAIC Secure Business Solutions Group www.saic.com/securebiz Center for Information Security Technology www.cist-east.saic.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 10:09:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23682 for ; Thu, 31 Oct 2002 10:09:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187Gjh-0007ZW-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 06:55:53 -0800 Received: from pullyou.nist.gov ([129.6.16.93] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #2) id 187GjT-0007ZE-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 06:55:39 -0800 Received: from P612389 (gorilla.antd.nist.gov [129.6.55.20]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id g9VEtQCC003665 for ; Thu, 31 Oct 2002 09:55:26 -0500 (EST) Message-ID: <005c01c280ed$61ee3200$14370681@P612389> From: "Scott Rose" To: References: <3C1E3607B37295439F7C409EFBA08E6803B95812@US-Columbia-CIST.mail.saic.com> Subject: Re: Delegation Signer Resource Record Date: Thu, 31 Oct 2002 09:54:15 -0500 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.5 required=5.0 tests=INVALID_MSGID,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,TO_BE_REMOVED_REPLY,USER_AGENT_OE version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit But try to word the suggestion as an administrative/operating suggestion and not a protocol suggestion. And repeat the suggestion in stronger terms in the mythic BCP on running a signed zone/security aware server. Whenever it shows up again :) Scott ----- Original Message ----- From: "Loomis, Rip" > > At the most, though, the DS protocol/standard document should recommend > the use of two separate keys, rather than requiring it. An > operational BCP should probably discuss the issues like > dynamic update of secure zones. > > -- > Rip Loomis Senior Systems Security Engineer > SAIC Secure Business Solutions Group www.saic.com/securebiz > Center for Information Security Technology www.cist-east.saic.com > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 11:24:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29090 for ; Thu, 31 Oct 2002 11:24:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187HuX-000CMt-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 08:11:09 -0800 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #2) id 187HuU-000CMh-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 08:11:07 -0800 Received: from [68.53.172.178] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0) with ESMTP-TLS id 171391 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 10:09:02 -0600 Message-ID: <3DC15617.7040506@ehsco.com> Date: Thu, 31 Oct 2002 10:11:03 -0600 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-reid-ipv6ok-00.txt References: <200210311115.GAA13175@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=RCVD_IN_RFCI,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Title : Indicating Resolver Support for AAAA Records > Author(s) : J. Reid, S. Woolf > Filename : draft-reid-ipv6ok-00.txt > Pages : 4 > Date : 2002-10-30 This works for me, at least as a model. Some specifics: There isn't a lot of discussion on what the flag is supposed to cause to happen. Does it mean that whenever a server would normally return an A RR (either as answer or additional-data) that it should also return any available AAAA RRs for all of those names? What if the size of the answer will overload the EDNS message? That will put us back into the original problem case. Should the server not return the AAAA data, should the server give a truncated response using the existing rules, or what. On a broader note, include-AAAA-for-every-A implicitly updates several specifications which prescribe additional-data behavior. Even if this doesn't result in any significant problems, it may still be necessary to itemize (at the least) or discuss (at the worst) the impact of this change to those specifications. OTOH, if the intention is architecture -- facilitating standardized usage but not updating the default behavior for any existing specifications -- then that should be stated somewhere explicitly as well. | More explicitly, IPv6-aware nameservers MUST NOT insert AAAA RRs in | a response unless the IO bit was set on the request. Should be "MUST NOT insert [unsolicited] AAAA RRs" if I understand the model correctly. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 11:25:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29124 for ; Thu, 31 Oct 2002 11:25:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187Hvh-000CQy-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 08:12:21 -0800 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #2) id 187Hvf-000CQk-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 08:12:19 -0800 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id g9VG3oo28244 for ; Thu, 31 Oct 2002 11:03:50 -0500 (EST) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAv9aqk3; Thu, 31 Oct 02 11:03:50 -0500 Received: from shmrspr1-pf0.shdc.chrysler.com ([129.9.145.48]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2002103111121106141 for ; Thu, 31 Oct 2002 11:12:11 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g9VGC6408684 for ; Thu, 31 Oct 2002 11:12:06 -0500 (EST) Message-ID: <3DC1561C.34CDA4C1@daimlerchrysler.com> Date: Thu, 31 Oct 2002 11:11:08 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Comment on draft-reid-ipv6ok-00.txt References: <200210311115.GAA13175@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.5 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM, X_ACCEPT_LANG version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Why allocate a bit in the EDNS0 extended flags, which you'll probably never be able to de-allocate/re-allocate? Use an OPTION record instead. For an option which is basically just boolean, it only takes up 4 octets (2 for the option code and 2 for the length field); hardly enough to break the bank, and when the option is no longer needed, it can simply be phased out. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 12:58:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04831 for ; Thu, 31 Oct 2002 12:58:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187JIA-000Hpc-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 09:39:38 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 187JI7-000Hom-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 09:39:35 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9VHdWYm052625; Thu, 31 Oct 2002 12:39:32 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA19959; Thu, 31 Oct 2002 12:39:30 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3C1E3607B37295439F7C409EFBA08E6803B95812@US-Columbia-CIST.mail.saic.com> References: <3C1E3607B37295439F7C409EFBA08E6803B95812@US-Columbia-CIST.mail.saic.com> Date: Thu, 31 Oct 2002 09:39:30 -0800 To: "Loomis, Rip" , =?iso-8859-1?Q?=27=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson=27?= From: Edward Lewis Subject: on-offline keys : was RE: Delegation Signer Resource Record Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-8.6 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This might work in spite of some history below in a related area. Not having the ZSK on-line means that if the KEY RR is altered, it can't be resigned and the chain of trust broken. And in this case, you might what a hard failure. As described below, the safety of a set of keys is a low as the least safe key. An on-line key means that off-line keys are just as weak. However, what is being gained by this strategy is not having to go back to the parent zone every time someone breaks into your name server. At 9:12 -0500 10/31/02, Loomis, Rip wrote: ... >multiple keys as well--anyone who wants to do dynamic update >of a signed zone will need to keep at least *some* of the >keying material online. Keeping only the ZSK on the >authoritative master, and keeping the KSK on an off-line >signing system, seems to be the best compromise right now >to support re-signing a zone following dynamic update. A long time ago, in a office vacated by a Labs, we once discussed the concept of key strength. This was to be in the last four bits of the KEY RR flags field, the definition might appear in RFC 2065 (the one obsoleted by 2535). We thought at the time that there would be a reason to keep some keys off-line and some on-line. Key strength was a means to prevent on-line keys from replacing a SIG RR put in place by an off-line key. Ultimately this bad idea went away when we discovered that if the vulnerability that we feared was exploited, any gain from this feature vanished. E.g., if the server's host security was compromised and the "weaker" off-line key was exposed, then the attacker could forge SIG RR's with the weak key. True, there's a SIG RR with the stronger key (possibly) to compete with the SIG RR of the (corrupt) weaker key, but a resolver will likely never see both in time to compare them. We gave up on trying to design for having different strength (in the sense of how safe the private component is, not crypto-strength) keys as a result of this observation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 13:40:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07176 for ; Thu, 31 Oct 2002 13:40:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187K1H-000KoX-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 10:26:15 -0800 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #2) id 187K1F-000KoK-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 10:26:13 -0800 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 13:25:55 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002103113255511811 ; Thu, 31 Oct 2002 13:25:55 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Oct 2002 13:25:43 -0500 Message-Id: <3C1E3607B37295439F7C409EFBA08E6803B95819@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Edward Lewis'" Cc: namedroppers@ops.ietf.org Subject: RE: on-offline keys : was RE: Delegation Signer Resource Record Date: Thu, 31 Oct 2002 13:26:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ed-- I think you just leapfrogged right over me with your train of thought...let me try to catch up... > Not having the ZSK on-line means that if the KEY RR is altered, it > can't be resigned and the chain of trust broken. And in this case, > you might what a hard failure. ITYM "...it can't be re-signed, and the chain of trust is therefore broken. And in this case you might want a hard failure." If my re-wording matches what you were trying to say: Correct. If the private portion of the ZSK pair is stored on-line and is subsequently compromised, then the compromise recovery is slightly faster if I don't need to change KSKs or DS records. There are some potential issues if I immediately generate a new ZSK and remove the old one entirely without rollover, but compromise recovery is *always* messy like that. (I'm beginning to think that the TTL on ZSKs and the SIG on ZSKs is going to be on the order of 5-10 minutes max, in a perhaps futile attempt to force quicker cache coherency following a ZSK compromise. TTL for other records/SIGs could, and probably should, be more like the typical 5-7 days of today.) Note that I'm still _hoping_ that the [private portion of the] ZSK will only be stored in an off-line signer--but dynamically-updated DNS zones seem to be a fairly common and reasonable thing to plan for when looking at zones outside the foundation/registry zones. > As described below, the safety of a set of keys is a low as the least > safe key. An on-line key means that off-line keys are just as weak. > However, what is being gained by this strategy is not having to go > back to the parent zone every time someone breaks into your name > server. Not sure I grok your use of the common words weak/strong and safe/unsafe in this context. If both halves of the ZSK pair are online (the public portion in the zone, and the private portion in the authoritative master) then I'm not sure how that makes the offline-only KSK "weak". Sure, if the ZSK is compromised then the attacker can modify the zone and re-sign; that's why it's strongly preferred that the ZSK be kept only off-line. Unfortunately, I need to be able to re-sign a dynamically-updated zone in real-time--not every zone, but some zones. I'm going to have to be willing to reduce the effective security/assurance provided by the combination of the ZSK and KSK in such a case; if I do so then I *really* need to minimize the window of vulnerability following a compromise (since ZSK compromise would now expected to be much more likely). [...] > Ultimately this bad idea went away when we discovered that if the > vulnerability that we feared was exploited, any gain from this > feature vanished. E.g., if the server's host security was > compromised and the "weaker" off-line key was exposed, then the > attacker could forge SIG RR's with the weak key. True, there's a SIG > RR with the stronger key (possibly) to compete with the SIG RR of the > (corrupt) weaker key, but a resolver will likely never see both in > time to compare them. > > We gave up on trying to design for having different strength (in the > sense of how safe the private component is, not crypto-strength) keys > as a result of this observation. I think in the DS world of separate ZSKs and KSKs, the issues are slightly different. What I'm trying to produce is a scenario where if a ZSK is compromised then the parent zone does not necessarily need to take any action to assist in the compromise recovery. I think it's reasonable, do-able, and (for the case of dynamic updates to signed zones) necessary-- and the existence of a separate KSK makes it possible. I think we're actually more-or-less in violent agreement... --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 14:11:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08963 for ; Thu, 31 Oct 2002 14:11:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187Kb4-000NGW-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 11:03:14 -0800 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #2) id 187Kb2-000NG8-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 11:03:12 -0800 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g9VJ3BYm056472; Thu, 31 Oct 2002 14:03:11 -0500 (EST) Received: from [192.35.167.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA04607; Thu, 31 Oct 2002 14:03:09 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3C1E3607B37295439F7C409EFBA08E6803B95819@US-Columbia-CIST.mail.saic.com> References: <3C1E3607B37295439F7C409EFBA08E6803B95819@US-Columbia-CIST.mail.saic.com> Date: Thu, 31 Oct 2002 11:03:06 -0800 To: "Loomis, Rip" , "'Edward Lewis'" From: Edward Lewis Subject: RE: on-offline keys : was RE: Delegation Signer Resource Record Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:26 -0500 10/31/02, Loomis, Rip wrote: >Not sure I grok your use of the common words weak/strong and safe/unsafe >in this context. If both halves of the ZSK pair are online (the public I grok your nongrok. I switched terminology on purpose. By safe/unsafe, I mean: safe = private key is not vulnerable to a break in host security unsafe = private key is at risk of a break in host security - in this context. Safe/unsafe are terms I just applied in the last mail because (IMHO) they are more descriptive than strong/weak. The terms strong/weak were the poorly chosen words used way back then, with strong=safe, and weak=unsafe. > >I think we're actually more-or-less in violent agreement... > Yes. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 14:14:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09060 for ; Thu, 31 Oct 2002 14:14:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187KbA-000NGn-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 11:03:20 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #2) id 187Kb8-000NGb-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 11:03:18 -0800 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA23965; Thu, 31 Oct 2002 14:03:16 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA06976; Thu, 31 Oct 2002 13:59:18 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id NAA23917; Thu, 31 Oct 2002 13:55:46 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id NAA22617; Thu, 31 Oct 2002 13:55:46 -0500 (EST) To: "Loomis, Rip" Cc: "'Edward Lewis'" , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: on-offline keys : was RE: Delegation Signer Resource Record References: <3C1E3607B37295439F7C409EFBA08E6803B95819@US-Columbia-CIST.mail.saic.com> Date: 31 Oct 2002 13:55:46 -0500 In-Reply-To: <3C1E3607B37295439F7C409EFBA08E6803B95819@US-Columbia-CIST.mail.saic.com> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-12.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Loomis, Rip" writes: > on ZSKs and the SIG on ZSKs is going to be on the order of 5-10 minutes > max, in a perhaps futile attempt to force quicker cache coherency > following a ZSK compromise. TTL for other records/SIGs could, and > probably should, be more like the typical 5-7 days of today.) If you have a SIG record with 5-7 day TTL and a KEY record with a 5-10 minute TTL, you run the risk of creating invalid signatures if you remove the old KEY record too soon. In particular, when you roll over the ZKS, you MUST keep the OLD KEY around for another period of time. Granted, it is still safe to keep the KEY-RR TTL rather low, but that doesn't mean you can _remove_ the key any faster than your "outstanding" records. But I think you knew that.. ;) -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 16:03:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14863 for ; Thu, 31 Oct 2002 16:03:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187MKt-0004mw-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 12:54:39 -0800 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #2) id 187MKr-0004mI-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 12:54:37 -0800 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g9VKoW285606; Thu, 31 Oct 2002 15:50:32 -0500 (EST) (envelope-from ogud@ogud.com) Date: Thu, 31 Oct 2002 15:50:32 -0500 (EST) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: "Loomis, Rip" cc: DNSEXT mailing list Subject: Re: on-offline keys : was RE: Delegation Signer Resource Record In-Reply-To: Message-ID: <20021031154550.H85409-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 31 Oct 2002, Derek Atkins wrote: > "Loomis, Rip" writes: > > > on ZSKs and the SIG on ZSKs is going to be on the order of 5-10 minutes > > max, in a perhaps futile attempt to force quicker cache coherency > > following a ZSK compromise. TTL for other records/SIGs could, and > > probably should, be more like the typical 5-7 days of today.) > > If you have a SIG record with 5-7 day TTL and a KEY record with a 5-10 > minute TTL, you run the risk of creating invalid signatures if you > remove the old KEY record too soon. In particular, when you roll over > the ZKS, you MUST keep the OLD KEY around for another period > of time. This also brings out another issue that we have seen in the workshops. What TTL should be used in a cahce for verified data. a) the TTL the record arrived with b) the smallest TTL of any of the KEY and DS RRsets used to validate the RRset. If the answer is b. then all data validated by a key in your KEY RRset will be expired within 10 minutes. I do not know what the right answer is, a user selectable policy is one possible answer. Is this an issue that the DNSSEC-bis document should address ? Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Oct 31 18:03:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19382 for ; Thu, 31 Oct 2002 18:03:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187O8L-000DFz-00 for namedroppers-data@psg.com; Thu, 31 Oct 2002 14:49:49 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 187O8K-000DFn-00 for namedroppers@ops.ietf.org; Thu, 31 Oct 2002 14:49:48 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 5F47837A037; Thu, 31 Oct 2002 22:49:45 +0000 (GMT) From: Paul Vixie To: Olafur Gudmundsson Cc: "Loomis, Rip" , DNSEXT mailing list Subject: Re: on-offline keys : was RE: Delegation Signer Resource Record In-Reply-To: Message from Olafur Gudmundsson of "Thu, 31 Oct 2002 15:50:32 EST." <20021031154550.H85409-100000@hlid.dc.ogud.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 31 Oct 2002 22:49:45 +0000 Message-Id: <20021031224945.5F47837A037@as.vix.com> X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This also brings out another issue that we have seen in the workshops. > What TTL should be used in a cahce for verified data. > a) the TTL the record arrived with > b) the smallest TTL of > any of the KEY and DS RRsets used to validate the RRset. > > If the answer is b. then all data validated by a key in your KEY RRset > will be expired within 10 minutes. > > I do not know what the right answer is, a user selectable policy is > one possible answer. > > Is this an issue that the DNSSEC-bis document should address ? if there's to be a policy, let it be at the authoritative side. (the signer can minimize ttl's at signing time if the ttl would otherwise be longer than the signature.) when caching/forwarding secure rrsets, the standard dns ttl rules ought to apply. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: