From owner-namedroppers@ops.ietf.org Fri Sep 1 20:26:46 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23337 for ; Fri, 1 Sep 2000 20:26:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13V0Im-000Dj4-00 for namedroppers-data@psg.com; Fri, 01 Sep 2000 16:32:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13V0Il-000Diy-00 for namedroppers@ops.ietf.org; Fri, 01 Sep 2000 16:32:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13V0Il-0004a1-00 for namedroppers@ops.ietf.org; Fri, 01 Sep 2000 16:32:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Fri, 01 Sep 2000 03:00:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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. the list is moderated. 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. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Sep 6 09:57:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12478 for ; Wed, 6 Sep 2000 09:57:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13WezP-000Fsg-00 for namedroppers-data@psg.com; Wed, 06 Sep 2000 06:11:43 -0700 Received: from [195.149.150.42] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13WezN-000Fsa-00 for namedroppers@ops.ietf.org; Wed, 06 Sep 2000 06:11:42 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13WezX-00069x-00 for namedroppers@ops.ietf.org; Wed, 06 Sep 2000 15:11:51 +0200 Message-Id: <200009061044.GAA06805@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-okbit-00.txt Date: Wed, 06 Sep 2000 06:44:02 -0400 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 : Indicating Resolver Support of DNSSEC Author(s) : D. Conrad Filename : draft-ietf-dnsext-dnssec-okbit-00.txt Pages : 5 Date : 05-Sep-00 In order to deploy DNSSEC operationally, DNSSEC aware servers should only respond with DNSSEC 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 the necessary protocol changes to implement that notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-00.txt 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-okbit-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-okbit-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: <20000905135118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-okbit-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-okbit-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135118.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. From owner-namedroppers@ops.ietf.org Fri Sep 8 03:44:17 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18532 for ; Fri, 8 Sep 2000 03:44:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13XICk-000IkO-00 for namedroppers-data@psg.com; Fri, 08 Sep 2000 00:04:06 -0700 Received: from dynamic219.workshop.sigz.net ([195.149.150.219] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13XICj-000IkI-00 for namedroppers@ops.ietf.org; Fri, 08 Sep 2000 00:04:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13XID5-0008Wh-00 for namedroppers@ops.ietf.org; Fri, 08 Sep 2000 09:04:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000908023743.00bade00@localhost> Date: Fri, 08 Sep 2000 02:53:21 -0400 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: WG Last call: RSA-SHA1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a last call on this document, This document defines a new Signature algorithm transform RSA/SHA1 to replace RSA/MD5 (alg 1) currently defined in RFC2537. This document contains text similar to what is in RFC2537 but changing the message digest algorithm. The draft also makes RSA/SHA1 a MANDATORY to implement. This is a WG last call ending September 20'th 2000 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-01.txt The URL for RFC2537 is http://www.ietf.org/rfc/rfc2537.txt This draft will replace RFC2537 on standards track, and obsoletes RFC2537. If you disagree with above action please state why, this document is not ready or if this should not be done. 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. From owner-namedroppers@ops.ietf.org Sat Sep 9 08:39:19 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21258 for ; Sat, 9 Sep 2000 08:39:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13XjCU-000HqX-00 for namedroppers-data@psg.com; Sat, 09 Sep 2000 04:53:38 -0700 Received: from d16.nic-se.se ([212.247.3.16] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13XjCT-000Hps-00 for namedroppers@ops.ietf.org; Sat, 09 Sep 2000 04:53:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13XjBz-0000BD-00 for namedroppers@ops.ietf.org; Sat, 09 Sep 2000 13:53:07 +0200 Date: Sat, 9 Sep 2000 04:33:50 -0700 (PDT) From: Brian Wellington To: Olafur Gudmundsson Cc: DNSEXT WG Mailing list Subject: Re: WG Last call: RSA-SHA1 In-Reply-To: <4.3.2.7.2.20000908023743.00bade00@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 8 Sep 2000, Olafur Gudmundsson wrote: > This is a last call on this document, This document defines a new > Signature algorithm transform RSA/SHA1 to replace RSA/MD5 (alg 1) > currently defined in RFC2537. > > This document contains text similar to what is in RFC2537 but changing > the message digest algorithm. The draft also makes RSA/SHA1 a MANDATORY > to implement. > > This is a WG last call ending September 20'th 2000 This document does not specify the method for deriving the footprint (id, tag, whatever it's called now) for an RSA-SHA1 key. This leads to a slight ambiguity. Although RFC2535 specifies the computation method for all future algorithms, an RSA-SHA1 key is identical to an RSA-MD5 key, and if the RFC2535 method is used, two identical keys would have different footprints. Using the RFC2535 method is probably the right thing to do, but maybe mentioning this anomaly in the draft would be reasonable. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Sep 10 05:45:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07162 for ; Sun, 10 Sep 2000 05:45:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13Y2vD-0009hk-00 for namedroppers-data@psg.com; Sun, 10 Sep 2000 01:57:07 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13Y2vB-0009hd-00 for namedroppers@ops.ietf.org; Sun, 10 Sep 2000 01:57:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Y2sV-0000Sx-00 for namedroppers@ops.ietf.org; Sun, 10 Sep 2000 10:54:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200009100252.WAA12723@torque.pothole.com> To: Brian Wellington cc: DNSEXT WG Mailing list Subject: Re: WG Last call: RSA-SHA1 In-reply-to: Your message of "Sat, 09 Sep 2000 04:33:50 PDT." Date: Sat, 09 Sep 2000 22:52:43 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, That's a good point. I think the general method given in RFC2535 should be used, which I think is the current implication. But, because the previous RSA key used a special method, this change in RSA KEY tag calculation should be pointed out in the draft. Thanks, Donald From: Brian Wellington Date: Sat, 9 Sep 2000 04:33:50 -0700 (PDT) To: Olafur Gudmundsson Cc: DNSEXT WG Mailing list In-Reply-To: <4.3.2.7.2.20000908023743.00bade00@localhost> Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >On Fri, 8 Sep 2000, Olafur Gudmundsson wrote: > >> This is a last call on this document, This document defines a new >> Signature algorithm transform RSA/SHA1 to replace RSA/MD5 (alg 1) >> currently defined in RFC2537. >> >> This document contains text similar to what is in RFC2537 but changing >> the message digest algorithm. The draft also makes RSA/SHA1 a MANDATORY >> to implement. >> >> This is a WG last call ending September 20'th 2000 > >This document does not specify the method for deriving the footprint (id, >tag, whatever it's called now) for an RSA-SHA1 key. This leads to a >slight ambiguity. Although RFC2535 specifies the computation method for >all future algorithms, an RSA-SHA1 key is identical to an RSA-MD5 key, and >if the RFC2535 method is used, two identical keys would have different >footprints. > >Using the RFC2535 method is probably the right thing to do, but maybe >mentioning this anomaly in the draft would be reasonable. > >Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 12 01:58:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20401 for ; Tue, 12 Sep 2000 01:58:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13YiID-000Gws-00 for namedroppers-data@psg.com; Mon, 11 Sep 2000 22:07:37 -0700 Received: from dhcp070.ripemtg.ripe.net ([193.0.4.70] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13YiIB-000Gwm-00 for namedroppers@ops.ietf.org; Mon, 11 Sep 2000 22:07:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13YiIU-0001Yf-00 for namedroppers@ops.ietf.org; Tue, 12 Sep 2000 07:07:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200009120127.SAA01644@toad.com> To: Olafur Gudmundsson cc: DNSEXT WG Mailing list , gnu@toad.com Subject: Re: WG Last call: RSA-SHA1 In-reply-to: <4.3.2.7.2.20000908023743.00bade00@localhost> Date: Mon, 11 Sep 2000 18:27:00 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This is a last call on this document, This document defines a new > Signature algorithm transform RSA/SHA1 to replace RSA/MD5 (alg 1) > currently defined in RFC2537. > > This document contains text similar to what is in RFC2537 but changing > the message digest algorithm. The draft also makes RSA/SHA1 a MANDATORY > to implement. > > This is a WG last call ending September 20'th 2000 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-01.txt There is no document at this URL. (There is a -00 version though.) Please repost the last-call once a proposed document exists. > This draft will replace RFC2537 on standards track, and obsoletes RFC2537. > If you disagree with above action please state why, this document is > not ready or if this should not be done. I disagree with the above action. I believe that RFC 2537 should not be obsoleted. It is a valid algorithm identifier, already in use in widely deployed code, and should remain part of the standard. RFC 2537 is currrently merely "recommended", not required. The text in the -00 document is unclear about whether to use algorithm #1 or #5 in KEY records. It should state that either is appropriate, since the selection of hash algorithm for signing does not affect the key. It should also note (as pointed out by Brian Wellington) that the algorithm number used will change the calculation of the 'key tag' field in any SIG records created using this key, since algorithm #1 used an early method, while all other algorithms use a checksum. > The draft also makes RSA/SHA1 a MANDATORY to implement. I'm confused -- has consensus flipped again in the RSA/DSA debate? Do we now agree that RSA should be mandatory? Do the IESG and IAB also agree? They were the ones who shat on the idea originally. If RSA is really going to be mandatory, then I think algorithm 1 as well as 5 should be mandatory, for interoperability. John to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 12 07:50:21 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00418 for ; Tue, 12 Sep 2000 07:50:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13Ynvk-000Kvq-00 for namedroppers-data@psg.com; Tue, 12 Sep 2000 04:08:48 -0700 Received: from dhcp070.ripemtg.ripe.net ([193.0.4.70] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13Ynvj-000Kvj-00 for namedroppers@ops.ietf.org; Tue, 12 Sep 2000 04:08:47 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Ynvh-0002A4-00 for namedroppers@ops.ietf.org; Tue, 12 Sep 2000 13:08:45 +0200 Message-Id: <200009121049.GAA28459@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-rsa-01.txt Date: Tue, 12 Sep 2000 06:49:13 -0400 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 : RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-rsa-01.txt Pages : 8 Date : 11-Sep-00 Since the adoption of a Proposed Standard for RSA signatures in the DNS [RFC 2537], advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG resource records (RRs). The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-01.txt 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-rsa-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-rsa-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: <20000911143231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rsa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rsa-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000911143231.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. From owner-namedroppers@ops.ietf.org Tue Sep 12 10:49:06 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05516 for ; Tue, 12 Sep 2000 10:49:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13Yqrs-000MtM-00 for namedroppers-data@psg.com; Tue, 12 Sep 2000 07:17:00 -0700 Received: from dhcp070.ripemtg.ripe.net ([193.0.4.70] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13Yqrr-000MtG-00 for namedroppers@ops.ietf.org; Tue, 12 Sep 2000 07:17:00 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Yqrq-0002Qu-00 for namedroppers@ops.ietf.org; Tue, 12 Sep 2000 16:16:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200009120127.SAA01644@toad.com> References: <4.3.2.7.2.20000908023743.00bade00@localhost> Date: Tue, 12 Sep 2000 10:14:34 -0400 To: John Gilmore From: Edward Lewis Subject: Re: WG Last call: RSA-SHA1 Cc: Olafur Gudmundsson , DNSEXT WG Mailing list , gnu@toad.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 9:27 PM -0400 9/11/00, John Gilmore wrote: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-01.txt > >There is no document at this URL. (There is a -00 version though.) >Please repost the last-call once a proposed document exists. I see a document at that location... >If RSA is really going to be mandatory, then I think algorithm 1 as >well as 5 should be mandatory, for interoperability. The thinking is that RSA patent will expire RSN, and since MD5 is shakey, only SHA-1 will be promoted to "mandatory to implement." -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 12 11:52:00 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07411 for ; Tue, 12 Sep 2000 11:52:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13Yroj-000Ncj-00 for namedroppers-data@psg.com; Tue, 12 Sep 2000 08:17:49 -0700 Received: from dhcp070.ripemtg.ripe.net ([193.0.4.70] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13Yroi-000Ncd-00 for namedroppers@ops.ietf.org; Tue, 12 Sep 2000 08:17:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Yrog-0002WS-00 for namedroppers@ops.ietf.org; Tue, 12 Sep 2000 17:17:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200009121504.LAA17685@torque.pothole.com> To: John Gilmore cc: DNSEXT WG Mailing list Subject: Re: WG Last call: RSA-SHA1 In-reply-to: Your message of "Mon, 11 Sep 2000 18:27:00 PDT." <200009120127.SAA01644@toad.com> Date: Tue, 12 Sep 2000 11:04:06 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, From: John Gilmore Message-Id: <200009120127.SAA01644@toad.com> To: Olafur Gudmundsson cc: DNSEXT WG Mailing list , gnu@toad.com In-reply-to: <4.3.2.7.2.20000908023743.00bade00@localhost> Date: Mon, 11 Sep 2000 18:27:00 -0700 >> This is a last call on this document, This document defines a new >> Signature algorithm transform RSA/SHA1 to replace RSA/MD5 (alg 1) >> currently defined in RFC2537. >> >> This document contains text similar to what is in RFC2537 but changing >> the message digest algorithm. The draft also makes RSA/SHA1 a MANDATORY >> to implement. >> >> This is a WG last call ending September 20'th 2000 >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-01.txt > >There is no document at this URL. (There is a -00 version though.) >Please repost the last-call once a proposed document exists. My apologies for not cc'ing the list when I sent this in to I-D. It's there now. I suggest the last call ending just be extended by a few days. >> This draft will replace RFC2537 on standards track, and obsoletes RFC2537. >> If you disagree with above action please state why, this document is >> not ready or if this should not be done. > >I disagree with the above action. I believe that RFC 2537 should not >be obsoleted. It is a valid algorithm identifier, already in use in >widely deployed code, and should remain part of the standard. > >RFC 2537 is currrently merely "recommended", not required. I gather from this that you think that RSA-MD5 signatures are strong and will reamin so for some time despite the weaknesses that have been identified in MD5? Declaring RSA-MD5 signatures obsolete does not make any deployed code stop working, it just tells everyone that they should move will all deliberate speed to upgrade to RSA-SHA1. >The text in the -00 document is unclear about whether to use algorithm >#1 or #5 in KEY records. It should state that either is appropriate, >since the selection of hash algorithm for signing does not affect the >key. It should also note (as pointed out by Brian Wellington) that >the algorithm number used will change the calculation of the 'key tag' >field in any SIG records created using this key, since algorithm #1 >used an early method, while all other algorithms use a checksum. The intend is to mandate algorithm #5 for RSA KEYS RRs. This is certainly a debatable point and they could have all been left with algorithm #1 since, as you say, the RSA key is independent of the hash algorithm. Or both could be allowed, but that seems more complex. All of this points up the problem with leaving both algorithms as approved for use: when/if MD5 is broken, then bad guys can forge RSA-MD5 signatures based on the RSA KEYs that are in the DNS or are preconfigured in resolvers even if the keys are there with the intent that they be used with RSA-SHA1, which is generally acknowledged to be stronger. And having two different KEY RR algorithm numbers to distinguish these is no help, except for pre-configured KEY RRs, because the bad guys can change the algorithm number. >> The draft also makes RSA/SHA1 a MANDATORY to implement. > >I'm confused -- has consensus flipped again in the RSA/DSA debate? >Do we now agree that RSA should be mandatory? Do the IESG and IAB >also agree? They were the ones who shat on the idea originally. Yes, there seems to a ground swell of feeling that RSA should be mandatory. >If RSA is really going to be mandatory, then I think algorithm 1 as >well as 5 should be mandatory, for interoperability. In my opinon, this guarantees that things will only be as strong as the weaker of the two algorithms. > John Donald to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 13:36:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21094 for ; Tue, 19 Sep 2000 13:36:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bQah-0005AD-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 09:49:55 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bQah-0005A7-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 09:49:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bQah-0009D6-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 09:49:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 19 Sep 2000 11:17:40 -0400 To: DNSEXT WG Mailing list From: Edward Lewis Subject: Same-signed keys Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Earlier in the month, a couple of DNSSEC workshops were held in Europe. One of the issues was whether the following is possible: The zone: $origin somedomain.xy @ SOA KEY key #1 KEY key #2 SIG KEY by key #1 SIG KEY by key #2 data A address SIG A by key #2 (and all the other needed records) The distributed key is key #1 (NOT #2). When the A record for data is received, here is the chain of trust: data A is secured by SIG(A) signed by key #2 key #2 is secured by SIG(KEY) signed by key #1 key #1 is implicitly trusted because it is configured in resolvers This seems like a plausable way to "privately" (old term) or "locally" (newer term) secure a zone. But there is one problem, BIND 9(rc5 at least) enforced a rule that a key set must be signed by a name at least one label shorter that the owner's name. The reason - to make sure the chain of trust progresses to the root at each step. Brian had the following idea, and I figured it needed to be aired out in the mailing list. There is a clear reason to allow key #1 to sign key #2 and for the above example to work. There is also a clear reason to prevent arbitratily long chains of trust to be imposed on resolvers. To mediate this, the rule of short names signing longer names will stand with the exception that for a resolver, at preconfigured points of trust (e.g., key #1's owner), keys of the same set may be used to validate the others - i.e., an exception to the "always shorter" rule. This seems to be acceptable to me. Comments? PS - This should be reflected in the signing authority draft. PPS - The rules regarding who can sign for what say that signers must be < or = to the length of the data, hence the BIND s/w is overly restrictive as far as the spec is concerned. However, the restriction is well-intentioned as it makes sense that the signer of a keyset is always < (label-depth-wise) the owner of the key set except at locally pre-configured points. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 15:44:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23678 for ; Tue, 19 Sep 2000 15:44:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bSbJ-0006lG-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 11:58:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bSbJ-0006lA-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 11:58:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bSbI-000A7S-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 11:58:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200009191855.e8JItgT19659@sh.lh.vix.com> To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: Same-signed keys In-reply-to: Your message of "Tue, 19 Sep 2000 11:17:40 EDT." Date: Tue, 19 Sep 2000 11:55:42 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is there a technical reason to "prevent arbitratily long chains of trust to be imposed on resolvers"? I think I understand the reasons why this is suboptimal, and can require a significant increase in computational effort and number of queries. I don't see why this needs to be prevented. I do remember specific reasons to prevent have a sig that is not in the same tree, and I think that prohibition should remain in place. This case does not violate that problem. What it seems to me a better solution is to relax the test such that the test is for keys that are at the same level or closer to the root. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 16:27:10 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24345 for ; Tue, 19 Sep 2000 16:27:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bTME-0007Qn-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 12:47:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bTMD-0007Qh-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 12:47:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bTMD-000ASF-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 12:47:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <006801c02271$92928aa0$b9370681@antd.nist.gov> From: "Scott Rose" To: "DNSEXT WG Mailing list" References: Subject: Re: Same-signed keys Date: Tue, 19 Sep 2000 15:41:14 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit *snip* > Brian had the following idea, and I figured it needed to be aired out in > the mailing list. > > There is a clear reason to allow key #1 to sign key #2 and for the above > example to work. There is also a clear reason to prevent arbitratily long > chains of trust to be imposed on resolvers. To mediate this, the rule of > short names signing longer names will stand with the exception that for a > resolver, at preconfigured points of trust (e.g., key #1's owner), keys of > the same set may be used to validate the others - i.e., an exception to the > "always shorter" rule. > > This seems to be acceptable to me. Comments? > I agree. Since incremental deployment is an issue, a need for providing a means to "locally" or "privately" secure zone exists. If I remember, the CAIRN testbed used to have a KEY signing key that was statically configured having the name "cairn.net". This was different than the cain.net key used to sign the cain.net zone. The most obvious threat to allowing signers name = KEY name is the creation of KEY chains like CNAME chains. Perhaps keys with the same name length as the data to be verified should only be allowed if the key is statically configured? Just an idea, there is some good and bad "wiggle room" in the RFC. Scott =============================================================== Scott Rose Advanced Network Technologies Division NIST ph: 301-975-8439 fax: 301-590-0932 http://www.nist.gov =============================================================== > PS - This should be reflected in the signing authority draft. > > PPS - The rules regarding who can sign for what say that signers must be < > or = to the length of the data, hence the BIND s/w is overly restrictive as > far as the spec is concerned. However, the restriction is well-intentioned > as it makes sense that the signer of a keyset is always < > (label-depth-wise) the owner of the key set except at locally > pre-configured points. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > "It takes years of training to know when to do nothing" - Dogbert > > Opinions expressed are property of my evil twin, not my employer. > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 16:35:36 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24486 for ; Tue, 19 Sep 2000 16:35:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bTcM-0007fq-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 13:03:50 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bTcM-0007fk-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 13:03:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bTcM-000AZT-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 13:03:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Lewis cc: DNSEXT WG Mailing list Subject: Re: Same-signed keys In-Reply-To: Message from Edward Lewis dated "Tue, 19 Sep 2000 13:59:55 EDT" References: From: Rob Austein Message-Id: <20000919200217Z23214-225+274@thrintun.hactrn.net> Date: Tue, 19 Sep 2000 16:02:11 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't see why this situation is fundamentally different from all the other forms of potential infinite loops in DNS (eg, CNAME loops). The traditional solution is a simple counter (RFC-1035, p43, last paragraph). If the only issue here is preventing infinite loops, I don't think that either form of the "always shorter" rule is necessary or desirable. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 18:41:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25903 for ; Tue, 19 Sep 2000 18:41:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bVY7-0009aZ-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 15:07:36 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bVY7-0009aT-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:07:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bVY7-000BR8-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:07:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <20000919200217Z23214-225+274@thrintun.hactrn.net> References: Message from Edward Lewis dated "Tue, 19 Sep 2000 13:59:55 EDT" Date: Tue, 19 Sep 2000 16:39:23 -0400 To: Rob Austein From: Edward Lewis Subject: Re: Same-signed keys Cc: Edward Lewis , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The only fundamental difference (if that) is the expense of each operation. Are you suggesting that the BIND code should just make sure the signer label length is <= (as opposed to strictly <) the owner length? (As the current specs require.) At 4:02 PM -0400 9/19/00, Rob Austein wrote: >I don't see why this situation is fundamentally different from all the >other forms of potential infinite loops in DNS (eg, CNAME loops). The >traditional solution is a simple counter (RFC-1035, p43, last >paragraph). If the only issue here is preventing infinite loops, I >don't think that either form of the "always shorter" rule is necessary >or desirable. I think that there is another fundamental issue here though, that is either tangential or orthoginal. Preventing loops is one issue, but so is "authorization" - the "right" to sign / authenticate data. This latter issue is what is driving Signing Authority (close to be moved through the IESG). There's a subtle difference between urging BIND to: 1) Only enforce the <= rule and 2) Not enforce the < rule The difference is that with #2, "on-tree" validation checks are still done. PS - The reason that "sideways" authentication is only allowed at preconfigured points is that this is the only situation in which it makes sense. E.g.: At parent: key #0 At child: key #1, #2. Child signs zone with #2, distrbutes #1. But also, child sends keys to parent for authentication, so {#1,#2} are both signed together by #0. Upon validation, a resolver could have data->key #2->key #1->key #0. More likely, the resolver would see either data->key #2->key #0 or data->key #2->key #1. In the latter situation, key #1 would be preconfigured, in the former, it is not. I hope that resolvers prefer to shorten the key chaining effort (e.g., using preconfigured keys over climbing further)... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 18:43:11 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25924 for ; Tue, 19 Sep 2000 18:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bVVm-0009Y1-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 15:05:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bVVl-0009Xv-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:05:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bVVl-000BQE-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:05:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200009191855.e8JItgT19659@sh.lh.vix.com> References: Your message of "Tue, 19 Sep 2000 11:17:40 EDT." Date: Tue, 19 Sep 2000 16:22:20 -0400 To: Jerry Scharf From: Edward Lewis Subject: Re: Same-signed keys Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 2:55 PM -0400 9/19/00, Jerry Scharf wrote: > Is there a technical reason to "prevent arbitratily long chains of trust > to be >imposed on resolvers"? Yes. Ohh, umm, I figure I should back that up, huh... W/o such prevention, a clogging (DOS) attack could be launched by simply getting someone to query for data signed by a key that is signed by another and another and another ... possibly into an infinite loop of authentications. Crypto operations are a great amplification-of-effort tool that an attacker may use to leverage the amount of damage that can be caused. We want to limit the number of "free" crypto operations available to arbitrary data. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 18:45:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25943 for ; Tue, 19 Sep 2000 18:45:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bVZR-0009cu-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 15:08:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bVZR-0009cn-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:08:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bVZR-000BRr-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:08:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000919224441.06954e20@127.0.0.1> Date: Tue, 19 Sep 2000 22:47:25 +0200 To: Edward Lewis , DNSEXT WG Mailing list From: Harald Alvestrand Subject: Re: Same-signed keys Cc: lewis@tislabs.com In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:17 19/09/2000 -0400, Edward Lewis wrote: >To mediate this, the rule of >short names signing longer names will stand with the exception that for a >resolver, at preconfigured points of trust (e.g., key #1's owner), keys of >the same set may be used to validate the others - i.e., an exception to the >"always shorter" rule. it is not possible to deduct that a node in the DNS tree is or is not a preconfigured point of trust by looking at it - because this configuration is not stored in the DNS. However, it seems harmless to me to say that self-signed keys are allowed - that is, the subject and the name of the key are the same. This particular infinite loop is always closed after one hop....easily checked for; applications that don't have trust in this key preconfigured MUST ignore this SIG when deciding whether to trust the key. Harald Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 18:51:38 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26018 for ; Tue, 19 Sep 2000 18:51:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bVm9-000A5q-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 15:22:05 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bVm8-000A5k-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:22:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bVm8-000BY8-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:22:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000919170254.00b98b60@localhost> Date: Tue, 19 Sep 2000 17:10:05 -0400 To: Rob Austein , Edward Lewis From: Olafur Gudmundsson Subject: Re: Same-signed keys Cc: DNSEXT WG Mailing list In-Reply-To: <20000919200217Z23214-225+274@thrintun.hactrn.net> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 04:02 PM 9/19/00, Rob Austein wrote: >I don't see why this situation is fundamentally different from all the >other forms of potential infinite loops in DNS (eg, CNAME loops). The >traditional solution is a simple counter (RFC-1035, p43, last >paragraph). If the only issue here is preventing infinite loops, I >don't think that either form of the "always shorter" rule is necessary >or desirable. No, the main issue is: Do we need to explicitly state that pre-configured trusted keys are allowed to validate the key set they belong to? RFC2535 and Signing-Authority do not clearly address this. The general rule is that KEY set is allays signed by it's parent with the exception off the root key set. I think we should allow this as it will make it simpler to create "islands of security" and assists in initial roll out of DNSSEC. Off tree validation is a separate topic. 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. From owner-namedroppers@ops.ietf.org Tue Sep 19 19:05:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26230 for ; Tue, 19 Sep 2000 19:05:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bVwZ-000AV2-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 15:32:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bVwY-000AUw-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:32:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bVwY-000BdX-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:32:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C7E02D.3E06F511@aurora.rg.iupui.edu> Date: Tue, 19 Sep 2000 16:52:45 -0500 From: Gunther Schadow To: namedroppers@ops.ietf.org, Harald@alvestrand.no Subject: What are the chances for OID resource records in the DNS? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a proposal for a careful DNS extension that I would love to have your opinion on. The ISO Object Identifier scheme becomes increasingly important. Particularly as the Internet adopts more and more OSI based protocols, such as X.509, we see a lot of use for OIDs. In addition, OIDs are a very useful identifier scheme since they allow a fully distributed management with little technical overhead (unlike UUIDs or GUIDs). Looking at an OID in the format suggested by RFC 1778, the most impressing thing about OIDs is that they are very much like DNS domain names or IPv4 addresses. I.e., OIDs are simple sequences of positive integer numbers separated by dots. Similar to IPv4 addresses the left side of an OID is more significant than the right side. Unlike IPv4 addresses, the range of the numbers between the dots is not constrained to 255 and the length of the OID is not constrained to four numbers. RFC 1778 also suggests the use of symbolic OID parts on the left side. Even though the OID scheme is in use since the late 80th, there has never been any attempt to somehow publicly account for the assignment of those OIDs. Harald Alvestrand went through great pain to put up some OID registry at http://www.alvestrand.no/~hta/objectid/. Yet this registry is neither complete nor does it scale. LDAP is what remains today from the X.500 idea (that brought forth the OID too) While LDAP could support an OID directory architecture it seems as if LDAP directories are not really designed or used for a truly distributed structure. This is where I believe DNS comes in. The DNS is an existing infrastructure that can carry simple directory information. Basically what I would suggest is the addition of some DNS resource records or, alternatively a new DNS record class. There are two principal use cases: 1) Given an OID one wants to understand what that OID means. 2) Given a symbolic OID part (as of RFC 1778) one wants to find out the numeric OID. The first use case occurs at human speed, the second use case occurs at machine speed. That is, only humans are so curious as to searching for some "meaning" of an OID. A few TXT records are probably all they need. (Note: OIDs are not an addressing scheme, so there is no processing that depends on the resolution of OIDs.) If, as RFC 1778 suggests, one should use symbolic OID parts, then machines should be able to resolve those symbolic OID parts to return the numeric OID. Note that with OIDs only the numbers are canonical. Those symbolic OID parts may change over time, i.e., the ITU-T was formally called CCITT. So, the backbone the OID system is those numbers, the names are merely aliases. For example, let's say my organization, Health Level-7 (HL7) has been given the number 113883 from ANSI. ANSI maintains the branch 2.16.840.1, so HL7's OID is 2.16.840.1.113883. Write this in the reverse order, and put a toplevel domain at the end and you have a normal DNS domain name: 113883.1.840.16.2.OID.ISO This is like the IN PTR records 122.31.68.134.IN-ADDR.ARPA. So, ANSI's DNS zone file could contain the following entry for this record: 113883.1.840.16.2.OID.ISO IN TXT "Health Level-7, Ann Arbor, MI" IN TXT "URL:http://www.hl7.org" alternatively, and more likely, HL7 would want to have authority over its OID namespace on the DNS and so the ANSI zone file would contain only 113883.1.840.16.2.OID.ISO IN NS dns.hl7.org. then HL7's zone file would be @ IN SOA 113883.1.840.16.2.OID.ISO. oidmaster ( ... ) IN NS dns.hl7.org. IN TXT "Health Level-7, Ann Arbor, MI" IN TXT "URL:http://www.hl7.org" oidmaster IN TXT "Gunther Schadow" IN TXT "URL:tel:+13176307960" 3 IN TXT "HL7 Registered Organizations" 4 IN TXT "HL7 Registered External Identifiers" 5 IN TXT "HL7 Code Tables" 6 IN TXT "HL7 Registered External Coding Systems" You see how the TXT records define the meaning of the OID branches sufficiently for human consumption. You also see that nothing needs to be added to the DNS itself to make this zone file work. The only thing that needs to be in place is the OID.ISO. domain name and its maintenance. Given that there is not a very good relatioship between IETF and ISO, and most subtrees of ISO, the IANA could for some time be a non-authoritative root for the OID DNS. This could be bootstrapped from Harald Alvestrands database. In addition one could ask ISO whether they want to take this over. The idea of the "non- authoritative root" is that it would have all assignments that are known in the community but that noone else has claimed authority. At any time an organization such as ANSI or ISO could come and claim their branches and set up their own SOA. OID records would be allowed to act like "glue-records", that is the superordiante NS would make OID assignments. Thus the ANSI NS would contain @ SOA 1.840.16.2.oid.iso. ... ( ... ) ... 113883 IN OID 2.16.840.1.113883 IN NS dns.hl7.org. hl7 IN CNAME 113883 (Note: when I used TXT records to carry the OID I would receive zone errors from BIND because it doesn't allow TXT to be used in the glus-record style. So I had to defer the OID assignment to the sub- domain zone. SYMBOLIC OID PARTS Basically, those symbolic OID parts are aliases for an OID. For example "HL7" could be an alias for the canonical oid "2.16.840.1.113883". Another alias for that OID could be "joint-iso-itu-t.country.us.org.hl7". Now, to comply with the spirit of the DNS we have to reverse these names and have to attach them to a top-level domain: hl7.org. being a valid DNS name could assign an OID record to itself: hl7.org. IN OID 2.16.840.1.113883 OID records would act similar as A records. The long winded symbolic name for HL7 would be: hl7.org.us.country.joint-iso-itu-t.iso. IN OID 2.16.840.1.113883 Note that the canonical name of the OID is always the number form, so there is no need for reverse mapping PTR records. The ultimate resolution of the OID is at the most a TXT record that may include a URL reference or something. This aliasing could be done without a special resource record type by just using CNAMEs. Thus, for example we would have a hl7.org.us.country.joint-iso-itu-t.iso. IN CNAME 113883.1.840.16.2.OID.ISO. However, this would not allow us to use HL7.org as a name for both an IP address and an OID. Therefore I think that an OID record type similar to the A or AAAA record types is in fact needed. COMBINATION OF NUMERIC AND SYMBOLIC OID PARTS There is a third extension to the DNS that we need to sensibly use the DNS for OID management, and I may be wrong here. That requirement is about the following problem. I want all of the following named OIDs to resolve to the same numeric OIDs: hl7.org.us.country.joint-iso-itu-t.oid.iso. 113883.org.us.country.joint-iso-itu-t.oid.iso. 113883.1.us.country.joint-iso-itu-t.oid.iso. 113883.1.840.country.joint-iso-itu-t.oid.iso. 113883.1.840.16.joint-iso-itu-t.oid.iso. 113883.1.840.16.2.oid.iso. The only way I found I could do this with BIND was to define a zone for each of these 6 variants. When HL7 now delegates some of its sub-branches to someone else, that person would have to define 7, 8, 9, 10 or more zones just in order to map all combinations of numeric and symbolic forms. And that doesn't even cover something like: hl7.org.us.16.2.oid.iso. hl7.1.840.16.2.oid.iso. hl7.1.us.16.2.oid.iso. etc. So, the functional extension of the DNS system I would propose is that when the resource type of the DNS query is OID, then the DNS server should resolve as much of the symbolic OID parts as possible starting from the most significant part. That way, zone files would only need to be defined for the numbered form and the DNS system would resolve the symbols from the most significant symbol down on its way through the NS graph. In the case of "hl7.1.us.16.2.oid.iso." it would take oid.iso. as one well known domain asking the OID root NS for 16.2.oid.iso.'s NS. That NS would be asked to resolve "us" and then to ask the NS of 1.840 for what "hl7" is. That cascade would return 113883.1.840.16.2.oid.iso. and eventually return that OID "2.16.840.1.113883". SUMMARY The DNS system seems very close to what would be needed to manage the Object Identifier scheme that would support human understanding of OIDs as well as resolving symbolic OID parts or other DNS names to OIDs. Only three additional conventions need to be established: 1. The root domain OID.ISO. that would be non-authoritatively managed by IANA until other organizations claim authority for the DNS management of their branches. 2. The resource record type OID that assigns OIDs to DNS names. 3. A special DNS name resolution where DNS names are resolved stepwise. (This may actually just be a change to the BIND implementation of DNS.) I would be glad for any reactions as to whether this might make sense to you. Especially, if you think that nothing is needed, I would appreciate your ideas on how to deal with the last problem (3) of the combinatorial explosion of symbol/number variances. thank you, -Gunther to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 19:18:02 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26288 for ; Tue, 19 Sep 2000 19:18:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bW9x-000B31-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 15:46:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bW9x-000B2s-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:46:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bW9x-000BkE-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 15:46:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200009192246.e8JMkCi68090@drugs.dv.isc.org> Cc: DNSEXT WG Mailing list From: Mark.Andrews@nominum.com Subject: Re: Same-signed keys In-reply-to: Your message of "Tue, 19 Sep 2000 16:02:11 EDT." <20000919200217Z23214-225+274@thrintun.hactrn.net> Date: Wed, 20 Sep 2000 09:46:12 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I don't see why this situation is fundamentally different from all the > other forms of potential infinite loops in DNS (eg, CNAME loops). The > traditional solution is a simple counter (RFC-1035, p43, last > paragraph). If the only issue here is preventing infinite loops, I > don't think that either form of the "always shorter" rule is necessary > or desirable. Supporting looping at the same level helps with really large zones or where very long lived keys are required as it can reduce the amount of clear text available per key. DNSSEC has only defined heirachical securing of zones. PGP style is not defined though it may at somestage be useful at some point in time. Have a knob that defaults to enforcing the heirachical nature is one way to go. Note this looping is within one RRset so it should be easy to detect infinite loops. With PGP style securing of zone it becomes harder but not impossible as the loops are potentially bigger. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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. From owner-namedroppers@ops.ietf.org Tue Sep 19 19:38:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26487 for ; Tue, 19 Sep 2000 19:38:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bWN5-000Bdv-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 16:00:15 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bWN5-000Bdp-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:00:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bWN5-000BqL-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:00:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Gunther Schadow Cc: namedroppers@ops.ietf.org, Harald@alvestrand.no Subject: Re: What are the chances for OID resource records in the DNS? In-Reply-To: Your message of "Tue, 19 Sep 2000 16:52:45 CDT." <39C7E02D.3E06F511@aurora.rg.iupui.edu> Date: Wed, 20 Sep 2000 09:57:06 +1100 Message-Id: <16881.969404226@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 19 Sep 2000 16:52:45 -0500 From: Gunther Schadow Message-ID: <39C7E02D.3E06F511@aurora.rg.iupui.edu> | 1. The root domain OID.ISO. that would be non-authoritatively managed by | IANA until other organizations claim authority for the DNS management | of their branches. Doing this would mean creating the new TLD ".ISO". New TLDs is a political quagmire that no-one here really wants to get involved in. Once created (if ever) the administrator of .ISO gets to decide if OID.ISO would get created or not, and if so, who would get to administer it. That last person gets to decide how it is used. | 2. The resource record type OID that assigns OIDs to DNS names. I couldn't actually figure out what you were trying to do with that record, it looks as if its purpose was to say X=X which doesn't really seem like a useful thing to do. | 3. A special DNS name resolution where DNS names are resolved stepwise. | (This may actually just be a change to the BIND implementation of DNS.) You proposed 2 significant changes to the DNS specification. One was to allow OID records (assuming there is some reason for them at all) to be allowed in the parent zone rather than in the zone where they belong. I see no rational reason for that one at all. The second was to allow CNAMES for non-terminal nodes. That is unlikely to ever happen (though at times it would make life easier) but there's an alternate (but very new and just about invisible in the wild yet) mechanism that has been proposed which would be an alternative. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 20:29:38 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26871 for ; Tue, 19 Sep 2000 20:29:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bXEq-000D5U-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 16:55:48 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bXEq-000D5O-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:55:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bXEq-000CBo-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:55:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 19 Sep 2000 16:20:41 -0700 (PDT) From: Brian Wellington To: Harald Alvestrand Cc: Edward Lewis , DNSEXT WG Mailing list Subject: Re: Same-signed keys In-Reply-To: <4.3.2.7.2.20000919224441.06954e20@127.0.0.1> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 19 Sep 2000, Harald Alvestrand wrote: > At 11:17 19/09/2000 -0400, Edward Lewis wrote: > >To mediate this, the rule of > >short names signing longer names will stand with the exception that for a > >resolver, at preconfigured points of trust (e.g., key #1's owner), keys of > >the same set may be used to validate the others - i.e., an exception to the > >"always shorter" rule. > > it is not possible to deduct that a node in the DNS tree is or is not a > preconfigured point of trust by looking at it - because this configuration > is not stored in the DNS. It's not possible to tell as an outsider. However, a resolver knows whether or not it has the preconfigured key. If it does, the validation can be attempted. If not, it cannot validate the data (and probably shouldn't have tried in the first place, since it likely has no reason to have started the validation process). > However, it seems harmless to me to say that self-signed keys are allowed - > that is, the subject and the name of the key are the same. > This particular infinite loop is always closed after one hop....easily > checked for; applications that don't have trust in this key preconfigured > MUST ignore this SIG when deciding whether to trust the key. Exactly. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 20:39:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26948 for ; Tue, 19 Sep 2000 20:39:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bXTz-000DM5-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 17:11:27 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bXTy-000DLz-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 17:11:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bXTy-000CIC-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 17:11:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Gunther Schadow Cc: namedroppers@ops.ietf.org, Harald@alvestrand.no Subject: Re: What are the chances for OID resource records in the DNS? In-Reply-To: Your message of "Tue, 19 Sep 2000 18:19:09 CDT." <39C7F46D.48960E01@aurora.rg.iupui.edu> Date: Wed, 20 Sep 2000 11:09:03 +1100 Message-Id: <17617.969408543@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 19 Sep 2000 18:19:09 -0500 From: Gunther Schadow Message-ID: <39C7F46D.48960E01@aurora.rg.iupui.edu> | well, I suppose one could use an existing TLD, say .ARPA. to form OID.ARPA. | :-) That is something which (if enough real potential for use, as distinct from just "it looks like a good fit", could be demonstrated) could actually be accomplished before we're all dead... | hl7.org. IN A 198.87.144.122 | hl7.org. IN OID 2.16.840.1.113883 | hl7.org. IN AAAA 3ffe:1ce0:123:1 | | here you have the same domain name hl7.org resolve to three different | address types. I couldn't do this if I had to use CNAMEs to assign | hl7.org. to the CNAME 113883.1.840.16.2.OID.ARPA. That's true. Is this something that has a use? | I suppose I can still use TXT records that by convention start with | OID for that purpose. No, don't do that. But you could use a PTR h17.org. IN PTR 113883.1.840.16.2.OID.ARPA. (or whatever tree it ends up in). Generating the OID out of that is not difficult... | Are you saying that there is an alternative other than creating so many | zones? What is that alternative? Would you please drop some hint? See rfc2672 ... but don't expect lots of support for it yet. What you need to do next is to explain just what the real world uses for having this information in the DNS tree will be (not could be, but really will be). Without that, there isn't going to be much enthusiasm. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 20:45:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27039 for ; Tue, 19 Sep 2000 20:45:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bXFA-000D60-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 16:56:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bXFA-000D5u-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:56:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bXFA-000CBr-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:56:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: from aurora.rg.iupui.edu ([134.68.31.122]) by psg.com with esmtp (Exim 3.16 #1) id 13bWi0-000CTl-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:21:53 -0700 Received: from aurora.rg.iupui.edu (schadow_g.regenstrief.iupui.edu [134.68.31.121]) by aurora.rg.iupui.edu (8.9.3/8.9.3) with ESMTP id SAA78894; Tue, 19 Sep 2000 18:18:35 -0500 (EST) (envelope-from gunther@aurora.rg.iupui.edu) Message-ID: <39C7F46D.48960E01@aurora.rg.iupui.edu> Date: Tue, 19 Sep 2000 18:19:09 -0500 From: Gunther Schadow To: Robert Elz CC: namedroppers@ops.ietf.org, Harald@alvestrand.no Subject: Re: What are the chances for OID resource records in the DNS? References: <16881.969404226@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > | 1. The root domain OID.ISO. that would be non-authoritatively managed by > | IANA until other organizations claim authority for the DNS management > | of their branches. > > Doing this would mean creating the new TLD ".ISO". New TLDs is a > political quagmire that no-one here really wants to get involved in. > > Once created (if ever) the administrator of .ISO gets to decide if > OID.ISO would get created or not, and if so, who would get to administer > it. That last person gets to decide how it is used. well, I suppose one could use an existing TLD, say .ARPA. to form OID.ARPA. :-) I guess what I want is to heavy-lift the entire OID train on the DNS rails. This may be a bit too ambitious. I just thought that if the IETF finds a DNS based global OID directory useful, it might be something one could do gradually. > | 2. The resource record type OID that assigns OIDs to DNS names. > > I couldn't actually figure out what you were trying to do with that > record, it looks as if its purpose was to say X=X which doesn't really > seem like a useful thing to do. I agree that a record such as this: 113883.1.840.16.2.OID.ARPA. IN OID 2.16.840.1.113883 looks a lot like X=X. When we had CNAMEs for non-terminal nodes, we could do all the OID symbol to numeric translation through CNAMEs? But, look at this: hl7.org. IN A 198.87.144.122 hl7.org. IN OID 2.16.840.1.113883 hl7.org. IN AAAA 3ffe:1ce0:123:1 here you have the same domain name hl7.org resolve to three different address types. I couldn't do this if I had to use CNAMEs to assign hl7.org. to the CNAME 113883.1.840.16.2.OID.ARPA. I suppose I can still use TXT records that by convention start with OID for that purpose. So, this OID RR type is not necessarily the one that plagues me most. What plagues me most is this: > | 3. A special DNS name resolution where DNS names are resolved stepwise. > | (This may actually just be a change to the BIND implementation of DNS.) > > You proposed 2 significant changes to the DNS specification. [...] > The second was to allow CNAMES for non-terminal nodes. That is unlikely > to ever happen (though at times it would make life easier) but there's > an alternate (but very new and just about invisible in the wild yet) > mechanism that has been proposed which would be an alternative. Are you saying that there is an alternative other than creating so many zones? What is that alternative? Would you please drop some hint? Thank you, -Gunther to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 20:48:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27084 for ; Tue, 19 Sep 2000 20:48:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bXFN-000D69-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 16:56:21 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bXFN-000D63-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:56:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bXFN-000CBy-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 16:56:21 -0700 Message-Id: <3.0.32.20000919192343.01c953c0@odie.av8.com> Date: Tue, 19 Sep 2000 19:24:09 -0400 To: Gunther Schadow , namedroppers@ops.ietf.org, Harald@alvestrand.no From: Dean Anderson Subject: Re: What are the chances for OID resource records in the DNS? Mime-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Around 04:52 PM 09/19/2000 -0500, rumor has it that Gunther Schadow said: >Hi, > >I have a proposal for a careful DNS extension that I would love to have >your opinion on. > >The ISO Object Identifier scheme becomes increasingly important. Particularly >as the Internet adopts more and more OSI based protocols, such as X.509, we >see a lot of use for OIDs. In addition, OIDs are a very useful identifier >scheme since they allow a fully distributed management with little technical >overhead (unlike UUIDs or GUIDs). You seem to misunderstand how UUID's work. While OID's are assigned like domain names by a managing organization and the assignee is able to "subdomain", by contrast UUID's are generated by the creator/developer, and are guarenteed to be unique by the generator. UUID's have zero technical/management overhead. The only disadvantage is that you wind up having large, unordered lists of them, making them unwieldy to search without a database. As a matter of history, I thought OID's came from SNMP ;-) As an SNMP user (MIB-Looker-Upper), I think your idea has some merit, but I'm not sure DNS is the right protocol. I'd think an LDAP server would be well suited to handle this kind of data. Rather, a publicly accessible LDAP server... --Dean > >Looking at an OID in the format suggested by RFC 1778, the most impressing >thing about OIDs is that they are very much like DNS domain names or IPv4 >addresses. I.e., OIDs are simple sequences of positive integer numbers >separated by dots. Similar to IPv4 addresses the left side of an OID is more >significant than the right side. Unlike IPv4 addresses, the range of the >numbers between the dots is not constrained to 255 and the length of the OID >is not constrained to four numbers. RFC 1778 also suggests the use of >symbolic OID parts on the left side. > >Even though the OID scheme is in use since the late 80th, there has never >been any attempt to somehow publicly account for the assignment of those >OIDs. Harald Alvestrand went through great pain to put up some OID >registry at http://www.alvestrand.no/~hta/objectid/. Yet this registry >is neither complete nor does it scale. > >LDAP is what remains today from the X.500 idea (that brought forth >the OID too) While LDAP could support an OID directory architecture it >seems as if LDAP directories are not really designed or used for a >truly distributed structure. > >This is where I believe DNS comes in. The DNS is an existing infrastructure >that can carry simple directory information. Basically what I would suggest >is the addition of some DNS resource records or, alternatively a new DNS >record class. > >There are two principal use cases: > >1) Given an OID one wants to understand what that OID means. > >2) Given a symbolic OID part (as of RFC 1778) one wants to find out > the numeric OID. > >The first use case occurs at human speed, the second use case occurs >at machine speed. That is, only humans are so curious as to searching >for some "meaning" of an OID. A few TXT records are probably all they >need. (Note: OIDs are not an addressing scheme, so there is no processing >that depends on the resolution of OIDs.) > >If, as RFC 1778 suggests, one should use symbolic OID parts, then >machines should be able to resolve those symbolic OID parts to return >the numeric OID. > >Note that with OIDs only the numbers are canonical. Those symbolic OID >parts may change over time, i.e., the ITU-T was formally called CCITT. >So, the backbone the OID system is those numbers, the names are merely >aliases. For example, let's say my organization, Health Level-7 (HL7) has >been given the number 113883 from ANSI. ANSI maintains the branch 2.16.840.1, >so HL7's OID is 2.16.840.1.113883. Write this in the reverse order, and >put a toplevel domain at the end and you have a normal DNS domain name: > >113883.1.840.16.2.OID.ISO > >This is like the IN PTR records 122.31.68.134.IN-ADDR.ARPA. So, ANSI's >DNS zone file could contain the following entry for this record: > >113883.1.840.16.2.OID.ISO IN TXT "Health Level-7, Ann Arbor, MI" > IN TXT "URL:http://www.hl7.org" > >alternatively, and more likely, HL7 would want to have authority over its >OID namespace on the DNS and so the ANSI zone file would contain only > >113883.1.840.16.2.OID.ISO IN NS dns.hl7.org. > >then HL7's zone file would be > >@ IN SOA 113883.1.840.16.2.OID.ISO. oidmaster ( ... ) > IN NS dns.hl7.org. > IN TXT "Health Level-7, Ann Arbor, MI" > IN TXT "URL:http://www.hl7.org" >oidmaster IN TXT "Gunther Schadow" > IN TXT "URL:tel:+13176307960" > >3 IN TXT "HL7 Registered Organizations" >4 IN TXT "HL7 Registered External Identifiers" >5 IN TXT "HL7 Code Tables" >6 IN TXT "HL7 Registered External Coding Systems" > >You see how the TXT records define the meaning of the OID branches sufficiently >for human consumption. You also see that nothing needs to be added to the DNS >itself to make this zone file work. > >The only thing that needs to be in place is the OID.ISO. domain name >and its maintenance. Given that there is not a very good relatioship >between IETF and ISO, and most subtrees of ISO, the IANA could for >some time be a non-authoritative root for the OID DNS. This could be >bootstrapped from Harald Alvestrands database. In addition one could >ask ISO whether they want to take this over. The idea of the "non- >authoritative root" is that it would have all assignments that are >known in the community but that noone else has claimed authority. At >any time an organization such as ANSI or ISO could come and claim their >branches and set up their own SOA. > >OID records would be allowed to act like "glue-records", that is the >superordiante NS would make OID assignments. Thus the ANSI NS would >contain > >@ SOA 1.840.16.2.oid.iso. ... ( ... ) > ... >113883 IN OID 2.16.840.1.113883 > IN NS dns.hl7.org. >hl7 IN CNAME 113883 > >(Note: when I used TXT records to carry the OID I would receive zone >errors from BIND because it doesn't allow TXT to be used in the >glus-record style. So I had to defer the OID assignment to the sub- >domain zone. > > >SYMBOLIC OID PARTS > >Basically, those symbolic OID parts are aliases for an OID. For example >"HL7" could be an alias for the canonical oid "2.16.840.1.113883". Another >alias for that OID could be "joint-iso-itu-t.country.us.org.hl7". Now, >to comply with the spirit of the DNS we have to reverse these names and >have to attach them to a top-level domain: > >hl7.org. being a valid DNS name could assign an OID record to itself: > >hl7.org. IN OID 2.16.840.1.113883 > >OID records would act similar as A records. The long winded symbolic >name for HL7 would be: > >hl7.org.us.country.joint-iso-itu-t.iso. IN OID 2.16.840.1.113883 > >Note that the canonical name of the OID is always the number form, >so there is no need for reverse mapping PTR records. The ultimate >resolution of the OID is at the most a TXT record that may include >a URL reference or something. > >This aliasing could be done without a special resource record type >by just using CNAMEs. Thus, for example we would have a > >hl7.org.us.country.joint-iso-itu-t.iso. IN CNAME 113883.1.840.16.2.OID.ISO. > >However, this would not allow us to use HL7.org as a name for both >an IP address and an OID. Therefore I think that an OID record type >similar to the A or AAAA record types is in fact needed. > > >COMBINATION OF NUMERIC AND SYMBOLIC OID PARTS > >There is a third extension to the DNS that we need to sensibly use >the DNS for OID management, and I may be wrong here. That requirement >is about the following problem. I want all of the following named >OIDs to resolve to the same numeric OIDs: > >hl7.org.us.country.joint-iso-itu-t.oid.iso. >113883.org.us.country.joint-iso-itu-t.oid.iso. >113883.1.us.country.joint-iso-itu-t.oid.iso. >113883.1.840.country.joint-iso-itu-t.oid.iso. >113883.1.840.16.joint-iso-itu-t.oid.iso. >113883.1.840.16.2.oid.iso. > >The only way I found I could do this with BIND was to define a zone for >each of these 6 variants. When HL7 now delegates some of its sub-branches >to someone else, that person would have to define 7, 8, 9, 10 or more >zones just in order to map all combinations of numeric and symbolic forms. >And that doesn't even cover something like: > >hl7.org.us.16.2.oid.iso. >hl7.1.840.16.2.oid.iso. >hl7.1.us.16.2.oid.iso. > >etc. So, the functional extension of the DNS system I would propose is >that when the resource type of the DNS query is OID, then the DNS server >should resolve as much of the symbolic OID parts as possible starting >from the most significant part. That way, zone files would only need >to be defined for the numbered form and the DNS system would resolve >the symbols from the most significant symbol down on its way through >the NS graph. > >In the case of "hl7.1.us.16.2.oid.iso." it would take oid.iso. as one >well known domain asking the OID root NS for 16.2.oid.iso.'s NS. That >NS would be asked to resolve "us" and then to ask the NS of 1.840 for >what "hl7" is. That cascade would return 113883.1.840.16.2.oid.iso. >and eventually return that OID "2.16.840.1.113883". > > > >SUMMARY > >The DNS system seems very close to what would be needed to manage the >Object Identifier scheme that would support human understanding of OIDs >as well as resolving symbolic OID parts or other DNS names to OIDs. >Only three additional conventions need to be established: > >1. The root domain OID.ISO. that would be non-authoritatively managed by > IANA until other organizations claim authority for the DNS management > of their branches. > >2. The resource record type OID that assigns OIDs to DNS names. > >3. A special DNS name resolution where DNS names are resolved stepwise. > (This may actually just be a change to the BIND implementation of DNS.) > >I would be glad for any reactions as to whether this might make sense >to you. Especially, if you think that nothing is needed, I would >appreciate your ideas on how to deal with the last problem (3) of the >combinatorial explosion of symbol/number variances. > >thank you, >-Gunther > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.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. From owner-namedroppers@ops.ietf.org Tue Sep 19 21:13:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27400 for ; Tue, 19 Sep 2000 21:13:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bXwX-000Dzf-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 17:40:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bXwX-000DzZ-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 17:40:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bXwX-000CTV-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 17:40:57 -0700 Message-Id: <200009200040.RAA27839@boreas.isi.edu> To: IETF-Announce: ; Subject: BCP 42, RFC 2929 on DNS IANA Considerations Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 19 Sep 2000 17:40:33 -0700 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. BCP 42 RFC 2929 Title: Domain Name System (DNS) IANA Considerations Author(s): D. Eastlake 3rd, E. Brunner-Williams, B. Manning Status: Best Current Practice Date: September 2000 Mailbox: Donald.Eastlake@motorola.com, brunner@engage.com, bmanning@isi.edu Pages: 12 Characters: 22454 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-iana-dns-01.txt URL: ftp://ftp.isi.edu/in-notes/rfc2929.txt Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. This document is a product of the DNS Extensions Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000919173820.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2929 --OtherAccess Content-Type: Message/External-body; name="rfc2929.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000919173820.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 21:14:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27411 for ; Tue, 19 Sep 2000 21:14:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bXz7-000E4e-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 17:43:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bXz6-000E4W-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 17:43:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bXz6-000CUu-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 17:43:36 -0700 Message-Id: <200009200043.RAA28173@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2930 on The DNS TKEY RR Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 19 Sep 2000 17:43:02 -0700 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2930 Title: Secret Key Establishment for DNS (TKEY RR) Author(s): D. Eastlake 3rd Status: Standards Track Date: September 2000 Mailbox: Donald.Eastlake@motorola.com Pages: 16 Characters: 34894 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-tkey-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc2930.txt [RFC 2845] provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000919174109.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2930 --OtherAccess Content-Type: Message/External-body; name="rfc2930.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000919174109.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 21:18:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27548 for ; Tue, 19 Sep 2000 21:18:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bY3d-000ECI-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 17:48:17 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bY3d-000ECC-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 17:48:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bY3d-000CWw-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 17:48:17 -0700 Message-Id: <200009200045.RAA28517@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2931 on DNS SIG(0) Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 19 Sep 2000 17:45:36 -0700 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2931 Title: DNS Request and Transaction Signatures ( SIG(0)s ) Author(s): D. Eastlake 3rd Status: Standards Track Date: September 2000 Mailbox: Donald.Eastlake@motorola.com Pages: 10 Characters: 19073 Updates: 2535 I-D Tag: draft-ietf-dnsext-sig-zero-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2931.txt Extensions to the Domain Name System (DNS) are described in [RFC 2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Implementation experience has indicated the need for minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented herein. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000919174326.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2931 --OtherAccess Content-Type: Message/External-body; name="rfc2931.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000919174326.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 22:10:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29209 for ; Tue, 19 Sep 2000 22:10:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bYOA-000Eqa-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 18:09:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bYO9-000EqT-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 18:09:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bYO9-000CgX-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 18:09:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200009200056.JAA13382@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA13382; Wed, 20 Sep 2000 09:55:56 +0859 Subject: Re: Same-signed keys In-Reply-To: from Brian Wellington at "Sep 19, 2000 04:20:41 pm" To: Brian Wellington Date: Wed, 20 Sep 2000 09:55:55 +0859 () CC: Harald Alvestrand , Edward Lewis , DNSEXT WG Mailing list X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > On Tue, 19 Sep 2000, Harald Alvestrand wrote: > > > At 11:17 19/09/2000 -0400, Edward Lewis wrote: > > >To mediate this, the rule of > > >short names signing longer names will stand with the exception that for a > > >resolver, at preconfigured points of trust (e.g., key #1's owner), keys of > > >the same set may be used to validate the others - i.e., an exception to the > > >"always shorter" rule. > > > > it is not possible to deduct that a node in the DNS tree is or is not a > > preconfigured point of trust by looking at it - because this configuration > > is not stored in the DNS. > > It's not possible to tell as an outsider. However, a resolver knows > whether or not it has the preconfigured key. If it does, the validation > can be attempted. If not, it cannot validate the data (and probably > shouldn't have tried in the first place, since it likely has no reason to > have started the validation process). It is one (among many) of a fatal design flaw I pointed out long ago that SECDNS fails to separate the roles of resolvers and name servers. You are seeing the result. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 22:19:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29309 for ; Tue, 19 Sep 2000 22:19:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bYpR-000Ffo-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 18:37:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bYpQ-000Ffi-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 18:37:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bYpQ-000Cr3-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 18:37:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200009200126.KAA13554@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA13554; Wed, 20 Sep 2000 10:26:33 +0900 Subject: Re: What are the chances for OID resource records in the DNS? In-Reply-To: <39C7E02D.3E06F511@aurora.rg.iupui.edu> from Gunther Schadow at "Sep 19, 2000 04:52:45 pm" To: Gunther Schadow Date: Wed, 20 Sep 2000 10:26:32 +0859 () CC: namedroppers@ops.ietf.org, Harald@alvestrand.no X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gunther; > The only thing that needs to be in place is the OID.ISO. Put it under some domain already owned by ISO or apply for one under existing TLDs. Given that ISO would be able to get ISO.INT, it is not an issue that ISO.ORG is already taken by someone. > There is a third extension to the DNS that we need to sensibly use > the DNS for OID management, and I may be wrong here. That requirement > is about the following problem. I want all of the following named > OIDs to resolve to the same numeric OIDs: > > hl7.org.us.country.joint-iso-itu-t.oid.iso. > 113883.org.us.country.joint-iso-itu-t.oid.iso. > 113883.1.us.country.joint-iso-itu-t.oid.iso. > 113883.1.840.country.joint-iso-itu-t.oid.iso. > 113883.1.840.16.joint-iso-itu-t.oid.iso. > 113883.1.840.16.2.oid.iso. > > The only way I found I could do this with BIND was to define a zone for > each of these 6 variants. When HL7 now delegates some of its sub-branches > to someone else, that person would have to define 7, 8, 9, 10 or more > zones just in order to map all combinations of numeric and symbolic forms. > And that doesn't even cover something like: > > hl7.org.us.16.2.oid.iso. > hl7.1.840.16.2.oid.iso. > hl7.1.us.16.2.oid.iso. With BIND, you need exponentially (to the number of labels) lengthy zone file. You only have to write your own special name server which internally converts symbolic names to numbers and looks up its internal database. Then, the length of the database glows linearly. There is some complexity upon delegation that name servers of child zones must know symbolic labels in parent zones. There seems to be no easy solution other than configuring child name servers with upper level labels. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 23:03:38 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00667 for ; Tue, 19 Sep 2000 23:03:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bZaq-000H4h-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 19:26:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bZaq-000H4a-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 19:26:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bZaq-000D8x-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 19:26:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.3.2.7.2.20000919224441.06954e20@127.0.0.1> References: Date: Tue, 19 Sep 2000 22:19:49 -0400 To: Harald Alvestrand From: Edward Lewis Subject: Re: Same-signed keys Cc: Edward Lewis , DNSEXT WG Mailing list Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 4:47 PM -0400 9/19/00, Harald Alvestrand wrote: >it is not possible to deduct that a node in the DNS tree is or is not a >preconfigured point of trust by looking at it - because this configuration >is not stored in the DNS. This is not a "correct" question. An arbitrary point in the DNS will be a "preconfigured point of trust" is some reolvers and not others. It's always relative to the resolver's point of view. (Trust is always in the eye of the behold[ing resolv]er.) The process of validation is done internal to a resolver. The resolver "knows" what is the relevant "universe" of pre-configurated points of trust - as far as the resolver is concerned. During the validation process, given a piece of data and a signature "certifying" the data according to a particular key, the question to be asked before doing any crypto is "do I (the resolver) *care* if the signature validates the data?" A rational resolver will care about the signature if (among other things) the key used to verify the signature is trusted. The issue being discussed is how does the rational resolver come to determine the trustworthyness of a key? Acheiving the trust needs to be done in such a way that limits the exposure to over-use of resources given dubious credentials (the clogging concern), in such a way that limits the chance that trust can be gained through fraud (shadowy data signers), and in such a way that legitimately trustworthy data is maximized. Okay, so much for the Internet Philisophical Task Force ... IMHO - allowing one key of a set to extend trust to other members of it's own set is a good thing. Restricting this only to a resolver's preconfigured keys is implementationally a reasonable restriction, but perhaps this restriction is not necessary. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 23:07:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00699 for ; Tue, 19 Sep 2000 23:07:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bZke-000HP8-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 19:36:48 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bZkd-000HP2-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 19:36:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bZkd-000DDF-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 19:36:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C82236.CB30CE3@aurora.rg.iupui.edu> Date: Tue, 19 Sep 2000 21:34:30 -0500 From: Gunther Schadow To: Robert Elz CC: namedroppers@ops.ietf.org, Harald@alvestrand.no Subject: Re: What are the chances for OID resource records in the DNS? References: <17617.969408543@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert, I see your point, you want to know whether my suggestion is useful beyond just a nice to have, so that it makes sense the trouble. Good point. Need to think about that. In my standard organization we want to employ OIDs for most everything. We will have thousands of oids. Including OID sub-domains delegated to users around the world. We can decide to use some LDAP stuff that -- I believe -- is not proven to scale. Or, we may piggy back our needs on the DNS that's proven to scale and that is ubiquitous. Will have to make a stronger point to convince you, perhaps. But for now I am after a working interim solution for us, since we do not have the time of one year or so that it takes to fight any extension into the DNS (and seeing it implemented). For that reason alone I am very conservative. > | I suppose I can still use TXT records that by convention start with > | OID for that purpose. > > No, don't do that. But you could use a PTR > > h17.org. IN PTR 113883.1.840.16.2.OID.ARPA. Hmm, I like that, but what exactly would it mean? Right now the domain OID.ARPA. doesn't exist, so I suppose that those PTRs would be invalid. Can you explain why you think that PTR is a good fit? After all, I know PTR only from reverse mapping of IN-ADDR.ARPA "domains" to domain names. How come you suggest it for mapping domain names to OIDs? I could like that approach if I understood it better. Thanks for the DNAME hint. That sounds like exactly what I need. Though it's not supported in my fairly recent version of BIND :-( regards -Gunther to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Sep 19 23:24:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00830 for ; Tue, 19 Sep 2000 23:24:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bZx6-000HpC-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 19:49:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bZx5-000Hp6-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 19:49:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bZx5-000DIl-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 19:49:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 19 Sep 2000 22:37:54 -0400 From: Michael Mealling To: Gunther Schadow Cc: namedroppers@ops.ietf.org, Harald@alvestrand.no Subject: Re: What are the chances for OID resource records in the DNS? Message-ID: <20000919223754.A18337@bailey.dscga.com> Reply-To: michaelm@netsol.com In-Reply-To: <39C7E02D.3E06F511@aurora.rg.iupui.edu>; from gunther@aurora.rg.iupui.edu on Tue, Sep 19, 2000 at 04:52:45PM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, Sep 19, 2000 at 04:52:45PM -0500, Gunther Schadow wrote: > Gunther, Take a look at http://www.ietf.org/internet-drafts/draft-mealling-oid-urn-02.txt And the DDDS drafts: http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-00.txt http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-00.txt http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-00.txt For a way to do this the right way... The only issue to be resolved is getting ISO to run the root of the thing.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.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. From owner-namedroppers@ops.ietf.org Wed Sep 20 01:53:25 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08547 for ; Wed, 20 Sep 2000 01:53:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bcBX-000Kc4-00 for namedroppers-data@psg.com; Tue, 19 Sep 2000 22:12:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bcBX-000Kby-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 22:12:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bcBX-000EBV-00 for namedroppers@ops.ietf.org; Tue, 19 Sep 2000 22:12:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C8470F.2CE0177D@aurora.rg.iupui.edu> Date: Wed, 20 Sep 2000 00:11:43 -0500 From: Gunther Schadow To: michaelm@netsol.com CC: namedroppers@ops.ietf.org, Harald@alvestrand.no Subject: Re: What are the chances for OID resource records in the DNS? References: <39C7E02D.3E06F511@aurora.rg.iupui.edu> <20000919223754.A18337@bailey.dscga.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michael, while I think that your DDDS idea contains one answer to the problem, I submit that it is much more general and therefore, unfortunately, complicates things beyond what's necessary for a simple DNS based OID catalogue. I will try to extract some good ideas out of your approach. For example, I might find the NAPTR RRs useful. Also, I can use the same kind of stepwise resolution algorithm that you are suggesting, though I was hoping that I could use a simple resolver query to get to the whole information at one shot. regards -Gunther to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Sep 20 08:15:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19973 for ; Wed, 20 Sep 2000 08:15:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bi9d-0000TJ-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 04:35:09 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bi9d-0000TD-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 04:35:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bi9d-000GbS-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 04:35:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000920122650.052d4f00@127.0.0.1> Date: Wed, 20 Sep 2000 12:27:31 +0200 To: Edward Lewis From: Harald Alvestrand Subject: Re: Same-signed keys Cc: Edward Lewis , DNSEXT WG Mailing list In-Reply-To: References: <4.3.2.7.2.20000919224441.06954e20@127.0.0.1> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 22:19 19/09/2000 -0400, Edward Lewis wrote: >> it is not possible to deduct that a node in the DNS tree is or is not a >> preconfigured point of trust by looking at it - because this configuration >> is not stored in the DNS. > >This is not a "correct" question. An arbitrary point in the DNS will be a >"preconfigured point of trust" is some reolvers and not others. It's >always relative to the resolver's point of view. (Trust is always in the >eye of the behold[ing resolv]er.) This is why the configuration of the resolver cannot enter into the question of whether it is legal or not to store a particular record in the DNS. That is - we agree. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Sep 20 08:19:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20054 for ; Wed, 20 Sep 2000 08:19:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13biA0-0000Ua-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 04:35:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bi9z-0000UU-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 04:35:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bi9z-000Gbk-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 04:35:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000920121841.078683a8@127.0.0.1> Date: Wed, 20 Sep 2000 12:20:10 +0200 To: Masataka Ohta , Gunther Schadow From: Harald Alvestrand Subject: Re: What are the chances for OID resource records in the DNS? Cc: namedroppers@ops.ietf.org In-Reply-To: <200009200126.KAA13554@necom830.hpcl.titech.ac.jp> References: <39C7E02D.3E06F511@aurora.rg.iupui.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:26 20/09/2000 +0859, Masataka Ohta wrote: >Put it under some domain already owned by ISO or apply for one under >existing TLDs. > >Given that ISO would be able to get ISO.INT, it is not an issue >that ISO.ORG is already taken by someone. I agree. And: If it is a function the world needs, piloting it under aurora.rg.iupui.edu will give you valuable experience, and does not have to wait for ISO to react. (BTW, ISO currently lives at iso.ch) -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Sep 20 08:22:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20117 for ; Wed, 20 Sep 2000 08:22:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bi94-0000SS-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 04:34:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13bi94-0000SM-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 04:34:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13bi94-000Gb8-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 04:34:34 -0700 Message-Id: <200009201029.GAA17261@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-zone-status-03.txt Date: Wed, 20 Sep 2000 06:29:12 -0400 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 Extension Clarification on Zone Status Author(s) : E. Lewis Filename : draft-ietf-dnsext-zone-status-03.txt Pages : 9 Date : 19-Sep-00 The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, 'experimentally secure' status is deprecated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-03.txt 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-zone-status-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-zone-status-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: <20000919125454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-zone-status-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-zone-status-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000919125454.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. From owner-namedroppers@ops.ietf.org Wed Sep 20 11:03:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24556 for ; Wed, 20 Sep 2000 11:03:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bkyT-0003aq-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 07:35:49 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13bkyS-0003aj-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 07:35:49 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13bkyx-000ArR-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 07:36:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200009201354.WAA15930@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA15930; Wed, 20 Sep 2000 22:54:26 +0900 Subject: Re: What are the chances for OID resource records in the DNS? In-Reply-To: <4.3.2.7.2.20000920121841.078683a8@127.0.0.1> from Harald Alvestrand at "Sep 20, 2000 12:20:10 pm" To: Harald Alvestrand Date: Wed, 20 Sep 2000 22:54:26 +0859 () CC: Gunther Schadow , namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald; > >Put it under some domain already owned by ISO or apply for one under > >existing TLDs. > > > >Given that ISO would be able to get ISO.INT, it is not an issue > >that ISO.ORG is already taken by someone. > > I agree. > And: If it is a function the world needs, piloting it under > aurora.rg.iupui.edu will give you valuable experience, and does not have to > wait for ISO to react. > > (BTW, ISO currently lives at iso.ch) I don't think someone in ISO seriously argue against ISO operate under *BOTH* iso.ch and iso.int. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Sep 20 11:39:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25260 for ; Wed, 20 Sep 2000 11:39:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bkwv-0003Yn-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 07:34:13 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13bkwu-0003Yg-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 07:34:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13bkxK-000ArL-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 07:34:38 -0700 Message-Id: In-Reply-To: <200009201029.GAA17261@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Sep 2000 09:47:29 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-zone-status-03.txt Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The most significant changes are: Use of "global/local" instead of "fully/privately" secure as the new terms better capture the span of resolvers that seen answers as secure. A section on "closest security root" - a concept used in the BIND validator. The text is supposed to be an explanation of it - not a protocol spec defining it. Other rewording addressing concerns at/prior to the Pitt Meeting. (I.e., the dilemma that DNSSEC requires notification of security - but - does this by remaining silent when security is enhanced, and adding a NULL key when there is no enhancement.) At 6:29 AM -0400 9/20/00, Internet-Drafts@ietf.org wrote: >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 Extension Clarification on Zone Status > Author(s) : E. Lewis > Filename : draft-ietf-dnsext-zone-status-03.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Sep 20 23:19:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15676 for ; Wed, 20 Sep 2000 23:19:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bwMb-000I2q-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 19:45:29 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13bwMZ-000I2U-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 19:45:28 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13bwMa-000B7S-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 22:45:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C8D5F0.B3E61CE6@aurora.rg.iupui.edu> Date: Wed, 20 Sep 2000 10:21:20 -0500 From: Gunther Schadow To: Harald Alvestrand CC: Masataka Ohta , namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? References: <39C7E02D.3E06F511@aurora.rg.iupui.edu> <4.3.2.7.2.20000920121841.078683a8@127.0.0.1> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald Alvestrand wrote: > > At 10:26 20/09/2000 +0859, Masataka Ohta wrote: > >Put it under some domain already owned by ISO or apply for one under > >existing TLDs. > > > >Given that ISO would be able to get ISO.INT, it is not an issue > >that ISO.ORG is already taken by someone. > > I agree. > And: If it is a function the world needs, piloting it under > aurora.rg.iupui.edu will give you valuable experience, and does not have to > wait for ISO to react. O.K. I have set up a pilot for HL7. And have used Robert Elz's recommendation to do the canonical OID mapping using PTR records. Thus we can say hl7.org. IN A 198.87.144.122 hl7.org. IN AAAA 3ffe:1ce0:123:1 hl7.org. IN PTR 113883.1.840.16.2.OID.ARPA. which puts resolutions for one DNS name to IPv4, IPv6, and OIDs into the DNS without ammending the DNS spec. So that works nicely. The rule to resolve to an OID is now: 1. issue resolve query with qtype = PRT, 2. in the answers find the name in the OID.ARPA. domain 3. clip off .OID.ARPA. 4. reverse the number sequence That's very easy to do. So, no new RR type "OID" would be needed. Now the question: will I be put to into cyber-jail when I use the domain OID.ARPA. here experimentally without this being a standard assignment? I want to avoid using something in my own domains, such as hl7.org. or regenstrief.org, since that would confuse the point. The resolution should really go to absolute OIDs, not to OIDs in HL7's or Regenstrief's OID domain. What can I do to somehow reserve the domain OID.ARPA. for such experimental purpose? I will write an internet draft on this experiment, but at the same time I would like to deploy this function within our standard organization right away. And I know that the draft to RFC transition can take a long time these days. I will have lots of difficulties explaining or selling this to our constituency (mostly legacy system vendors and consultants) if I had to use a transient domain such as "root-oid.hl7.org." or something. thank you, -Gunther to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Sep 20 23:23:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15764 for ; Wed, 20 Sep 2000 23:23:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bwKZ-000I0G-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 19:43:23 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13bwKX-000I09-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 19:43:22 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13bwKV-000B7I-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 22:43:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39C8D24A.92AAB161@aurora.rg.iupui.edu> Date: Wed, 20 Sep 2000 10:05:46 -0500 From: Gunther Schadow To: Dean Anderson CC: namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? References: <3.0.32.20000919192343.01c953c0@odie.av8.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dean Anderson wrote: > >[...] In addition, OIDs are a very useful identifier > >scheme since they allow a fully distributed management with little technical > >overhead (unlike UUIDs or GUIDs). > > You seem to misunderstand how UUID's work. While OID's are assigned like > domain names by a managing organization and the assignee is able to > "subdomain", by contrast UUID's are generated by the creator/developer, and > are guarenteed to be unique by the generator. UUID's have zero > technical/management overhead. The only disadvantage is that you wind up > having large, unordered lists of them, making them unwieldy to search > without a database. Well, the technical problem with UUIDs though is that you really need an Ethernet card to assign those, since UUIDs piggy back on the unique ID scheme of those Ethernet cards. What if you have no such basis? Second technical problem is that there aren't that many UUID implementations around on platforms other than Windoze (where UUIDs are called GUIDs). My perceptions is that UUIDs have never really taken off the ground as poublicly shared identifiers. That's where OIDs seem to be much better accepted. The technical requirements for assigning OIDs are absolutely trivial, can do that manually or without special Ethernet card dependent software. > As a matter of history, I thought OID's came from SNMP ;-) That is interesting. Can you back that up? I thought the the OSI stems even from the late 70's and early 80's. Was SNMP around already back then? > As an SNMP user (MIB-Looker-Upper), I think your idea has some merit, but > I'm not sure DNS is the right protocol. I'd think an LDAP server would be > well suited to handle this kind of data. Rather, a publicly accessible LDAP > server... LDAP is what everyone keeps recommending me. And yet there are two defects with LDAP: #1 is LDAP really designed to be so distributed as DNS? If we would run LDAP in the same massive distribution, wouldn't we reinvent the wheel? Wouldn't we have to solve all the DNSSEC issues once again for LDAP? #2 LDAP is not nearly as ubiquitous as the DNS. People would have to spend time and sweat to set up and maintain LDAP servers besides DNS. Most will have access to some DNS server already, but few will do LDAP. We have been setting up LDAP here, that's when I found how immature the implementation is. I'd much rather use BIND or any DNS server around the globe. That's why I am not actually eager to invent new DNS RR types. And it seems there isn't any new RR type needed. A PTR to some OID.ARPA. domain will do. Thank you, -Gunther to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Sep 20 23:35:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16222 for ; Wed, 20 Sep 2000 23:35:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bwhU-000IcY-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 20:07:04 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13bwhS-000IcE-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 20:07:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13bwhQ-000B9F-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 23:07:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000920121450.05393f08@127.0.0.1> Date: Wed, 20 Sep 2000 12:21:53 -0400 To: Gunther Schadow From: Harald Alvestrand Subject: Re: What are the chances for OID resource records in the DNS? Cc: namedroppers@ops.ietf.org In-Reply-To: <39C8D5F0.B3E61CE6@aurora.rg.iupui.edu> References: <39C7E02D.3E06F511@aurora.rg.iupui.edu> <4.3.2.7.2.20000920121841.078683a8@127.0.0.1> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:21 20/09/2000 -0500, Gunther Schadow wrote: >Now the question: will I be put to into cyber-jail when I use the domain >OID.ARPA. here experimentally without this being a standard assignment? >I want to avoid using something in my own domains, such as hl7.org. or >regenstrief.org, since that would confuse the point. The resolution should >really go to absolute OIDs, not to OIDs in HL7's or Regenstrief's OID >domain. For testing the concepts and seeing what you can do with it, using oid.hl7.org would in fact be much better - the reason being that you clearly label this as an experiment done under the auspices of HL7, not an IETF-blessed or ISO-blessed operational service. The reason you want control of the oid.arpa domain is to put information there (such as making HL7.OID.ARPA a CNAME to 113883.1.840.16.2.OID.ARPA, indicating that you are allowed to use HL7 as a top level symbolic name - something I think will be controversial, btw; less controversial is that ISO.OID.ARPA should be a CNAME pointing to 0.OID.ARPA). If this ever becomes a standard, you are likely to be at the end of a LONG discussion on exactly what information to put into the oid.arpa tree, who is to be delegated the various subentries, and so on and so forth. Again, using oid.hl7.org isolates your internal deployment from the hazards of the standards process, and guarantees that your applications will go on working no matter how many people disagree with you. My recommendation should be clear.... -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Sep 21 00:01:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16559 for ; Thu, 21 Sep 2000 00:01:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13bx0r-000J9L-00 for namedroppers-data@psg.com; Wed, 20 Sep 2000 20:27:05 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13bx0o-000J98-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 20:27:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13bx0m-000BAO-00 for namedroppers@ops.ietf.org; Wed, 20 Sep 2000 23:27:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <3.0.32.20000920211622.01c9c720@odie.av8.com> Date: Wed, 20 Sep 2000 21:22:10 -0400 To: Gunther Schadow From: Dean Anderson Subject: Re: What are the chances for OID resource records in the DNS? Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Around 10:05 AM 09/20/2000 -0500, rumor has it that Gunther Schadow said: >Dean Anderson wrote: > >> >[...] In addition, OIDs are a very useful identifier >> >scheme since they allow a fully distributed management with little technical >> >overhead (unlike UUIDs or GUIDs). >> >> You seem to misunderstand how UUID's work. While OID's are assigned like >> domain names by a managing organization and the assignee is able to >> "subdomain", by contrast UUID's are generated by the creator/developer, and >> are guarenteed to be unique by the generator. UUID's have zero >> technical/management overhead. The only disadvantage is that you wind up >> having large, unordered lists of them, making them unwieldy to search >> without a database. > >Well, the technical problem with UUIDs though is that you really need an >Ethernet card to assign those, since UUIDs piggy back on the unique ID >scheme of those Ethernet cards. What if you have no such basis? Good point. I'll take a look at the UUID specs tomorrow if I have time. It strikes me that there is a "non-ethernet" method for obtaining those 8 bytes of the UUID. >Second >technical problem is that there aren't that many UUID implementations >around on platforms other than Windoze (where UUIDs are called GUIDs). Actually, The Open Group made DCE public, and made the RPC library (which contains a UUID generator program) free several years ago. Its been ported to Linux. There is some activity. Certainly DCE, though not completely dead, has certainly faded. I can't think of any other significant users of UUID's except for the H.323 protocol stacks. I think you can also find code to generate UUID's in Openh323. >> As a matter of history, I thought OID's came from SNMP ;-) > >That is interesting. Can you back that up? I thought the the OSI stems >even from the late 70's and early 80's. Was SNMP around already back >then? I guess not. Someone posted that it came from ASN.1, upon which SNMP was based. > >> As an SNMP user (MIB-Looker-Upper), I think your idea has some merit, but >> I'm not sure DNS is the right protocol. I'd think an LDAP server would be >> well suited to handle this kind of data. Rather, a publicly accessible LDAP >> server... > >LDAP is what everyone keeps recommending me. And yet there are two defects >with LDAP: #1 is LDAP really designed to be so distributed as DNS? If we >would run LDAP in the same massive distribution, wouldn't we reinvent the >wheel? Wouldn't we have to solve all the DNSSEC issues once again for LDAP? >#2 LDAP is not nearly as ubiquitous as the DNS. People would have to spend >time and sweat to set up and maintain LDAP servers besides DNS. Most will >have access to some DNS server already, but few will do LDAP. We have been >setting up LDAP here, that's when I found how immature the implementation >is. I'd much rather use BIND or any DNS server around the globe. That's why >I am not actually eager to invent new DNS RR types. And it seems there isn't >any new RR type needed. A PTR to some OID.ARPA. domain will do. Well, the LDAP servers work. Running them to cooperate this way might be another thing... On the other hand, there is no reason that DNS software can't be made to run on another port instead of 53, nor that these "other" servers integrate in the DNS name hierarchy somewhere. Change some constants and recompile, and you will have a working hierachical distributed database system... That the protocol is the same as dns can be coincidental. ;-) Maybe LDAP should be obsolesced ;-) --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.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. From owner-namedroppers@ops.ietf.org Thu Sep 21 14:59:11 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12444 for ; Thu, 21 Sep 2000 14:59:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cAgv-0009Pm-00 for namedroppers-data@psg.com; Thu, 21 Sep 2000 11:03:25 -0700 Received: from [209.212.233.188] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13cAgu-0009OC-00 for namedroppers@ops.ietf.org; Thu, 21 Sep 2000 11:03:24 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13cAgO-000Bj3-00 for namedroppers@ops.ietf.org; Thu, 21 Sep 2000 14:02:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CA4C83.ED29B2D2@ehsco.com> Date: Thu, 21 Sep 2000 10:59:31 -0700 From: "Eric A. Hall" To: Gunther Schadow CC: namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? References: <39C7E02D.3E06F511@aurora.rg.iupui.edu> <4.3.2.7.2.20000920121841.078683a8@127.0.0.1> <39C8D5F0.B3E61CE6@aurora.rg.iupui.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry coming into this late. In general, I am opposed to using DNS for directory-like functions, since DNS does not provide directory features like authenticated-vs-anonymous queries or key indexing/searching against attribute data. Neither of those issues should be a problem here though, should they? I mean, do you need to worry about any of the OIDs being returned for anonymous users (since all DNS queries are anonymous by nature)? > O.K. I have set up a pilot for HL7. And have used Robert Elz's > recommendation to do the canonical OID mapping using PTR records. Yeah, PTR should work just fine for reverse lookups. > The rule to resolve to an OID is now: > > 1. issue resolve query with qtype = PRT, > 2. in the answers find the name in the OID.ARPA. domain > 3. clip off .OID.ARPA. > 4. reverse the number sequence > > That's very easy to do. So, no new RR type "OID" would be needed. I don't know if that's the best approach. I think you were on the right track with an explicit OID RR. For example, some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 would require an explicit OID RR in order to properly encapsulate the OID data. Standardized intepretations require standardized representations, so using an explicit OID RR would ensure that the OID value were being represented properly. There are also distinct benefits to having explicit domain name entries, such as being able to use CNAMEs and additonal RRs. You might want: some.other.oid.osi.int. CNAME some.oid.osi.int. some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 TXT "OID for XYZ" RP "oid-admins@xyz.org" Etcetera. Building a reverse name from the PTR data won't allow for any of that to occur. -- 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. From owner-namedroppers@ops.ietf.org Fri Sep 22 03:30:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03610 for ; Fri, 22 Sep 2000 03:30:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cMuS-0007R7-00 for namedroppers-data@psg.com; Fri, 22 Sep 2000 00:06:12 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13cMuR-0007R0-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:06:11 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13cMuQ-000Cby-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:06:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CA7BE9.9DE22E0D@ehsco.com> Date: Thu, 21 Sep 2000 14:21:45 -0700 From: "Eric A. Hall" To: Gunther Schadow CC: Robert Elz , namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? References: <19107.969565561@mundamutti.cs.mu.OZ.AU> <39CA68B6.555B6C66@ehsco.com> <39CA77AD.D4C972EE@aurora.rg.iupui.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The other thing is, it doesn't make sense to do backward lookup with > OIDs, because OIDs are not addresses. OIDs are really simply names. Yeah I know, OIDs have multiple aliases. But there are multiple ways to delegate the management of the assignment namespace using the different names. There are definitely multiple, different namespaces. There are forward and reverse lookups of common name(s) to numeric ID and vice versa. Whatever. The principle benefit of an OID RR would be consistent data-typing, so the best use would be OID on both namespaces, instead of OID for one and PTR for the other. I'm not even sure that a data-type is relevant given the OID syntax. It would likely just be a sequence of labels so any label-based datatype would work since the attribute trees are mostly isolated when they do actually exist. Given all of the above, PTR and CNAME RRs should work fine. As I also said, I'm generally opposed to using DNS for directories. It's a naming service, not a directory. The more directory-like features and data that creep into it, the harder it is to make a distinction. -- 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. From owner-namedroppers@ops.ietf.org Fri Sep 22 03:30:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03621 for ; Fri, 22 Sep 2000 03:30:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cMoP-0006jO-00 for namedroppers-data@psg.com; Thu, 21 Sep 2000 23:59:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13cMoP-0006jI-00 for namedroppers@ops.ietf.org; Thu, 21 Sep 2000 23:59:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13cMoP-000CRa-00 for namedroppers@ops.ietf.org; Thu, 21 Sep 2000 23:59:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Eric A. Hall" Cc: Gunther Schadow , namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? In-Reply-To: Your message of "Thu, 21 Sep 2000 10:59:31 PDT." <39CA4C83.ED29B2D2@ehsco.com> Date: Fri, 22 Sep 2000 06:46:01 +1100 Message-Id: <19107.969565561@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 21 Sep 2000 10:59:31 -0700 From: "Eric A. Hall" Message-ID: <39CA4C83.ED29B2D2@ehsco.com> | There are also distinct benefits to having explicit domain name entries, | such as being able to use CNAMEs and additonal RRs. You might want: | | some.other.oid.osi.int. CNAME some.oid.osi.int. | some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 | TXT "OID for XYZ" | RP "oid-admins@xyz.org" | | Etcetera. Building a reverse name from the PTR data won't allow for any of | that to occur. What? some.other.oid.osi.int. CNAME some.oid.osi.int. some.oid.osi.int. PTR 1.2.3.4.5.6.77.88.99.OID.ARPA. TXT "OID for XYZ" RP "oid-admins@xyz.org" What's the difference? kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Sep 22 03:31:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03641 for ; Fri, 22 Sep 2000 03:31:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cMjA-00065w-00 for namedroppers-data@psg.com; Thu, 21 Sep 2000 23:54:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13cMj9-00065q-00 for namedroppers@ops.ietf.org; Thu, 21 Sep 2000 23:54:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13cMj9-000CPY-00 for namedroppers@ops.ietf.org; Thu, 21 Sep 2000 23:54:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CA5958.DD70AC3A@aurora.rg.iupui.edu> Date: Thu, 21 Sep 2000 13:54:16 -0500 From: Gunther Schadow To: "Eric A. Hall" CC: namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? References: <39C7E02D.3E06F511@aurora.rg.iupui.edu> <4.3.2.7.2.20000920121841.078683a8@127.0.0.1> <39C8D5F0.B3E61CE6@aurora.rg.iupui.edu> <39CA4C83.ED29B2D2@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric, the reason why I moved away from explicit OID RRs is because I've got the sense from the group that enthusiasm for this project is relatively low. Also, what good is "my own RR" when it isn't widely implemented? Since I wanted to deploy this project *widely* with an organization where DNS, BIND and UNIX hackers are the utter minority, I have to use what is there already. That's why using PTR records seems to work best, unless of course, you have another idea. I can now simply do this: hl7.org. IN PTR 113883.1.840.16.2.OID-ROOT.NET. (Yes, I have registered OID-ROOT.NET. for this in order to start this project right away.) Each known OID will have a "descriptive" RR (TXT, RP, etc.) underneath OID-ROOT.NET. This will include named OIDs (the idea of named OIDs is set forth in the original ASN.1 spec.) Thus, for example, $ORIGIN OID-ROOT.NET. ISO IN PTR 0.OID-ROOT.NET. 0 IN TXT "International Organization for Standardization" CCITT IN PTR 1.OID-ROOT.NET. 1 IN TXT "International Telecommunication Union" JOINT-ISO-CCITT IN PTR 2.OID-ROOT.NET. 2 IN TXT "Joint ISO and ITU-T assignments" ISO.STANDARD IN PTR 0.0.OID-ROOT.NET. 0.0 IN TXT "ISO Standard" 4217.0.0 IN TXT "ISO 4217 - Currency Codes" ;... 16.2 IN TXT "Country Assignments" 840.16.2 IN TXT "United States of America" 1.840.16.2 IN TXT "U.S. Organizations" 113883.1.840.16.2 IN TXT "Health Level-7" So, you see that the OID-ROOT.NET. zone will contain all OIDs, numbered and named. This data could all be generated from Harald Alvestrand's database. If someone claims authority over his DNS OID space, that person can get a normal DNS assignment, i.e., 113883.1.840.16.2 NS dns.hl7.org. However, this would only be possible if the claiming entity makes sure that it takes over DNS maintenance of the subordinate OIDs. For example, if ANSI comes and wants 840.16.2 NS oid.ansi.org. they would have to make sure they maintain 1.840... and 113883.1.840... assignments. Alternatively, they could map an NS record back to the root. The idea is that if this project flies, more and more zones will be taken over by their rightful owners until the entire OID system is on the DNS track. The problem with named OIDs and CNAMEs is that the DNS was not designed for allowing synonymy of symbols and a canonical number for each step independently. Thus, symbolic OID resolution is somewhat of a hassle. As much as I understand the DNAME proposal (which just got its first implementation in brand-new BIND9), even DNAMEs will not be able to handle all that variance sufficiently well. I have two algorithms to resolve symbolic and mixed numeric/symbolic OIDs so far. Will bounce this back off you to get criticism. One question I have before I leave: are there any worries that the DNS system may be overloaded through such new uses outside simple name-to-A* record mapping? Are there any worries the system would be overloaded by resolution algorithms that retry various combinations of names and numbers, and resolve each OID representation in multiple steps until a pure canonical form is found? I mean, I don't want to abuse a precious infrastructure. any opinions on that? -Gunther > > O.K. I have set up a pilot for HL7. And have used Robert Elz's > > recommendation to do the canonical OID mapping using PTR records. > > Yeah, PTR should work just fine for reverse lookups. > > > The rule to resolve to an OID is now: > > > > 1. issue resolve query with qtype = PRT, > > 2. in the answers find the name in the OID.ARPA. domain > > 3. clip off .OID.ARPA. > > 4. reverse the number sequence > > > > That's very easy to do. So, no new RR type "OID" would be needed. > > I don't know if that's the best approach. I think you were on the right > track with an explicit OID RR. For example, > > some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 > > would require an explicit OID RR in order to properly encapsulate the OID > data. Standardized intepretations require standardized representations, so > using an explicit OID RR would ensure that the OID value were being > represented properly. > > There are also distinct benefits to having explicit domain name entries, > such as being able to use CNAMEs and additonal RRs. You might want: > > some.other.oid.osi.int. CNAME some.oid.osi.int. > some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 > TXT "OID for XYZ" > RP "oid-admins@xyz.org" > > Etcetera. Building a reverse name from the PTR data won't allow for any of > that to occur. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Sep 22 03:32:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03652 for ; Fri, 22 Sep 2000 03:32:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cMpB-0006rO-00 for namedroppers-data@psg.com; Fri, 22 Sep 2000 00:00:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13cMpB-0006rI-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:00:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13cMpB-000CSl-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:00:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CA68B6.555B6C66@ehsco.com> Date: Thu, 21 Sep 2000 12:59:51 -0700 From: "Eric A. Hall" To: Robert Elz CC: Gunther Schadow , namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? References: <19107.969565561@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 > some.oid.osi.int. PTR 1.2.3.4.5.6.77.88.99.OID.ARPA. > What's the difference? There is no difference if the forward-lookup domain name is defined in both cases. Maybe I read the first message wrong, but it looked like things were leaning towards PTRs without matching forward lookups, which would have only allowed a number-to-name match without any supplemental data being associated with the name. -- 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. From owner-namedroppers@ops.ietf.org Fri Sep 22 03:33:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03681 for ; Fri, 22 Sep 2000 03:33:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cMt2-0007Q8-00 for namedroppers-data@psg.com; Fri, 22 Sep 2000 00:04:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13cMt1-0007Q2-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:04:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13cMt1-000CXk-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:04:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CA77AD.D4C972EE@aurora.rg.iupui.edu> Date: Thu, 21 Sep 2000 16:03:41 -0500 From: Gunther Schadow To: "Eric A. Hall" CC: Robert Elz , namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? References: <19107.969565561@mundamutti.cs.mu.OZ.AU> <39CA68B6.555B6C66@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Eric A. Hall" wrote: > > > | some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 > > > some.oid.osi.int. PTR 1.2.3.4.5.6.77.88.99.OID.ARPA. > > > What's the difference? > > There is no difference if the forward-lookup domain name is defined in > both cases. Maybe I read the first message wrong, but it looked like > things were leaning towards PTRs without matching forward lookups, which > would have only allowed a number-to-name match without any supplemental > data being associated with the name. Forward/backward lookup, hmm. If I read the DNS spec. right, PTR is simply a pointer to another name in the DNS space. As such, there is nothing in the PTR definition that limits it to "backward lookup" of IP names. The other thing is, it doesn't make sense to do backward lookup with OIDs, because OIDs are not addresses. OIDs are really simply names. There are canonical OIDs -- numbers and dots only --, and there are OIDs with some symbolic components. The main use of the DNS is to resolve 1 general DNS names to OIDs 2 OIDs with symbolic components to canonical OIDs 3 canonical OIDs to TXT and RP records, mostly for human consumption. There is not a single backward mapping from a canonical OID to a symbolic OID or general domain name, therefore the kind of backward lookup we have with PTR from the IN-ADDR.ARPA. domain into normal domains does not exists for OIDs. regards -Gunther to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Sep 22 03:33:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03692 for ; Fri, 22 Sep 2000 03:33:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cMm5-0006Lu-00 for namedroppers-data@psg.com; Thu, 21 Sep 2000 23:57:33 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13cMm5-0006Lo-00 for namedroppers@ops.ietf.org; Thu, 21 Sep 2000 23:57:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13cMm4-000CQN-00 for namedroppers@ops.ietf.org; Thu, 21 Sep 2000 23:57:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39CA5F7D.E1E239BF@daimlerchrysler.com> Date: Thu, 21 Sep 2000 15:20:29 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: What are the chances for OID resource records in the DNS? References: <39C7E02D.3E06F511@aurora.rg.iupui.edu> <4.3.2.7.2.20000920121841.078683a8@127.0.0.1> <39C8D5F0.B3E61CE6@aurora.rg.iupui.edu> <39CA4C83.ED29B2D2@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric A. Hall wrote: > Sorry coming into this late. > > In general, I am opposed to using DNS for directory-like functions, since > DNS does not provide directory features like authenticated-vs-anonymous > queries or key indexing/searching against attribute data. Neither of those > issues should be a problem here though, should they? I mean, do you need > to worry about any of the OIDs being returned for anonymous users (since > all DNS queries are anonymous by nature)? > > > O.K. I have set up a pilot for HL7. And have used Robert Elz's > > recommendation to do the canonical OID mapping using PTR records. > > Yeah, PTR should work just fine for reverse lookups. > > > The rule to resolve to an OID is now: > > > > 1. issue resolve query with qtype = PRT, > > 2. in the answers find the name in the OID.ARPA. domain > > 3. clip off .OID.ARPA. > > 4. reverse the number sequence > > > > That's very easy to do. So, no new RR type "OID" would be needed. > > I don't know if that's the best approach. I think you were on the right > track with an explicit OID RR. For example, > > some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 > > would require an explicit OID RR in order to properly encapsulate the OID > data. Standardized intepretations require standardized representations, so > using an explicit OID RR would ensure that the OID value were being > represented properly. > > There are also distinct benefits to having explicit domain name entries, > such as being able to use CNAMEs and additonal RRs. You might want: > > some.other.oid.osi.int. CNAME some.oid.osi.int. > some.oid.osi.int. OID 99.88.77.6.5.4.3.2.1 > TXT "OID for XYZ" > RP "oid-admins@xyz.org" > > Etcetera. Building a reverse name from the PTR data won't allow for any of > that to occur. CNAMEs can point to PTR-owning names (cf. RFC 2317). PTR's can co-exist with other record types. I think PTR works just fine as a generic, non-aliasing, name-to-name mapping type. It is only tradition/convention which limits PTR's to reverse lookups. - 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. From owner-namedroppers@ops.ietf.org Fri Sep 22 03:43:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03727 for ; Fri, 22 Sep 2000 03:43:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cN1r-0008Y4-00 for namedroppers-data@psg.com; Fri, 22 Sep 2000 00:13:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13cN1r-0008Xy-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:13:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13cN1r-000Cft-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:13:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200009220218.e8M2Idi53348@drugs.dv.isc.org> To: Brian Wellington Cc: DNSEXT WG Mailing list From: Mark.Andrews@nominum.com Subject: Re: Same-signed keys In-reply-to: Your message of "Wed, 20 Sep 2000 10:24:11 PDT." Date: Fri, 22 Sep 2000 13:18:39 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Wed, 20 Sep 2000 Mark.Andrews@nominum.com wrote: > >>> I don't see why this situation is fundamentally different from all the >>> other forms of potential infinite loops in DNS (eg, CNAME loops). The >>> traditional solution is a simple counter (RFC-1035, p43, last >>> paragraph). If the only issue here is preventing infinite loops, I >>> don't think that either form of the "always shorter" rule is necessary >>> or desirable. >> >> Supporting looping at the same level helps with really large >> zones or where very long lived keys are required as it can >> reduce the amount of clear text available per key. > > No it doesn't. Having a keyset with multiple keys has this effect. > > Looping just doesn't work. Think of it this way - at the zone apex, > there's a KEY set and a SIG KEY set. Unless this is a security root, the > SIG KEY set must contain a signature from the parent. A resolver should > always attempt to verify that signature. If this is a security root, > there will be no parent signature, so the resolver should attempt to > verify any self-generated signature for which it has a key that it > implicitly trusts or has validated. However, if has any keys that it has > validated, it must have already validated the KEY set, and this is a > pointless revalidation. > You are right. I actually think DNSSEC would be simpler is individual keys as opposed to key sets were signed. It would definitely make key management easier. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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. From owner-namedroppers@ops.ietf.org Fri Sep 22 03:47:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03756 for ; Fri, 22 Sep 2000 03:47:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13cN5u-0009Lj-00 for namedroppers-data@psg.com; Fri, 22 Sep 2000 00:18:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13cN5t-0009Lb-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:18:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13cN5t-000ChL-00 for namedroppers@ops.ietf.org; Fri, 22 Sep 2000 00:18:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gunther Schadow Cc: namedroppers@ops.ietf.org, Harald@alvestrand.no Subject: Re: What are the chances for OID resource records in the DNS? In-Reply-To: Message from Gunther Schadow of "Tue, 19 Sep 2000 19:15:43 EDT." <39C7E02D.3E06F511@aurora.rg.iupui.edu> Date: Fri, 22 Sep 2000 02:31:39 -0400 From: Rob Austein Message-Id: <20000922063145.2533B8C4C@pak.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Be warned that US Patent 6,003,077 (probably, I'm not a lawyer) covers some of the territory you're talking about. To the best of my knowledge the rights to that patent are held by Wind River Systems. I hereby request that the namedroppers moderator rule the inevitable flamage about software patents out of scope. For the record, in a probably futile attempt to save the moderator some work: I tried and failed to talk my former employer out of patenting this. [ will do -- rb ] to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Sep 23 13:30:21 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22665 for ; Sat, 23 Sep 2000 13:30:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13csMT-000EPp-00 for namedroppers-data@psg.com; Sat, 23 Sep 2000 09:41:13 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13csMS-000EPj-00 for namedroppers@ops.ietf.org; Sat, 23 Sep 2000 09:41:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13csMS-00053q-00 for namedroppers@ops.ietf.org; Sat, 23 Sep 2000 09:41:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Bernard Aboba" To: Subject: Comments on draft-aboba-dnsext-mdns-01.txt? Date: Sat, 23 Sep 2000 08:02:42 -0700 Message-Id: In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a request for feedback on draft-aboba-dnsext-mdns-01.txt. Please post comments to the list and/or the authors. Ideally we would like to get a revised version of the draft out by the second week of October. The revised version will be renamed as a WG draft, as decided at IETF 48. Since this is an early draft there are probably a lot of things to be fixed and improved. To speed that process along, if you have specific text you'd like to change, it would be helpful if you could include the suggested replacement text with your comment so that we can incorporate your changes quickly. All suggestions/comments will be acknowledged in the acknowledgments section. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Sep 28 13:34:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27401 for ; Thu, 28 Sep 2000 13:34:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13egol-000EzQ-00 for namedroppers-data@psg.com; Thu, 28 Sep 2000 09:45:55 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13egol-000EzK-00 for namedroppers@ops.ietf.org; Thu, 28 Sep 2000 09:45:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13egol-0002tI-00 for namedroppers@ops.ietf.org; Thu, 28 Sep 2000 09:45:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D37541.7BB2C505@ehsco.com> Date: Thu, 28 Sep 2000 09:43:45 -0700 From: "Eric A. Hall" To: namedroppers Subject: [Fwd: RFC 2916 on E.164 number and DNS] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Although I confess to being out of the loop on many things, I have a couple of issues with this particular RR. As I have stated many times, DNS is a lousy directory, partly due to an inability to provide different answer sets in response to different query sources. There is no way to provide one set of RRs to anonymous users versus detailed answers to specific users versus other detailed answers to other users. It would seem that that this particular extension would pretty much require such a mechanism in order to be fully realized, and as such, DNS is the wrong database for this extension. "2. E.164 numbers and DNS "The domain "e164.arpa" is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers." Shouldn't that be the e164.int tree? Considering the number of similar RRs that have been shot down by this group, I am surprised that this one went through. Was this group included in the development of this RR? The announcement didn't go here. -- 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. From owner-namedroppers@ops.ietf.org Thu Sep 28 15:16:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00075 for ; Thu, 28 Sep 2000 15:16:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13eihz-000GPB-00 for namedroppers-data@psg.com; Thu, 28 Sep 2000 11:47:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13eihz-000GP5-00 for namedroppers@ops.ietf.org; Thu, 28 Sep 2000 11:47:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13eihy-0003pw-00 for namedroppers@ops.ietf.org; Thu, 28 Sep 2000 11:47:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Eric A. Hall" Cc: namedroppers Subject: Re: [Fwd: RFC 2916 on E.164 number and DNS] References: <39D37541.7BB2C505@ehsco.com> Message-Id: Date: Thu, 28 Sep 2000 11:44:21 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Shouldn't that be the e164.int tree? see > Considering the number of similar RRs that have been shot down by this > group, I am surprised that this one went through. it's not an rr randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Sep 28 18:36:21 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04203 for ; Thu, 28 Sep 2000 18:36:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13elrR-000Ig6-00 for namedroppers-data@psg.com; Thu, 28 Sep 2000 15:09:01 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13elrR-000Ig0-00 for namedroppers@ops.ietf.org; Thu, 28 Sep 2000 15:09:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13elrR-0005Eq-00 for namedroppers@ops.ietf.org; Thu, 28 Sep 2000 15:09:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D3BA21.80D86DC3@ehsco.com> Date: Thu, 28 Sep 2000 14:37:37 -0700 From: "Eric A. Hall" CC: namedroppers Subject: Re: [Fwd: RFC 2916 on E.164 number and DNS] References: <200009282025.QAA15827@hun.gw.tislabs.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ as this is not a protocol issue, the discussion will please move to dnsop or poisson. this is the last message i will approve on the topic -- randy ] Good thing I made a disclaimer Olafur Gudmundsson wrote: > > "Eric A. Hall" writes > > > > "2. E.164 numbers and DNS > > > > "The domain "e164.arpa" is being populated in order to provide the > > infrastructure in DNS for storage of E.164 numbers." > > > > Shouldn't that be the e164.int tree? > > > > Due to ownership issues of ".int" domain, all registrations that need > persistent name are now registered in the .arpa domain. > IPv6 reverse map just migrated from .int to .arpa, in RFC2874 > like this into the IESG controlled .arpa domain. I suppose there will be an RFC on this that updates the definitions made in RFC 1591? Just curious. > > Considering the number of similar RRs that have been shot down by > > this group, I am surprised that this one went through. Was this > > group included in the development of this RR? The announcement > > didn't go here. > > Not a new RR, just new use of an existing RR, thus no changes to > servers or resolvers only applications that want to use this. Okay, that's the correct way to state it. I don't know why I wrote what I did when it's obviously not a new RR, but instead is an arbitrary addition to the namespace for the sole purpose of adding an arbitrary index for non-existent objects. I suppose my concern is: the namespace has historically provided an index for RRs sorted by domain name, except for a couple of cases where the RRs needed to be sorted by value (A records). My understanding is that there has been resistance to adding new indexes based on other RRs (a namespace hierarchy for MX RRs that listed mail servers with the mail domains that they serve could be useful) and there has been resistance to RRs that provide directory-like functionality, since both of those extensions would take DNS beyond the boundaries of a naming service. In that light, the addition of an index of objects that don't exist as resources on the Internet in any form seems somewhat surprising. This is particularly true given that the long-term benefits of the index would be to provide authenticated answers (anonymous data, data for my boss, data for my family). Isn't this exactly the purpose of a directory, and the exact antithesis of a limited-scope naming service like DNS? I have no position on it one way or the other. I find it confusing that one group will play whack-a-mole on any extension effort while others will gladly extend DNS however they see fit. This will probably get political fast so I will stop. Just interesting. -- 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. From owner-namedroppers@ops.ietf.org Thu Sep 28 18:37:06 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04220 for ; Thu, 28 Sep 2000 18:37:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13eleG-000IVc-00 for namedroppers-data@psg.com; Thu, 28 Sep 2000 14:55:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13eleG-000IVW-00 for namedroppers@ops.ietf.org; Thu, 28 Sep 2000 14:55:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13eleF-00057p-00 for namedroppers@ops.ietf.org; Thu, 28 Sep 2000 14:55:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200009282025.QAA15827@hun.gw.tislabs.com> To: "Eric A. Hall" cc: namedroppers Subject: Re: [Fwd: RFC 2916 on E.164 number and DNS] In-reply-to: Your message of "Thu, 28 Sep 2000 09:43:45 PDT." <39D37541.7BB2C505@ehsco.com> Date: Thu, 28 Sep 2000 16:25:47 -0400 From: Olafur Gudmundsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Eric A. Hall" writes > > "2. E.164 numbers and DNS > > "The domain "e164.arpa" is being populated in order to provide the > infrastructure in DNS for storage of E.164 numbers." > > Shouldn't that be the e164.int tree? > Due to ownership issues of ".int" domain, all registrations that need persistent name are now registered in the .arpa domain. IPv6 reverse map just migrated from .int to .arpa, in RFC2874 like this into the IESG controlled .arpa domain. > > Considering the number of similar RRs that have been shot down by this > group, I am surprised that this one went through. Was this group included > in the development of this RR? The announcement didn't go here. Not a new RR, just new use of an existing RR, thus no changes to servers or resolvers only applications that want to use this. 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. From owner-namedroppers@ops.ietf.org Fri Sep 29 08:44:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28284 for ; Fri, 29 Sep 2000 08:44:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13eymg-0000hK-00 for namedroppers-data@psg.com; Fri, 29 Sep 2000 04:56:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13eymg-0000hE-00 for namedroppers@ops.ietf.org; Fri, 29 Sep 2000 04:56:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13eymg-000Aa7-00 for namedroppers@ops.ietf.org; Fri, 29 Sep 2000 04:56:58 -0700 Message-Id: <200009291101.HAA26191@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-message-size-01.txt Date: Fri, 29 Sep 2000 07:01:07 -0400 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 and IPv6 A6 aware server/resolver message size requirements Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-message-size-01.txt Pages : 6 Date : 28-Sep-00 This document mandates support for EDNS0 in DNS entities claiming to support DNS Security Extensions and A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fallback to TCP will happen, having a detrimental impact on query latency and DNS server load. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-01.txt 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-message-size-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-message-size-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: <20000928115159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-message-size-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-message-size-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000928115159.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. From owner-namedroppers@ops.ietf.org Fri Sep 29 14:33:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04951 for ; Fri, 29 Sep 2000 14:33:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13f4KJ-0004TO-00 for namedroppers-data@psg.com; Fri, 29 Sep 2000 10:52:03 -0700 Received: from adsl-63-206-97-82.dsl.snfc21.pacbell.net ([63.206.97.82] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 13f4KI-0004TI-00 for namedroppers@ops.ietf.org; Fri, 29 Sep 2000 10:52:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13f4KH-0000Bw-00 for namedroppers@ops.ietf.org; Fri, 29 Sep 2000 10:52:01 -0700 Message-Id: <4.3.2.7.2.20000929103717.00b2ee20@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Sep 2000 10:45:45 -0400 To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-message-size-01.txt In-Reply-To: <200009291101.HAA26191@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Summary off changes: More explicit rationale in introduction, including why we want to start fragmenting DNS answers. Larger sizes required than in old version, different sizes required for DNSSEC and IPv6 but larger size required for support of both. I put in a requirement there that hosts supporting EDNS0 MUST be able to deal with fragmented UDP messages. Please send comments. Olafur PS: to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Sep 30 18:00:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01447 for ; Sat, 30 Sep 2000 18:00:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 13fU5R-000MXW-00 for namedroppers-data@psg.com; Sat, 30 Sep 2000 14:22:25 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.16 #1) id 13fU5R-000MXJ-00 for namedroppers@ops.ietf.org; Sat, 30 Sep 2000 14:22:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13fU5Q-000PkW-00 for namedroppers@ops.ietf.org; Sat, 30 Sep 2000 14:22:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Bernard Aboba" To: Subject: Issues with draft-aboba-dnsext-mdns-01.txt Date: Sat, 30 Sep 2000 11:58:13 -0700 Message-Id: In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To stimulate discussion, I thought I'd post a list of issues that came up in the process of going over the draft. If you have opinions on these or other topics, please respond to the list. a. Does mDNS apply only to QCLASS=IN or can it apply to other QCLASSes as well? b. Should the response only return NS and SOA RRs to a query with QTYPE=ANY? Or should it return other records as well? c. Are there any OPCODE restrictions (e.g. no OPCODE=1?) d. What happens if the TC flag is set in the reply? e. Should the response always have the RA bit clear? What if it doesn't? f. Are RRs ever returned in the additional section? If so, is any language required in the draft relating to validation of these RRs? g. Should the AA bit be set in responses? h. Should we have any language about what should be permitted in the ensuing unicast queries? i. What is the default value of TTL used in unicast queries? j. What is the implied TTL for negative caching when there is no multicast response? k. Is no response equivalent to NXRRSET or NXDOMAIN? l. How will mDNS work with DNSSEC? Hosts can generate KEY and SIG RRs, but how can they get the KEY record signed? There is no name server authoritative for the .lcl.arpa domain, right? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.