From owner-namedroppers@ops.ietf.org Thu Mar 2 13:28:39 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22082 for ; Thu, 2 Mar 2000 13:28:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12QZPr-000IG5-00 for namedroppers-data@psg.com; Thu, 02 Mar 2000 09:29:35 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12QZPq-000IFz-00 for namedroppers@ops.ietf.org; Thu, 02 Mar 2000 09:29:34 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12QZPq-000Knu-00 for namedroppers@ops.ietf.org; Thu, 02 Mar 2000 09:29:34 -0800 Message-Id: <200003021532.KAA15187@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-tkey-01.txt Date: Thu, 02 Mar 2000 10:32:43 -0500 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 : Secret Key Establishment for DNS (TKEY RR) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tkey-01.txt Pages : 17 Date : 01-Mar-00 [draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-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-tkey-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-tkey-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: <20000301115259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000301115259.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 Thu Mar 2 13:28:49 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22098 for ; Thu, 2 Mar 2000 13:28:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12QZPl-000IFt-00 for namedroppers-data@psg.com; Thu, 02 Mar 2000 09:29:29 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12QZPl-000IFn-00 for namedroppers@ops.ietf.org; Thu, 02 Mar 2000 09:29:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12QZPl-000Knq-00 for namedroppers@ops.ietf.org; Thu, 02 Mar 2000 09:29:29 -0800 Message-Id: <200003021532.KAA15164@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-sig-zero-00.txt Date: Thu, 02 Mar 2000 10:32:37 -0500 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 Request and Transaction Signatures ( SIG(0)s ) Author(s) : D. Eastlake Filename : draft-ietf-dnsext-sig-zero-00.txt Pages : 9 Date : 01-Mar-00 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-sig-zero-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-sig-zero-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-sig-zero-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: <20000301115227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-sig-zero-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-sig-zero-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000301115227.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 Thu Mar 2 17:20:10 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29713 for ; Thu, 2 Mar 2000 17:20:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12QdCj-000One-00 for namedroppers-data@psg.com; Thu, 02 Mar 2000 13:32:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12QdCi-000OnY-00 for namedroppers@ops.ietf.org; Thu, 02 Mar 2000 13:32:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12QdCh-000Mjh-00 for namedroppers@ops.ietf.org; Thu, 02 Mar 2000 13:32:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <726A4C58DBA56E409F3D3563A8BF953C09ECE8@airstream-corp.platinum.corp.microsoft.com> From: Peter Ford To: "'Al Costanzo'" , "Donald E. Eastlake 3rd" , "Namedroppers@Internic.Net" Subject: RE: "local" names Date: Thu, 2 Mar 2000 10:44:04 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit how about ".notglobal", or simply ".not". The critical attribute is that the name is NOT part of the guaranteed to unique global namespace. I also think it might be useful to have another name: ".linklocal". fwiw, peterf -----Original Message----- From: Al Costanzo [mailto:al@akc.com] Sent: Tuesday, December 28, 1999 1:24 PM To: Donald E. Eastlake 3rd; Namedroppers@Internic.Net Subject: RE: "local" names IMHO, I think this is a good idea. I can remember 10 years ago when Prime computer setup a private network that wrapped around the world with thousands upon thousands of nodes within it. Would have been marvelous then as well as now. As far as the suffix is concerned, my own opinion would be to use: '.intra'. Everyone is familiar with the word Intranet vs. Internet so it makes sense to me to base the phrase-oligy on something familiar. | -----Original Message----- | From: owner-namedroppers@internic.net | [mailto:owner-namedroppers@internic.net]On Behalf Of Donald | E. Eastlake | 3rd | Sent: luned=EC 27 dicembre 1999 8.53 | To: namedroppers@internic.net | Subject: "local" names | | | I have received a request to change "local" in | draft-ietf-dnsind-local-names-07.txt. In particular, the | correspondent | said: | | | ... I do prefer another name though. Something like .intra or | .internal. These names associate better with the meaning of an | internal network. Moreover, internal networks of big | companies tend to | have a global coverage rather then a local one. .Intra or .internal | nicely fit into: | www.mycompany.com is for our international customers, | www.mycompany.nl aims at customers in The Netherlands, | etc. | www.mycompany.intra aims at the employee's of the company. | | | Does anyone on namedroppers have an opinon on this? | | Thanks, | Donald | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Donald E. Eastlake 3rd +1 914-276-2668 dee3@torque.pothole.com | 65 Shindegan Hill Rd, RR#1 +1 914-784-7913(w) dee3@us.ibm.com | Carmel, NY 10512 USA | 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 Mar 3 09:18:25 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27784 for ; Fri, 3 Mar 2000 09:18:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Qrlw-000Bfv-00 for namedroppers-data@psg.com; Fri, 03 Mar 2000 05:05:36 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Qrlw-000BfR-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 05:05:36 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Qrlv-0003BO-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 05:05:35 -0800 Message-Id: <200003031126.GAA22462@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-apl-rr-00.txt Date: Fri, 03 Mar 2000 06:26:45 -0500 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 : A DNS RR Type for Lists of Address Prefixes (APL RR) Author(s) : P. Koch Filename : draft-ietf-dnsext-apl-rr-00.txt Pages : 7 Date : 02-Mar-00 The Domain Name System is primarily used to translate domain names into IPv4 addresses using A RRs. Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type 'APL' for address prefix lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-apl-rr-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-apl-rr-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-apl-rr-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: <20000302145807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-apl-rr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-apl-rr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000302145807.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 Mar 3 09:18:26 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27787 for ; Fri, 3 Mar 2000 09:18:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Qrm6-000Bg5-00 for namedroppers-data@psg.com; Fri, 03 Mar 2000 05:05:46 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Qrm6-000Bfz-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 05:05:46 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Qrm6-0003BU-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 05:05:46 -0800 Message-Id: <200003031126.GAA22476@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-tsig-00.txt Date: Fri, 03 Mar 2000 06:26:51 -0500 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 : Secret Key Transaction Authentication for DNS (TSIG) Author(s) : P. Vixie, O.Gudmundsson, D. Eastlake, B. Wellington Filename : draft-ietf-dnsext-tsig-00.txt Pages : 15 Date : 02-Mar-00 This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-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-tsig-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-tsig-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: <20000302145818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tsig-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tsig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000302145818.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 Sat Mar 4 01:26:21 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19491 for ; Sat, 4 Mar 2000 01:26:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12R7Nu-00030a-00 for namedroppers-data@psg.com; Fri, 03 Mar 2000 21:45:50 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12R7Nu-00030U-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 21:45:50 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12R7Nt-0008sS-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 21:45:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000303131708.00a33a30@mail.gw.tislabs.com> Date: Fri, 03 Mar 2000 13:33:36 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: SIG(0) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a last call on this document, SIG(0) updates RFC2535 in the definition of transaction signatures. The changes are mostly to make SIG(0) more like TSIG in implementation and result of implementation experience. SIG(0) is required for TKEY exchange when no existing shared secret between two DNS entities exist. This is a WG last call ending March 20'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-sig-zero-00.txt This draft is on standards track, if you disagree with that please state why in your response. 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 Mar 4 01:26:24 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19512 for ; Sat, 4 Mar 2000 01:26:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12R7Sc-0003Jq-00 for namedroppers-data@psg.com; Fri, 03 Mar 2000 21:50:42 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12R7Sc-0003Ji-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 21:50:42 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12R7Sc-0008uI-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 21:50:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000303133724.00a07670@mail.gw.tislabs.com> Date: Fri, 03 Mar 2000 13:51:32 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: DNS-IANA-00 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a second last call on this draft, authors have addressed all the issues raised in the first round. This document has provides general guidance to IANA for DNS related reservations. This is a WG last call ending March 14'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-iana-dns-00.txt This document is to published as a BCP, if you disagree with that please state your reasons. 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 Mar 4 01:26:25 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19513 for ; Sat, 4 Mar 2000 01:26:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12R7Tu-0003W0-00 for namedroppers-data@psg.com; Fri, 03 Mar 2000 21:52:02 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12R7Tu-0003Vu-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 21:52:02 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12R7Tu-0008uh-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 21:52:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003031920.OAA07939@torque.pothole.com> To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: TKEY In-reply-to: Your message of "Mon, 07 Feb 2000 09:10:30 EST." Date: Fri, 03 Mar 2000 14:20:00 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: Edward Lewis X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <200002070426.XAA05296@torque.pothole.com> References: Your message of "Tue, 04 Jan 2000 09:50:00 EST." Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Feb 2000 09:10:30 -0500 To: "Donald E. Eastlake 3rd" Cc: Edward Lewis , "Donald E. Eastlake 3rd" , namedroppers@internic.net >At 11:26 PM -0500 2/6/00, Donald E. Eastlake 3rd wrote: >>However, I must say that the process of reviewing and re-organization >>this material was a lot more work than I thought it would be and has >>lead, in my opinion, to a lot more improvement than I though it would. >>In fact, I found cases that said "SHOULD" which have to say "MUST" to >>actually achieve security. > >This is what I thought would happen. By following a stricter discipline >(e.g., no requirements in intro, discussions), I have found that the result >is much better. Not only do the aesthetics improve, the reorganization >effort often finds other places where one can tighten the work. I think >the reason is that the author sees the requirements from another angle, >performing another round of requirements analysis. > >>Based on all this it seems best to not use the DNS header RCODE field, >>so the current -dnsind-tkey-03.txt draft on page 7 where the error >>codes are listed says the following which I essentially plan to retain >>in the next draft: >> >> When an extended RCODE appears in the TKEY in a response, the DNS >> header RCODE field indicates no error. > >I think it is wise to report an error just once, lest you start seeing >messages with multiple error codes, leading to confusion by the reader. >Writing a "good" client that understands the error codes is very hard once >we start indicating multiple failures. > >OTOH, reporting "no error" in the header field is probably misleading, is >there a "error inside" value? That being said, I think having "no error" >in the header field is better than having some other specific error code >there. Deciding to minimize changes, I left it as "no error" in the updated version of the draft just announced today. >--- > >There is a paper by Ferguson & Schneier called "A Cryptographic Evaluation >of IPsec," unfortunately I have a copy for which I cannot give a published >reference[1] (it was handed to me). In this, they[2] criticize IPsec from >a security/cryptographic point of view. I think that some of the >interesting points are the claims that the documentation of IPsec prevents >good security analysis, as well as the protocol's complexity making it hard >to ensure that security is "attained." The reason I am riding the DNS >security documents hard is to try and avoid the same criticisms if DNS >security. It's at . The IPSEC/ISAKMP/IKE/... melange is an order of magnitude more complex than all proposals for DNS security put together. >[1] There is a URL: www.counterpane.com under the title. >[2] Assuming the paper did not forge their typed names...;) > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis NAI Labs >Phone: +1 443-259-2352 Email: lewis@tislabs.com > >"Trying is the first step to failure." - Homer Simpson >"No! Try not. Do... or do not. There is no try." - Yoda >"It takes years of training to know when to do nothing" - Dogbert 1/21/00 > >Opinions expressed are property of my evil twin, not my employer. Thanks, Donald =================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Rd, RR#1 lde008@dma.isg.mot.com Carmel, NY 10512 USA +1 914-276-2668(h) +1 508-261-5434(w) 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 Mar 4 01:38:36 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19490 for ; Sat, 4 Mar 2000 01:26:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12R7OG-00030k-00 for namedroppers-data@psg.com; Fri, 03 Mar 2000 21:46:12 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12R7OF-00030e-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 21:46:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12R7OF-0008sc-00 for namedroppers@ops.ietf.org; Fri, 03 Mar 2000 21:46:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000303131618.00a36e90@mail.gw.tislabs.com> Date: Fri, 03 Mar 2000 13:33:28 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: TKEY-01 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a last call on this document, TKEY defines a DNS protocol mechanism to allow two DNS entities to create a shared secret to be used by TSIG for message authentication. The document defines two mandatory modes to implement and few optional ones. This is a WG last call ending March 20'th 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-01.txt This draft is on standards track, if you disagree with that please state why in your response. 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 Mon Mar 6 09:06:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06512 for ; Mon, 6 Mar 2000 09:06:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Rx1X-000GNd-00 for namedroppers-data@psg.com; Mon, 06 Mar 2000 04:54:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Rx1W-000GNX-00 for namedroppers@ops.ietf.org; Mon, 06 Mar 2000 04:54:10 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Rx1W-00058m-00 for namedroppers@ops.ietf.org; Mon, 06 Mar 2000 04:54:10 -0800 Message-Id: <200003061157.GAA02568@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-axfr-clarify-00.txt Date: Mon, 06 Mar 2000 06:57:59 -0500 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 Zone Transfer Protocol Clarifications Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-00.txt Pages : 5 Date : 03-Mar-00 In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-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-axfr-clarify-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-axfr-clarify-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: <20000303145725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000303145725.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 Mar 7 20:00:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20607 for ; Tue, 7 Mar 2000 20:00:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SU8u-0006LK-00 for namedroppers-data@psg.com; Tue, 07 Mar 2000 16:16:00 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12SU8t-0006L8-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 16:15:59 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12SU9B-0002KQ-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 16:16:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Mar 2000 15:39:27 -0500 (EST) From: Brian Wellington To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: SIG(0) In-Reply-To: <4.1.20000303131708.00a33a30@mail.gw.tislabs.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 3 Mar 2000, Olafur Gudmundsson wrote: > This is a last call on this document, SIG(0) updates RFC2535 in > the definition of transaction signatures. The changes are mostly > to make SIG(0) more like TSIG in implementation and result of > implementation experience. > SIG(0) is required for TKEY exchange when no existing shared secret > between two DNS entities exist. Once again, I suggest that the number of SIG(0) signatures per message be restricted to 1. Allowing more than one introduces unnecessary complexity. The only benefit would be to allow TKEY-generated TSIGs to have multiple authorizations (derived from each signing SIG(0)), but the necessity of this feature is unconvincing. Also, multiple authorizations can lead to conflicts whose resolution is not specified in any document. 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 Mar 7 20:00:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20619 for ; Tue, 7 Mar 2000 20:00:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SU4g-0006HS-00 for namedroppers-data@psg.com; Tue, 07 Mar 2000 16:11:38 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12SU4f-0006H1-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 16:11:37 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12SSho-0001e7-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 14:43:56 -0800 Message-Id: <200003071128.GAA28748@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-ixfr-00.txt Date: Tue, 07 Mar 2000 06:28:14 -0500 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 : Incremental Zone Transfer in DNS Author(s) : M. Ohta Filename : draft-ietf-dnsext-ixfr-00.txt Pages : 10 Date : 06-Mar-00 This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-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-ixfr-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-ixfr-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: <20000306120236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ixfr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ixfr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120236.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 Mar 7 20:00:46 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20723 for ; Tue, 7 Mar 2000 20:00:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SU5V-0006I8-00 for namedroppers-data@psg.com; Tue, 07 Mar 2000 16:12:29 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12SU5U-0006I0-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 16:12:29 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12SPqk-0000dO-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 11:40:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000306100528.009f0340@mail.gw.tislabs.com> Date: Mon, 06 Mar 2000 10:17:17 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Last call reminder: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We now have 5 documents in Last call, without any comments. Here is a list of the documents in last call and the deadline for comments on each one. Remember it is Randy and my job to judge the consensus of the group but to do so we need some feedback on each one of these documents. I would like to finish as many of these important documents before or at Adelaide meeting. Due March 8'th 2000: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-00.txt and http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update- 00.txt Due March 14'th 2000. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-iana-dns-00.txt Due March 20'th 2000. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-sig-zero-00.txt and http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-01.txt 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 Mar 7 20:01:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21115 for ; Tue, 7 Mar 2000 20:01:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SU3u-0006GO-00 for namedroppers-data@psg.com; Tue, 07 Mar 2000 16:10:50 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12SU3t-0006GI-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 16:10:50 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12STB2-00028w-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 15:14:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Mar 2000 13:23:38 -0500 Message-Id: <200003071823.NAA11606@hun.gw.tislabs.com> From: Olafur Gudmundsson To: namedroppers@ops.ietf.org Subject: Summary of TSIG changes since IETF last call Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There have been a number of changes requested by the IESG and IETF Last call commentators. Current draft addresses all the concerns and issues. TSIG draft now distinguishes between Transaction Signatures (SIG(0)) and message authentication code (MAC). Change insisted upon by Steve Kent. New algorithms MUST be registered with IANA. Algorithm name is now domain name encoding of a character string and there is no requirement that it is a resolvable name. Old version did not capitalize all MUST/SHOULD/MAY/REQUIRED statements, fixed. Wording on truncation case made clearer, processing of Incoming messages (section 3.2) contains more explicit MUST and SHOULD statements. Section 4.2 now explicitly outlaws servers from adding a TSIG to a unsigned query. Section 4.5.2 has added text about replay prevention and allows servers to discard TSIG messages if one with more recent time has been received. Section 7 IANA considerations has been rewritten to reflect the requirements that algorithm names are unique and not a valid domain names. The name "HMAC-MD5.SIG-ALG.REG.INT" is grandfathered in as a name to allow exisiting implementations to function. New paragraph has been added to cover assignment of new TSIG error codes. 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 Mar 7 20:23:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20606 for ; Tue, 7 Mar 2000 20:00:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SU85-0006KR-00 for namedroppers-data@psg.com; Tue, 07 Mar 2000 16:15:09 -0800 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12SU84-0006KL-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 16:15:09 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12SU8M-0002KM-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 16:15:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Mar 2000 15:26:18 -0500 (EST) From: Brian Wellington To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TKEY-01 In-Reply-To: <4.1.20000303131618.00a36e90@mail.gw.tislabs.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 3 Mar 2000, Olafur Gudmundsson wrote: > This is a last call on this document, TKEY defines a DNS protocol > mechanism to allow two DNS entities to create a shared secret to be > used by TSIG for message authentication. I have no objections, but one question. Transaction security MUST be applied to many of the TKEY transactions, but there is no specified error to return if there is no transaction security. I'd vote for rcode NOTAUTH, but anything else would be ok too. 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 Wed Mar 8 02:10:43 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17241 for ; Wed, 8 Mar 2000 02:10:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Sa8S-000E6i-00 for namedroppers-data@psg.com; Tue, 07 Mar 2000 22:39:56 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Sa8R-000E6c-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 22:39:55 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Sa8R-0000L7-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 22:39:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003080431.UAA20066@toad.com> To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org, gnu@toad.com Subject: Re: Last call reminder: In-reply-to: <4.1.20000306100528.009f0340@mail.gw.tislabs.com> Date: Tue, 07 Mar 2000 20:31:05 -0800 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > We now have 5 documents in Last call, without any comments. > Here is a list of the documents in last call and the deadline > for comments on each one. > Remember it is Randy and my job to judge the consensus of the group but > to do so we need some feedback on each one of these documents. I think the WG has successfully worn out just about everyone who cares, by constant rewriting of standards that we haven't ever field-tested. I certainly can't dedicate the time to keep up with all these paper standards. Please allow me to recommend that all of them be discarded or delayed indefinitely, until we have some operational experience with the draft standards that preceded them. Now you have one comment for your last call. 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 Wed Mar 8 02:10:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17274 for ; Wed, 8 Mar 2000 02:10:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Sa6b-000E5I-00 for namedroppers-data@psg.com; Tue, 07 Mar 2000 22:38:01 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Sa6a-000E5C-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 22:38:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Sa6a-0000KM-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 22:38:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003080349.WAA11445@torque.pothole.com> To: Brian Wellington cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: SIG(0) In-reply-to: Your message of "Tue, 07 Mar 2000 15:39:27 EST." Date: Tue, 07 Mar 2000 22:49:21 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Actually, although multiple different authorization was the only reason I mentioned when we last talked about this, there is another. With TSIG, you have (or at least believe you have) a shared (secret) key and algorithm. With SIG(0), you typically don't have or need that since the public key to verify the signature can be obtained from the DNS. However, that also means you don't know what algorithm(s) the server understands. So you might want to have, for example, two signatures giving exactly the same authorization but with diffeent algorithms and the understanding would be that if any SIG(0) for that specific authorization verified, you have the authority indicated (assuming it conforms to server policy, etc.). I suppose it could also be possible that during some key rollover situation with some clock jitter, you might want two signatures with the same authority and algorithm but different keys, although usually you would arrange for the key validities to overlap enough that it wouldn't be a problem. Donald From: Brian Wellington Date: Tue, 7 Mar 2000 15:39:27 -0500 (EST) To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org In-Reply-To: <4.1.20000303131708.00a33a30@mail.gw.tislabs.com> Message-ID: >On Fri, 3 Mar 2000, Olafur Gudmundsson wrote: > >> This is a last call on this document, SIG(0) updates RFC2535 in >> the definition of transaction signatures. The changes are mostly >> to make SIG(0) more like TSIG in implementation and result of >> implementation experience. >> SIG(0) is required for TKEY exchange when no existing shared secret >> between two DNS entities exist. > >Once again, I suggest that the number of SIG(0) signatures per message be >restricted to 1. Allowing more than one introduces unnecessary >complexity. The only benefit would be to allow TKEY-generated TSIGs to >have multiple authorizations (derived from each signing SIG(0)), but the >necessity of this feature is unconvincing. Also, multiple authorizations >can lead to conflicts whose resolution is not specified in any document. > >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. 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 Mar 8 02:21:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21770 for ; Wed, 8 Mar 2000 02:21:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Sa6j-000E5T-00 for namedroppers-data@psg.com; Tue, 07 Mar 2000 22:38:09 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Sa6j-000E5N-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 22:38:09 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Sa6j-0000KV-00 for namedroppers@ops.ietf.org; Tue, 07 Mar 2000 22:38:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003080350.WAA11395@torque.pothole.com> To: Brian Wellington cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: TKEY-01 In-reply-to: Your message of "Tue, 07 Mar 2000 15:26:18 EST." Date: Tue, 07 Mar 2000 22:50:19 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That would be fine with me. Donald From: Brian Wellington Date: Tue, 7 Mar 2000 15:26:18 -0500 (EST) To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org In-Reply-To: <4.1.20000303131618.00a36e90@mail.gw.tislabs.com> Message-ID: >On Fri, 3 Mar 2000, Olafur Gudmundsson wrote: > >> This is a last call on this document, TKEY defines a DNS protocol >> mechanism to allow two DNS entities to create a shared secret to be >> used by TSIG for message authentication. > >I have no objections, but one question. Transaction security MUST be >applied to many of the TKEY transactions, but there is no specified error >to return if there is no transaction security. I'd vote for rcode >NOTAUTH, but anything else would be ok too. > >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 Wed Mar 8 10:37:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22115 for ; Wed, 8 Mar 2000 10:37:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12ShpR-0001Mg-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 06:52:49 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12ShpR-0001MZ-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 06:52:49 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12ShpR-0003AX-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 06:52:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200003080349.WAA11445@torque.pothole.com> References: Your message of "Tue, 07 Mar 2000 15:39:27 EST." Date: Wed, 8 Mar 2000 09:01:13 -0500 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: DNSEXT WG Last Call: SIG(0) Cc: Brian Wellington , Olafur Gudmundsson , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Brian. If we start with one signature and, given operational experience demanding multiple signatures, later expand the protocol to allow multiple we will be better off that with the alternative. If we start with multiple but decide single is the way to go, then we will have deployed resolvers that won't interoperate with new servers. Given the choice between a restrictive system (one sig) and a more flexible system (multi sigs), the more restrictive will be more secure in an operational setting. I don't care if "theoretically" multi sigs are as safe as single sigs, once we get into operations, if a critical assumptions supporting the proof is voided, the proof is useless.[1] At 10:49 PM -0500 3/7/00, Donald E. Eastlake 3rd wrote: >Actually, although multiple different authorization was the only >reason I mentioned when we last talked about this, there is another. > ... > >From: Brian Wellington >Date: Tue, 7 Mar 2000 15:39:27 -0500 (EST) >To: Olafur Gudmundsson >cc: namedroppers@ops.ietf.org >> >>Once again, I suggest that the number of SIG(0) signatures per message be >>restricted to 1. Allowing more than one introduces unnecessary [1] Gratuitous analogy - there was once a race between a Porsche and a Chevy. Although standing still the Prosche was a faster vehicle and the course was thought to favor it, the Chevy won. The reason turned out to be Chevy's lack of aerodynamic styling. The (paved) road course was somewhat uneven (few potholes, other depressions), leaving small pockets of vaccuum as the Porsche rushed by. The Chevy didn't have the vaccuum problems since it didn't hug the road. The moral is - the Porsche assumed a flat surface, but in the real world, the road settles. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 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 Mar 8 10:38:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22231 for ; Wed, 8 Mar 2000 10:38:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12ShjT-0001Ce-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 06:46:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12ShjT-0001CY-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 06:46:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12ShjT-000384-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 06:46:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003081344.IAA12336@torque.pothole.com> To: namedroppers@ops.ietf.org Subject: Re: Last call reminder: In-reply-to: Your message of "Tue, 07 Mar 2000 20:31:05 PST." <200003080431.UAA20066@toad.com> Date: Wed, 08 Mar 2000 08:44:05 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While there certainly is a problem with lack of energy and participation in the WG, and with lack of deployment, I don't see throwing away the current drafts or delaying going to RFC as a solution. In many cases the drafts are simplifications or clarification that have been derived from implementation or attempted implementation. To just throw them out would leave the previous complex and/or unclear RFCs as the only reference. And going to RFC gives wider notice and is considered by some as an important factor in favor of implementation and deployment. I'm not sure what the answer is. Maybe we need some really controversial drafts so as to get people's interest and energy levels up higher and cause more comment... the most recent large spurt of comments was on my .local draft. Guess it's time to integrate those comments and re-issue it :-) Actaully, I don't think the lack of comments is quite as bad as it seems. In many cases the drafts have been commented on before and those comments integrated or at least some comments were passed around when the draft first came out, before the last call. Thanks, Donald From: John Gilmore Message-Id: <200003080431.UAA20066@toad.com> To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org, gnu@toad.com In-reply-to: <4.1.20000306100528.009f0340@mail.gw.tislabs.com> Date: Tue, 07 Mar 2000 20:31:05 -0800 >> We now have 5 documents in Last call, without any comments. >> Here is a list of the documents in last call and the deadline >> for comments on each one. >> Remember it is Randy and my job to judge the consensus of the group but >> to do so we need some feedback on each one of these documents. > >I think the WG has successfully worn out just about everyone who cares, >by constant rewriting of standards that we haven't ever field-tested. >I certainly can't dedicate the time to keep up with all these paper >standards. > >Please allow me to recommend that all of them be discarded or delayed >indefinitely, until we have some operational experience with the draft >standards that preceded them. > >Now you have one comment for your last call. > > 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 Wed Mar 8 10:41:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23628 for ; Wed, 8 Mar 2000 10:41:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12ShjD-0001CK-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 06:46:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12ShjC-0001CE-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 06:46:22 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12ShjC-00037x-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 06:46:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200003080431.UAA20066@toad.com> References: <4.1.20000306100528.009f0340@mail.gw.tislabs.com> Date: Wed, 8 Mar 2000 08:29:53 -0500 To: John Gilmore From: Edward Lewis Subject: Re: Last call reminder: Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org, gnu@toad.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:31 PM -0500 3/7/00, John Gilmore wrote: >I think the WG has successfully worn out just about everyone who cares, >by constant rewriting of standards that we haven't ever field-tested. >I certainly can't dedicate the time to keep up with all these paper >standards. I half agree and half disagree with your message... The last calls are not that effective. Most of these documents have been getting little review and little discussion on the list. I think the deadlines are too tight given that the start of the last call comes out of the blue. On the other hand, these are not just 'paper standards.' Most, if not all[1], are being implemented in BIND 9. (I am unsure about what Microsoft has implemented regarding GSSAPI TKEY.) What is happening is the pre-documentation of the protocols as they are being implemented. Not just in in the DNS[A-Z0-9]* WG, but throughout the IETF there is a effort to put the paper before the code. (IMHO, this is the ISO-ization process.) The WG problem isn't the lack of implementation, but the lack of competing implementations that foster in-depth discussions leading to improved words on paper. You are right that we do need operational experience. I have been doing all I can to make this come about, but I don't have resources. Who does? I'd like to know. [1] I know TSIG is, I think SIG(0) and TKEY is, what are the other two docs in last call? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 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 Mar 8 11:05:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02351 for ; Wed, 8 Mar 2000 11:05:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SiGl-0002Fm-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 07:21:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12SiGl-0002Fg-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 07:21:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12SiGl-0003NW-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 07:21:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003081515.KAA01098@torque.pothole.com> To: namedroppers@ops.ietf.org cc: ogud@tislabs.com, bwelling@tislabs.com Subject: re: draft-ietf-dnsext-simple-secure-update-00.txt Date: Wed, 08 Mar 2000 10:15:05 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit draft-ietf-dnsext-simple-secure-update-00.txt On section 3 on Policy, I think there is a bit of an over reaction here. True, RFC 2137 was way to complex and hard to implement. But just saying that ALL update policy is outside of the standard doesn't strike me as the best design either. You say it avoids non-interoperability problems but that is only by ruling it all outside the area of the standard so that possibly you will always have non-interoperability and a burden on anyone who has an updatable zone and wants to move their primary. Assume that 99% of all KEY based updates could be handled by name scoped authority to update user RRs only. In particular I think that would be adequate to handle the DHCP cases. Consider the following straw man proposal: three of the formerly designated "signatory" bits are zero/ignored but the fourth has the following meaning: if zero, the KEY can not be used to authorize updates; if one, the default meaning is that the KEY can authorize DNS name scoped update of user RRs only, however, this authority can be arbitrarily expanded or reduced by policy setting at the primary server. If my assumption was correct, you would then handle 99% of the update authorization requirements in this one bit in the KEY RR and such zones could be freely moved between primary servers that supported the secure dynamic update standard. Only in the rare cases where a KEY needs to be authorized to add/change NS's or be restricted to only doing updates on alternate shrove tuesdays or it's really important to limit its authority to TXT RRs or something would the primary server arbitrary policy configuration mechanism be needed. I'd also like to suggest a minor rewording of section 1.3 as follows: 1.3 - Comparison of data authentication and message authentication Message based authentication, using TSIG or SIG(0), provides protection for the entire message with a single signing and single verification which, in the case of TSIG, is a relatively inexpensive MAC creation and check. For update requests, this signature can establish, based on policy or key negotation, the authority to make the request. DNSSEC SIG records can be used to protect the integrity of individual RRs or RRsets in a DNS message with the authority of the zone owner. However, this cannot sufficiently protect the dynamic update request. Using SIG records to secure RRsets in an update request is incompatible with the design of update, as described below, and would in any case require multiple expensive public key signatures and verifcations. SIG records do not cover the message header, which includes record counts. Therefore, it is possibly to maliciously insert or remove RRsets in an update request without causing a verification failure. If SIG records were used to protect the prerequisite section, it would be impossible to determine whether the SIGs themselves were a prerequisite or simply used for validation. In the update section of an update request, signing requests to add an RRset is straightforward, and this signature could be permanently used to protect the data, as specified in [RFC2535]. However, if an RRset is deleted, there is no data for a SIG to cover. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) Carmel, NY 10512 USA +1 508-261-5434(w) 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 Mar 8 11:13:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05012 for ; Wed, 8 Mar 2000 11:13:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SiLJ-0002RT-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 07:25:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12SiLJ-0002RN-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 07:25:45 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12SiLJ-0003PW-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 07:25:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Mar 2000 10:23:09 -0500 (EST) From: Brian Wellington To: "Donald E. Eastlake 3rd" cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: SIG(0) In-Reply-To: <200003080349.WAA11445@torque.pothole.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 7 Mar 2000, Donald E. Eastlake 3rd wrote: > Actually, although multiple different authorization was the only > reason I mentioned when we last talked about this, there is another. OK. My primary concern is that situations involving multiple authorizations don't arise. Restricting it in SIG(0) seesed like the logical choice, but maybe not. > With TSIG, you have (or at least believe you have) a shared (secret) > key and algorithm. With SIG(0), you typically don't have or need that > since the public key to verify the signature can be obtained from the > DNS. However, that also means you don't know what algorithm(s) the > server understands. I'm not sure about this. The server is expected to understand the mandatory to implement algorithms, I think a better solution is to allow the server to notify the client that a SIG(0) could not be verified, and then the client would never try it again. The client can also query the server and determine what keys it uses for SIG(0) (or at least an approximation - all dnssec protocol host keys at the server's name), and determine what algorithms it understands from that. > So you might want to have, for example, two > signatures giving exactly the same authorization but with diffeent > algorithms and the understanding would be that if any SIG(0) for that > specific authorization verified, you have the authority indicated > (assuming it conforms to server policy, etc.). But if the client sends 2 SIG(0)'s with one message, and the server verifies one of them, the client doesn't know which one was verified. So, any further SIG(0) signed messages will also need to be signed with both. I'd recommend something the following: - client sends RSA SIG(0) signed TKEY mesage - server doesn't do RSA, sends back NOTAUTH - client sends DSA SIG(0) signed TKEY mesage - server sends back signed TKEY response, all is good. Of course, the client should probably send DSA first, since it's mandatory, but that wouldn't illustrate the point. > I suppose it could > also be possible that during some key rollover situation with some > clock jitter, you might want two signatures with the same authority > and algorithm but different keys, although usually you would arrange > for the key validities to overlap enough that it wouldn't be a > problem. This could be a problem, but I think that it should be up to the user to properly configure keys. 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 Wed Mar 8 11:40:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15193 for ; Wed, 8 Mar 2000 11:40:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Sium-0003n6-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 08:02:24 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Sium-0003n0-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 08:02:24 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Sium-0003fp-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 08:02:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: From: Philip Hallam-Baker To: namedroppers@ops.ietf.org Subject: RE: Last call reminder: Date: Wed, 8 Mar 2000 07:56:55 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My experience of the URN working group is that no RFCs is usually better than bad RFCs. Anyone trying to do any work on URNs will find the detritus from the failed URN working group in the way. Every bad design decision of the group is now fixed by authority of an RFC. I believe that we have to deploy a security infrastructure for the internet name system system in a very short timescale. I am somewhat disturbed by the fact that there are RFCs at proposed standard that do not appear to have been reviewed by the commercial providers of name infrastructure or PKI infrastructure. Furthermore there does not appear to be any commitment to deploy the specifications from the principal operating systems vendors - with the exception of SRV. Before deployment the easiest thing to change is the specifications. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Mar 8 11:52:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19238 for ; Wed, 8 Mar 2000 11:52:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Sj19-00046k-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 08:08:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Sj19-00046e-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 08:08:59 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Sj19-0003iq-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 08:08:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003081605.LAA12805@torque.pothole.com> To: Edward Lewis cc: Brian Wellington , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: SIG(0) In-reply-to: Your message of "Wed, 08 Mar 2000 09:01:13 EST." Date: Wed, 08 Mar 2000 11:05:49 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't see how permitting multiple signatures for the same authority but different algorithms, such that the request is considered valid if any of them verify, reduces security, since you can just send N requests, each with one of the multiple signatures. However, since you can do that, it is also not particularly important to allow multiple signatures for this reason. 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 Wed Mar 8 12:13:36 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26466 for ; Wed, 8 Mar 2000 12:13:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SjFl-0004gD-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 08:24:05 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12SjFl-0004g7-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 08:24:05 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12SjFl-0003rN-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 08:24:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003081629.RAA25493@114046.kema.nl> To: Edward Lewis cc: John Gilmore , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: Last call reminder: In-reply-to: Your message of Wed, 08 Mar 2000 08:29:53 -0500. Date: Wed, 08 Mar 2000 17:29:47 +0100 From: Jaap Akkerhuis Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You are right that we do need operational experience. I have been doing all I can to make this come about, but I don't have resources. Who does? I'd like to know. We, the domein-registry in .nl, de-nic (.de) have some resources allocated for doing some large scale dns-sec implementation testing (based on bind9), together with nlnetlabs.nl and other parties. We are actively setting op an workgroup etc. As soon as the details are sorted out, we can give some more details. jaap [1] I know TSIG is, I think SIG(0) and TKEY is, what are the other two docs in last call? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda "It takes years of training to know when to do nothing" - Dogbert 1/21/00 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 Wed Mar 8 12:26:25 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01135 for ; Wed, 8 Mar 2000 12:26:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Sjk3-0005rn-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 08:55:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Sjk2-0005rh-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 08:55:22 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Sjk2-000462-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 08:55:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Michael Mealling To: Philip Hallam-Baker Cc: namedroppers@ops.ietf.org Subject: Re: Last call reminder: Message-ID: <20000308113630.G24105@bailey.dscga.com> Reply-To: michaelm@netsol.com References: In-Reply-To: ; from pbaker@verisign.com on Wed, Mar 08, 2000 at 07:56:55AM -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 08 Mar 2000 08:55:23 -0800 Content-Transfer-Encoding: 7bit On Wed, Mar 08, 2000 at 07:56:55AM -0800, Philip Hallam-Baker wrote: > My experience of the URN working group is that no RFCs is usually better > than bad RFCs. Anyone trying to do any work on URNs will find the > detritus from the failed URN working group in the way. Every bad > design decision of the group is now fixed by authority of an RFC. Huh? Failed? The group is just about finished and implementations are under way. One of the two larger uses can be found in the upcoming XML URN and the work being done in ENUM. -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 Mar 8 13:46:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25826 for ; Wed, 8 Mar 2000 13:46:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SknA-0008SN-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 10:02:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12SknA-0008SH-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 10:02:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Skn9-0004YO-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 10:02:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C68E71.C94A1A90@whistle.com> Date: Wed, 08 Mar 2000 09:31:29 -0800 From: Terry Lambert To: Brian Wellington CC: "Donald E. Eastlake 3rd" , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WG Last Call: SIG(0) References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian Wellington wrote: > On Tue, 7 Mar 2000, Donald E. Eastlake 3rd wrote: > > > Actually, although multiple different authorization was the only > > reason I mentioned when we last talked about this, there is another. > > OK. My primary concern is that situations involving multiple > authorizations don't arise. Restricting it in SIG(0) seesed like the > logical choice, but maybe not. I think the key jitter argument is specious; I personally use SecurID, from Security Dynamics, to get behind an IBM firewall. This works by generating pseudo-random numbers, and providing a window for "jitter" to deal with the clock synchronization issue for the pseudo-random number (e.g., the number is valid for ~3x the window, and the back end is synchronized ("recentered") on the middle of the window for a valid number. This argument is specious for automatic systems, since there are no automatic systems that implement this (the SecurID system is to permit people with keychain fobs and an account and PIN to login from outside, not one machine with magic client hardware to talk to another with magic server hardware; I also think that permitting the implementation of a "standards conforming" system that is nevertheless non-interoperable with other instances of "standards conforming" systems is an extreme error, and points up an obvious flaw in the standards document, if it is even theoretically possible to create such an implementation). It seems to me that the "jitter" argument is an attempt to dodge the key distribution problem, which I believe has already been adequately resolved elsewhere (e.g. "Racoon" for IPv6), and we can look elsewhere for a model. For the non-"jitter" argument of multiple algorithms, I think that if a client has an unsupported algorithm, then it should attempt it, and if the server does not accept it, then the client MUST fall back to a supported (e.g. a "mandatory to implement") algorithm. I use the word "MUST" intentionally, in its RFC sense. Right now, we are beset with attempts to control the client, the server, or both sides of the implementation of supposedly standard security protocols, sometimes in the face of white papers by the authors of the standards specifically stating the intended use of "optional" fields, such as we are talking about in this specific case. What is to stop a vendor from implementing a signature security algorithm that is proprietary and/or patented, and then setting up their servers to require the use of their signatures, thus leveraging a near monopoly in clients to force the use of their servers? Or vice-versa, what is to stop someone from implementing a server which understands such an algorithm, and treats clients which only implement the "mandatory to implement" algorithms as second class citizens in "their" network? It is not strong enough to permit optional algorithms, we MUST ensure that the "mandatory to implement" ones are universal, and that implementations which _only_ support these CAN NOT be treated as second class network citizens as a result of a vendor whim. The RFC SHOULD NOT be issued until interoperability guarantees have been addressed in the protocol definition. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. 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 Mar 8 15:48:35 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00761 for ; Wed, 8 Mar 2000 15:48:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SmUj-000Cuu-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 11:51:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12SmUj-000Cuo-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 11:51:45 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12SmUi-0005Bo-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 11:51:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C6A1B7.57132C31@cisco.com> Date: Wed, 08 Mar 2000 10:53:43 -0800 From: Peter Deutsch To: michaelm@netsol.com CC: Philip Hallam-Baker , namedroppers@ops.ietf.org Subject: Re: Last call reminder: References: <20000308113630.G24105@bailey.dscga.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ enough. can we take this one elsewhere please? -- rb ] Guys, Michael Mealling wrote: > > On Wed, Mar 08, 2000 at 07:56:55AM -0800, Philip Hallam-Baker wrote: > > My experience of the URN working group is that no RFCs is usually better > > than bad RFCs. Anyone trying to do any work on URNs will find the > > detritus from the failed URN working group in the way. Every bad > > design decision of the group is now fixed by authority of an RFC. > > Huh? Failed? The group is just about finished and implementations > are under way. One of the two larger uses can be found in > the upcoming XML URN and the work being done in ENUM. And so it came to pass that the Pope in Avignon sent out his forces to do battle with the forces of the Pope in Rome. And there was misery and woe upon the land... In other words, some people don't believe in URNs as defined by that working group. So don't use them. We used to welcome diversity. Yeesh... - peterd 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 Mar 8 19:28:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29708 for ; Wed, 8 Mar 2000 19:28:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Sq9j-000IIe-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 15:46:19 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Sq9j-000IIY-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 15:46:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Sq9i-0006bZ-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 15:46:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003082338.PAA09523@toad.com> To: Philip Hallam-Baker cc: namedroppers@ops.ietf.org, gnu@toad.com Subject: Re: Last call reminder: (DNSSEC) In-reply-to: Date: Wed, 08 Mar 2000 15:38:39 -0800 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I believe that we have to deploy a security infrastructure for the > internet name system system in a very short timescale. Why do you believe this, particularly the timescale? > I am somewhat > disturbed by the fact that there are RFCs at proposed standard that > do not appear to have been reviewed by the commercial providers of > name infrastructure or PKI infrastructure. ISC and NSI and CORE and IANA all reviewed it. I think ICANN has had its hands full with politics, legalism and bureacracy, and is only starting to be able to deal with technology issues. As for PKI infrastructure, DNSSEC *competes* with PKI infrastructure. Isn't that why Verisign bought NSI? PKI has been heavily based on deliberate anti-privacy information collection ("voluntary" disclosure to Dun&Bradstreet, which then sells your info, is required to get a cert for secure web serving), cumbersome ISO encoding, and centralized providers protected by patent monopolies who are maneuvering to collect tolls from everyone on the Internet. We should expect companies invested in X.509 and PKI certificate models -- such as your own, Philip -- to want to kill or cripple DNSSEC. It is only to the extent that they didn't notice DNSSEC, or didn't believe that it was viable, that it has survived. Though perhaps with NSI firmly in hand, Verisign can arrange to collect tolls from DNSSEC users too, so now wants to see it deployed. > Furthermore there does not appear to be any commitment to deploy the > specifications from the principal operating systems vendors. A collection of Unix companies is funding BIND v9 development and support, with the intent of incorporating it into their products. As for Microsoft, they have been tracking the standards, but who would believe them if they said they'd implement it as written? When it serves their interest to do something else, they do something else. 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 Wed Mar 8 21:38:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13519 for ; Wed, 8 Mar 2000 21:38:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Ss8L-000KuK-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 17:53:01 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Ss8K-000KuE-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 17:53:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Ss8K-0007Ob-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 17:53:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Mar 2000 20:50:16 -0500 From: Mark Kosters To: John Gilmore Cc: Philip Hallam-Baker , namedroppers@ops.ietf.org Subject: Re: Last call reminder: (DNSSEC) Message-ID: <20000308205016.C7110@slam.internic.net> References: <200003082338.PAA09523@toad.com> In-Reply-To: <200003082338.PAA09523@toad.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, Mar 08, 2000 at 03:38:39PM -0800, John Gilmore wrote: > ISC and NSI and CORE and IANA all reviewed it. I think ICANN has had > its hands full with politics, legalism and bureacracy, and is only > starting to be able to deal with technology issues. You are more confident than I that ICANN is past the non-technical issues and has extra cycles to think about signing the root. Nevertheless, there are a couple of things that need to happen to make this a reality from my prospective (and this list may not be complete): 1) EDNS0 needs to be deployed for dnssec to happen at the roots. Running TCP retries due to udp packet overflows will be bad if we were to deploy this now. 2) Software needs to work. The dnssec workshops that I've participated in have had less than stellar results over the past year. 3) More thought has to go into key rollovers for delegations. The idea of the millions of .coms having to deal resigning their keys with the parent is suboptimal at this point.* That reminds me - what happened to the draft that Donald and Mark wrote almost a year ago? Regards, Mark *I've written a keyserver to authenticate the child using the registrar/registry model. This is cool but am unsure if every admin really wants to do this on a frequent basis outside of DNS. -- Mark Kosters markk@netsol.com Network Solutions, Inc. PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 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 Mar 9 00:52:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09669 for ; Thu, 9 Mar 2000 00:52:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SvMd-000Opk-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 21:19:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12SvMc-000Ope-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 21:19:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12SvMc-0008q9-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 21:19:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003090328.OAA09823@bsdi.dv.isc.org> To: Mark Kosters Cc: John Gilmore , Philip Hallam-Baker , namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: Last call reminder: (DNSSEC) In-reply-to: Your message of "Wed, 08 Mar 2000 20:50:16 CDT." <20000308205016.C7110@slam.internic.net> Date: Thu, 09 Mar 2000 14:28:23 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 3) More thought has to go into key rollovers for delegations. The idea > of the millions of .coms having to deal resigning their keys with > the parent is suboptimal at this point.* That reminds me - what > happened to the draft that Donald and Mark wrote almost a year ago? > We are still working on it. We want to use SRV records to be able to seperate the server from the signer if wanted. Mark > Regards, > Mark > > *I've written a keyserver to authenticate the child using the > registrar/registry model. This is cool but am unsure if every admin really > wants to do this on a frequent basis outside of DNS. -- Mark Andrews, Nominum Inc. / Internet Software Consortium 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 Thu Mar 9 00:53:19 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10030 for ; Thu, 9 Mar 2000 00:53:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SvP7-000OuD-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 21:22:33 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12SvP6-000Ou7-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 21:22:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12SvP6-0008rs-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 21:22:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 08 Mar 2000 21:33:38 -0500 To: dnsop@cafax.se, namedroppers@ops.ietf.org From: Marc Blanchet Subject: Fwd: [idn] next ietf idn agenda proposal Cc: jseng@pobox.org.sg Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 8bit FYI. IDN wg meeting will be monday, March 27, 2000 13h00-15h00 You are more than welcome to participate. Marc. (idn wg co-chair) >Date: Wed, 08 Mar 2000 09:16:01 -0500 >To: idn@ops.ietf.org >From: Marc Blanchet >Subject: [idn] next ietf idn agenda proposal > > >Hi, > based on requests, here is a first agenda proposal for the next > ietf idn wg meeting. Hope I didn't forget someone. > if you want to make a presentation, please send request to me and > james (Marc.Blanchet@viagenie.qc.ca and jseng@pobox.org.sg). > Recall that our focus for now is on requirements. So priority #1 > on presentations is for the requirements. If we have time, we will begin > discussing the implementations document. > I'll wait for a few days for comments on the agenda and then send > it to the IETF secretariat. > >Marc. >===================== >IETF 47th, Adelaide, March 2000 > >Internationalized domain names (idn) >working group meeting agenda > >- Agenda bashing, blue sheet, setup, 5 minutes > >- Requirements document, James Seng, 50 minutes > http://www.normos.org/ietf/draft/draft-ietf-idn-requirment-00.txt > >- Requirements from Japan, Yoshiro YONEYA, 15 minutes > >- Internationalization of URLs: history, Larry Masinter, 15 minutes > http://www.normos.org/ietf/draft/draft-masinter-url-i18n-04.txt > >- Report on APTLD meetings, TBA, 5 minutes > >- Implementations document structure and plan, TBA, 30 minutes Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. 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 Mar 9 00:58:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11320 for ; Thu, 9 Mar 2000 00:58:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12SvGy-000Oj8-00 for namedroppers-data@psg.com; Wed, 08 Mar 2000 21:14:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12SvGx-000Oiz-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 21:14:07 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12SvGx-0008mS-00 for namedroppers@ops.ietf.org; Wed, 08 Mar 2000 21:14:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200003090226.SAA19759@zephyr.isi.edu> Subject: Re: Last call reminder: (DNSSEC) To: markk@netsol.com (Mark Kosters) Date: Wed, 8 Mar 2000 18:26:18 -0800 (PST) Cc: gnu@toad.com (John Gilmore), pbaker@verisign.com (Philip Hallam-Baker), namedroppers@ops.ietf.org In-Reply-To: <20000308205016.C7110@slam.internic.net> from "Mark Kosters" at Mar 08, 2000 08:50:16 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % On Wed, Mar 08, 2000 at 03:38:39PM -0800, John Gilmore wrote: % > ISC and NSI and CORE and IANA all reviewed it. I think ICANN has had % > its hands full with politics, legalism and bureacracy, and is only % > starting to be able to deal with technology issues. % % You are more confident than I that ICANN is past the non-technical issues % and has extra cycles to think about signing the root. Nevertheless, there % are a couple of things that need to happen to make this a reality from % my prospective (and this list may not be complete): Echo Marks concerns. I believe that ICANN has a couple of technical steps ahead of itself before it could begin to be prepared to think of how to deploy DNSSEC. % 1) EDNS0 needs to be deployed for dnssec to happen at the roots. Running % TCP retries due to udp packet overflows will be bad if we were to deploy % this now. The problem would not be a root issue once the g & cc TLDs are migrated off the roots to their own servers. It would still be an issue. % 2) Software needs to work. The dnssec workshops that I've participated % in have had less than stellar results over the past year. Well, it does work, but with significant manual intervention. I am concerned that there is a lack of compatability between versions. Still too fluid for a production system for my tastes. % 3) More thought has to go into key rollovers for delegations. The idea % of the millions of .coms having to deal resigning their keys with % the parent is suboptimal at this point.* That reminds me - what % happened to the draft that Donald and Mark wrote almost a year ago? % % Regards, % Mark % % *I've written a keyserver to authenticate the child using the % registrar/registry model. This is cool but am unsure if every admin really % wants to do this on a frequent basis outside of DNS. Nifty! % % -- % % Mark Kosters markk@netsol.com Network Solutions, Inc. % PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 % % % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. % -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Mar 9 14:19:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22775 for ; Thu, 9 Mar 2000 14:19:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12T7bR-000BO6-00 for namedroppers-data@psg.com; Thu, 09 Mar 2000 10:24:05 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12T7bQ-000BO0-00 for namedroppers@ops.ietf.org; Thu, 09 Mar 2000 10:24:04 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12T7bP-000EXS-00 for namedroppers@ops.ietf.org; Thu, 09 Mar 2000 10:24:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C7EA49.96B9B597@ehsco.com> Date: Thu, 09 Mar 2000 10:15:37 -0800 From: "Eric A. Hall" To: namedroppers@ops.ietf.org Subject: opcode 2: server status request Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RFC 1035 doesn't provide any purpose or usage notes on opcode 2: server status request. Various searches have also proven futile. Anybody got any background info on this they can share? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.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 Mar 9 15:49:02 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17879 for ; Thu, 9 Mar 2000 15:48:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12T9BW-000D2t-00 for namedroppers-data@psg.com; Thu, 09 Mar 2000 12:05:26 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12T9BV-000D2m-00 for namedroppers@ops.ietf.org; Thu, 09 Mar 2000 12:05:25 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12T9BV-000FKc-00 for namedroppers@ops.ietf.org; Thu, 09 Mar 2000 12:05:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000309132321.00a2e3f0@localhost> Date: Thu, 09 Mar 2000 15:08:25 -0500 To: "Donald E. Eastlake 3rd" , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: re: draft-ietf-dnsext-simple-secure-update-00.txt In-Reply-To: <200003081515.KAA01098@torque.pothole.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:15 AM 3/8/00 , Donald E. Eastlake 3rd wrote: >draft-ietf-dnsext-simple-secure-update-00.txt > >On section 3 on Policy, I think there is a bit of an over reaction >here. True, RFC 2137 was way to complex and hard to implement. But >just saying that ALL update policy is outside of the standard doesn't >strike me as the best design either. You say it avoids >non-interoperability problems but that is only by ruling it all >outside the area of the standard so that possibly you will always have >non-interoperability and a burden on anyone who has an updatable zone >and wants to move their primary. The main problem with RFC 2137 it is not trivial for resolver to determine if the key is allowed to update the data it signed. The language might be toned down a little bit. > >Assume that 99% of all KEY based updates could be handled by name >scoped authority to update user RRs only. In particular I think that >would be adequate to handle the DHCP cases. Consider the following >straw man proposal: three of the formerly designated "signatory" bits >are zero/ignored but the fourth has the following meaning: if zero, >the KEY can not be used to authorize updates; if one, the default >meaning is that the KEY can authorize DNS name scoped update of user >RRs only, however, this authority can be arbitrarily expanded or >reduced by policy setting at the primary server. If my assumption was >correct, you would then handle 99% of the update authorization >requirements in this one bit in the KEY RR and such zones could be >freely moved between primary servers that supported the secure dynamic >update standard. Only in the rare cases where a KEY needs to be >authorized to add/change NS's or be restricted to only doing updates >on alternate shrove tuesdays or it's really important to limit its >authority to TXT RRs or something would the primary server arbitrary >policy configuration mechanism be needed. I think it is premature to anticipate what policies sites will use, and making any assumptions about X% of updates is counterproductive. Policy at a site can be much more fine grained than just name; hosts could be allowed to only update address records but not text records etc. I think that keeping the policy outside the specification until this area is better understood is the right thing to do NOW. (KISS principle). 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 Mar 11 17:28:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00508 for ; Sat, 11 Mar 2000 17:28:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12TtSi-000PCy-00 for namedroppers-data@psg.com; Sat, 11 Mar 2000 13:30:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12TtSi-000PCs-00 for namedroppers@ops.ietf.org; Sat, 11 Mar 2000 13:30:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12TtSh-0009ir-00 for namedroppers@ops.ietf.org; Sat, 11 Mar 2000 13:30:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CABAAA.2E0E772A@ehsco.com> Date: Sat, 11 Mar 2000 13:29:14 -0800 From: "Eric A. Hall" To: namedroppers@ops.ietf.org Subject: Re: opcode 2: server status request References: <38C7EA49.96B9B597@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a thought, but if this opcode is neither used nor understood, then perhaps it should be made obsolete. "Eric A. Hall" wrote: > > RFC 1035 doesn't provide any purpose or usage notes on opcode 2: server > status request. Various searches have also proven futile. Anybody got > any background info on this they can share? -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.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 Mon Mar 13 14:13:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18074 for ; Mon, 13 Mar 2000 14:13:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12UZ8K-0000So-00 for namedroppers-data@psg.com; Mon, 13 Mar 2000 10:00:00 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12UZ8K-0000Si-00 for namedroppers@ops.ietf.org; Mon, 13 Mar 2000 10:00:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12UZ8J-000LEh-00 for namedroppers@ops.ietf.org; Mon, 13 Mar 2000 09:59:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 13 Mar 2000 12:55:06 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG Last Call Summary: Signing Authority-00 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit The last call period on this document has concluded. No substantial comments where received during the last call. Minor edit's where suggested in private emails to author and WG-chair. Author will update document for clarity. It is the sense of the WG that the document is ready for advancement and will be forwarded to IESG after update. There will be an oppertunity to address the WG last call of this document in Working Group meeting. Olafur > > This document was spun off from the Simple Secure Update document after > WGLC. > This document specifies that for DNSSEC purposes only zone key signatures > are material. This restriction simplifies signature validation, and > allows flexible dynamic update policies. The changes result from > implementation > experience. > This is a WG last call ending March 8'th 2000. > The draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-00.txt > There are no known defects in this version of the document. > Please send comments to the list. > This document is to be published as an standards track RFC, updating RFC2565. > 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 Mon Mar 13 14:16:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19505 for ; Mon, 13 Mar 2000 14:16:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12UZ8T-0000T0-00 for namedroppers-data@psg.com; Mon, 13 Mar 2000 10:00:09 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12UZ8T-0000Su-00 for namedroppers@ops.ietf.org; Mon, 13 Mar 2000 10:00:09 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12UZ8S-000LEl-00 for namedroppers@ops.ietf.org; Mon, 13 Mar 2000 10:00:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 13 Mar 2000 12:55:13 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG Last Call Summary: Simple Secure Update-00 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit The last call period on this document has concluded. No substantial comments where received Minor comments where for improved wording of certain sections and clarification. Some discussion on the merits of update policies expressed in KEY records versus configured in servers was conducted. The consensus is that author should address the minor edits requested and post a new version of the document which is ready to forwarded to the IESG. There will be an opportunity to address the WG last call of this document in Working Group meeting. Olafur > > This is a second last call on this document, in the first round some > changes where suggested mainly spilt the document in two as the original > document was updating RFC2535 and obsoleting RFC2137 this document > reflects all comments received. > This document specifies how to update zones securely using only message > authentication. This document does not specify update policy, but extends > dynamic update RFC2136 to DNSSEC types and their restrictions. > This is a WG last call ending March 8'th 2000. > The draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update-0 > 0.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Mar 14 12:06:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06302 for ; Tue, 14 Mar 2000 12:06:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12UtlD-0007oU-00 for namedroppers-data@psg.com; Tue, 14 Mar 2000 08:01:31 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12UtlD-0007oO-00 for namedroppers@ops.ietf.org; Tue, 14 Mar 2000 08:01:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12UtlC-0003kw-00 for namedroppers@ops.ietf.org; Tue, 14 Mar 2000 08:01:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003141430.JAA14566@noah.dma.isg.mot.com> To: skwan@microsoft.com From: Donald Eastlake 3rd cc: dee3@torque.pothole.com, lde008@dma.isg.mot.com, namedroppers@ops.ietf.org, jamesg@microsoft.com, praeritg@microsoft.com Subject: draft-skwan-gss-tsig-05.txt Date: Tue, 14 Mar 2000 09:30:36 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Stuart, Reviewing the latest version of your draft, I note that you seem to use spontaneous server inclusion of TKEY RR only for key deletion, not for coveying GSS-API info. So there would never be a GSS-API mode TKEY RR spontaneously included by a server. Would you mind if I removed that possibility from the TKEY draft to simplify it? Thanks, Donald PS: The TSIG and TEKY info in your References section is a bit out of date... ================================================================== Donald Eastlake 3rd +1 914-276-2668(h) dee3@torque.pothole.com 65 Shindegan Hill Rd. +1 508-261-5434(w) lde008@dma.isg.mot.com Carmel, NY 10512 USA 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 Mar 17 11:30:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07700 for ; Fri, 17 Mar 2000 11:30:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Vy5b-000FXt-00 for namedroppers-data@psg.com; Fri, 17 Mar 2000 06:50:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Vy5a-000FXn-00 for namedroppers@ops.ietf.org; Fri, 17 Mar 2000 06:50:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Vy5a-000979-00 for namedroppers@ops.ietf.org; Fri, 17 Mar 2000 06:50:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19398D273324D3118A2B0008C7E9A56905F55154@SIT.platinum.corp.microsoft.com> From: Stuart Kwan To: "'Donald Eastlake 3rd'" Cc: lde008@dma.isg.mot.com, namedroppers@ops.ietf.org, James Gilroy , Praerit Garg Subject: RE: draft-skwan-gss-tsig-05.txt Date: Thu, 16 Mar 2000 22:57:50 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Donald, I don't mind if you remove that section (5.2) from the TKEY draft. I'll fix up the references before I resubmit the draft as a DNSEXT I-D. Cheers, - Stuart -----Original Message----- From: Donald Eastlake 3rd [mailto:dee3@torque.pothole.com] Sent: Tuesday, March 14, 2000 6:31 AM To: Stuart Kwan Cc: dee3@torque.pothole.com; lde008@dma.isg.mot.com; namedroppers@ops.ietf.org; James Gilroy; Praerit Garg Subject: draft-skwan-gss-tsig-05.txt Hi Stuart, Reviewing the latest version of your draft, I note that you seem to use spontaneous server inclusion of TKEY RR only for key deletion, not for coveying GSS-API info. So there would never be a GSS-API mode TKEY RR spontaneously included by a server. Would you mind if I removed that possibility from the TKEY draft to simplify it? Thanks, Donald PS: The TSIG and TEKY info in your References section is a bit out of date... ================================================================== Donald Eastlake 3rd +1 914-276-2668(h) dee3@torque.pothole.com 65 Shindegan Hill Rd. +1 508-261-5434(w) lde008@dma.isg.mot.com Carmel, NY 10512 USA 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 Fri Mar 17 20:12:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02543 for ; Fri, 17 Mar 2000 20:12:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12W72I-0002Sa-00 for namedroppers-data@psg.com; Fri, 17 Mar 2000 16:24:10 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12W72I-0002SU-00 for namedroppers@ops.ietf.org; Fri, 17 Mar 2000 16:24:10 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12W72H-000BtE-00 for namedroppers@ops.ietf.org; Fri, 17 Mar 2000 16:24:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000317160535.06aec8b0@localhost> Date: Fri, 17 Mar 2000 16:18:40 -0500 To: namedroppers@ops.ietf.org, agenda@ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG agenda at 45'th IETF Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here is the draft DNSEXT agenda bashing 5 minutes (Randy) charter review 10 minutes (Olafur) working group last call summary 10 minutes (Olafur) TSIG draft-ietf-dnsext-tsig-00.txt zone signing key draft-ietf-dnsext-signing-auth-00.txt secure update draft-ietf-dnsext-simple-secure-update-00.txt TKEY draft-ietf-dnsext-tkey-01.txt SIG(0) draft-ietf-dnsext-sig-zero-00.txt IANA draft-ietf-dnsext-iana-dns-00.txt RFC status 10 minutes (Olafur) RFC 2782 current drafts 40 minutes (Authors or chair) axfr 5 draft-ietf-dnsext-axfr-clarify-00.txt IXFR 5 draft-ietf-dnsext-ixfr-00.txt eds0.5 10 draft-ietf-dnsext-edns0dot5-00.txt Zone secure status 5 draft-ietf-dnsext-zone-status-00.txt DHCID 5 draft-ietf-dnsind-dhcp-rr-00.txt related drafts 40 (Author or chair) TSIG-GSSAPI 5 draft-skwan-gss-tsig-05.txt Multicast DNS 20 draft-aboba-dnsext-mdns-00.txt related WG's 10 (WG chairs) DNSOPS IDNS other agenda items 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 Mar 17 21:56:06 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11892 for ; Fri, 17 Mar 2000 21:56:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12W8qd-0006fr-00 for namedroppers-data@psg.com; Fri, 17 Mar 2000 18:20:15 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12W8qc-0006fW-00 for namedroppers@ops.ietf.org; Fri, 17 Mar 2000 18:20:14 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12W8qc-000CSp-00 for namedroppers@ops.ietf.org; Fri, 17 Mar 2000 18:20:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19398D273324D3118A2B0008C7E9A56905F55176@SIT.platinum.corp.microsoft.com> From: Stuart Kwan To: "'Olafur Gudmundsson'" , namedroppers@ops.ietf.org Subject: RE: DNSEXT WG agenda at 45'th IETF Date: Fri, 17 Mar 2000 17:50:36 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, I will not be attending Adelaide. Olafur, can you please drive the discussion on GSS-TSIG? I intend to resubmit GSS-TSIG as a working group draft when the I-D window reopens. I am not planning any significant changes to the draft. Cheers, - Stuart 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 Mar 18 18:00:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15694 for ; Sat, 18 Mar 2000 18:00:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12WRUO-0007Oa-00 for namedroppers-data@psg.com; Sat, 18 Mar 2000 14:14:32 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12WRUO-0007OU-00 for namedroppers@ops.ietf.org; Sat, 18 Mar 2000 14:14:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12WRUN-000Hcs-00 for namedroppers@ops.ietf.org; Sat, 18 Mar 2000 14:14:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000318163748.00a3ebb0@sentry.gw.tislabs.com> Date: Sat, 18 Mar 2000 16:39:36 -0500 To: Stuart Kwan , "'Olafur Gudmundsson'" , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: RE: DNSEXT WG agenda at 45'th IETF In-Reply-To: <19398D273324D3118A2B0008C7E9A56905F55176@SIT.platinum.corp .microsoft.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 08:50 PM 3/17/00 , Stuart Kwan wrote: >Hello all, > >I will not be attending Adelaide. Olafur, can you please drive the >discussion on GSS-TSIG? No problem, I will bring up the issue that the draft is applying to become a working group draft, and I see no reason for that not to happen. >I intend to resubmit GSS-TSIG as a working group draft when the I-D window >reopens. I am not planning any significant changes to the draft. I will read the draft before the meeting and send you any suggestions I may have. 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 Mon Mar 20 11:29:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14647 for ; Mon, 20 Mar 2000 11:29:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12X40J-0009Ky-00 for namedroppers-data@psg.com; Mon, 20 Mar 2000 07:22:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12X40J-0009Ks-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 07:22:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12X40J-0005FL-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 07:22:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200003201422.JAA20357@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: namedroppers@internic.net From: The IESG Subject: Protocol Action: Secret Key Transaction Authentication for DNS (TSIG) to Proposed Standard Date: Mon, 20 Mar 2000 09:22:06 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'Secret Key Transaction Authentication for DNS' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document, orginally available as draft-ietf-dnsind-tsig-nn, specifies an extension to DNS that allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. Working Group Summary There was consensus is the WG to advance the document. Protocol Quality This document has been reviewed for the IESG by Erik Nordmark. 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 Mon Mar 20 14:47:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03266 for ; Mon, 20 Mar 2000 14:47:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12X7VX-000BpM-00 for namedroppers-data@psg.com; Mon, 20 Mar 2000 11:06:31 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12X7VW-000BpG-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 11:06:30 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12X7VW-0006Oz-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 11:06:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 20 Mar 2000 10:55:28 -0800 (PST) From: Erik Nordmark Subject: SRV records for SIP? To: namedroppers@ops.ietf.org Cc: nordmark@jurassic.Eng.Sun.COM, gnair@cs.columbia.edu, shulzrinne@cs.columbia.edu Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit draft-ietf-sip-dhcp-00.txt defines some new DHCP options. One of them carry the FQDN to use when asking for SRV records (which seems a little bit odd - I'd expect a fixed prefix like _sip._tcp. ??). The other DHCP option tries to capture all of the content of the reply to a query for an SRV record. The DHCP option doesn't contain anything like a DNS TTL for this info. Thus I'd appreciate if somebody could give this document a careful read from the DNS perspective. Erik 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 Mon Mar 20 16:09:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04378 for ; Mon, 20 Mar 2000 16:09:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12X8ZH-000Cgk-00 for namedroppers-data@psg.com; Mon, 20 Mar 2000 12:14:27 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12X8ZH-000Cge-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 12:14:27 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12X8ZG-0006lY-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 12:14:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D68306.6FB790C3@cs.columbia.edu> Date: Mon, 20 Mar 2000 14:59:02 -0500 From: Gautam Nair To: Erik Nordmark CC: namedroppers@ops.ietf.org, nordmark@jurassic.Eng.Sun.COM, hgs@cs.columbia.edu Subject: Re: SRV records for SIP? References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the first option we defined, we send a DNS string to the client. This DNS string could either be an SRV name such as sip.udp.cs.columbia.edu *or* it could be an A record string such as marta.cs.columbia.edu. It is obviously more desireable to use the SRV record. The local DHCP administrator can configure the DHCP server to send either the SRV or the A record string according to the DNS capabilities of the DNS server and the SIP client. The client should however first attempt to use the string in an SRV query if it is SRV cognizant. I do not think there is any harm in sending an A record string in an SRV query other than the fact that it will fail and a second attempt (making the A record query) will have to be made. The second option that we defined is an attempt to replicate the reply to an SRV query. This is done with some embedded systems, that do not implement DNS, in mind. Since all the IP addresses and priority/weightage information is available, a DNS query is not required. For the DNS TTL type of info: In this case, it is expected that the DHCP administrator would make sure that the IP addresses are up to date, so TTL is not too important here. Regards, Gautam. Erik Nordmark wrote: > draft-ietf-sip-dhcp-00.txt defines some new DHCP options. > One of them carry the FQDN to use when asking for SRV records > (which seems a little bit odd - I'd expect a fixed prefix like > _sip._tcp. ??). > > The other DHCP option tries to capture all of the content of > the reply to a query for an SRV record. > The DHCP option doesn't contain anything like a DNS TTL for this info. > Thus I'd appreciate if somebody could give this document a careful read > from the DNS perspective. > > Erik 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 Mon Mar 20 16:15:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06800 for ; Mon, 20 Mar 2000 16:15:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12X8zV-000Czx-00 for namedroppers-data@psg.com; Mon, 20 Mar 2000 12:41:33 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12X8zU-000Czq-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 12:41:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12X8zU-0006ud-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 12:41:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 20 Mar 2000 12:28:03 -0800 (PST) From: Erik Nordmark Subject: SRV records for SIP? To: namedroppers@ops.ietf.org Cc: nordmark@jurassic.Eng.Sun.COM, narten@raleigh.ibm.com, gnair@cs.columbia.edu, schulzrinne@cs.columbia.edu In-Reply-To: "Your message with ID" Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Resent with correct address.] draft-ietf-sip-dhcp-00.txt defines some new DHCP options. One of them carry the FQDN to use when asking for SRV records (which seems a little bit odd - I'd expect a fixed prefix like _sip._tcp. ??). The other DHCP option tries to capture all of the content of the reply to a query for an SRV record. The DHCP option doesn't contain anything like a DNS TTL for this info. Thus I'd appreciate if somebody could give this document a careful read from the DNS perspective. Erik 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 Mar 21 00:55:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21093 for ; Tue, 21 Mar 2000 00:55:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12XGqE-000J45-00 for namedroppers-data@psg.com; Mon, 20 Mar 2000 21:04:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12XGqE-000J3z-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 21:04:30 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12XGqD-0009Zg-00 for namedroppers@ops.ietf.org; Mon, 20 Mar 2000 21:04:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: gnair@cs.columbia.edu, schulzrinne@cs.columbia.edu Cc: Erik Nordmark , narten@raleigh.ibm.com, namedroppers@internic.net Subject: Re: SRV records for SIP? In-Reply-To: Your message of "Mon, 20 Mar 2000 12:28:03 -0800." Date: Tue, 21 Mar 2000 12:55:36 +1100 Message-Id: <2352.953603736@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 20 Mar 2000 12:28:03 -0800 (PST) From: Erik Nordmark Message-ID: | One of them carry the FQDN to use when asking for SRV records | (which seems a little bit odd - I'd expect a fixed prefix like | _sip._tcp. ??). I don't mind that .. if anything building the magic knowledge into less places is probably an advantage, the extra few octets that appear in the DHCP reply (even given that DHCP packets are, like the DNS, one of those places where space is at a premium) shouldn't matter. However, just like every new place where DNS names are embedded in binary protocols, I don't believe that using the ascii form of the DNS name benefits anyone - embed the thing using DNS binary form. If that's done, then it is certain that a max length of 255 octets is sufficient (so the one byte length code works) - in textual form that is no longer going to cover all the cases, some sequences need extra bytes to act as escapes. With the (possible) forthcoming use of more international domain names, this is likely to become much more important (as perhaps will names that come closer to needing the full 255 octets than those we typically see today). For the kind of application that is being suggested here, one which may not even have a DNS client, this is likely to be an even bigger win, as it allows DNS support to be added without the need to have a hostname parser - the string returned from the DHCP option could be copied literally into the question section of a DNS packet, making the DNS support that much cheaper to add. | The other DHCP option tries to capture all of the content of | the reply to a query for an SRV record. That part is totally brain dead. Anything that can cope with DHCP ought to be able to cope with DNS as well, the two are very similar in their requirements - both use UDP, so both need internal retransmit timers and backoffs, both use a binary packet format, ... | The DHCP option doesn't contain anything like a DNS TTL for this info. While that would be trivial to add, and absolutely must be added anywhere that addresses are being passed around. With DHCP the server could perhaps mitigate this to some extent by arranging for the lease on the client's IP address to be no longer than the minimum TTL of all the addresses in the reply - most other addresses in DHCP replies have no TTLs either - but this ought to be stated somewhere, and further, someone needs to work out how all of this functions with DHCPINFORM requests, where no leasing info is supplied. But just assuming that an address is valid when it is returned, and that that obviates the need for a TTL totally misses the point of the TTL, which is as a guarantee (promise) of how long into the future the address will remain valid. If no TTL were to be included, then the doc would need to say "for immediate consumption, another DHCP query must be performed if the address is to be reused more than a second later than when the first DHCP reply is received". However, I don't believe this is a good match to the DHCP protocol, or DHCP servers - where DNS servers expect to be asked the same questions over and over, DHCP servers typiclaly don't - the protocol generally expects the clients to go away for hours after a query has been answered. This manifests itself in many ways - not the least being the habbit of DHCP servers to log every query received, and every answer sent. However, perhaps even worse than that is that this option is so IPv4 centric. I know that DHCPv6 is a different protocol, but it seems to me that defining new options now, that can't simply be used in both, is a grave mistake - anything new ought be compatible with both the v4 and v6 versions of DHCP. Here, as for some obscure reason the address (uniquely I belive amongst all DHCP options) is being returned as a dotted quad (ie: in ascii instead of binary), supporting IPv6 would be fairly easy - just allow it's ascii form to be returned as well. However the doc explicitly states that the address is a dotted quad. That means IPv4 only. More trivially... wt: This field is used by the load balancing mechanism. When selecting a target host among those that have the same priority, the chance of trying this one first SHOULD be proportional to its weight. The range of this number is 1- 65535. Domain administrators are urged to use Weight 0 when there isn't any load balancing to do, to make the option easier to read for humans (less noisy). which just duplicates the language from an old SRV draft - language which was one of the overhauls before the doc was finished, not least because it is hard to see how to specify "Weight 0" (as directed) in a field which has a range of 1-65535. I would simply drop this option - require use of the DNS, and don't attempt to pervert the DHCP protocol into becoming an el-cheapo DNS protocol in disguise. DHCP will already tell the client the address of the DNS server to use, sending an extra DNS query cannot realistically be enough overhead (in code size, or in execution time) to really matter (and as far as time goes, especially once it is realised that the DHCP server is often going to have to do the DNS query to get the information anyway - ie: you cannot assume that the delay won't exist). Just return the name to be used in the DNS SRV request, and return that in DNS encoded binary form (ie: an overall length - 1..255 followed by a series of one or more