From owner-namedroppers@ops.ietf.org Mon Jul 1 06:16:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19532 for ; Mon, 1 Jul 2002 06:16:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17OxyZ-0003dw-00 for namedroppers-data@psg.com; Mon, 01 Jul 2002 03:00:07 -0700 Received: from randy by psg.com with local (Exim 3.36 #1) id 17OxyT-0003dL-00 for namedroppers@ops.ietf.org; Mon, 01 Jul 2002 03:00:01 -0700 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Mon, 01 Jul 2002 03:00:01 -0700 X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 1 06:49:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23766 for ; Mon, 1 Jul 2002 06:49:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17OyX7-0006sO-00 for namedroppers-data@psg.com; Mon, 01 Jul 2002 03:35:49 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17OyX1-0006rA-00 for namedroppers@ops.ietf.org; Mon, 01 Jul 2002 03:35:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21269; Mon, 1 Jul 2002 06:34:55 -0400 (EDT) Message-Id: <200207011034.GAA21269@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-ad-is-secure-06.txt Date: Mon, 01 Jul 2002 06:34:54 -0400 X-Spam-Status: No, hits=1.4 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6, DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Redefinition of DNS AD bit Author(s) : B. Wellington, O. Gudmundsson Filename : draft-ietf-dnsext-ad-is-secure-06.txt Pages : 7 Date : 28-Jun-02 Based on implementation experience, the RFC2535 definition of the Authenticated Data (AD) bit in the DNS header is not useful. This draft changes the specification so that the AD bit is only set on answers where signatures have been cryptographically verified or the server is authoritative for the data and is allowed to set the bit by policy. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ad-is-secure-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628141901.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ad-is-secure-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628141901.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 06:44:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02387 for ; Tue, 2 Jul 2002 06:44:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PKwC-000PhI-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 03:31:12 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17PKw6-000Ph5-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 03:31:07 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00867; Tue, 2 Jul 2002 06:30:17 -0400 (EDT) Message-Id: <200207021030.GAA00867@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-01.txt Date: Tue, 02 Jul 2002 06:30:17 -0400 X-Spam-Status: No, hits=1.4 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,DOUBLE_CAPSWORD, EXCUSE_6 version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Resource Records for DNS Security Extensions Author(s) : R. Arends et al. Filename : draft-ietf-dnsext-dnssec-records-01.txt Pages : 26 Date : 01-Jul-02 The DNS Security Extensions (DNSSEC) introduce four resource records: the KEY, DS, SIG, and NXT resource records. This document defines the purpose and the RDATA format for each of these records. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that provide source authentication for the DNS. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-records-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-dnssec-records-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: <20020701151820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151820.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 06:44:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02410 for ; Tue, 2 Jul 2002 06:44:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PKw1-000Pgt-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 03:31:01 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17PKvw-000Pgb-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 03:30:56 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00824; Tue, 2 Jul 2002 06:30:06 -0400 (EDT) Message-Id: <200207021030.GAA00824@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-restrict-key-for-dnssec-03.txt Date: Tue, 02 Jul 2002 06:30:06 -0400 X-Spam-Status: No, hits=1.4 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6, DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Limiting the Scope of the KEY Resource Record Author(s) : D. Massey, S. Rose Filename : draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Pages : 15 Date : 01-Jul-02 This document limits the Domain Name System KEY resource record to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY resource record used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys in one record was a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY Resource Record Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are removed. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-restrict-key-for-dnssec-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701151800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-restrict-key-for-dnssec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151800.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 06:44:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02455 for ; Tue, 2 Jul 2002 06:44:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PKw6-000Ph6-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 03:31:06 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17PKw1-000Pgs-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 03:31:01 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00841; Tue, 2 Jul 2002 06:30:12 -0400 (EDT) Message-Id: <200207021030.GAA00841@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-ipv6-addresses-02.txt Date: Tue, 02 Jul 2002 06:30:12 -0400 X-Spam-Status: No, hits=1.4 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6, DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Representing IPv6 addresses in DNS Author(s) : R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain Filename : draft-ietf-dnsext-ipv6-addresses-02.txt Pages : 6 Date : 01-Jul-02 This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ipv6-addresses-02.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-ipv6-addresses-02.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: <20020701151811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ipv6-addresses-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ipv6-addresses-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151811.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 06:45:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02488 for ; Tue, 2 Jul 2002 06:45:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PKvt-000PgY-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 03:30:53 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17PKvm-000PfJ-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 03:30:46 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00775; Tue, 2 Jul 2002 06:29:56 -0400 (EDT) Message-Id: <200207021029.GAA00775@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-02.txt Date: Tue, 02 Jul 2002 06:29:56 -0400 X-Spam-Status: No, hits=3.5 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,OPT_IN,EXCUSE_6, DOUBLE_CAPSWORD version=2.30 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC Opt-in Author(s) : R. Arends, M. Kosters, D. Blacka Filename : draft-ietf-dnsext-dnssec-opt-in-02.txt Pages : 19 Date : 01-Jul-02 In RFC 2535, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-opt-in-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-02.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: <20020701151741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151741.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 07:46:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02388 for ; Tue, 2 Jul 2002 06:44:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PKwL-000PhS-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 03:31:21 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17PKvr-000Pfj-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 03:30:51 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00808; Tue, 2 Jul 2002 06:30:02 -0400 (EDT) Message-Id: <200207021030.GAA00808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-delegation-signer-08.txt Date: Tue, 02 Jul 2002 06:30:01 -0400 X-Spam-Status: No, hits=1.9 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6, DOUBLE_CAPSWORD,PORN_3 version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-08.txt Pages : 13 Date : 01-Jul-02 The delegation signer (DS) resource record is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and the implications of this record on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC1035, RFC2535, RFC3008 and RFC3090. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-delegation-signer-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020701151751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020701151751.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 12:27:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29015 for ; Tue, 2 Jul 2002 12:27:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PQEf-0007Xh-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 09:10:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17PQER-0007XJ-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 09:10:23 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17PQER-0002NQ-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 09:10:23 -0700 Message-ID: <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> In-Reply-To: <200207021030.GAA00824@ietf.org> References: <200207021030.GAA00824@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 2 Jul 2002 13:36:29 +0200 (CEST) Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: "Simon Josefsson" To: X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > Title : Limiting the Scope of the KEY Resource Record IMO it is a mistake to prohibit core DNSSEC functionality without offering an alternative for those that want to continue use the deprecated functionality. Suggestion: Ship restrict-key-for-dnssec together with the APPKEY spec, assuming the scope of APPKEY is made the same as KEY-for-application was. Also, quoting the security considerations: This document eliminates potential security problems that could arise due to the coupling of DNS zone keys and application keys. Prior to the change described in this document, a correctly authenticated KEY set could include both application keys and DNSSEC keys. If one of the application keys is compromised, it could be used as a false zone key to create false DNS signatures (SIG records). Resolvers that do not carefully check the KEY sub-type could believe these false signatures and incorrectly authenticate DNS data. With this change, application keys cannot appear in an authenticated KEY set and this vulnerability is eliminated. This is a bogus consideration. A resolver that doesn't use the correct key for each purpose is broken, and removing one way of getting those incorrect keys doesn't improve the situation. This specification does not fix security problem. Continuing quoting: The format and correct usage of DNSSEC keys is not changed by this document and no new security considerations are introduced. The last statement is plain wrong, prohibiting application key distribution using KEY records of course has security implications The considerations are even major, since any existing security applications using KEY RRs are made non-compliant. This should be made clear. Ideally a transition plan should be discussed as well. Suggested new security consideration: This specification prohibits storing of application keys in KEY records, which has immediate security implications for any applications currently using KEY records for this purpose. However, it is not expected that many such applications exists. Existing application are suggested to transition to [APPKEY]. The format and correct usage of DNSSEC keys is not changed by this document, and the security considerations of [RFC2535] still apply. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 13:59:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04484 for ; Tue, 2 Jul 2002 13:59:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PRkv-000DvT-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 10:48:01 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17PRko-000Dtz-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 10:47:54 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA04963; Tue, 2 Jul 2002 13:47:53 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA11037; Tue, 2 Jul 2002 13:42:31 -0400 (EDT) Received: from lockpicking-tools.mit.edu (LOCKPICKING-TOOLS.MIT.EDU [18.101.0.168]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA16128; Tue, 2 Jul 2002 13:42:27 -0400 (EDT) Received: (from ghudson@localhost) by lockpicking-tools.mit.edu (8.9.3) id NAA15983; Tue, 2 Jul 2002 13:42:26 -0400 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: Greg Hudson To: Simon Josefsson Cc: namedroppers@ops.ietf.org In-Reply-To: <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> References: <200207021030.GAA00824@ietf.org> <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 02 Jul 2002 13:42:26 -0400 Message-Id: <1025631746.1758.23.camel@lockpicking-tools.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Speaking as someone who thinks it would be cool to protect keys using DNSSEC: On Tue, 2002-07-02 at 07:36, Simon Josefsson wrote: > IMO it is a mistake to prohibit core DNSSEC functionality without offering > an alternative for those that want to continue use the deprecated > functionality. I don't think application keys in DNS is "core DNSSEC functionality." The core DNSSEC functionality is protecting existing DNS data (most importantly, name-to-address and address-to-name mappings). We don't have consensus on whether or not it's a good idea to put keys in DNS or to protect them with DNSSEC. As such, it is hard to progress proposals which fix the problems associated with doing it the RFC 2535 way. We do seem to have consensus that KEY is a bad way to put keys in DNS. It seems reasonable to say, "Don't do it this way; we will continue to argue about whether we should be helping you to do it at all." > Suggestion: Ship restrict-key-for-dnssec together with the APPKEY spec, > assuming the scope of APPKEY is made the same as KEY-for-application was. I have doubts that APPKEY is practical, by itself. It seems that if you have many applications with keys at the same domain name, you will quickly exceed the EDNS0 UDP packet size limit and eventually exceed the hard 64K limit. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 14:31:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06769 for ; Tue, 2 Jul 2002 14:31:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PSGd-000G7x-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 11:20:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17PSGY-000G7m-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 11:20:42 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17PSGY-00060m-00; Tue, 02 Jul 2002 11:20:42 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Hudson Cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <200207021030.GAA00824@ietf.org> <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> <1025631746.1758.23.camel@lockpicking-tools.mit.edu> Message-Id: Date: Tue, 02 Jul 2002 11:20:42 -0700 X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I don't think application keys in DNS is "core DNSSEC > functionality." The core DNSSEC functionality is protecting > existing DNS data (most importantly, name-to-address and > address-to-name mappings). ack > We don't have consensus on whether or not it's a good idea to put > keys in DNS or to protect them with DNSSEC. quibble: if we get consensus to put them in, i presume that they would be authenticated with normal dnssec mechanisms. i.e. the latter should not be an issue. > We do seem to have consensus that KEY is a bad way to put keys in > DNS. indeed, i believe this draft did pass wg last call. this version was a touchup to answer nits raised by the area director before passing to the iesg. > It seems reasonable to say, "Don't do it this way; we will > continue to argue about whether we should be helping you to do it > at all." it is my impression that this is what is occurring. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 14:40:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07365 for ; Tue, 2 Jul 2002 14:40:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PSSf-000GzY-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 11:33:13 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17PSSb-000GzN-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 11:33:09 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id CB6011932 for ; Tue, 2 Jul 2002 14:33:08 -0400 (EDT) Date: Tue, 02 Jul 2002 14:33:08 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: <1025631746.1758.23.camel@lockpicking-tools.mit.edu> References: <200207021030.GAA00824@ietf.org> <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> <1025631746.1758.23.camel@lockpicking-tools.mit.edu> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigorymae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020702183308.CB6011932@thrintun.hactrn.net> X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02 Jul 2002 13:42:26 -0400, Greg Hudson wrote: > > I don't think application keys in DNS is "core DNSSEC functionality." > The core DNSSEC functionality is protecting existing DNS data (most > importantly, name-to-address and address-to-name mappings). Bingo. > I have doubts that APPKEY is practical, by itself. It seems that if you > have many applications with keys at the same domain name, you will > quickly exceed the EDNS0 UDP packet size limit and eventually exceed the > hard 64K limit. This is the so-called "subtyping problem". In brief: conceptually, an RRset is named by TYPE + NAME + CLASS, where "+" denotes (conceptual) concatenation. When such an RRset gets too big and all the RRs in such an RRset are (conceptually) related, there's not much one can do about it (this is part of the reason why MG RRs never caught on), but when the RRs that make up such an RRset make up two or more conceptually distinct groups that can only be identified by fetching and examing the whole RRset (and, most likely, discarding the irrelevant portions), it's the subtyping problem. All the known ways of getting out of the subtyping problem involve breaking the big RRset up into seperate RRsets by changing the conceptual name (somehow). The two common ways are either to use separate TYPE codes or to use magic labels at the least significant end of the NAME. Which solution one prefers depends on how easy one believes it is to add new TYPE codes to the DNS (opinions vary) and how much one wishes to avoid using magic labels (opinions vary). My understanding is that most (all?) of the folks proposing to use a single APPKEY TYPE also propose to use the magic label approach. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 15:11:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09413 for ; Tue, 2 Jul 2002 15:11:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PSuJ-000Iy7-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 12:01:47 -0700 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.36 #1) id 17PSu9-000Ixu-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 12:01:37 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id PAA18301 for ; Tue, 2 Jul 2002 15:01:35 -0400 (EDT) Message-ID: <009101c221fa$174c6b60$b9370681@BARNACLE> From: "Scott Rose" To: References: <200207021030.GAA00824@ietf.org><65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com><1025631746.1758.23.camel@lockpicking-tools.mit.edu> <20020702183308.CB6011932@thrintun.hactrn.net> Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Date: Tue, 2 Jul 2002 14:55:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The main reason no alternative was bundled with the restrict-key draft was because we didn't have any consensus about how to store keys in the DNS, but a general consensus that the KEY RR was a bad choice. In fact an entire BOF was spawned to address a general version of this problem (SIKED). Besides APPKEY, there are a few other competing proposals if I remember. So how non-DNSSEC keys are still being debated on, we decide to at least take the KEY RR out of the running and leave the subject of securing DNS separate than using DNS to support other security transactions. Scott ----- Original Message ----- From: "Rob Austein" To: Sent: Tuesday, July 02, 2002 2:33 PM Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt > At 02 Jul 2002 13:42:26 -0400, Greg Hudson wrote: > > > > I don't think application keys in DNS is "core DNSSEC functionality." > > The core DNSSEC functionality is protecting existing DNS data (most > > importantly, name-to-address and address-to-name mappings). > > Bingo. > > > I have doubts that APPKEY is practical, by itself. It seems that if you > > have many applications with keys at the same domain name, you will > > quickly exceed the EDNS0 UDP packet size limit and eventually exceed the > > hard 64K limit. > > This is the so-called "subtyping problem". In brief: conceptually, an > RRset is named by TYPE + NAME + CLASS, where "+" denotes (conceptual) > concatenation. When such an RRset gets too big and all the RRs in > such an RRset are (conceptually) related, there's not much one can do > about it (this is part of the reason why MG RRs never caught on), but > when the RRs that make up such an RRset make up two or more > conceptually distinct groups that can only be identified by fetching > and examing the whole RRset (and, most likely, discarding the > irrelevant portions), it's the subtyping problem. > > All the known ways of getting out of the subtyping problem involve > breaking the big RRset up into seperate RRsets by changing the > conceptual name (somehow). The two common ways are either to use > separate TYPE codes or to use magic labels at the least significant > end of the NAME. Which solution one prefers depends on how easy one > believes it is to add new TYPE codes to the DNS (opinions vary) and > how much one wishes to avoid using magic labels (opinions vary). > > My understanding is that most (all?) of the folks proposing to use a > single APPKEY TYPE also propose to use the magic label approach. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 15:33:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10747 for ; Tue, 2 Jul 2002 15:33:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PTIq-000Kik-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 12:27:08 -0700 Received: from adsl-63-196-7-183.dsl.snfc21.pacbell.net ([63.196.7.183] helo=blade.unixpeople.internal) by psg.com with esmtp (Exim 3.36 #1) id 17PTIj-000KhW-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 12:27:01 -0700 Received: from unixpeople.com (localhost [127.0.0.1]) by blade.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g62JQgoW008244 for ; Tue, 2 Jul 2002 12:26:43 -0700 (PDT) Message-ID: <3D21FDFD.5060005@unixpeople.com> Date: Tue, 02 Jul 2002 12:24:45 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <200207021030.GAA00824@ietf.org> <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> <1025631746.1758.23.camel@lockpicking-tools.mit.edu> <20020702183308.CB6011932@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > At 02 Jul 2002 13:42:26 -0400, Greg Hudson wrote: > >>I don't think application keys in DNS is "core DNSSEC functionality." >>The core DNSSEC functionality is protecting existing DNS data (most >>importantly, name-to-address and address-to-name mappings). > > > Bingo. I disagree. RFC 2535 is very clear on this point, as I was reminded a few weeks ago when I questioned why we bother with DNSSEC at all. | Keys associated with DNS names can be retrieved to support other | protocols. Provision is made for a variety of key types and | algorithms. `---- > > >>I have doubts that APPKEY is practical, by itself. It seems that if you >>have many applications with keys at the same domain name, you will >>quickly exceed the EDNS0 UDP packet size limit and eventually exceed the >>hard 64K limit. > > > This is the so-called "subtyping problem". In brief: conceptually, an > RRset is named by TYPE + NAME + CLASS, where "+" denotes (conceptual) > concatenation. When such an RRset gets too big and all the RRs in > such an RRset are (conceptually) related, there's not much one can do > about it (this is part of the reason why MG RRs never caught on), but > when the RRs that make up such an RRset make up two or more > conceptually distinct groups that can only be identified by fetching > and examing the whole RRset (and, most likely, discarding the > irrelevant portions), it's the subtyping problem. Yes, this could be a problem, IF you have a lot of keys at one name. I envision that additional names will be created for most applications. If we assume 1k per key (which I don't feel is unreasonable, but I could be wrong here), then we can store approximately 60 keys at a single name before we overflow. > > All the known ways of getting out of the subtyping problem involve > breaking the big RRset up into seperate RRsets by changing the > conceptual name (somehow). The two common ways are either to use > separate TYPE codes or to use magic labels at the least significant > end of the NAME. Which solution one prefers depends on how easy one > believes it is to add new TYPE codes to the DNS (opinions vary) and > how much one wishes to avoid using magic labels (opinions vary). > > My understanding is that most (all?) of the folks proposing to use a > single APPKEY TYPE also propose to use the magic label approach. Neither of these is necessary if we can live with the 60 keys per DNAME restriction. I don't think this is overly-restrictive. Its just like we all deal with limitations on number of type A RRs associated with a name so that the query/response doesn't fall over into TCP which a huge number of name servers would fail on anyway (cause silly admins block TCP). -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) Give a small boy a hammer and he will find that everything he encounters needs pounding. --ABRAHAM KAPLAN -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 16:56:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14918 for ; Tue, 2 Jul 2002 16:56:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PUX9-00008a-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 13:45:59 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17PUWK-00007O-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 13:45:08 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id D05F41932 for ; Tue, 2 Jul 2002 16:45:07 -0400 (EDT) Date: Tue, 02 Jul 2002 16:45:07 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: <3D21FDFD.5060005@unixpeople.com> References: <200207021030.GAA00824@ietf.org> <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> <1025631746.1758.23.camel@lockpicking-tools.mit.edu> <20020702183308.CB6011932@thrintun.hactrn.net> <3D21FDFD.5060005@unixpeople.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigorymae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020702204507.D05F41932@thrintun.hactrn.net> X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 02 Jul 2002 12:24:45 -0700, Andy W. Barclay wrote: > > I disagree. RFC 2535 is very clear on this point, as I was reminded > a few weeks ago when I questioned why we bother with DNSSEC at all. > > | Keys associated with DNS names can be retrieved to support other > | protocols. Provision is made for a variety of key types and > | algorithms. The WG said a great many things in RFC 2535, some of which have held up better than others under further scrutiny as the WG has continued its attempts to understand the problem space. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 18:18:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19169 for ; Tue, 2 Jul 2002 18:18:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PVmU-0005Fw-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 15:05:54 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17PVmR-0005Fh-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 15:05:51 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 6778D52A9; Wed, 3 Jul 2002 00:05:48 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id D1F901DF8; Wed, 3 Jul 2002 00:05:47 +0200 (MEST) Date: Wed, 3 Jul 2002 00:05:47 +0200 (CEST) From: Jakob Schlyter To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: <20020702183308.CB6011932@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 2 Jul 2002, Rob Austein wrote: > My understanding is that most (all?) of the folks proposing to use a > single APPKEY TYPE also propose to use the magic label approach. one could use a naming based on napstr, that would remove the magic label approch for appkey but move it to a reference inside an naptr instead. perhaps something like: host.example.com. NAPTR 1 10 "p" "APPKEY+ipsec" "" ipsec.host.example.com. ipsec.host.example.com. APPKEY ... jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 18:23:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19316 for ; Tue, 2 Jul 2002 18:23:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PVw4-0005sK-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 15:15:48 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17PVvz-0005s8-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 15:15:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18857; Tue, 2 Jul 2002 18:14:50 -0400 (EDT) Message-Id: <200207022214.SAA18857@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Delegation Signer Resource Record to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 02 Jul 2002 18:14:50 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=X_NOT_PRESENT,ALL_CAPS_HEADER,TO_MALFORMED version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions Working Group to consider Delegation Signer Resource Record as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 30, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-08.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 18:42:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20095 for ; Tue, 2 Jul 2002 18:42:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PWG0-0007JJ-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 15:36:24 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17PWFw-0007J2-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 15:36:20 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19700; Tue, 2 Jul 2002 18:35:26 -0400 (EDT) Message-Id: <200207022235.SAA19700@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Limiting the Scope of the KEY Resource Record to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 02 Jul 2002 18:35:26 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=X_NOT_PRESENT,ALL_CAPS_HEADER,TO_MALFORMED version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions Working Group to consider Limiting the Scope of the KEY Resource Record as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 30, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-03.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 2 23:39:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01949 for ; Tue, 2 Jul 2002 23:39:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Palr-000PzL-00 for namedroppers-data@psg.com; Tue, 02 Jul 2002 20:25:35 -0700 Received: from [202.28.97.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17Palm-000PzA-00 for namedroppers@ops.ietf.org; Tue, 02 Jul 2002 20:25:30 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g633P8I25735; Wed, 3 Jul 2002 10:25:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g633OUf02670; Wed, 3 Jul 2002 10:24:34 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Andy W. Barclay" cc: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: <3D21FDFD.5060005@unixpeople.com> References: <3D21FDFD.5060005@unixpeople.com> <200207021030.GAA00824@ietf.org> <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> <1025631746.1758.23.camel@lockpicking-tools.mit.edu> <20020702183308.CB6011932@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jul 2002 10:24:30 +0700 Message-ID: <2668.1025666670@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 02 Jul 2002 12:24:45 -0700 From: "Andy W. Barclay" Message-ID: <3D21FDFD.5060005@unixpeople.com> | I disagree. RFC 2535 is very clear on this point, as I was reminded | a few weeks ago when I questioned why we bother with DNSSEC at all. | | | Keys associated with DNS names can be retrieved to support other | | protocols. Provision is made for a variety of key types and | | algorithms. That says that you can use the KEYS that exist for other protocols if you feel inclined. It doesn't say that you can add new ones for some other purpose... The variety of key types, etc, is in case DNSSEC needs/wants to change the algorithms it uses for securing the DNS. | Yes, this could be a problem, IF you have a lot of keys at one name. The only way to avoid that is as Rob Austein said - magic names, or different types. Magic names are absolutely the wrong way to use the DNS - the namespace there is to be allocated to the end user organisations to use as they see fit, not to constrain for protocol purposes. (You can see that I have one of the opinions that Rob mentioned...) | Neither of these is necessary if we can live with the 60 keys per DNAME | restriction. That means < 30 applications max (to allow each to have a current, and a past, key visible). That's a very very low limit. And ... jakob@crt.se said: | one could use a naming based on napstr, that would remove the magic | label approch for appkey but move it to a reference inside an naptr | instead. perhaps something like: That isn't a solution, it is the problem itself. That's exactly what needs to be avoided (for some particular cases it may be possible to work that way, and NAPTR might happen to be one of those, keys certainly aren't). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 05:39:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02603 for ; Wed, 3 Jul 2002 05:39:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PgQz-000MDr-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 02:28:25 -0700 Received: from smtp.denic.de ([194.246.96.22]) by psg.com with esmtp (Exim 3.36 #1) id 17PgQv-000MDg-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 02:28:21 -0700 Received: from notes.denic.de (frankfurt1.denic.de [194.246.96.101]) by smtp.denic.de with esmtp id 17PgQE-0001vL-00; Wed, 3 Jul 2002 11:27:38 +0200 Subject: Comments on delegation-signer-08 To: namedroppers@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Marcos Sanz/Denic" Date: Wed, 3 Jul 2002 11:27:20 +0200 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.8 |June 18, 2001) at 03.07.2002 11:27:37 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=3.0 required=5.0 tests=DOUBLE_CAPSWORD,UPPERCASE_25_50 version=2.30 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA02603 Section 2.6.1, It says: "Secure DS: NS + DS + SIG(DS)" Shouldn't it say? "Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT)" Regards, Marcos Sanz System Development DENIC eG -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 06:35:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04322 for ; Wed, 3 Jul 2002 06:35:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PhN5-000Pqj-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 03:28:27 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17PhMz-000PqW-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 03:28:22 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03219; Wed, 3 Jul 2002 06:27:32 -0400 (EDT) Message-Id: <200207031027.GAA03219@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-unknown-rrs-03.txt Date: Wed, 03 Jul 2002 06:27:32 -0400 X-Spam-Status: No, hits=1.4 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,TO_MALFORMED,EXCUSE_6, DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Handling of Unknown DNS RR Types Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-unknown-rrs-03.txt Pages : 7 Date : 02-Jul-02 Extending the Domain Name System with new Resource Record types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-unknown-rrs-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702150914.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-unknown-rrs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702150914.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 07:24:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05821 for ; Wed, 3 Jul 2002 07:24:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Pi6J-0002xh-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 04:15:11 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17Pi65-0002w1-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 04:14:57 -0700 Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 9A3B3137F03; Wed, 3 Jul 2002 04:14:44 -0700 (PDT) Date: Wed, 3 Jul 2002 04:14:44 -0700 (PDT) From: Roy Arends To: Marcos Sanz/Denic Cc: Subject: Re: Comments on delegation-signer-08 In-Reply-To: Message-ID: <20020703040544.C86988-100000@shell.nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Jul 2002, Marcos Sanz/Denic wrote: > Section 2.6.1, > > It says: > "Secure DS: NS + DS + SIG(DS)" > > Shouldn't it say? > "Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT)" The resolver can determine by an "NS + DS + SIG(DS)" response that this is a delegation to a secured zone. Though in the parent zone there resides a "+ NXT + SIG(NXT)", this section documents how a resolver determines the type of delegation. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 09:30:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12368 for ; Wed, 3 Jul 2002 09:30:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Pk1Y-000B8B-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 06:18:24 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17Pk1P-000B6z-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 06:18:15 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id JAA09811; Wed, 3 Jul 2002 09:18:13 -0400 (EDT) Received: from [199.171.39.211] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA25459; Wed, 3 Jul 2002 09:18:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <3D21FDFD.5060005@unixpeople.com> References: <200207021030.GAA00824@ietf.org> <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> <1025631746.1758.23.camel@lockpicking-tools.mit.edu> <20020702183308.CB6011932@thrintun.hactrn.net> <3D21FDFD.5060005@unixpeople.com> Date: Tue, 2 Jul 2002 22:53:43 -0400 To: "Andy W. Barclay" , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,DOUBLE_CAPSWORD, DATE_IN_PAST_06_12 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't intend this statement to be directed at any individual, but the following mail fragment is what prompted my statements below. At 12:24 PM -0700 7/2/02, Andy W. Barclay wrote: >Rob Austein wrote: >> At 02 Jul 2002 13:42:26 -0400, Greg Hudson wrote: >> >>>I don't think application keys in DNS is "core DNSSEC functionality." The >>>core DNSSEC functionality is protecting existing DNS data (most >>>importantly, name-to-address and address-to-name mappings). >> >> Bingo. > >I disagree. RFC 2535 is very clear on this point, as I was reminded >a few weeks ago when I questioned why we bother with DNSSEC at all. > >| Keys associated with DNS names can be retrieved to support other >| protocols. Provision is made for a variety of key types and >| algorithms. >`---- I agree with Rob's and Randy's (not shown) thoughts on this thread. Speaking as someone who has spent considerable time on DNSSEC, who co-chaired the BOF on SIKED, and was a closet proponent of A6, DNAME, and binary labels, I would say now that - to stay to the subject at hand - placing unadorned application keys in DNS is a mistake. Way back before I spent time in the IETF, I developed a name server prototype. The project I did this for is not historically significant, but I learned a lesson then that I had forgotten in my (later) formative years. (I have since relearned it from Randy at the SecDynUp workshop last winter). Name service ought to be a simple, humble component in the machinery of a network. Much like any central piece of a distributed system, the name service must be built to be rugged, flexible, and resilient. Does this mean that the name service should not be secured, a la DNSSEC? No. Security is part of resilience. But what I do mean to say is that putting a lot of extraneous features into the name service - just because it is there - is a patently bad approach. Sure, it is tempting to leverage on the service in place, but in the long run we wind up making the protocol more complex and worse, by putting all our eggs in one basket, create a more critical single point of failure. RFC 2535 (and its predecessor) were wrong to promise that DNSSEC would be a fine way to distribute keys. (I don't fault the editor, it was WG consensus at one time.) Key distribution is a matter best left to the certificate working groups. Why let the distributed database folks create another trust model when this is being done by security folks? So what if there is unhappiness with what has been produced to date - those unhappy aren't going to do a better job than security experts. I don't want to tie in the IPv6 record debate - that's another document, another thread, and a different last call. But (I will because) the reason behind my distaste for this kind of DNS innovation is that these are (worthy) problems that ought not be solved in the DNS protocol. What is needed is better (software) tools, applied in the right places. These tools should do the work that is needed (learning trusted keys, managing renumbering of networks) and input the results of that work to a DNS server. The DNS server should then simply distribute the data, and nothing more. Securely distribute - but only guaranteeing that what went into the master zone is what comes out the resolver. No application security, just end-to-end transit security. Keep the DNS simple. Use it to locate other services. Let other services update the DNS. But don't make the DNS do too much - even if it is the path of least resistance. Remember what the E in IETF stands for, it's not the "Internet Path of Least Resistance Task Force." Fix what's broken, don't overload the protocol. Complexity is a cancer. Creeping features are a carcinogen. So much for a soapbox statement. As far as application keys, instead of trying to lump keys into the DNS, why not explore certificates? They don't work? Engineer them until they do. By their very nature, certificates are the proper approach. If it is because the tools aren't available - make the tools. Don't break a fine protocol like DNS. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 09:57:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14124 for ; Wed, 3 Jul 2002 09:57:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PkX0-000DVw-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 06:50:54 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17PkWo-000DVd-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 06:50:42 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA25989; Wed, 3 Jul 2002 09:50:40 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA23930; Wed, 3 Jul 2002 09:50:40 -0400 (EDT) Received: from lockpicking-tools.mit.edu (LOCKPICKING-TOOLS.MIT.EDU [18.101.0.168]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA00526; Wed, 3 Jul 2002 09:50:38 -0400 (EDT) Received: (from ghudson@localhost) by lockpicking-tools.mit.edu (8.9.3) id JAA22830; Wed, 3 Jul 2002 09:50:38 -0400 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: Greg Hudson To: Edward Lewis Cc: namedroppers@ops.ietf.org In-Reply-To: References: <200207021030.GAA00824@ietf.org> <65064.62.255.241.113.1025609789.squirrel@yxa.extundo.com> <1025631746.1758.23.camel@lockpicking-tools.mit.edu> <20020702183308.CB6011932@thrintun.hactrn.net> <3D21FDFD.5060005@unixpeople.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 03 Jul 2002 09:50:38 -0400 Message-Id: <1025704238.1758.52.camel@lockpicking-tools.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2002-07-02 at 22:53, Edward Lewis wrote: > As far as application keys, instead of trying to lump keys into the > DNS, why not explore certificates? They don't work? Engineer them > until they do. By their very nature, certificates are the proper > approach. Gosh, that's a strong statement. I guess I'll just note that the current widely-known certificate deployment has no key revocation infrastructure; as a result, bogus certificates issued for Microsoft could not be revoked except by deploying new software (with a hardcoded CRL) to every desktop. I'm not sure that solving this problem is a simple matter of "engineering certificates." It may mean scrapping the whole concept of an offline system. > But what I do mean to say is that putting a lot of extraneous features > into the name service - just because it is there - is a patently bad > approach. I continue to find this argument to be FUD. For some applications, such as IPSEC, protecting the key of a host using DNSSEC is not an "extraneous feature"; it's a core part of determining that the host you're talking to is really authorized by the naming authorities to use the hostname you wanted to talk to. You could use certificates for the same purpose (as we do today for web servers), but it will always leave one with the nagging question of whether the certificate authority agrees with the naming authority on who gets to use what name. Saying that DNS is being proposed "just because it is there" is a straw man argument. People have given perfectly good reasons to use DNS for this purpose. > These tools should do the work that is needed (learning trusted keys, > managing renumbering of networks) and input the results of that work > to a DNS server. Agreed. But I think the same technique can allow putting keys or key fingerprints in DNS without adding complexity to the primary DNS serving software. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 13:50:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23673 for ; Wed, 3 Jul 2002 13:50:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PnGa-000MPw-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 09:46:08 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17PnFi-000MPM-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 09:45:14 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g63Gj2d23070; Wed, 3 Jul 2002 16:45:03 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g63Gj6MP005253; Wed, 3 Jul 2002 11:45:06 -0500 (CDT) Date: Wed, 3 Jul 2002 11:45:04 -0500 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Andy W. Barclay" , namedroppers@ops.ietf.org To: Edward Lewis From: Ted Lemon In-Reply-To: Message-Id: <397F45EA-8EA4-11D6-873D-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Maybe this is a stupid question, but in what way does putting application key records into the DNS make it more complicated? Does it *need* to be more complicated, or is this a bug in the specification that could be fixed? I agree with you that adding *complexity* to DNS is a bad thing. I just don't see how that premise directly supports the argument that there should be no keys in the DNS. That is, adding *complexity* to the DNS is not the same thing as adding *records* to the DNS. There is no reason why records have to be complex. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 15:12:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00692 for ; Wed, 3 Jul 2002 15:12:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PpLC-0000YH-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 11:59:02 -0700 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 17PpL8-0000Y6-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 11:58:58 -0700 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 11:58:57 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 11:58:57 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 11:58:57 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 11:58:57 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 3 Jul 2002 11:59:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: The reverse lookup issue Date: Wed, 3 Jul 2002 11:59:11 -0700 Message-ID: Thread-Topic: The reverse lookup issue Thread-Index: AcIiuY9hv2rnw5toQ3KVFi8ru3QRYgABykrA From: "Christian Huitema" To: , X-OriginalArrivalTime: 03 Jul 2002 18:59:03.0167 (UTC) FILETIME=[B2B070F0:01C222C3] X-Spam-Status: No, hits=1.5 required=5.0 tests=DOUBLE_CAPSWORD,GAPPY_TEXT version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA00692 As we are looking at evaluating various transition mechanisms, we will need to address the reverse lookup issue, i.e. how to get the equivalent functionality to "gethostbyaddr()", and whether we really need it. I am specially interested by the solution in the case of unmanaged networks, such as a home network. Today, it kind of works as follow: the ISP allocates an IPv4 address to the home gateway or NAT; that address belongs to the range of IPv4 addresses managed by the ISP; reverse lookup are served directly by the ISP's DNS server. The level of service varies a lot, but the dominant solutions are either a perfunctory record, such as the ISP "example.net" mapping "64.5.6.7" to "ip4-64-5-6-7.example.net", or no service at all. The problem is particularly acute with "autoconfigured" solutions such as 6to4, Teredo and to some extent ISATAP. The 6to4 router that builds a prefix for "2002:4005:607" may or may not obtain a delegation of the domain "7.0.6.0.5.0.0.4.2.0.0.2.ip6.arpa" -- that can be arranged if was statically allocated and the ISP allocating the address is "64.5.6.7" willing to delegate, but the operational implications are daunting. Even if the 6to4 router actually obtains delegation, we are not out of the woods. Unmanaged networks will typically use automatic address configuration, specially as they want to enhance the users' privacy with "privacy addresses." The only practical solutions there are either to use an algorithm and generate perfunctory records (e.g., a.b.c.d.e.f.0.1.2.3.4.5.6.7.8.9.1.0.0.0.7.0.6.0.5.0.0.4.2.0.0.2.ip6.arpa maps to ip6-abcdef01234567891000706050042002.example.net); or somehow forward the DNS request to the host itself, which will answer with some arbitrary value. So, my question is, do we really need to invest in a reverse lookup DNS tree for IPv6? Or should we not just "declare victory" and recognize that reverse lookup has very little practical value? -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 15:59:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03615 for ; Wed, 3 Jul 2002 15:59:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Pq5y-00024p-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 12:47:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Pq5X-00022w-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 12:46:55 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17Pq5X-000LLX-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 12:46:55 -0700 Message-Id: <200207031936.g63JaC0L035839@whizzo.transsys.com> References: In-reply-to: Your message of "Wed, 03 Jul 2002 11:59:11 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: "Christian Huitema" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: "Louis A. Mamakos" Subject: Re: (ngtrans) The reverse lookup issue Date: Wed, 03 Jul 2002 15:36:12 -0400 X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > So, my question is, do we really need to invest in a reverse lookup DNS > tree for IPv6? Or should we not just "declare victory" and recognize > that reverse lookup has very little practical value? I think that about a decade ago (or so I it seems..) I suggested that we abandon the notion of using the DNS to do address->name lookups. Rather, define a simple standard service where a host can be asked what it thinks it's name is. In many cases, this does the "right thing" in that you get a meaningful name at the time that the address was allocated to someone (e.g., out of a DHCP pool or other transient network connection.) Sure, you can't "trust" this name. Just like you can't really trust the one in DNS PTR records, either. Or simply decide the practical value is small. louie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 16:04:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03852 for ; Wed, 3 Jul 2002 16:04:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PqAt-0002Eo-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 12:52:27 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17PqAU-0002EC-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 12:52:02 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g63Jprd23574; Wed, 3 Jul 2002 19:51:53 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g63JpwMP005334; Wed, 3 Jul 2002 14:51:58 -0500 (CDT) Date: Wed, 3 Jul 2002 14:51:57 -0500 Subject: Re: The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: , To: "Christian Huitema" From: Ted Lemon In-Reply-To: Message-Id: <5547A1B4-8EBE-11D6-873D-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am also somewhat skeptical about the value of reverse lookups, but people seem to like them, so I'm not sure if debating their value serves any purpose. If the customer wants it, and it's a valid thing to do, who are we to tell them they can't have it? This is a difficult problem to solve, though, with stateless addrconf, because the only device that can really update the DNS is the device that has configured its address, and that device might well not have any sort of security relationship with the owner of the address space. Since reverse lookups to some degree go hand-in-hand with a desire to control use of addresses, it might make sense to say that we can only do this with stateful addrconf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 16:40:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05789 for ; Wed, 3 Jul 2002 16:40:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Pqkw-0003dP-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 13:29:42 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17Pqjq-0003aL-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 13:28:34 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 3EA1628B6C; Wed, 3 Jul 2002 13:28:34 -0700 (PDT) From: Paul Vixie To: "Louis A. Mamakos" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Message from "Louis A. Mamakos" of "Wed, 03 Jul 2002 15:36:12 EDT." <200207031936.g63JaC0L035839@whizzo.transsys.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 03 Jul 2002 13:28:34 -0700 Message-Id: <20020703202834.3EA1628B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Sure, you can't "trust" this name. Just like you can't really trust > the one in DNS PTR records, either. using dns you get higher "trust splay" -- the party you're distrusting about the reverse mapping is different from (and is probably differently trustable) than the party you're distrusting about the forward mapping. that's a good thing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 16:41:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05885 for ; Wed, 3 Jul 2002 16:41:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Pqge-0003Sq-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 13:25:16 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17PqgP-0003Qc-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 13:25:01 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 2676C28B6C; Wed, 3 Jul 2002 13:25:00 -0700 (PDT) From: Paul Vixie To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue In-Reply-To: Message from "Christian Huitema" of "Wed, 03 Jul 2002 11:59:11 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 03 Jul 2002 13:25:00 -0700 Message-Id: <20020703202500.2676C28B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So, my question is, do we really need to invest in a reverse lookup DNS > tree for IPv6? Or should we not just "declare victory" and recognize > that reverse lookup has very little practical value? the practical value goes above and beyond those you've mentioned. i expect that many services, especially e-mail but also any other abusable service, will continue to reject connections for which no "reverse lookup" is known. we live on an increasingly irresponsible internet. my root name server gets more than a gigabyte of request traffic every day just from 10.0.0.0/8. we all get a huge amount of spam. anything that makes it harder to locate a responsible party for a given IP address (whether v4, v6, v8, or whatever) is automatically, unarguably "bad." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 17:44:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07930 for ; Wed, 3 Jul 2002 17:44:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Prba-0005dD-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 14:24:06 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17PrbU-0005d2-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 14:24:01 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 78DAD4B22; Thu, 4 Jul 2002 06:23:55 +0900 (JST) To: "Christian Huitema" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-reply-to: huitema's message of Wed, 03 Jul 2002 11:59:11 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (ngtrans) The reverse lookup issue From: itojun@iijlab.net Date: Thu, 04 Jul 2002 06:23:55 +0900 Message-Id: <20020703212355.78DAD4B22@coconut.itojun.org> X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >As we are looking at evaluating various transition mechanisms, we will >need to address the reverse lookup issue, i.e. how to get the equivalent >functionality to "gethostbyaddr()", and whether we really need it. how about draft-itojun-ipv6-nodeinfo-revlookup-00.txt? (i know the IESG pushback for ICMPv6 node info query, and the deployment problem) >So, my question is, do we really need to invest in a reverse lookup DNS >tree for IPv6? Or should we not just "declare victory" and recognize >that reverse lookup has very little practical value? as documented in draft-ietf-dnsop-inaddr-required-03.txt, if we could nuke reverse lookup tree it would be nice. but there are apps that use gethostbyaddr(), we need something. itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 18:20:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09947 for ; Wed, 3 Jul 2002 18:20:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ps3t-0006hY-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 14:53:21 -0700 Received: from postman.ripe.net ([193.0.0.199]) by psg.com with smtp (Exim 3.36 #1) id 17Ps3h-0006fe-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 14:53:09 -0700 Received: (qmail 10806 invoked by uid 0); 3 Jul 2002 21:53:07 -0000 Received: from x22.ripe.net (HELO x22.ripe.net.ripe.net) (193.0.1.22) by postman.ripe.net with SMTP; 3 Jul 2002 21:53:07 -0000 Date: Wed, 3 Jul 2002 23:53:07 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: "Louis A. Mamakos" cc: ngtrans@sunroof.eng.sun.com, Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <200207031936.g63JaC0L035839@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Jul 2002, Louis A. Mamakos wrote in reply to Christian Huitema: > > So, my question is, do we really need to invest in a reverse lookup DNS > > tree for IPv6? Or should we not just "declare victory" and recognize > > that reverse lookup has very little practical value? > > I think that about a decade ago (or so I it seems..) I suggested that > we abandon the notion of using the DNS to do address->name lookups. > Rather, define a simple standard service where a host can be asked > what it thinks it's name is. In many cases, this does the "right If you wish 'simple', you may as well use something very much akin to ident(1431), or indeed, overload the existing ident protocol with a slightly different request and answer. Not that I'm seriously suggesting that. > thing" in that you get a meaningful name at the time that the > address was allocated to someone (e.g., out of a DHCP pool or other > transient network connection.) As DNS operational folk have seen (MS, ddns by default), if you give the user the ability to define their own name, they will attempt to declare themselves to be 'all.high.and.mighty', and I really wouldn't like to see that sort of string appearing in my access logs. > Sure, you can't "trust" this name. Just like you can't really trust > the one in DNS PTR records, either. If you wish vaguely reliable, you've got the existing (reverse) DNS at the administrative mercies of providers/hopefully clued users. Most PTR records, if available, do have some sort of relationship to the responsible person behind the host. > Or simply decide the practical value is small. The practical value of address to name mapping is large for the site administrator; 'What is the host behind this IP address?'. If the host in question has been compromised, you can no longer trust _anything_ from that host. Hence, a requirement for address to name mapping does exist. DNS, so far, appears to work in providing that functionality. People outside your site may have policies (sometimes poorly thought out) that require you to provide some level of address to name mapping. This may or may not alter your liking of doing such. Regards, --==-- Bruce. Speaking for myself. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 18:21:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10056 for ; Wed, 3 Jul 2002 18:21:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PsGq-0007CR-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 15:06:44 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17PsGm-0007CE-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 15:06:40 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 151713; Wed, 03 Jul 2002 17:03:43 -0500 Message-ID: <3D23756D.7020205@ehsco.com> Date: Wed, 03 Jul 2002 17:06:37 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Christian Huitema CC: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/3/2002 1:59 PM Christian Huitema wrote: > So, my question is, do we really need to invest in a reverse lookup DNS > tree for IPv6? Yes, it's useful and necessary to a variety of validation processes, especially when used with double lookups (check PTR and A both ways). I would think that DDNS could handle the dynamic scenarios but perhaps I don't understand the problem. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 18:37:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10648 for ; Wed, 3 Jul 2002 18:37:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PsZQ-00080y-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 15:25:56 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17PsZE-00080h-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 15:25:44 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 151714 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 17:22:47 -0500 Message-ID: <3D2379E5.4030002@ehsco.com> Date: Wed, 03 Jul 2002 17:25:41 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers Subject: [Fwd: I-D ACTION:draft-hall-dns-datatypes-00.txt] Content-Type: multipart/mixed; boundary="------------010202010307070808090001" X-Spam-Status: No, hits=3.8 required=5.0 tests=TO_LOCALPART_EQ_REAL,EXCUSE_6,DOUBLE_CAPSWORD version=2.30 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------010202010307070808090001 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'd like to bring this up for discussion please. There are a handful of problems that this draft tries to address. The original problem which motivated this effort is that there isn't an easy way for a dual-mode (STD13 & IDN) name server to determine whether or not a particular eight-bit name is a binary name or an i18n name. If you read through draft-hall-dm-idns-00.txt (expired but around), you see this problem pretty clearly. The state machine falls apart when these names show up. The best way to solve the problem is to impose strong data-type rules on the underlying data such that there is no way for an A RR (for example) to have an eight-bit codepoint value in the STD13 namespace. Secondarily, the UCS character repertoire contains logical characters with a variety of encoded representation forms. There is no logical character for "octet value 0xHH" so there is no way to represent eight-bit octet values in the internationalized namespace. Well, we could hack something up with an extension or variation of \ddd but there are other secondary problems from that approach, and the best solution here (again) is to define strong data-type rules. Setting aside those two problems above, there is a general need to define strong data-types for the different domain names types and their associated RRs so that application protocols know what to do. There has been rampant confusion on what is valid for which purposes, and a big part of this draft attempts to clarify the confusing points. Along the same lines, this draft attempts to repair holes and conflicts in the specifications. It consolidates minimum length of a domain name to 1 character (conflicting data between 952 and 1035), maximum length of a hostname and domain name to 255 octets (forcing /etc/hosts to match), defines formal usage for the dot separator and requires longhand forms to accomodate its presence, extends the \nnn syntax to data-streams other than zone table storage, and so forth. If nothing else, this work should be done, even if the rest of it is malarky IYHO. Please read it and give your thoughts. BTW, half of the document is schema, references and general overhead, so it's not as large as it appears. Thanks -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ --------------010202010307070808090001 Content-Type: message/rfc822; name="I-D ACTION:draft-hall-dns-datatypes-00.txt" Content-Disposition: attachment; filename="I-D ACTION:draft-hall-dns-datatypes-00.txt" X-Mozilla-Status2: 00000000 Return-Path: Received: from loki.ietf.org ([132.151.1.177] verified) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP id 151667 for lists@EHSCO.COM; Wed, 03 Jul 2002 14:30:50 -0500 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA22039 for ietf-123-outbound.02@ietf.org; Wed, 3 Jul 2002 10:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA19417 for ; Wed, 3 Jul 2002 06:29:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03449 for ; Wed, 3 Jul 2002 06:28:39 -0400 (EDT) Message-Id: <200207031028.GAA03449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hall-dns-datatypes-00.txt Date: Wed, 03 Jul 2002 06:28:39 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name Data-Types Author(s) : E. Hall Filename : draft-hall-dns-datatypes-00.txt Pages : 39 Date : 02-Jul-02 This document defines syntax and structural rules for a namespace of internationalized domain names, and also clarifies the syntax and structural rules for the existing DNS namespace. Furthermore, this document defines syntax and structural rules for specific types of labels and domain names, and also defines usage rules for specific resource records within the domain name system. This document specifically does not describe any mechanisms for interacting with these namespaces, domain names or resource records, but instead focuses exclusively on the syntax and structural rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hall-dns-datatypes-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hall-dns-datatypes-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-hall-dns-datatypes-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: <20020702151138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hall-dns-datatypes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hall-dns-datatypes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151138.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------010202010307070808090001-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 18:55:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11423 for ; Wed, 3 Jul 2002 18:55:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PsnV-0008di-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 15:40:29 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17Psn0-0008bC-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 15:39:59 -0700 Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00148 for ; Wed, 3 Jul 2002 16:39:58 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GYP00HP32YLLE@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 16:39:58 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GYP00C112YKX9@mail.sun.net> for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 16:39:57 -0600 (MDT) Date: Wed, 03 Jul 2002 15:39:56 -0700 From: Alain Durand Subject: Re: (ngtrans) The reverse lookup issue In-reply-to: To: Christian Huitema Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Wednesday, July 3, 2002, at 11:59 AM, Christian Huitema wrote: > So, my question is, do we really need to invest in a reverse lookup DNS > tree for IPv6? Or should we not just "declare victory" and recognize > that reverse lookup has very little practical value? You might want to look at draft-durand-ngtrans-dns-issues-00.txt that tries to summarize some issues around DNS in IPv6 land and the discussion last week in DNSop mailing list about reverse lookups. - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 19:13:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12195 for ; Wed, 3 Jul 2002 19:13:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PtBS-0009eQ-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 16:05:14 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17PtAm-0009ce-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 16:04:32 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g63N4Kd24042; Wed, 3 Jul 2002 23:04:21 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g63N4PMP005384; Wed, 3 Jul 2002 18:04:25 -0500 (CDT) Date: Wed, 3 Jul 2002 18:04:25 -0500 Subject: Re: The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, Christian Huitema To: "Eric A. Hall" From: Ted Lemon In-Reply-To: <3D23756D.7020205@ehsco.com> Message-Id: <3832E7CC-8ED9-11D6-873D-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I would think that DDNS could handle the dynamic scenarios but perhaps I > don't understand the problem. How do you establish a security association between the DNS server for the reverse zone and the node with the IP address? This is a key management problem of epic proportions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 19:48:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13674 for ; Wed, 3 Jul 2002 19:48:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PtdM-000AnK-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 16:34:04 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17Ptd4-000Am2-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 16:33:46 -0700 From: Masataka Ohta Message-Id: <200207032322.IAA05283@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA05283; Thu, 4 Jul 2002 08:21:55 +0859 Subject: Re: The reverse lookup issue In-Reply-To: from Christian Huitema at "Jul 3, 2002 11:59:11 am" To: Christian Huitema Date: Thu, 4 Jul 2002 08:21:55 +0859 () CC: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Christian; > I am specially interested by the solution in the case of unmanaged > networks, such as a home network. Wrong. If a home network is unmanaged (by an ISP), it is not connected to the Internet and is not a problem. Instead, a home network can be wrongly managed. Any kind of problem can be caused by creative wrong management, which IETF can not forbid. IETF, instead, can write documents on dull ways of management and possibile consequences of the creativity. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 19:52:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13875 for ; Wed, 3 Jul 2002 19:52:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ptee-000Auo-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 16:35:24 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17PteX-000AtX-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 16:35:17 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g63NZCW28216; Wed, 3 Jul 2002 16:35:12 -0700 (PDT) From: Bill Manning Message-Id: <200207032335.g63NZCW28216@boreas.isi.edu> Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: from Bruce Campbell at "Jul 3, 2 11:53:07 pm" To: bruce.campbell@ripe.net (Bruce Campbell) Date: Wed, 3 Jul 2002 16:35:12 -0700 (PDT) Cc: louie@TransSys.COM, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As others have pointed out, the addressing structure maps the topology while the naming structure maps the administrative structure. Sometimes (rarely) they overlap. Most times they do not. My keys/certs are tied to the node name (bloat.isi.edu) and not to the IP address, which can and does change with some frequency. (any time the laptop moves). Cross-correlation is a good and useful thing. The claim about the maintaince of the in-addr tree vs the maintance of the forward tree are interesting. The last data that we collected on in-addr.arpa and the Mice/Men data on the forward tree indicates that the in-addr tree is actually better maintained... Go figure. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 20:34:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15720 for ; Wed, 3 Jul 2002 20:34:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PuTr-000DZH-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 17:28:19 -0700 Received: from alderaan.chagres.net ([216.223.236.235] helo=chagres.net) by psg.com with esmtp (Exim 3.36 #1) id 17PuTi-000DXp-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 17:28:11 -0700 Received: (qmail 2640 invoked from network); 4 Jul 2002 00:28:24 -0000 Received: from unknown (HELO laptoy) (jmbrown@chagres.net@216.223.236.249) by alderaan.chagres.net with RC4-MD5 encrypted SMTP; 4 Jul 2002 00:28:24 -0000 Reply-To: From: "John M. Brown" To: "Louis A. Mamakos" , "Christian Huitema" Cc: , Subject: RE: (ngtrans) The reverse lookup issue Date: Wed, 3 Jul 2002 18:27:29 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <200207031936.g63JaC0L035839@whizzo.transsys.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit yet if the host you are asking has been compromised then it could give back an invalid name. whereas the in-addr tree is typically managed one or more levels above the host, and often by a different party. thus two or more systems would have to be compromised. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Louis > A. Mamakos > Sent: Wednesday, July 03, 2002 1:36 PM > To: Christian Huitema > Cc: ngtrans@sunroof.eng.sun.com; namedroppers@ops.ietf.org > Subject: Re: (ngtrans) The reverse lookup issue > > > [ post by non-subscriber. with the massive amount of spam, > it is easy to > miss and therefore delete mis-posts. so fix subscription > addresses! ] > > > So, my question is, do we really need to invest in a > reverse lookup DNS > > tree for IPv6? Or should we not just "declare victory" > and recognize > > that reverse lookup has very little practical value? > > I think that about a decade ago (or so I it seems..) I > suggested that > we abandon the notion of using the DNS to do address->name lookups. > Rather, define a simple standard service where a host can be asked > what it thinks it's name is. In many cases, this does the "right > thing" in that you get a meaningful name at the time that the > address was allocated to someone (e.g., out of a DHCP pool or other > transient network connection.) > > Sure, you can't "trust" this name. Just like you can't really trust > the one in DNS PTR records, either. > > Or simply decide the practical value is small. > > louie > > > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 21:07:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17411 for ; Wed, 3 Jul 2002 21:07:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PuzW-000F4N-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 18:01:02 -0700 Received: from mail6.microsoft.com ([131.107.3.126]) by psg.com with esmtp (Exim 3.36 #1) id 17PuzO-000F4A-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 18:00:54 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 18:00:53 -0700 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Jul 2002 18:00:53 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Jul 2002 18:00:53 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 18:00:53 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 3 Jul 2002 18:00:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (ngtrans) The reverse lookup issue Date: Wed, 3 Jul 2002 18:00:51 -0700 Message-ID: Thread-Topic: (ngtrans) The reverse lookup issue Thread-Index: AcIi0RUZ/1B/c1/yQAyN411GKs/2ZwAIeXSw From: "Christian Huitema" To: "Paul Vixie" , "Louis A. Mamakos" Cc: , X-OriginalArrivalTime: 04 Jul 2002 01:00:51.0727 (UTC) FILETIME=[3DFFD1F0:01C222F6] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA17411 Reading this thread, there are three arguments for keeping the reverse lookup: 1) In enterprise networks, reverse lookups provide a way to identify the source of the traffic. 2) In general, it is better to have an information from a third party (network provider) than from the host itself, since the host may be compromised or mismanaged. 3) Some applications (e.g. SMTP servers) actually use reverse lookup to check that the name provided by the caller is not entirely bogus. My issues are mostly related to several IPv6 procedures that let the host configure its own address: automatic address configuration based on prefix advertised by the local routers, and transition procedures such as 6to4 that allow a router or a host to configure an IPv6 address prefix from an IPv4 address. So, what about the following: 1) In enterprise networks, it is possible to use dynamic DNS updates, thus meeting requirement #1. (Using the same procedure in consumer networks, or across domain boundaries, is much less likely.) 2) In consumer networks, the ISP will typically delegate a /48 or possibly /64 prefix to the consumer -- to a host or a gateway. The informative part (the third party information) is really only derived from this prefix allocation; everything else can be made up by the user. It is thus realistic to have the ISP enter a "catch-all" PTR record for the prefix, providing a reasonable response to a PTR query. (If we end up using dynamic DNS updates, the catch-all will only be used in prsence of less specific information). This is essentially the solution proposed in draft-durand-ngtrans-dns-issues-00.txt. 3) Applications such as SMTP relays may receive a generic record (*.example.net ?) as a response to their reverse lookup. There should be a way to compare this generic record to the name otherwise provided by the caller, in order to gain a modicum of control. (Indeed, one possibility is for the client app to first perform the reverse lookup itself, and then use the result in SMTP.) However, this leaves open the "auto-delegation" case, such as the 6to4 prefix. One possibility would be to have a generic record: *.2.0.0.2.ip6.arpa IN PTR host.6to4.net ... But that would not be terribly informative. Another possibility is to enter a set of NS & PTR records under .2.0.0.2.ip6.arpa that essentially mimic the in-addr.arpa tree, so that *.1.0.2.0.3.0.4.0.ip6.arpa yields the same value as 1.2.3.4.in-addr.arpa, possibly complemented by some "generic" name-part. A DNAME comes to mind, but let's not go there. Alternatively, one could program an hard-wired short-cut in DNS resolvers and possibly DNS servers as well. Does this make sense? -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 3 21:44:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19793 for ; Wed, 3 Jul 2002 21:44:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PvVZ-000GUm-00 for namedroppers-data@psg.com; Wed, 03 Jul 2002 18:34:09 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17PvVU-000GUa-00 for namedroppers@ops.ietf.org; Wed, 03 Jul 2002 18:34:04 -0700 From: Masataka Ohta Message-Id: <200207040116.KAA06441@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA06441; Thu, 4 Jul 2002 10:16:26 +0900 Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: from Christian Huitema at "Jul 3, 2002 06:00:51 pm" To: Christian Huitema Date: Thu, 4 Jul 2002 10:16:25 +0859 () CC: Paul Vixie , "Louis A. Mamakos" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Christian; > My issues are mostly related to several IPv6 procedures that let the > host configure its own address: automatic address configuration based on DHCP is the best possible for autoconfiguration. Any attempt beyond it is to make the Internet fool proof and your issue is creativity of fools having nothing specifically to do with reverse look up. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 03:37:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10529 for ; Thu, 4 Jul 2002 03:37:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q0s4-0000x6-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 00:17:44 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17Q0rz-0000wv-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 00:17:40 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 0A78B20F; Thu, 4 Jul 2002 00:17:39 -0700 (PDT) Date: Thu, 4 Jul 2002 00:17:38 -0700 From: David Terrell To: Michael Richardson Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020704001738.B516@pianosa.catch22.org> Reply-To: David Terrell References: <200207040153.g641rl1V014867@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200207040153.g641rl1V014867@marajade.sandelman.ottawa.on.ca>; from mcr@sandelman.ottawa.on.ca on Wed, Jul 03, 2002 at 09:53:47PM -0400 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:05AM up 2 days, 2:56, 17 users, load averages: 0.11, 0.30, 0.24 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Jul 03, 2002 at 09:53:47PM -0400, Michael Richardson wrote: > Precisely *this* has been proposed. > I can't recall if it was Keith Moore or Bill Manning that had code to do > exactly this using plug-ins to bind9. Keith wrote a draft that proposed several mechanisms and debated their reasonability. I implemented one suggestion (not perfectly) for bind9's sdb mechanism, that creates pseudoauthority records for 2002:abcd:efgh:: that point to 2002:abcd:efgh:magic-suffii. It is available here: http://meat.net/~dbt/code/rev6to4/ The other method (infer authority records from closest authority records in IPv4 in-addr tree) was implemented by Feico Dillema in his self-described DNSALG totd, available at http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html. The draft is expired, though I've placed a copy of it at meat.net/~dbt/code/rev6to4/draft-ietf-ngtrans-6to4-dns-00.txt. I do not have an archived copy of the -01 draft and it has expired. -- David Terrell | Step 1: "configure one system using your GUI" dbt@meat.net | Step 2: "now configure 1000 more" Nebcorp Prime Minister | - Casper H.S. Dik http://wwn.nebcorp.com | -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 09:15:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16775 for ; Thu, 4 Jul 2002 09:15:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q6Eh-0007Sl-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 06:01:27 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17Q6Ec-0007Rx-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 06:01:22 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA01631; Wed, 3 Jul 2002 18:29:20 -0400 Date: Wed, 3 Jul 2002 18:43:04 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Paul Vixie cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue In-Reply-To: <20020703202500.2676C28B6C@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This misuse of reverse DNS is probably the single best reason to abolish it altogether. Reverse DNS has no bearing on the location of parties responsible for IP addresses. ipv4-65-14-33-11.example.com gives no information, and just wastes time for those who have to create such silly entries, and waste the memory of nameservers that have to store these meaningless entries. --Dean On Wed, 3 Jul 2002, Paul Vixie wrote: > > So, my question is, do we really need to invest in a reverse lookup DNS > > tree for IPv6? Or should we not just "declare victory" and recognize > > that reverse lookup has very little practical value? > > the practical value goes above and beyond those you've mentioned. i expect > that many services, especially e-mail but also any other abusable service, > will continue to reject connections for which no "reverse lookup" is known. > > we live on an increasingly irresponsible internet. my root name server gets > more than a gigabyte of request traffic every day just from 10.0.0.0/8. we > all get a huge amount of spam. > > anything that makes it harder to locate a responsible party for a given IP > address (whether v4, v6, v8, or whatever) is automatically, unarguably "bad." > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 09:18:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16816 for ; Thu, 4 Jul 2002 09:17:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q6FB-0007TU-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 06:01:57 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17Q6Es-0007TC-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 06:01:38 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id VAA04130; Wed, 3 Jul 2002 21:45:09 -0400 Date: Wed, 3 Jul 2002 21:58:58 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Christian Huitema cc: Paul Vixie , "Louis A. Mamakos" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: RE: (ngtrans) The reverse lookup issue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Jul 2002, Christian Huitema wrote: > Reading this thread, there are three arguments for keeping the reverse > lookup: > > 1) In enterprise networks, reverse lookups provide a way to identify the > source of the traffic. Do you mean within the organizations network? If so, this is better handled by a enterprise whois database of internal address assignments rather than in-addr. In many very large organizations, there is no central database. For example, when I worked for Hitachi, I depended on the internic (subsequently ARIN) whois server to figure out which Hitachi org had what address blocks. There were a lot! And back then only 3 people were even remotely concerned about the issue--myself, a guy in Oklahoma, and another guy in Japan. That was worldwide, for the 7th largest company in the world. Most divisions were only concerned about the connection to the divisions they transfered files with, and had no concern with global connectivity. The trouble with in-addr is that too much information is given out, or one must run private nameservers, in which case too much information may be given out to employees. > 2) In general, it is better to have an information from a third party > (network provider) than from the host itself, since the host may be > compromised or mismanaged. ISP's frequently don't give out any information on who the customer is. The inverse lookups are usually just the ip address encoded by a script that generates names from IP addresses. As I said before, this is meaningless, and a waste of time, Nameserver memory, and bandwidth. > 3) Some applications (e.g. SMTP servers) actually use reverse lookup to > check that the name provided by the caller is not entirely bogus. Most don't work this way. Those that do address checking merely check if the reverse answer matches somewhat the corresponding forward. The sort of check you describe would fail when the SMTP server is handling multiple virtual domains, since in that case you want to put in the virtual domain sending mail rather than the reverse of the IP address. The virtual domain can clue which customer is sending the mail. The IP address is known already. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 10:07:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17673 for ; Thu, 4 Jul 2002 10:07:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q71j-0008sC-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 06:52:07 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17Q71b-0008rz-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 06:51:59 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 53CDD137F04; Thu, 4 Jul 2002 06:51:58 -0700 (PDT) To: Dean Anderson Cc: Paul Vixie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue In-Reply-To: Message from Dean Anderson of "Wed, 03 Jul 2002 18:43:04 EDT." Date: Thu, 04 Jul 2002 06:51:58 -0700 Message-ID: <8014.1025790718@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Dean" == Dean Anderson writes: Dean> This misuse of reverse DNS is probably the single best Dean> reason to abolish it altogether. Some applications and protocols rely on reverse lookups. The BSD line printer daemon and r- protocols for example. Nobody would disagree that these things are somewhat broken by relying on reverse lookups for authentication and access control. But it's a fact of life that they exist and are widely used. They can't be wished away, much as we might like them to. Security software like SSH and TCPwrappers can use reverse lookups. How do you propose to replace/modify them if reverse DNS is killed? Dean> Reverse DNS has no bearing on the location of parties Dean> responsible for IP addresses. It is quite often a more reliable indicator -- if only by establishing where the reverse tree delegations end -- than anything else. ISPs often fail to update the RIR whois database when they hand out addresses to their customers and delegate the reverse tree to them. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 10:09:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16776 for ; Thu, 4 Jul 2002 09:15:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q6Ey-0007TJ-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 06:01:44 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17Q6Eo-0007T3-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 06:01:34 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA01624; Wed, 3 Jul 2002 18:26:05 -0400 Date: Wed, 3 Jul 2002 18:39:49 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Paul Vixie cc: "Louis A. Mamakos" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <20020703202834.3EA1628B6C@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The party on either the forward or reverse end isn't definitely known, due to the potential for spoofing. You can't trust dns, ever. All of the reverse dns mythology is based on the idea that you can somehow trust reverse dns differently than forward dns, and the huge assumption that if the answers match, then you can _ASSUME_ they are correct, when the stark truth is that you can't trust either of them because both can be spoofed. The only use I have for reverse DNS is to make traceroutes pretty. That's all. Nothing more than that. Reverse DNS should only be allowed for routers, to make traceroutes pretty. Using reverse dns for anything else opens one up to .rhosts type of security problems. There is no avoiding it, short of dnssec procedures, and then only on the zones secured that way. Indeed, I think you still can't trust reverse DNS, since the resolver doesn't know if the reverse zone is actually trustworthy, only that its been "secured". If it proves vulnerable to attack, then once again you can't trust DNS--ever--for anything more pressing than the prettiness of traceroutes. "You can't place any trust in an answer given by someone you don't know." --Dean On Wed, 3 Jul 2002, Paul Vixie wrote: > > Sure, you can't "trust" this name. Just like you can't really trust > > the one in DNS PTR records, either. > > using dns you get higher "trust splay" -- the party you're distrusting > about the reverse mapping is different from (and is probably differently > trustable) than the party you're distrusting about the forward mapping. > > that's a good thing. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 10:34:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18216 for ; Thu, 4 Jul 2002 10:34:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q7Zt-0009gu-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 07:27:25 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17Q7Zl-0009gH-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 07:27:17 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9C57E44EF; Thu, 4 Jul 2002 16:27:14 +0200 (CEST) Date: Thu, 4 Jul 2002 16:27:14 +0200 From: bert hubert To: Jim Reid Cc: Dean Anderson , Paul Vixie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue Message-ID: <20020704142714.GB12345@outpost.ds9a.nl> References: <8014.1025790718@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8014.1025790718@shell.nominum.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Jul 04, 2002 at 06:51:58AM -0700, Jim Reid wrote: > >>>>> "Dean" == Dean Anderson writes: > > Dean> This misuse of reverse DNS is probably the single best > Dean> reason to abolish it altogether. > > Some applications and protocols rely on reverse lookups. The BSD line > printer daemon and r- protocols for example. Nobody would disagree > that these things are somewhat broken by relying on reverse lookups > for authentication and access control. But it's a fact of life that > they exist and are widely used. They can't be wished away, much as we > might like them to. Security software like SSH and TCPwrappers can > use reverse lookups. How do you propose to replace/modify them if > reverse DNS is killed? Reverse DNS is already going the way of the dodo. I see no reason to explicitly deprecate IPv6 reverse though. Already it is becoming hard to explain many ISPs what this reverse thing is or why it is good. Trying to make RFCs that do nothing but deprecate existing practice will only put the IETF (further) out of synch with the real world by putting all people using reverse DNS in a position where they are 'violating' an rfc! Such behaviour causes inflation, leading to a devaluation of the power of an RFC. Just leaving out reverse from newer RFCs which obsolete earlier ones amounts to the same thing. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 10:46:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18693 for ; Thu, 4 Jul 2002 10:46:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q7lW-0009wa-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 07:39:26 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Q7lA-0009vh-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 07:39:04 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17Q7lA-00012f-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 07:39:04 -0700 Message-ID: <000e01c2233c$722b3780$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <200207040153.g641rl1V014867@marajade.sandelman.ottawa.on.ca> From: "Jeroen Massar" To: "'Michael Richardson'" Cc: , Subject: RE: (ngtrans) The reverse lookup issue Date: Thu, 4 Jul 2002 11:23:21 +0200 X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,GAPPY_TEXT,DOUBLE_CAPSWORD,PORN_3 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Michael Richardson wrote: A bit off topic to the rest, but I just have to mention it; > I am profoundly unhappy with the notion that these networks are in anyway different. > Citizens need control over their reverse maps. Period. I agree to the fact that any person should be able to set up his/her/it's/... own reverse *BUT* seeing the fact that there are 'kiddos' coming up with things like found in: http://www.garion.org/spamcalc/sorted.txt excerpt and apologies for the bad language used: 8<------------- 3432 - NA.PULA.SUJO.IN.CUR.SI.INTRE.MASELE.PANA.FACI.CA.LEANA.LU.VIOREL.DIN.DEA L.bakan.OrG 3073 - Screw.me.if.I.m.wrong.but.you.want.to.kiss.Dropsu.because.i.m.ircop.de 2759 - gov.edu.cc.com.ws.net.info.ro.sk.dk.co.uk.jp.ca.spy.org.ru 2449 - drama.vietii.mele.prima.gagica.a.mea.avea.o.fata.de.desfacator.de.bere.s poof.de 2082 - emma.and.weirdo.sitting.in.a.tree.d.o.i.n.g.it.doggiestyle.nu. 2020 - Dropsu.e.ala.cu.sufletul.mare.dar.dont.asl.me.becuz.i.am.hijack.de 1743 - nicu.plus.aneta.egal.pedofilie.si.aneta.plus.viorel.din.deal.egal.zoofil ie.ipv4.de 1649 - has.no.bandwidth.at.all.so.he.doesnt.belong.to.the.internet-elite.cx 1620 - roulez.and.feeva.is.the.king.of.the.turks.on.the.ircnetwork.de 1589 - i.put.my.foot.in.shit.and.now.it.is.a.shitfoot.com 1394 - IcH.wEiSs.IcH.SoLLte.GeHeN.UnD.IcH.WiLL.Ja.AuCh.AbErS.GehT.NeT 1296 - just.because.i.stink.doesnt.mean.i.am.a.heavy.drinker.net 1282 - fuck.with.me.and.get.anthrax.because.im.from.the.penismafia.com ------------->8 I don't really think it's always 'good' to allow it. Though I have to admit that most of the crap seen on the list comes from "ISP's" and generally so called 'vhost' providers. They simply consume IPv4 space to make 'nice' reverses. In IPv6 IRCNet this is somewhat controlled due to the fact that most opers kline on sight (also in v4 space lately) and many tunnelbrokers watch their reverses so that these weird things don't pop up, also see http://www.ipng.nl/index.php3?page=dnsspam.html And yes it's mainly an IRC thing that people want to have good-looking hostnames. Yes reverses are good, but they are there for _administrative_ ease and for a teeny verification step, not for the fun of some 12 year olds. Fortunatly we got RFC1178 already mentioning this, unfortunatly there is no way of forcing/making IPspace owners abide these rules. And with dynamic updates it isn't quite easy to check it unless one logs the updates. My suggestion would be to have reverses and maintain them, but for endusers, and yes I am also one of them, only allow reverse changes through some form of adminstrative step. Of course this al depends on the ISP and the ISP itself can go 'wrong' very easily (as said with all those vhost providers), but I don't think we should have to worry or even look at reverses for the last /64 assigned to a cablemodem in terms of reverse dns management. Another thing we could be looking at is saying that, as the last 64 bits should usually be on the same link that there must be a reverse for the first 64 bits and there should/can be reverses for the hostpart. Currently many SMTP servers will do a forward/reverse check and refuse service if there is a mismatch, we could say that if a host doesn't have a reverse it simply isn't set up correctly and probably should be sending SMTP either and refuse service, redirecting it to a local smtp which is set up by the ISP with correct ACL's and a matching forward/reverse. This in turn would kind of block spam too. >From reverse-dnsspam to UCE ;) Greets, Jeroen -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 11:44:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19850 for ; Thu, 4 Jul 2002 11:44:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q8VR-000B6C-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 08:26:53 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17Q8V7-000B5g-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 08:26:34 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 83858137F02; Thu, 4 Jul 2002 08:26:33 -0700 (PDT) To: Jeroen Massar Cc: Michael Richardson , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Message from "Jeroen Massar" of "Thu, 04 Jul 2002 11:23:21 +0200." <000e01c2233c$722b3780$534510ac@cyan> Date: Thu, 04 Jul 2002 08:26:33 -0700 Message-ID: <8702.1025796393@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Jeroen" == Jeroen Massar writes: Jeroen> I agree to the fact that any person should be able to set Jeroen> up his/her/it's/... own reverse *BUT* seeing the fact Jeroen> that there are 'kiddos' coming up with things like found Jeroen> in: http://www.garion.org/spamcalc/sorted.txt excerpt and Jeroen> apologies for the bad language used: .... long list of garbage deleted .... I fail to understand the point you're making. So what if kiddies are putting stupid or obscene names in the reverse tree? There's nothing stopping them. Or doing that in any other (forward?) zones they own. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 13:12:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21429 for ; Thu, 4 Jul 2002 13:11:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Q9zu-000DW5-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 10:02:26 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17Q9yt-000DUJ-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 10:01:23 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g64H19d26577; Thu, 4 Jul 2002 17:01:09 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g64H1DMP005468; Thu, 4 Jul 2002 12:01:13 -0500 (CDT) Date: Thu, 4 Jul 2002 12:01:13 -0500 Subject: Re: The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, Paul Vixie To: Dean Anderson From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Reverse DNS has no bearing on the location of parties responsible for IP > addresses. ipv4-65-14-33-11.example.com gives no information, and just > wastes time for those who have to create such silly entries, and waste the > memory of nameservers that have to store these meaningless entries. It tells you that the user (maybe) lives at example.com. You can traipse up the in-addr chain looking for an SOA record, and see who's responsible for the zone. Yes, "ipv4-65-14-33-11.example.com" doesn't say anything specific about the end user, but it is not completely worthless. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 14:55:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22886 for ; Thu, 4 Jul 2002 14:55:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QBXt-000GAv-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 11:41:37 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17QBXo-000GAk-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 11:41:32 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA02142; Thu, 4 Jul 2002 14:41:31 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA02523; Thu, 4 Jul 2002 14:41:28 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA14409; Thu, 4 Jul 2002 14:41:27 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id OAA13028; Thu, 4 Jul 2002 14:41:25 -0400 Subject: Re: (ngtrans) The reverse lookup issue From: Greg Hudson To: Dean Anderson Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 04 Jul 2002 14:41:25 -0400 Message-Id: <1025808085.1185.4.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-07-03 at 18:39, Dean Anderson wrote: > The only use I have for reverse DNS is to make traceroutes pretty. That's > all. Nothing more than that. Reverse DNS should only be allowed for > routers, to make traceroutes pretty. What special claim does traceroute have on looking pretty? Why shouldn't web server logs or wtmp files get to look pretty too? I'd advocate a more general statement of this position. Reverse DNS is useful for humans--useful enough that I think it's worth preserving. It is not especially useful for automated processing, since the answer you get back isn't very robust. (You could do a forward lookup of the result you get back, and see if that forward lookup is protected with DNSSEC, but in the short and medium term you're not going to get very many positives.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 17:45:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25564 for ; Thu, 4 Jul 2002 17:45:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QEC7-000Kad-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 14:31:19 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17QEBv-000KaQ-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 14:31:07 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id A7EB01BA; Thu, 4 Jul 2002 14:31:06 -0700 (PDT) Date: Thu, 4 Jul 2002 14:31:06 -0700 From: David Terrell To: Michael Richardson Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020704143106.A18583@pianosa.catch22.org> Reply-To: David Terrell References: <200207040153.g641rl1V014867@marajade.sandelman.ottawa.on.ca> <20020704001738.B516@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020704001738.B516@pianosa.catch22.org>; from dbt@meat.net on Thu, Jul 04, 2002 at 12:17:38AM -0700 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 2:30PM up 2 days, 17:21, 30 users, load averages: 0.24, 0.24, 0.24 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Jul 04, 2002 at 12:17:38AM -0700, David Terrell wrote: > The draft is expired, though I've placed a copy of it at > meat.net/~dbt/code/rev6to4/draft-ietf-ngtrans-6to4-dns-00.txt. > I do not have an archived copy of the -01 draft and it has > expired. (there never was any -01 draft, I am in error here. Odd. Sorry for any confusion.) -- David Terrell | "The Court understands fully why licensing has many Nebcorp Prime Minister | advantages for software publishers. However, this dbt@meat.net | preference does not alter the Court's analysis that http://wwn.nebcorp.com/ | the substance of the transaction at issue here is a sale and not a license." - Judge Dean Pregerson, Softman v Adobe. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 19:03:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26705 for ; Thu, 4 Jul 2002 19:03:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QFRh-000MOr-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 15:51:29 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17QFRa-000MOY-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 15:51:23 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D93254B22; Fri, 5 Jul 2002 07:51:14 +0900 (JST) To: Michael Richardson Cc: "Jeroen Massar" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-reply-to: mcr's message of Thu, 04 Jul 2002 18:25:58 -0400. <200207042226.g64MPw1V018013@marajade.sandelman.ottawa.on.ca> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (ngtrans) The reverse lookup issue From: itojun@iijlab.net Date: Fri, 05 Jul 2002 07:51:14 +0900 Message-Id: <20020704225114.D93254B22@coconut.itojun.org> X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Yes reverses are good, but they are there for _administrative_ ease and > > for a teeny > > verification step, not for the fun of some 12 year olds. > I strongly disagree. > DNSSEC signed reverses are extremely useful. > Please see draft-richardson-ipsec-opportunistic-09.txt. DNSSEC-signed reverse solves some of the problem, but not all. solves: - guarantees that noone spoofs PTR records, i.e. ensures integrity between the records held by authoritative nameserver and the response you've got - address-to-key mapping and secure distribution of those keys, like those used in opportuniistic encryption does not solve: - integrity between forward and reverse DNS records (btw, with scoped IPv6 address, it's impossible) itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 19:07:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27368 for ; Thu, 4 Jul 2002 19:07:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QFaV-000Mbj-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 16:00:35 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17QFaA-000Maz-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 16:00:14 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17QFaA-000EdY-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 16:00:14 -0700 Message-Id: <200207042226.g64MPw1V018013@marajade.sandelman.ottawa.on.ca> In-reply-to: Your message of "Thu, 04 Jul 2002 11:23:21 +0200." <000e01c2233c$722b3780$534510ac@cyan> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: "Jeroen Massar" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Date: Thu, 04 Jul 2002 18:25:58 -0400 From: Michael Richardson X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD,LINES_OF_YELLING, PGP_SIGNATURE version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jeroen" == Jeroen Massar writes: Jeroen> Michael Richardson wrote: Jeroen> A bit off topic to the rest, but I just have to mention it; >> I am profoundly unhappy with the notion that these networks are in Jeroen> anyway different. >> Citizens need control over their reverse maps. Period. Jeroen> I agree to the fact that any person should be able to set up Jeroen> his/her/it's/... Jeroen> own reverse *BUT* seeing the fact that there are 'kiddos' coming up with Jeroen> things like found in: http://www.garion.org/spamcalc/sorted.txt Jeroen> excerpt and apologies for the bad language used: And, so what? Does your software break? Fix it. Are you the internet censor? Jeroen> Yes reverses are good, but they are there for _administrative_ ease and Jeroen> for a teeny Jeroen> verification step, not for the fun of some 12 year olds. I strongly disagree. DNSSEC signed reverses are extremely useful. Please see draft-richardson-ipsec-opportunistic-09.txt. Jeroen> My suggestion would be to have reverses and maintain them, but for Jeroen> endusers, and Jeroen> yes I am also one of them, only allow reverse changes through some form Jeroen> of Jeroen> adminstrative step. Of course this al depends on the ISP and the ISP Why? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPSTLToqHRg3pndX9AQGvNgP8DL/qYoZr44MsTmOgUCiHzuyxN+TH7kiB gV5/xZyQJgNIrfF22/yzmlyP5zKwwNWZqxqnYjDsOGly7zJ7bXNyqL5xYokuKPWw IV/G/qQseErxxQhUqkWGcWGI+GgOHh+np7SBZqnESbNBaRDn2rfGvH6AMwfvuNm0 ZEG0qNWrQK8= =hU57 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 19:09:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27401 for ; Thu, 4 Jul 2002 19:09:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QFbg-000MeU-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 16:01:48 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17QFbb-000MeF-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 16:01:43 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 7547D1E6; Thu, 4 Jul 2002 16:01:42 -0700 (PDT) Date: Thu, 4 Jul 2002 16:01:42 -0700 From: David Terrell To: Dean Anderson Cc: Paul Vixie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, Christian Huitema , "Louis A. Mamakos" Subject: Re: The reverse lookup issue Message-ID: <20020704160142.C516@pianosa.catch22.org> Reply-To: David Terrell References: <20020703202500.2676C28B6C@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dean@av8.com on Wed, Jul 03, 2002 at 06:43:04PM -0400 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 9:51AM up 2 days, 12:42, 17 users, load averages: 0.16, 0.19, 0.17 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Jul 03, 2002 at 06:43:04PM -0400, Dean Anderson wrote: > This misuse of reverse DNS is probably the single best reason to abolish > it altogether. > > Reverse DNS has no bearing on the location of parties responsible for IP > addresses. ipv4-65-14-33-11.example.com gives no information, and just > wastes time for those who have to create such silly entries, and waste the > memory of nameservers that have to store these meaningless entries. So, reverse DNS is useless because people can put useless information into it. On Wed, Jul 03, 2002 at 09:58:58PM -0400, Dean Anderson wrote: > On Wed, 3 Jul 2002, Christian Huitema wrote: > Do you mean within the organizations network? If so, this is better > handled by a enterprise whois database of internal address assignments > rather than in-addr. In many very large organizations, there is no > central database. For example, when I worked for Hitachi, I depended on > the internic (subsequently ARIN) whois server to figure out which Hitachi > org had what address blocks. There were a lot! And back then only 3 people > were even remotely concerned about the issue--myself, a guy in Oklahoma, > and another guy in Japan. That was worldwide, for the 7th largest company > in the world. Most divisions were only concerned about the connection to > the divisions they transfered files with, and had no concern with global > connectivity. In my organization, I use reverse DNS to track address assignments to individual hosts and to identify the responsible admin for a service quickly and easily. It is a useful tool. > The trouble with in-addr is that too much information is given out, or one > must run private nameservers, in which case too much information may be > given out to employees. Ok, in-addr gives out too much information. Which is it? > > 2) In general, it is better to have an information from a third party > > (network provider) than from the host itself, since the host may be > > compromised or mismanaged. > > ISP's frequently don't give out any information on who the customer > is. The inverse lookups are usually just the ip address encoded by a > script that generates names from IP addresses. As I said before, this is > meaningless, and a waste of time, Nameserver memory, and bandwidth. My home machine has proper reverse DNS. This makes it easy for people who are having a problem with it to contact me directly instead of having to go through my ISP to find out who I am. I consider that a feature. If I did not want that level of accountability, I would have my ISP reset reverse DNS to some generic default. > > 3) Some applications (e.g. SMTP servers) actually use reverse lookup to > > check that the name provided by the caller is not entirely bogus. > > Most don't work this way. Those that do address checking merely check if > the reverse answer matches somewhat the corresponding forward. The sort > of check you describe would fail when the SMTP server is handling multiple > virtual domains, since in that case you want to put in the virtual domain > sending mail rather than the reverse of the IP address. The virtual domain > can clue which customer is sending the mail. The IP address is known > already. He's not talking about MAIL FROM, rather the name provided for EHLO/HELO. reverse DNS is an easy, loggable way of identifying the responsible party for an address. Sure, it's not always accurate but neither is anything else on this internet. whois can't support that kind of load, nor should it. -- David Terrell | "the only part about medicinal marijuana that Prime Minister, Nebcorp | bothers me is that, when I started chemo, all of dbt@meat.net | my children and grandchildren told me they could http://wwn.nebcorp.com/ | get some for me if I needed it." -mrw's grandfather -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 21:40:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29245 for ; Thu, 4 Jul 2002 21:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QHi1-000PyZ-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 18:16:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17QHhl-000Py2-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 18:16:13 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17QHhl-000IFy-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 18:16:13 -0700 Message-Id: <200207050054.g650su1V029076@marajade.sandelman.ottawa.on.ca> In-reply-to: Your message of "Fri, 05 Jul 2002 07:51:14 +0900." <20020704225114.D93254B22@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Date: Thu, 04 Jul 2002 20:54:55 -0400 From: Michael Richardson X-Spam-Status: No, hits=-8.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,LINES_OF_YELLING,PGP_SIGNATURE version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] -----BEGIN PGP SIGNED MESSAGE----- >>>>> "itojun" == itojun writes: >> > Yes reverses are good, but they are there for _administrative_ ease and >> > for a teeny >> > verification step, not for the fun of some 12 year olds. >> I strongly disagree. >> DNSSEC signed reverses are extremely useful. >> Please see draft-richardson-ipsec-opportunistic-09.txt. itojun> DNSSEC-signed reverse solves some of the problem, but not all. itojun> solves: itojun> - guarantees that noone spoofs PTR records, i.e. ensures integrity itojun> between the records held by authoritative nameserver and the response itojun> you've got itojun> - address-to-key mapping and secure distribution of those keys, like itojun> those used in opportuniistic encryption itojun> does not solve: itojun> - integrity between forward and reverse DNS records itojun> (btw, with scoped IPv6 address, it's impossible) By this, you mean that: host1.example.com -> 3ffe::00c0:ffee -> host2.example.com ? Yes, we have to continue checking this problem. Since both AAAA and PTR records are 1:n mappings, we will always have this problem. Getting rid of reverse zones simply guarantees that we have no useful diagnostic information. Yes, reverse zone for scoped IPv6 addresses is a local matter. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPSTuXoqHRg3pndX9AQFg6AP/fZBU1yXRm5S+GsjABjNJ+svv3wt1+jdd S4qco4Z9Tf7fyLCSdbe/FIGB6eUt93FBzU0G87zQKqxUadEXZVyGtwPuuzTUrASL +N7TNzatu+B01oQpFbPOCXxI+A7tDLurt1+YAPjI0LJ9jePwkcpCW+adxODxd6rY ReOUrngfB2g= =/rD/ -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 4 22:59:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01680 for ; Thu, 4 Jul 2002 22:59:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QJ68-0002By-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 19:45:28 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17QJ63-0002Bn-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 19:45:23 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id WAA17712; Thu, 4 Jul 2002 22:45:21 -0400 (EDT) Received: from [208.58.216.253] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA10324; Thu, 4 Jul 2002 22:44:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <397F45EA-8EA4-11D6-873D-00039367340A@nominum.com> References: <397F45EA-8EA4-11D6-873D-00039367340A@nominum.com> Date: Thu, 4 Jul 2002 22:44:51 -0400 To: Ted Lemon , Edward Lewis From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Cc: "Andy W. Barclay" , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.5 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,DOUBLE_CAPSWORD, RCVD_IN_OSIRUSOFT_COM version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:45 AM -0500 7/3/02, Ted Lemon wrote: >Maybe this is a stupid question, but in what way does putting application key >records into the DNS make it more complicated? Does it *need* to be more >complicated, or is this a bug in the specification that could be fixed? First I'll present the obvious but rather weak argument - just to get it out of the way. KEY RR's are going to be large - so if we stuff a couple of them at one domain name (one KEY RR set) we will either trip into TCP or need EDNS0 to enlarge the packets. (Of course this is also true for CERT RR's - even more so.) Okay, let's get serious now... The complexity that I am concerned with is architectural and administrative. If there is plan to use DNSSEC to protect the delivery of keys to application elements, the problem is that we are imposing on application the security model being used by DNS. The security model for DNS should be tailored to the needs of DNS. (If we plan to allow DNS to address the security of applications, then we'd need to make sure that the security model of DNS accounts for that.) The administrative complexity is the extra burden placed on administrators to enter the keys into the DNS. Okay, CERT RR's are just as hard to enter, but a KEY RR does not allow for the final check that a CERT RR does (CRL's, more flexible validation process). Looking at the architectural complexity, keep in mind that DNS is not a layer under an application. DNS itself is an application. As such DNS has a security model (albeit one barely spoken or written), one that needs to address the use of caches and, well, not too much more. DNSSEC is designed to make sure that what ever the rightful (authoritative) administrator enters into the primary master server is what is seen by resolvers. (Secondaries are covered too by TSIG, which I consider to be part of DNSSEC. Differences of opinion on this are just terminology, which isn't all that important in this message.) Applications are going to have other security needs. SSH needs to make sure that the client has an account and can "beat the challenge" along with tunneling and encrypting traffic. Email needs to make sure stored messages can be decrypted at a later point. What I mean is that applications have different needs - amongst themselves and in contrast to DNS. If we were to integrate the security models of applications to DNS then we'd have to deal with a 1:many relationship. But there's another danger, one that has me more concerned and is why I stopped pursuing SIKED work soon after the BoF. By tying DNS security to application security we are "putting our eggs in one basket." If DNSSEC is broken, applications relying on KEY RRS only protected by DNSSEC also melt down. I.e., the complexity of integrating security models can have a catastrophic impact. Now, about the administrative complexity. If an administrator is handed a KEY RR (okay, perhaps I should say APPKEY RR), there's a decision point. Does the administrator check the validity of the key? If so, this is a new requirement on DNS administration. If not, then the applications are still at risk. What if a CERT RR is required? Then the application is "forced" to think about an authentication/validation process external to DNS. Yeah, self-signed CERTS can be put in the DNS and we basically have KEY's again, but then that's the fault of a lazy application design. Now, to take a trip on a red herring/side bar, a situation came up during a DS RR workshop held yesterday (one reason my response is delayed). We discovered that the snapshot code being tested truncated the TTL of the validated record set to the shortest TTL of any set used (KEY, DS) to validate it. This means that when any part of the data used to validate the answer expires, the date also expires. Good or bad? Good in that it means that the cache will only have data that is currently valid. But is that the goal of DNSSEC? Not in my opinion, DNSSEC only makes sure that the answer arrives "good." DNS has never been concerned with real-time correctness, and I don't think we should start now. Why? Well, if TTL truncation remains, then once the root key TTL's to 0 in the server (or pick your favorite TLD), all data in the cache immediately dies - requiring more DNS queries to fly through the network. Nowadays, if the NS for .org expires in "my" cache, at least ietf.org will last until it's ttl hits 0. Morale of the story - 1) trying to inflict security that benefits applications that need "freshly" secured data harms the DNS through more traffic. 2) tying TTL and SIG validity periods is a bad idea (but seem to keep popping up). (TTL - database coherency, sig validity - crypto health. Don't confuse them. Yes, the signer should truncate the ttl to the validity, but not the cache's. I'd expound further, but this isn't why I'm writing.) The point of the sidebar is that trying to make DNS more acceptable to applications in the security sense can have a negative impact on DNS itself. (And, if the application needs freshly checked data - let the application do it.) ...let's see, my main points are that the complexity is hidden in the interaction of the security models and needs of DNS and applications and that we really do want to avoid the "eggs in one basket" syndrome. One last thing, I am curious to see how this pans out with opportunistic keying. But this message is long enough as it is... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 00:24:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02768 for ; Fri, 5 Jul 2002 00:24:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QKOP-0004Cj-00 for namedroppers-data@psg.com; Thu, 04 Jul 2002 21:08:25 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17QKOI-0004CY-00 for namedroppers@ops.ietf.org; Thu, 04 Jul 2002 21:08:18 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g6548Eg23678; Thu, 4 Jul 2002 21:08:14 -0700 (PDT) From: Bill Manning Message-Id: <200207050408.g6548Eg23678@boreas.isi.edu> Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: from Edward Lewis at "Jul 4, 2 10:44:51 pm" To: edlewis@arin.net (Edward Lewis) Date: Thu, 4 Jul 2002 21:08:14 -0700 (PDT) Cc: Ted.Lemon@nominum.com, edlewis@arin.net, abarclay@unixpeople.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit it is wise to retain the distinction that using DNS to distribute appkeys may not be the smartest thing, for the reasons mentioned. I think that the current snapshot is deadon to expire data. wrt OE, the keying material is being used to build IPSEC "tunnels" so having a key tied to the IP address being considered for use is a good thing. And the DNS looks like the "best" way to push them around. % ...let's see, my main points are that the complexity is hidden in the % interaction of the security models and needs of DNS and applications % and that we really do want to avoid the "eggs in one basket" syndrome. % % One last thing, I am curious to see how this pans out with % opportunistic keying. But this message is long enough as it is... % -- % -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- % Edward Lewis +1-703-227-9854 % ARIN Research Engineer % % % -- % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. % archive: % -- --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 07:19:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18987 for ; Fri, 5 Jul 2002 07:19:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QQqV-000DH2-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 04:01:51 -0700 Received: from tms001bb.han.telia.se ([131.115.230.132]) by psg.com with esmtp (Exim 3.36 #1) id 17QQpp-000DFp-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 04:01:09 -0700 Received: from TMS031MB.tcad.telia.se ([131.115.230.162]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 5 Jul 2002 13:01:07 +0200 content-class: urn:content-classes:message Subject: RE: (ngtrans) Re: The reverse lookup issue MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 5 Jul 2002 13:01:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE807E10F@TMS031MB.tcad.telia.se> Thread-Topic: (ngtrans) Re: The reverse lookup issue Thread-Index: AcIjrwPqd2L9hVswQv+YJh/NywHznAAYh+VQ From: To: Cc: X-OriginalArrivalTime: 05 Jul 2002 11:01:07.0634 (UTC) FILETIME=[4390D920:01C22413] X-Spam-Status: No, hits=-0.7 required=5.0 tests=NO_REAL_NAME,SUPERLONG_LINE version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA18987 > > ISP's frequently don't give out any information on who the customer > > is. The inverse lookups are usually just the ip address encoded by a > > script that generates names from IP addresses. As I said > before, this is > > meaningless, and a waste of time, Nameserver memory, and bandwidth. > > My home machine has proper reverse DNS. This makes it easy > for people who are having a problem with it to contact me > directly instead of having to go through my ISP to find out > who I am. I consider that a feature. If I did not want that > level of accountability, I would have my ISP reset reverse DNS > to some generic default. > if my home machine does not have proper reverse dns, because my isp is not providing this service, can i still have a mail server (with domain, dns, etc) and be able to _actually_ send mail through that server? or, is all mail where reverse dns don't match treated as spam and filtered out. jasminko -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 07:56:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20329 for ; Fri, 5 Jul 2002 07:56:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QRcQ-000ENE-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 04:51:22 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17QRcE-000EMw-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 04:51:10 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20031; Fri, 5 Jul 2002 07:49:48 -0400 (EDT) Message-Id: <200207051149.HAA20031@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: Representing IPv6 addresses in DNS to Informational RFC Date: Fri, 05 Jul 2002 07:49:47 -0400 X-Spam-Status: No, hits=0.3 required=5.0 tests=X_NOT_PRESENT,TO_MALFORMED,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved publication of the following Internet-Drafts as Informational RFCs: o Representing IPv6 addresses in DNS o Tradeoffs in DNS support for IPv6 In addition, the IESG has reclassified RFCs 2673 and 2874 from Proposed Standard to Experimental. These documents are the products of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary With the publication of RFC's 1886 "DNS Extensions to support IP version 6" (aka AAAA) and 2874 "DNS Extensions to Support IPv6 Address Aggregation and Renumbering" (aka A6/DNAME), the IETF standardized two different ways to store IPv6 address information in the DNS. This has led to confusion and conflicts on which one to deploy. RFC 2874 defines the A6 RR, which stores IPv6 addresses not as a single RR, but as a chain of RRs. A6 RRs were designed to simplify DNS aspects of renumbering sites. In addition, RFC 2874 defined a DNAME RR, which could be used for management of the reverse tree. This protocol action reclassifies RFC 2874 as Experimental. RFC 2673 "Binary Labels in the Domain Name System" defines a new DNS label intended to solve the problem of storing binary data and delegating authority on arbitrary boundaries. This format was to be used in the reverse tree for mapping IPv6 addresses via PTR RRs back into domain names. Since the development of RFC 2673 it has been learned that deployment of a new type is difficult since DNS servers that do not support bit labels reject queries containing bit labels as being malformed. The community has also indicated that this new label type is not needed for mapping reverse addresses. This protocol action reclassifies RFC 2673 as Experimental. With these actions, the the IETF is recommending that the DNS mechanisms to support IPv6 stay essentially the same as those already in use with IPv4 today. Working Group Summary The discussions surrounding the use of A6, Binary Labels, and DNAME to support IPv6 have been long and divisive. Some in the community believe that the DNS extensions (and especially A6) provide needed facilities to ease the burden of site renumbering, and that if not deployed today, we will not have an opportuntity again in the future that can displace the installed base. Others feel that sufficient benefits of the DNS extensions have not been demonstrated, and that their complexity and potential dangers do not justify widespread use and deployment. The (rough) consensus of the community is that the A6, Binary Labels and DNAME DNS extensions should not be widely deployed for use with IPv6 at this time, and that IPv6 should continue to use the same basic mechanisms as IPv4 uses today. Protocol Quality This protocol has been reviewed for the IESG by Erik Nordmark and Thomas Narten. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 08:26:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21585 for ; Fri, 5 Jul 2002 08:26:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QS1r-000F4v-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 05:17:39 -0700 Received: from [202.28.97.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17QS1T-000F3j-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 05:17:15 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g65CH6I02245; Fri, 5 Jul 2002 19:17:07 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g65CGTf13219; Fri, 5 Jul 2002 19:16:29 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Christian Huitema" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jul 2002 19:16:29 +0700 Message-ID: <13217.1025871389@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 3 Jul 2002 11:59:11 -0700 From: "Christian Huitema" Message-ID: | So, my question is, do we really need to invest in a reverse lookup DNS | tree for IPv6? Or should we not just "declare victory" and recognize | that reverse lookup has very little practical value? There's actually an intermediate position. That is, we keep the reverse lookup tree, but we just make it clear that we no longer expect people to populate it fully. Or if they like, not to populate it at all. Applications can go on doing lookups there if they like, and if you're an ISP and want traceroutes through your net to give out names, then you can fill in the PTR records (on traceroutes I do over v4 today, I think I get about 50% of the routes with names, of which about 75% give any useful information at all). If you're a user of an application that for some odd reason actually needs the data, then you will add the entries to the DNS, because you actually need the things. But we just end the pretense that every allocated address is going to have a PTR record somewhere. It isn't true now, people just don't do it (and as has been pointed out, often when they do, the result conveys no useful information - that 1.2.3.4 maps to 1-2-3-4.example.com tells us even less than is available from whois). paul@vix.com said: | using dns you get higher "trust splay" -- the party you're distrusting | about the reverse mapping is different from (and is probably | differently trustable) than the party you're distrusting about the | forward mapping. With IPv6 (and increasingly with IPv4) this is simply not generally true. The information from the DNS is originating at the host that created it in either case - with the DNS there's the extra step of an intermediate agent involved, but all it is going is conveying to whoever asks is the information the host told it to give out. That's just the same as if the end-host were asked directly. The only difference is that the DNS is perhaps more likely to be there to answer the question sometime after the host has vanished - I used to think this was a valuable property, but I have re-considered, it just isn't worth the pain. ehall@ehsco.com said: | Yes, it's useful and necessary to a variety of validation processes, | especially when used with double lookups (check PTR and A both ways). Since you certainly cannot reply on anything in a PTR record not just being supplied by the host itself, you may as well just ask the host what its name is - even better, do that as part of the protocol of interest, rather than as some extra add on. The validation any of this provides was useful only in the days when some human manually typed in all of the names of the hosts on his/her network. That just isn't what happens any more. bmanning@ISI.EDU said: | The last data | that we collected on in-addr.arpa and the Mice/Men data on | the forward tree indicates that the in-addr tree is actually | better maintained... Go figure. This is not surprising at all. The forward tree is allocated to anyone at all, with no requirement for a "DNS operators licence" before a domain will be handed out. A forward domain is a practical necessity for most operations on the internet, and is also used as a vanity piece (and squatting), where whether the domain works or not isn't relevant, only that it exists (but in the domains that matter, existence isn't allowed without delegation, but delegation accuracy isn't verified). All this leads to lots and lots of breakage. On the other hand, in-addr.arpa domains aren't required for almost anything. That tends to mean that they're only set up by people who have some kind of clue what they're doing. Consequently it isn't at all surprising that what exists out there is better looked after than the forward domains. If anything, this is evidence for lowering the expectation that reverse lookups will succeed - just because it is providing evidence that this is the current state of the world. mcr@sandelman.ottawa.on.ca said: | Getting rid of reverse zones simply guarantees that we have no | useful diagnostic information. No, you still have the addresses. Those are more useful for most diagnostics anyway. As the percentage of addresses which map to meaningful names drops further and further (and it is doing so, no question about it) the futility of attempting to pretend that people who haven't filled in the reverse tree are somehow derelict in their duty will become more and more obvious. Although the message I sent a while ago to dnsop read as if I was suggesting that we should delete the IP6.{INT,ARPA} trees completely, that isn't my position (it wasn't phrased as well as it should have been). Leave the things for anyone who really wants to use them. Just stop trying to tell people that they *have* to use them. Personally I'm sick of doing lots of work just so all the rest of you get prettier log files... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 09:12:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23378 for ; Fri, 5 Jul 2002 09:12:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QSkU-000GFw-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 06:03:46 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17QSkL-000GEk-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 06:03:37 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id WAA19374; Thu, 4 Jul 2002 22:12:27 -0400 Date: Thu, 4 Jul 2002 22:26:45 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Jim Reid cc: Paul Vixie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue In-Reply-To: <8014.1025790718@shell.nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 4 Jul 2002, Jim Reid wrote: > >>>>> "Dean" == Dean Anderson writes: > > Dean> This misuse of reverse DNS is probably the single best > Dean> reason to abolish it altogether. > > Some applications and protocols rely on reverse lookups. The BSD line > printer daemon and r- protocols for example. Nobody would disagree > that these things are somewhat broken by relying on reverse lookups > for authentication and access control. But it's a fact of life that > they exist and are widely used. They can't be wished away, much as we > might like them to. Security software like SSH and TCPwrappers can > use reverse lookups. How do you propose to replace/modify them if > reverse DNS is killed? Easy. This can already be turned off in ssh and tcpwrappers. Everyone will just have to turn it off. The printer daemon and the rcmds will have to have ip addresses in the .rhosts, hosts.equiv, and hosts.lpd files. Actually, I think this will work without code changes. > Dean> Reverse DNS has no bearing on the location of parties > Dean> responsible for IP addresses. > > It is quite often a more reliable indicator -- if only by establishing > where the reverse tree delegations end -- than anything else. ISPs > often fail to update the RIR whois database when they hand out > addresses to their customers and delegate the reverse tree to them. More reliable than RIR? I haven't heard of RIR spoofing. But I think you are talking maintenance. Maintenance of reverse trees was what got this going... And maintenance is an operational issue that is made easier or harder by standards. Removing reliance on reverse lookups might make it easier for ISPs to keep up better whois records, which are made public or not made public depending on the ISP's policies. Also, I'm not saying that reverse lookups haven't ever been useful. But the utility is such that one cannot depend on it. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 10:53:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28000 for ; Fri, 5 Jul 2002 10:53:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QUJn-000If9-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 07:44:19 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17QUJg-000Iex-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 07:44:12 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17QUJg-000Dsg-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 07:44:12 -0700 Message-ID: <20020705093716.GB58122@NLnetLabs.nl> Mail-Followup-To: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: Fri, 5 Jul 2002 11:37:16 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: small comment on DS-08 draft X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] hello, In section 2.2 "Protocol Change": ...If a query contains the OK bit, a server returning a referral for the delegation MUST... Change to ...If a query contains the OK bit, a server or cache, returning a referral for the delegation MUST... By adding the "or cache" one implies that a DS cache MUST discriminate between the parent NXT and child NXT and that it should return the correct one. regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 10:53:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28027 for ; Fri, 5 Jul 2002 10:53:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QUHi-000IcF-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 07:42:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17QUHd-000Ic3-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 07:42:05 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17QUHd-000Doi-00; Fri, 05 Jul 2002 07:42:05 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Woodcock Cc: namedroppers Subject: Re: support for draft-ietf-dnsop-serverid-00.txt References: Message-Id: Date: Fri, 05 Jul 2002 07:42:05 -0700 X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> given the use of anycast, one *really* wants to know the >> identity of the server, as in host, responded to a query. >> and not some subsequent query, but the one that gave one >> the bad answer. > Okay, so excuse the DNS naivete, but how would one deal with that > issue? return the unique ip address of the server as additional info with every query? change 2181 and go v6-style and have the source ip of the response be that unique address. thought required. but, if you're gonna do anycast for other than caches, and it would be good even for caches, then some hack like this AND full dnssec are pretty much mandatory or you'll never clean up the mess. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 11:59:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01296 for ; Fri, 5 Jul 2002 11:59:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QVIB-000KG7-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 08:46:43 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17QVI2-000KFC-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 08:46:35 -0700 From: Masataka Ohta Message-Id: <200207051531.AAA13565@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA13565; Sat, 6 Jul 2002 00:31:08 +0900 Subject: Re: The reverse lookup issue In-Reply-To: <13217.1025871389@munnari.OZ.AU> from Robert Elz at "Jul 5, 2002 07:16:29 pm" To: Robert Elz Date: Sat, 6 Jul 2002 00:31:07 +0859 () CC: Christian Huitema , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kre; > It isn't true now, people just don't do > it (and as has been pointed out, often when they do, the result conveys > no useful information - that 1.2.3.4 maps to 1-2-3-4.example.com tells > us even less than is available from whois). > All this leads to lots and lots of breakage. Surely, with wrong management, there can be lots of breakage. But, who, are you saying, will suffer from the breakage? Those under the wrong management? Or? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 12:26:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02853 for ; Fri, 5 Jul 2002 12:26:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QVhA-000Kqw-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 09:12:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17QVh0-000Kql-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 09:12:22 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17QVh0-000GO9-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 09:12:22 -0700 Message-Id: <200207051153.g65BrUWk001896@marajade.sandelman.ottawa.on.ca> In-reply-to: Your message of "Thu, 04 Jul 2002 00:17:38 PDT." <20020704001738.B516@pianosa.catch22.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: David Terrell cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Date: Fri, 05 Jul 2002 07:53:30 -0400 From: Michael Richardson X-Spam-Status: No, hits=-8.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,LINES_OF_YELLING,PGP_SIGNATURE version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] -----BEGIN PGP SIGNED MESSAGE----- >>>>> "David" == David Terrell writes: David> On Wed, Jul 03, 2002 at 09:53:47PM -0400, Michael Richardson wrote: >> Precisely *this* has been proposed. >> I can't recall if it was Keith Moore or Bill Manning that had code to do >> exactly this using plug-ins to bind9. Thank you for posting with the details. David> Keith wrote a draft that proposed several mechanisms and debated David> their reasonability. I implemented one suggestion (not perfectly) David> for bind9's sdb mechanism, that creates pseudoauthority records for David> 2002:abcd:efgh:: that point to 2002:abcd:efgh:magic-suffii. It is David> available here: http://meat.net/~dbt/code/rev6to4/ David> The other method (infer authority records from closest authority David> records in IPv4 in-addr tree) was implemented by Feico Dillema in David> his self-described DNSALG totd, available at David> http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html. I didn't realize that these were seperate suggestions - we do DNSALG, and if we find nothing, we try the magic-suffii. Although now that I think about it, the likelyhood of there being any NS records at the leaf of the IPv4 tree is pretty much zero. Is there a plan to go forward with any of this? It simply seems like the right solution to me. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPSWIuIqHRg3pndX9AQFbywQAkS/J/I+CTKa2sdmRU2LCPwsOdxSabFJ1 GxTHlfrEw5tzn9qk4ygwJBmYUrStBLaHU4uBD+b00l7/4VI/492HpM+n9WEWp+WR 7oJvBp3RRKGpWWR1gH8Z1v+mBO8DEtL/fDWkpoR/vyglR9p09OtkMTwUvqQJrrhK 2IxOHGEAqQE= =4ycf -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 12:26:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02872 for ; Fri, 5 Jul 2002 12:26:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QVk6-000KwB-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 09:15:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17QVjy-000Kw0-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 09:15:26 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17QVjx-000GTS-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 09:15:26 -0700 Message-ID: <000601c2243c$442f3f60$420d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <13217.1025871389@munnari.OZ.AU> From: "Jeroen Massar" To: "'Robert Elz'" , "'Christian Huitema'" Cc: , Subject: RE: (ngtrans) Re: The reverse lookup issue Date: Fri, 5 Jul 2002 17:54:37 +0200 X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Robert Elz wrote: > There's actually an intermediate position. That is, we keep the > reverse lookup tree, but we just make it clear that we no longer > expect people to populate it fully. Or if they like, not to > populate it at all. There are currently a few 'applications' for PTR's/reverse lookups: * traceroute reverse But not everyone fills in 'useful' data anymore, and with v6 that will probably end too. Especially as you probably won't be letting a router do a dynamic DNS update(1) or something :) * IRC Which really is the *only* reason most people want a PTR. "Look mummy I look cool on IRC". Especially with the dnsspamming, and yes I know the people who sell domain names or provide dns services like that a lot, it's their wallet getting filled, but unfortunatly in the v4 world every irc-vhost takes one IP of the stack that could have been used for another user's end2end connection. But maybe that's a better question for e2e and not for people providing dns services... * Logging purposes If one logs into a box with SSH, the server will reverse+forward check the hostname, and use that in the logs and 'who' which is much clearer as 3FFE:8114:2000:240:290:27FF:FE24:C19F for instance. These loggings also are done for other protocols like FTP and SMTP. Some SMTP's refuse service if the reverse+forward doesn't match, though that doesn't happen a lot. Summing up, the reverses are just cosmetical and usually bogus unless you check reverse&forward to be the same and even then: what's the use of 4.3.2.1 PTR 1-2-3-4.example.net or in v6 space: 4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.ip6.arpa /int PTR 1234.1234.1234.1234.... :) Requiring them to be there is 'insane', as we'll probably end up with the above, though some ISP's are known to use a big dictionary to fill them out, which is nice but still isn't usefull ;) Having the possibility to resolve them can be 'cosmetically nice' though there isn't any other advantage. If one need to know where an IP is at use the whois, but then there are always people saying that it wasn't 'designed' for that purpose. But it is still the single most 'secure' place of finding out the owner and the abuse/contact addresses of an IP, which is probably where IP lookups are mostly used for: reporting problems. There are currently (afaik) two ways of handling 'reverse' lookups: - PTR record in DNS - icmp6 message to the host. The first one (PTR) can be 'protected' from evil doing, the second one can be easily spoofed and doesn't really proove a thing as it can be invented by the admin of the box. But it's more usual for the host to know it's own/real/in-use hostname than for DNS to know it. (1) = Dynamic updates, will you really be going to let every user of your ISP update the reverses? In a company thats probably very different, if you got a nice tightly controlled environment. But then again, ofcourse we got http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html ;) Greets, Jeroen -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 12:57:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04079 for ; Fri, 5 Jul 2002 12:57:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QWHo-000Lso-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 09:50:24 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17QWH9-000Lrt-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 09:49:43 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id CB2761E6; Fri, 5 Jul 2002 09:49:41 -0700 (PDT) Date: Fri, 5 Jul 2002 09:49:41 -0700 From: David Terrell To: Jeroen Massar Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Re: The reverse lookup issue Message-ID: <20020705094941.A6889@pianosa.catch22.org> Reply-To: David Terrell References: <13217.1025871389@munnari.OZ.AU> <000601c2243c$442f3f60$420d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000601c2243c$442f3f60$420d640a@unfix.org>; from jeroen@unfix.org on Fri, Jul 05, 2002 at 05:54:37PM +0200 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 9:17AM up 3 days, 12:08, 28 users, load averages: 0.27, 0.30, 0.23 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jul 05, 2002 at 05:54:37PM +0200, Jeroen Massar wrote: > * Logging purposes > If one logs into a box with SSH, the server will reverse+forward check > the hostname, and use > that in the logs and 'who' which is much clearer as > 3FFE:8114:2000:240:290:27FF:FE24:C19F > for instance. These loggings also are done for other protocols like FTP > and SMTP. Some SMTP's > refuse service if the reverse+forward doesn't match, though that doesn't > happen a lot. I hate having IPv6 literals in [wu]tmp. With the emphasis that IPv6 is putting on renumberability, the person with an address today may not be the same person with it tomorrow. If we can get the reverse DNS tree to follow addressing (which is reasonably possible, even if we don't have DNAME in the reverse tree) then your snapshot of who had the address two weeks ago when you're looking at your logs can be more useful than checking whois or whatnot. > Summing up, the reverses are just cosmetical and usually bogus unless > you check reverse&forward > to be the same and even then: what's the use of 4.3.2.1 PTR > 1-2-3-4.example.net or in v6 space: > 4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.4.3.2.1.ip6.arpa > /int PTR 1234.1234.1234.1234.... :) > > Requiring them to be there is 'insane', as we'll probably end up with > the above, though some ISP's > are known to use a big dictionary to fill them out, which is nice but > still isn't usefull ;) > Having the possibility to resolve them can be 'cosmetically nice' though > there isn't any other advantage. > If one need to know where an IP is at use the whois, but then there are > always people saying that > it wasn't 'designed' for that purpose. But it is still the single most > 'secure' place of finding out the owner > and the abuse/contact addresses of an IP, which is probably where IP > lookups are mostly used for: reporting problems. whois can't give me a name to log. whois already can't handle the constant load from spam harvester runs. > There are currently (afaik) two ways of handling 'reverse' lookups: > - PTR record in DNS > - icmp6 message to the host. > > The first one (PTR) can be 'protected' from evil doing, the second one > can be easily spoofed and > doesn't really proove a thing as it can be invented by the admin of the > box. > But it's more usual for the host to know it's own/real/in-use hostname > than for DNS to know it. For the machines you're complaining about with regard to having lame reverse (1-2-3-4.example.net), they're far less likely to have a locally configured name that exists in the DNS. This may change as things like ddns become more popular. -- David Terrell | "To increase the hype, I'm gonna release a bunch Nebcorp PM | of BLT variants (NetBLT, FreeBLT, BLT386, etc) dbt@meat.net | and create artificial rivalries." wwn.nebcorp.com | - Brian Swetland (www.openblt.org) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 12:59:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04192 for ; Fri, 5 Jul 2002 12:59:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QWMK-000M1P-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 09:55:04 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17QWMA-000M0p-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 09:54:54 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25315; Fri, 5 Jul 2002 12:54:28 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13999; Fri, 5 Jul 2002 12:54:27 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA22700; Fri, 5 Jul 2002 12:54:26 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA08871; Fri, 5 Jul 2002 12:54:25 -0400 (EDT) To: "Jeroen Massar" Cc: "'Robert Elz'" , "'Christian Huitema'" , , Subject: Re: (ngtrans) Re: The reverse lookup issue References: <000601c2243c$442f3f60$420d640a@unfix.org> From: Derek Atkins Date: 05 Jul 2002 12:54:25 -0400 In-Reply-To: <000601c2243c$442f3f60$420d640a@unfix.org> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Jeroen Massar" writes: > (1) = Dynamic updates, will you really be going to let every user of > your ISP update the reverses? No, but the ISP trust's its own DHCP server to update its reverse domain (which may involve updating a reverse-tree deleagation). Note that the client does not need to update the reverse tree itself; it can provide its DNS hostname to the DHCP server and the DHCP server updates the reverse tree. > In a company thats probably very different, if you got a nice tightly > controlled environment. > But then again, ofcourse we got > http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html ;) Personally, I find the reverse tree both useful in my every day work and also I can see a number of future uses, such as binding keys to IP addresses. From an IPsec perspective, all I know is that I want to send a packet to host X (where X is some IP Address), and I need to key that connection. This requires either certificates with IP addresses or DNS lookups based on IP Address. I certainly prefer the latter case, because generally certificates are based on the FQDN, not the IP Address. If I want to talk to 1.2.3.4 and get back a certificate claiming to be for secure.host.net, how do I know I'm talking to the right machine? OTOH, if I can query DNS for "4.3.2.1.in-addr.arpa. IN ", which is DNSSec-protected, then I have a higher assurance that I'm actually talking to the host I think I am. > Greets, > Jeroen -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 13:22:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05211 for ; Fri, 5 Jul 2002 13:22:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QWfV-000MXY-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 10:14:53 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17QWeS-000MVX-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 10:13:49 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 674631E6; Fri, 5 Jul 2002 10:13:43 -0700 (PDT) Date: Fri, 5 Jul 2002 10:13:43 -0700 From: David Terrell To: Jasminko.W.Mulahusic@telia.se Cc: namedroppers@ops.ietf.org Subject: Re: (ngtrans) Re: The reverse lookup issue Message-ID: <20020705101343.A24771@pianosa.catch22.org> Reply-To: David Terrell References: <7B64D9FB62EB42449683BA51E9AB2AE807E10F@TMS031MB.tcad.telia.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7B64D9FB62EB42449683BA51E9AB2AE807E10F@TMS031MB.tcad.telia.se>; from Jasminko.W.Mulahusic@telia.se on Fri, Jul 05, 2002 at 01:01:07PM +0200 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 10:12AM up 3 days, 13:03, 37 users, load averages: 0.44, 0.24, 0.23 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jul 05, 2002 at 01:01:07PM +0200, Jasminko.W.Mulahusic@telia.se wrote: > > > > ISP's frequently don't give out any information on who the customer > > > is. The inverse lookups are usually just the ip address encoded by a > > > script that generates names from IP addresses. As I said > > before, this is > > > meaningless, and a waste of time, Nameserver memory, and bandwidth. > > > > My home machine has proper reverse DNS. This makes it easy > > for people who are having a problem with it to contact me > > directly instead of having to go through my ISP to find out > > who I am. I consider that a feature. If I did not want that > > level of accountability, I would have my ISP reset reverse DNS > > to some generic default. > > if my home machine does not have proper reverse dns, because my > isp is not providing this service, can i still have a mail server > (with domain, dns, etc) and be able to _actually_ send mail through > that server? or, is all mail where reverse dns don't match treated > as spam and filtered out. I don't think many people are left who believe that reverse dns can be used as a policy enforcement engine, but it can and should be used for logging purposes. (answer: your mail gets through). -- David Terrell | "The war on drugs supports terror. If you support dbt@meat.net | the war on drugs, you support terror too." Nebcorp PM | - Jacob Sullum, Reason Magazine wwn.nebcorp.com | http://reason.com/sullum/020802.shtml -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 13:22:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05230 for ; Fri, 5 Jul 2002 13:22:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QWgD-000MYg-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 10:15:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17QWee-000MWB-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 10:14:00 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17QWee-000I7V-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 10:14:00 -0700 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 5 Jul 2002 10:06:53 -0700 (PDT) From: Bill Woodcock To: Randy Bush cc: namedroppers Subject: Re: support for draft-ietf-dnsop-serverid-00.txt X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > return the unique ip address of the server as additional info with > every query? Yes, but as I asked, is there any way of gluing the additional info back together with the response, after the fact, in the client's cache, if you actually need the data? In so far as I can see, additional info is only useful if you're able to see the packet in flight on the wire. > change 2181 and go v6-style and have the source ip of > the response be that unique address. I can think of a lot more utility for that one, and it opens up room for quite a bit of additional functionality in resolvers in the future, but it also opens a big box of potential security problems, which may not be fixable without rendering the protocol more complex, which would be too great a price to pay. > but, if you're gonna do anycast for other than caches, and it would > be good even for caches, then some hack like this AND full dnssec > are pretty much mandatory or you'll never clean up the mess. Yeah, if DNSSEC is mandatory, that takes care of it. I think I like the combination of DNSSEC and the server using a source address of its choosing, which the resolver could then optionally use for future queries. -Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 13:45:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06294 for ; Fri, 5 Jul 2002 13:45:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QX4a-000NFs-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 10:40:48 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17QX41-000NEQ-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 10:40:13 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g65HbOd29873; Fri, 5 Jul 2002 17:37:24 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g65HbTMP005625; Fri, 5 Jul 2002 12:37:29 -0500 (CDT) Date: Fri, 5 Jul 2002 12:37:29 -0500 Subject: Re: (ngtrans) Re: The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: , , "'Christian Huitema'" , "'Robert Elz'" To: "Jeroen Massar" From: Ted Lemon In-Reply-To: <000601c2243c$442f3f60$420d640a@unfix.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > (1) = Dynamic updates, will you really be going to let every user of > your ISP update the reverses? > In a company thats probably very different, if you got a nice tightly > controlled environment. > But then again, ofcourse we got > http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html ;) If you are doing stateful addrconf, DNS updates are done by the DHCP server, not the client, so this isn't a problem. Of course, you have to accept the name the client provides, or make one up, but this isn't a big problem either - if you don't want to do that, don't. It is my impression that populating PTR records hasn't been considered a requirement for some time now. The reason we do it is so that our users can successfully interoperate with people who insist on it. An IETF mandate is not going to eliminate people who insist on it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 5 17:00:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17549 for ; Fri, 5 Jul 2002 17:00:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17QZrH-0001MT-00 for namedroppers-data@psg.com; Fri, 05 Jul 2002 13:39:15 -0700 Received: from gw.gbch.net ([203.143.238.93]) by psg.com with smtp (Exim 3.36 #1) id 17QZrC-0001MI-00 for namedroppers@ops.ietf.org; Fri, 05 Jul 2002 13:39:10 -0700 Received: (qmail 57173 invoked by uid 1001); 6 Jul 2002 06:39:04 +1000 X-Posted-By: GJB-Post 2.26 06-May-2002 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Uptime: 2 days, 12:36 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Sat, 06 Jul 2002 06:39:04 +1000 From: Greg Black To: namedroppers@ops.ietf.org Subject: Re: (ngtrans) Re: The reverse lookup issue References: <7B64D9FB62EB42449683BA51E9AB2AE807E10F@TMS031MB.tcad.telia.se> <20020705101343.A24771@pianosa.catch22.org> In-reply-to: <20020705101343.A24771@pianosa.catch22.org> of Fri, 05 Jul 2002 10:13:43 MST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Terrell wrote: | On Fri, Jul 05, 2002 at 01:01:07PM +0200, Jasminko.W.Mulahusic@telia.se wrote: | > | > if my home machine does not have proper reverse dns, because my | > isp is not providing this service, can i still have a mail server | > (with domain, dns, etc) and be able to _actually_ send mail through | > that server? or, is all mail where reverse dns don't match treated | > as spam and filtered out. | | I don't think many people are left who believe that reverse dns can | be used as a policy enforcement engine, but it can and should be used | for logging purposes. | | (answer: your mail gets through). Better answer: your mail gets through most of the time. There are people out there who block mail from hosts without reverse DNS and there are even people out there who will block mail from xyz.example.com if its reverse gives abc.example.com -- I think those people are misguided, but I encounter them several times a year and have to accommodate them. In your case, you'd have to relay through your ISP's mail server to send mail to the people who would otherwise block you. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 7 07:12:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19172 for ; Sun, 7 Jul 2002 07:12:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17R9aP-0007D3-00 for namedroppers-data@psg.com; Sun, 07 Jul 2002 03:48:13 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17R9aK-0007CU-00 for namedroppers@ops.ietf.org; Sun, 07 Jul 2002 03:48:08 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 1AFC222E; Sun, 7 Jul 2002 03:48:07 -0700 (PDT) Date: Sun, 7 Jul 2002 03:48:07 -0700 From: David Terrell To: Toshi Yamasaki Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020707034806.A15169@pianosa.catch22.org> Reply-To: David Terrell References: <014e01c2259e$91442d20$e4ff240a@ty> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <014e01c2259e$91442d20$e4ff240a@ty>; from t.yamasaki@ntt.com on Sun, Jul 07, 2002 at 07:10:44PM +0900 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 3:40AM up 5 days, 6:31, 26 users, load averages: 0.21, 0.19, 0.17 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Jul 07, 2002 at 07:10:44PM +0900, Toshi Yamasaki wrote: > > 2) 3rd party may want to identify the source of traffic to complain about > spam or abuse, not necessarily per host but per /48. What 3rd party want is > not the FQDN but the contact (tech-c or admin-c) of the source, per /48. > Whois db is enough to get the contact. One justification behind TCP wrappers paranoid mode (require reverse, require that reverse and forward match) is that whois data can easily become stale, but tcp wrappers will enforce that reverse DNS will at least identify someone responsible for the domain (because forward matches). I like being able to identify the source of traffic in my logfiles without having to run whois against every single entry. This becomes more crucial with IPv6 (addresses are harder to remember and identify easily), not less. I do not think that deprecating the reverse tree is warranted or acceptable. -- David Terrell | "To increase the hype, I'm gonna release a bunch Nebcorp PM | of BLT variants (NetBLT, FreeBLT, BLT386, etc) dbt@meat.net | and create artificial rivalries." wwn.nebcorp.com | - Brian Swetland (www.openblt.org) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 7 11:05:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22661 for ; Sun, 7 Jul 2002 11:05:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RDLy-000GE1-00 for namedroppers-data@psg.com; Sun, 07 Jul 2002 07:49:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17RDLu-000GDo-00 for namedroppers@ops.ietf.org; Sun, 07 Jul 2002 07:49:30 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17RDLu-0009Gg-00 for namedroppers@ops.ietf.org; Sun, 07 Jul 2002 07:49:30 -0700 Message-ID: <014e01c2259e$91442d20$e4ff240a@ty> References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Toshi Yamasaki" To: "Christian Huitema" , "Paul Vixie" , "Louis A. Mamakos" Cc: , Subject: Re: (ngtrans) The reverse lookup issue Date: Sun, 7 Jul 2002 19:10:44 +0900 X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] As one of the commercial IPv4/IPv6 service operators, I have almost the same issues as Huitema has, and am feeling that reverse lookup might NOT be NECESSARY in both IPv4 and IPv6 enviroment. 1) Site (or ISP) admins may often want to identify the source of traffic per host. Reverse lookup is one of the good ways to do so, but there are several other good ways and what method to use is none of 3rd party's business. 2) 3rd party may want to identify the source of traffic to complain about spam or abuse, not necessarily per host but per /48. What 3rd party want is not the FQDN but the contact (tech-c or admin-c) of the source, per /48. Whois db is enough to get the contact. 3) Reverse lookup has been being used by MTA and public FTP sites as a simple authentication or a method, but it's not an enough method for authentication. 4) If we assume (or hope) IPv6 be deployed to everyone including residential users who doesn't care about technical issues, we shouldn't force end-users about technical managements which is NOT NECESSARY. So, I'd say that ISPs should delegate responsibility to manage the reverse lookup zone, IF the CUSTOMERs REQUESTE, but shouldn't force them to be delagated the zones and maintain them. I know it's better that reverse lookups are maintained by all end-users correctly, but tell me, somebody, the reasons why it is NECESSARY. > Reading this thread, there are three arguments for keeping the reverse > lookup: > > 1) In enterprise networks, reverse lookups provide a way to identify the > source of the traffic. > > 2) In general, it is better to have an information from a third party > (network provider) than from the host itself, since the host may be > compromised or mismanaged. > > 3) Some applications (e.g. SMTP servers) actually use reverse lookup to > check that the name provided by the caller is not entirely bogus. > > My issues are mostly related to several IPv6 procedures that let the > host configure its own address: automatic address configuration based on > prefix advertised by the local routers, and transition procedures such > as 6to4 that allow a router or a host to configure an IPv6 address > prefix from an IPv4 address. So, what about the following: > > 1) In enterprise networks, it is possible to use dynamic DNS updates, > thus meeting requirement #1. (Using the same procedure in consumer > networks, or across domain boundaries, is much less likely.) > > 2) In consumer networks, the ISP will typically delegate a /48 or > possibly /64 prefix to the consumer -- to a host or a gateway. The > informative part (the third party information) is really only derived > from this prefix allocation; everything else can be made up by the user. > It is thus realistic to have the ISP enter a "catch-all" PTR record for > the prefix, providing a reasonable response to a PTR query. (If we end > up using dynamic DNS updates, the catch-all will only be used in prsence > of less specific information). This is essentially the solution proposed > in draft-durand-ngtrans-dns-issues-00.txt. > > 3) Applications such as SMTP relays may receive a generic record > (*.example.net ?) as a response to their reverse lookup. There should be > a way to compare this generic record to the name otherwise provided by > the caller, in order to gain a modicum of control. (Indeed, one > possibility is for the client app to first perform the reverse lookup > itself, and then use the result in SMTP.) > > However, this leaves open the "auto-delegation" case, such as the 6to4 > prefix. One possibility would be to have a generic record: > *.2.0.0.2.ip6.arpa IN PTR host.6to4.net > ... But that would not be terribly informative. > > Another possibility is to enter a set of NS & PTR records under > .2.0.0.2.ip6.arpa that essentially mimic the in-addr.arpa tree, so that > *.1.0.2.0.3.0.4.0.ip6.arpa yields the same value as > 1.2.3.4.in-addr.arpa, possibly complemented by some "generic" name-part. > A DNAME comes to mind, but let's not go there. Alternatively, one could > program an hard-wired short-cut in DNS resolvers and possibly DNS > servers as well. > > Does this make sense? > > -- Christian Huitema > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 7 13:12:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26871 for ; Sun, 7 Jul 2002 13:12:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RFPE-000Jmw-00 for namedroppers-data@psg.com; Sun, 07 Jul 2002 10:01:04 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17RFP9-000Jml-00 for namedroppers@ops.ietf.org; Sun, 07 Jul 2002 10:00:59 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g67H0id05650; Sun, 7 Jul 2002 17:00:44 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g67H0nMP006210; Sun, 7 Jul 2002 12:00:49 -0500 (CDT) Date: Sun, 7 Jul 2002 12:00:48 -0500 Subject: Re: (ngtrans) The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Christian Huitema" , "Paul Vixie" , "Louis A. Mamakos" , , To: "Toshi Yamasaki" From: Ted Lemon In-Reply-To: <014e01c2259e$91442d20$e4ff240a@ty> Message-Id: <160E7A84-91CB-11D6-8575-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I know it's better that reverse lookups are maintained by all end-users > correctly, but tell me, somebody, the reasons why it is NECESSARY. I don't think anybody's asserting that it _is_ necessary. The question is, how do you do it if you want to do it? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 7 19:24:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10997 for ; Sun, 7 Jul 2002 19:24:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RL60-0007fR-00 for namedroppers-data@psg.com; Sun, 07 Jul 2002 16:05:36 -0700 Received: from bdsl.66.12.174.102.gte.net ([66.12.174.102] helo=mail.digitalmarketplace.com) by psg.com with esmtp (Exim 3.36 #1) id 17RL5m-0007fA-00 for namedroppers@ops.ietf.org; Sun, 07 Jul 2002 16:05:22 -0700 Received: from win2kdev ([208.3.65.193]) by mail.digitalmarketplace.com with Microsoft SMTPSVC(5.5.1877.197.19); Sun, 7 Jul 2002 16:42:53 -0700 Reply-To: From: "Jason Coombs" To: "Ted Lemon" , "Eric A. Hall" Cc: , , "Christian Huitema" Subject: RE: The reverse lookup issue Date: Sun, 7 Jul 2002 13:13:40 -1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3832E7CC-8ED9-11D6-873D-00039367340A@nominum.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Aloha, > This is a key management problem of epic proportions. Key management for DNSSEC is a problem of epic proportions without secure DDNS, secure reverse lookup, and secure reverse DDNS lookup. I've been following DNSSEC with interest but have contributed nothing to the process. Not that nay-saying is much of a contribution, but why does DNSSEC have to preserve the distributed management feature of DNS? Centralized authoritative controls would make key management a viable proposition. Even for DDNS and reverse lookups. Real-time feedback would then be possible as well, to push information about alleged IP-to-name mappings (plural) back to the secure DNS where security notices can be dispatched securely to administrative and technical contacts who need to know when somebody arbitrarily begins to purport that their node's FQDN puts it inside their domain. Forged FQDNs in spam relay and other types of FQDN misrepresentation could then be flagged in secure DNS and further actions taken against those people (and nodes) responsible. Authentic, comprehensive forward and reverse mappings would then be possible, giving real-time meaning to negative responses (FQDN does not exist) that aren't possible today with DNS. Sincerely, Jason Coombs jasonc@science.org -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Ted Lemon Sent: Wednesday, July 03, 2002 1:04 PM To: Eric A. Hall Cc: namedroppers@ops.ietf.org; ngtrans@sunroof.eng.sun.com; Christian Huitema Subject: Re: The reverse lookup issue > I would think that DDNS could handle the dynamic scenarios but perhaps I > don't understand the problem. How do you establish a security association between the DNS server for the reverse zone and the node with the IP address? This is a key management problem of epic proportions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 7 21:45:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16560 for ; Sun, 7 Jul 2002 21:45:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RNMb-000A5H-00 for namedroppers-data@psg.com; Sun, 07 Jul 2002 18:30:53 -0700 Received: from 12-234-90-219.client.attbi.com ([12.234.90.219]) by psg.com with esmtp (Exim 3.36 #1) id 17RNML-000A4x-00 for namedroppers@ops.ietf.org; Sun, 07 Jul 2002 18:30:37 -0700 Received: from Master.gorean.org (master.gorean.org [10.0.0.2]) by 12-234-90-219.client.attbi.com (8.12.3/8.12.3) with ESMTP id g681UIC2089663; Sun, 7 Jul 2002 18:30:31 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from localhost (doug@localhost) by Master.gorean.org (8.12.5/8.12.5/Submit) with ESMTP id g681QwYo001876; Sun, 7 Jul 2002 18:26:58 -0700 (PDT) X-Authentication-Warning: Master.gorean.org: doug owned process doing -bs Date: Sun, 7 Jul 2002 18:26:58 -0700 (PDT) From: Doug Barton To: Christian Huitema cc: Paul Vixie , "Louis A. Mamakos" , , Subject: RE: (ngtrans) The reverse lookup issue In-Reply-To: Message-ID: <20020707182459.E679-100000@master.gorean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Jul 2002, Christian Huitema wrote: > Reading this thread, there are three arguments for keeping the reverse > lookup: > > 1) In enterprise networks, reverse lookups provide a way to identify the > source of the traffic. > > 2) In general, it is better to have an information from a third party > (network provider) than from the host itself, since the host may be > compromised or mismanaged. > > 3) Some applications (e.g. SMTP servers) actually use reverse lookup to > check that the name provided by the caller is not entirely bogus. FWIW, I agree with all three of these points. I manage forward and reverse dns for our company, with over 15,000 internet-connected systems in both public and private space. We make extensive use of reverse dns to aid in debugging problems, both with our own systems and those of 3rd parties. Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 09:30:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13862 for ; Mon, 8 Jul 2002 09:30:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RY9K-0002dR-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 06:01:54 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17RY8p-0002cS-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 06:01:23 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id BAA03638; Mon, 8 Jul 2002 01:15:27 -0400 Date: Mon, 8 Jul 2002 01:15:54 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: David Terrell cc: Toshi Yamasaki , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <20020707034806.A15169@pianosa.catch22.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk But the problem is your [wrong] _assumption_ that when forward and reverse match, you have "identified someone responsible". You haven't done anything of the sort. Garbage in just matches garbage out. If you have the IP address, you will be able to find out (eg from DHCP logs) who was assigned that IP address at a certain time, and you'll be able to find the DHCP server owner starting from whois records. If you have only the reverse DNS, you have nothing. Even if the reverse matches the forward, you still have nothing. If your assumption were true, then reverse DNS might be warranted. But your assumption is false, and it has proven very difficult to eradicate that false assumption. Because of the difficulty of that eradication, and the danger posed by the misplaced trust, in comparison with the minor cosmetic benefits of having it, reverse DNS needs to be deprecated. --Dean On Sun, 7 Jul 2002, David Terrell wrote: > On Sun, Jul 07, 2002 at 07:10:44PM +0900, Toshi Yamasaki wrote: > > > > 2) 3rd party may want to identify the source of traffic to complain about > > spam or abuse, not necessarily per host but per /48. What 3rd party want is > > not the FQDN but the contact (tech-c or admin-c) of the source, per /48. > > Whois db is enough to get the contact. > > One justification behind TCP wrappers paranoid mode (require reverse, > require that reverse and forward match) is that whois data can > easily become stale, but tcp wrappers will enforce that reverse DNS > will at least identify someone responsible for the domain (because > forward matches). > > I like being able to identify the source of traffic in my logfiles > without having to run whois against every single entry. This becomes > more crucial with IPv6 (addresses are harder to remember and identify > easily), not less. I do not think that deprecating the reverse > tree is warranted or acceptable. > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 09:34:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13959 for ; Mon, 8 Jul 2002 09:34:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RYVB-0003Il-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 06:24:29 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17RYV5-0003Hw-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 06:24:23 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id JAA27770 for ; Mon, 8 Jul 2002 09:24:21 -0400 (EDT) Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA14633; Mon, 8 Jul 2002 09:24:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200207050408.g6548Eg23678@boreas.isi.edu> References: <200207050408.g6548Eg23678@boreas.isi.edu> Date: Mon, 8 Jul 2002 09:24:23 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:08 PM -0700 7/4/02, Bill Manning wrote: > it is wise to retain the distinction that using DNS to distribute > appkeys may not be the smartest thing, for the reasons mentioned. > I think that the current snapshot is deadon to expire data. > > wrt OE, the keying material is being used to build IPSEC "tunnels" > so having a key tied to the IP address being considered for use > is a good thing. And the DNS looks like the "best" way to push > them around. Herein lies a personal dilemma. On the one hand, my personal architectural view of DNS is that it is not suited for distributing keys, based on reasons I've mentioned before. On the other hand, from what I know about the opportunistic encryption effort, the most efficient manner to distribute keys is via the reverse map of the DNS. Additionally, the trust models seem to go hand in hand. This tells me that 1) my personal architecture view of DNS is flawed or 2) my understanding of the opportunistic encryption effort is incomplete. It is rare in nature to find "one clean exception." Usually making exceptions leads to longer term problems, sometimes exceptions are gateways to better models. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 10:43:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17278 for ; Mon, 8 Jul 2002 10:43:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RZdR-0004jU-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 07:37:05 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17RZd0-0004jE-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 07:36:38 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17RZd0-000Oay-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 07:36:38 -0700 Message-Id: <200207081335.NAA02605@vacation.karoshi.com> In-Reply-To: from "Dean Anderson" at Jul 08, 2002 01:15:54 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@karoshi.com Subject: Re: (ngtrans) The reverse lookup issue To: dean@av8.com (Dean Anderson) Date: Mon, 8 Jul 2002 13:35:16 +0000 (UCT) Cc: dbt@meat.net (David Terrell), t.yamasaki@ntt.com (Toshi Yamasaki), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Spam-Status: No, hits=-6.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] and the whois data get has only one instance and is always correct... :) when forward and reverse match, you have potentially -two- distinct administrative regimes that agree on the target of the delegation. Based on the heirarchical nature of the DNS, I can follow delegation chains, increasing my confidence in the answer. Its not ideal, but its much stronger than a single lookup into a whois database. Of course both whois and dns depend on the integrity of the routing system. And DNS does have a defined method for checking the validity of a response (DNSSEC) while whois has no such integrity checks. > > But the problem is your [wrong] _assumption_ that when forward and reverse > match, you have "identified someone responsible". You haven't done > anything of the sort. Garbage in just matches garbage out. If you have the > IP address, you will be able to find out (eg from DHCP logs) who was > assigned that IP address at a certain time, and you'll be able to find the > DHCP server owner starting from whois records. If you have only the > reverse DNS, you have nothing. Even if the reverse matches the forward, > you still have nothing. > > If your assumption were true, then reverse DNS might be warranted. But > your assumption is false, and it has proven very difficult to eradicate > that false assumption. Because of the difficulty of that eradication, and > the danger posed by the misplaced trust, in comparison with the minor > cosmetic benefits of having it, reverse DNS needs to be deprecated. > > --Dean > > On Sun, 7 Jul 2002, David Terrell wrote: > > > On Sun, Jul 07, 2002 at 07:10:44PM +0900, Toshi Yamasaki wrote: > > > > > > 2) 3rd party may want to identify the source of traffic to complain about > > > spam or abuse, not necessarily per host but per /48. What 3rd party want is > > > not the FQDN but the contact (tech-c or admin-c) of the source, per /48. > > > Whois db is enough to get the contact. > > > > One justification behind TCP wrappers paranoid mode (require reverse, > > require that reverse and forward match) is that whois data can > > easily become stale, but tcp wrappers will enforce that reverse DNS > > will at least identify someone responsible for the domain (because > > forward matches). > > > > I like being able to identify the source of traffic in my logfiles > > without having to run whois against every single entry. This becomes > > more crucial with IPv6 (addresses are harder to remember and identify > > easily), not less. I do not think that deprecating the reverse > > tree is warranted or acceptable. > > > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 11:00:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18052 for ; Mon, 8 Jul 2002 11:00:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RZu8-00052O-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 07:54:20 -0700 Received: from ad202.166.27.108.magix.com.sg ([202.166.27.108] helo=matjes.koerber.org) by psg.com with esmtp (Exim 3.36 #1) id 17RZu2-00052B-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 07:54:14 -0700 Received: from [172.22.22.252] (mathias@noisy.koerber.org [172.22.22.252]) by matjes.koerber.org (8.11.1/8.11.1) with ESMTP id g68ErdW26568; Mon, 8 Jul 2002 22:53:39 +0800 Date: Mon, 08 Jul 2002 22:53:39 +0800 From: Mathias Koerber To: bmanning@karoshi.com, Dean Anderson cc: David Terrell , Toshi Yamasaki , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <44770000.1026140019@noisy.koerber.org> In-Reply-To: <200207081335.NAA02605@vacation.karoshi.com> References: <200207081335.NAA02605@vacation.karoshi.com> X-Mailer: Mulberry/2.2.0 (Linux/x86 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Add to that the fact that mass-WHOIS lookups are in at least some cases frowned upon or restricted already, so that using WHOIS information to check through only a short log of anything may not even be possible mk --On Monday, July 08, 2002 01:35:16 PM +0000 bmanning@karoshi.com wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > > and the whois data get has only one instance and is always > correct... :) > > when forward and reverse match, you have potentially -two- > distinct administrative regimes that agree on the target of > the delegation. Based on the heirarchical nature of the DNS, > I can follow delegation chains, increasing my confidence in > the answer. > > Its not ideal, but its much stronger than a single lookup > into a whois database. Of course both whois and dns depend > on the integrity of the routing system. And DNS does have a > defined method for checking the validity of a response (DNSSEC) > while whois has no such integrity checks. > > >> >> But the problem is your [wrong] _assumption_ that when forward and >> reverse match, you have "identified someone responsible". You haven't >> done anything of the sort. Garbage in just matches garbage out. If you >> have the IP address, you will be able to find out (eg from DHCP logs) >> who was assigned that IP address at a certain time, and you'll be able >> to find the DHCP server owner starting from whois records. If you have >> only the reverse DNS, you have nothing. Even if the reverse matches the >> forward, you still have nothing. >> >> If your assumption were true, then reverse DNS might be warranted. But >> your assumption is false, and it has proven very difficult to eradicate >> that false assumption. Because of the difficulty of that eradication, and >> the danger posed by the misplaced trust, in comparison with the minor >> cosmetic benefits of having it, reverse DNS needs to be deprecated. >> >> --Dean >> >> On Sun, 7 Jul 2002, David Terrell wrote: >> >> > On Sun, Jul 07, 2002 at 07:10:44PM +0900, Toshi Yamasaki wrote: >> > > >> > > 2) 3rd party may want to identify the source of traffic to complain >> > > about spam or abuse, not necessarily per host but per /48. What 3rd >> > > party want is not the FQDN but the contact (tech-c or admin-c) of >> > > the source, per /48. Whois db is enough to get the contact. >> > >> > One justification behind TCP wrappers paranoid mode (require reverse, >> > require that reverse and forward match) is that whois data can >> > easily become stale, but tcp wrappers will enforce that reverse DNS >> > will at least identify someone responsible for the domain (because >> > forward matches). >> > >> > I like being able to identify the source of traffic in my logfiles >> > without having to run whois against every single entry. This becomes >> > more crucial with IPv6 (addresses are harder to remember and identify >> > easily), not less. I do not think that deprecating the reverse >> > tree is warranted or acceptable. >> > >> > >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mathias Koerber mathias@koerber.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 11:22:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19303 for ; Mon, 8 Jul 2002 11:22:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ra9y-0005Nr-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 08:10:42 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17Ra9O-0005N4-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 08:10:06 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 8A7A4137F06; Mon, 8 Jul 2002 08:10:05 -0700 (PDT) To: bmanning@karoshi.com Cc: dean@av8.com (Dean Anderson), dbt@meat.net (David Terrell), t.yamasaki@ntt.com (Toshi Yamasaki), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Message from bmanning@karoshi.com of "Mon, 08 Jul 2002 13:35:16 -0000." <200207081335.NAA02605@vacation.karoshi.com> Date: Mon, 08 Jul 2002 08:10:05 -0700 Message-ID: <56641.1026141005@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "bill" == bmanning writes: bill> and the whois data get has only one instance and is bill> always correct... :) Except when your ISP hasn't bothered to tell the RIR that they've handed you some chunk of the address space that the RIR assigned to them. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 12:02:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21521 for ; Mon, 8 Jul 2002 12:02:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RanR-0006CO-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 08:51:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17RamB-0006AX-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 08:50:11 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17RamB-0000jF-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 08:50:11 -0700 Message-Id: <200207081528.PAA02752@vacation.karoshi.com> In-Reply-To: <56641.1026141005@shell.nominum.com> from "Jim Reid" at Jul 08, 2002 08:10:05 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@karoshi.com Subject: Re: (ngtrans) The reverse lookup issue To: Jim.Reid@nominum.com (Jim Reid) Date: Mon, 8 Jul 2002 15:28:17 +0000 (UCT) Cc: bmanning@karoshi.com, dean@av8.com (Dean Anderson), dbt@meat.net (David Terrell), t.yamasaki@ntt.com (Toshi Yamasaki), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Spam-Status: No, hits=-6.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > >>>>> "bill" == bmanning writes: > > bill> and the whois data get has only one instance and is > bill> always correct... :) > > Except when your ISP hasn't bothered to tell the RIR that they've > handed you some chunk of the address space that the RIR assigned to > them. > notice the smiley... the last count I made was ~70 whois servers, many with "replicated" data and no means to keep the data in sync. rWhois was a valient attempt but has yet to gain traction (and it has its own warts). The whole argument seems to boil down to that age old split, "do I delegate responsiblity to others or not." the net is getting larger. What are we doing to increase "clue density"? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 13:02:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25222 for ; Mon, 8 Jul 2002 13:02:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RblU-0007Mt-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 09:53:32 -0700 Received: from mail6.microsoft.com ([131.107.3.126]) by psg.com with esmtp (Exim 3.36 #1) id 17RblO-0007MY-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 09:53:26 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 09:53:26 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jul 2002 09:53:26 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Jul 2002 09:53:25 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 09:53:25 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 8 Jul 2002 09:53:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (ngtrans) The reverse lookup issue Date: Mon, 8 Jul 2002 09:53:24 -0700 Message-ID: Thread-Topic: (ngtrans) The reverse lookup issue Thread-Index: AcImj8i+XL3NRAFeSB+zY/JOus7yVwAB3uaQ From: "Christian Huitema" To: Cc: , X-OriginalArrivalTime: 08 Jul 2002 16:53:25.0116 (UTC) FILETIME=[F9B9E3C0:01C2269F] X-Spam-Status: No, hits=0.4 required=5.0 tests=GAPPY_TEXT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA25222 > when forward and reverse match, you have potentially -two- > distinct administrative regimes that agree on the target of > the delegation. Based on the heirarchical nature of the DNS, > I can follow delegation chains, increasing my confidence in > the answer. Well, there are obvious loopholes in this reasoning. Suppose that the organization "example.com" has managed to optain the network prefix 2001:0123:4567::/48, and delegation of the corresponding subtree "7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa". Suppose then that this organization writes two scripts in its DNS server, that perform as follow: 1) any request to find a PTR record for "0.1.2.3.4.5.6.7.8.9.A.B.C.D.E.F.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arp a" is served by providng an automatic response: "2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com" In which the local name part is simply derived from the requested address; 2) any request to find an AAAA record for "2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com" Is served by providing the automatic response: 2001:1234:4567:0001:FEDC:BA98:7645:3210 In which the address is simply a parsing of the last name part. Bingo -- the forward and reverse address do match! In fact, I would expect many organizations to do just that, possibly with an exception for a few servers and hosts for which they really want to provide a mnemonic name. It has quite a few advantages, such as not revealing to the outside the structure of the corporate network. This would solve most of the reverse lookup issues for the delegated address spaces. It does not however solve the issue with 6to4. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 13:36:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26949 for ; Mon, 8 Jul 2002 13:36:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RcIk-00089w-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 10:27:54 -0700 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 17RcHS-00088L-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 10:26:34 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.5/8.11.6) with ESMTP id g68HPivG003217; Mon, 8 Jul 2002 13:25:44 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200207081725.g68HPivG003217@nic-naa.net> To: bmanning@karoshi.com cc: Jim.Reid@nominum.com (Jim Reid), dean@av8.com (Dean Anderson), dbt@meat.net (David Terrell), t.yamasaki@ntt.com (Toshi Yamasaki), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Your message of "Mon, 08 Jul 2002 15:28:17 -0000." <200207081528.PAA02752@vacation.karoshi.com> Date: Mon, 08 Jul 2002 13:25:44 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_MX_FOR_FROM version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I noticed the "whois considered useful" a few days ago. In another universe, unfortunately proximal, the protocol running on port 43 is either for mining personal identifiers, or for trademark infringement discovery, or for "law enforcement". Issues like correctness, consistency, completeness -- these aren't what is controlling the policiers of whois data. Eric -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 13:38:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27158 for ; Mon, 8 Jul 2002 13:38:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RcOa-0008Jy-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 10:33:56 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17RcO4-0008II-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 10:33:24 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 314F376; Mon, 8 Jul 2002 10:33:21 -0700 (PDT) Date: Mon, 8 Jul 2002 10:33:21 -0700 From: David Terrell To: Dean Anderson Cc: Toshi Yamasaki , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020708103321.B7809@pianosa.catch22.org> Reply-To: David Terrell References: <20020707034806.A15169@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dean@av8.com on Mon, Jul 08, 2002 at 01:15:54AM -0400 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 10:28AM up 10:20, 36 users, load averages: 0.50, 0.37, 0.33 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Jul 08, 2002 at 01:15:54AM -0400, Dean Anderson wrote: > But the problem is your [wrong] _assumption_ that when forward and reverse > match, you have "identified someone responsible". Given a reverse dns of foo-10-27-123-99.example.net and a forward that matches, I can reasonably assume that I can email {root,postmaster,abuse}@example.net and probably reach someone who can take care of a problem I am having with a machine; and I am more likely to get a response from the tech contact under whois example.net than I am from the contact in whois -a 10.27.123.99. Whois data is far more frequently out of date; a single whois request causes a much higher load on the whois server than a single reverse DNS request; and most importantly there is no way for a clued person to enforce that whois is somewhat correct when a connection is made. > anything of the sort. Garbage in just matches garbage out. If you have the > IP address, you will be able to find out (eg from DHCP logs) who was > assigned that IP address at a certain time, and you'll be able to find the > DHCP server owner starting from whois records. If you have only the > reverse DNS, you have nothing. Even if the reverse matches the forward, > you still have nothing. DHCP? Are you assuming these are internal netblocks that I own? > If your assumption were true, then reverse DNS might be warranted. But > your assumption is false, and it has proven very difficult to eradicate > that false assumption. Because of the difficulty of that eradication, and > the danger posed by the misplaced trust, in comparison with the minor > cosmetic benefits of having it, reverse DNS needs to be deprecated. Just because DNS is sometimes wrong doesn't mean that it's useless. Forward DNS is sometimes wrong, should we eradicate that too? If we push people off to whois, the load on whois servers will go up exponentially and we'll end up needing to bring it back anyway. -- David Terrell | "Anyone want to start a fund for students Nebcorp Prime Minister | that vow not to work at MS?" dbt@meat.net | - Libor Michalek http://wwn.nebcorp.com/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 13:59:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28148 for ; Mon, 8 Jul 2002 13:59:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RciE-0008tJ-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 10:54:14 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17Rch6-0008rm-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 10:53:04 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 6897F76; Mon, 8 Jul 2002 10:53:04 -0700 (PDT) Date: Mon, 8 Jul 2002 10:53:04 -0700 From: David Terrell To: Christian Huitema Cc: bmanning@karoshi.com, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020708105304.C7809@pianosa.catch22.org> Reply-To: David Terrell References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from huitema@windows.microsoft.com on Mon, Jul 08, 2002 at 09:53:24AM -0700 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 10:44AM up 10:36, 34 users, load averages: 0.42, 0.37, 0.34 X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,GAPPY_TEXT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Jul 08, 2002 at 09:53:24AM -0700, Christian Huitema wrote: > > when forward and reverse match, you have potentially -two- > > distinct administrative regimes that agree on the target of > > the delegation. Based on the heirarchical nature of the DNS, > > I can follow delegation chains, increasing my confidence in > > the answer. > > Well, there are obvious loopholes in this reasoning. Suppose that the > organization "example.com" has managed to optain the network prefix > 2001:0123:4567::/48, and delegation of the corresponding subtree > "7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa". Suppose then that this organization > writes two scripts in its DNS server, that perform as follow: > > 1) any request to find a PTR record for > "0.1.2.3.4.5.6.7.8.9.A.B.C.D.E.F.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arp > a" > is served by providng an automatic response: > "2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com" > In which the local name part is simply derived from the requested > address; > > 2) any request to find an AAAA record for > "2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com" > Is served by providing the automatic response: > 2001:1234:4567:0001:FEDC:BA98:7645:3210 > In which the address is simply a parsing of the last name part. > > Bingo -- the forward and reverse address do match! Yes, but in the DNS world that means that someone has delegated 7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa to the same group to whom .com zone operator has delegated example.com. How about that. Two distinct administrative regimes. And I can generally map example.com more accurately than I can map 2001:0123:4567::, because the DNS contact database generally has the same information used for DNS billing; whois does not. I also can't send email to abuse@2001:0123:4567::, I can send email to abuse@example.com. > In fact, I would expect many organizations to do just that, possibly > with an exception for a few servers and hosts for which they really want > to provide a mnemonic name. It has quite a few advantages, such as not > revealing to the outside the structure of the corporate network. This > would solve most of the reverse lookup issues for the delegated address > spaces. It does not however solve the issue with 6to4. Nope, draft-ietf-ngtrans-6to4-dns-00.txt[*] really needs some working group attention, and I think it needs the opinion of the DNS folks; ngtrans doesn't necessarily know the right way to do automatic delegations. * - mirrored here, the draft has expired.... http://meat.net/~dbt/code/rev6to4/draft-ietf-ngtrans-6to4-dns-00.txt -- David Terrell | "Any sufficiently advanced technology Prime Minister, Nebcorp | is indistinguishable from a rigged demo." dbt@meat.net | - Brian Swetland http://wwn.nebcorp.com/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 14:08:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28577 for ; Mon, 8 Jul 2002 14:08:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rcou-000964-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 11:01:08 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17Rcoa-00095d-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 11:00:48 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 2689438F; Mon, 8 Jul 2002 11:00:48 -0700 (PDT) Date: Mon, 8 Jul 2002 11:00:48 -0700 From: David Terrell To: Christian Huitema Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020708110047.D7809@pianosa.catch22.org> Reply-To: David Terrell References: <20020708105304.C7809@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020708105304.C7809@pianosa.catch22.org>; from dbt@meat.net on Mon, Jul 08, 2002 at 10:53:04AM -0700 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 10:58AM up 10:50, 34 users, load averages: 0.29, 0.31, 0.32 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Jul 08, 2002 at 10:53:04AM -0700, David Terrell wrote: > And I can generally map example.com > more accurately than I can map 2001:0123:4567::, because the DNS > contact database generally has the same information used for DNS > billing; whois does not. This sentence doesn't make any sense, sorry :). ARIN/APNIC/RIPE whois has virtually zero need to match reality, because billing is not done through it; forward DNS whois does (in most cases). Mapping an address to a name is useful, even if the most specific namepart is not. Even if you don't think everybody should use it all the time, that's not a good enough reason to get rid of it. Dave, who plans on putting a * IN PTR notused.meat.net. in his ipv6 reverse DNS zone somewhere.... -- David Terrell | "To increase the hype, I'm gonna release a bunch Nebcorp PM | of BLT variants (NetBLT, FreeBLT, BLT386, etc) dbt@meat.net | and create artificial rivalries." wwn.nebcorp.com | - Brian Swetland (www.openblt.org) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 14:11:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28703 for ; Mon, 8 Jul 2002 14:11:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RcqL-00098v-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 11:02:37 -0700 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #1) id 17Rcq4-00097R-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 11:02:21 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 11:02:20 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jul 2002 11:02:20 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 11:02:20 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Jul 2002 11:02:19 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 8 Jul 2002 11:02:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (ngtrans) The reverse lookup issue Date: Mon, 8 Jul 2002 11:02:19 -0700 Message-ID: Thread-Topic: (ngtrans) The reverse lookup issue Thread-Index: AcImqFCUOcHdx3o9Spy2FpKxlqqlmAAADKOQ From: "Christian Huitema" To: "David Terrell" Cc: , , X-OriginalArrivalTime: 08 Jul 2002 18:02:19.0512 (UTC) FILETIME=[9A04A780:01C226A9] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA28703 > Yes, but in the DNS world that means that someone has delegated > 7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa to the same group to whom .com > zone operator has delegated example.com. How about that. Two > distinct administrative regimes. And I can generally map example.com > more accurately than I can map 2001:0123:4567::, because the DNS > contact database generally has the same information used for DNS > billing; whois does not. I also can't send email to > abuse@2001:0123:4567::, I can send email to abuse@example.com. Well, the owner of 7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa presumably also has delegation of some direct DNS name space, maybe "example.net" instead of "example.com". So, two situations can occur. The delegation of the DNS address tree matches the actual routing delegation, in our case to "example.com", and things are fine. Or, second case, the ISP could not for some reason delegate the DNS address tree to the user of the prefix. In that case, the ISP can still use the trick I was describing; the addresses will resolve to "ip6.example.net" instead of "ip6.example.com"; or perhaps "ip6-customer-xyz.example.net" if the ISP is inventive. We will still get some reverse mapping, and it will still be semi-informative. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 14:26:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29945 for ; Mon, 8 Jul 2002 14:26:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rd4K-0009X9-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 11:17:04 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Rd3D-0009VY-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 11:15:55 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 152394; Mon, 08 Jul 2002 13:13:00 -0500 Message-ID: <3D29D6D7.2050006@ehsco.com> Date: Mon, 08 Jul 2002 13:15:51 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dean Anderson CC: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/8/2002 12:15 AM Dean Anderson wrote: > But the problem is your [wrong] _assumption_ that when forward and > reverse match, you have "identified someone responsible". You haven't > done anything of the sort. Garbage in just matches garbage out. The garbage is in two different zone partitions, each of which have to be updated at the replication master by somebody with access rights (in the common case). So even if the hostname labels are lies, the zones will still be correct. EG, you can make your PTR foobar.IBM.COM but if the IBM.COM doesn't have a forward match then I'm less inclined to believe it is true, and without access to the IBM.COM zone you'll get caught sooner or later since I can track you down through your IN-ADDR path. There are a bunch of security holes that make this less than 100% trustworthy but it is perfectly reasonable as a first-pass approximation. For large organizations with multiple netblocks, a well-managed IN-ADDR space with double-lookups is a requirement for basic first-pass access restriction controls. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 15:54:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05550 for ; Mon, 8 Jul 2002 15:54:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ReTO-000BdZ-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 12:47:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17ReTF-000Bd7-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 12:46:53 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17ReTF-0007Ok-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 12:46:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200207081934.TAA19083@jet.isi.edu> Date: Mon, 8 Jul 2002 19:34:41 GMT To: Erik.Nordmark@sun.com, rhall@quadritek.com Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Cc: bmanning@ISI.EDU, mayer@gis.net, iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Erik and Randy, We have ready to go. Should we be waiting for an updated version of this document? Thank you. RFC Editor > From rfc-ed@ISI.EDU Fri Apr 5 10:09:55 2002 > Date: Fri, 05 Apr 2002 13:10:07 -0500 > From: rhall@quadritek.com (Randy Hall) > X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) > X-Accept-Language: en > MIME-Version: 1.0 > To: Erik Nordmark > CC: Bill Manning , Danny Mayer , > iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, > namedroppers@ops.ietf.org > Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed > Standard > Content-Transfer-Encoding: 7bit > X-AntiVirus: scanned by AMaViS 0.2.1 > > Erik Nordmark wrote: > > > > There were (IMO) bugs in the TKEY, TSIG, and other protocols > > > that needed fixing, and some changes (IMO) were needed (and > > > made) to the protocol, but there were no IP issues relating > > > these issues. > > > Where these bugs in the RFCs or bugs in an implementation of > > those RFCs? > > Implementation. > > Cheers > Randy > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 15:55:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05568 for ; Mon, 8 Jul 2002 15:55:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ReL9-000BRR-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 12:38:31 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17ReKV-000BR7-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 12:37:51 -0700 Received: from [128.177.195.140] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 70782137F06; Mon, 8 Jul 2002 12:37:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 08 Jul 2002 12:38:39 -0700 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: David Conrad To: Edward Lewis , Ted Lemon Cc: "Andy W. Barclay" , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 7/4/02 7:44 PM, "Edward Lewis" wrote: > KEY RR's are going to be large - so if we stuff a > couple of them at one domain name (one KEY RR set) we will either > trip into TCP or need EDNS0 to enlarge the packets. (Of course this > is also true for CERT RR's - even more so.) You already need EDNS0 to indicate support of DNSSEC. > The complexity that I am concerned with is architectural and > administrative. I find the 'architectural complexity' argument somewhat amusing. The complexity of putting application keys into the DNS pales to insignificance in comparison to the complexity of actually implementing and deploying DNSSEC. The code is already there (well, almost -- presumably would need to implement the APPKEY RR, but that is conceptually no different than any other RR). As for administrative complexity, I'm confused how this is particularly relevant to DNSEXT. Was there much concern about the administrative complexity of actually using as opposed to defining (say) the LOC RR? > If there is plan to use DNSSEC to protect the > delivery of keys to application elements, the problem is that we are > imposing on application the security model being used by DNS. Which, in some cases (e.g., opportunistic keying), is presumably OK as the thing you are trying to lookup is DNS based. > By tying DNS security to > application security we are "putting our eggs in one basket." A valid concern. However, in a few select applications (e.g., ssh), you are already relying on the DNS so it isn't clear to me how much additional vulnerability is raised should the DNS security model fail. > Morale of the story - 1) trying to inflict security that benefits > applications that need "freshly" secured data harms the DNS through > more traffic. You are assuming additional DNS traffic is harmful. Why? I hear there is a glut of bandwidth... More seriously, DNSSEC _will_ result in more traffic. Any additional traffic caused by something like APPKEY would, I suspect, be lost in the noise. > 2) tying TTL and SIG validity periods is a bad idea > (but seem to keep popping up). You are saying we should ignore the SHOULD in RFC 2535 section 4.4? The implication of this would, of course, be that you'd have unverifiable data. If your resolver would be able to handle such data, then I don't see the point in having DNSSEC. > (TTL - database coherency, sig validity - crypto health. Don't > confuse them. Yes, the signer should truncate the ttl to the > validity, but not the cache's. I'd expound further, but this isn't > why I'm writing.) While I am not confusing database coherency and database validity, it isn't clear to me that coherent but (potentially) invalid data is of any use to anyone actually interested in security. Indeed, it would seem it would open up windows of vulnerability if presumably secure resolvers can accept unverifiable data. Expound please. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 17:28:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11780 for ; Mon, 8 Jul 2002 17:28:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rfxj-000E3C-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 14:22:27 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17RfxD-000E2n-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 14:21:55 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17RfxC-0009xL-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 14:21:55 -0700 In-Reply-To: <20020708105304.C7809@pianosa.catch22.org> References: MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020708211930.DE27F1932@thrintun.hactrn.net> Date: Mon, 08 Jul 2002 17:19:30 -0400 From: Rob Austein To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At Mon, 8 Jul 2002 10:53:04 -0700, David Terrell wrote: > > Nope, draft-ietf-ngtrans-6to4-dns-00.txt[*] really needs some working > group attention, and I think it needs the opinion of the DNS folks; > ngtrans doesn't necessarily know the right way to do automatic > delegations. To be fair: Keith has been trying to get me to work with him on that draft for over a year now, but I keep forgetting about it and he's too polite to remind me. I agree that it needs more attention. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 17:28:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11795 for ; Mon, 8 Jul 2002 17:28:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RftR-000Dx3-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 14:18:01 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17Rfsn-000Dvf-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 14:17:21 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id RAA18003; Mon, 8 Jul 2002 17:17:19 -0400 (EDT) Received: from [192.149.252.164] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA00271; Mon, 8 Jul 2002 17:17:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 8 Jul 2002 17:09:54 -0400 To: David Conrad From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:38 PM -0700 7/8/02, David Conrad wrote: >I find the 'architectural complexity' argument somewhat amusing. > >The complexity of putting application keys into the DNS pales to >insignificance in comparison to the complexity of actually implementing and >deploying DNSSEC. The code is already there (well, almost -- presumably >would need to implement the APPKEY RR, but that is conceptually no different >than any other RR). My concern is we might be making the interaction between DNS and an application more complex. This isn't related to how complex the code is. >As for administrative complexity, I'm confused how this is particularly >relevant to DNSEXT. Was there much concern about the administrative >complexity of actually using as opposed to defining (say) the LOC RR? I wasn't involved in any of the LOC RR discussions, nor have I seen it used. >Which, in some cases (e.g., opportunistic keying), is presumably OK as the >thing you are trying to lookup is DNS based. I dunno. I'm trying to rationalize this, I made remarks on this in an intervening message. >> By tying DNS security to >> application security we are "putting our eggs in one basket." > >A valid concern. However, in a few select applications (e.g., ssh), you are >already relying on the DNS so it isn't clear to me how much additional >vulnerability is raised should the DNS security model fail. Not exactly true, regarding SSH. SSH still would require that the key in DNS matches the key offered through the connection. One would have to corrupt both the DNS and the host to carry out a "host in the middle" attack. >You are assuming additional DNS traffic is harmful. Why? I hear there is a >glut of bandwidth... More seriously, DNSSEC _will_ result in more traffic. >Any additional traffic caused by something like APPKEY would, I suspect, be >lost in the noise. There might be bandwidth available (my home is still a 28.8max POTS line), but there's also the latency issue. Then again, my argument isn't about on-the-wire complexity/load, but the interactions that would lead to a spectacular meltdown (eggs) when there's a problem. > >> 2) tying TTL and SIG validity periods is a bad idea >> (but seem to keep popping up). > >You are saying we should ignore the SHOULD in RFC 2535 section 4.4? The >implication of this would, of course, be that you'd have unverifiable data. >If your resolver would be able to handle such data, then I don't see the >point in having DNSSEC. After rereading 4.4 or 2535, yeah, I think that cache's shouldn't trim the TTL. For example, if a piece of data is ttl'd for 4 days but the key signing it is valid for 2 days, who's to say that the key won't be resigned for another 4 days? Why throw out the data when it will be valid again? >> (TTL - database coherency, sig validity - crypto health. Don't >> confuse them. Yes, the signer should truncate the ttl to the >> validity, but not the cache's. I'd expound further, but this isn't >> why I'm writing.) > >While I am not confusing database coherency and database validity, it isn't >clear to me that coherent but (potentially) invalid data is of any use to >anyone actually interested in security. Indeed, it would seem it would open >up windows of vulnerability if presumably secure resolvers can accept >unverifiable data. Expound please. The point is that if an application cares enough about the security of the data it is using, the application will have to do the check itself. "Arrived securely" data will largely be safe enough for most run of the mill applications. Try this for example: SSH (a security sensitive app) validates the IP address of a host. The net TTL of the validity is 120 seconds. Should SSH then end the connection in 120 seconds? Should all applications cease making use of data from DNS once the resolver's copy of the .org key ttl's out? DNS data is not real-time by its nature. This is why I bristle at attempts to make the data (too) time sensitive. I've expounded...happy? ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 17:42:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12434 for ; Mon, 8 Jul 2002 17:42:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rg9G-000EPB-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 14:34:22 -0700 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #1) id 17Rg7u-000ENU-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 14:32:58 -0700 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id g68LY5001045; Mon, 8 Jul 2002 17:34:05 -0400 (EDT) Received: from nodnsquery(129.9.145.48) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAXuaGcc; Mon, 8 Jul 02 17:34:05 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1-eri0-1.is.chrysler.com [53.230.102.56]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g68LWoB17294; Mon, 8 Jul 2002 17:32:50 -0400 (EDT) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.61]) by wokcdts1.is.chrysler.com (8.11.2/8.9.1) with ESMTP id g68LViE13821; Mon, 8 Jul 2002 17:31:44 -0400 (EDT) Message-ID: <3D2A04BF.26384398@daimlerchrysler.com> Date: Mon, 08 Jul 2002 17:31:43 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue References: <3D23756D.7020205@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Eric A. Hall" wrote: > on 7/3/2002 1:59 PM Christian Huitema wrote: > > > So, my question is, do we really need to invest in a reverse lookup DNS > > tree for IPv6? > > Yes, it's useful and necessary to a variety of validation processes, > especially when used with double lookups (check PTR and A both ways). Like many other contributors to this thread, I happen to consider those validation processes to be, for the most part, broken, and I'd rather hasten their demise than hand them a crutch with which to hobble into the IPv6 world. Yet, I recognize that reverse DNS has its uses, outside the realm of authentication. At the very least, it makes "traceroute" output more readable. Beyond that, I'd be a hypocrite to say that reverse DNS is *useless*, since I actually use reverse DNS extensively in the homegrown system we use here for maintaining our DNS. I don't think anyone (?) in this discussion thinks that reverse DNS is *useless*, i.e. devoid of any practical application. We're only debating the *degree* to which it is useful (and, potentially, the degree to which it might be harmful as well, e.g. fostering bad security practices and/or a false sense of security). But that's only looking at one side of the cost-benefit equation. The benefit is small but non-negligible; what is the cost? I have to apologize for not following the IPv6-related discussions as closely as perhaps I should have. How painful is it to implement reverse DNS for IPv6 (assuming that we resist the temptation to add extra bells and whistles and just stick with a straight address-to-name mapping mechanism)? Maybe the benefit is worth the cost, maybe it isn't. I certainly can't make up my mind on that without knowing both sides of the equation... - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 18:10:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13843 for ; Mon, 8 Jul 2002 18:10:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RgaT-000FD8-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 15:02:29 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17RgZb-000FC3-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 15:01:35 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA22624; Mon, 8 Jul 2002 17:03:30 -0400 Date: Mon, 8 Jul 2002 17:03:57 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: David Terrell cc: Toshi Yamasaki , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <20020708103321.B7809@pianosa.catch22.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 8 Jul 2002, David Terrell wrote: > On Mon, Jul 08, 2002 at 01:15:54AM -0400, Dean Anderson wrote: > > But the problem is your [wrong] _assumption_ that when forward and reverse > > match, you have "identified someone responsible". > > Given a reverse dns of foo-10-27-123-99.example.net and a forward that > matches, I can reasonably assume that I can email > {root,postmaster,abuse}@example.net and probably reach someone who can > take care of a problem I am having with a machine; and I am more likely > to get a response from the tech contact under whois example.net than > I am from the contact in whois -a 10.27.123.99. You can _ASSUME_ anything. That doesn't make the assumption true. I know I have far better luck contacting whois contacts than I do domain contacts, especially domains associated with some kind of abuse or cracking. A whois record usually represents a real business. Even when the email address and phone number doesn't work, the business can still be found. A domain name registration record represents $10. Sometimes less. DNSSEC (when it is used), will get you to someone who paid $10 and didn't leave any addresses or phone numbers. (one could say DNSSec [if it works, and is used] is a lot of trouble for securing something worth $10). > Whois data is far more frequently out of date; a single whois request > causes a much higher load on the whois server than a single reverse > DNS request; and most importantly there is no way for a clued person > to enforce that whois is somewhat correct when a connection is made. > > > anything of the sort. Garbage in just matches garbage out. If you have the > > IP address, you will be able to find out (eg from DHCP logs) who was > > assigned that IP address at a certain time, and you'll be able to find the > > DHCP server owner starting from whois records. If you have only the > > reverse DNS, you have nothing. Even if the reverse matches the forward, > > you still have nothing. > > DHCP? Are you assuming these are internal netblocks that I own? In IPv6, it is expected that there will be more DHCP use. Who owns the address today will be different from who owns it in 2 weeks. That information (to whom it was assigned and when) will be logged in a DHCP log. > Just because DNS is sometimes wrong doesn't mean that it's useless. > Forward DNS is sometimes wrong, should we eradicate that too? If > we push people off to whois, the load on whois servers will go up > exponentially and we'll end up needing to bring it back anyway. You should not be using it for authentication. Forward and reverse DNS is useless for authentication. Its use should be eradicated from authentication. So, "yes". Whois servers can be scaled up. And you can get local copies. Most people don't need to make these lookups frequently, so your assertion that whois load will increase exponentially is false. And frankly, I think that whois lookups should be far easier to process than DNS lookups, so even if it did increase by a lot, it should be more than compensated by the reduced reverse lookup load, and corresponding traffic. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 18:11:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13898 for ; Mon, 8 Jul 2002 18:11:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rgb2-000FE8-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 15:03:04 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17RgZs-000FCG-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 15:01:52 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA20515; Mon, 8 Jul 2002 16:32:41 -0400 Date: Mon, 8 Jul 2002 16:33:08 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Mathias Koerber cc: bmanning@karoshi.com, David Terrell , Toshi Yamasaki , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <44770000.1026140019@noisy.koerber.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Still a [wrong] +++ assumption +++: You don't have two administrative domains. You don't even have one, since both forward and reverse replies can be spoofed, or set by an untrustworthy administrative domain to be matching garbage. Whois is much more trustworthy, since the administrative domain is trusted. Given a domain name taken from reverse/forward lookups, you know nothing whatsoever about the originator. It could be completely misleading. Given an IP address, you can find out who it was. Whois can be scaled with replication, and you can obtain local copies if you really do a lot of analysis. Restrictions on whois use presently apply to abusive uses only. --Dean On Mon, 8 Jul 2002, Mathias Koerber wrote: > Add to that the fact that mass-WHOIS lookups are in at least some > cases frowned upon or restricted already, so that using WHOIS information > to check through only a short log of anything may not even be possible > > mk > > --On Monday, July 08, 2002 01:35:16 PM +0000 bmanning@karoshi.com wrote: > > > [ post by non-subscriber. with the massive amount of spam, it is easy to > > miss and therefore delete mis-posts. so fix subscription addresses! ] > > > > > > and the whois data get has only one instance and is always > > correct... :) > > > > when forward and reverse match, you have potentially -two- > > distinct administrative regimes that agree on the target of > > the delegation. Based on the heirarchical nature of the DNS, > > I can follow delegation chains, increasing my confidence in > > the answer. > > > > Its not ideal, but its much stronger than a single lookup > > into a whois database. Of course both whois and dns depend > > on the integrity of the routing system. And DNS does have a > > defined method for checking the validity of a response (DNSSEC) > > while whois has no such integrity checks. > > > > > >> > >> But the problem is your [wrong] _assumption_ that when forward and > >> reverse match, you have "identified someone responsible". You haven't > >> done anything of the sort. Garbage in just matches garbage out. If you > >> have the IP address, you will be able to find out (eg from DHCP logs) > >> who was assigned that IP address at a certain time, and you'll be able > >> to find the DHCP server owner starting from whois records. If you have > >> only the reverse DNS, you have nothing. Even if the reverse matches the > >> forward, you still have nothing. > >> > >> If your assumption were true, then reverse DNS might be warranted. But > >> your assumption is false, and it has proven very difficult to eradicate > >> that false assumption. Because of the difficulty of that eradication, and > >> the danger posed by the misplaced trust, in comparison with the minor > >> cosmetic benefits of having it, reverse DNS needs to be deprecated. > >> > >> --Dean > >> > >> On Sun, 7 Jul 2002, David Terrell wrote: > >> > >> > On Sun, Jul 07, 2002 at 07:10:44PM +0900, Toshi Yamasaki wrote: > >> > > > >> > > 2) 3rd party may want to identify the source of traffic to complain > >> > > about spam or abuse, not necessarily per host but per /48. What 3rd > >> > > party want is not the FQDN but the contact (tech-c or admin-c) of > >> > > the source, per /48. Whois db is enough to get the contact. > >> > > >> > One justification behind TCP wrappers paranoid mode (require reverse, > >> > require that reverse and forward match) is that whois data can > >> > easily become stale, but tcp wrappers will enforce that reverse DNS > >> > will at least identify someone responsible for the domain (because > >> > forward matches). > >> > > >> > I like being able to identify the source of traffic in my logfiles > >> > without having to run whois against every single entry. This becomes > >> > more crucial with IPv6 (addresses are harder to remember and identify > >> > easily), not less. I do not think that deprecating the reverse > >> > tree is warranted or acceptable. > >> > > >> > > >> > >> > >> -- > >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > >> > > > > > > > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 19:03:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16008 for ; Mon, 8 Jul 2002 19:03:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RhLS-000GcH-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 15:51:02 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.36 #1) id 17RhLG-000Gbp-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 15:50:50 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 8 Jul 2002 22:50:49 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Mon, 8 Jul 2002 18:50:26 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002070818502526818 ; Mon, 08 Jul 2002 18:50:25 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <3FF82Z90>; Mon, 8 Jul 2002 18:50:18 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2CAF@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Dean Anderson'" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: RE: (ngtrans) The reverse lookup issue Date: Mon, 8 Jul 2002 18:46:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (List of CC addresses trimmed significantly, since I'm assuming that most people read one or the other list...) I disagree with a number of Dean's recent points, and I'll try to address them in some coherent fashion: Dean Anderson wrote on Monday, 08 July, 2002 15:33: > You don't have two administrative domains. You don't even > have one, since > both forward and reverse replies can be spoofed, or set by an > untrustworthy administrative domain to be matching garbage. > > Whois is much more trustworthy, since the administrative domain is > trusted. Rather than discussing relative trust, or probability of correct/unspoofed data, let's stick to basic principles: 1. Reverse DNS (PTR) information is frequently incorrect or incomplete (my statement/opinion). 2. In some cases, organizations *intentionally* hide their reverse lookup data to make mapping (by an attacker) more difficult. In other cases, organizations simply can't be bothered to keep it up to date (my statement/opinion). 3. However, reverse DNS information is currently useful to many folks for troubleshooting/information gathering--both within enterprise networks, and across the 'Net (my statement/opinion). 4. Christian's original message was in relation to 6to4 transition, and "how to get the equivalent functionality to gethostbyaddr(), and whether we really need it." I believe that in spite of all its shortfalls, it's a useful piece of information--and should not be deprecated. In a large enterprise network where I *don't* control IP range allocation, reverse lookup is much more useful than whois...or are some of you working for companies/organizations that actually run internal whois servers for internal IP address range delegations? If reverse lookup is deprecated for IPv6, then certain types of network misconfiguration/possible attack will get *harder* to deal with, not easier. > Given a domain name taken from reverse/forward lookups, you > know nothing > whatsoever about the originator. It could be completely > misleading. Given > an IP address, you can find out who it was. Given a choice between more information and less when investigating an event, I would prefer more. It does not appear to be an impossible burden to many DNS admins. > Whois can be scaled with replication If it were that easy then it would already be more scaled... > and you can obtain local copies if you really do a lot of analysis. Which is pointless if what I want is *current* information that requires an automated lookup. Again, whois contains a lot of wonderful information...but is not a silver bullet for every situation. Previously, Dean Anderson wrote on Monday, 08 July, 2002 16:04: > A domain name registration record represents $10. Sometimes less. > DNSSEC (when it is used), will get you to someone who paid > $10 and didn't leave any addresses or phone numbers. (one could > say DNSSec [if it works, and is used] is a lot of trouble for > securing something worth $10). Ladies and gentlemen--I note for you an apples and oranges comparison in the above statement. The amount something *costs* has no direct relationship to what it is *worth*. www.amazon.com is worth substantially more than $10, regardless of what amazon.com cost to register. *That* is why DNSSEC is worthwhile for at least some folks. There are other folks out there who don't even care about domain names--but if DNS information can be spoofed then information flow stops and people might die or many shekels be lost. (For some of those cases, registration of domain names are free because they're inside an existing hierarchy--that doesn't mean that the domain names are only "worth" $0.) > > Just because DNS is sometimes wrong doesn't mean that it's useless. > > Forward DNS is sometimes wrong, should we eradicate that too? If > > we push people off to whois, the load on whois servers will go up > > exponentially and we'll end up needing to bring it back anyway. > > You should not be using it for authentication. Forward and > reverse DNS is useless for authentication. Its use should be > eradicated from authentication. So, "yes". I generally agree that "reverse lookup equals forward lookup" is not a robust means of authentication. One could equally say that in current technology, biometric fingerprint readers are not a robust means of authentication (based on recent "gummi" research). That does not mean, however, that it cannot be useful as a data point or as a portion of a multi-factor system. Perfect is (in some cases) the enemy of good enough, and security is not an absolute. In the case of r-protocols -vs- SSH, I can easily explain why SSH should be used and the r-protocols eradicated. It's not so obvious to me here why "reverse lookup equals forward lookup" is hugely inadequate for all uses. -- Rip Loomis Senior Systems Security Engineer SAIC Secure Business Solutions Group www.saic.com/securebiz Center for Information Security Technology www.cist-east.saic.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 19:04:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16072 for ; Mon, 8 Jul 2002 19:04:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RhJR-000GYW-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 15:48:57 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17RhJG-000GYG-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 15:48:46 -0700 Received: from [128.177.195.140] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id ED697137F05; Mon, 8 Jul 2002 15:48:45 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 08 Jul 2002 15:49:35 -0700 Subject: Re: (ngtrans) The reverse lookup issue From: David Conrad To: Dean Anderson , Mathias Koerber Cc: , David Terrell , Toshi Yamasaki , , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 7/8/02 1:33 PM, "Dean Anderson" wrote: > Whois can be scaled with replication, and you can obtain local copies if > you really do a lot of analysis. Can you say HOSTS.TXT? I knew you could. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 19:17:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16589 for ; Mon, 8 Jul 2002 19:17:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rhaf-000H4D-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 16:06:45 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17Rha7-000H2L-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 16:06:11 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id C10C820; Mon, 8 Jul 2002 16:06:09 -0700 (PDT) Date: Mon, 8 Jul 2002 16:06:09 -0700 From: David Terrell To: Dean Anderson Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020708160609.E22245@pianosa.catch22.org> Reply-To: David Terrell References: <20020708103321.B7809@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dean@av8.com on Mon, Jul 08, 2002 at 05:03:57PM -0400 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 3:46PM up 15:38, 41 users, load averages: 0.49, 0.36, 0.29 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Jul 08, 2002 at 05:03:57PM -0400, Dean Anderson wrote: > > You can _ASSUME_ anything. That doesn't make the assumption true. I know > I have far better luck contacting whois contacts than I do domain > contacts, especially domains associated with some kind of abuse or > cracking. A whois record usually represents a real business. Even when > the email address and phone number doesn't work, the business can still be > found. A domain name registration record represents $10. Sometimes less. > DNSSEC (when it is used), will get you to someone who paid $10 and didn't > leave any addresses or phone numbers. (one could say DNSSec [if it works, > and is used] is a lot of trouble for securing something worth $10). There is no information on the internet guaranteed to be true, and that is correct regardless of encryption, information source, or anything else. However, reverse DNS is a lightweight method to identify a name for a host that cannot be easily replicated using another method. If a central TCP server identifying addresses would have scaled, DNS would never have been created. Reverse DNS has value. Your statement that you do not find it to be valuable are interesting, but not sufficient to convince me that the value I have derived from said service where chimerical. > > > anything of the sort. Garbage in just matches garbage out. If you have the > > > IP address, you will be able to find out (eg from DHCP logs) who was > > > assigned that IP address at a certain time, and you'll be able to find the > > > DHCP server owner starting from whois records. If you have only the > > > reverse DNS, you have nothing. Even if the reverse matches the forward, > > > you still have nothing. > > > > DHCP? Are you assuming these are internal netblocks that I own? > > In IPv6, it is expected that there will be more DHCP use. Who owns the > address today will be different from who owns it in 2 weeks. That > information (to whom it was assigned and when) will be logged in a DHCP > log. Much work has gone into making DHCP completely unnecessary for IPv6 deployment, though of course DHCPv6 does exist. Regardless, you only buttress my position. Reverse DNS today, when you connect to my machine, is far more likely to have useful information that may point me to you than whois will in a month when that netblock has been reassigned by your upstream. whois is not loggable in-band. DNS is. > > Just because DNS is sometimes wrong doesn't mean that it's useless. > > Forward DNS is sometimes wrong, should we eradicate that too? If > > we push people off to whois, the load on whois servers will go up > > exponentially and we'll end up needing to bring it back anyway. > > You should not be using it for authentication. Forward and reverse DNS is > useless for authentication. Its use should be eradicated from > authentication. So, "yes". r* should die; agreed. So what? SSH's RSARhosts authentication method uses reverse DNS securely. You assume that authentication is the only purpose of this data. You're wrong. It has informational value to me, there are ways in which reverse DNS records can be cryptographically verified using another service that is secure. > Whois servers can be scaled up. And you can get local copies. Most people > don't need to make these lookups frequently, so your assertion that whois > load will increase exponentially is false. And frankly, I think that whois > lookups should be far easier to process than DNS lookups, so even if it > did increase by a lot, it should be more than compensated by the reduced > reverse lookup load, and corresponding traffic. A scalable protocol for a global name and address resolution already exists, why are you trying to duplicate it, badly, with a TCP service? -- David Terrell | Step 1: "configure one system using your GUI" dbt@meat.net | Step 2: "now configure 1000 more" Nebcorp Prime Minister | - Casper H.S. Dik http://wwn.nebcorp.com | -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 19:35:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17292 for ; Mon, 8 Jul 2002 19:35:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RhwI-000Hib-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 16:29:06 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17Rhw8-000HiJ-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 16:28:56 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA09805; Mon, 8 Jul 2002 19:28:48 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA02890; Mon, 8 Jul 2002 19:28:48 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id TAA06709; Mon, 8 Jul 2002 19:28:47 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id TAA17825; Mon, 8 Jul 2002 19:28:48 -0400 (EDT) To: Edward Lewis Cc: David Conrad , namedroppers From: Derek Atkins Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: Date: 08 Jul 2002 19:28:48 -0400 In-Reply-To: Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,RCVD_IN_RELAYS_ORDB_ORG version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > Try this for example: SSH (a security sensitive app) validates the IP > address of a host. The net TTL of the validity is 120 seconds. Should > SSH then end the connection in 120 seconds? Should all applications > cease making use of data from DNS once the resolver's copy of the .org > key ttl's out? Actually, this isn't completely accurate. The security that SSH provides is linkability between connections. Assuming your personal SSH Cache is secure (which may be false), you know that the host you know as host.foo.com is the same host you knew as host.foo.com last week. Where keys-in-DNS helps is the first connection. If you've never contacted a host before, you have no way to know whether to trust the key. If, however, you can compare the key in DNS to the key the server hands you, you get one more level of protection. As for the timeout question, that is actually still under debate. There actually _ARE_ applications that timeout their security after some period of time. IPsec does this (you have to periodically re-key the connection). A number of GSSAPI mechanisms stop working at the timeout, too. So, yes, in the name of security it MAY BE reasonable to timeout the connection based on the TTL. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 19:39:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17442 for ; Mon, 8 Jul 2002 19:39:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ri1D-000HsN-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 16:34:11 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17Rhzq-000Hpo-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 16:32:47 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA10722; Mon, 8 Jul 2002 19:32:22 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA03065; Mon, 8 Jul 2002 19:32:20 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA04382; Mon, 8 Jul 2002 19:32:18 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id TAA17840; Mon, 8 Jul 2002 19:32:18 -0400 (EDT) To: Dean Anderson Cc: Mathias Koerber , bmanning@karoshi.com, David Terrell , Toshi Yamasaki , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue References: Date: 08 Jul 2002 19:32:18 -0400 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > Still a [wrong] +++ assumption +++: > > You don't have two administrative domains. You don't even have one, since > both forward and reverse replies can be spoofed, or set by an > untrustworthy administrative domain to be matching garbage. Not with DNSSec. -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 21:15:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21916 for ; Mon, 8 Jul 2002 21:15:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RjRG-000KWW-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 18:05:10 -0700 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 17RjQo-000KVb-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 18:04:42 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.5/8.11.6) with ESMTP id g6913evG004536; Mon, 8 Jul 2002 21:03:40 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200207090103.g6913evG004536@nic-naa.net> To: David Conrad cc: Dean Anderson , Mathias Koerber , bmanning@karoshi.com, David Terrell , Toshi Yamasaki , ngtrans@sunroof.eng.sun.com, namedroppers , brunner@nic-naa.net Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Your message of "Mon, 08 Jul 2002 15:49:35 PDT." Date: Mon, 08 Jul 2002 21:03:40 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_MX_FOR_FROM version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On 7/8/02 1:33 PM, "Dean Anderson" wrote: > > Whois can be scaled with replication, and you can obtain local copies if > > you really do a lot of analysis. > > Can you say HOSTS.TXT? I knew you could. There is a difference. The data published by the NIC as HOSTS.TXT was ephemerally accurate. The data published by whois publishers has the endearing property of being persistently inextant or inaccurate. HOSTS.TXT, partially shredded. Cheers, Eric -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 21:16:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21945 for ; Mon, 8 Jul 2002 21:16:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RjUL-000Kbe-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 18:08:21 -0700 Received: from bdsl.66.12.174.102.gte.net ([66.12.174.102] helo=mail.digitalmarketplace.com) by psg.com with esmtp (Exim 3.36 #1) id 17RjU9-000KbD-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 18:08:09 -0700 Received: from win2kdev ([208.3.65.158]) by mail.digitalmarketplace.com with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 8 Jul 2002 18:44:41 -0700 Reply-To: From: "Jason Coombs" To: "Derek Atkins" , "Edward Lewis" Cc: "David Conrad" , "namedroppers" Subject: RE: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Date: Mon, 8 Jul 2002 15:15:15 -1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Aloha, Derek and Edward; (I've enjoyed this discussion, thanks to both of you) > Where keys-in-DNS helps is the first connection. If you've > never contacted a host before, you have no way to know whether to > trust the key. If, however, you can compare the key in DNS to the > key the server hands you, you get one more level of protection. This has already been mentioned, but aren't certificates a better way to accomplish the application security you describe for that first connection? The attacker has another hoop to jump through in order to be an attacker: they have to steal the secret key that corresponds to the root certificate in the trust chain, or discover it through successful cryptanalysis. This seems comparable to the additional hoop required to spoof DNSSEC responses delivered to resolvers in your proposed scenario. The difficulty of mounting the attack is identical once the server gets keyed and certified. So how does a key in DNS increase the difficulty of an attack, exactly? By requiring the attacker to hijack or spoof two boxes instead of just one? Trivial if the attacker is already a full-fledged MITM. If DNSSEC is deployed for the Internet as a PGP-style web of trust rather than a DNS-style hierarchical distributed database or an SSL-style centralized certificate authority trust model, you still won't be able to trust anyone whose key is signed by somebody you don't trust, and if you trust everyone who signs keys then you essentially trust nobody all over again but you just spent a whole bunch of time getting there. I know this is old debate, at least in cryptographic circles. My point is simply to caution against assuming more security than you really have and suggest that it may in fact be inappropriate (or at best useless) to view keys from DNSSEC as anything other than applicable to DNSSEC as suggested by draft-ietf-dnsext-restrict-key-for-dnssec-03.txt. Some sort of APPKEY may be valuable, but if it isn't for the purpose of defining an Internet standard key service for some sort of Internet standard cryptographic system like some type of international smart card ID system and associated single sign on service (*cringe*) then APPKEY seems to me to be of value primarily for private, custom applications that don't need nor do they benefit from the standards process. Sincerely, Jason Coombs jasonc@science.org -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Derek Atkins Sent: Monday, July 08, 2002 1:29 PM To: Edward Lewis Cc: David Conrad; namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Edward Lewis writes: > Try this for example: SSH (a security sensitive app) validates the IP > address of a host. The net TTL of the validity is 120 seconds. Should > SSH then end the connection in 120 seconds? Should all applications > cease making use of data from DNS once the resolver's copy of the .org > key ttl's out? Actually, this isn't completely accurate. The security that SSH provides is linkability between connections. Assuming your personal SSH Cache is secure (which may be false), you know that the host you know as host.foo.com is the same host you knew as host.foo.com last week. Where keys-in-DNS helps is the first connection. If you've never contacted a host before, you have no way to know whether to trust the key. If, however, you can compare the key in DNS to the key the server hands you, you get one more level of protection. As for the timeout question, that is actually still under debate. There actually _ARE_ applications that timeout their security after some period of time. IPsec does this (you have to periodically re-key the connection). A number of GSSAPI mechanisms stop working at the timeout, too. So, yes, in the name of security it MAY BE reasonable to timeout the connection based on the TTL. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 21:31:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22892 for ; Mon, 8 Jul 2002 21:31:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rjk7-000L7t-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 18:24:39 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17Rjjz-000L6m-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 18:24:31 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA01761; Mon, 8 Jul 2002 21:24:09 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA02653; Mon, 8 Jul 2002 21:24:08 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id VAA22128; Mon, 8 Jul 2002 21:24:07 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id VAA18198; Mon, 8 Jul 2002 21:24:08 -0400 (EDT) To: Cc: "Edward Lewis" , "David Conrad" , "namedroppers" From: "Derek Atkins" Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: Date: 08 Jul 2002 21:24:08 -0400 In-Reply-To: Message-ID: Lines: 82 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD,LINES_OF_YELLING, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Jason Coombs" writes: > Aloha, Derek and Edward; > > (I've enjoyed this discussion, thanks to both of you) > > > Where keys-in-DNS helps is the first connection. If you've > > never contacted a host before, you have no way to know whether to > > trust the key. If, however, you can compare the key in DNS to the > > key the server hands you, you get one more level of protection. > > This has already been mentioned, but aren't certificates a better > way to accomplish the application security you describe for that > first connection? I wouldn't call it "better", but "different". To be pedantic, DNSSEC _does_ provide a certificate, by definition. It's providing a binding of a key to a name. The only difference is that it's using the DNSSEC key hierarchy instead of a non-DNSSEC key hierarchy for the chain-of-trust. But technically you do get "certificates" from DNSSEC. > The attacker has another hoop to jump through in order to be an > attacker: they have to steal the secret key that corresponds to > the root certificate in the trust chain, or discover it through > successful cryptanalysis. This seems comparable to the additional > hoop required to spoof DNSSEC responses delivered to resolvers > in your proposed scenario. The attacks against X.509 Certs are the same as they are against DNSSEC, and vice versa. Any attack you can mount against DNSSEC can be mounted against a CA. The real difference is that theoretically you should be less successful with a real CA. I say theoretically because, well, "Verisign's Microsoft Certificate". > The difficulty of mounting the attack is identical once the > server gets keyed and certified. So how does a key in DNS > increase the difficulty of an attack, exactly? By requiring > the attacker to hijack or spoof two boxes instead of just > one? Trivial if the attacker is already a full-fledged MITM. Let's look at the SSH protocol.. The first time a clien connects to a server, the server sends its key and the user is asked whether to accept it. If, however, the client makes a DNSSEC query for IN APPKEY .. and receives: IN APPKEY ... IN SIG (APPKEY) ... So, if the client compares the key from DNS against the key obtained from the server, they have a higher level of assurance in that key (if they match) than just accepting it blindly. The user has a level of assurance that the key data in DNS is the data that the owner of the domain put into the zone file. A MITM could not insert or change this data in the DNS, because they wouldn't know the DNS signing key. Now, you could call into question the ability of the DNS operator to manage the keys, but the same can be said for CAs. Similarly, if you say the MITM has access to the DNSSEC signing keys, that's the same as saying they have access to the CA Signing Keys. A rose by any other name.... > My point is simply to caution against assuming more security > than you really have and suggest that it may in fact be > inappropriate (or at best useless) to view keys from DNSSEC > as anything other than applicable to DNSSEC as suggested by > draft-ietf-dnsext-restrict-key-for-dnssec-03.txt. Some sort I believe you are mis-reading the restrict-key draft. The draft is just saying that the KEY RR should be restricted, not that the concept of using DNSSec for KEY Distribution is flawed. When I say 'key', I mean the concept of a key (be it stored in a CERT, APPKEY, or FROZBAR RR), not the "DNS KEY-RR". -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 21:51:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24287 for ; Mon, 8 Jul 2002 21:51:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rk2s-000LhE-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 18:44:02 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17Rk2Y-000Lgs-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 18:43:43 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 36FE2392; Mon, 8 Jul 2002 18:43:42 -0700 (PDT) Date: Mon, 8 Jul 2002 18:43:42 -0700 From: David Terrell To: Jason Coombs Cc: namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Message-ID: <20020708184342.A15836@pianosa.catch22.org> Reply-To: David Terrell References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jasonc@science.org on Mon, Jul 08, 2002 at 03:15:15PM -1000 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 6:41PM up 18:33, 32 users, load averages: 0.45, 0.37, 0.41 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Jul 08, 2002 at 03:15:15PM -1000, Jason Coombs wrote: > I know this is old debate, at least in cryptographic circles. > My point is simply to caution against assuming more security > than you really have and suggest that it may in fact be > inappropriate (or at best useless) to view keys from DNSSEC > as anything other than applicable to DNSSEC as suggested by > draft-ietf-dnsext-restrict-key-for-dnssec-03.txt. the dropping of all non-DNSSEC KEY records is non-controversial because nobody wants to have to parse multiple KEY RRs _while_doing_ _DNSSEC_validation_, not because the idea that DNSSEC should not be used for application keys has gained WG consensus. -- David Terrell | "If I had a nickel for every time I've seen a Usenet poster Nebcorp PM | slip in an ostensibly casual reference to how much smarter dbt@meat.net | he/she is than everyone else... why, I'd be able to throw a wwn.nebcorp.com |party for all my Mensa buddies!" -- Miguel Cruz -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 8 23:38:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00922 for ; Mon, 8 Jul 2002 23:38:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rlg6-000OjG-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 20:28:38 -0700 Received: from [202.28.97.7] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17Rlfx-000Oi1-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 20:28:30 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g693SMI22136; Tue, 9 Jul 2002 10:28:22 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g693R3f25805; Tue, 9 Jul 2002 10:27:10 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Christian Huitema" cc: bmanning@karoshi.com, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jul 2002 10:27:03 +0700 Message-ID: <25803.1026185223@munnari.OZ.AU> X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,GAPPY_TEXT,FOR_FREE version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 8 Jul 2002 09:53:24 -0700 From: "Christian Huitema" Message-ID: | 1) any request to find a PTR record for | "0.1.2.3.4.5.6.7.8.9.A.B.C.D.E.F.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arp | a" | is served by providng an automatic response: | "2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com" Christian, right idea, but poor implementation. That one allows people to conclude that there is an "example.com" in there which is some kind of useful information (it isn't, but people believe it). The automatic response is much more likely to be 2001-1234-4567-0001-FEDC-BA98-7645-3210.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa And then this becomes ... | 2) any request to find an AAAA record for | "2001-1234-4567-0001-FEDC-BA98-7645-3210.ip6.example.com" Any attempt to find the AAAA (A6...) record for 2001-1234-4567-0001-FEDC-BA98-7645-3210.1.0.0.0.7.6.5.4.3.2.1.0.1.0.0.2.ip6.arpa | Is served by providing the automatic response: | 2001:1234:4567:0001:FEDC:BA98:7645:3210 | In which the address is simply a parsing of the last name part. And of course, all of this is server out of the same pseudo-zone. Pseudo in that all of the data in the zone, (perhaps excluding SOA and NS records, if they exist at all) is created on the fly based upon queries received (and most likely given a TTL of the order of years, so the server minimises the number of queries it gets - caches will tend to put an upper bound on that, so "years" wouldn't actually work, but still the max possible TTL for each cache is achieved). And then.. | Bingo -- the forward and reverse address do match! Exactly - and the node that asked the query has precisely no information it didn't have before it started. | In fact, I would expect many organizations to do just that, Yes. More than that, I'd expect that sites will offer servers to do exactly that for free (just as you can get forward DNS servers now for "free" - which means that you have to suffer looking at their web advertising every time you do something...) With such a site, all that's needed is that when you're delegated an address block, you list the magic site's DNS servers as being responsible for the IP6.ARPA domain. Most likely you would have had to set the server up first (or they wouldn't be able to get you to their site, and hence to view their advertising...) and perhaps they would allow you to enter some specific data in case you do want to have some particular addresses mapped to names. With all this of course, there is precisely no information available in the DNS which in any way relates the address to any useful contact information for the user of the address. Yet it satisfies the letter (and the practical requirements) of the "rule" that some would like to see imposed. All that is needed for us to reach this state, is to keep telling people that they're *required* to implement IP6.ARPA domains for their address blocks. If they're not required, or expected, to (and people stop attempting to force them by idiotic, then no-one will bother with this nonsense, they just won't bother having an IP6.ARPA zone at all, or if they have one, it will have in it only the PTR records that the net admin wants to make public. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 00:03:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01635 for ; Tue, 9 Jul 2002 00:03:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rm65-000PXw-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 20:55:29 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Rm60-000PXg-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 20:55:24 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 152508; Mon, 08 Jul 2002 22:52:29 -0500 Message-ID: <3D2A5EA9.2060803@ehsco.com> Date: Mon, 08 Jul 2002 22:55:21 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Dean Anderson CC: namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/8/2002 3:33 PM Dean Anderson wrote: > Whois is much more trustworthy, since the administrative domain is > trusted. The A RR for whois.internic.net is immune to spoofing? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 00:17:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01907 for ; Tue, 9 Jul 2002 00:17:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RmJu-000Pzm-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 21:09:46 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17RmJp-000Pza-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 21:09:41 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 152506; Mon, 08 Jul 2002 23:06:46 -0500 Message-ID: <3D2A6202.4040208@ehsco.com> Date: Mon, 08 Jul 2002 23:09:38 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Kevin Darcy CC: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: The reverse lookup issue References: <3D23756D.7020205@ehsco.com> <3D2A04BF.26384398@daimlerchrysler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/8/2002 4:31 PM Kevin Darcy wrote: > "Eric A. Hall" wrote: >> Yes, it's useful and necessary to a variety of validation processes, > Like many other contributors to this thread, I happen to consider those > validation processes to be, for the most part, broken, and I'd rather > hasten their demise than hand them a crutch with which to hobble into > the IPv6 world. Just a clarification that I specifically used "validation" and not authentication, nor even authorization. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 01:14:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03117 for ; Tue, 9 Jul 2002 01:14:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rn9U-0001bu-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 22:03:04 -0700 Received: from [202.28.97.7] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17Rn8p-0001aI-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 22:02:56 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g6952AI07726; Tue, 9 Jul 2002 12:02:11 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6951Rf26226; Tue, 9 Jul 2002 12:01:27 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Christian Huitema" , bmanning@karoshi.com, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <25803.1026185223@munnari.OZ.AU> References: <25803.1026185223@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jul 2002 12:01:27 +0700 Message-ID: <26224.1026190887@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 09 Jul 2002 10:27:03 +0700 From: Robert Elz Message-ID: <25803.1026185223@munnari.OZ.AU> Oops, I sent the message half way through a thought, after being distracted by non-electronic communications... | All that is needed for us to reach this state, is to keep telling people | that they're *required* to implement IP6.ARPA domains for their address | blocks. | If they're not required, or expected, to (and people stop attempting to | force them by idiotic This was supposed to go on to say "idiotic refusals to allow incoming connections (FTP, SMTP, ..) where the IP6.ARPA info isn't available)" | , then no-one will bother with this nonsense, | they just won't bother having an IP6.ARPA zone at all, or if they have one, | it will have in it only the PTR records that the net admin wants to make | public. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 01:51:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03782 for ; Tue, 9 Jul 2002 01:51:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RnnL-0002oO-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 22:44:15 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17RnnD-0002oD-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 22:44:07 -0700 Received: from [10.0.1.24] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 523E7137F03; Mon, 8 Jul 2002 22:44:06 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 08 Jul 2002 22:44:54 -0700 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: David Conrad To: Edward Lewis Cc: namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 7/8/02 2:09 PM, "Edward Lewis" wrote: > My concern is we might be making the interaction between DNS and an > application more complex. Again, I'm confused how this is particularly relevant to DNSEXT. If you want application complexity related to the DNS, look at NAPTR and 2916bis. APPKEY looks much simpler to me, but isn't this a question for the application developers that want to make use of APPKEY? > There might be bandwidth available (my home is still a 28.8max POTS > line), but there's also the latency issue. Then again, my argument > isn't about on-the-wire complexity/load, but the interactions that > would lead to a spectacular meltdown (eggs) when there's a problem. If you believe DNSSEC is going to happen, then you implicitly assume the bandwidth and CPU consumption for DNS is going to take a huge jump. If this will lead to a "spectacular meltdown", then let's make 2535bis say "Don't do DNSSEC" (I know many people who would pee themselves in joy at the prospect). However, I fail to see how adding another RR, even a big RR like an APPKEY could be, is going to trigger a "spectacular meltdown". What am I missing? As for bandwidth consumption and latency, I would be somewhat stunned to find that an X.509 CERT verification (including verification of CRL) is any less consumptive of time or bandwidth from the end user's perspective (of course, it will be less from the DNS server's perspective -- is that your point?). > After rereading 4.4 or 2535, yeah, I think that cache's shouldn't > trim the TTL. For example, if a piece of data is ttl'd for 4 days > but the key signing it is valid for 2 days, who's to say that the key > won't be resigned for another 4 days? Why throw out the data when it > will be valid again? Um. How do you know it is valid and not spoofed? > Try this for example: SSH (a security sensitive app) validates the > IP address of a host. The net TTL of the validity is 120 seconds. > Should SSH then end the connection in 120 seconds? If someone has made their key validity period be 120 seconds, then that would appear to be the desired behavior, would it not? > DNS data is not real-time by its nature. Interesting theory. That explains why a TTL of 0 isn't allowed and why DNS based load balancers are such complete failures. Err, wait... Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 02:57:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14066 for ; Tue, 9 Jul 2002 02:57:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rop8-0004us-00 for namedroppers-data@psg.com; Mon, 08 Jul 2002 23:50:10 -0700 Received: from [202.28.97.7] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17Roor-0004u1-00 for namedroppers@ops.ietf.org; Mon, 08 Jul 2002 23:49:54 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g696mOI23722; Tue, 9 Jul 2002 13:48:25 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g696lTf26509; Tue, 9 Jul 2002 13:47:34 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: David Conrad cc: Edward Lewis , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jul 2002 13:47:29 +0700 Message-ID: <26507.1026197249@munnari.OZ.AU> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 08 Jul 2002 22:44:54 -0700 From: David Conrad Message-ID: | Again, I'm confused how this is particularly relevant to DNSEXT. If you | want application complexity related to the DNS, look at NAPTR and 2916bis. | APPKEY looks much simpler to me, but isn't this a question for the | application developers that want to make use of APPKEY? If there were one group of application developers looking to make use of a single APPKEY record, most likely no-one would care much more than about all the other random records that people keep adding to the DNS. That is there'd be a bunch of "Oh no, not another one" groaning, but as long as the spec was reasonable, no-one would seriously object. The problem is that the premise isn't true - what's needed is an APPKEY for every application, not just one APPKEY RR. That leads to one of three possibilities - the APPKEY RDATA identifies the application - but that solution simply doesn't work at all. Or there's a different APPKEY RR type for every different application. That one would work fine, but now the groans above start to become more like pained shouting. The 16 bit RR type space is currently huge, but if we start numbering applications out of it, it will soon vanish. So, this one really doesn't scale either. Or, we start creating magic names for applications, to live in the DNS, and so start to reserve namespace, which should be the end user's prerogative to assign. That's ugly - no, it is truly foul (SRV managed that, with protocols, of which there are a far smaller number than applications, with the leading _ trick by pretending that no users would ever actually want to assign names starting with an underscore). That there is no clean scheme that allows APPKEY to work reasonably (assuming anyone would want to use it - if there are no actual users, implementing it would be easy...) is why there's so much push back against this one in particular. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 03:33:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15051 for ; Tue, 9 Jul 2002 03:33:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RpN7-00062a-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 00:25:17 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 17RpMx-000623-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 00:25:07 -0700 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g697OvD14604; Tue, 9 Jul 2002 09:24:57 +0200 Date: Tue, 9 Jul 2002 09:24:57 +0200 From: "Olaf M. Kolkman" To: Edward Lewis Cc: david.conrad@nominum.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Message-Id: <20020709092457.403a4871.olaf@ripe.net> In-Reply-To: References: Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > After rereading 4.4 or 2535, yeah, I think that cache's shouldn't > trim the TTL. For example, if a piece of data is ttl'd for 4 days > but the key signing it is valid for 2 days, who's to say that the key > won't be resigned for another 4 days? Why throw out the data when it > will be valid again? What 4.4 does is define a state in which a cache should be after a signature expires. If data that is supposed to be secured is not in a state that it can be trusted it should not be around, at least not for anybody who queries that data. If an implementation wants to hide the data from the clients until the data can be verified again then that is OK but I do not think it's really efficient. ( The amount of data in a query for the SIG only -- where you will get all the SIGs for a name -- is probably bigger than for a query of given TYPE where the SIGs for that TYPE and the TYPe itself is returned. ) ::01af --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 04:36:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16591 for ; Tue, 9 Jul 2002 04:36:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RqLy-0007TB-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 01:28:10 -0700 Received: from bartok.sidn.nl ([193.176.144.164]) by psg.com with esmtp (Exim 3.36 #1) id 17RqLj-0007Sv-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 01:27:55 -0700 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g698Rp5d036704; Tue, 9 Jul 2002 10:27:52 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200207090827.g698Rp5d036704@bartok.sidn.nl> To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-reply-to: Your message of Mon, 08 Jul 2002 16:33:08 -0400. Date: Tue, 09 Jul 2002 10:27:51 +0200 From: Jaap Akkerhuis X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Whois can be scaled with replication, and you can obtain local copies if you really do a lot of analysis. Restrictions on whois use presently apply to abusive uses only. No. Restrictions on whois is not only related to abusive use. Privacy regulations in various jurisdictions also put heavy restrictions on whois use. The same is true for storing and using local copies. jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 06:49:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19089 for ; Tue, 9 Jul 2002 06:49:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RsKm-000AmL-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 03:35:04 -0700 Received: from [202.28.97.7] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17RsKQ-000Aks-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 03:34:49 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g69AYOI18966; Tue, 9 Jul 2002 17:34:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g69AXIf27358; Tue, 9 Jul 2002 17:33:33 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Simon Josefsson cc: David Conrad , Edward Lewis , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: References: <26507.1026197249@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jul 2002 17:33:18 +0700 Message-ID: <27356.1026210798@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 09 Jul 2002 11:53:11 +0200 From: Simon Josefsson Message-ID: | One RR per application is not needed. Solving the problem with SRV | style naming work. I'm not sure I belive that - I can think of cases where I am switching between web servers, all HTTP, all port 80 (or any other similar setup), but with a different key for each of them. | I don't buy that. Allocating a RR number for each security related | IETF protocol is no problem. If it were just one per protocol (in which case the RR name would probably be better as PROTOKEY or similar) I might just accept that. But when it can be one per application, which I think it probably needs to be, I don't. Even with protocols, it would help if we had an unused RR type cleanup mechanism (other than atrophy) but we don't. | Yes, it is ugly. How does that matter? It solves the problem and I | don't see any _technical_ problem. Can you translate ugliness into | something that will cause actual problems? If the "magic" name is X, and I happen to have already delegated X to some other organisation, there's no way I can stick any RR's at the X label, as it belongs to someone else now. Leave the namespace for delegations, the way it is intended to be used. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 07:20:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19752 for ; Tue, 9 Jul 2002 07:20:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RsxH-000Bkj-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 04:14:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Rsx9-000BkS-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 04:14:43 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17Rsx9-0005fx-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 04:14:43 -0700 References: <26507.1026197249@munnari.OZ.AU> In-Reply-To: <26507.1026197249@munnari.OZ.AU> (Robert Elz's message of "Tue, 09 Jul 2002 13:47:29 +0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Robert Elz Cc: David Conrad , Edward Lewis , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: Simon Josefsson Date: Tue, 09 Jul 2002 11:53:11 +0200 X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Robert Elz writes: > The problem is that the premise isn't true - what's needed is an APPKEY > for every application, not just one APPKEY RR. > > That leads to one of three possibilities - the APPKEY RDATA identifies > the application - but that solution simply doesn't work at all. One RR per application is not needed. Solving the problem with SRV style naming work. OTOH, I think it would be nicer to have one RR per application because it 1) doesn't use sub-typing which supposedly is bad and 2) it doesn't move semantics from the RR type field into the owner name field. The latter is only cosmetic, and the former only a minor advantage. Either solution would be fine. > Or there's a different APPKEY RR type for every different application. > That one would work fine, but now the groans above start to become more > like pained shouting. The 16 bit RR type space is currently huge, > but if we start numbering applications out of it, it will soon vanish. > So, this one really doesn't scale either. I don't buy that. Allocating a RR number for each security related IETF protocol is no problem. It wouldn't be a problem even if the RR type space was 8bit. Compare EAP's 8bit mechanism field. If only it was easier to introduce new RRs, I think this is the way to go actually. > Or, we start creating magic names for applications, to live in the > DNS, and so start to reserve namespace, which should be the end user's > prerogative to assign. That's ugly - no, it is truly foul (SRV managed > that, with protocols, of which there are a far smaller number than > applications, with the leading _ trick by pretending that no users would > ever actually want to assign names starting with an underscore). Yes, it is ugly. How does that matter? It solves the problem and I don't see any _technical_ problem. Can you translate ugliness into something that will cause actual problems? If not, I'd say the argument isn't very good. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 10:35:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26997 for ; Tue, 9 Jul 2002 10:35:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rvtp-000Gwc-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 07:23:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17Rvtc-000GwC-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 07:23:16 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.05) id 17Rvtb-000Al3-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 07:23:15 -0700 References: <26507.1026197249@munnari.OZ.AU> <27356.1026210798@munnari.OZ.AU> In-Reply-To: <27356.1026210798@munnari.OZ.AU> (Robert Elz's message of "Tue, 09 Jul 2002 17:33:18 +0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: Robert Elz Cc: David Conrad , Edward Lewis , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: Simon Josefsson Date: Tue, 09 Jul 2002 14:51:23 +0200 X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Robert Elz writes: > Date: Tue, 09 Jul 2002 11:53:11 +0200 > From: Simon Josefsson > Message-ID: > > | One RR per application is not needed. Solving the problem with SRV > | style naming work. > > I'm not sure I belive that - I can think of cases where I am switching > between web servers, all HTTP, all port 80 (or any other similar setup), > but with a different key for each of them. Hm. I'm not sure I follow, why wouldn't the following work if the web servers were called w1, w2 and w3, respectively? w1 IN A 1.2.3.4 IN NAPTR 1 10 "p" "APPKEY+ipsec" "" foo.keys foo.keys IN APPKEY MIIfoo= w2 IN A 1.2.3.5 IN NAPTR 1 10 "p" "APPKEY+ipsec" "" bar.keys bar.keys IN APPKEY MIIbar= w3 IN A 1.2.3.6 IN NAPTR 1 10 "p" "APPKEY+ipsec" "" baz.keys baz.keys IN APPKEY MIIbaz= Or simpler but a little bit less flexible (see below): w1 IN A 1.2.3.4 w1._ipsec IN APPKEY MIIfoo= w2 IN A 1.2.3.5 w2._ipsec IN APPKEY MIIfoo= w3 IN A 1.2.3.6 w3._ipsec IN APPKEY MIIfoo= > | I don't buy that. Allocating a RR number for each security related > | IETF protocol is no problem. > > If it were just one per protocol (in which case the RR name would > probably be better as PROTOKEY or similar) I might just accept that. > But when it can be one per application, which I think it probably needs > to be, I don't. Why would one be needed per application? That doesn't make sense to me. Rather, I envision that various IETF security protocols would write a profile document saying how keying material is stored in DNS. If each application defined its own use, there is no point in standardizing anything and this whole discussion is irrelevant. > Even with protocols, it would help if we had an unused RR type > cleanup mechanism (other than atrophy) but we don't. The IANA registry can deallocate allocated but unused RR types. Compare this to IP service ports, also allocated by IANA. It is also a 16 bit space. > | Yes, it is ugly. How does that matter? It solves the problem and I > | don't see any _technical_ problem. Can you translate ugliness into > | something that will cause actual problems? > > If the "magic" name is X, and I happen to have already delegated X to > some other organisation, there's no way I can stick any RR's at the X > label, as it belongs to someone else now. This isn't an issue if NAPTR is used. If NAPTR is not used, why would you have delegated a domain like _ipsec? If you care about app keys in DNS, you revoke the delegation and put your host IPSEC keys thereinstead. If you don't care about keys in DNS, you can continue to delegate the domain. This isn't really rocket science. > Leave the namespace for delegations, the way it is intended to be used. I am inclined to agree, but I still doesn't see any technical arguments, only cosmetic ones. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 11:32:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29343 for ; Tue, 9 Jul 2002 11:32:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RwmR-000Ih1-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 08:19:55 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17Rwls-000Iez-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 08:19:20 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g69FGWd12475; Tue, 9 Jul 2002 15:16:32 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g69FGbMP007006; Tue, 9 Jul 2002 10:16:37 -0500 (CDT) Date: Tue, 9 Jul 2002 10:16:34 -0500 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: David Conrad , Edward Lewis , namedroppers To: Robert Elz From: Ted Lemon In-Reply-To: <26507.1026197249@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Or, we start creating magic names for applications, to live in the > DNS, and so start to reserve namespace, which should be the end user's > prerogative to assign. That's ugly - no, it is truly foul (SRV managed > that, with protocols, of which there are a far smaller number than > applications, with the leading _ trick by pretending that no users would > ever actually want to assign names starting with an underscore). Let's say I have a host, toccata.fugue.com, with sshd running on it. So what's wrong with having an APPKEY hanging off of sshd.toccata.fugue.com? We don't currently use subdomains of hostnames - what's the conflicting use that we're ruining by doing this? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 11:37:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29477 for ; Tue, 9 Jul 2002 11:37:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rwtw-000Iyp-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 08:27:40 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17Rwsy-000Iwt-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 08:26:40 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g69FNtd12491; Tue, 9 Jul 2002 15:23:55 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g69FNxMP007009; Tue, 9 Jul 2002 10:23:59 -0500 (CDT) Date: Tue, 9 Jul 2002 10:23:59 -0500 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Simon Josefsson , David Conrad , Edward Lewis , namedroppers To: Robert Elz From: Ted Lemon In-Reply-To: <27356.1026210798@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Leave the namespace for delegations, the way it is intended to be used. No offense, Elz-san, but this is sounds like "the way I think it should be used," which isn't very constructive, since you are not the only one on the planet who uses it. My server's hostname is not a delegation. It's in the namespace. What do you mean, "the way it was intended to be used?" Who intended this? This sounds like "if God had meant us to hack, he would have given us ethernet jacks in the backs of our heads." Maybe it' s true, but here we are hacking, without the USB jacks, so the argument isn' t convincing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 11:49:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00130 for ; Tue, 9 Jul 2002 11:49:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Rx3h-000JLA-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 08:37:45 -0700 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 17Rx2U-000JHg-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 08:36:30 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with SMTP id g69FaSM22090; Tue, 9 Jul 2002 17:36:28 +0200 (MEST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id RAA21927; Tue, 9 Jul 2002 17:36:28 +0200 Message-Id: <200207091536.RAA21927@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Ted Lemon Cc: namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-reply-to: Your message of "Tue, 09 Jul 2002 10:16:34 CDT." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Tue, 09 Jul 2002 17:36:28 +0200 From: Peter Koch X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Let's say I have a host, toccata.fugue.com, with sshd running on it. So > what's wrong with having an APPKEY hanging off of sshd.toccata.fugue.com? While applications nicely fit into the hierarchical model (as well as e.g. interface names) ... > We don't currently use subdomains of hostnames - what's the conflicting use > that we're ruining by doing this? ... you can't tell for sure what a host is. How do you find the SSH key for the host "fugue.com" in your example? How do you find the "WWW" or "FTP" key? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 12:07:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01072 for ; Tue, 9 Jul 2002 12:07:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RxNn-000K9z-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 08:58:31 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17RxN8-000K8k-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 08:57:51 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g69FvWd12553; Tue, 9 Jul 2002 15:57:32 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g69FvaMP007069; Tue, 9 Jul 2002 10:57:36 -0500 (CDT) Date: Tue, 9 Jul 2002 10:57:36 -0500 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers To: Peter Koch From: Ted Lemon In-Reply-To: <200207091536.RAA21927@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-Id: <963F2332-9354-11D6-8575-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ... you can't tell for sure what a host is. How do you find the SSH key > for the host "fugue.com" in your example? How do you find the "WWW" or > "FTP" > key? Why, you use the PTR record! No, seriously, if fugue.com doesn't have an A record (and thus, a related appkey) then it has a CNAME that points you to the True Name of the host, doesn't it? So the appkey is going to be hanging off the appropriate subdomain of the CNAME. This isn't a problem, other than that it might make the appkey lookup code a little more tricky - it's a Simple Matter Of Programming. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 12:11:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01363 for ; Tue, 9 Jul 2002 12:11:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RxVR-000KTv-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 09:06:25 -0700 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 17RxVI-000KTi-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 09:06:16 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with SMTP id g69G6EM23044; Tue, 9 Jul 2002 18:06:14 +0200 (MEST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id SAA22014; Tue, 9 Jul 2002 18:06:14 +0200 Message-Id: <200207091606.SAA22014@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Ted Lemon Cc: namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-reply-to: Your message of "Tue, 09 Jul 2002 10:57:36 CDT." <963F2332-9354-11D6-8575-00039367340A@nominum.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Tue, 09 Jul 2002 18:06:14 +0200 From: Peter Koch X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > No, seriously, if fugue.com doesn't have an A record (and thus, a related > appkey) then it has a CNAME that points you to the True Name of the host, With current reality (delegations only in COM) it must not. So, "fugue.com" has an A RR and you have delegated "sshd.fugue.com" for fugue's "special strings harmony department". Now your key's name would fall into their namespace. Did you say "2782"? OK, make it _sshd.fugue.com. But then we have this "_" debate again. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 12:37:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02264 for ; Tue, 9 Jul 2002 12:37:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RxsA-000LNy-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 09:29:54 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17Rxqu-000LJi-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 09:28:36 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g69GSMd12649; Tue, 9 Jul 2002 16:28:22 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g69GSQMP007078; Tue, 9 Jul 2002 11:28:26 -0500 (CDT) Date: Tue, 9 Jul 2002 11:28:26 -0500 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers To: Peter Koch From: Ted Lemon In-Reply-To: <200207091606.SAA22014@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > With current reality (delegations only in COM) it must not. So, "fugue.com" > has an A RR and you have delegated "sshd.fugue.com" for fugue's "special > strings harmony department". Now your key's name would fall into their > namespace. Okay, I can see where this would be a problem in the case you describe. Everybody here who types "ssh mydomain.com" to lob in, please raise your hand? I guess this would be a problem for people who set up "fugue.com" as their web server address instead of "www.fugue.com", though. I never understood why that was such a great idea, but whatever. So fine, the key has to go at _sshd.fugue.com. Again, why's that a problem? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 14:23:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06186 for ; Tue, 9 Jul 2002 14:23:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17RzRu-000PCn-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 11:10:54 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17RzRN-000PAe-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 11:10:21 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id OAA19357; Tue, 9 Jul 2002 14:10:20 -0400 (EDT) Received: from [192.149.252.164] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA17779; Tue, 9 Jul 2002 14:10:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 9 Jul 2002 14:10:17 -0400 To: David Conrad , Edward Lewis From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:44 PM -0700 7/8/02, David Conrad wrote: >On 7/8/02 2:09 PM, "Edward Lewis" wrote: >Again, I'm confused how this is particularly relevant to DNSEXT. I wouldn't want to the WG to promote something that could do harm. (Answering why I think this is relavant - not arguing for the moment if the topic at hand would cause harm. What was the topic again?) >However, I fail to see how adding another RR, even a big RR like an APPKEY >could be, is going to trigger a "spectacular meltdown". What am I missing? Meltdown in the sense of a successful attack on DNS would undermine the applications depending on the DNS. >As for bandwidth consumption and latency, I would be somewhat stunned to >find that an X.509 CERT verification (including verification of CRL) is any >less consumptive of time or bandwidth from the end user's perspective (of >course, it will be less from the DNS server's perspective -- is that your >point?). No. When comparing an unsecured version of an application versus the secured version of the same application, more resources are needed. That's a given. >> After rereading 4.4 or 2535, yeah, I think that cache's shouldn't >> trim the TTL. For example, if a piece of data is ttl'd for 4 days >> but the key signing it is valid for 2 days, who's to say that the key >> won't be resigned for another 4 days? Why throw out the data when it >> will be valid again? > >Um. How do you know it is valid and not spoofed? Presumably the data arrived at the cache and was valid at the time. (In addition, the source indicates that the TTL should be high - the data isn't supposed to change and the source doesn't want to be bothered much.) Once the data arrives, why would the cache grow to be suspicious of it (barring other input). >> Try this for example: SSH (a security sensitive app) validates the >> IP address of a host. The net TTL of the validity is 120 seconds. >> Should SSH then end the connection in 120 seconds? > >If someone has made their key validity period be 120 seconds, then that >would appear to be the desired behavior, would it not? That depends on the application. Some might, some might not. Let's just make the DNS the "least common denominator" to account for the varying needs. >> DNS data is not real-time by its nature. > >Interesting theory. That explains why a TTL of 0 isn't allowed and why DNS >based load balancers are such complete failures. Err, wait... TTL's of 0 are approximating the "real-time" nature of DNS by suppressing caching, but load balancers are just speeding up processing. Even if you are using TTL's of 0 you aren't getting the full benefit of being real-time, there's no way to compare which 0-TTL's RR is "fresher." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 15:11:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10232 for ; Tue, 9 Jul 2002 15:10:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S0I4-0001Lh-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 12:04:48 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17S0Hd-0001K8-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 12:04:21 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 83DFA394; Tue, 9 Jul 2002 12:04:18 -0700 (PDT) Date: Tue, 9 Jul 2002 12:04:18 -0700 From: David Terrell To: Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020709120418.B6069@pianosa.catch22.org> Reply-To: David Terrell References: <25803.1026185223@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <25803.1026185223@munnari.OZ.AU>; from kre@munnari.OZ.AU on Tue, Jul 09, 2002 at 10:27:03AM +0700 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:02PM up 1 day, 11:54, 38 users, load averages: 0.33, 0.45, 0.42 X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Jul 09, 2002 at 10:27:03AM +0700, Robert Elz wrote: > All that is needed for us to reach this state, is to keep telling people that > they're *required* to implement IP6.ARPA domains for their address blocks. > If they're not required, or expected, to (and people stop attempting to force > them by idiotic, then no-one will bother with this nonsense, > they just won't bother having an IP6.ARPA zone at all, or if they have one, > it will have in it only the PTR records that the net admin wants to make > public. Even if I don't _require_ reverse DNS, I'd be happy to block such addresses just as a FU to those who do it. Very few people are insisting that we write "ip6.arpa records must be filled out for every address"; but I resist the claim that {ip6,in-addr}.arpa is useless on the face of it. Opt-in, sure, but useful nonetheless. -- David Terrell | "Let it be known that i think of Ashcroft as a dbt@meat.net | power-hungry Conserv-a-monkey who wouldn't know the Nebcorp Prime Minister | Constitution if he tore it up and used it for http://wwn.nebcorp.com | toilet paper." - Sean Willis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 15:24:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13889 for ; Tue, 9 Jul 2002 15:24:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S0QO-0001h4-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 12:13:24 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17S0PW-0001f3-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 12:12:30 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 69DA5393; Tue, 9 Jul 2002 12:12:29 -0700 (PDT) Date: Tue, 9 Jul 2002 12:12:29 -0700 From: David Terrell To: Robert Elz Cc: namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Message-ID: <20020709121229.C6069@pianosa.catch22.org> Reply-To: David Terrell References: <26507.1026197249@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <26507.1026197249@munnari.OZ.AU>; from kre@munnari.OZ.AU on Tue, Jul 09, 2002 at 01:47:29PM +0700 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:08PM up 1 day, 12:01, 38 users, load averages: 0.23, 0.30, 0.35 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Jul 09, 2002 at 01:47:29PM +0700, Robert Elz wrote: > Or, we start creating magic names for applications, to live in the > DNS, and so start to reserve namespace, which should be the end user's > prerogative to assign. That's ugly - no, it is truly foul (SRV managed > that, with protocols, of which there are a far smaller number than > applications, with the leading _ trick by pretending that no users would > ever actually want to assign names starting with an underscore). > > That there is no clean scheme that allows APPKEY to work reasonably > (assuming anyone would want to use it - if there are no actual users, > implementing it would be easy...) is why there's so much push back against > this one in particular. Well, if we've already _got_ magic names, and they're aren't actually SRV specific.... hostname IN A 10.0.1.1 _ssh._tcp.hostname IN SRV 0 0 22 hostname _ssh._tcp.hostname IN APPKEY "magic gloop" and associated SIG records. I wouldn't require that the APPKEY record require a matching SRV, to be sure; the usual port assumptions (or user configuration) can be used. -- David Terrell | "... a grandiose, wasteful drug war that will never dbt@meat.net | be won as long as so many Americans need to Nebcorp Prime Minister | anesthetize themselves to get through the day." http://wwn.nebcorp.com/ | -Camille Paglia -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 17:50:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19268 for ; Tue, 9 Jul 2002 17:50:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S2fg-0007Xn-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 14:37:20 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17S2fQ-0007WA-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 14:37:04 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id B91C4137F03; Tue, 9 Jul 2002 14:37:03 -0700 (PDT) To: rfc-editor@rfc-editor.org Cc: Erik.Nordmark@sun.com, rhall@quadritek.com, bmanning@ISI.EDU, mayer@gis.net, iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-reply-to: Your message of "Mon, 08 Jul 2002 19:34:41 GMT." <200207081934.TAA19083@jet.isi.edu> Date: Tue, 09 Jul 2002 21:37:03 +0000 From: Kevin Dunlap Message-Id: <20020709213703.B91C4137F03@shell.nominum.com> X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have found something in GSS Algorithm for TSIG (GSS-TSIG) draft-ietf-dnsext-gss-tsig-05.txt, that is in conflict with RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG). In draft-ietf-dnsext-gss-tsig-05.txt, Section 3.1.3.1: Second Paragraph: Confirmation is in the form of a query response with RCODE=NOERROR and with the last client supplied TKEY record in the answer section of the query. The Response MUST be signed with a TSIG record....... In the TSIG RFC, RFC 2845, section 4.2 says: When a server has generated a response to a signed request, it signs the response using the same algorithm and key. The server MUST not generate a signed response to an unsigned request. I think the fact that the GSS-TSIG TKEY exchange contains a TSIG on a response when the request did not contain one violates the TSIG RFC. I find this problem on April 19. At that point I notified two of the Authors of GSS-TSIG and the DNSEXT WG Co-chairs. I now realize, I forgot to post somthing to namedroppers. -Kevin ------------------- Your message dated: Mon, 08 Jul 2002 19:34:41 GMT >[ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > >Erik and Randy, > >We have ready to go. Should we be >waiting for an updated version of this document? > >Thank you. > >RFC Editor > > >> From rfc-ed@ISI.EDU Fri Apr 5 10:09:55 2002 >> Date: Fri, 05 Apr 2002 13:10:07 -0500 >> From: rhall@quadritek.com (Randy Hall) >> X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) >> X-Accept-Language: en >> MIME-Version: 1.0 >> To: Erik Nordmark >> CC: Bill Manning , Danny Mayer , >> iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, >> namedroppers@ops.ietf.org >> Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed > >> Standard >> Content-Transfer-Encoding: 7bit >> X-AntiVirus: scanned by AMaViS 0.2.1 >> >> Erik Nordmark wrote: >> >> > > There were (IMO) bugs in the TKEY, TSIG, and other protocols >> > > that needed fixing, and some changes (IMO) were needed (and >> > > made) to the protocol, but there were no IP issues relating >> > > these issues. >> >> > Where these bugs in the RFCs or bugs in an implementation of >> > those RFCs? >> >> Implementation. >> >> Cheers >> Randy >> > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 18:14:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20004 for ; Tue, 9 Jul 2002 18:14:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S33g-0008bf-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 15:02:08 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17S32c-0008Xp-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 15:01:02 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA04357; Tue, 9 Jul 2002 16:54:59 -0400 Date: Tue, 9 Jul 2002 16:55:27 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Derek Atkins cc: namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Yes, 'with DNSsec'. Supposing DNSsec _can't_ be spoofed (another assumption with uncertain truth), A signed garbage domain is still garbage. You don't know who or where the stuff in your log came from. Your resolver is happy, though. The bad guy just registers a domain with no information, signs up nameservice with no information. If thats not sufficient, they just deregister the domain. And I still don't expect that many domains will be secured with DNSsec, so what's in your logs could still be spoofed. Since you don't have any IP's, you have nothing to go on. --Dean On 8 Jul 2002, Derek Atkins wrote: > Dean Anderson writes: > > > Still a [wrong] +++ assumption +++: > > > > You don't have two administrative domains. You don't even have one, since > > both forward and reverse replies can be spoofed, or set by an > > untrustworthy administrative domain to be matching garbage. > > Not with DNSSec. > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 18:19:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20130 for ; Tue, 9 Jul 2002 18:19:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S3Dz-000972-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 15:12:47 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17S3DP-00095d-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 15:12:12 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA09084; Tue, 9 Jul 2002 18:12:10 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA20497; Tue, 9 Jul 2002 18:10:06 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id SAA23109; Tue, 9 Jul 2002 18:10:05 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA20604; Tue, 9 Jul 2002 18:10:06 -0400 (EDT) To: Dean Anderson Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue References: Date: 09 Jul 2002 18:10:06 -0400 In-Reply-To: Message-ID: Lines: 49 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,RCVD_IN_RELAYS_ORDB_ORG version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > Yes, 'with DNSsec'. Supposing DNSsec _can't_ be spoofed (another > assumption with uncertain truth), A signed garbage domain is still > garbage. You don't know who or where the stuff in your log came from. > Your resolver is happy, though. The bad guy just registers a domain with > no information, signs up nameservice with no information. If thats not > sufficient, they just deregister the domain. > > And I still don't expect that many domains will be secured with DNSsec, so > what's in your logs could still be spoofed. > > Since you don't have any IP's, you have nothing to go on. Dean, you're talking apples and oranges. First you say that domains can be spoofed. I maintain that DNSSec can protect against that. Then you go off and talk about registering phantom domains and setting up fake records to those phantom domains. What kinds of attacks are you worried about? From where I sit you can't seem to make up your mind and every time someone points out a flaw in your argument you change it. What other people are worrying about is the quazi-ephemeral nature of IPv6 addresses. A domain name is going to last a couple years in the databases. An ipv6 address is less likely to last quite so long (according to some). Having an IP address that has changed hands 5 times is much less useful than a domain-name. Does it mean the domain name is _REAL_? No. However if forward and reverse match (and the PTR does not point to itself), you have some validation about the existence of the domain. For example, while I can put a PTR to foo.ibm.com in my reverse domain, it's highly unlikely that I can get ibm.com to put it in their forward domain. Who cares if the answer is spoofed? We're not running military or life-or-death systems using this. It's a tool, like everything else, and a significant piece of the community find the tool useful. Perhaps tools should log both the IP Address _and_ the PTR record (and maybe whether the forward record matches). Should reverse domains be _MANDATORY_? Hell no. Should it be RECOMMENDED, yes. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 19:10:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20003 for ; Tue, 9 Jul 2002 18:14:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S34m-0008eF-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 15:03:16 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17S32i-0008Y0-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 15:01:08 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA05761; Tue, 9 Jul 2002 17:10:48 -0400 Date: Tue, 9 Jul 2002 17:11:16 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Eric Brunner-Williams in Portland Maine cc: namedroppers Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <200207090103.g6913evG004536@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Well, the exaggerations are getting more extreme, so perhaps we've reached the end of the useful part of the discussion. Whois is a client/server architecture that can be delegated and replicated. It is just as scalable as DNS, and having fewer complications than DNS, is arguably more scalable with less compute, bandwidth, and memory overhead. It has no comparision with HOSTS.TXT. Putting everything in DNS simply because you can't figure out how to write software is an unnecessary drain on DNS servers everywhere. I suppose one doesn't need LDAP, or any other protocol. I suppose one could even implement remote shells with DNS. Maybe we can do backups with DNS. I'd like to be in charge of that committee. Square Peg, Round hole: In some places the peg is too big for the hole. In others, its too small. This is exactly the sort of problem you have with using reverse DNS for authentication. Its not that reverse dns is totally useless, its that the utility value is less than the cost of the risk posed by its misuse as an authentication method, and the cost of garbage put in log files instead of useful information, such as the IP address. This misuse has a significant cost, and the utility is mostly, perhaps even completely, cosmetic. --Dean On Mon, 8 Jul 2002, Eric Brunner-Williams in Portland Maine wrote: > > On 7/8/02 1:33 PM, "Dean Anderson" wrote: > > > Whois can be scaled with replication, and you can obtain local copies if > > > you really do a lot of analysis. > > > > Can you say HOSTS.TXT? I knew you could. > > There is a difference. The data published by the NIC as HOSTS.TXT was > ephemerally accurate. The data published by whois publishers has the > endearing property of being persistently inextant or inaccurate. > > HOSTS.TXT, partially shredded. > > Cheers, > Eric > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 20:22:51 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22557 for ; Tue, 9 Jul 2002 20:22:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S58f-000ENn-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 17:15:25 -0700 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17S58A-000EMV-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 17:14:54 -0700 Received: from tecotoo.www.gis.net ([63.209.226.54]) by mx05.gis.net; Tue, 09 Jul 2002 20:14:51 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ma027702 for ; Tue, 9 Jul 2002 20:14:42 -0400 Message-Id: <4.3.1.2.20020709200922.00e1f140@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 09 Jul 2002 20:14:29 -0400 To: Dean Anderson , David Terrell From: Danny Mayer Subject: Re: (ngtrans) The reverse lookup issue Cc: Toshi Yamasaki , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: References: <20020708103321.B7809@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:03 PM 7/8/02, Dean Anderson wrote: > A domain name registration record represents $10. Sometimes less. >DNSSEC (when it is used), will get you to someone who paid $10 and didn't >leave any addresses or phone numbers. (one could say DNSSec [if it works, >and is used] is a lot of trouble for securing something worth $10). You are not really securing the domain as much as you are making the user secure in that he has received a valid answer to a lookup for that domain. The difference may seem subtle, but the domain does nothing with the data, it's the client that uses it. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 21:54:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24274 for ; Tue, 9 Jul 2002 21:54:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S6SI-000Hx5-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 18:39:46 -0700 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 17S6S1-000HwO-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 18:39:29 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.5/8.11.6) with ESMTP id g6A1d6vG008160; Tue, 9 Jul 2002 21:39:06 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200207100139.g6A1d6vG008160@nic-naa.net> To: Dean Anderson cc: Eric Brunner-Williams in Portland Maine , namedroppers , brunner@nic-naa.net Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Your message of "Tue, 09 Jul 2002 17:11:16 EDT." Date: Tue, 09 Jul 2002 21:39:06 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Well, the exaggerations are getting more extreme, so perhaps we've reached > the end of the useful part of the discussion. You may be right. > Whois is a client/server architecture that can be delegated and > replicated. It is just as scalable as DNS, and having fewer complications > than DNS, is arguably more scalable with less compute, bandwidth, and > memory overhead. It has no comparision with HOSTS.TXT. 954 doesn't mention delegation or replication. Neither does 812, nor does 742. If you are discussing an implementation, could you be specific as to which you are referring to? Eric -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 9 23:59:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26678 for ; Tue, 9 Jul 2002 23:59:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17S8OR-000NKe-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 20:43:55 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.36 #1) id 17S8OJ-000NJc-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 20:43:47 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 10 Jul 2002 03:43:46 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Tue, 9 Jul 2002 23:43:37 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002070923433616289 ; Tue, 09 Jul 2002 23:43:36 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <3FF8L6DX>; Tue, 9 Jul 2002 23:43:29 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2CC0@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Dean Anderson '" Cc: "'namedroppers '" Subject: RE: (ngtrans) The reverse lookup issue Date: Tue, 9 Jul 2002 23:43:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson wrote: > Well, the exaggerations are getting more extreme, so perhaps > we've reached the end of the useful part of the discussion. I still strongly disagree with most of the points you're trying to make, and you've not attempted to rebut my last message on the subject--or convingly addressed several other messages which were more coherent/concise IMHO. I'm not sure why your statement above should be considered productive. With all due respect, please educate me. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 02:39:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22698 for ; Wed, 10 Jul 2002 02:39:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SB2M-0004bu-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 23:33:18 -0700 Received: from [43.254.8.36] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17SB2G-0004bi-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 23:33:13 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17SB1G-0002tW-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 23:32:10 -0700 References: <200207091606.SAA22014@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200207091606.SAA22014@grimsvotn.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Tue, 09 Jul 2002 18:06:14 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Peter Koch Cc: Ted Lemon , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: Simon Josefsson Date: Tue, 09 Jul 2002 18:40:10 +0200 X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Peter Koch writes: >> No, seriously, if fugue.com doesn't have an A record (and thus, a related >> appkey) then it has a CNAME that points you to the True Name of the host, > > With current reality (delegations only in COM) it must not. So, "fugue.com" > has an A RR and you have delegated "sshd.fugue.com" for fugue's "special > strings harmony department". Now your key's name would fall into their > namespace. So what? If you delegate away a critical zone, it is your loss. Naturally the name "sshd." could be chosen differently so that people normally don't have to revoke delegations to take advantage of this, thus "_sshd.". You can see from another angle too. Consider that you trust the Special Strings Harmony Department to handle keys better than yourself, then you can delegate this responsibility to them. > Did you say "2782"? OK, make it _sshd.fugue.com. But then we have this "_" > debate again. Please summarize the technical arguments from the debate so we don't have to go through it again. Did someone dislike the "_" character? None of this applies if NAPTR is used, of course. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 02:44:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22811 for ; Wed, 10 Jul 2002 02:44:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SB0y-0004XB-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 23:31:52 -0700 Received: from [43.254.8.36] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17SB0C-0004Vc-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 23:31:04 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17SB03-0002tL-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 23:30:55 -0700 References: <200207091536.RAA21927@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200207091536.RAA21927@grimsvotn.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Tue, 09 Jul 2002 17:36:28 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Peter Koch Cc: Ted Lemon , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: Simon Josefsson Date: Tue, 09 Jul 2002 18:14:38 +0200 X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Peter Koch writes: >> Let's say I have a host, toccata.fugue.com, with sshd running on it. So >> what's wrong with having an APPKEY hanging off of sshd.toccata.fugue.com? > > While applications nicely fit into the hierarchical model (as well as > e.g. interface names) ... > >> We don't currently use subdomains of hostnames - what's the conflicting use >> that we're ruining by doing this? > > ... you can't tell for sure what a host is. How do you find the SSH key > for the host "fugue.com" in your example? How do you find the "WWW" or "FTP" > key? Huh? In a DNS-centric world; a host is a domain name with at least one IN A, IN A6 or IN AAAA record. Given a name of a host, to find the SSH key you prepend "ssh.". In your examples, the answer to your question would be "ssh.fugue.com IN APPKEY", "WWW.fugue.com IN APPKEY" and "FTP.fugue.com IN APPKEY", respectively. What's the problem? I'm not saying prepending "ssh." is a good solution, but the only argument against it presented so far seem to be design religious ones. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 02:48:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22884 for ; Wed, 10 Jul 2002 02:48:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SB5S-0004lQ-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 23:36:30 -0700 Received: from [43.254.8.36] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17SB5F-0004kv-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 23:36:19 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17SB57-0002tu-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 23:36:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <200207091606.SAA22014@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-Id: Date: Tue, 09 Jul 2002 23:36:09 -0700 X-Spam-Status: No, hits=-1.4 required=5.0 tests=X_NOT_PRESENT,TO_LOCALPART_EQ_REAL version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit this discussion is about how to put app keys in the dns. but there is a different list for that. using namedroppers is disenfranchisng those who think the topic will be discussed there. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 02:55:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23061 for ; Wed, 10 Jul 2002 02:55:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SBJe-0005Wr-00 for namedroppers-data@psg.com; Tue, 09 Jul 2002 23:51:10 -0700 Received: from [43.254.8.36] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17SBJL-0005Tw-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 23:51:05 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17SBCJ-0002ub-00 for namedroppers@ops.ietf.org; Tue, 09 Jul 2002 23:43:35 -0700 References: In-Reply-To: (Edward Lewis's message of "Tue, 9 Jul 2002 14:10:17 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Edward Lewis Cc: David Conrad , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: Simon Josefsson Date: Tue, 09 Jul 2002 21:14:26 +0200 X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Edward Lewis writes: > At 10:44 PM -0700 7/8/02, David Conrad wrote: >>On 7/8/02 2:09 PM, "Edward Lewis" wrote: >>Again, I'm confused how this is particularly relevant to DNSEXT. > > I wouldn't want to the WG to promote something that could do > harm. (Answering why I think this is relavant - not arguing for the > moment if the topic at hand would cause harm. What was the topic > again?) The topic was if the KEY RR should be made DNSSEC-only without offering a transition path for people who want to use it for what it was defined in RFC 2535 to support. Some solutions: 1) State in the document that application keys in DNS is a bad idea and it is now forbidden to do this. 2) State in the document that applications should transition to APPKEY. This would mean shipping it together with APPKEY, which could be made similar to what KEY is today (which I think it mostly is, or?). The APPKEY document could be silent on if it is a good idea, how owner names are used or anything like that. This would keep the status quo. 3) State in the document that applications should transition to CERT. This would mean releasing an updated version of the CERT RFC (which would be useful anyhow, it is unclear on several things) that adds a sentence that clarifies that it is OK to store unsigned structures within the RRDATA. 4) ? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 04:38:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24772 for ; Wed, 10 Jul 2002 04:38:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SClT-0008vA-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 01:23:59 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17SClF-0008tT-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 01:23:45 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 401AB137F06; Wed, 10 Jul 2002 01:23:45 -0700 (PDT) To: Simon Josefsson Cc: Peter Koch , Ted Lemon , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: Message from Simon Josefsson of "Tue, 09 Jul 2002 18:14:38 +0200." Date: Wed, 10 Jul 2002 01:23:45 -0700 Message-ID: <6560.1026289425@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Simon" == Simon Josefsson writes: Simon> Given a name of a host, to find the SSH key you prepend Simon> "ssh.". In your examples, the answer to your question Simon> would be "ssh.fugue.com IN APPKEY", "WWW.fugue.com IN Simon> APPKEY" and "FTP.fugue.com IN APPKEY", respectively. Simon> What's the problem? Well what if I had a host called ssh.fugue.com? Or what if prepending the protocol name makes the overall domain name too long? I think that prepending the protocol name isn't so bad though it is a bit ugly. But the label for the protocol name should probably include an underscore so it doesn't clash with a hostname, just like underscores in SRV records. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 04:39:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24788 for ; Wed, 10 Jul 2002 04:39:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SCpu-00093b-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 01:28:34 -0700 Received: from 61.193.166.83 ([61.193.166.83] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17SCpq-00093G-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 01:28:30 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17SCom-000375-00; Wed, 10 Jul 2002 01:27:24 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Simon Josefsson Cc: namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: Message-Id: Date: Wed, 10 Jul 2002 01:27:24 -0700 X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1) State in the document that application keys in DNS is a bad idea > and it is now forbidden to do this. > > 2) State in the document that applications should transition to > APPKEY. This would mean shipping it together with APPKEY, which > could be made similar to what KEY is today (which I think it mostly > is, or?). The APPKEY document could be silent on if it is a good > idea, how owner names are used or anything like that. This would > keep the status quo. > > 3) State in the document that applications should transition to CERT. > This would mean releasing an updated version of the CERT RFC (which > would be useful anyhow, it is unclear on several things) that adds > a sentence that clarifies that it is OK to store unsigned > structures within the RRDATA. > > 4) ? this are items for the siked effort. this document should not try to encompass that effort. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 04:48:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24956 for ; Wed, 10 Jul 2002 04:48:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SCvl-0009JF-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 01:34:37 -0700 Received: from bdsl.66.12.174.102.gte.net ([66.12.174.102] helo=mail.digitalmarketplace.com) by psg.com with esmtp (Exim 3.36 #1) id 17SCvZ-0009Im-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 01:34:25 -0700 Received: from win2kdev ([208.3.65.171]) by mail.digitalmarketplace.com with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 10 Jul 2002 02:13:22 -0700 Reply-To: From: "Jason Coombs" To: "namedroppers" Subject: RE: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Date: Tue, 9 Jul 2002 22:43:40 -1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1) State in the document that application keys in DNS is a bad idea > and it is now forbidden to do this. Application keys in DNS may be a bad idea, period. Infosec best practices say simplify and remove features if you want security. The square peg round hole argument alone is strong, but combine it with what we've learned about how to write secure software over the last 20 years or so and I'm surprised there's even anything to debate... Applications that use the KEY RR today for anything other than DNSSEC are security-flawed for practical reasons if not for cryptographic ones. Practical security, how security is accomplished in practice, must be considered by this standards working group or else it might as well make the Windows Scripting Host a REQUIRED part of all DNSSEC resolvers. Specialized key servers are a great idea. In practice, expecting programmers and administrators to manage security for APPKEY as long as they're already managing security for DNSSEC is a non starter. These are different application domains and must be secured as such. The DNSSEC architecture meets only a subset of the needs of a generic key service. Keys for individual authenticated identities, keys for transactions associated with those identities, keys for short time periods, keys for long time periods, keys for hashing, keys for encryption, keys for verifying digital signatures, mechanisms to log every use of a key, mechanisms to log no use of a key, options to store and disseminate signed keyed hashes of files so that operating system vendors and others can reliably distribute authentic hash codes that can be used to detect the presence of malicious code on compromised boxes, and server awareness of successful key delivery are just some of the key service features that should exist that are unlikely to ever occur within the context of DNSSEC. Misappropriating DNSSEC because it exists and can serve data applicable only to other applications is no different than defining an XML Web service to serve application-specific purposes according to a single common standard. More importantly, HTTP servers exist and are widespread. DNSSEC servers are few. The problem of insecure DNS is acute, and anything that might hold up DNSSEC server deployment must be killed. Otherwise we should be discussing an XML Web service standard as the distribution mechanism for DNSSEC RRs instead of specialized name servers using port 53. I recommend no migration path or backwards compatibility for non-DNSSEC uses of the KEY RR. And while anyone can do anything they want to create custom implementations of DNSSEC, I don't see it as productive to practical information security for the DNSSEC to be adapted and extended as a generic key service as part of the IETF standard. Spin off that functionality and assign it a new port number. Don't clutter DNSSEC with unrelated APPKEY functionality. Sincerely, Jason Coombs jasonc@science.org -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Simon Josefsson Sent: Tuesday, July 09, 2002 9:14 AM To: Edward Lewis Cc: David Conrad; namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Edward Lewis writes: > At 10:44 PM -0700 7/8/02, David Conrad wrote: >>On 7/8/02 2:09 PM, "Edward Lewis" wrote: >>Again, I'm confused how this is particularly relevant to DNSEXT. > > I wouldn't want to the WG to promote something that could do > harm. (Answering why I think this is relavant - not arguing for the > moment if the topic at hand would cause harm. What was the topic > again?) The topic was if the KEY RR should be made DNSSEC-only without offering a transition path for people who want to use it for what it was defined in RFC 2535 to support. Some solutions: 1) State in the document that application keys in DNS is a bad idea and it is now forbidden to do this. 2) State in the document that applications should transition to APPKEY. This would mean shipping it together with APPKEY, which could be made similar to what KEY is today (which I think it mostly is, or?). The APPKEY document could be silent on if it is a good idea, how owner names are used or anything like that. This would keep the status quo. 3) State in the document that applications should transition to CERT. This would mean releasing an updated version of the CERT RFC (which would be useful anyhow, it is unclear on several things) that adds a sentence that clarifies that it is OK to store unsigned structures within the RRDATA. 4) ? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 07:01:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27609 for ; Wed, 10 Jul 2002 07:01:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SF3j-000E7b-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 03:50:59 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17SF3H-000E6v-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 03:50:32 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g6AAoNwF001736; Wed, 10 Jul 2002 12:50:23 +0200 To: Jim Reid Cc: Peter Koch , Ted Lemon , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <6560.1026289425@shell.nominum.com> X-Hashcash: 020710:Jim.Reid@nominum.com:69fdc6c37da3fb8a X-Hashcash: 020710:pk@TechFak.Uni-Bielefeld.DE:65fb1a10447e7833 X-Hashcash: 020710:Ted.Lemon@nominum.com:85ab0363ab152ce2 X-Hashcash: 020710:namedroppers@ops.ietf.org:973ec753aeb78440 From: Simon Josefsson Date: Wed, 10 Jul 2002 12:50:23 +0200 In-Reply-To: <6560.1026289425@shell.nominum.com> (Jim Reid's message of "Wed, 10 Jul 2002 01:23:45 -0700") Message-ID: Lines: 33 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> Given a name of a host, to find the SSH key you prepend > Simon> "ssh.". In your examples, the answer to your question > Simon> would be "ssh.fugue.com IN APPKEY", "WWW.fugue.com IN > Simon> APPKEY" and "FTP.fugue.com IN APPKEY", respectively. > Simon> What's the problem? > > Well what if I had a host called ssh.fugue.com? Yes, how does that create a problem? > Or what if prepending the protocol name makes the overall domain > name too long? If this scheme is used (which I think is a bad idea), then you must change the domain name in order to use application keys in DNS. If you are not willing to do that, noone is forcing you. > I think that prepending the protocol name isn't so bad though it is > a bit ugly. But the label for the protocol name should probably > include an underscore so it doesn't clash with a hostname, just like > underscores in SRV records. I agree. Using the owner name for this is not a good idea, but my point is that it would "work". I think I prefer NAPTR, it gives all the advantages of being able to delegate application key zones to trusted third parties without the disadvantages of overloading the owner name field and possible name clashes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 07:01:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27624 for ; Wed, 10 Jul 2002 07:01:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SF6b-000EEO-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 03:53:57 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17SF5y-000ED7-00; Wed, 10 Jul 2002 03:53:18 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g6AArGwF001748; Wed, 10 Jul 2002 12:53:16 +0200 To: Randy Bush Cc: namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: X-Hashcash: 020710:randy@psg.com:059104b281a44be4 X-Hashcash: 020710:namedroppers@ops.ietf.org:19bddb4955826f39 From: Simon Josefsson Date: Wed, 10 Jul 2002 12:53:16 +0200 In-Reply-To: (Randy Bush's message of "Wed, 10 Jul 2002 01:27:24 -0700") Message-ID: Lines: 26 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush writes: >> 1) State in the document that application keys in DNS is a bad idea >> and it is now forbidden to do this. >> >> 2) State in the document that applications should transition to >> APPKEY. This would mean shipping it together with APPKEY, which >> could be made similar to what KEY is today (which I think it mostly >> is, or?). The APPKEY document could be silent on if it is a good >> idea, how owner names are used or anything like that. This would >> keep the status quo. >> >> 3) State in the document that applications should transition to CERT. >> This would mean releasing an updated version of the CERT RFC (which >> would be useful anyhow, it is unclear on several things) that adds >> a sentence that clarifies that it is OK to store unsigned >> structures within the RRDATA. >> >> 4) ? > > this are items for the siked effort. this document should not try > to encompass that effort. As the restrict-key-for-dnssec document currently reads, it choses 1) above but only implicitely. Thus the document takes a stand in the siked discussion by forbidding the use of KEY for that purpose. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 08:04:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28711 for ; Wed, 10 Jul 2002 08:04:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SG4F-000GVj-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 04:55:35 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17SG47-000GVP-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 04:55:27 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id B4D65137F03; Wed, 10 Jul 2002 04:55:26 -0700 (PDT) To: Simon Josefsson Cc: Peter Koch , Ted Lemon , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: Message from Simon Josefsson of "Wed, 10 Jul 2002 12:50:23 +0200." Date: Wed, 10 Jul 2002 04:55:26 -0700 Message-ID: <8253.1026302126@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Simon" == Simon Josefsson writes: Simon> Given a name of a host, to find the SSH key you prepend Simon> "ssh.". In your examples, the answer to your question Simon> would be "ssh.fugue.com IN APPKEY", "WWW.fugue.com IN Simon> APPKEY" and "FTP.fugue.com IN APPKEY", respectively. Simon> What's the problem? >> Well what if I had a host called ssh.fugue.com? Simon> Yes, how does that create a problem? Apologies,I was not clear. Suppose I delegate ssh.fugue.com and there's an A record for fugue.com which has an ssh key. In your scheme, that ssh key would have to go in the child zone which may be under a different administrative control. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 08:05:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28725 for ; Wed, 10 Jul 2002 08:05:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SG6P-000Ga6-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 04:57:49 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17SG6I-000GZu-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 04:57:42 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g6ABvcwF002347; Wed, 10 Jul 2002 13:57:38 +0200 To: Jim Reid Cc: Peter Koch , Ted Lemon , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <8253.1026302126@shell.nominum.com> X-Hashcash: 020710:Jim.Reid@nominum.com:7600ef24fe34fb96 X-Hashcash: 020710:pk@TechFak.Uni-Bielefeld.DE:9abf9d4e01a5103b X-Hashcash: 020710:Ted.Lemon@nominum.com:a439322b201b49a2 X-Hashcash: 020710:namedroppers@ops.ietf.org:49e679ac48cbb441 From: Simon Josefsson Date: Wed, 10 Jul 2002 13:57:38 +0200 In-Reply-To: <8253.1026302126@shell.nominum.com> (Jim Reid's message of "Wed, 10 Jul 2002 04:55:26 -0700") Message-ID: Lines: 20 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> Given a name of a host, to find the SSH key you prepend > Simon> "ssh.". In your examples, the answer to your question > Simon> would be "ssh.fugue.com IN APPKEY", "WWW.fugue.com IN > Simon> APPKEY" and "FTP.fugue.com IN APPKEY", respectively. > Simon> What's the problem? > >> Well what if I had a host called ssh.fugue.com? > > Simon> Yes, how does that create a problem? > > Apologies,I was not clear. Suppose I delegate ssh.fugue.com and > there's an A record for fugue.com which has an ssh key. In your > scheme, that ssh key would have to go in the child zone which may be > under a different administrative control. I see. Yes, that is a problem. That's why I'm not proposing that scheme; NAPTR seems more flexible. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 08:48:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00537 for ; Wed, 10 Jul 2002 08:48:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SGlg-000IGt-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 05:40:28 -0700 Received: from [202.28.97.7] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17SGl9-000IDX-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 05:40:02 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g6ACdY815577; Wed, 10 Jul 2002 19:39:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6ACcTf03076; Wed, 10 Jul 2002 19:38:32 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Ted Lemon cc: David Conrad , Edward Lewis , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Jul 2002 19:38:29 +0700 Message-ID: <3074.1026304709@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 9 Jul 2002 10:16:34 -0500 From: Ted Lemon Message-ID: | We don't currently use subdomains of hostnames - what's the conflicting use | that we're ruining by doing this? Says who? We currently put "hostnames" anywhere in the DNS tree that we like. Ted.Lemon@nominum.com said in a different message: | No offense, Elz-san, but this is sounds like "the way I think it | should be used," which isn't very constructive, since you are not the | only one on the planet who uses it. My server's hostname is not a | delegation. It's in the namespace. What do you mean, "the way it | was intended to be used?" If the namespace was delegated to you, it should be your choice how you use it. If you don't want your server's hostnames to be delegated, or to have delegated sub-domains, or whatever, that's your choice, as it should be. Just stop trying to tell everyone else that they're required to assign names, and perform delegations in the way that you believe it should be done - every domain name owner gets to decide this for themselves. And that includes sticking _'s anywhere in any domain name that they like. And almost any other character. The only restrictions are that the names not violate the rules of the protocols in which they're used (the DNS's rules relate to lengths, and no more, other protocols have other rules). If I want to do example.com. IN MX _sshd.example.com. _sshd.example.com. IN NS some.random.other.site. Then that's what I should be allowed to do (regardless of how stupid that you believe it is, it is legal, and there are reasons for doing just this - if perhaps not that particular name). No-one should be defining away the namespace to make that cause things to fail. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 09:04:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01260 for ; Wed, 10 Jul 2002 09:04:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SH1o-000J0P-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 05:57:08 -0700 Received: from 61.193.166.83 ([61.193.166.83] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17SH1d-000IzG-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 05:56:58 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17SH1R-0003H4-00; Wed, 10 Jul 2002 05:56:46 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Simon Josefsson Cc: namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: Message-Id: Date: Wed, 10 Jul 2002 05:56:46 -0700 X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> 1) State in the document that application keys in DNS is a bad idea >> and it is now forbidden to do this. > As the restrict-key-for-dnssec document currently reads, it choses 1) > above but only implicitely. no it does not. saying don't use A for X does not in any way imply don't do X randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 11:25:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06804 for ; Wed, 10 Jul 2002 11:25:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SJ6Y-000OXN-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 08:10:10 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17SJ5E-000OSD-00; Wed, 10 Jul 2002 08:08:48 -0700 Received: from isi.edu (c1-vpn3.isi.edu [128.9.176.29]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g6AF8gr09176; Wed, 10 Jul 2002 08:08:42 -0700 (PDT) Message-ID: <3D2C4E29.D993D457@isi.edu> Date: Wed, 10 Jul 2002 11:09:29 -0400 From: Dan Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Simon Josefsson , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > >> 1) State in the document that application keys in DNS is a bad idea > >> and it is now forbidden to do this. > > As the restrict-key-for-dnssec document currently reads, it choses 1) > > above but only implicitely. > > no it does not. saying don't use A for X does not in any way imply > don't do X > > randy If I say don't use the A record for IPv6 addresses, that does not implicitly mean that IPv6 addresses don't belong in the DNS. Key restrict says don't use the KEY record for application keys. That does not implicity mean application keys don't belong in the DNS. In fact, the draft explicitly states: > The scope of this document is strictly limited to the KEY record. > This document prohibits storing application keys in the KEY record, > but it does not endorse or restrict the storing application keys in > other record types. Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 11:40:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07522 for ; Wed, 10 Jul 2002 11:40:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SJSb-000PZ0-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 08:32:57 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17SJRs-000PW7-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 08:32:12 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29550; Wed, 10 Jul 2002 11:31:59 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA01258; Wed, 10 Jul 2002 11:31:57 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA14723; Wed, 10 Jul 2002 11:31:57 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA22701; Wed, 10 Jul 2002 11:31:55 -0400 (EDT) To: Robert Elz Cc: Ted Lemon , David Conrad , Edward Lewis , namedroppers From: Derek Atkins Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <3074.1026304709@munnari.OZ.AU> Date: 10 Jul 2002 11:31:55 -0400 In-Reply-To: <3074.1026304709@munnari.OZ.AU> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > If I want to do > > example.com. IN MX _sshd.example.com. > _sshd.example.com. IN NS some.random.other.site. > > Then that's what I should be allowed to do (regardless of how stupid > that you believe it is, it is legal, and there are reasons for doing > just this - if perhaps not that particular name). > > No-one should be defining away the namespace to make that cause things > to fail. Nobody is proposing any such thing. Nobody is making restrictions on what you _can_ do. However, this is a proposal just that "if you want to do FOO, do it _this_ way" in order to be compatible with everyone else. This is NOT the same thing. If the proposal for "if you want to store an SSHD key in DNS, you should prepend _sshd to the hostname" goes through, you can still do what you want as your suggest, but you just will not be able to store SSHD keys in DNS following the convention. But that is perfectly within your right as a zone operator to not follow conventions. It just means your zone wont play with existing applications that use those features. If you don't want to provide those features, you are well within your rights to make that choice. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 12:13:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09303 for ; Wed, 10 Jul 2002 12:13:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SJwq-00010g-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 09:04:12 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17SJvm-0000yD-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 09:03:07 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id LAA01687; Wed, 10 Jul 2002 11:10:33 -0400 Date: Wed, 10 Jul 2002 11:11:02 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Derek Atkins cc: namedroppers@ops.ietf.org Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 9 Jul 2002, Derek Atkins wrote: > Dean, you're talking apples and oranges. First you say that domains > can be spoofed. I maintain that DNSSec can protect against that. The problem is the improper use of reverse dns for authentication and access control. There are multiple ways that reverse dns-dependency can be exploited, both with and without DNSsec. I'm sorry if that isn't clear. The fundamental harm is using reverse DNS as the basis for 1) authenication/validation 2) logging of the communication. Logging is to identify when, what, and who. If you can't identify "who", because you used a reverse DNS entry that has only cosmetic value, you have failed in the logging task. When people put host.example.com in their firewall configuration, this can be spoofed, and access granted inappropriately. DNSsec _could_ (big assumption) _possibly_ fix that case (only that case) _if_ the specific domain in question is signed, and DNSsec can't be spoofed. However, DNSsec cannot fix the case of validation, nor can it solve the logging problem. DNSsec only protects the domain that is signed. Even if DNSsec is "widely" deployed, it is unlikely that everyone would use it, and even unlikely that many would use it. If DNSsec were required, then it is still possible, as I said, to register a fake domain for a short time to put useless data in your logs or satisfy your "validation" check. There is no way to strengthen DNS to make your "validation" assumption true, even including DNSsec. The problem isn't specific to IPv6. It is the same on v6 and v4. You have no validation of the existance of the domain, except through whois for the domain, which as was pointed out, can easilly be faked on many domain registries. That reverse and forward match means exactly nothing. By contrast, the Address space registries are usually dealing with businesses and so their records are much more trustworthy. I have yet to see an ARIN record with 000-000-0000 as the phone and no address, and no name. Sometimes the addresses and phone numbers are wrong, because the businesses have moved, but the businesses can still be found. The only thing that is even remotely tangible is an IP address. The next thing you'll say is that the reverse record comes from the address registry: It doesn't. It is often delegated to the end user, who can set it to garbage. Then your "validation" may succeed, but your log entry is useless. (This is without spoofing---They could still be spoof the same useless garbage). If you had the IP address instead, it would not be so useless. The expected "quasi-ephemeral" nature of IPv6 address just makes the current reverse system even harder to maintain than it is now, so "validation" demands are even sillier than they are now. But the essential silliness of the proposition that there is some meaning to be attached when forward and reverse match is independent of v4 and v6. The problem is that reverse dns is being used inappropriately as snake oil, and people like you keep insisting that there is meaning to something that is meaningless, and you cause significant harm by doing so. That is why we should deprecate reverse dns. Yes, that basically ruins it for everyone who liked the cosmetic uses. But the alternative is worse. --Dean > Then you go off and talk about registering phantom domains and setting > up fake records to those phantom domains. What kinds of attacks are > you worried about? From where I sit you can't seem to make up your > mind and every time someone points out a flaw in your argument you > change it. > > What other people are worrying about is the quazi-ephemeral nature of > IPv6 addresses. A domain name is going to last a couple years in the > databases. An ipv6 address is less likely to last quite so long > (according to some). Having an IP address that has changed hands 5 > times is much less useful than a domain-name. > > Does it mean the domain name is _REAL_? No. However if forward and > reverse match (and the PTR does not point to itself), you have some > validation about the existence of the domain. For example, while I > can put a PTR to foo.ibm.com in my reverse domain, it's highly > unlikely that I can get ibm.com to put it in their forward domain. > > Who cares if the answer is spoofed? We're not running military or > life-or-death systems using this. It's a tool, like everything else, > and a significant piece of the community find the tool useful. > Perhaps tools should log both the IP Address _and_ the PTR record (and > maybe whether the forward record matches). > > Should reverse domains be _MANDATORY_? Hell no. Should it be > RECOMMENDED, yes. > > -derek > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 12:25:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09733 for ; Wed, 10 Jul 2002 12:25:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SKBN-0001g7-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 09:19:13 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17SKBI-0001fn-00; Wed, 10 Jul 2002 09:19:08 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6AGIrd15794; Wed, 10 Jul 2002 16:18:53 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6AGIwMP007416; Wed, 10 Jul 2002 11:18:58 -0500 (CDT) Date: Wed, 10 Jul 2002 11:18:57 -0500 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Simon Josefsson , namedroppers To: Randy Bush From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > this are items for the siked effort. this document should not try > to encompass that effort. I believe that the argument was that the restrict-key-for-dnssec draft should not advance in the absence of an app-key draft advancing, because otherwise we lose functionality. So if we make a normative reference to the app key draft in the restrict-key draft, that solves that problem. : '} -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 13:30:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12322 for ; Wed, 10 Jul 2002 13:30:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SL9X-0004Ua-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 10:21:23 -0700 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.36 #1) id 17SL9I-0004UE-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 10:21:08 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id NAA04978; Wed, 10 Jul 2002 13:20:43 -0400 (EDT) Message-ID: <008d01c22835$4dc8faf0$b9370681@BARNACLE> From: "Scott Rose" To: "Ted Lemon" , Cc: "namedroppers" References: Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Date: Wed, 10 Jul 2002 13:14:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There was a reference to APPKEY (Jakob's draft? not certain and I don't have it in front of me). It was taken out (by me probably) when we saw that there was a lot of debate about how to store application keys in the DNS. The APPKEY draft only proposed one possible solution and we didn't want to say it was the choice option. A reference to any application key draft could be included, just to say other means exist and are being debated. As for the overlap between Restrict-KEY and the DS RR draft: I think I understand the comment. A referrence to how Restrict-KEY will update the last part of the DS RR intro. correct me if I'm wrong. Scott ----- Original Message ----- From: "Ted Lemon" To: "Randy Bush" Cc: "Simon Josefsson" ; "namedroppers" Sent: Wednesday, July 10, 2002 12:18 PM Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt > > this are items for the siked effort. this document should not try > > to encompass that effort. > > I believe that the argument was that the restrict-key-for-dnssec draft > should not advance in the absence of an app-key draft advancing, because > otherwise we lose functionality. So if we make a normative reference to > the app key draft in the restrict-key draft, that solves that problem. : > '} > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 14:09:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13728 for ; Wed, 10 Jul 2002 14:09:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SLow-0006ST-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 11:04:10 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17SLoq-0006Rk-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 11:04:04 -0700 Received: from isi.edu (c1-vpn3.isi.edu [128.9.176.29]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g6AI3lr06079; Wed, 10 Jul 2002 11:03:48 -0700 (PDT) Message-ID: <3D2C772F.587ED18E@isi.edu> Date: Wed, 10 Jul 2002 14:04:31 -0400 From: Dan Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Scott Rose CC: Ted Lemon , lewis@arin.net, namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <008d01c22835$4dc8faf0$b9370681@BARNACLE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose wrote: > There was a reference to APPKEY (Jakob's draft? not certain and I don't > have it in front of me). It was taken out (by me probably) when we saw that > there was a lot of debate about how to store application keys in the DNS. > The APPKEY draft only proposed one possible solution and we didn't want to > say it was the choice option. > I think Scott took it out, but I also strongly agree with that decision. This thread, past discusions, the last BOF, and so forth all show that there is active discussion on application keys so I don't think restrict key should point to a particular approach. > > A reference to any application key draft could be included, just to say > other means exist and are being debated. I don't think key restrict should go further than the current text that says: > Other documents can describe how DNS handles application keys. This does not point to a specific approach and leaves a clear path for some application key document to gain consensus. The main point of key restrict is just that application keys don't belong in the KEY record (not equivalent to "don't belong in the DNS"). Regardless of what else happens, I haven't seen any reason why this would change. Since we have consensus on the don't belong in the KEY record, let's make that change so things like the DNSSEC revision, operational policies, and so forth can all benefit from this simplification. Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 14:13:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13876 for ; Wed, 10 Jul 2002 14:13:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SLss-0006eX-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 11:08:14 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17SLsQ-0006bl-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 11:07:46 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6AI6Wd16057; Wed, 10 Jul 2002 18:06:32 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6AI6aMP007433; Wed, 10 Jul 2002 13:06:36 -0500 (CDT) Date: Wed, 10 Jul 2002 13:06:36 -0500 Subject: Re: (ngtrans) The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, Derek Atkins To: Dean Anderson From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't know of _anybody_ who still uses the reverse map to do authentication. Once in a while I hear about people who still use telnet, but that's a rarity nowadays. I suppose there's probably someone out there who still uses rsh, but they're probably at least taking pains to make sure that the packets are never exposed outside of their corporate network. My point is that nobody here is saying that we should be using the reverse map for authentication. So why do you keep bringing it up? The only thing we're talking about here is using the reverse map for validation. Validation is a tricky term. In some cases, it means "verifying that the data is correct." In other cases, it means "corroboration." In this case, I think we are all talking about corroboration, not verification. Corroboration just means that you have two entities who agree on something. It doesn't mean the something is correct. In theory, we can never depend on corroborated data, because the mere fact that two unknown entities who might actually be the same entity claim that something is true does not mean that it is true. I don't think there is a single person here, Dean, who would debate this point with you. The debate is not over whether corroborated data can be depended upon, but rather whether corroborated data can be useful. And it seems that most people agree that it can be useful, with a few notable exceptions, yourself included. Despite these exceptions, we do seem to have pretty broad agreement on is that we should *recommend*, not *require*, that people set up reverse domains. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 14:42:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15035 for ; Wed, 10 Jul 2002 14:42:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SMM0-00085z-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 11:38:20 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17SMLq-000856-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 11:38:10 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 152966; Wed, 10 Jul 2002 13:35:15 -0500 Message-ID: <3D2C7F0C.5020400@ehsco.com> Date: Wed, 10 Jul 2002 13:38:04 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Ted Lemon CC: Dean Anderson , namedroppers@ops.ietf.org, Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/10/2002 1:06 PM Ted Lemon wrote: > I don't know of _anybody_ who still uses the reverse map to do > authentication. Nor should they. In point of fact, the only security service that reverse PTRs are useful for is proving that something *IS NOT* something, simply because they did not claim to be. At that point, the only real threat to IN-ADDR spoofing is a DoS attack, keeping otherwise legitimate hosts from connecting to a service. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 14:44:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15081 for ; Wed, 10 Jul 2002 14:44:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SMHt-0007td-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 11:34:05 -0700 Received: from rs1.arin.net ([192.149.252.21]) by psg.com with esmtp (Exim 3.36 #1) id 17SMHm-0007sf-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 11:33:58 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id OAA18118; Wed, 10 Jul 2002 14:33:55 -0400 (EDT) Received: from [208.58.217.124] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA07527; Wed, 10 Jul 2002 14:33:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <008d01c22835$4dc8faf0$b9370681@BARNACLE> References: <008d01c22835$4dc8faf0$b9370681@BARNACLE> Date: Wed, 10 Jul 2002 14:33:34 -0400 To: "Scott Rose" , "Ted Lemon" , From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Cc: "namedroppers" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,RCVD_IN_OSIRUSOFT_COM version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:14 PM -0400 7/10/02, Scott Rose wrote: >As for the overlap between Restrict-KEY and the DS RR draft: I think I >understand the comment. A referrence to how Restrict-KEY will update the >last part of the DS RR intro. correct me if I'm wrong. I caught this too - I sent mail to authors and the IESG (because its in last call) yesterday after talking to Olafur. That's exactly the location where I was the overlap. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 15:07:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15814 for ; Wed, 10 Jul 2002 15:07:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SMil-0009Fe-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 12:01:51 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17SMiT-0009FM-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 12:01:33 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g6AIx1V03499; Wed, 10 Jul 2002 14:59:01 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Wed, 10 Jul 2002 14:59:01 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Ted Lemon cc: Simon Josefsson , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: Message-ID: <20020710142535.H3435-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 10 Jul 2002, Ted Lemon wrote: > > this are items for the siked effort. this document should not try > > to encompass that effort. > > I believe that the argument was that the restrict-key-for-dnssec draft > should not advance in the absence of an app-key draft advancing, because > otherwise we lose functionality. So if we make a normative reference to > the app key draft in the restrict-key draft, that solves that problem. : > '} Let me give some background, RFC2065 observes that now that we have KEY record for DNSSEC we can piggy-back on that to provide key distribution for other uses. This is carried to RFC2535. Some DNS people have been advocating that the biggest mistakes in DNS are when multiple things share the same RR type, it is simpler from a specification perspective but it has operational and development issues. Now back to KEY, Dan Massey started a DNSSEC test bed and it noticed that his organization had all the public services located at the zone apex, web, ftp, mail, ssh, etc. If each one of these was allowed to put key records in to the apex KEY set it got big. NLnetlabs people run a DNSSEC test bed and they noticed that KEY sets for children where going stale as the child did not send the parent the key set to sign. They proposed a change to DNSSEC that delegation KEY records be stored at the parent (KEY@parent). There is a workshop in Malmo on DNSSEC for operators and international lawyers to discuss the implications of signing KEY sets. The lawyers did not like that TLD's sign application keys. I give a whole day seminar on DNSSEC in Iceland and the information flow in there, after answering many times "there is no other way" to questions like "Why do something this complicated", I concoct the predecessor of the DS record. The original DS spec contains text motivated by all the experiences above on why application keys should not be allowed to coexist with this starts a discussion how to store non-DNS keys. The consensus of this discussion was that DNS keys should be separated from the non-DNS keys, but there is no consensus on how/if to store the non-DNS keys. In order to force the issue and motivate people to discuss full ideas the chairs on 2001/10/26 invited submissions on various ideas on how to store non-DNS keys in DNS. Dan and Scott submitted a paper motivated by all above named restrict-key. The goal of this paper is to prevent harm to DNS and motivate people to find a different solution if one exists. I personally prefer some variant of APPKEY is the solution, my current preference is to give each use (protocol or application) its own type code. The siked effort (keydist@cafax.se) is the appropriate forum for this discussion as this is a larger issue than DNS. If a application comes to DNSEXT with specifications on a new type to store keys and the security area people are comfortable with that specification, DNSEXT will review the specification and comment on it. Please keep the discussion on this topic focused on the issue at hand. "Is restricting the use of the KEY RR a good idea". Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 15:14:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16238 for ; Wed, 10 Jul 2002 15:14:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SMof-0009ae-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 12:07:57 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17SMno-0009Ys-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 12:07:04 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g6AJ4TX03515; Wed, 10 Jul 2002 15:04:29 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Wed, 10 Jul 2002 15:04:29 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Edward Lewis cc: Scott Rose , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: Message-ID: <20020710145926.P3435-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 10 Jul 2002, Edward Lewis wrote: > At 1:14 PM -0400 7/10/02, Scott Rose wrote: > >As for the overlap between Restrict-KEY and the DS RR draft: I think I > >understand the comment. A referrence to how Restrict-KEY will update the > >last part of the DS RR intro. correct me if I'm wrong. > > I caught this too - I sent mail to authors and the IESG (because its > in last call) yesterday after talking to Olafur. That's exactly the > location where I was the overlap. > I think DS should drop the first paragraph on page 3: "Another complication of the DNSSEC" and replace that with a short summary and a reference to Restrict-Key section 2 that does a better job of documenting the issue. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 15:32:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16657 for ; Wed, 10 Jul 2002 15:32:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SN3g-000AOC-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 12:23:28 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17SN30-000ALR-00; Wed, 10 Jul 2002 12:22:47 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g6AJMZwF007285; Wed, 10 Jul 2002 21:22:35 +0200 To: Dan Massey Cc: Randy Bush , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <3D2C4E29.D993D457@isi.edu> X-Hashcash: 020710:masseyd@ISI.EDU:b515013166a27bdc X-Hashcash: 020710:randy@psg.com:7d7af95c83b02f58 X-Hashcash: 020710:namedroppers@ops.ietf.org:fa703112307f3c6d From: Simon Josefsson Date: Wed, 10 Jul 2002 21:22:35 +0200 In-Reply-To: <3D2C4E29.D993D457@isi.edu> (Dan Massey's message of "Wed, 10 Jul 2002 11:09:29 -0400") Message-ID: Lines: 32 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dan Massey writes: > Randy Bush wrote: > >> >> 1) State in the document that application keys in DNS is a bad idea >> >> and it is now forbidden to do this. >> > As the restrict-key-for-dnssec document currently reads, it choses 1) >> > above but only implicitely. >> >> no it does not. saying don't use A for X does not in any way imply >> don't do X >> >> randy > > If I say don't use the A record for IPv6 addresses, that does > not implicitly mean that IPv6 addresses don't belong in the DNS. If A records was designed to hold IPv6 addresses, and was the only way to store IPv6 addresses in DNS, and it later became deprecated for specifically that use only, it seems to me like a pretty clear message that IPv6 addresses should not be in DNS. > Key restrict says don't use the KEY record for application keys. > That does not implicity mean application keys don't belong > in the DNS. In fact, the draft explicitly states: > >> The scope of this document is strictly limited to the KEY record. >> This document prohibits storing application keys in the KEY record, >> but it does not endorse or restrict the storing application keys in >> other record types. Yes, and that text together with my reasoning above confused me. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 10 15:44:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16936 for ; Wed, 10 Jul 2002 15:44:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SNE6-000AvM-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 12:34:14 -0700 Received: from 61.193.166.83 ([61.193.166.83] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17SNDR-000Auj-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 12:33:33 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17SND8-0003cl-00; Wed, 10 Jul 2002 12:33:14 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Simon Josefsson Cc: Dan Massey , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: <3D2C4E29.D993D457@isi.edu> Message-Id: Date: Wed, 10 Jul 2002 12:33:14 -0700 X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> no it does not. saying don't use A for X does not in any way imply >>> don't do X >> If I say don't use the A record for IPv6 addresses, that does >> not implicitly mean that IPv6 addresses don't belong in the DNS. > If A records was designed to hold IPv6 addresses, and was the only way > to store IPv6 addresses in DNS, and it later became deprecated for > specifically that use only, it seems to me like a pretty clear message > that IPv6 addresses should not be in DNS. there are 42 interesting proposals for storing IPv6 addresses in the DNS. this draft would be foolish to choose sides. it would merely move those non-terminating discussions into this simple draft. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 00:56:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00226 for ; Thu, 11 Jul 2002 00:56:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SVlB-000COY-00 for namedroppers-data@psg.com; Wed, 10 Jul 2002 21:40:57 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17SVl6-000COM-00 for namedroppers@ops.ietf.org; Wed, 10 Jul 2002 21:40:52 -0700 Received: from [128.177.195.161] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C7C8B137F03; Wed, 10 Jul 2002 21:40:51 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 10 Jul 2002 21:41:44 -0700 Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt From: David Conrad To: Olafur Gudmundsson , Ted Lemon Cc: Simon Josefsson , namedroppers Message-ID: In-Reply-To: <20020710142535.H3435-100000@hlid.dc.ogud.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 7/10/02 11:59 AM, "Olafur Gudmundsson" wrote: > "Is restricting the use of the KEY RR a good idea". Yes. Has anyone been arguing that it isn't? Tnx, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 05:16:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13904 for ; Thu, 11 Jul 2002 05:16:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SZt2-000MLg-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 02:05:20 -0700 Received: from [202.28.97.5] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17SZsg-000MKR-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 02:04:59 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g6B94R507355; Thu, 11 Jul 2002 16:04:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6B93Vf06968; Thu, 11 Jul 2002 16:03:32 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Ted Lemon cc: Dean Anderson , namedroppers@ops.ietf.org, Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Jul 2002 16:03:31 +0700 Message-ID: <6966.1026378211@munnari.OZ.AU> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 10 Jul 2002 13:06:36 -0500 From: Ted Lemon Message-ID: | Despite these exceptions, we do seem to have pretty broad | agreement on is that we should *recommend*, not *require*, that people set | up reverse domains. I don't think we have agreement even for that - there are plenty of people who actually want the IP6.ARPA (and IP6.INT) - and maybe even IN-ADDR.ARPA delegations to go away, so no-one can set up a reverse domain, even if they want to. That doesn't sound anything like agreement to recommend that it be done... I wouldn't go that far, but nor would I recommend that people set up reverse delegations. What I would agree with is explaining to people what they're good for, and why they might want to do it, but stopping short of actually recommending that it be done. I'd also want some strong words in there though about how the data should not be used (which would not of course prevent anyone who felt strongly enough from going ahead ad doing it anyway). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 09:19:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17941 for ; Thu, 11 Jul 2002 09:19:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SdZf-0000wH-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 06:01:35 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17SdZ2-0000vR-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 06:00:56 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id UAA08300; Wed, 10 Jul 2002 20:38:20 -0400 Date: Wed, 10 Jul 2002 20:38:50 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Eric Brunner-Williams in Portland Maine cc: namedroppers Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <200207100139.g6A1d6vG008160@nic-naa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 954 doesn't mention delegation or replication. Neither does 812, nor does 742. > > If you are discussing an implementation, could you be specific as to which > you are referring to? Rfc2167 has all of the delegation and replication stuff. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 10:37:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19274 for ; Thu, 11 Jul 2002 10:37:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Sev8-0002U7-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 07:27:50 -0700 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 17SeuL-0002TZ-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 07:27:01 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.5/8.11.6) with ESMTP id g6BEQ1vG014559; Thu, 11 Jul 2002 10:26:01 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200207111426.g6BEQ1vG014559@nic-naa.net> To: Dean Anderson cc: Eric Brunner-Williams in Portland Maine , namedroppers , brunner@nic-naa.net Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Your message of "Wed, 10 Jul 2002 20:38:50 EDT." Date: Thu, 11 Jul 2002 10:26:01 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_MX_FOR_FROM version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Rfc2167 has all of the delegation and replication stuff. Oh. The protocol running on port 4321. Not the protocol running on port 43. That might account for some misunderstanding. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 11:09:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20367 for ; Thu, 11 Jul 2002 11:09:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SfSn-0003Ex-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 08:02:37 -0700 Received: from adsl-63-196-7-183.dsl.snfc21.pacbell.net ([63.196.7.183] helo=blade.unixpeople.internal) by psg.com with esmtp (Exim 3.36 #1) id 17SfRt-0003Dg-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 08:01:41 -0700 Received: from unixpeople.com (quake.unixpeople.internal [192.168.37.210]) by blade.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g6BEqX7n010351; Thu, 11 Jul 2002 07:52:33 -0700 (PDT) Message-ID: <3D2D9C50.2080201@unixpeople.com> Date: Thu, 11 Jul 2002 07:55:12 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz CC: Ted Lemon , Dean Anderson , namedroppers@ops.ietf.org, Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue References: <6966.1026378211@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > | Despite these exceptions, we do seem to have pretty broad > | agreement on is that we should *recommend*, not *require*, that people set > | up reverse domains. > > I don't think we have agreement even for that - there are plenty of people > who actually want the IP6.ARPA (and IP6.INT) - and maybe even IN-ADDR.ARPA > delegations to go away, so no-one can set up a reverse domain, even if > they want to. That doesn't sound anything like agreement to recommend > that it be done... > > I wouldn't go that far, but nor would I recommend that people set up > reverse delegations. > > What I would agree with is explaining to people what they're good for, > and why they might want to do it, but stopping short of actually > recommending that it be done. I'd also want some strong words in there > though about how the data should not be used (which would not of course > prevent anyone who felt strongly enough from going ahead ad doing it anyway). > > kre I'm assuming that your last sentence was incomplete here. You really meant ot say that "the data should not be used for authentication" right? "should not be used" is silly. FWIW, I use the information in reverse DNS all the time. I don't authenticate with it, but I still find it usefull for information purposes. -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) Tell a man that there are 300 billion stars in the universe, and he'll believe you.... Tell him that a bench has wet paint upon it and he'll have to touch it to be sure. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 11:13:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20511 for ; Thu, 11 Jul 2002 11:13:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SfYH-0003Or-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 08:08:17 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17SfXq-0003Nt-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 08:07:50 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6BF4vd19426; Thu, 11 Jul 2002 15:04:57 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6BF51MP007804; Thu, 11 Jul 2002 10:05:01 -0500 (CDT) Date: Thu, 11 Jul 2002 10:05:00 -0500 Subject: Re: (ngtrans) The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Dean Anderson , namedroppers@ops.ietf.org, Derek Atkins To: Robert Elz From: Ted Lemon In-Reply-To: <6966.1026378211@munnari.OZ.AU> Message-Id: <92358000-94DF-11D6-8575-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I don't think we have agreement even for that - there are plenty of people > who actually want the IP6.ARPA (and IP6.INT) - and maybe even IN-ADDR.ARPA Right, you're one of the people who doesn't agree. Of course you don't think we have agreement. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 11:45:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21845 for ; Thu, 11 Jul 2002 11:45:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SfyB-00047F-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 08:35:03 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17Sfxd-00045x-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 08:34:29 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6BFVgd19482; Thu, 11 Jul 2002 15:31:43 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6BFVkMP007811; Thu, 11 Jul 2002 10:31:46 -0500 (CDT) Date: Thu, 11 Jul 2002 10:31:46 -0500 Subject: Re: (ngtrans) The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Derek Atkins , namedroppers To: Robert Elz From: Ted Lemon In-Reply-To: <3D2D9C50.2080201@unixpeople.com> Message-Id: <4F4D02F3-94E3-11D6-8575-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > recommending that it be done. I'd also want some strong words in there > though about how the data should not be used (which would not of course > prevent anyone who felt strongly enough from going ahead ad doing it > anyway). To be a little less opaque, let me just point out that what you are trying to do here is to solve problem in a standard that can't be solved in a standard. There is a reason why people set up services that expect the forward and reverse to match. It's a useful sanity check in some cases, and it's handy for logging in many cases. They are wrong to *expect* it to work - it's an incredible hassle for me when I'm doing testing on a network and name service isn't working that I have to wait a minute for the lookup to timeout before I can log into another machine, and I'd bloody well like it if people wouldn't code their clients and servers to insist on doing the lookup without being configured that way. I'd also really like it if, e.g., openssh wouldn't spew out a panicky message about a man-in-the-middle every time I use it to ssh into a machine that *has* a valid DNS setup, but that gets its IP address from DHCP and therefore doesn't have a consistent IP address. So we do agree that people are abusing the DNS in ways that don't make sense. A machine's IP address is not its identity, and the information about the machine in the DNS isn't its identity either. What we don't agree on is that this means we shouldn't recommend that people set up reverse zones. My worry is that you, and perhaps Dean, are arguing that PTR records should basically go away, and I think the reason you want them to go away is because you believe they are being misused, and if they aren't there they can't be misused. So you're arguing that we should get rid of very useful functionality in order to force people to stop misusing it. Baby. Bathwater. Need I say more? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 18:19:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09435 for ; Thu, 11 Jul 2002 18:19:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Sm35-000DV8-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 15:04:31 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17Sm2P-000DTe-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 15:03:49 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA24356; Thu, 11 Jul 2002 15:29:49 -0400 Date: Thu, 11 Jul 2002 15:30:19 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Ted Lemon cc: Robert Elz , namedroppers@ops.ietf.org, Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <92358000-94DF-11D6-8575-00039367340A@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk And you're one of the people who thinks there is agreement where this isn't any. Funny, that is the same problem you have with reverse DNS. I wonder if its some unidentified disease of the center of the brain that processes meaning and significance... ;-) --Dean On Thu, 11 Jul 2002, Ted Lemon wrote: > > I don't think we have agreement even for that - there are plenty of people > > who actually want the IP6.ARPA (and IP6.INT) - and maybe even IN-ADDR.ARPA > > Right, you're one of the people who doesn't agree. Of course you don't > think we have agreement. > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 18:19:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09458 for ; Thu, 11 Jul 2002 18:19:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Sm3G-000DVL-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 15:04:42 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17Sm2X-000DUt-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 15:03:57 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA25422; Thu, 11 Jul 2002 15:37:24 -0400 Date: Thu, 11 Jul 2002 15:37:55 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Ted Lemon cc: Robert Elz , Derek Atkins , namedroppers Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <4F4D02F3-94E3-11D6-8575-00039367340A@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 11 Jul 2002, Ted Lemon wrote: > To be a little less opaque, let me just point out that what you are trying > to do here is to solve problem in a standard that can't be solved in a > standard. There is a reason why people set up services that expect the > forward and reverse to match. It's a useful sanity check in some cases, > and it's handy for logging in many cases. Well, at the risk of saying "no, its not", I'll just say "No, its not a useful sanity check, and its not handy for logging." These are the things reverse DNS should NOT be used for. > My worry is that you, and perhaps Dean, are arguing that PTR records should > basically go away, and I think the reason you want them to go away is > because you believe they are being misused, and if they aren't there they > can't be misused. So you're arguing that we should get rid of very useful > functionality in order to force people to stop misusing it. > > Baby. Bathwater. Need I say more? Baby toys. Cute, Sparkly, but choking hazard. Clearly, its needs to go, since the children can't handle the responibility or understand the implications. But I'll shutup now, and let other people disagree. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 19:00:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11750 for ; Thu, 11 Jul 2002 19:00:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Smon-000EwR-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 15:53:49 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17Smnn-000Eui-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 15:52:47 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6BMqTd20525; Thu, 11 Jul 2002 22:52:30 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6BMqYMP010208; Thu, 11 Jul 2002 17:52:34 -0500 (CDT) Date: Thu, 11 Jul 2002 17:52:33 -0500 Subject: Re: (ngtrans) The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Robert Elz , Derek Atkins , namedroppers To: Dean Anderson From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Well, at the risk of saying "no, its not", I'll just say "No, its not a > useful sanity check, and its not handy for logging." These are the things > reverse DNS should NOT be used for. Yes, you've stated this several times. Stating it several times doesn't make it true. > Baby toys. Cute, Sparkly, but choking hazard. Clearly, its needs to go, > since the children can't handle the responibility or understand the > implications. Right, you've said this too. Several times. Thanks. I didn't quite understand it the first time. :'} Unfortunately, I still don't understand your point. I get lots of good use out of the reverse mappings, and I really haven't seen any evidence of widespread misuse of them. Have you? Care to elaborate? You seem to be very happy to keep repeating your basic reasons for objecting, but when someone asks you to justify them, you do not do so. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 11 23:12:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22181 for ; Thu, 11 Jul 2002 23:12:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17SqfL-000Lkw-00 for namedroppers-data@psg.com; Thu, 11 Jul 2002 20:00:19 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17SqfD-000Lkk-00 for namedroppers@ops.ietf.org; Thu, 11 Jul 2002 20:00:11 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g6C312O00724; Thu, 11 Jul 2002 23:01:02 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Thu, 11 Jul 2002 23:01:01 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: David Conrad cc: Simon Josefsson , namedroppers Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt In-Reply-To: Message-ID: <20020711225709.G712-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 10 Jul 2002, David Conrad wrote: > On 7/10/02 11:59 AM, "Olafur Gudmundsson" wrote: > > "Is restricting the use of the KEY RR a good idea". > > Yes. Has anyone been arguing that it isn't? That opinion has been expressed to me in private e-mails and in person at the last IETF. There is a feeling of betrayal by some people that looked to DNSSEC as a ready made PKI that was just around the corner has been taken away. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 09:30:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21654 for ; Fri, 12 Jul 2002 09:30:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T07y-0008rA-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 06:06:30 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17T07c-0008qi-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 06:06:08 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id BAA09649; Fri, 12 Jul 2002 01:02:21 -0400 Date: Fri, 12 Jul 2002 01:02:51 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Ted Lemon cc: Robert Elz , Derek Atkins , namedroppers Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 11 Jul 2002, Ted Lemon wrote: > Unfortunately, I still don't understand your point. I get lots of good > use out of the reverse mappings, and I really haven't seen any evidence of > widespread misuse of them. Have you? Care to elaborate? You seem to > be very happy to keep repeating your basic reasons for objecting, but when > someone asks you to justify them, you do not do so. Well, I think I did state a valid objection. I apologize if I wasn't clear. I'll try to summarize the issues. kre and I (at least) are in agreement. I think your use ("handy for logging and validation") ought to be classfied to be misuse, and therefore there is widespread misuse of Reverse DNS for just those purposes. Your disagreement is that your use isn't actually misuse, and that it should be OK to use Reverse DNS for authentication or "validation", and logging. You have argued that when reverse and forward maps match, that there is some kind of useful meaning to be implied from this. I think I have shown through several examples that, in fact, there is no meaning that can be attached should it happen that forward and reverse match, and therefore validation is also a misuse of Reverse DNS. This is the crux of the disagreement, I think. It is a frequent misconception that reverse DNS can be used for logging, and authentication or validation, and therefore a "widespread misuse of Reverse DNS." My objection then is that reverse DNS is often misused. When used properly, reverse DNS has only cosmetic use, and thus only a minor benefit. The misuse can result in a number of bad things happening, from improper authentication to useless logging. Because of the misuse, in comparison with the minor cosmetic benefit, I think Reverse DNS should be deprecated. Our disagreement revolves around what is proper use and what is misuse of reverse DNS, and maybe more specifically whether there is any significance for the state when Reverse DNS and Forward DNS match. If such a state is meaningless (since as I argue, it can't be meaningful), then there is much misuse of reverse DNS by the people who assume it has meaning when it has no meaning. I think there are specific harms to each of the misuses: Logging allows useless information to be logged, obscuring or in lieu of what little useful indentifying information that is available, and would have been used instead, if Reverse DNS were not available, such as the IP address. Authentication allows persons to gain access inappropriately. Authentication and Validation are almost the same. Authentication seems to mean shell access is given. "Validation" creates a false impression of confirmed identity, and a false feeling of comfort that might lead one into granting priveleges without further checks. DNSsec could mitigate some of these harms in the cases where DNSsec is used, but not all of the harms. In the cases where DNSsec isn't used, all of these harms could apply to these misuses. I don't think you dispute the harms so much as you simply dismiss them as unimportant. This attitude towards them, I think, is probably also a harm, since it causes people not to give proper attention to issues such as logging and the assumptions made due to a "comfort level" obtained when Reverse and Forward DNS match. I think it was a similar attitude or perhaps a false sense of comfort that led to significant security problems in the r-commands. These is probably not a complete list of harms. But I think it is sufficient, when stacked against the cosmetic benefit, to warrant serious consideration of removing Reverse DNS from IPv6. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 10:26:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24429 for ; Fri, 12 Jul 2002 10:26:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T1ER-000AKe-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 07:17:15 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.36 #1) id 17T1DF-000AIT-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 07:16:01 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 12 Jul 2002 14:16:01 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 10:15:45 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002071210154417883 ; Fri, 12 Jul 2002 10:15:44 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <3VGJ9GMR>; Fri, 12 Jul 2002 10:16:24 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2CD7@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Olafur Gudmundsson '" , "'namedroppers '" Subject: RE: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt Date: Fri, 12 Jul 2002 10:16:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > "Is restricting the use of the KEY RR a good idea". > > > > Yes. Has anyone been arguing that it isn't? > > That opinion has been expressed to me in private e-mails and > in person at the last IETF. > > There is a feeling of betrayal by some people that looked to > DNSSEC as a ready made PKI that was just around the corner > has been taken away. But this isn't the "Internet Try-not-to-make-anyone-feel-betrayed Task Force". If we could find the ITTF, maybe those folks would try to help us. In the meantime, we're engineering. Having KEY records available for uses other than DNSSEC keys *might* have been at least an Okay Thing. Therefore, that was the way things were originally written. However, experience shows that trying to deal with a load of extra KEY records in the middle of each DNSSEC validation turns out to be a Bad Thing. We must therefore revert to being part of the I _E_ TF, and update the RFCs appropriately. The no-brainer way (IMHO) to engineer a solution that allows DNSSEC to function is to restrict KEY for DNSSEC. In fact, I haven't seen any discussion of any other reasonable solution--and I am still going on the basis that DNSSEC remains on the standards track and therefore should be supported appropriately. There was previous discussion of APPKEY and/or CERT records, and I'm not quite sure how we (now) seem to have lost the previous consensus. For right now, though, I would ask that anyone who can't live with the restrict-KEY draft *please* clearly state your objections--once that's out of the way *then* we can address APPKEY/CERT/SINK/whatever and engineer an appropriate solution. Or am I missing something? --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 10:27:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24471 for ; Fri, 12 Jul 2002 10:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T1FY-000AMA-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 07:18:24 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17T1EW-000AKr-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 07:17:20 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA29417; Fri, 12 Jul 2002 10:17:18 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA04946; Fri, 12 Jul 2002 10:17:18 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA24176; Fri, 12 Jul 2002 10:17:17 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id KAA16378; Fri, 12 Jul 2002 10:17:16 -0400 Subject: Re: (ngtrans) The reverse lookup issue From: Greg Hudson To: Dean Anderson Cc: namedroppers In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 12 Jul 2002 10:17:16 -0400 Message-Id: <1026483436.1185.155.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2002-07-12 at 01:02, Dean Anderson wrote: > Your disagreement is that your use isn't actually misuse, and that it > should be OK to use Reverse DNS for authentication or "validation", and > logging. You have argued that when reverse and forward maps match, that > there is some kind of useful meaning to be implied from this. I think I > have shown through several examples that, in fact, there is no meaning > that can be attached should it happen that forward and reverse match, and > therefore validation is also a misuse of Reverse DNS. This is the crux of > the disagreement, I think. Of course there is meaning. It means "this domain is listed in the DNS as the name for this address, and it is not a complete forgery (although it might be meaningless)." A fine thing to log. Log the IP address too, since as you pointed out, the name might go away. I wouldn't call this logging a purely aesthetic benefit. You can use that information to collect statistical data ("look, 30% of our connections are from IBM") as long as you're willing to accept that organizations can hide themselves from that collection (don't expect to find out that another 30% of your connections are coming from the NSA). > It is a frequent misconception that reverse DNS can be used for logging, > and authentication or validation, and therefore a "widespread misuse of > Reverse DNS." There are historical examples of use for authentication (I'm still unsure what you mean by "validation"), but I'm not aware of any recent examples. I think your "widespread misuse" is pretty much limited to the occasional logging of domain names without also logging IP addresses. With forward DNSSEC, of course, it's fine to use reverse DNS for authentication, as long as you don't want to give anyone negative access rights (and aren't worried about IP spoofing, for whatever reason). If I want to say "only these hosts can log in here," reverse DNS works as a hint. An inline statement in the protocol would work just as well, if the protocol allows for that; I'm not saying that this is a great idea, just that it works. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 10:54:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25829 for ; Fri, 12 Jul 2002 10:54:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T1h1-000B6H-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 07:46:47 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.36 #1) id 17T1gw-000B66-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 07:46:42 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 12 Jul 2002 14:46:42 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 10:46:30 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002071210462910886 ; Fri, 12 Jul 2002 10:46:29 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <3VGJ9HJT>; Fri, 12 Jul 2002 10:47:09 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2CD8@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Dean Anderson '" Cc: "'namedroppers '" Subject: RE: (ngtrans) The reverse lookup issue Date: Fri, 12 Jul 2002 10:46:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean-- Thanks for a well-written summary of your issues. Now that I've read the last few messages from you and kre, I would have to allow that you do have valid concerns. However: > Logging allows useless information to be logged, obscuring or in lieu of > what little useful indentifying information that is available, and would > have been used instead, if Reverse DNS were not available, such as the > IP address. I disagree that the logged information is always useless. Your statement appears to be based on the fact that since anyone who controls their reverse DNS can change it to $whatever, the information cannot be relied upon. For the more typical (currently) case where most users do not control their reverse DNS, I would state that it is *sometimes* useful. Identifying when the information is useful and how to use it does seem to be a problem for a lot of folks--I just don't agree that the IETF should take away the baby toys. > Authentication allows persons to gain access inappropriately. No, authentication *prevents* people from gaining access inappropriately, if one's authentication system(s) are properly implemented. > Authentication and Validation are almost the same. Not in my opinion. I generally don't expect anyone except users who have some associated authorization to be authenticating. Validation (to me) refers more to "does this (connection attempt or whatever) seem to be reasonable and I should therefore allow it." If a mail server I control receives an incoming connection attempt on port 25 from a system that claims to be "mail.hghChEEpnow!.net" but in fact shows up in the reverse map as "dsl-1-2-3-4.bigisp.net", then why should I not use this information to help in the decision on accepting the incoming connection attempt? (Note that I'm not saying I would make a decision based on this one data point alone--but it could be one data point towards a decision.) >Authentication seems to mean shell access is given. No, authentication means authentication. Shell access, or other access, is a function of the authorizations granted to the entity which has authenticated. > "Validation" creates a false impression of confirmed identity, and a > false feeling of comfort that might lead one into granting priveleges > without further checks. No, validation means that I have validated a set of information against a set of criteria, and I believe that I the set of information is useful. It doesn't necessarily mean that identity is confirmed--but in the example above, it's reasonable to think that identity has been (at least partially) denied. > DNSsec could mitigate some of these harms in the cases where DNSsec is > used, but not all of the harms. In the cases where DNSsec isn't used, > all of these harms could apply to these misuses. I personally believe that without DNSSEC, there are many fundamental issues with the DNS protocols today that will continue to bite us in the butt. Reverse lookup is only one of them. Therefore, if anything I believe that DNSSEC _will_ be more widely used, and that some of your harms will have their effect reduced--particularly inside certain large enterprise networks. > [...] it causes people not to give proper attention to issues such as > logging and the assumptions made due to a "comfort level" obtained when > Reverse and Forward DNS match. I think it was a similar attitude or > perhaps a false sense of comfort that led to significant security > problems in the r-commands. You've brought up the r-commands before, and I still don't see the specific link. I agree that reverse DNS information has been and still can be used in-appropriately for authentication, which gives a false sense of comfort. That's significantly different in my mind from the (remarkably bad in hindsight) assumptions behind the r-commands. > These is probably not a complete list of harms. But I think it is > sufficient, when stacked against the cosmetic benefit, to warrant > serious consideration of removing Reverse DNS from IPv6. I agree that you have clearly stated some potential issues. However, I don't think that any of them are so grievous (individually or as a whole) to cause reverse DNS to be harmful. For certain specific cases, reverse DNS remains useful IMHO (particularly inside large enterprise networks)--and I believe that it can continue to be useful in an IPv6 world. The biggest reason that I could see (and that at least some folks mentioned at one time) to support deprecating reverse DNS would be to allow organizations to hide internal information. There are already other solutions/mechanisms to address the separation of internal/external DNS information, and getting rid of reverse DNS entirely would be a poor solution for that other class of problems. (I mention it in passing only for completeness.) --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 11:26:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27612 for ; Fri, 12 Jul 2002 11:26:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T2Ah-000BvP-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 08:17:27 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17T2AE-000Bts-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 08:16:58 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6CFEKd22905; Fri, 12 Jul 2002 15:14:20 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6CFE9MP010318; Fri, 12 Jul 2002 10:14:09 -0500 (CDT) Date: Fri, 12 Jul 2002 10:14:08 -0500 Subject: Re: (ngtrans) The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers , Derek Atkins , Robert Elz To: Dean Anderson From: Ted Lemon In-Reply-To: Message-Id: <033CB31C-95AA-11D6-9580-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit No, no, this is precisely the point, Dean. You stated two objections, and when people pointed out the problems with your objections, you stated them again, without addressing the problems that were raised. Just now you restated them once more, again without addressing those problems. I am tempted to once more restate my arguments about your objections, but it seems pointless - we could go around like this forever. This is why working groups are only required to reach "rough" consensus - sometimes there will be someone who, perhaps rightly, but as a minority, simply will not budge from their firmly held opinion that what is being proposed is wrong, and shouldn't happen. So we blunder forward and see what happens. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 15:16:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10182 for ; Fri, 12 Jul 2002 15:16:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T5fp-000Hai-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 12:01:49 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17T5fk-000HaV-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 12:01:44 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id NAA06790; Fri, 12 Jul 2002 13:07:24 -0400 Date: Fri, 12 Jul 2002 13:07:56 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Ted Lemon cc: namedroppers , Derek Atkins , Robert Elz Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <033CB31C-95AA-11D6-9580-00039367340A@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ditto. You made objections about my objections, but you just restated that there is meaning to the state when reverse and forward match. You didn't offer any evidence that there is any meaning to such a state, except you and some others commonly make that assumption. That others make the same assumption isn't proof the assumption is true. And you asserted that DNSsec makes the objections I raised go away. But I showed that it only makes some problems go away, not all problems, and in some cases, DNSsec makes no problems go away. So your objection is incomplete, and does't address my objections. Essentially, we are just circling about the meaning of the state when reverse and forward match. So in that respect, we are at an impasse. I suppose we have to bumble forward somehow. Frankly, I think I've offered credible evidence that there isn't any such meaning, and I've shown there are specific harms to the assumption that there is such meaning. All you've offered is that its handy and some people use it this way, and that DNSsec might help. I don't think you've made a positive case for retention of Reverse DNS. Do others? Robert? --Dean On Fri, 12 Jul 2002, Ted Lemon wrote: > No, no, this is precisely the point, Dean. You stated two objections, and > when people pointed out the problems with your objections, you stated them > again, without addressing the problems that were raised. Just now you > restated them once more, again without addressing those problems. > > I am tempted to once more restate my arguments about your objections, but > it seems pointless - we could go around like this forever. This is why > working groups are only required to reach "rough" consensus - sometimes > there will be someone who, perhaps rightly, but as a minority, simply will > not budge from their firmly held opinion that what is being proposed is > wrong, and shouldn't happen. So we blunder forward and see what happens. > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 16:08:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12857 for ; Fri, 12 Jul 2002 16:08:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T6Zj-000J8k-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 12:59:35 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17T6ZH-000J7C-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 12:59:07 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6CJx2d23653; Fri, 12 Jul 2002 19:59:02 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6CJwqMP010352; Fri, 12 Jul 2002 14:58:52 -0500 (CDT) Date: Fri, 12 Jul 2002 14:58:51 -0500 Subject: Re: (ngtrans) The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: Robert Elz , Derek Atkins , namedroppers To: Dean Anderson From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > You didn't offer any evidence that there is any meaning to such a state, > except you and some others commonly make that assumption. That others make > the same assumption isn't proof the assumption is true. I personally use, and get value out of, ptr records in the in-addr.arpa domain. This is my own personal experience. You can't contradict this - I have observed it directly. Maybe it doesn't match your experience, but it doesn't have to, because the argument you've made here attempts to disprove the premise that the system is useful. The fact that quite a few people have stepped forward and said "I personally get real, meaningful benefit out of the system as it is" is sufficient to invalidate any argument that you make to the effect that "the system is not useful." You make a second argument, where you attempt to prove that the system is incorrectly used as an authentication mechanism, and therefore should be eliminated so as to discourage this use. Here, your statement is a positive one - you are trying to prove that something is true. So your reason has to support your argument. That is, you have to give evidence. Several people, including me, have asked you to say just who it is that is using the system as an authentication mechanism, and how prevalent this use is. You have not done so. Several of us have stipulated that if, for example, use of r-commands were still common, that would be a bad thing, and we'd want to discourage that, but none of us have seen any evidence that this is in fact so. Indeed, I made a pretty basic statistical case for the idea that it actually *can't* be true - an argument against which you have presented no counterargument. So again, your argument fails to convince, in this case because you have not brought forth any evidence to support it, and you have not even attempted to invalidate any of the counterarguments that have been presented. If you are just trying to convince yourself, that's fine, but you already know you are right, so you needn't argue about it in public. If you are trying to convince *us*, you have to use arguments that actually have that effect. And if you are just trying to vote, well, I know what your vote is now, and, barring some successful argument you or kre may make, you know mine also. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 18:00:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16370 for ; Fri, 12 Jul 2002 18:00:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T8Ix-000MBw-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 14:50:23 -0700 Received: from 12-234-90-219.client.attbi.com ([12.234.90.219]) by psg.com with esmtp (Exim 3.36 #1) id 17T8IV-000M9s-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 14:49:55 -0700 Received: from master.gorean.org (master.gorean.org [10.0.0.2]) by 12-234-90-219.client.attbi.com (8.12.3/8.12.3) with ESMTP id g6CLmwBu000991; Fri, 12 Jul 2002 14:48:58 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from localhost (doug@localhost) by master.gorean.org (8.12.5/8.12.5/Submit) with ESMTP id g6CLmqsf025317; Fri, 12 Jul 2002 14:48:53 -0700 (PDT) Date: Fri, 12 Jul 2002 14:48:52 -0700 (PDT) From: Doug Barton To: Dean Anderson cc: Ted Lemon , namedroppers , Derek Atkins , Robert Elz Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: Message-ID: <20020712144527.M24790-100000@master.gorean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 12 Jul 2002, Dean Anderson wrote: > Ditto. You made objections about my objections, but you just restated that > there is meaning to the state when reverse and forward match. Several of us have stated that FOR US, there is meaning. Some of us are even smart enough to know that the meaning is limited to certain scopes. You obviously believe that there is no meaning whatsoever to reverse records. I'm happy to acknowledge that for you that might be true, but I think that enough people have disagreed with you at this point to show that your point of view is far from universal. > You didn't offer any evidence that there is any meaning to such a state, > except you and some others commonly make that assumption. That others make > the same assumption isn't proof the assumption is true. I alluded to some specific cases in my brief post, but I don't see any point in providing further details because you've obviously made up your mind. Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 18:10:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16868 for ; Fri, 12 Jul 2002 18:10:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T8Ut-000MXM-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 15:02:43 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17T8UP-000MVZ-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 15:02:13 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA32248; Fri, 12 Jul 2002 16:58:21 -0400 Date: Fri, 12 Jul 2002 16:58:53 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Greg Hudson cc: namedroppers Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <1026483436.1185.155.camel@error-messages.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 12 Jul 2002, Greg Hudson wrote: > On Fri, 2002-07-12 at 01:02, Dean Anderson wrote: > > Your disagreement is that your use isn't actually misuse, and that it > > should be OK to use Reverse DNS for authentication or "validation", and > > logging. You have argued that when reverse and forward maps match, that > > there is some kind of useful meaning to be implied from this. I think I > > have shown through several examples that, in fact, there is no meaning > > that can be attached should it happen that forward and reverse match, and > > therefore validation is also a misuse of Reverse DNS. This is the crux of > > the disagreement, I think. > > Of course there is meaning. It means "this domain is listed in the DNS > as the name for this address, and it is not a complete forgery (although > it might be meaningless)." A fine thing to log. Log the IP address > too, since as you pointed out, the name might go away. It could be a complete forgery. As a complete forgery, it might not be actually listed in DNS. So your statement is false. If you log it, you've just logged a false statement. I assert that is a harm. > I wouldn't call this logging a purely aesthetic benefit. You can use > that information to collect statistical data ("look, 30% of our > connections are from IBM") as long as you're willing to accept that > organizations can hide themselves from that collection (don't expect to > find out that another 30% of your connections are coming from the NSA). This has the implied assumption that most or all of your traffic is "honest", by which I mean that the connections aren't spoofed, and there isn't anyone trying to skew your logs. You would be much better off by analyzing the IP addresses into route netblocks, AS numbers or using Whosi information directly to find out where most of your traffic is comming from. 'Log skewing' has happened, and isn't a purely theoretical possibility. > > It is a frequent misconception that reverse DNS can be used for logging, > > and authentication or validation, and therefore a "widespread misuse of > > Reverse DNS." > > There are historical examples of use for authentication (I'm still > unsure what you mean by "validation"), but I'm not aware of any recent > examples. I think your "widespread misuse" is pretty much limited to > the occasional logging of domain names without also logging IP > addresses. Actually, I think validation was Ted's term. By it, I think he meant the same thing you said in your first paragraph: [It means "this domain is listed in the DNS as the name for this address, and it is not a complete forgery (although it might be meaningless)."] But as I said, a false sense of comfort leads one to grant access that should not be granted with the information available. This is sort of thing may have led to the r-cmd problem, and it could still happen, as other kinds of access is granted based on the false sense of comfort obtained when reverse and forward match. As Ted mentioned that authentication would be possible with DNSsec, let me take a minute to put down some thoughts about that. If I recall the dates properly, BSD4.3 was released in 1986, and DNS was invented that same year, or slightly earlier. It seems to me it is likely the rcmds were developed with a hosts file, and then a resolver with reverse DNS introduced later. So perhaps the rcmds weren't developed with a "false" sense of security--the hosts file could be trusted. It was the seemingly innocuous change to use the resolver with reverse DNS that introduced the exploitable security flaw. What I'm getting to, is that one might develop applications that depend on DNSsec with trustable reverse DNS, and then make a similar seemingly innocuous change to not using DNSsec, and in doing so introduce a similar exploitable security flaw. This is a risk of having Reverse DNS. > With forward DNSSEC, of course, it's fine to use reverse DNS for > authentication, as long as you don't want to give anyone negative access > rights (and aren't worried about IP spoofing, for whatever reason). If > I want to say "only these hosts can log in here," reverse DNS works as a > hint. An inline statement in the protocol would work just as well, if > the protocol allows for that; I'm not saying that this is a great idea, > just that it works. Agreed, subject to the limitation that the "trusted" domains _must_ use DNSsec, and that DNSsec must be proven to be unspoofable. I'm not sure if one can claim DNSsec can't be spoofed just yet. . Should DNSsec turn out to be spoofable, then this becomes false. This could be an example of that "seemingly innocuous change", I was talking about above. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 18:48:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18307 for ; Fri, 12 Jul 2002 18:48:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17T97U-000NiO-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 15:42:36 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17T96W-000NgU-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 15:41:36 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id E7A591BA; Fri, 12 Jul 2002 15:41:34 -0700 (PDT) Date: Fri, 12 Jul 2002 15:41:34 -0700 From: David Terrell To: Dean Anderson Cc: Greg Hudson , namedroppers Subject: Re: (ngtrans) The reverse lookup issue Message-ID: <20020712224134.GA23986@pianosa.catch22.org> Reply-To: David Terrell References: <1026483436.1185.155.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 3:37PM up 4 days, 15:29, 38 users, load averages: 0.41, 1.11, 0.92 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jul 12, 2002 at 04:58:53PM -0400, Dean Anderson wrote: > > With forward DNSSEC, of course, it's fine to use reverse DNS for > > authentication, as long as you don't want to give anyone negative access > > rights (and aren't worried about IP spoofing, for whatever reason). If > > I want to say "only these hosts can log in here," reverse DNS works as a > > hint. An inline statement in the protocol would work just as well, if > > the protocol allows for that; I'm not saying that this is a great idea, > > just that it works. > > Agreed, subject to the limitation that the "trusted" domains _must_ use > DNSsec, and that DNSsec must be proven to be unspoofable. I'm not sure if > one can claim DNSsec can't be spoofed just yet. personally know the answer, but rather I think the answer is still an > unknown>. Should DNSsec turn out to be spoofable, then this becomes false. > This could be an example of that "seemingly innocuous change", I was > talking about above. Yes, but then I can break your claimed superior solution of rwhois by simply spoofing the A{,AAA} record of the rwhois server. :) A node to name mapping is a fundamental necessity for various pieces of functionality on the internet. Let's not forget that that mapping, like all others, should be verified and hopefully signed; but it's not a trivially removable component of the architecture of the internet today. -- David Terrell | "The Court understands fully why licensing has many Nebcorp Prime Minister | advantages for software publishers. However, this dbt@meat.net | preference does not alter the Court's analysis that http://wwn.nebcorp.com/ | the substance of the transaction at issue here is a sale and not a license." - Judge Dean Pregerson, Softman v Adobe. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 22:15:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24728 for ; Fri, 12 Jul 2002 22:15:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TCCM-00034Z-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 18:59:50 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17TCBK-00032y-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 18:58:47 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id TAA13955; Fri, 12 Jul 2002 19:13:31 -0400 Date: Fri, 12 Jul 2002 19:14:03 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: David Terrell cc: Greg Hudson , namedroppers Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <20020712224134.GA23986@pianosa.catch22.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 12 Jul 2002, David Terrell wrote: > Yes, but then I can break your claimed superior solution of rwhois > by simply spoofing the A{,AAA} record of the rwhois server. :) Someone (you?) already said that. I replied that doing this is much harder than the former, since the rwhois spoofer does not know _when_ I'll make that lookup. Inconveniently (for the spoofer), its made some variably long time after his bad activity. By contrast, the Reverse/Forward DNS (logging, validation, authentication, etc purpose) spoofer _knows_ when this lookup will be made. Conveniently, its made at roughly the same time as his bad activity. > A node to name mapping is a fundamental necessity for various pieces > of functionality on the internet. Let's not forget that that > mapping, like all others, should be verified and hopefully signed; > but it's not a trivially removable component of the architecture > of the internet today. This is a new objection, unless I missed it before. If so, I'm sorry. What exactly would break irreparably without reverse DNS? --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 12 23:38:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27089 for ; Fri, 12 Jul 2002 23:38:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TDYm-0005bH-00 for namedroppers-data@psg.com; Fri, 12 Jul 2002 20:27:04 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17TDYI-0005b1-00 for namedroppers@ops.ietf.org; Fri, 12 Jul 2002 20:26:34 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6D3QOd24526; Sat, 13 Jul 2002 03:26:25 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6D3QCMP010999; Fri, 12 Jul 2002 22:26:12 -0500 (CDT) Date: Fri, 12 Jul 2002 22:26:11 -0500 Subject: Re: (ngtrans) The reverse lookup issue Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: David Terrell , Greg Hudson , namedroppers To: Dean Anderson From: Ted Lemon In-Reply-To: Message-Id: <47A542A7-9610-11D6-9580-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Someone (you?) already said that. I replied that doing this is much harder > than the former, since the rwhois spoofer does not know _when_ I'll make > that lookup. Inconveniently (for the spoofer), its made some variably long > time after his bad activity. By contrast, the Reverse/Forward DNS > (logging, validation, authentication, etc purpose) spoofer _knows_ when > this lookup will be made. Conveniently, its made at roughly the same time > as his bad activity. Let us take as an axiom that we should only log IP addresses and never log reverse DNS information. If that's so, then when I go to figure out, after the fact, who owns the IP address, I have two tools available to me - the rwhois database, and the DNS. Both are useful. If there is information in the rwhois database, I can use it. If there is information in the DNS, I can use it. It is not the case that either bit of information is definitely true or definitely false; rather, both pieces of information provide me with clues. If I do the lookup later on, the attacker can't know when, whether it's a DNS lookup or an rwhois lookup. But because of the axiom we have chosen, we have forgone one of the clues we might have used in our search for the culprit - we have not recorded the information in the DNS at the time of the event. Like the other two pieces of information, the information from the DNS is a clue, not a provably true statement. But we have one less clue. I agree with you completely that logging just the information from the DNS is wrong; what we disagree on is whether the information from the DNS is useful. I should like to point out to you that spoofing the DNS is not *quite* as easy as you claim. When I go to look up a new PTR record, I probably don' t just go to the NS record that's conveniently in my cache and send the request to that IP address, because I don't have the NS record in my cache yet. In fact, what I do, most likely, is go to the highest zone I've cached, which is probably in-addr.arpa, or if I'm lucky maybe 204.in-addr. arpa, and look up the NS record there. Then I work my way down. So the attacker has to do a pretty difficult job - it has to send in the attack that we're logging, and also guess not one but two or more transaction IDs that my name server will generate, *and* it has to guess what I have in my cache, *and* it has to get the forward lookup right as well, and it has to get the timing right so that the answers come soon enough that they are used, but late enough that they don't anticipate the requests. *Or* it has to be on the local network. Doing this on the local network would be a challenge, but definitely doable. Doing this as a remote attack would be a truly impressive feat. But you are quite right that we can't trust the information the name server returns, unless we have DNSSEC, and maybe not even then. Does that render it useless? No. It's still a clue. It's still useful. Of course it shouldn't be taken as gospel, but it's useful. So your reasoning still isn't valid - you still haven't disproven the premise that logging the reverse zone information from the DNS is useful, nor have you proven, as you assert, that logging this information causes harm. > What exactly would break irreparably without reverse DNS? We would lose a piece of the puzzle that's available to us now. Baby. Bathwater. Need I say more? > But as I said, a false sense of comfort leads one to grant access that > should not be granted with the information available. This is sort of > thing may have led to the r-cmd problem, and it could still happen, as > other kinds of access is granted based on the false sense of comfort You are absolutely right. If people were using the information from the DNS in this way, it would be Bad. Really Bad. We would want to take some kind of action to discourage this practice, perhaps even the course of action you propose. But rounded to the nearest hundred, nobody is using the information in the DNS this way. So why are we even talking about this? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 13 12:00:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26433 for ; Sat, 13 Jul 2002 12:00:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TOzu-0007Da-00 for namedroppers-data@psg.com; Sat, 13 Jul 2002 08:39:50 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17TOzp-0007DP-00 for namedroppers@ops.ietf.org; Sat, 13 Jul 2002 08:39:45 -0700 Received: from engill.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g6DFeXr05264; Sat, 13 Jul 2002 11:40:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020712114029.02af3300@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 12 Jul 2002 11:46:03 -0400 To: Dean Anderson , Ted Lemon From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: (ngtrans) The reverse lookup issue Cc: namedroppers In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_12_24 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:02 AM 7/12/2002, Dean Anderson wrote: >On Thu, 11 Jul 2002, Ted Lemon wrote: > > Unfortunately, I still don't understand your point. I get lots of good > > use out of the reverse mappings, and I really haven't seen any evidence of > > widespread misuse of them. Have you? Care to elaborate? You seem to > > be very happy to keep repeating your basic reasons for objecting, but when > > someone asks you to justify them, you do not do so. > >Well, I think I did state a valid objection. I apologize if I wasn't >clear. I'll try to summarize the issues. kre and I (at least) are in >agreement. > >I think your use ("handy for logging and validation") ought to be >classfied to be misuse, and therefore there is widespread misuse of >Reverse DNS for just those purposes. This discussion has no relevance to the DNS protocol, this is a philosophy discussion. Please DO NOT post any more messages to namedroppers on this subject. Olafur DNSEXT co-chair. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 14 07:45:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02408 for ; Sun, 14 Jul 2002 07:45:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ThWu-0008Vj-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 04:27:08 -0700 Received: from astrid2.nic.fr ([192.134.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 17ThWp-0008VY-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 04:27:04 -0700 Received: from kerkenna.nic.fr (IDENT:99PNixFycqQ1B99ed5KrCJARlkkaGDv3@kerkenna.nic.fr [192.134.4.98]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id NAA27987 ; Sun, 14 Jul 2002 13:25:35 +0200 (MET DST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id g6EBPZ828459; Sun, 14 Jul 2002 13:25:35 +0200 Date: Sun, 14 Jul 2002 13:25:35 +0200 From: Mohsen Souissi To: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Cc: vladimir ksinant , RFC1886 Interop tests , g6@g6.asso.fr Subject: RFC 1886 Interop Tests & Results Message-ID: <20020714132535.A28205@kerkenna.nic.fr> References: <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D2EA251.D9CBA0A0@6wind.com>; from vladimir.ksinant@6wind.com on Fri, Jul 12, 2002 at 10:33:05AM +0100 X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,MAILTO_TO_SPAM_ADDR version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, Upon request from Alain Durand (Co-Chair of ngtrans wg) and Olafur Gudmundsson (Co-chair of dnsext wg), 6WIND, AFNIC, France Telecom R&D and IRISA (as members of G6) organized RFC1886 interop tests in last June-July 2002. Three well-known server implementations and 2 resolver implementations were used. The results are : - 2 server implementations are fully interoperable as defined in RFC1886 (section 2 and section 3). - The two resolvers have identical behaviors and are correct. - A third server is partially in conformity with RFC 1886: it does not perform correctly additional section processing (section 3 of RFC1886) for MX, SRV, NS and SOA . The description and results of the tests are now online: IPv4 : http://www.6wind.com/RFC1886/testRFC1886.html IPv6 : http://www.ipv6.6wind.com/standard/testRFC1886.html All comments/questions (which may be sent to rfc1886@nic.fr) will be welcome. Cheers, Mohsen (for RFC1886 Interop tests team). P.S. I apologize beforehand for possible multiple copies. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 14 09:45:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05983 for ; Sun, 14 Jul 2002 09:45:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TjQg-000ArI-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 06:28:50 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17TjQc-000Ar6-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 06:28:46 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02484; Sun, 14 Jul 2002 07:28:43 -0600 (MDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6EDSag00124; Sun, 14 Jul 2002 15:28:37 +0200 (MEST) Date: Sun, 14 Jul 2002 15:26:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard To: rfc-editor@rfc-editor.org Cc: Erik.Nordmark@sun.com, rhall@quadritek.com, bmanning@ISI.EDU, mayer@gis.net, iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Erik and Randy, > > We have ready to go. Should we be > waiting for an updated version of this document? Yes, this issue needs to be inspected further. We've set the deadline to have a proposed solution to be Sept 1 - after that we either publish the document with the bug or figure out how to withdraw it. But the hope is that a fix will be presented and reviewed before Sept 1. Thanks, Erik > RFC Editor > > > > From rfc-ed@ISI.EDU Fri Apr 5 10:09:55 2002 > > Date: Fri, 05 Apr 2002 13:10:07 -0500 > > From: rhall@quadritek.com (Randy Hall) > > X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) > > X-Accept-Language: en > > MIME-Version: 1.0 > > To: Erik Nordmark > > CC: Bill Manning , Danny Mayer , > > iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, > > namedroppers@ops.ietf.org > > Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed > > Standard > > Content-Transfer-Encoding: 7bit > > X-AntiVirus: scanned by AMaViS 0.2.1 > > > > Erik Nordmark wrote: > > > > > > There were (IMO) bugs in the TKEY, TSIG, and other protocols > > > > that needed fixing, and some changes (IMO) were needed (and > > > > made) to the protocol, but there were no IP issues relating > > > > these issues. > > > > > Where these bugs in the RFCs or bugs in an implementation of > > > those RFCs? > > > > Implementation. > > > > Cheers > > Randy > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 14 16:25:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16097 for ; Sun, 14 Jul 2002 16:25:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Tpcr-000LjH-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 13:05:49 -0700 Received: from citation.av8.net ([130.105.12.4]) by psg.com with esmtp (Exim 3.36 #1) id 17Tpcl-000Liu-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 13:05:43 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA10028; Sun, 14 Jul 2002 15:57:24 -0400 Date: Sun, 14 Jul 2002 15:57:59 -0400 (EDT) From: Dean Anderson X-Sender: dean@commander.av8.net To: Ted Lemon cc: David Terrell , Greg Hudson , namedroppers Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <47A542A7-9610-11D6-9580-00039367340A@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 12 Jul 2002, Ted Lemon wrote: > > Someone (you?) already said that. I replied that doing this is much harder > > than the former, since the rwhois spoofer does not know _when_ I'll make > > that lookup. Inconveniently (for the spoofer), its made some variably long > > time after his bad activity. By contrast, the Reverse/Forward DNS > > (logging, validation, authentication, etc purpose) spoofer _knows_ when > > this lookup will be made. Conveniently, its made at roughly the same time > > as his bad activity. > > Let us take as an axiom that we should only log IP addresses and never log > reverse DNS information. If that's so, then when I go to figure out, > after the fact, who owns the IP address, I have two tools available to me > - the rwhois database, and the DNS. Both are useful. If there is > information in the rwhois database, I can use it. If there is information > in the DNS, I can use it. It is not the case that either bit of > information is definitely true or definitely false; rather, both pieces of > information provide me with clues. If I do the lookup later on, the > attacker can't know when, whether it's a DNS lookup or an rwhois lookup. With the exception that a spoofer can make the DNS information false. When the Rwhois information is false, its due to adminstrative error by the rwhois authority. > But because of the axiom we have chosen, we have forgone one of the clues > we might have used in our search for the culprit - we have not recorded the > information in the DNS at the time of the event. Like the other two > pieces of information, the information from the DNS is a clue, not a > provably true statement. But we have one less clue. I agree with you > completely that logging just the information from the DNS is wrong; what we > disagree on is whether the information from the DNS is useful. Except that as a clue, it could be misleading, and whether it is misleading is under the control of the bad people. This is somewhat analogous to the testimony of convicted criminals. You can't be sure of whether they are telling the truth, or attempting to frame someone else. > I should like to point out to you that spoofing the DNS is not *quite* as > easy as you claim. When I go to look up a new PTR record, I probably don' "Easy" depends on either skills or tools. For example, there are now plenty of tools to root linux boxes. Such tools are used by people who don't have any skills at administering linux boxes or even how the exploits work, as I have directly observed with analyzing rooted linux boxes. There could be tools to spoof reverse DNS. > So the attacker has to do a pretty difficult job - it has to send in the > attack that we're logging, and also guess not one but two or more > transaction IDs that my name server will generate, *and* it has to guess > what I have in my cache, *and* it has to get the forward lookup right as > well, and it has to get the timing right so that the answers come soon > enough that they are used, but late enough that they don't anticipate the > requests. *Or* it has to be on the local network. Doing this on the > local network would be a challenge, but definitely doable. Doing this as > a remote attack would be a truly impressive feat. It was easy enough to exploit rcmds vulnerabilities remotely. It could be harder with more random transaction ids, but as we know, there aren't truly random numbers. So the task becomes "trivial" again once you can predict the random number sequence. > But you are quite right that we can't trust the information the name server > returns, unless we have DNSSEC, and maybe not even then. Does that render > it useless? No. It's still a clue. It's still useful. Of course it > shouldn't be taken as gospel, but it's useful. So your reasoning still And how are we to argue against those who say it should be "taken as gospel"? > isn't valid - you still haven't disproven the premise that logging the > reverse zone information from the DNS is useful, nor have you proven, as > you assert, that logging this information causes harm. > > What exactly would break irreparably without reverse DNS? > > We would lose a piece of the puzzle that's available to us now. Baby. > Bathwater. Need I say more? Yes. You should say more. I can't think of anything that would break, except the illusions of many people have the reverse DNS is something absolutely trustworthy, and absolutely necesary before any trust should be given. > > But as I said, a false sense of comfort leads one to grant access that > > should not be granted with the information available. This is sort of > > thing may have led to the r-cmd problem, and it could still happen, as > > other kinds of access is granted based on the false sense of comfort > > You are absolutely right. If people were using the information from the > DNS in this way, it would be Bad. Really Bad. We would want to take > some kind of action to discourage this practice, perhaps even the course of > action you propose. But rounded to the nearest hundred, nobody is using > the information in the DNS this way. So why are we even talking about > this? OK. So you agree that if people are putting too much trust in reverse DNS, then it would be reasonable to remove Reverse DNS. I think a lot of people are using reverse DNS in this way. Recent discussions on Nanog revolved around the "evil" of ATTBI not delegating or populating reverse DNS. I would like to propose a compromise as a way to bumble forward: I could be happy with optional reverse DNS provided there were very strong statements made which indicate that the answers given by Reverse DNS have no special meaning even if "coroborated" by forward DNS, and that DNS shouldn't be used for logging, or authentication, or any sort of validation purpose, and that Reverse DNS is an optional, purely cosmetic service. Would you agree to this? --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 14 18:04:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18389 for ; Sun, 14 Jul 2002 18:04:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Tr1p-000Oh8-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 14:35:41 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17Tr1k-000Ogv-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 14:35:36 -0700 Received: by coconut.itojun.org (Postfix, from userid 1001) id 84B6E4B22; Mon, 15 Jul 2002 06:35:32 +0900 (JST) To: Mohsen.Souissi@nic.fr Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr Subject: Re: RFC 1886 Interop Tests & Results In-Reply-To: Your message of "Sun, 14 Jul 2002 13:25:35 +0200" <20020714132535.A28205@kerkenna.nic.fr> References: <20020714132535.A28205@kerkenna.nic.fr> X-Mailer: Cue version 0.6 (010821-2319/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20020714213532.84B6E4B22@coconut.itojun.org> Date: Mon, 15 Jul 2002 06:35:32 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Upon request from Alain Durand (Co-Chair of ngtrans wg) and Olafur > Gudmundsson (Co-chair of dnsext wg), 6WIND, AFNIC, France Telecom R&D > and IRISA (as members of G6) organized RFC1886 interop tests in last > June-July 2002. > Three well-known server implementations and 2 resolver implementations > were used. the co-existence of ip6.int and ip6.arpa tree will require us to: query ip6.arpa; if (no record) query ip6.int; for backward compatibility. was it taken into account, or did you test just "ip6.arpa" lookups? itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 14 19:26:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20721 for ; Sun, 14 Jul 2002 19:26:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TsZE-0002Xq-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 16:14:16 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17TsZ9-0002Xe-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 16:14:11 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17TsZ8-00039Y-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 08:14:10 +0900 Mime-Version: 1.0 Message-Id: In-Reply-To: <20020714213532.84B6E4B22@coconut.itojun.org> References: <20020714132535.A28205@kerkenna.nic.fr> <20020714213532.84B6E4B22@coconut.itojun.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Date: Mon, 15 Jul 2002 01:10:44 +0200 To: itojun@itojun.org (Jun-ichiro itojun Hagino), Mohsen.Souissi@nic.fr From: Brad Knowles Subject: Re: RFC 1886 Interop Tests & Results Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr X-Spam-Status: No, hits=-7.5 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At 6:35 AM +0900 2002/07/15, Jun-ichiro itojun Hagino wrote: > the co-existence of ip6.int and ip6.arpa tree will require us to: > query ip6.arpa; > if (no record) > query ip6.int; > for backward compatibility. was it taken into account, or did you > test just "ip6.arpa" lookups? I checked the source code for BIND 9.2.1, and IIRC it checks ip6.int first and then ip6.arpa second. This allows us to stand up ip6.arpa whenever, and then once that is set, we can tear down ip6.int. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 14 21:34:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23890 for ; Sun, 14 Jul 2002 21:34:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TucQ-0008w1-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 18:25:42 -0700 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17TucK-0008um-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 18:25:36 -0700 Received: from tecotoo.www.gis.net ([216.41.47.145]) by mx03.gis.net; Sun, 14 Jul 2002 21:25:34 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id aa027768 for ; Sun, 14 Jul 2002 21:25:16 -0400 Message-Id: <4.3.1.2.20020714212352.00e9f980@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 14 Jul 2002 21:25:02 -0400 To: Erik Nordmark , rfc-editor@rfc-editor.org From: Danny Mayer Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Cc: Erik.Nordmark@sun.com, rhall@quadritek.com, bmanning@ISI.EDU, iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, namedroppers@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:26 AM 7/14/02, Erik Nordmark wrote: > > Erik and Randy, > > > > We have ready to go. Should we be > > waiting for an updated version of this document? > >Yes, this issue needs to be inspected further. >We've set the deadline to have a proposed solution to be Sept 1 - after >that we either publish the document with the bug or figure out how to withdraw >it. But the hope is that a fix will be presented and reviewed before Sept 1. It would be wrong to publish a document with a bug in it. Danny >Thanks, > Erik > > > RFC Editor > > > > > > > From rfc-ed@ISI.EDU Fri Apr 5 10:09:55 2002 > > > Date: Fri, 05 Apr 2002 13:10:07 -0500 > > > From: rhall@quadritek.com (Randy Hall) > > > X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) > > > X-Accept-Language: en > > > MIME-Version: 1.0 > > > To: Erik Nordmark > > > CC: Bill Manning , Danny Mayer , > > > iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, > > > namedroppers@ops.ietf.org > > > Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) > to Proposed > > > Standard > > > Content-Transfer-Encoding: 7bit > > > X-AntiVirus: scanned by AMaViS 0.2.1 > > > > > > Erik Nordmark wrote: > > > > > > > > There were (IMO) bugs in the TKEY, TSIG, and other protocols > > > > > that needed fixing, and some changes (IMO) were needed (and > > > > > made) to the protocol, but there were no IP issues relating > > > > > these issues. > > > > > > > Where these bugs in the RFCs or bugs in an implementation of > > > > those RFCs? > > > > > > Implementation. > > > > > > Cheers > > > Randy > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 14 21:39:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24030 for ; Sun, 14 Jul 2002 21:39:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TuZg-0008k5-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 18:22:52 -0700 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17TuZc-0008jo-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 18:22:48 -0700 Received: from tecotoo.www.gis.net ([216.41.47.145]) by mx03.gis.net; Sun, 14 Jul 2002 21:22:45 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id na027755 for ; Sun, 14 Jul 2002 21:22:33 -0400 Message-Id: <4.3.1.2.20020714211757.00e89480@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 14 Jul 2002 21:22:15 -0400 To: Mohsen Souissi , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: Danny Mayer Subject: Re: RFC 1886 Interop Tests & Results Cc: vladimir ksinant , RFC1886 Interop tests , g6@g6.asso.fr In-Reply-To: <20020714132535.A28205@kerkenna.nic.fr> References: <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,MAILTO_TO_SPAM_ADDR,RCVD_IN_OSIRUSOFT_COM version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 07:25 AM 7/14/02, Mohsen Souissi wrote: >Hello, > >Upon request from Alain Durand (Co-Chair of ngtrans wg) and Olafur >Gudmundsson (Co-chair of dnsext wg), 6WIND, AFNIC, France Telecom R&D >and IRISA (as members of G6) organized RFC1886 interop tests in last >June-July 2002. > >Three well-known server implementations and 2 resolver implementations >were used. > >The results are : >- 2 server implementations are fully interoperable as defined in RFC1886 >(section 2 and section 3). >- The two resolvers have identical behaviors and are correct. >- A third server is partially in conformity with RFC 1886: it does not >perform correctly additional section processing (section 3 of RFC1886) >for MX, SRV, NS and SOA . > >The description and results of the tests are now online: > >IPv4 : http://www.6wind.com/RFC1886/testRFC1886.html >IPv6 : http://www.ipv6.6wind.com/standard/testRFC1886.html > >All comments/questions (which may be sent to rfc1886@nic.fr) will be welcome. > >Cheers, > >Mohsen (for RFC1886 Interop tests team). > >P.S. I apologize beforehand for possible multiple copies. Two comments: 1) The data is most peculiar since nowhere that I could find are X, Y and Z identified. If they are somewhere I couldn't find it. Is there a reason to keep them obscured? 2) dig 8.3 is available for Windows XP. Just pick up the BIND8.3.3Tools.zip kit from the ISC Web site. You need dig.exe and libbind.dll in the same place or libbind.dll in the PATH. It's better to use the same tool for all tests. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 00:04:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29357 for ; Mon, 15 Jul 2002 00:04:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Twtv-000Fkm-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 20:51:55 -0700 Received: from [133.93.71.210] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.36 #1) id 17Twtp-000Fkb-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 20:51:49 -0700 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6F3oVO10011; Mon, 15 Jul 2002 12:50:32 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Andy W. Barclay" cc: Ted Lemon , Dean Anderson , namedroppers@ops.ietf.org, Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: <3D2D9C50.2080201@unixpeople.com> References: <3D2D9C50.2080201@unixpeople.com> <6966.1026378211@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Jul 2002 12:50:31 +0900 Message-ID: <10009.1026705031@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 11 Jul 2002 07:55:12 -0700 From: "Andy W. Barclay" Message-ID: <3D2D9C50.2080201@unixpeople.com> | I'm assuming that your last sentence was incomplete here. | You really meant ot say that "the data should not be used for | authentication" right? | | "should not be used" is silly. Yes - but what it said was "about how the data should not be used." That is, I wasn't actually saying what it should say, just that it should say some things about inappropriate uses. If we ever got to agree on at least this much, then we could start the debate about what uses are inappropriate and should be warned against. | FWIW, I use the information in reverse DNS all the time. I don't | authenticate with it, but I still find it usefull for information | purposes. Yes, so do I, though I find I use the -n options to ping/traceroute much more often than I omit them. But the fact that I (or you) like to make use of other people's work doesn't mean they should forced, requested or even just encouraged, to provide it. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 00:33:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00264 for ; Mon, 15 Jul 2002 00:33:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TxP5-000HAF-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 21:24:07 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17TxP0-000HA2-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 21:24:02 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA02306; Mon, 15 Jul 2002 00:23:53 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA07957; Mon, 15 Jul 2002 00:23:52 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA28757; Mon, 15 Jul 2002 00:23:51 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id AAA21918; Mon, 15 Jul 2002 00:23:51 -0400 (EDT) To: Robert Elz Cc: "Andy W. Barclay" , Ted Lemon , Dean Anderson , namedroppers@ops.ietf.org, Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue References: <3D2D9C50.2080201@unixpeople.com> <6966.1026378211@munnari.OZ.AU> <10009.1026705031@munnari.OZ.AU> From: Derek Atkins Date: 15 Jul 2002 00:23:50 -0400 In-Reply-To: <10009.1026705031@munnari.OZ.AU> Message-ID: Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > | FWIW, I use the information in reverse DNS all the time. I don't > | authenticate with it, but I still find it usefull for information > | purposes. > > Yes, so do I, though I find I use the -n options to ping/traceroute > much more often than I omit them. But the fact that I (or you) like > to make use of other people's work doesn't mean they should forced, > requested or even just encouraged, to provide it. I find that I use the -n options when I want to rule out a DNS problem. Once I'm sure that the network is up via -n, I kill ping/traceroute/mtr and re-run without -n to see where it's actually going. My take on where we are now is that there is enough use to NOT depricate reverse-resolution, but perhaps add some language in the Security Considerations that say something to affect of: "Using DNS Reverse Resolution for Authentication is dangerous." > kre -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 02:04:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06897 for ; Mon, 15 Jul 2002 02:04:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TyoW-000LDD-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 22:54:28 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17TyoK-000LD1-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 22:54:23 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17TyoK-0003m8-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 14:54:16 +0900 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 15 Jul 2002 08:49:22 +0300 (EEST) From: Pekka Savola To: Brad Knowles cc: Jun-ichiro itojun Hagino , , , , , , , , Subject: Re: RFC 1886 Interop Tests & Results X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 15 Jul 2002, Brad Knowles wrote: [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > At 6:35 AM +0900 2002/07/15, Jun-ichiro itojun Hagino wrote: > > > the co-existence of ip6.int and ip6.arpa tree will require us to: > > query ip6.arpa; > > if (no record) > > query ip6.int; > > for backward compatibility. was it taken into account, or did you > > test just "ip6.arpa" lookups? > > I checked the source code for BIND 9.2.1, and IIRC it checks > ip6.int first and then ip6.arpa second. This allows us to stand up > ip6.arpa whenever, and then once that is set, we can tear down > ip6.int. FWIW, e.g. Linux glibc resolver only checks ip6.arpa now, so you'd better start standing up.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 02:51:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13663 for ; Mon, 15 Jul 2002 02:51:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17TzTg-000N5Z-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 23:37:00 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17TzTV-000N5O-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 23:36:50 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17TzTU-0003pS-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 15:36:49 +0900 Message-Id: <200207150621.GAA14594@vacation.karoshi.com> In-Reply-To: from "Pekka Savola" at Jul 15, 2002 08:49:22 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@karoshi.com Subject: Re: RFC 1886 Interop Tests & Results To: pekkas@netcore.fi (Pekka Savola) Date: Mon, 15 Jul 2002 06:21:45 +0000 (UCT) Cc: brad.knowles@skynet.be (Brad Knowles), itojun@itojun.org (Jun-ichiro itojun Hagino), Mohsen.Souissi@nic.fr, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr X-Spam-Status: No, hits=-6.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > On Mon, 15 Jul 2002, Brad Knowles wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > > At 6:35 AM +0900 2002/07/15, Jun-ichiro itojun Hagino wrote: > > > > > the co-existence of ip6.int and ip6.arpa tree will require us to: > > > query ip6.arpa; > > > if (no record) > > > query ip6.int; > > > for backward compatibility. was it taken into account, or did you > > > test just "ip6.arpa" lookups? > > > > I checked the source code for BIND 9.2.1, and IIRC it checks > > ip6.int first and then ip6.arpa second. This allows us to stand up > > ip6.arpa whenever, and then once that is set, we can tear down > > ip6.int. > > FWIW, e.g. Linux glibc resolver only checks ip6.arpa now, so you'd better > start standing up.. > Yet another instance of Linux jumping the gun... :) --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 03:06:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14181 for ; Mon, 15 Jul 2002 03:06:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Tzm1-000Nwb-00 for namedroppers-data@psg.com; Sun, 14 Jul 2002 23:55:57 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17Tzlt-000Nv6-00 for namedroppers@ops.ietf.org; Sun, 14 Jul 2002 23:55:49 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 3583738F; Sun, 14 Jul 2002 23:55:48 -0700 (PDT) Date: Sun, 14 Jul 2002 23:55:48 -0700 From: David Terrell To: Pekka Savola Cc: Brad Knowles , Jun-ichiro itojun Hagino , Mohsen.Souissi@nic.fr, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr Subject: Re: RFC 1886 Interop Tests & Results Message-ID: <20020715065547.GA16956@pianosa.catch22.org> Reply-To: David Terrell References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 11:47PM up 6 days, 23:39, 37 users, load averages: 0.26, 0.33, 0.25 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Jul 15, 2002 at 08:49:22AM +0300, Pekka Savola wrote: > On Mon, 15 Jul 2002, Brad Knowles wrote: > > At 6:35 AM +0900 2002/07/15, Jun-ichiro itojun Hagino wrote: > > > > > the co-existence of ip6.int and ip6.arpa tree will require us to: > > > query ip6.arpa; > > > if (no record) > > > query ip6.int; > > > for backward compatibility. was it taken into account, or did you > > > test just "ip6.arpa" lookups? > > > > I checked the source code for BIND 9.2.1, and IIRC it checks > > ip6.int first and then ip6.arpa second. This allows us to stand up > > ip6.arpa whenever, and then once that is set, we can tear down > > ip6.int. > > FWIW, e.g. Linux glibc resolver only checks ip6.arpa now, so you'd better > start standing up.. 2.0.0.2.ip6.arpa: NXDOMAIN e.f.f.3.ip6.arpa: NXDOMAIN That's probably 70-80% of all IP6 deployments reachable via the public ipv6 internet (granted, especially most 2002:: folks don't have reverse DNS set up yet, but plenty do...). It would be reasonable for glibc to at least make fallback to ip6.int an option... -- David Terrell | "Any sufficiently advanced technology Prime Minister, Nebcorp | is indistinguishable from a rigged demo." dbt@meat.net | - Brian Swetland http://wwn.nebcorp.com/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 03:47:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15421 for ; Mon, 15 Jul 2002 03:47:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17U0Ty-000PVl-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 00:41:22 -0700 Received: from [133.93.71.210] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.36 #1) id 17U0TT-000PVI-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 00:40:51 -0700 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6F7dQO11462; Mon, 15 Jul 2002 16:39:31 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Derek Atkins cc: "Andy W. Barclay" , Ted Lemon , Dean Anderson , namedroppers@ops.ietf.org, Derek Atkins Subject: Re: (ngtrans) The reverse lookup issue In-Reply-To: References: <3D2D9C50.2080201@unixpeople.com> <6966.1026378211@munnari.OZ.AU> <10009.1026705031@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Jul 2002 16:39:26 +0900 Message-ID: <11460.1026718766@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 15 Jul 2002 00:23:50 -0400 From: Derek Atkins Message-ID: We have already been asked to stop this on namedroppers, it probably really belongs on dnsop, the last message I posted before I saw that request, but since this is still here, just one last message from me. | My take on where we are now is that there is enough use to NOT | depricate reverse-resolution, Personally, I never wanted to actually deprecate it. What I want to do is get rid of the expectation that it is supposed to be done. That is, that networks that don't bother to set up reverse delegation stop being treated as a lower form of life which should be denied all kinds of service. So... | but perhaps add some language in | the Security Considerations that say something to affect of: | | "Using DNS Reverse Resolution for Authentication is dangerous." Of course, no-one would object to that. But that's not enough. Something more to the effect of There is no requirement to configure reverse delegations for assigned network numbers. Applications should not refuse service to an incoming connection merely because no reverse delegation for the source network address exists. is what is required. The first sentence merely states the status quo anyway - no-one is being forced to make a reverse delegation. The second is really a logical consequence of deciding that the first is OK. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 17:41:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17330 for ; Mon, 15 Jul 2002 17:41:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UDJ1-000OQw-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 14:22:55 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17UDI9-000OPA-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 14:22:01 -0700 Received: from engill.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g6FLMQr09293; Mon, 15 Jul 2002 17:22:27 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020715102701.028204b0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 15 Jul 2002 10:57:28 -0400 To: Danny Mayer , Mohsen Souissi , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: RFC 1886 Interop Tests & Results Cc: vladimir ksinant , RFC1886 Interop tests , g6@g6.asso.fr In-Reply-To: <4.3.1.2.20020714211757.00e89480@pop.gis.net> References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_06_12 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:22 PM 7/14/2002, Danny Mayer wrote: >At 07:25 AM 7/14/02, Mohsen Souissi wrote: >>Hello, >> >>Upon request from Alain Durand (Co-Chair of ngtrans wg) and Olafur >>Gudmundsson (Co-chair of dnsext wg), 6WIND, AFNIC, France Telecom R&D >>and IRISA (as members of G6) organized RFC1886 interop tests in last >>June-July 2002. > >Two comments: >1) The data is most peculiar since nowhere that I could find are X, Y and Z >identified. If they are somewhere I couldn't find it. Is there a reason >to keep >them obscured? This is standard procedure in DNSEXT interop testing and reporting. The vendors have access to the full reports and I have been in contact with the vendor that "failed" additional section processing and they will fix this in their next release. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 19:22:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19761 for ; Mon, 15 Jul 2002 19:22:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UExa-00024s-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 16:08:54 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17UExC-00023P-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 16:08:30 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17UEx9-0004IS-00; Tue, 16 Jul 2002 08:08:27 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> Message-Id: Date: Tue, 16 Jul 2002 08:08:27 +0900 X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> 1) The data is most peculiar since nowhere that I could find are X, Y and Z >> identified. If they are somewhere I couldn't find it. Is there a reason >> to keep them obscured? > This is standard procedure in DNSEXT interop testing and reporting. s/DNSEXT/IETF/ the point is that the vendors' products are not what is being tested. what we are testing is the *spec* by testing if multiple implementors interpreted it sufficiently similarly to create interoperable implementations. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 20:40:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21413 for ; Mon, 15 Jul 2002 20:40:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UGHC-0005Qv-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 17:33:14 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17UGH8-0005Qk-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 17:33:10 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6FKVu23046430 for ; Mon, 15 Jul 2002 20:31:56 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA05602 for ; Mon, 15 Jul 2002 20:33:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 15 Jul 2002 20:32:59 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: dnssec discussion today at noon Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.2 required=5.0 tests=MSGID_CHARS_WEIRD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There will be a hastily-organized, informal gathering to talk about where DNSSEC is (now that we see implementations of the DS record) and is going. The gathering is in room 415, from noon until 1 today (Tuesday of the IETF). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 21:08:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22370 for ; Mon, 15 Jul 2002 21:08:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UGi9-0006iy-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 18:01:05 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17UGhU-0006hq-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 18:00:24 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17UGhT-0004fH-00; Tue, 16 Jul 2002 10:00:23 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Lewis Cc: namedroppers@ops.ietf.org, dns op wg , dnssec@cafax.se Subject: Re: dnssec discussion today at noon References: Message-Id: Date: Tue, 16 Jul 2002 10:00:23 +0900 X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There will be a hastily-organized, informal gathering to talk about > where DNSSEC is (now that we see implementations of the DS record) > and is going. by the way, i know this will come as a surprise, but there will also be an actual wg meeting of dnsext, where this subject will be covered. :-) randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 21:19:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22712 for ; Mon, 15 Jul 2002 21:19:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UGtX-0007Eb-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 18:12:51 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17UGsH-0007Aq-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 18:11:33 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17UGsH-0004hM-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 10:11:33 +0900 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 15 Jul 2002 21:08:24 -0400 (EDT) From: Sam Weiler To: cc: , , Subject: DS mini-workshop results X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] A small DS workshop was held in Rockville on Wednesday, July 3, 2002. Our main goal was to try to identify any showstopper bugs in Nominum's code prior to holding a larger workshop. Attendees included Russ Mundy, Sam Weiler, Scott Rose, Ed Lewis, Wes Griffin, Andy Vaskys, Olafur Gudmundsson, Roger Hartmuller, Lindy Foster, Tom Newell, and Rip Loomis. Quick summary: Nominum's and Olafur's authoritative servers worked and interoperated, to the extent of our testing. There were bugs in Nominum's recursive resolver, but basic cases generally worked as expected. I've listed some of the issues raised. Bug reports have been passed back to Nominum, and a more detailed report may be available later. Item 1: TTLs v. SIG lifetimes. If the SIG on an RRset expires sooner than its TTL, what should the TTL for the cached RRset be? Someone (Ed?) proposed that the TTL should be the minimum of: the TTL on the incoming RR, the original TTL in the SIG, or the remaining time on the SIG. Item 2: TTLs in chains. If you set the TTL to the smallest remaining TTL of all the RRs needed to validate an RRset, then you're restricted to the shortest of the parents' (including the root's) timeouts. Delegations can't set longer timeouts, and, worse, everything under .com will time out at once, pounding the nameservers. Perhaps the TTL should be set to that minimum less some random amount. Item 3: Erroneous AA bits with CNAMES. Assume islands of trust, with a CNAME in one and the associated A in another. Query for the (non-existent) A at the first zone. With no DNSSEC checking enabled, asking a recursive server that's also authoritative for the CNAME zone returns BOTH CNAME and A and sets AA. With DNSSEC, also get AA. In the first case, you're not AA for the A record. In the second, you should be saying AD for the A record, not AA. Asking a recursive only server with only the first zone's key configured gives neither AA nor AD. (perhaps correct) If both keys are configured, you get AD. (correct) Item 4: When DS records or KEYs changed, recursive resolvers that had cached the old records still answered, but gave no AD. Why the change? Shouldn't they still give out ADs until the cache expires? Item 5: Unexplained and inconsistent SERVFAILs asking for DS records from recursive servers, especially when testing islands of trust (see below). Some things tested: DS delegations key rollover AXFR islands of trust: [ signed ] \ [ signed ] / \ [ unsigned ] [ signed ] / [ signed ] / [ signed ] Not tested: deep DS delegations TSIG -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 21:45:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23484 for ; Mon, 15 Jul 2002 21:45:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UHGg-0008Aj-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 18:36:46 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17UHGc-0008AY-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 18:36:42 -0700 Received: from [133.93.76.134] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 5C4FE137F02; Mon, 15 Jul 2002 18:36:41 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 16 Jul 2002 10:36:40 +0900 Subject: Re: [vet-DS]DS mini-workshop results From: David Conrad To: Sam Weiler , DNS Operations Cc: dnssec , , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not to be too pedantic, but in a recent message on namedroppers regarding RFC 1886 interoperability testing, the following was stated: >> 1) The data is most peculiar since nowhere that I could find are X, Y and Z >> identified. If they are somewhere I couldn't find it. Is there a reason >> to keep them obscured? > This is standard procedure in DNSEXT interop testing and reporting. Yet, Nominum gets identified in DS testing: On 7/16/02 10:08 AM, "Sam Weiler" wrote: > Quick summary: Nominum's and Olafur's authoritative servers worked and > interoperated, to the extent of our testing. There were bugs in > Nominum's recursive resolver, but basic cases generally worked as > expected. Might I suggest a bit of consistency here? I'm very much in favor of interop testing, but I'd prefer to avoid the hassle of defending our participation in informal interop events to my marketing/pr folks. Tnx, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 21:48:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23703 for ; Mon, 15 Jul 2002 21:48:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UHOQ-0008Vw-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 18:44:46 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17UHOI-0008VY-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 18:44:38 -0700 Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3CCF01902 for ; Mon, 15 Jul 2002 21:44:37 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 7DFFF3D for ; Tue, 16 Jul 2002 01:44:32 +0000 (GMT) Date: Tue, 16 Jul 2002 10:44:03 +0900 From: Rob Austein To: namedroppers@ops.ietf.org Subject: DNSEXT WG agenda In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigorymae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020716014432.7DFFF3D@thangorodrim.hactrn.net> X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,OPT_IN,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk With apologies for the extreme last minute nature of this (we miss you, Olafur :), here's the agenda and doc list for this afternoon's DNSEXT WG meeting. * $Date: 2002/07/16 01:32:18 $ . * Agenda . + Hello . + Procure scribe . + Bash agenda . + Status of WG documents . + Interoperability reports . + WG document discussion (see doc list) . + Other documents . + Any other business . + Bye . * Interoperability reports . + RFC 1886 interop test . + DS interop test . + Plea from chairs for more interop test reports . * Document list . + Published as RFC or in RFC Editor queue . - draft-ietf-dnsext-ipv6-addresses-02.txt . - draft-ietf-dnsext-dnsmib-historical-00.txt . - draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt . - draft-ietf-dnsext-gss-tsig-05.txt . - draft-ietf-dnsext-message-size-04.txt . + In IETF last call . - draft-ietf-dnsext-restrict-key-for-dnssec-03.txt . - draft-ietf-dnsext-delegation-signer-08.txt . + Back in WG's lap . - draft-ietf-dnsext-ad-is-secure-06.txt . - draft-ietf-dnsext-dnssec-roadmap-05.txt . + Ready for WG last call? . - draft-ietf-dnsext-dnssec-records-01.txt . - draft-ietf-dnsext-unknown-rrs-03.txt . - draft-ietf-dnsext-dnssec-intro-01.txt . - draft-ietf-dnsext-rfc2536bis-dsa-01.txt . - draft-ietf-dnsext-rfc2539bis-dhk-01.txt . - draft-ietf-dnsext-mdns-10.txt . + WG not finished yet . - draft-ietf-dnsext-axfr-clarify-04.txt . - draft-ietf-dnsext-dnssec-opt-in-02.txt . - draft-ietf-dnsext-obsolete-iquery-03.txt . - draft-ietf-dnsext-dns-threats-01.txt . - draft-ietf-dnsext-tkey-renewal-mode-01.txt . + Blocked waiting for other documents . - draft-ietf-dnsext-ecc-key-01.txt . - draft-ietf-dnsext-dhcid-rr-05.txt . + Other documents . - draft-kitamura-ipv6-name-auto-reg-01.txt . - draft-dnsext-opcode-discover-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 22:08:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24475 for ; Mon, 15 Jul 2002 22:08:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UHhP-0009Nz-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 19:04:23 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17UHh1-0009NZ-00; Mon, 15 Jul 2002 19:04:00 -0700 From: Masataka Ohta Message-Id: <200207160149.KAA02116@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA02116; Tue, 16 Jul 2002 10:48:46 +0859 Subject: Re: dnssec discussion today at noon To: randy@psg.com (Randy Bush) Date: Tue, 16 Jul 2 10:48:45 JST Cc: edlewis@arin.net, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se In-Reply-To: ; from "Randy Bush" at Jul 16, 102 10:13 am X-Mailer: ELM [version 2.3 PL11] X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,INVALID_DATE,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > There will be a hastily-organized, informal gathering to talk about > > where DNSSEC is (now that we see implementations of the DS record) > > and is going. > > by the way, i know this will come as a surprise, but there will also > be an actual wg meeting of dnsext, where this subject will be covered. > :-) To stimulate (or cool down?) the discussion, here is a theory on why DNSSEC (or public key cryptography as a whole) is unimportant. Basically, public key cryptography is unimportant because the trusted third party (CA) is an intelligent intermediate entity. That is, CA, the trusted third party, do not have much information on the first and second parties. Nor can it firmly control transactions. With public key cryptography, in its simplest form, communication with CA is not necessary for every transaction. But it is so, only because the trusted third party knows or controls nothing about the transaction. However, for real security, it is essential that there must be compensation for a failed transaction by a party responsible for the failure. Knowing nothing about the contents of transactions, CAs can not be responsible. In the real world, secure transaction consists of a chain of credentials between the trusted first and second parties, in which case, it is possible to identify on which part of the chain a transaction failes. If A send B some amount of money using banks C and D, there is a chain of three credentials between A and C, between C and D and between B and D. If A buy something from B using credit card companies C and D, there is a chain of three credentials between A and C, between C and D and between B and D. To complete a transaction, there must be a communication between all the pairs of the trusted first and second parties. Considering that we have the Internet, which connects all the related first and second parties mostly in real time, it is not a problem. And, when there is a credential between the first and second parties, they can share a secret information (password, PIN etc.) to secure transaction, which is why public key is not necessary. As usual with protocols violating the end to end principle, there is a lot of attempot to make the protocol complex to let CA, the intelligent intermediate entity, partially control the transaction. But, as we know, such attempts are assurred to be incomplete and unusable. For example, it is possible to set a upper limit on the amount of money carried by a transaction. But, it is not effective against repeated transactions. This is why, with transactions using credit card in the real world, authorizations are required on all the transactions (except for buying, say, fresh food, too much repetition of which will harm the attacker by increasing his weight) even if there is a upper limit on each transaction. Another interesting obserbasion is CRL. There is no expiration period universally applicable to all the types of transactions, CA may set a duration to expire a certificate and, in addition, may issue CRL to invalidate it quicker, which is an incomplete attempt of control. It is interesting that, with CRL, the trusted third party must be contacted quite frequently. Finally, there is a very convincing reasoning against PKI. That is, "it's OSI". Masataka Ohta PS As public key cryptography is unimportant, CAs with web browsers are already overkill and we don't need DNSSEC. We can live with the weak security, security level of which is, with proper 3 way handshaking with cookies, equivalent to that of the telephone network. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 22:31:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25401 for ; Mon, 15 Jul 2002 22:31:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UHyL-000A70-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 19:21:53 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17UHyC-000A6h-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 19:21:44 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6FMKT23046661; Mon, 15 Jul 2002 22:20:29 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA14417; Mon, 15 Jul 2002 22:21:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200207160149.KAA02116@necom830.hpcl.titech.ac.jp> References: <200207160149.KAA02116@necom830.hpcl.titech.ac.jp> Date: Mon, 15 Jul 2002 22:21:33 -0400 To: Masataka Ohta From: Edward Lewis Subject: Re: dnssec discussion today at noon Cc: edlewis@arin.net, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Just to clarify what the meetings are for - The noon DNSSEC meeting is to discuss plans for going forward on DS - who's planning what, workshops upcoming, places where tutorials might be given, etc. The meeting assumes that the attendees are pushing DNSSEC forward. Also, there's no plan to discuss any issue with the implementation/design of the protocol/specification. The WG meetings are there to discuss the protocol itself, as per the agendas distributed. The DNSSEC meeting isn't intended to conflict with the WG discussions. If you want to argue whether DNSSEC is a good thing or not, I'm not sure what is the best venue... PS - Sorry to cross-post but time until the meetings is growing short. At 10:48 AM +0900 7/16/02, Masataka Ohta wrote: >> > There will be a hastily-organized, informal gathering to talk about >> > where DNSSEC is (now that we see implementations of the DS record) >> > and is going. >> >> by the way, i know this will come as a surprise, but there will also >> be an actual wg meeting of dnsext, where this subject will be covered. >> :-) > >To stimulate (or cool down?) the discussion, here is a theory on >why DNSSEC (or public key cryptography as a whole) is unimportant. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 22:48:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26416 for ; Mon, 15 Jul 2002 22:48:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UIGV-000AuT-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 19:40:39 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17UIGR-000AuH-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 19:40:35 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17UIGO-0004of-00; Tue, 16 Jul 2002 11:40:32 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Conrad Cc: Sam Weiler , DNS Operations , dnssec , , namedroppers Subject: Re: [vet-DS]DS mini-workshop results References: Message-Id: Date: Tue, 16 Jul 2002 11:40:32 +0900 X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit the ietf, itself, does not do interop testing. we do solicit and file interop testing reports. we ask that those reports anonymize the implementations. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 15 23:41:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27502 for ; Mon, 15 Jul 2002 23:41:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UJ3h-000Cyj-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 20:31:29 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17UJ3V-000CqP-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 20:31:17 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g6G3TcJe072732; Tue, 16 Jul 2002 13:29:38 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200207160329.g6G3TcJe072732@drugs.dv.isc.org> To: namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se From: Mark.Andrews@isc.org Subject: Re: dnssec discussion today at noon In-reply-to: Your message of "Tue, 16 Jul 2 10:48:45 JST ." <200207160149.KAA02116@necom830.hpcl.titech.ac.jp> Date: Tue, 16 Jul 2002 13:29:38 +1000 X-Spam-Status: No, hits=-6.4 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > There will be a hastily-organized, informal gathering to talk about > > > where DNSSEC is (now that we see implementations of the DS record) > > > and is going. > > > > by the way, i know this will come as a surprise, but there will also > > be an actual wg meeting of dnsext, where this subject will be covered. > > :-) > > To stimulate (or cool down?) the discussion, here is a theory on > why DNSSEC (or public key cryptography as a whole) is unimportant. > > Basically, public key cryptography is unimportant because the trusted > third party (CA) is an intelligent intermediate entity. > > That is, CA, the trusted third party, do not have much information on > the first and second parties. Nor can it firmly control transactions. > > With public key cryptography, in its simplest form, communication > with CA is not necessary for every transaction. But it is so, only > because the trusted third party knows or controls nothing about the > transaction. > > However, for real security, it is essential that there must be > compensation for a failed transaction by a party responsible for > the failure. > > Knowing nothing about the contents of transactions, CAs can not > be responsible. > > In the real world, secure transaction consists of a chain of > credentials between the trusted first and second parties, > in which case, it is possible to identify on which part of > the chain a transaction failes. > > If A send B some amount of money using banks C and D, there > is a chain of three credentials between A and C, between C > and D and between B and D. > > If A buy something from B using credit card companies C and D, > there is a chain of three credentials between A and C, between > C and D and between B and D. > > To complete a transaction, there must be a communication between > all the pairs of the trusted first and second parties. > > Considering that we have the Internet, which connects all the > related first and second parties mostly in real time, it is > not a problem. > > And, when there is a credential between the first and second parties, > they can share a secret information (password, PIN etc.) to secure > transaction, which is why public key is not necessary. > > As usual with protocols violating the end to end principle, > there is a lot of attempot to make the protocol complex to > let CA, the intelligent intermediate entity, partially control > the transaction. > > But, as we know, such attempts are assurred to be incomplete > and unusable. > > For example, it is possible to set a upper limit on the amount > of money carried by a transaction. But, it is not effective > against repeated transactions. > > This is why, with transactions using credit card in the real > world, authorizations are required on all the transactions > (except for buying, say, fresh food, too much repetition of > which will harm the attacker by increasing his weight) even > if there is a upper limit on each transaction. > > Another interesting obserbasion is CRL. There is no expiration > period universally applicable to all the types of transactions, > CA may set a duration to expire a certificate and, in addition, > may issue CRL to invalidate it quicker, which is an incomplete > attempt of control. It is interesting that, with CRL, the trusted > third party must be contacted quite frequently. > > Finally, there is a very convincing reasoning against PKI. That > is, "it's OSI". > > Masataka Ohta > > PS > > As public key cryptography is unimportant, CAs with web browsers > are already overkill and we don't need DNSSEC. > > We can live with the weak security, security level of which is, > with proper 3 way handshaking with cookies, equivalent to that > of the telephone network. And what does this have to do with DNSSEC? DNSSEC is designed to allow you to verify that the data you receive from the DNS is that which was entered. That your transactions havn't been spoofed. What you do with that data is outside the scope of DNSSEC as is should a particular entity have been delegated a particular name. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 01:26:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29806 for ; Tue, 16 Jul 2002 01:26:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UKhw-000Gkm-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 22:17:08 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17UKhl-000Gk2-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 22:16:57 -0700 From: Masataka Ohta Message-Id: <200207160504.OAA02957@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA02957; Tue, 16 Jul 2002 14:04:33 +0900 Subject: Re: dnssec discussion today at noon In-Reply-To: <200207160329.g6G3TcJe072732@drugs.dv.isc.org> from "Mark.Andrews@isc.org" at "Jul 16, 2002 01:29:38 pm" To: Mark.Andrews@isc.org Date: Tue, 16 Jul 2002 14:04:32 +0859 () CC: namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark; > And what does this have to do with DNSSEC? The theory explains the reality that public key cryptography (including DNSSEC) is not used for serious purposes. The theory can be used to explain some (or most or all) of operational difficulty of DNSSEC deployment. > DNSSEC is designed to allow you to verify that the data you > receive from the DNS is that which was entered. That your > transactions havn't been spoofed. Such security is not useful for serious purposes, when no one is really responsible if your transactions are spoofed. So, > > We can live with the weak security, security level of which is, > > with proper 3 way handshaking with cookies, equivalent to that > > of the telephone network. Just as you can rely on people operating name servers, you can rely on people operating routers. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 01:55:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00770 for ; Tue, 16 Jul 2002 01:55:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ULEf-000Htl-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 22:50:57 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17ULEU-000HsZ-00 for namedroppers@ops.ietf.org; Mon, 15 Jul 2002 22:50:46 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g6G5o8Je073774; Tue, 16 Jul 2002 15:50:28 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200207160550.g6G5o8Je073774@drugs.dv.isc.org> to: namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se From: Mark.Andrews@isc.org Subject: Re: dnssec discussion today at noon In-reply-to: Your message of "Tue, 16 Jul 2002 14:04:32 +0859." <200207160504.OAA02957@necom830.hpcl.titech.ac.jp> Date: Tue, 16 Jul 2002 15:50:08 +1000 X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark; > > > And what does this have to do with DNSSEC? > > The theory explains the reality that public key cryptography > (including DNSSEC) is not used for serious purposes. No. It explains why it may not be useful for some purposes. In no way does it demostrate that it not useful for DNSSEC. > The theory can be used to explain some (or most or all) of > operational difficulty of DNSSEC deployment. > > > DNSSEC is designed to allow you to verify that the data you > > receive from the DNS is that which was entered. That your > > transactions havn't been spoofed. > > Such security is not useful for serious purposes, when no one is > really responsible if your transactions are spoofed. Actually once DNSSEC is available there is a person responible if the data spoofed. The person that entered the data in such away that it could be spoofed. > So, > > > > We can live with the weak security, security level of which is, > > > with proper 3 way handshaking with cookies, equivalent to that > > > of the telephone network. > > Just as you can rely on people operating name servers, you > can rely on people operating routers. Getting routers fixed to block spoofed traffic relies on *everyone* doing the right thing. Getting DNSSEC working only requires that the operators of the root servers, down to the zone servers do the right thing. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 01:55:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00792 for ; Tue, 16 Jul 2002 01:55:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ULCo-000HpW-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 22:49:02 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17ULCi-000Hos-00; Mon, 15 Jul 2002 22:48:57 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA07488; Tue, 16 Jul 2002 01:48:55 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA19342; Tue, 16 Jul 2002 01:43:47 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id BAA08350; Tue, 16 Jul 2002 01:43:46 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id BAA07160; Tue, 16 Jul 2002 01:43:47 -0400 (EDT) To: Masataka Ohta Cc: randy@psg.com (Randy Bush), edlewis@arin.net, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se Subject: Re: dnssec discussion today at noon References: <200207160149.KAA02116@necom830.hpcl.titech.ac.jp> From: Derek Atkins Date: 16 Jul 2002 01:43:47 -0400 In-Reply-To: <200207160149.KAA02116@necom830.hpcl.titech.ac.jp> Message-ID: Lines: 139 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Unfortunately you are incorrect. Public Key Cryptography is absolutely necessary for any store-and-forward protocol. Note that I said PKC, not PKI. The _I_ part (infrastructure) is not necessary in many cases, but the technology of public key most certainly is. The problem is that the alternative, secret-key cryptography, requires each pair of communicating parties to share a key, resulting in N-squared keys in the system. OTOH, with public keys you only need N key-pairs in the system (each entity has only one key-pair). Note that the use of public-key cryptography is completely orthogonal to the issue of transactions or money transfer that you seem to be bringing into the picture. I would purport that without public key cryptography you could have ZERO financial transactions on the Internet exactly because you could not secure them. As an example, look at HTTPS (SSL/TLS) -- without Public Key, SSL would not work. So, where does DNS and DNSSec fit into this? First, there is a strong goal to protect the DNS infrastructure. I wont go into the numerous types of attacks possible against DNS (feel free to contact me personally if you really want to go down that rathole). Suffice it to say that various cache poisoning and spoofing attacks can lead users and applications to contact the wrong server site. Second, some people believe that, once you have a secured DNS, you could use it to deliver Public Keys. You may not believe in Public Key, but this is not the forum to debate that issue. Thanks, -derek Masataka Ohta writes: > > > There will be a hastily-organized, informal gathering to talk about > > > where DNSSEC is (now that we see implementations of the DS record) > > > and is going. > > > > by the way, i know this will come as a surprise, but there will also > > be an actual wg meeting of dnsext, where this subject will be covered. > > :-) > > To stimulate (or cool down?) the discussion, here is a theory on > why DNSSEC (or public key cryptography as a whole) is unimportant. > > Basically, public key cryptography is unimportant because the trusted > third party (CA) is an intelligent intermediate entity. > > That is, CA, the trusted third party, do not have much information on > the first and second parties. Nor can it firmly control transactions. > > With public key cryptography, in its simplest form, communication > with CA is not necessary for every transaction. But it is so, only > because the trusted third party knows or controls nothing about the > transaction. > > However, for real security, it is essential that there must be > compensation for a failed transaction by a party responsible for > the failure. > > Knowing nothing about the contents of transactions, CAs can not > be responsible. > > In the real world, secure transaction consists of a chain of > credentials between the trusted first and second parties, > in which case, it is possible to identify on which part of > the chain a transaction failes. > > If A send B some amount of money using banks C and D, there > is a chain of three credentials between A and C, between C > and D and between B and D. > > If A buy something from B using credit card companies C and D, > there is a chain of three credentials between A and C, between > C and D and between B and D. > > To complete a transaction, there must be a communication between > all the pairs of the trusted first and second parties. > > Considering that we have the Internet, which connects all the > related first and second parties mostly in real time, it is > not a problem. > > And, when there is a credential between the first and second parties, > they can share a secret information (password, PIN etc.) to secure > transaction, which is why public key is not necessary. > > As usual with protocols violating the end to end principle, > there is a lot of attempot to make the protocol complex to > let CA, the intelligent intermediate entity, partially control > the transaction. > > But, as we know, such attempts are assurred to be incomplete > and unusable. > > For example, it is possible to set a upper limit on the amount > of money carried by a transaction. But, it is not effective > against repeated transactions. > > This is why, with transactions using credit card in the real > world, authorizations are required on all the transactions > (except for buying, say, fresh food, too much repetition of > which will harm the attacker by increasing his weight) even > if there is a upper limit on each transaction. > > Another interesting obserbasion is CRL. There is no expiration > period universally applicable to all the types of transactions, > CA may set a duration to expire a certificate and, in addition, > may issue CRL to invalidate it quicker, which is an incomplete > attempt of control. It is interesting that, with CRL, the trusted > third party must be contacted quite frequently. > > Finally, there is a very convincing reasoning against PKI. That > is, "it's OSI". > > Masataka Ohta > > PS > > As public key cryptography is unimportant, CAs with web browsers > are already overkill and we don't need DNSSEC. > > We can live with the weak security, security level of which is, > with proper 3 way handshaking with cookies, equivalent to that > of the telephone network. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 02:32:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11150 for ; Tue, 16 Jul 2002 02:32:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ULjF-000J5D-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 23:22:33 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17ULii-000J3Q-00; Mon, 15 Jul 2002 23:22:00 -0700 From: Masataka Ohta Message-Id: <200207160611.PAA03321@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA03321; Tue, 16 Jul 2002 15:10:51 +0859 Subject: Re: dnssec discussion today at noon In-Reply-To: from Derek Atkins at "Jul 16, 2002 01:43:47 am" To: Derek Atkins Date: Tue, 16 Jul 2002 15:10:50 +0859 () CC: Randy Bush , edlewis@arin.net, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Derek; > Public Key Cryptography is absolutely necessary for any > store-and-forward protocol. Note that I said PKC, not PKI. The _I_ > part (infrastructure) is not necessary in many cases, but the > technology of public key most certainly is. The problem is that the > alternative, secret-key cryptography, requires each pair of > communicating parties to share a key, resulting in N-squared keys in > the system. OTOH, with public keys you only need N key-pairs in the > system (each entity has only one key-pair). That is a wrong counting. First, the number of dynamically generated shared key is same, regardless of whether you use public or shared key cryptography. If N party directly interact with all the other N-1 parties, you need N-squared keys regardless of whether you use public or shared key cryptography. Preconfigured secret-key, on the other hand, is necessary, only when there is preconfigured credential. By having KDC, we need as much secret key as necessary for PKI with CAs, though KDC as the trusted third party is as bogus as CAs. However, it is fine to have KDC as the trusted first or second party. To send money from A to B through banks of C and D, secret keys are necessary between A and C, C and D, D and B, but not A and D. It is also pobbible to let banks act as KDCs. > Note that the use of public-key cryptography is completely orthogonal > to the issue of transactions or money transfer that you seem to be > bringing into the picture. I would purport that without public key > cryptography you could have ZERO financial transactions on the > Internet exactly because you could not secure them. As an example, > look at HTTPS (SSL/TLS) -- without Public Key, SSL would not work. Huh? What is necessary for the financial transactions is credential between credit card owners and credit card companies. Weak protection by HTTPS does not essentially add anything. > First, there is a strong goal to protect the DNS infrastructure. I > wont go into the numerous types of attacks possible against DNS (feel > free to contact me personally if you really want to go down that > rathole). Suffice it to say that various cache poisoning and spoofing > attacks can lead users and applications to contact the wrong server > site. That's why it is stupid to make DNS even more complex. Feel free to contact me personally, if you really want to know the rathole, for example, on how easily cache poisoning can be prevented and how wrongly various implementations tried to prevent it. > Second, some people believe that, once you have a secured DNS, you > could use it to deliver Public Keys. You may not believe in Public > Key, but this is not the forum to debate that issue. That is an uninteresting topic. Let's skip it. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 02:50:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11591 for ; Tue, 16 Jul 2002 02:50:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UM2y-000Jl2-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 23:42:56 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17UM2T-000Jk7-00; Mon, 15 Jul 2002 23:42:25 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id CAA04559; Tue, 16 Jul 2002 02:42:24 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA20270; Tue, 16 Jul 2002 02:42:23 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id CAA20970; Tue, 16 Jul 2002 02:42:19 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id CAA07281; Tue, 16 Jul 2002 02:42:20 -0400 (EDT) To: Masataka Ohta Cc: Randy Bush , edlewis@arin.net, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se Subject: Re: dnssec discussion today at noon References: <200207160611.PAA03321@necom830.hpcl.titech.ac.jp> From: Derek Atkins Date: 16 Jul 2002 02:42:20 -0400 In-Reply-To: <200207160611.PAA03321@necom830.hpcl.titech.ac.jp> Message-ID: Lines: 113 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Masataka Ohta writes: > First, the number of dynamically generated shared key is same, > regardless of whether you use public or shared key cryptography. I admit that I did not count ephemeral keys in the count, but that's because they ARE ephemeral. There is no _storage_ of those keys in the system. They are created (and destroyed) in near-real-time. My key-count is for long-term key storage, in which case my numbers are accurate. > If N party directly interact with all the other N-1 parties, you need > N-squared keys regardless of whether you use public or shared key > cryptography. You do not need to _store_ N-squared keys, you only need to store N keys (one key per entity. Yes, you need to store state during the transaction processing (which may include an ephemeral session key) but then you throw that key away when the transaction is complete. > By having KDC, we need as much secret key as necessary for PKI with CAs, > though KDC as the trusted third party is as bogus as CAs. > > However, it is fine to have KDC as the trusted first or second party. No, it is not sufficient. The problem is that you cannot have a long-term store-and-forward mechanism with secret-key technology. If Alice wants to send a secure message to Bob using secret-key encryption there is no way that Bob can prove to Charlie that Alice sent the message without revealing their own secret key. In other words, you cannot have non-repudiation with secret-key protocols, but this feature is ABSOLUTELY necessary for financial transactions. If Alice can repudiate their message to Bob, then how is Bob supposed to collect his money? > To send money from A to B through banks of C and D, secret keys are > necessary between A and C, C and D, D and B, but not A and D. Negative. You want a key between A and D in order to maintain confidentiality of the transaction. Moreover, you may need to tie the transaction to some other data (for example, I want to buy a widget for this e-money), which implies you need a secure channel to bind the widget to the payment. Again, you need a key shared between A and D. > It is also pobbible to let banks act as KDCs. This does not work, as I previously stated. The way the transaction works is that A sends a token to B; B presents the token to D; D presents the token back to C. You cannot do that with secret-key tokens. If A, B, C, and D are all online together, there are alternate protocols you can use, but it violates this particular transaction model (which is how the current banking system is implemented). > Huh? What is necessary for the financial transactions is credential > between credit card owners and credit card companies. You seem to be under the mistaken impression that credit cards are the only financial model in use. They are not. Cash uses a very different "protocol", some of which may be pseudo-offline. Moreover, in electronic transactions the customer may want to have a GOOD IDEA that they are talking to the "right" merchant (or at least the _same_ merchant that they were talking to yesterday). The only way to do this in a scalable way is Certificates. As much as I would love to seee Kerberos take over the world, it is not going to do so. Moreover, with data like DNS, you cannot use Kerberos because of the caching problem (see my previous statement about store-and-forward data not working with secret key). > Weak protection by HTTPS does not essentially add anything. It adds confidentiality of your payment token, and it provides a binding between the payment token and the paid-for object. > > First, there is a strong goal to protect the DNS infrastructure. I > > wont go into the numerous types of attacks possible against DNS (feel > > free to contact me personally if you really want to go down that > > rathole). Suffice it to say that various cache poisoning and spoofing > > attacks can lead users and applications to contact the wrong server > > site. > > That's why it is stupid to make DNS even more complex. > > Feel free to contact me personally, if you really want to know the > rathole, for example, on how easily cache poisoning can be prevented > and how wrongly various implementations tried to prevent it. Sure. Find me after DNSEXT. I can show you that no matter what you do, without cryptographic protection there is nothing you can do to prevent me from poisioning your cache if I can get between you and the DNS server you are querying. > > Second, some people believe that, once you have a secured DNS, you > > could use it to deliver Public Keys. You may not believe in Public > > Key, but this is not the forum to debate that issue. > > That is an uninteresting topic. Let's skip it. It may be uninteresting to you, but not to many people sitting in this room. Skipping a topic just because you find it uninteresting is the wrong answer. Feel free to leave the room if you are bored. Being here _is_ optional. > Masataka Ohta -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 03:02:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11968 for ; Tue, 16 Jul 2002 03:02:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UMGO-000KGz-00 for namedroppers-data@psg.com; Mon, 15 Jul 2002 23:56:48 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17UMGJ-000KGl-00; Mon, 15 Jul 2002 23:56:43 -0700 From: Masataka Ohta Message-Id: <200207160645.PAA03465@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA03465; Tue, 16 Jul 2002 15:45:41 +0900 Subject: Re: dnssec discussion today at noon In-Reply-To: from Derek Atkins at "Jul 16, 2002 02:42:20 am" To: Derek Atkins Date: Tue, 16 Jul 2002 15:45:40 +0859 () CC: Randy Bush , edlewis@arin.net, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Derek; > > By having KDC, we need as much secret key as necessary for PKI with CAs, > > though KDC as the trusted third party is as bogus as CAs. > > > > However, it is fine to have KDC as the trusted first or second party. > > No, it is not sufficient. The problem is that you cannot have a > long-term store-and-forward mechanism with secret-key technology. If > Alice wants to send a secure message to Bob using secret-key > encryption there is no way that Bob can prove to Charlie that Alice > sent the message without revealing their own secret key. I do assume all the related parties are online. > Negative. You want a key between A and D in order to maintain > confidentiality of the transaction. As you said; > I admit that I did not count ephemeral keys in the count, it's OK to have dynamically generated keys between A and D. > > By having KDC, we need as much secret key as necessary for PKI with CAs, > > though KDC as the trusted third party is as bogus as CAs. > > > > However, it is fine to have KDC as the trusted first or second party. > > No, it is not sufficient. The problem is that you cannot have a > long-term store-and-forward mechanism with secret-key technology. I'm saying we shouldn't use long-term store-and-forward mechanism, because it is not really secure. > Moreover, > in electronic transactions the customer may want to have a GOOD IDEA > that they are talking to the "right" merchant (or at least the _same_ > merchant that they were talking to yesterday). The only way to do > this in a scalable way is Certificates. That is a delusion. > As much as I would love to seee Kerberos take over the world, it is > not going to do so. Moreover, with data like DNS, you cannot use > Kerberos because of the caching problem (see my previous statement > about store-and-forward data not working with secret key). Kerberos with KDCs as the trusted third parties is as bad as PKI. > > Weak protection by HTTPS does not essentially add anything. > > It adds confidentiality of your payment token, and it provides > a binding between the payment token and the paid-for object. If you make a transaction confidential to the banks, banks can not assist you to make it secure. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 06:30:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16309 for ; Tue, 16 Jul 2002 06:30:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UPI6-0000eE-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 03:10:46 -0700 Received: from hamburg.dyn.ietf54.wide.ad.jp ([133.93.18.175] helo=HAMBURG) by psg.com with esmtp (Exim 3.36 #1) id 17UPHw-0000dq-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 03:10:36 -0700 Received: from localhost ([127.0.0.1]) by HAMBURG with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Jul 2002 19:10:40 +0900 To: namedroppers@ops.ietf.org From: kitamura@da.jp.nec.com Subject: Domain Name Auto-Registration for Plugged-in IPv6 Nodes X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020716191040Z.kitamura@netlab.nec.co.jp> Date: Tue, 16 Jul 2002 19:10:40 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 15 X-OriginalArrivalTime: 16 Jul 2002 10:10:40.0443 (UTC) FILETIME=[09C368B0:01C22CB1] X-Spam-Status: No, hits=-0.3 required=5.0 tests=NO_REAL_NAME,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I've presented "Domain Name Auto-Registration for Plugged-in IPv6 Nodes" at today's session. Chairs asked me to send e-mail to the mailing-list to confirm that this item moves to WG item. So, if there are any objections, please let us know. Thank you. Hiroshi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 07:28:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17550 for ; Tue, 16 Jul 2002 07:28:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UQKJ-0002j3-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 04:17:07 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17UQJg-0002h6-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 04:16:28 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17UQJe-0005VO-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 20:16:26 +0900 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020716193031C.kitamura@netlab.nec.co.jp> Subject: Domain Name Auto-Registration for Plugged-in IPv6 Nodes To: namedroppers@ops.ietf.org Date: Tue, 16 Jul 2002 19:30:31 +0900 (JST) From: Hiroshi KITAMURA X-Spam-Status: No, hits=-1.1 required=5.0 tests=X_NOT_PRESENT,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi All, I've presented "Domain Name Auto-Registration for Plugged-in IPv6 Nodes" at today's session. Chairs asked me to send e-mail to the mailing-list to confirm that this item moves to WG item. So, if there are any objections, please let us know. Thank you. Hiroshi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 09:20:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19154 for ; Tue, 16 Jul 2002 09:20:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17US6L-0006Xb-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 06:10:49 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17US5M-0006Up-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 06:09:48 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6G98V23050092; Tue, 16 Jul 2002 09:08:31 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA18181; Tue, 16 Jul 2002 09:09:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20020716191040Z.kitamura@netlab.nec.co.jp> References: <20020716191040Z.kitamura@netlab.nec.co.jp> Date: Tue, 16 Jul 2002 09:08:44 -0400 To: kitamura@da.jp.nec.com, namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:10 PM +0900 7/16/02, kitamura@da.jp.nec.com wrote: >Chairs asked me to send e-mail to the mailing-list to confirm >that this item moves to WG item. > >So, if there are any objections, please let us know. Although I like the idea (at least superficially), I don't know why this would be a WG item for a DNS working group. The plusses of this approach is that it provides a modular solution to registering IPv6 addresses in DNS. The modules are designed with the expertise to do the job, leaving DNS to keep to the task of just serving data as it does now. The minuses is that any state being held in a detector and registrar must be maintained across device failures. (Such a short analysis is bound to have holes.) But as far as whether this is a DNS document, I'm not sure. The process uses existing DNS features (secured dynamic update) and specifies default names that are meaningful to the application at hand. The draft does not introduce any modification to the way in which the DNS protocol operates. It seems that this would fit into an IPv6 work group (where the expertise to handle the IPv6 issues lay). When I originally read this, I assume the ipv6 in the draft name meant it was destined for draft-ietf-ipv6... eventually. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 10:15:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20107 for ; Tue, 16 Jul 2002 10:15:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17USz5-0008ZH-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 07:07:23 -0700 Received: from [133.93.71.210] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.36 #1) id 17USxX-0008VE-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 07:05:47 -0700 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6GE4uO23037; Tue, 16 Jul 2002 23:04:57 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: kitamura@da.jp.nec.com cc: namedroppers@ops.ietf.org Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes In-Reply-To: References: <20020716191040Z.kitamura@netlab.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Jul 2002 23:04:56 +0900 Message-ID: <23035.1026828296@munnari.OZ.AU> X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 16 Jul 2002 09:08:44 -0400 From: Edward Lewis Message-ID: | I don't know why this would be a WG item for a DNS working group. I agree with that. This looks more like a description of an interesting technique which can might make life easier for many sites if made available - but that's just software. There's no particular reason any two sites should adopt the same approach (nor why they shouldn't). If this was to be a recommended method, I'd be concerned about some of the assumptions (like expecting a manually configured address to necessarily have an entry in the DNS, or that a manually configured address wouldn't look identical to an EUI-64 auto-configured one - in fact I have both of those). But, as a "here is what we do that works for us" doc, it looks fine. No need for any work to be done on it (in dnsext or ipv6), just request that it get published as informational (which is what was suggested in the meeting). I doubt there will be any problem, provided that it is clear that documenting a useful technique that can be used is all that it is claiming to do. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 18:38:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01654 for ; Tue, 16 Jul 2002 18:38:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Uanr-0002Uh-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 15:28:19 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17UalQ-0002Kp-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 15:25:48 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17UalQ-0005uv-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 07:25:48 +0900 Mime-Version: 1.0 Message-Id: In-Reply-To: <200207160504.OAA02957@necom830.hpcl.titech.ac.jp> References: <200207160504.OAA02957@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Date: Tue, 16 Jul 2002 17:07:47 +0200 To: Masataka Ohta , Mark.Andrews@isc.org From: Brad Knowles Subject: Re: dnssec discussion today at noon Cc: namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se X-Spam-Status: No, hits=-7.5 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At 2:04 PM +0859 2002/07/16, Masataka Ohta wrote: >> And what does this have to do with DNSSEC? > > The theory explains the reality that public key cryptography > (including DNSSEC) is not used for serious purposes. Not used for serious purposes?!? Okay, let's have you run a B2B website where billions of dollars can be moved with the click of a single mouse button. Now, we have to ensure that you really are interacting with the real B2B website and not some clever fake, or worse, some site that performs a man-in-the-middle attack on you while you are conducting a real transaction, so that they can later go in and conduct multiple fake transactions. How about home banking? Sure, hundreds, thousands, tens of thousands, etc... of dollars may not be a whole lot of money to you, but they may be the entire life savings of a family. Multiply that by 250 million people in the US alone, and you're talking about some real money. I'm sorry. I don't buy your argument at all. Not in the least. I'm not saying that DNSSEC is necessarily the only solution to the problem, or even the best solution to the problem, or necessarily even one solution to the problem, but it is at least a step closer to one solution to the problem, and by working with DNSSEC and seeing where it works and where it fails, we can get closer to a real solution. > Such security is not useful for serious purposes, when no one is > really responsible if your transactions are spoofed. Okay, so we can all sue you for billions and trillions of dollars worth of damages when someone spoofs a DNS response packet which then leads us to be vulnerable to man-in-the-middle attacks. > Just as you can rely on people operating name servers, you > can rely on people operating routers. No, in both cases. There are a multitude of heinously screwed up servers in this world, and a multitude of heinously screwed up routers, too. If you don't believe me, then believe KC Claffy from CAIDA (see ). -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 18:39:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01668 for ; Tue, 16 Jul 2002 18:39:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ualy-0002OQ-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 15:26:22 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17Uakz-0002KJ-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 15:25:21 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17Uaky-0005up-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 07:25:20 +0900 Mime-Version: 1.0 Message-Id: In-Reply-To: <200207160550.g6G5o8Je073774@drugs.dv.isc.org> References: <200207160550.g6G5o8Je073774@drugs.dv.isc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Date: Tue, 16 Jul 2002 17:10:56 +0200 To: Mark.Andrews@isc.org, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se From: Brad Knowles Subject: Re: dnssec discussion today at noon X-Spam-Status: No, hits=-7.5 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At 3:50 PM +1000 2002/07/16, Mark.Andrews@isc.org wrote: > Getting DNSSEC working > only requires that the operators of the root servers, down > to the zone servers do the right thing. Which is hard enough. Witness all the incredibly screwed up TLD servers. Witness the differences in the modes of operations of the root nameservers themselves -- do you block all zone transfers or not? If we want DNSSEC to be taken seriously, then we have to work to get all the root & TLD servers fixed and operating properly, and have proper punitive measures that we can take if they aren't. Otherwise, we don't have a snowball's chance. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 20:03:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03692 for ; Tue, 16 Jul 2002 20:03:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UcAG-0006TB-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 16:55:32 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17UcA6-0006Sy-00; Tue, 16 Jul 2002 16:55:22 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g6GNtHS03489; Tue, 16 Jul 2002 16:55:17 -0700 (PDT) From: Bill Manning Message-Id: <200207162355.g6GNtHS03489@boreas.isi.edu> Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results In-Reply-To: from Brad Knowles at "Jul 16, 2 11:17:57 pm" To: brad.knowles@skynet.be (Brad Knowles) Date: Tue, 16 Jul 2002 16:55:16 -0700 (PDT) Cc: ed@alcpress.com, randy@psg.com, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % Moreover, if you are someone looking to actually use products % such as the ones under test, it would be a benefit to know which % products worked and which ones didn't, or which ones had what % problems in what environments, so that you would have a better idea % as to what products might be suitable for use in your own environment. % % % IMO, tests like this without full disclosure are meaningless. % % -- % Brad Knowles, % Brad, at this point most of this work is still shaking out specification ambiguities. It is useful to know which developers are involved with debugging the spec but details on the specific code/thinking that will be revised may not be that useful. When products are available -and- the spec is firm, then having interop results, OF THE PRODUCTS, makes sense. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 20:12:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04243 for ; Tue, 16 Jul 2002 20:12:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UcJU-0006wu-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 17:05:04 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17UcIu-0006w0-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 17:04:28 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6GK3K23059120; Tue, 16 Jul 2002 20:03:20 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA18028; Tue, 16 Jul 2002 20:04:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> <1026847384.23224.49.camel@red> Date: Tue, 16 Jul 2002 20:04:11 -0400 To: Brad Knowles , Ed Sawicki , Randy Bush From: Edward Lewis Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:17 PM +0200 7/16/02, Brad Knowles wrote: > IMO, tests like this without full disclosure are meaningless. Meaningless to whom? 1) For the specification process, it is not important who is able to produce compliant and interoperable implementations but that it is possible. This is a necessary - but not sufficient - part of the process. 2) For the implementors, getting clarification that leads to more implementations is good for all - choice spurs competition spurs growth of a market (at least in the development phase, before mergers and acquisitions kick in). 3) For buyers, yes, anonymized results are not beneficial. But then the IETF is not about being a venue for selling (a la Interop, trade magazines, consumer shows) but a venue for collaboration. (I.e., this audience is beyond the scope of the IETF's services.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 20:20:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04486 for ; Tue, 16 Jul 2002 20:20:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UcT5-0007Sc-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 17:14:59 -0700 Received: from [133.93.71.210] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.36 #1) id 17UcSY-0007S0-00; Tue, 16 Jul 2002 17:14:26 -0700 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6H0DTO01245; Wed, 17 Jul 2002 09:13:32 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Brad Knowles cc: Ed Sawicki , Randy Bush , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> <1026847384.23224.49.camel@red> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Jul 2002 09:13:29 +0900 Message-ID: <1243.1026864809@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 16 Jul 2002 23:17:57 +0200 From: Brad Knowles Message-ID: | At 12:23 PM -0700 2002/07/16, Ed Sawicki wrote: | | > Yes, but isn't there value in knowing who the implementors are so Sometimes a list of who participated is published, without identifying which implementation belongs to which implementor. | Moreover, if you are someone looking to actually use products | such as the ones under test, This is not the purpose of the tests - that's a worthy purpose, but it isn't the IETF's role. What is being tested, as Randy Bush keeps on saying, by the IETF is the standard upon which the implementations are based. We want to know if the standard describes something that can be implemented in an interoperable way. When a failure occurs, then we need to know whether of not that is because of a faulty standard, or just an implementation bug ("the standard was clear, I just screwed up..."). Apart from that, whether bugs exist or not is irrelevant - and the tests are not designed to attempt to discover implementation bugs - so that bugs weren't found in some implementation or other doesn't mean that there weren't any. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 21:53:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07432 for ; Tue, 16 Jul 2002 21:53:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17UdrM-000BuH-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 18:44:08 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17UdrG-000BtB-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 18:44:02 -0700 From: Masataka Ohta Message-Id: <200207170131.KAA06741@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA06741; Wed, 17 Jul 2002 10:30:59 +0859 Subject: Re: dnssec discussion today at noon In-Reply-To: from Brad Knowles at "Jul 16, 2002 05:07:47 pm" To: Brad Knowles Date: Wed, 17 Jul 2002 10:30:58 +0859 () CC: Mark.Andrews@isc.org, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Brad; > >> And what does this have to do with DNSSEC? > > > > The theory explains the reality that public key cryptography > > (including DNSSEC) is not used for serious purposes. > > Not used for serious purposes?!? No, not at all. > Okay, let's have you run a B2B > website where billions of dollars can be moved with the click of a > single mouse button. Now, we have to ensure that you really are > interacting with the real B2B website and not some clever fake, or > worse, some site that performs a man-in-the-middle attack on you > while you are conducting a real transaction, so that they can later > go in and conduct multiple fake transactions. Are you saying that the B2B website gladly accept a billion dollar order from some unkown company just because a CA says the company's domain name is not faked? Purely techinically, if secret is shared between the website and the company, shared key cryptography protect you from a clever fake and a MITM attack. But, it is not enough credential to perform serious commercial transaction. The website should check credit status of its members. > How about home banking? Sure, hundreds, thousands, tens of > thousands, etc... of dollars may not be a whole lot of money to you, > but they may be the entire life savings of a family. Multiply that > by 250 million people in the US alone, and you're talking about some > real money. Protection for home banking is by shared secret. > > Such security is not useful for serious purposes, when no one is > > really responsible if your transactions are spoofed. > > Okay, so we can all sue you for billions and trillions of dollars > worth of damages when someone spoofs a DNS response packet which then > leads us to be vulnerable to man-in-the-middle attacks. Huh? You can't ask root server operators for compasation for billions and trillions of dollars worth of damages when someone spoofs a DNS response. Serious users protect them with shared secret. They don't blank-mindedly rely on CAs not really offerring any serious compasation. > No, in both cases. There are a multitude of heinously screwed up > servers in this world, and a multitude of heinously screwed up > routers, too. And, there will be multiple screwed up CAs. Or, are there already? So, have weakly secure Internet and DNS as a infrastructure and don't rely on intermediate entities of servers, routers or CAs. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 21:53:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07487 for ; Tue, 16 Jul 2002 21:53:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Udra-000Bw5-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 18:44:22 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17UdrI-000BtL-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 18:44:04 -0700 Received: from [133.93.76.134] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 578C8137F02; Tue, 16 Jul 2002 18:44:02 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 16 Jul 2002 18:44:02 -0700 Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results From: David Conrad To: Ed Sawicki , Randy Bush Cc: DNS Operations , namedroppers , , IPng Message-ID: In-Reply-To: <1026847384.23224.49.camel@red> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ed, On 7/16/02 12:23 PM, "Ed Sawicki" wrote: > Yes, but isn't there value in knowing who the implementors are so > we can gauge what skill levels are required to produce interoperable > implementations? How do you gauge skill level? How does an external body know how many resources were put onto the implementation of a new protocol? > Besides, what's the reason for the secrecy? Many reasons. For one, a company may not want to advertise the fact that they are working on a particular technology (for whatever reason). For another, people might not want an experiment to be associated with what they do for their products. I'm sure you can think of other reasons. > I, for one, get suspicious when information is deliberately > withheld. It tells me that there's something to hide. Well, yeah. > This may seem like a small thing but I think it sets a > dangerous precedent. The standards process should be completely > open. The standards _are_ open. The implementations of those standards don't have to be (and typically aren't). > If IETF working groups can't be completely open about > important standards activity, they should be dissolved and new > ones formed that have more respect for their public trust. Interesting view. Wrong, but interesting. Of course, interoperability testing isn't, strictly speaking, a function of the IETF working group (as Randy Bush has pointed out). The point of interoperability testing as it is relevant to the IETF is to insure the protocol specifications are actually implementable. From that perspective, it doesn't matter who does the implementation, rather that at least two different sets of people can actually do them. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 16 21:55:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07709 for ; Tue, 16 Jul 2002 21:55:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Udxx-000CHy-00 for namedroppers-data@psg.com; Tue, 16 Jul 2002 18:50:57 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17Udxr-000CHj-00 for namedroppers@ops.ietf.org; Tue, 16 Jul 2002 18:50:52 -0700 Received: from [133.93.76.134] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 35A01137F02; Tue, 16 Jul 2002 18:50:51 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 16 Jul 2002 18:50:51 -0700 Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results From: David Conrad To: Brad Knowles , Ed Sawicki , Randy Bush Cc: DNS Operations , namedroppers , , IPng Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brad, On 7/16/02 2:17 PM, "Brad Knowles" wrote: > Moreover, if you are someone looking to actually use products > such as the ones under test, Who says the things under test are products? The DS implementation Nominum did was done on a snapshot of the ISC BIND tree that has not yet been released, even in alpha. It shouldn't be too much of a surprise that that version of BINDv9 contains bugs. The implementation was done to prove that the DS spec was actually implementable and to provide input back to the standardization proceess to tighten up the ambiguous bits. > it would be a benefit to know which > products worked and which ones didn't, or which ones had what > problems in what environments, so that you would have a better idea > as to what products might be suitable for use in your own environment. When products are available, such testing would indeed be useful. Of course, this isn't particularly relevant to what the IETF is doing. > IMO, tests like this without full disclosure are meaningless. To be blunt, your opinion would be wrong. Of course, there is meaning -- just the fact that multiple implementations of a protocol exist is useful information (indeed, an IETF protocol cannot advance to full standard without this fact being true). Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 17 06:34:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11833 for ; Wed, 17 Jul 2002 06:34:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ultt-0008Dt-00 for namedroppers-data@psg.com; Wed, 17 Jul 2002 03:19:17 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17Ulto-0008DB-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 03:19:12 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17Ultn-0007mS-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 19:19:12 +0900 Message-Id: <20020717175701.37002889.bert@secret-wg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Wed, 17 Jul 2002 17:57:01 +0900 From: "Bert's Secretary" To: namedroppers@ops.ietf.org Subject: DNS directorate X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Photographic evidence of Bert being a member of the DNS directorate. See http://bert.secret-wg.org/Trips-en-zo/IETF54/index.html --Bert's Secretary -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 17 07:19:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12802 for ; Wed, 17 Jul 2002 07:19:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Umjk-000A4T-00 for namedroppers-data@psg.com; Wed, 17 Jul 2002 04:12:52 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17Umjg-000A4I-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 04:12:49 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17Umjf-0007pq-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 20:12:47 +0900 Message-Id: <5.1.0.14.0.20020717113429.0247ca40@mail.club-internet.fr> In-Reply-To: References: <1026847384.23224.49.camel@red> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-21037C77; boundary="=======1309516B=======" Date: Wed, 17 Jul 2002 11:42:35 +0200 To: David Conrad , Ed Sawicki , Randy Bush From: "J-F C. (Jefsey) Morfin" Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: DNS Operations , namedroppers , , IPng X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=======1309516B======= Content-Type: text/plain; x-avg-checked=avg-ok-21037C77; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At 03:44 17/07/02, David Conrad wrote: > > If IETF working groups can't be completely open about > > important standards activity, they should be dissolved and new > > ones formed that have more respect for their public trust. >The point of interoperability testing as it is >relevant to the IETF is to insure the protocol specifications are actually >implementable. From that perspective, it doesn't matter who does the >implementation, rather that at least two different sets of people can >actually do them. The frustration results from an uncompleted report. The target is to demonstrate that different thinking families can have the same reading of the specs and can develop from them compatible softwares. The bugs may results from unclear specs or from an early development phase. That we need to know. The name of the participants would only help knowing the X, Y, Z architectures, used libraries, concept affiliations, "style", etc.. To evaluate if the specs testing spectrum is significant enough. But the better, easiest and common way would be that each participant describes his approach in his own terms (so there is no confidentiality break). IMHO this is basic to any hidden testing protocol. Regards. jfc --=======1309516B=======-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 17 07:38:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13171 for ; Wed, 17 Jul 2002 07:38:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Un2Z-000Ao2-00 for namedroppers-data@psg.com; Wed, 17 Jul 2002 04:32:19 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17Un2R-000Amu-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 04:32:12 -0700 Received: from [192.168.4.146] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E66EB137F02; Wed, 17 Jul 2002 04:32:10 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 17 Jul 2002 04:32:12 -0700 Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results From: David Conrad To: "J-F C. (Jefsey) Morfin" , Ed Sawicki , Randy Bush Cc: DNS Operations , namedroppers , , IPng Message-ID: In-Reply-To: <5.1.0.14.0.20020717113429.0247ca40@mail.club-internet.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On 7/17/02 2:42 AM, "J-F C. (Jefsey) Morfin" wrote: > The frustration results from an uncompleted report. It is complete as it needs to be to meet IETF requirements. > The target is to > demonstrate that different thinking families can have the same reading of > the specs and can develop from them compatible softwares. Right. > The bugs may > results from unclear specs or from an early development phase. That we need > to know. What a working group needs to know is whether or not a specification has sufficient detail for two independent developers to develop something that interoperates. If the implementations do not interoperate, then the testers generally (albeit not necessarily) take on the responsibility of figuring out why and proposing revisions to the spec so that interoperability can be achieved (after all, why would they bother implementing if they didn't want to interoperate?). If interoperability is not achieved, the spec doesn't move forward. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 17 08:49:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14863 for ; Wed, 17 Jul 2002 08:49:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Uo7N-000Exw-00 for namedroppers-data@psg.com; Wed, 17 Jul 2002 05:41:21 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17Uo6h-000Evz-00; Wed, 17 Jul 2002 05:40:40 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6HCb5v14086; Wed, 17 Jul 2002 14:37:06 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA25298; Wed, 17 Jul 2002 14:37:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6HCb3GF068792; Wed, 17 Jul 2002 14:37:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207171237.g6HCb3GF068792@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brad Knowles cc: Robert Elz , Ed Sawicki , Randy Bush , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results In-reply-to: Your message of Wed, 17 Jul 2002 11:23:50 +0200. Date: Wed, 17 Jul 2002 14:37:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: Moreover, this test should be labelled a "Standards Conformance Test" or "Standards Compliance Test", and not an "Interoperability Test", because the latter can be construed to be discussing "products" as opposed to pre-alpha testing mules. => I don't know if there is a difference between a "Standards Conformance Test" and a "Standards Compliance Test" but there is a large one between a "Standards Conformance Test" and an "Interoperability Test". And this test is clearly in the second category, so the label is correct. Regards Francis.Dupont@enst-bretagne.fr PS: I can give a contact in one of the four IPv6 test groups I know if you need details, pointers to standards, etc. BTW one of these groups participated to this test... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 17 11:51:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19710 for ; Wed, 17 Jul 2002 11:51:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Uqpj-000LFK-00 for namedroppers-data@psg.com; Wed, 17 Jul 2002 08:35:19 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17Uqod-000LBg-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 08:34:11 -0700 From: Masataka Ohta Message-Id: <200207171515.AAA11341@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA11341; Thu, 18 Jul 2002 00:15:16 +0900 Subject: Re: dnssec discussion today at noon In-Reply-To: from Brad Knowles at "Jul 17, 2002 12:22:59 pm" To: Brad Knowles Date: Thu, 18 Jul 2002 00:15:15 +0859 () CC: Mark.Andrews@isc.org, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Brad; > > Are you saying that the B2B website gladly accept a billion dollar > > order from some unkown company just because a CA says the company's > > domain name is not faked? > > Man-in-the-middle attack. All data that flows from point A to > point B (or vice-versa) is legitimate. It just happens to be > secretly routed through point C, whereby all traffic is sniffed, all > passwords are captured, etc... so that this information can be used > in the future to forge a real transaction. Shared key cryptography can be a protection from the MITM attack. If you think plain text passwords can be on the wire, you haven't seriously considered requirements for commercial transactions. > > Purely techinically, if secret is shared between the website and the > > company, shared key cryptography protect you from a clever fake and a > > MITM attack. > > This assumes perfect implementation of the cryptography and the > manner in which cryptography is used (and the whole rest of the > system). Schneier teaches us that this is a highly unlikely > situation to occur anywhere. I'm teching you Schneier (whoever he is) is wrong, then. > > But, it is not enough credential to perform serious commercial > > transaction. The website should check credit status of its > > members. > > As far as the site is concerned, the account is valid, the > password is valid, what more do you want? Heck, they can even > confirm that at least one valid transaction in the past came from the > same source (which the client can confirm), because there had to be > at least one full transaction that passed through the MITM. I'm saying that the site and its customer must establish credential relationship. If a bank reliably says that a company has large amount of cash, the company is reliable. > > Protection for home banking is by shared secret. > > Yes, you use shared secrets when you log in with your account & > password, but the client still needs to be certain that when he asks > to go to www.insertyourbankhere.com (or uses the custom home banking > software), that this really does take them to the appropriate site in > question and that cache poisoning attacks cannot cause this access to > be directed to a different site that might then do a MITM attack. Then, you are blindly belive CAs are secure. Even if they were, the reality is that most clients never checks whether the transaction use https or http. So, it is stupid to send plain text password with https. > > You can't ask root server operators for compasation for billions > > and trillions of dollars worth of damages when someone spoofs a DNS > > response. > > No, but I can hold up your name as the person who stood in the > way of implementing DNSSEC and DS, and therefore you would be at > least partially to blame for security breaches that occur anywhere in > the world that might have been preventable with DNSSEC and/or DS. As you said: >> Getting DNSSEC working >> only requires that the operators of the root servers, down >> to the zone servers do the right thing. > > Which is hard enough. Witness all the incredibly screwed up TLD >servers. Witness the differences in the modes of operations of the >root nameservers themselves -- do you block all zone transfers or not? you can't identify the person to be blamed for. Even if you can, have you ever checked standard contract of CAs? How much is the upper limit of compensation for failed transaction? > > Serious users protect them with shared secret. They don't blank-mindedly > > rely on CAs not really offerring any serious compasation. > > No. If you want serious protection, you use a one-time pad, and > you make damn sure it never gets used again. Have you ever heard about things called CHAP? You don't have to send your password in plain text over the wire. > > And, there will be multiple screwed up CAs. Or, are there already? > > So there are multiple screwed-up CAs. DNSSEC and DS will be an > improvement over what we've got now, and we will have a smaller set > of problems to deal with once they are in wide use. The more complex protocol, the larger set of problems. > > So, have weakly secure Internet and DNS as a infrastructure and don't > > rely on intermediate entities of servers, routers or CAs. > > Which is what we have now. Exactly. The real world is not using CAs. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 01:41:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12674 for ; Thu, 18 Jul 2002 01:41:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17V3iK-0005QQ-00 for namedroppers-data@psg.com; Wed, 17 Jul 2002 22:20:32 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17V3iF-0005Q4-00 for namedroppers@ops.ietf.org; Wed, 17 Jul 2002 22:20:27 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 544514B22; Thu, 18 Jul 2002 14:20:24 +0900 (JST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Thu, 18 Jul 2002 14:20:24 +0900 Message-Id: <20020718052024.544514B22@coconut.itojun.org> X-Spam-Status: No, hits=-1.1 required=5.0 tests=NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk chairs, i would like to get some guidance on how to proceed with my document draft-itojun-ipv6-nodeinfo-revlookup-00.txt. i would like to publish it as an informational/experimental RFC. which wg is appropriate, or should i pursue it as individual submission? i understand pushbacks against icmpv6 node information query (which should be addressed separately), and against non-DNS name mapping in general. itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 03:33:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25061 for ; Thu, 18 Jul 2002 03:33:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17V5dN-000AhO-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 00:23:33 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17V5dJ-000AhC-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 00:23:29 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 07D314B22; Thu, 18 Jul 2002 16:23:26 +0900 (JST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-reply-to: itojun's message of Thu, 18 Jul 2002 14:20:24 +0900. <20020718052024.544514B22@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Thu, 18 Jul 2002 16:23:25 +0900 Message-Id: <20020718072326.07D314B22@coconut.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > chairs, > i would like to get some guidance on how to proceed with my document > draft-itojun-ipv6-nodeinfo-revlookup-00.txt. i would like to publish > it as an informational/experimental RFC. which wg is appropriate, > or should i pursue it as individual submission? > > i understand pushbacks against icmpv6 node information query > (which should be addressed separately), and against non-DNS name > mapping in general. just to make sure - i don't mean to replace PTR with it, it can be used together with PTR. it is an interesting situation if you get answer from both, but anyway... itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 04:28:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25971 for ; Thu, 18 Jul 2002 04:28:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17V6WB-000CEV-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 01:20:11 -0700 Received: from hamburg.dyn.ietf54.wide.ad.jp ([133.93.18.175] helo=HAMBURG) by psg.com with esmtp (Exim 3.36 #1) id 17V6W6-000CEG-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 01:20:06 -0700 Received: from localhost ([127.0.0.1]) by HAMBURG with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Jul 2002 17:20:12 +0900 To: edlewis@arin.net, kre@munnari.OZ.AU Cc: kitamura@da.jp.nec.com, namedroppers@ops.ietf.org From: kitamura@da.jp.nec.com Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes In-Reply-To: References: <20020716191040Z.kitamura@netlab.nec.co.jp> <23035.1026828296@munnari.OZ.AU> X-Mailer: Mew version 1.94.2 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020718172011L.kitamura@netlab.nec.co.jp> Date: Thu, 18 Jul 2002 17:20:11 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 123 X-OriginalArrivalTime: 18 Jul 2002 08:20:12.0044 (UTC) FILETIME=[EFC17CC0:01C22E33] X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward and Robert, Thank you for your comments. I'm very happy to hear that both of you like and support my idea. Date: Tue, 16 Jul 2002 09:08:44 -0400 Message-ID: > At 7:10 PM +0900 7/16/02, kitamura@da.jp.nec.com wrote: > >Chairs asked me to send e-mail to the mailing-list to confirm > >that this item moves to WG item. > > > >So, if there are any objections, please let us know. > > Although I like the idea (at least superficially), I don't know why > this would be a WG item for a DNS working group. There are clear reasons why I propose my idea at DNSEXT WG. Probably, I have to start to explain the history of the activities of this idea. I have already presented my idea at IPv6 WG in 51st London meeting. And, chairs of IPv6 WG suggested me to continue this activities at DNSEXT WG. Olafur was there when I presented my idea at IPv6 WG. Chairs of IPv6 WG negotiated with Olafur at there. And, Olafur accepted to deal with this activities at DNSEXT WG. So, the "Domain Name Auto-Registration" issues was redirected from IPv6 WG to DNSEXT WG. # If necessary, I think Olafur will add some comments to my explanation. Anyway, I don't like to become a lost child. Please keep discussing on this issue at DNSEXT WG. Frankly speaking, my idea "Domain Name Auto-Registration" should be discussed at either DNSEXT WG or IPv6 WG. As I explained above, I think the decision whether which WG discuss on my idea is done. So, please discuss on my idea at DNSEXT WG. > The plusses of this approach is that it provides a modular solution > to registering IPv6 addresses in DNS. The modules are designed with > the expertise to do the job, leaving DNS to keep to the task of just > serving data as it does now. The minuses is that any state being > held in a detector and registrar must be maintained across device > failures. (Such a short analysis is bound to have holes.) Thank you for your analysis. Let me improve the minuses that you show in the next draft. > But as far as whether this is a DNS document, I'm not sure. The > process uses existing DNS features (secured dynamic update) and > specifies default names that are meaningful to the application at > hand. The draft does not introduce any modification to the way in > which the DNS protocol operates. Absolutely. That is one of sale points of my idea. Anyone who want to use my proposed idea can use it right now. I do not mandate to use my idea. To use or not depends on site policies. Those who want to use can use it. So, the goal of my I-D is to be published as an Informational RFC. > It seems that this would fit into an IPv6 work group (where the > expertise to handle the IPv6 issues lay). When I originally read > this, I assume the ipv6 in the draft name meant it was destined for > draft-ietf-ipv6... eventually. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer From: Robert Elz Date: Tue, 16 Jul 2002 23:04:56 +0900 Message-ID: <23035.1026828296@munnari.OZ.AU> > Date: Tue, 16 Jul 2002 09:08:44 -0400 > From: Edward Lewis > Message-ID: > > | I don't know why this would be a WG item for a DNS working group. > > I agree with that. This looks more like a description of an interesting > technique which can might make life easier for many sites if made > available - but that's just software. There's no particular reason any > two sites should adopt the same approach (nor why they shouldn't). > > If this was to be a recommended method, I'd be concerned about some of the > assumptions (like expecting a manually configured address to necessarily > have an entry in the DNS, or that a manually configured address wouldn't > look identical to an EUI-64 auto-configured one - in fact I have both of those). > > But, as a "here is what we do that works for us" doc, it looks fine. > No need for any work to be done on it (in dnsext or ipv6), just request > that it get published as informational (which is what was suggested in > the meeting). I doubt there will be any problem, provided that it is clear > that documenting a useful technique that can be used is all that it is > claiming to do. I think my idea must be reviewed by DNS expertise. This is one of reasons why I ask to discuss on this issues at DNSEXT WG. > kre > If my explanation is not enough and you still have any objections, please let us know. Thank you. Hiroshi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 06:18:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27582 for ; Thu, 18 Jul 2002 06:18:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17V8E1-000FEV-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 03:09:33 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17V8Dw-000FE4-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 03:09:28 -0700 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28999 for ; Thu, 18 Jul 2002 04:09:27 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GZF00I1MW7Q8V@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 04:09:27 -0600 (MDT) Received: from limande.dyn.ietf54.wide.ad.jp ([133.93.76.228]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GZF001N2W7NQ7@mail.sun.net> for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 04:09:26 -0600 (MDT) Date: Thu, 18 Jul 2002 12:09:24 +0200 From: Alain Durand Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-reply-to: <000401c22e38$f50dbe00$534510ac@cyan> To: Jeroen Massar Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <6F697FCE-9A36-11D6-BE89-000393764158@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Thursday, July 18, 2002, at 10:56 AM, Jeroen Massar wrote: > One application for this could be a reverse dnsserver who doesn't know > the > PTR for a certain IPv6 address it serves the delegation for. It could > then > send this icmp nodeinfo request to the endpoint, which is very probably > quite > close networkwise and use that as a response I'm sure this will lead to very interesting results when a secondary server will try to resolve the reverse for site local addresses.... - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 06:37:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27859 for ; Thu, 18 Jul 2002 06:37:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17V8Wt-000Fqb-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 03:29:03 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17V8Wp-000FqQ-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 03:28:59 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17V8Wp-0000Dk-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 19:28:59 +0900 Message-ID: <000401c22e38$f50dbe00$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <20020718072326.07D314B22@coconut.itojun.org> From: "Jeroen Massar" To: , , Subject: RE: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Date: Thu, 18 Jul 2002 10:56:06 +0200 X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] itojun@iijlab.net wrote: > > chairs, > > i would like to get some guidance on how to proceed with my document > > draft-itojun-ipv6-nodeinfo-revlookup-00.txt. i would like to publish > > it as an informational/experimental RFC. which wg is appropriate, > > or should i pursue it as individual submission? > > > > i understand pushbacks against icmpv6 node information query > > (which should be addressed separately), and against non-DNS name > > mapping in general. > > just to make sure - i don't mean to replace PTR with > it, it can be used together with PTR. it is an interesting situation > if you get answer from both, but anyway... One application for this could be a reverse dnsserver who doesn't know the PTR for a certain IPv6 address it serves the delegation for. It could then send this icmp nodeinfo request to the endpoint, which is very probably quite close networkwise and use that as a response. Ofcourse it could check first if the forward exists and/or that the reverse matches a specified set of host/domainnames. Ofcourse this setting depends on the operator of the dns and network. But IMHO it's easier to implement as it either avoids one to setup a dhcp server to update the reverse zone or to distribute the keys for secure reverse dns updates. Greets, Jeroen -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 07:44:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29342 for ; Thu, 18 Jul 2002 07:44:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17V9Rl-000JHT-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 04:27:49 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17V9Rh-000JHF-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 04:27:45 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6IBQEv31558; Thu, 18 Jul 2002 13:26:14 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA05511; Thu, 18 Jul 2002 13:26:14 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6IBQDGF072344; Thu, 18 Jul 2002 13:26:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207181126.g6IBQDGF072344@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Edward Lewis cc: kitamura@da.jp.nec.com, namedroppers@ops.ietf.org Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes In-reply-to: Your message of Tue, 16 Jul 2002 09:08:44 EDT. Date: Thu, 18 Jul 2002 13:26:13 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,DOMAIN_SUBJECT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: Although I like the idea (at least superficially), I don't know why this would be a WG item for a DNS working group. => this is not an IPv6 WG item for two reasons: - at the previous meeting there was an agreement to put it in the DNSEXT WG. - don't forget the words of our AD: IPv6 is for today. So we should not send everything with a 6 in it to the IPv6 WG but should put IPv6 DNS stuff into DNS WGs. BTW I really like this proposal and annoyed by the obvious lack of attention it received. Regards Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 09:15:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01765 for ; Thu, 18 Jul 2002 09:15:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VAx2-000MSk-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 06:04:12 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17VAwx-000MSR-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 06:04:07 -0700 Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04377 for ; Thu, 18 Jul 2002 07:04:06 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GZG00AHP4ATY6@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 07:04:06 -0600 (MDT) Received: from limande.dyn.ietf54.wide.ad.jp ([133.93.76.228]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GZG00C144AP4W@mail.sun.net> for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 07:04:04 -0600 (MDT) Date: Thu, 18 Jul 2002 15:04:00 +0200 From: Alain Durand Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-reply-to: <001e01c22e53$3594e970$534510ac@cyan> To: Jeroen Massar Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Thursday, July 18, 2002, at 02:03 PM, Jeroen Massar wrote: > That would give very interresting results indeed, so let's add > the fact > that it for example BIND have to be configged for such a delegation > like: > > zone "4.2.0.0.0.0.2.4.1.1.8.e.f.f.3.ip6.int" { > type ipv6nodeinfo; > allow_names "*.unfix.org"; > check_forward yes; > }; > > This would then tell BIND to do nodeinfo queries for > 3ffe:8114:2000:240::/60. This approach will work for the reverse mapping of Site Local addresses if and only if the primary server and all its secondary are all in the _same_ site local zone. If not the ICMP will go to the wrong place... - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 10:23:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03248 for ; Thu, 18 Jul 2002 10:23:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VBxl-000OyL-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 07:09:01 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17VBxb-000Oxe-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 07:08:51 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6IA6U23081063; Thu, 18 Jul 2002 10:06:30 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA11357; Thu, 18 Jul 2002 10:07:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200207181126.g6IBQDGF072344@givry.rennes.enst-bretagne.fr> References: <200207181126.g6IBQDGF072344@givry.rennes.enst-bretagne.fr> Date: Thu, 18 Jul 2002 10:07:05 -0400 To: Francis Dupont , Edward Lewis From: Edward Lewis Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes Cc: kitamura@da.jp.nec.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,DOMAIN_SUBJECT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry to be a process-wonk... At 1:26 PM +0200 7/18/02, Francis Dupont wrote: >=> this is not an IPv6 WG item for two reasons: No argument on that, I am unfamiliar with IPv6 charter. > - at the previous meeting there was an agreement to put it in the > DNSEXT WG. But in the DNSEXT charter this text exists: "Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter." Granted, this also exists: "Broad topics under consideration in DNSEXT are ... adjustments to address the requirements of IPv6 addressing." But this draft does not describe "adjustments" to the DNS protocol. Perhaps the chairs should shed light on what led the draft to us. >BTW I really like this proposal and annoyed by the obvious lack of >attention it received. I did read the draft before arriving in Yokohama as I am in need of learning IPv6, but there was just nothing DNS-related upon which I could comment. Ergo, I wouldn't have thought to mention anything about it on this mailing list. The draft describes a clean use of dynamic update, as per existing specifications. The concerns are whether the network elements will support the IPv6 needs. My knee-jerk reaction is to examine what happens if the elements go down, will this disrupt network activity, will it be able to recover as stateful elements recover? (These aren't DNS concerns.) I do like that this proposal requires no adjustment to DNS. I am not sure that this is a valuable observation. I would suggest that this proposal shares more issues with DHCP than DNS, granted that in DHCP the addresses are being assigned and in this, the addresses are being observed. Either way, an address is bound to an interface and the result recorded in DNS. Either way, the issues about failure, recovery, and possible cross-element cooperation are the same. (How far off-topic am I now?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 10:25:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03291 for ; Thu, 18 Jul 2002 10:25:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VBys-000P15-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 07:10:10 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17VBym-000P0Q-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 07:10:04 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6IA6J23081033; Thu, 18 Jul 2002 10:06:19 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA11326; Thu, 18 Jul 2002 10:07:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20020718172011L.kitamura@netlab.nec.co.jp> References: <20020716191040Z.kitamura@netlab.nec.co.jp> <23035.1026828296@munnari.OZ.AU> <20020718172011L.kitamura@netlab.nec.co.jp> Date: Thu, 18 Jul 2002 09:52:28 -0400 To: kitamura@da.jp.nec.com, edlewis@arin.net, kre@munnari.OZ.AU From: Edward Lewis Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes Cc: kitamura@da.jp.nec.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:20 PM +0900 7/18/02, kitamura@da.jp.nec.com wrote: >So, the goal of my I-D is to be published as an Informational RFC. Ahhhh, this is different than having this document become a DNSEXT WG item. (I'll leave it to the chairs to discuss [or not] what it means to make a document a WG item here.) So, basically, you just would like feedback from the DNS folks. That's fine, and apparently Olafur is giving approval to discuss the document on this list. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 11:29:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05100 for ; Thu, 18 Jul 2002 11:29:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VCsP-0001Ak-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 08:07:33 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17VCsK-0001A1-00; Thu, 18 Jul 2002 08:07:28 -0700 Received: from engill.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g6IF87h03865; Thu, 18 Jul 2002 11:08:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020717095218.02c556c0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 18 Jul 2002 11:04:52 -0400 To: "J-F C. (Jefsey) Morfin" , David Conrad , Ed Sawicki , Randy Bush From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: DNS Operations , namedroppers , , IPng In-Reply-To: <5.1.0.14.0.20020717113429.0247ca40@mail.club-internet.fr> References: <1026847384.23224.49.camel@red> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:42 AM 7/17/2002, J-F C. (Jefsey) Morfin wrote: >The frustration results from an uncompleted report. The target is to >demonstrate that different thinking families can have the same reading of >the specs and can develop from them compatible softwares. The bugs may >results from unclear specs or from an early development phase. That we >need to know. > >The name of the participants would only help knowing the X, Y, Z >architectures, used libraries, concept affiliations, "style", etc.. To >evaluate if the specs testing spectrum is significant enough. But the >better, easiest and common way would be that each participant describes >his approach in his own terms (so there is no confidentiality break). IMHO >this is basic to any hidden testing protocol. Just for the record, THIS interoperabilty test was performed without any vendor participation, thus it is real hard for the report to talk about approaches or reasons why. The real important thing here is there are three implementations that work. This enables the DNSEXT working group to advance RFC1886bis to Draft Standard. The fact that one implementation forces services (mail, NS, ..) to use IPv4 transport when IPv6 transport is available, is not critical as the information is available via explicit AAAA query. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 11:37:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05306 for ; Thu, 18 Jul 2002 11:37:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VDAs-0001r1-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 08:26:38 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17VDAm-0001q7-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 08:26:32 -0700 Received: from engill.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g6IFR2h03920; Thu, 18 Jul 2002 11:27:02 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020718101045.03343770@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 18 Jul 2002 11:23:47 -0400 To: kitamura@da.jp.nec.com, edlewis@arin.net, kre@munnari.OZ.AU From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes Cc: kitamura@da.jp.nec.com, namedroppers@ops.ietf.org In-Reply-To: <20020718172011L.kitamura@netlab.nec.co.jp> References: <20020716191040Z.kitamura@netlab.nec.co.jp> <23035.1026828296@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 04:20 AM 7/18/2002, kitamura@da.jp.nec.com wrote: >Edward and Robert, > >Thank you for your comments. >I'm very happy to hear that both of you like and support my idea. > > >Date: Tue, 16 Jul 2002 09:08:44 -0400 >Message-ID: > > > At 7:10 PM +0900 7/16/02, kitamura@da.jp.nec.com wrote: > > >Chairs asked me to send e-mail to the mailing-list to confirm > > >that this item moves to WG item. > > > > > >So, if there are any objections, please let us know. > > > > Although I like the idea (at least superficially), I don't know why > > this would be a WG item for a DNS working group. > >There are clear reasons why I propose my idea at DNSEXT WG. > >Probably, I have to start to explain the history of the activities of >this idea. >I have already presented my idea at IPv6 WG in 51st London meeting. >And, chairs of IPv6 WG suggested me to continue this activities at >DNSEXT WG. > >Olafur was there when I presented my idea at IPv6 WG. >Chairs of IPv6 WG negotiated with Olafur at there. >And, Olafur accepted to deal with this activities at DNSEXT WG. This is correct. The right place for this document is a DNS working group, there is NO IPv6 problem that needs to be solved, this document is about how to add information to DNS. >So, the "Domain Name Auto-Registration" issues was redirected from >IPv6 WG to DNSEXT WG. ># If necessary, I think Olafur will add some comments to my explanation. > >Anyway, I don't like to become a lost child. >Please keep discussing on this issue at DNSEXT WG. There are 3 possibilities the working group can take with any document that asks for admission: adopts the document as standards track document processes this document for informational/experimental publication the WG tells the authors this is a bad idea and why. >So, the goal of my I-D is to be published as an Informational RFC. This formal request to have the working group process the document as informational/experimental. I will post a formal question to the working group about taking this document on. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 18:45:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14444 for ; Thu, 18 Jul 2002 18:45:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VJen-000Im4-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 15:21:57 -0700 Received: from roam.psg.com ([133.93.74.251]) by psg.com with esmtp (Exim 3.36 #1) id 17VJeh-000Ils-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 15:21:52 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17VJef-0000Sb-00; Fri, 19 Jul 2002 07:21:49 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "J-F C. (Jefsey) Morfin" Cc: namedroppers , ngtrans@sunroof.eng.sun.com, IPng.ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results References: <1026847384.23224.49.camel@red> <5.1.1.6.2.20020717095218.02c556c0@localhost> Message-Id: Date: Fri, 19 Jul 2002 07:21:49 +0900 X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The frustration results from an uncompleted report. The target is to > demonstrate that different thinking families can have the same reading of > the specs and can develop from them compatible softwares. i missed the part about "different thinking families" in 2026. in the ietf, we still occasionally try NOT to make things more complex than they must be. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 22:01:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18760 for ; Thu, 18 Jul 2002 22:01:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VMx3-0000cW-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 18:53:01 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17VMwz-0000cK-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 18:52:57 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15931; Thu, 18 Jul 2002 19:52:54 -0600 (MDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6J1qog25805; Fri, 19 Jul 2002 03:52:50 +0200 (MEST) Date: Fri, 19 Jul 2002 03:50:59 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: kitamura@da.jp.nec.com, edlewis@arin.net, kre@munnari.OZ.AU, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.1.6.2.20020718101045.03343770@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The right place for this document is a DNS working group, there is NO > IPv6 problem that needs to be solved, this document is about how to > add information to DNS. Agreed. The more general question is whether DNSEXT should have the responsibility to drive the overall approach and design to registering and updating the DNS. I don't have a ready answer but merely note that this issue today spans multiple working groups which makes hard for at least me to see the overall design. Do folks have pros and cons for doing this in DNSEXT? Note that this does NOT imply that the components of the design (such as DHCP specifics of updating the DNS) would be under DNSEXT, merely the overall approach and design. 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. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 22:36:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19656 for ; Thu, 18 Jul 2002 22:36:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VNVm-0001yW-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 19:28:54 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17VNVh-0001yJ-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 19:28:49 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6J2S3Y21064; Fri, 19 Jul 2002 04:28:03 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA11124; Fri, 19 Jul 2002 04:28:03 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6J2S2GF074566; Fri, 19 Jul 2002 04:28:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207190228.g6J2S2GF074566@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Edward Lewis cc: kitamura@da.jp.nec.com, namedroppers@ops.ietf.org Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes In-reply-to: Your message of Thu, 18 Jul 2002 10:07:05 EDT. Date: Fri, 19 Jul 2002 04:28:02 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,DOMAIN_SUBJECT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: >=> this is not an IPv6 WG item for two reasons: No argument on that, I am unfamiliar with IPv6 charter. => the IPv6 charter is a catch-all... > - at the previous meeting there was an agreement to put it in the > DNSEXT WG. But in the DNSEXT charter this text exists: "Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter." => so you argue for the DNSOP WG? This is not unreasonable but the proposal has nothing to do with DNS servers. The draft describes a clean use of dynamic update, as per existing specifications. => I fully agree. I do like that this proposal requires no adjustment to DNS. I am not sure that this is a valuable observation. => IMHO this point is a good point for the proposal. I would suggest that this proposal shares more issues with DHCP than DNS, granted that in DHCP the addresses are being assigned and in this, the addresses are being observed. => this is an argument for zero-conf WG... The problem is we have to put it somewhere and not to throw it from WG to WG. So I believe we should stay at the first decision (it is an information/BCP so it doesn't really matter if it exactly fits in the charter or not... I'm more interested by the comments about the proposal itself). Regards Francis.Dupont@enst-bretagne.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 23:06:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20282 for ; Thu, 18 Jul 2002 23:06:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VNyS-00037u-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 19:58:32 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17VNyO-00037g-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 19:58:28 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6IMvJ23088468; Thu, 18 Jul 2002 22:57:19 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA01627; Thu, 18 Jul 2002 22:58:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200207190228.g6J2S2GF074566@givry.rennes.enst-bretagne.fr> References: <200207190228.g6J2S2GF074566@givry.rennes.enst-bretagne.fr> Date: Thu, 18 Jul 2002 22:52:06 -0400 To: Francis Dupont , Edward Lewis From: Edward Lewis Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes Cc: kitamura@da.jp.nec.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:28 AM +0200 7/19/02, Francis Dupont wrote: >=> so you argue for the DNSOP WG? This is not unreasonable but >the proposal has nothing to do with DNS servers. Well, the draft doesn't address the operation of a name server either. The DNSOP charter is a bit dated, but from what I read it's a stretch to place this document there too. >=> this is an argument for zero-conf WG... The problem is we have to put >it somewhere and not to throw it from WG to WG. So I believe we should >stay at the first decision (it is an information/BCP so it doesn't really >matter if it exactly fits in the charter or not... I'm more interested >by the comments about the proposal itself). I don't think that this draft needs a WG, if it is destined for informational (or even experimental). There's no need to force it into an existing WG. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 18 23:08:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20310 for ; Thu, 18 Jul 2002 23:08:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17VO1s-0003HN-00 for namedroppers-data@psg.com; Thu, 18 Jul 2002 20:02:04 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17VO1o-0003HC-00 for namedroppers@ops.ietf.org; Thu, 18 Jul 2002 20:02:00 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6IMvN23088471; Thu, 18 Jul 2002 22:57:23 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA01630; Thu, 18 Jul 2002 22:58:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 18 Jul 2002 22:58:08 -0400 To: Erik Nordmark , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= From: Edward Lewis Subject: Re: Domain Name Auto-Registration for Plugged-in IPv6 Nodes Cc: kitamura@da.jp.nec.com, edlewis@arin.net, kre@munnari.OZ.AU, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,MSGID_CHARS_WEIRD,DOMAIN_SUBJECT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 3:50 AM +0200 7/19/02, Erik Nordmark wrote: >Do folks have pros and cons for doing this in DNSEXT? I'm puzzled that there is a desire to have this become a DNSEXT WG item. I think this technique can be something applied site by site (as kre suggested) and that there's no real interop issue. Note that I am commenting only on admission to the WG, not on the merits of the approach. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 20 04:15:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06804 for ; Sat, 20 Jul 2002 04:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Vp5L-000N5e-00 for namedroppers-data@psg.com; Sat, 20 Jul 2002 00:55:27 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17Vp5H-000N5N-00 for namedroppers@ops.ietf.org; Sat, 20 Jul 2002 00:55:23 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 02627395; Sat, 20 Jul 2002 00:55:22 -0700 (PDT) Date: Sat, 20 Jul 2002 00:55:21 -0700 From: David Terrell To: Alain Durand Cc: Jeroen Massar , itojun@iijlab.net, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Message-ID: <20020720075521.GA7995@pianosa.catch22.org> Reply-To: David Terrell References: <001e01c22e53$3594e970$534510ac@cyan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:52AM up 12 days, 45 mins, 31 users, load averages: 0.24, 0.30, 0.38 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Jul 18, 2002 at 03:04:00PM +0200, Alain Durand wrote: > > On Thursday, July 18, 2002, at 02:03 PM, Jeroen Massar wrote: > > That would give very interresting results indeed, so let's add > >the fact > >that it for example BIND have to be configged for such a delegation > >like: > > > >zone "4.2.0.0.0.0.2.4.1.1.8.e.f.f.3.ip6.int" { > > type ipv6nodeinfo; > > allow_names "*.unfix.org"; > > check_forward yes; > >}; > > > >This would then tell BIND to do nodeinfo queries for > >3ffe:8114:2000:240::/60. > > This approach will work for the reverse mapping of > Site Local addresses if and only if the primary server and > all its secondary are all in the _same_ site local zone. > > If not the ICMP will go to the wrong place... This is yet another general problem with SL addressing which has been discussed before. One might imagine a configuration option that lets you restrict query access for SL addressing to site local (zone-based or otherwise configured local prefixes) requesters. Regardless, I like ICMP node lookup. Information is good. Being able to provide information is good. -- David Terrell | Just another satan-worshipping Harry Potter reader. dbt@meat.net | Nebcorp Prime Minister | http://wwn.nebcorp.com | -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 20 16:43:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15040 for ; Sat, 20 Jul 2002 16:43:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17W0lv-000DVE-00 for namedroppers-data@psg.com; Sat, 20 Jul 2002 13:24:11 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17W0lq-000DV3-00 for namedroppers@ops.ietf.org; Sat, 20 Jul 2002 13:24:07 -0700 From: Masataka Ohta Message-Id: <200207202005.FAA07398@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA07398; Sun, 21 Jul 2002 05:05:42 +0900 Subject: Re: dnssec discussion today at noon In-Reply-To: from Brad Knowles at "Jul 17, 2002 07:53:39 pm" To: Brad Knowles Date: Sun, 21 Jul 2002 05:05:41 +0859 () CC: Mark.Andrews@isc.org, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,PORN_3,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Brad; > > Shared key cryptography can be a protection from the MITM attack. > > They are subject to replay attacks. PAP is, CHAP is not. > If you're talking about cryptography or computer security and you > don't know who Schneier is, then you don't know anything useful about > cryptography or computer security. See above. > There is nothing in the field of cryptography that can begin to > compare with a properly implemented one-time pad. This is a known > fact. :-) You should really read text books. In addition, you should know that cache poisoning of DNS is prevented simply by having separate cache for each referral point, which has nothing to do with cryptography but can be understood with basic knowledge on computer security. > > Even if you can, have you ever checked standard contract of CAs? How > > much is the upper limit of compensation for failed transaction? > > Who needs civil law? Go after them as they did with Eugene > Kashpureff, and put the sucker in jail! It is clearly stated in their contract that operators of CAs won't compensate much. It is obvious that people here who operate root and tld servers won't compensate much. We can not be responsible for the stupidity of someone who use DNSSEC to secure billion dollar transactions. Civil laws will treat those who think they secured billion dollar transactions, simply because they pay $100 treat accordingly. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 20 17:24:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15503 for ; Sat, 20 Jul 2002 17:24:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17W1Tv-000Ew9-00 for namedroppers-data@psg.com; Sat, 20 Jul 2002 14:09:39 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17W1To-000Evw-00 for namedroppers@ops.ietf.org; Sat, 20 Jul 2002 14:09:35 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 20DD44B22; Sun, 21 Jul 2002 06:09:08 +0900 (JST) To: David Terrell Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-reply-to: dbt's message of Sat, 20 Jul 2002 00:55:21 MST. <20020720075521.GA7995@pianosa.catch22.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Sun, 21 Jul 2002 06:09:06 +0900 Message-Id: <20020720210908.20DD44B22@coconut.itojun.org> X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> On Thursday, July 18, 2002, at 02:03 PM, Jeroen Massar wrote: >> > That would give very interresting results indeed, so let's add >> >the fact >> >that it for example BIND have to be configged for such a delegation >> >like: >> >zone "4.2.0.0.0.0.2.4.1.1.8.e.f.f.3.ip6.int" { >> > type ipv6nodeinfo; >> > allow_names "*.unfix.org"; >> > check_forward yes; >> >}; i specifically mentioned in the draft (and presentation) that querier should be the node itself, as view of scope zone is different between them, and there's no way to pass scope zone info over DNS protocol (or identifying scopes). above example is OK as it is for global addresses, but for site-locals and link-locals, above approach (named translates DNS query into ICMPv6 node info query) does not work. minor implementation problem - non-privileged programs cannot generate ICMPv6. so we need: - a root-privileged daemon that sends ICMPv6 node info query, - communication channel from libc resolver to the daemon which does not lose scope info (DNS wire format doesn't work). unix domain socket, shared memory, whatever. current KAME revlookupd is problematical with respect to the latter bullet. http://www.kame.net/kame/kame/kame/revlookupd itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 20 20:05:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17976 for ; Sat, 20 Jul 2002 20:05:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17W42F-000K0s-00 for namedroppers-data@psg.com; Sat, 20 Jul 2002 16:53:15 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17W42A-000Jzh-00 for namedroppers@ops.ietf.org; Sat, 20 Jul 2002 16:53:10 -0700 Received: from green.bisbee.fugue.com (a15.pm3-67.theriver.com [206.25.48.207]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6KNqod18744; Sat, 20 Jul 2002 23:52:51 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6KNrBfD000347; Sat, 20 Jul 2002 16:53:11 -0700 (MST) Date: Sat, 20 Jul 2002 16:53:10 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, itojun@iijlab.net, Jeroen Massar , Alain Durand To: David Terrell From: Ted Lemon In-Reply-To: <20020720075521.GA7995@pianosa.catch22.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Regardless, I like ICMP node lookup. Information is good. Being > able to provide information is good. Yup. I think having the mechanism is great. What do people think of signing the ICMP packet with the private key that corresponds to a KEY RR that is attached to the name mentioned in the ICMP packet? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 20 20:14:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18115 for ; Sat, 20 Jul 2002 20:14:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17W4GF-000KX9-00 for namedroppers-data@psg.com; Sat, 20 Jul 2002 17:07:43 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17W4GB-000KWy-00 for namedroppers@ops.ietf.org; Sat, 20 Jul 2002 17:07:40 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 549884B22; Sun, 21 Jul 2002 09:07:36 +0900 (JST) To: Ted Lemon Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: Ted.Lemon's message of Sat, 20 Jul 2002 16:53:10 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Sun, 21 Jul 2002 09:07:36 +0900 Message-Id: <20020721000736.549884B22@coconut.itojun.org> X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >What do people think of signing the ICMP packet with the private key that >corresponds to a KEY RR that is attached to the name mentioned in the ICMP >packet? i may be asking a stupid question, but where do you get that private key from? for instance, if a node responds with "www.ietf.org", we could get a public key for www.ietf.org by KEY RR query, but not the private key (it's on ietf.org authoritative server, and is not accessible from outside). itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 20 20:33:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18400 for ; Sat, 20 Jul 2002 20:33:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17W4ZV-000LHw-00 for namedroppers-data@psg.com; Sat, 20 Jul 2002 17:27:37 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17W4ZR-000LHl-00 for namedroppers@ops.ietf.org; Sat, 20 Jul 2002 17:27:33 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 448FE4B22; Sun, 21 Jul 2002 09:27:31 +0900 (JST) Cc: Ted Lemon , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Sun, 21 Jul 2002 09:07:36 +0900. <20020721000736.549884B22@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Sun, 21 Jul 2002 09:27:31 +0900 Message-Id: <20020721002731.448FE4B22@coconut.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,MISSING_HEADERS version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>What do people think of signing the ICMP packet with the private key that >>corresponds to a KEY RR that is attached to the name mentioned in the ICMP >>packet? > i may be asking a stupid question, but where do you get that private > key from? for instance, if a node responds with "www.ietf.org", > we could get a public key for www.ietf.org by KEY RR query, but > not the private key (it's on ietf.org authoritative server, and > is not accessible from outside). aha, now i see what you mean... the ICMPv6 node information responder would sign it, and every nodes have secret key on their own. the now problem is there's no generic public-key signing protocol in L3. itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 21 02:42:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02161 for ; Sun, 21 Jul 2002 02:42:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WADS-000864-00 for namedroppers-data@psg.com; Sat, 20 Jul 2002 23:29:14 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17WADN-00085l-00 for namedroppers@ops.ietf.org; Sat, 20 Jul 2002 23:29:09 -0700 Received: from green.bisbee.fugue.com (az-ben-pm3-2-12.ppp.theriver.com [206.25.50.12]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6L6Ssd20141; Sun, 21 Jul 2002 06:28:54 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6L6TDfD000489; Sat, 20 Jul 2002 23:29:13 -0700 (MST) Date: Sat, 20 Jul 2002 23:29:13 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com To: itojun@iijlab.net From: Ted Lemon In-Reply-To: <20020721000736.549884B22@coconut.itojun.org> Message-Id: <2C521845-9C73-11D6-B03B-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > i may be asking a stupid question, but where do you get that private > key from? for instance, if a node responds with "www.ietf.org", > we could get a public key for www.ietf.org by KEY RR query, but > not the private key (it's on ietf.org authoritative server, and > is not accessible from outside). Presumably the device answering the ICMP request is the one named, and therefore knows the private key associated with its name. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 21 10:46:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06563 for ; Sun, 21 Jul 2002 10:46:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WHj4-000Jmc-00 for namedroppers-data@psg.com; Sun, 21 Jul 2002 07:30:22 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17WHiz-000JmR-00 for namedroppers@ops.ietf.org; Sun, 21 Jul 2002 07:30:17 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6LETqC32213; Sun, 21 Jul 2002 16:29:57 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA22324; Sun, 21 Jul 2002 16:29:52 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g6LETnGF083958; Sun, 21 Jul 2002 16:29:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207211429.g6LETnGF083958@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: David Terrell , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-reply-to: Your message of Sun, 21 Jul 2002 06:09:06 +0900. <20020720210908.20DD44B22@coconut.itojun.org> Date: Sun, 21 Jul 2002 16:29:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In your previous mail you wrote: minor implementation problem - non-privileged programs cannot generate ICMPv6. so we need: => to solve this issue I added in my old "INRIA" stack at the request of Alain Durand a SOCK_CONTROL socket type which has access to information ICMPs. - a root-privileged daemon that sends ICMPv6 node info query, - communication channel from libc resolver to the daemon which does not lose scope info (DNS wire format doesn't work). unix domain socket, shared memory, whatever. current KAME revlookupd is problematical with respect to the latter bullet. http://www.kame.net/kame/kame/kame/revlookupd Regards Francis.Dupont@enst-bretagne.fr PS: the change is very small: a definition in sys/socket.h, an entry in netinet[6]/in[6]_proto.c and some new "if" cases in netinet[6]/raw_ip[6].c. I let Alain defend his (very good IMHO) idea. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 21 18:43:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11413 for ; Sun, 21 Jul 2002 18:43:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WP7n-0009Ck-00 for namedroppers-data@psg.com; Sun, 21 Jul 2002 15:24:23 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17WP7i-0009Ar-00 for namedroppers@ops.ietf.org; Sun, 21 Jul 2002 15:24:18 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1D7F64B22; Mon, 22 Jul 2002 07:24:14 +0900 (JST) To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: Ted.Lemon's message of Sat, 20 Jul 2002 23:29:13 MST. <2C521845-9C73-11D6-B03B-00039317663C@nominum.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Mon, 22 Jul 2002 07:24:14 +0900 Message-Id: <20020721222414.1D7F64B22@coconut.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> i may be asking a stupid question, but where do you get that private >> key from? for instance, if a node responds with "www.ietf.org", >> we could get a public key for www.ietf.org by KEY RR query, but >> not the private key (it's on ietf.org authoritative server, and >> is not accessible from outside). >Presumably the device answering the ICMP request is the one named, >and therefore knows the private key associated with its name. no, the device answering ICMPv6 request is not named. with the "type ipv6nodeinfo" directive, named will work like this: - accept DNS query from a DNS client resolver. - send NI query to the target address. - receive NI response from the target. - send DNS response to the original DNS client resolver. since the NI query target can return arbitrary FQDN (like "www.ietf.org") named does not have the private key. client resolver ---------> named -------> the target DNS query NI query client resolver <--------- named <------- the target DNS response NI response itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 11:35:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07692 for ; Mon, 22 Jul 2002 11:35:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WeqQ-000FRC-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 08:11:30 -0700 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 17WeqG-000FQM-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 08:11:20 -0700 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 08:11:19 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Jul 2002 08:11:19 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 22 Jul 2002 08:11:19 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 08:11:18 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 22 Jul 2002 08:10:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C23191.EBC52B46" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Mon, 22 Jul 2002 08:10:31 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013DCBC5@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIrOuNxH05SWoTDSsiYL3IM7qXS0wGVnuUQ From: "Levon Esibov" To: "Erik Nordmark" , Cc: , , , , , , X-OriginalArrivalTime: 22 Jul 2002 15:10:32.0002 (UTC) FILETIME=[EC0BF220:01C23191] X-Spam-Status: No, hits=3.0 required=5.0 tests=DOUBLE_CAPSWORD,UPPERCASE_25_50 version=2.30 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C23191.EBC52B46 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Sunday, July 14, 2002 6:27 AM > To: rfc-editor@rfc-editor.org > Cc: Erik.Nordmark@sun.com; rhall@quadritek.com; bmanning@ISI.EDU; > mayer@gis.net; iesg-secretary@ietf.org; rfc-editor@ISI.EDU; iab@ISI.EDU; > namedroppers@ops.ietf.org > Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard >=20 > > Erik and Randy, > > > > We have ready to go. Should we be > > waiting for an updated version of this document? >=20 > Yes, this issue needs to be inspected further. > We've set the deadline to have a proposed solution to be Sept 1 - after > that we either publish the document with the bug or figure out how to > withdraw > it. But the hope is that a fix will be presented and reviewed before Sept > 1. [Levon Esibov]=20 Kevin Dunlap (who discovered this issue) and authors of the draft continued investigation and determined that GSS-TSIG draft requires minor modification to not contradict RFC 2845. The essence of the modification is to not sign GSS-TSIG server's response in response to not-signed-query sent by GSS-TSIG client. This modification makes GSS-TSIG compliant with RFC 2845's requirement "The server MUST not generate a signed response to an unsigned request" without jeopardizing security of GSS-TSIG algorithm. I attach the updated version of the draft (-06) that resolves this last issue. Sections modified to resolve this issue are 3.1.3.1, 3.1.3.2, 4.1.3 and 6. Please let us know if you find any problems with this modification. If you have any feedback, please respond by the end of day Wednesday, July 24, 2002. I'd like to submit the updated draft on Thursday. Thanks, Levon. >=20 > Thanks, > Erik ------_=_NextPart_001_01C23191.EBC52B46 Content-Type: text/plain; name="draft-ietf-dnsext-gss-tsig-06.txt" Content-Description: draft-ietf-dnsext-gss-tsig-06.txt Content-Disposition: attachment; filename="draft-ietf-dnsext-gss-tsig-06.txt" Content-Transfer-Encoding: base64 SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFN0dWFydCBLd2FuDQo8ZHJhZnQtaWV0Zi1kbnNleHQtZ3NzLXRzaWctMDYudHh0PiAgICAg ICAgICAgICAgICAgICAgICAgICBQcmFlcml0IEdhcmcNCkp1bHkgMjEsIDIwMDIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEphbWVzIEdpbHJveQ0KRXhwaXJl cyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTGV2 b24gRXNpYm92DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEplZmYgV2VzdGhlYWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY3Jvc29mdCBDb3JwLg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSYW5keSBI YWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEx1Y2VudCBUZWNobm9sb2dpZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQogICAgICAgICAgICAgICAgIEdTUyBBbGdvcml0aG0gZm9y IFRTSUcgKEdTUy1UU0lHKQ0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KVGhpcyBkb2N1bWVu dCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZQ0Kd2l0aCBh bGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCkludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQpUYXNr IEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0 aGF0DQpvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBh cw0KSW50ZXJuZXQtRHJhZnRzLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50 cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeA0KbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlcg0KZG9jdW1lbnRzIGF0IGFueSB0aW1lLiAg SXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtDQpEcmFmdHMgYXMgcmVmZXJlbmNl IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzDQoid29yayBpbiBwcm9ncmVz cy4iDQoNClRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3Nl ZCBhdA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoNClRoZSBs aXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQg YXQNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCg0KQWJzdHJhY3QNCg0KVGhl IFRTSUcgcHJvdG9jb2wgcHJvdmlkZXMgdHJhbnNhY3Rpb24gbGV2ZWwgYXV0aGVudGljYXRpb24g Zm9yIEROUy4NClRTSUcgaXMgZXh0ZW5zaWJsZSB0aHJvdWdoIHRoZSBkZWZpbml0aW9uIG9mIG5l dyBhbGdvcml0aG1zLiAgVGhpcw0KZG9jdW1lbnQgc3BlY2lmaWVzIGFuIGFsZ29yaXRobSBiYXNl ZCBvbiB0aGUgR2VuZXJpYyBTZWN1cml0eSBTZXJ2aWNlDQpBcHBsaWNhdGlvbiBQcm9ncmFtIElu dGVyZmFjZSAoR1NTLUFQSSkgKFJGQzI3NDMpLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRXhw aXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAxXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAg ICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCjE6IElu dHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjINCjI6IEFsZ29yaXRobSBPdmVydmlldy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjMNCiAgMi4xOiBHU1MgRGV0YWlscy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCjM6IENsaWVudCBQcm90b2Nv bCBEZXRhaWxzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCiAg My4xOiBOZWdvdGlhdGluZyBDb250ZXh0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjQNCiAgICAzLjEuMTogQ2FsbCBHU1NfSW5pdF9zZWNfY29udGV4dC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICAzLjEuMjogU2VuZCBUS0VZIFF1ZXJ5IHRv IFNlcnZlci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgICAzLjEuMzogUmVj ZWl2ZSBUS0VZIFF1ZXJ5LVJlc3BvbnNlIGZyb20gU2VydmVyLi4uLi4uLi4uLi4uLi4uLi4uLjcN CiAgMy4yOiBDb250ZXh0IEVzdGFibGlzaGVkLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMTANCiAgICAzLjIuMTogVGVybWluYXRpbmcgYSBDb250ZXh0Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCjQ6IFNlcnZlciBQcm90b2NvbCBEZXRhaWxz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCiAgNC4xOiBOZWdv dGlhdGluZyBDb250ZXh0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTANCiAgICA0LjEuMTogUmVjZWl2ZSBUS0VZIFF1ZXJ5IGZyb20gQ2xpZW50Li4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTANCiAgICA0LjEuMjogQ2FsbCBHU1NfQWNjZXB0X3NlY19jb250ZXh0 Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTENCiAgICA0LjEuMzogU2VuZCBUS0VZIFF1 ZXJ5LVJlc3BvbnNlIHRvIENsaWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTINCiAgNC4yOiBD b250ZXh0IEVzdGFibGlzaGVkLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTMNCiAgICA0LjIuMTogVGVybWluYXRpbmcgYSBDb250ZXh0Li4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTMNCjU6IFNlbmRpbmcgYW5kIFZlcmlmeWluZyBTaWduZWQgTWVz c2FnZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQNCiAgNS4xOiBTZW5kaW5nIGEgU2ln bmVkIE1lc3NhZ2UgLSBDYWxsIEdTU19HZXRNSUMuLi4uLi4uLi4uLi4uLi4uLi4uMTQNCiAgNS4y OiBWZXJpZnlpbmcgYSBTaWduZWQgTWVzc2FnZSAtIENhbGwgR1NTX1ZlcmlmeU1JQy4uLi4uLi4u Li4uLi4uMTUNCjY6IEV4YW1wbGUgdXNhZ2Ugb2YgR1NTLVRTSUcgYWxnb3JpdGhtLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTYNCjc6IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkNCjg6IElBTkEgQ29uc2lkZXJh dGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkNCjk6 IENvbmZvcm1hbmNlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTkNCjEwOkFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjANCjExOlJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjANCg0KDQoxLiBJbnRyb2R1 Y3Rpb24NCg0KVGhlIFNlY3JldCBLZXkgVHJhbnNhY3Rpb24gQXV0aGVudGljYXRpb24gZm9yIERO UyAoVFNJRykgW1JGQzI4NDVdDQpwcm90b2NvbCB3YXMgZGV2ZWxvcGVkIHRvIHByb3ZpZGUgYSBs aWdodHdlaWdodCBhdXRoZW50aWNhdGlvbiBhbmQNCmludGVncml0eSBvZiBtZXNzYWdlcyBiZXR3 ZWVuIHR3byBETlMgZW50aXRpZXMsIHN1Y2ggYXMgY2xpZW50IGFuZA0Kc2VydmVyIG9yIHNlcnZl ciBhbmQgc2VydmVyLiBUU0lHIGNhbiBiZSB1c2VkIHRvIHByb3RlY3QgZHluYW1pYw0KdXBkYXRl IG1lc3NhZ2VzLCBhdXRoZW50aWNhdGUgcmVndWxhciBtZXNzYWdlIG9yIHRvIG9mZi1sb2FkDQpj b21wbGljYXRlZCBETlNTRUMgW1JGQzI1MzVdIHByb2Nlc3NpbmcgZnJvbSBhIGNsaWVudCB0byBh IHNlcnZlciBhbmQNCnN0aWxsIGFsbG93IHRoZSBjbGllbnQgdG8gYmUgYXNzdXJlZCBvZiB0aGUg aW50ZWdyaXR5IG9mIHRoZSBhbnN3ZXJzLg0KDQpUaGUgVFNJRyBwcm90b2NvbCBbUkZDMjg0NV0g aXMgZXh0ZW5zaWJsZSB0aHJvdWdoIHRoZSBkZWZpbml0aW9uIG9mIG5ldw0KYWxnb3JpdGhtcy4g IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFuIGFsZ29yaXRobSBiYXNlZCBvbiB0aGUgR2VuZXJp Yw0KU2VjdXJpdHkgU2VydmljZSBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZSAoR1NTLUFQ SSkgW1JGQzI3NDNdLg0KR1NTLUFQSSBpcyBhIGZyYW1ld29yayB0aGF0IHByb3ZpZGVzIGFuIGFi c3RyYWN0aW9uIG9mIHNlY3VyaXR5IHRvIHRoZQ0KYXBwbGljYXRpb24gcHJvdG9jb2wgZGV2ZWxv cGVyLiAgVGhlIHNlY3VyaXR5IHNlcnZpY2VzIG9mZmVyZWQgY2FuDQppbmNsdWRlIGF1dGhlbnRp Y2F0aW9uLCBpbnRlZ3JpdHksIGFuZCBjb25maWRlbnRpYWxpdHkuDQoNClRoZSBHU1MtQVBJIGZy YW1ld29yayBoYXMgc2V2ZXJhbCBiZW5lZml0czoNCiogTWVjaGFuaXNtIGFuZCBwcm90b2NvbCBp bmRlcGVuZGVuY2UuICBUaGUgdW5kZXJseWluZyBtZWNoYW5pc21zIHRoYXQNCnJlYWxpemUgdGhl IHNlY3VyaXR5IHNlcnZpY2VzIGNhbiBiZSBuZWdvdGlhdGVkIG9uIHRoZSBmbHkgYW5kIHZhcmll ZA0Kb3ZlciB0aW1lLiAgRm9yIGV4YW1wbGUsIGEgY2xpZW50IGFuZCBzZXJ2ZXIgTUFZIHVzZSBL ZXJiZXJvcyBbUkZDMTk2NF0NCmZvciBvbmUgdHJhbnNhY3Rpb24sIHdoZXJlYXMgdGhhdCBzYW1l IHNlcnZlciBNQVkgdXNlIFNQS00gW1JGQzIwMjVdDQp3aXRoIGEgZGlmZmVyZW50IGNsaWVudC4N Cg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAyXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1Mt VFNJRyAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCiogVGhlIHByb3RvY29sIGRldmVs b3BlciBpcyByZW1vdmVkIGZyb20gdGhlIHJlc3BvbnNpYmlsaXR5IG9mDQpjcmVhdGluZyBhbmQg bWFuYWdpbmcgYSBzZWN1cml0eSBpbmZyYXN0cnVjdHVyZS4gIEZvciBleGFtcGxlLCB0aGUNCmRl dmVsb3BlciBkb2VzIG5vdCBuZWVkIHRvIGNyZWF0ZSBuZXcga2V5IGRpc3RyaWJ1dGlvbiBvciBr ZXkNCm1hbmFnZW1lbnQgc3lzdGVtcy4gIEluc3RlYWQgdGhlIGRldmVsb3BlciByZWxpZXMgb24g dGhlIHNlY3VyaXR5DQpzZXJ2aWNlIG1lY2hhbmlzbSB0byBtYW5hZ2UgdGhpcyBvbiBpdHMgYmVo YWxmLg0KDQpUaGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBpcyBsaW1pdGVkIHRvIHRoZSBkZXNj cmlwdGlvbiBvZiBhbg0KYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIG9ubHkuIEl0IGRvZXMgbm90 IGRpc2N1c3MgYW5kL29yIHByb3Bvc2UgYW4NCmF1dGhvcml6YXRpb24gbWVjaGFuaXNtLiAgUmVh ZGVycyB0aGF0IGFyZSB1bmZhbWlsaWFyIHdpdGggR1NTLUFQSQ0KY29uY2VwdHMgYXJlIGVuY291 cmFnZWQgdG8gcmVhZCB0aGUgY2hhcmFjdGVyaXN0aWNzIGFuZCBjb25jZXB0cyBzZWN0aW9uDQpv ZiBbUkZDMjc0M10gYmVmb3JlIGV4YW1pbmluZyB0aGlzIHByb3RvY29sIGluIGRldGFpbC4gSXQg aXMgYWxzbw0KYXNzdW1lZCB0aGF0IHRoZSByZWFkZXIgaXMgZmFtaWxpYXIgd2l0aCBbUkZDMjg0 NV0sIFtSRkMyOTMwXSwgW1JGQzEwMzRdDQphbmQgW1JGQzEwMzVdLg0KDQpUaGUga2V5IHdvcmRz ICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwN CiJSRUNPTU1FTkRFRCIsIGFuZCAiTUFZIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl cnByZXRlZCBhcw0KZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4NCg0KDQoyLiBBbGdv cml0aG0gT3ZlcnZpZXcNCg0KSW4gR1NTLCBjbGllbnQgYW5kIHNlcnZlciBpbnRlcmFjdCB0byBj cmVhdGUgYSAic2VjdXJpdHkgY29udGV4dCIuDQpUaGUgc2VjdXJpdHkgY29udGV4dCBjYW4gYmUg dXNlZCB0byBjcmVhdGUgYW5kIHZlcmlmeSB0cmFuc2FjdGlvbg0Kc2lnbmF0dXJlcyBvbiBtZXNz YWdlcyBiZXR3ZWVuIHRoZSB0d28gcGFydGllcy4gIEEgdW5pcXVlIHNlY3VyaXR5DQpjb250ZXh0 IGlzIHJlcXVpcmVkIGZvciBlYWNoIHVuaXF1ZSBjb25uZWN0aW9uIGJldHdlZW4gY2xpZW50IGFu ZA0Kc2VydmVyLg0KDQpDcmVhdGluZyBhIHNlY3VyaXR5IGNvbnRleHQgaW52b2x2ZXMgYSBuZWdv dGlhdGlvbiBiZXR3ZWVuIGNsaWVudCBhbmQNCnNlcnZlci4gIE9uY2UgYSBjb250ZXh0IGhhcyBi ZWVuIGVzdGFibGlzaGVkLCBpdCBoYXMgYSBmaW5pdGUgbGlmZXRpbWUNCmZvciB3aGljaCBpdCBj YW4gYmUgdXNlZCB0byBzZWN1cmUgbWVzc2FnZXMuICBUaHVzIHRoZXJlIGFyZSB0aHJlZQ0Kc3Rh dGVzIG9mIGEgY29udGV4dCBhc3NvY2lhdGVkIHdpdGggYSBjb25uZWN0aW9uOg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgViAgICAgICAgICB8 DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgICAgICAgICAgICAg ICAgICB8IFVuaW5pdGlhbGl6ZWQgfCAgfA0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICB8ICB8DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgViAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsg IHwNCiAgICAgICAgICAgICAgICAgICB8IE5lZ290aWF0aW5nICAgfCAgfA0KICAgICAgICAgICAg ICAgICAgIHwgQ29udGV4dCAgICAgICB8ICB8DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLSsgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgViAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgICAgICAgICAgICAgICAgICB8IENvbnRleHQgICAgICAg fCAgfA0KICAgICAgICAgICAgICAgICAgIHwgRXN0YWJsaXNoZWQgICB8ICB8DQogICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rDQoN CkV4cGlyZXMgSmFudWFyeSAyMSwgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgM10NCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgR1NTLVRT SUcgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQoNCkV2ZXJ5IGNvbm5lY3Rpb24gYmVn aW5zIGluIHRoZSB1bmluaXRpYWxpemVkIHN0YXRlLg0KDQoNCjIuMSBHU1MgRGV0YWlscw0KDQpD bGllbnQgYW5kIHNlcnZlciBNVVNUIGJlIGxvY2FsbHkgYXV0aGVudGljYXRlZCBhbmQgaGF2ZSBh Y3F1aXJlZA0KZGVmYXVsdCBjcmVkZW50aWFscyBiZWZvcmUgdXNpbmcgdGhpcyBwcm90b2NvbCBh cyBzcGVjaWZpZWQgaW4NClNlY3Rpb24gMS4xLjEgIkNyZWRlbnRpYWxzIiBpbiBSRkMgMjc0MyBb UkZDMjc0M10uDQoNClRoZSBHU1MtVFNJRyBhbGdvcml0aG0gY29uc2lzdHMgb2YgdHdvIHN0YWdl czoNCg0KSS4gRXN0YWJsaXNoIHNlY3VyaXR5IGNvbnRleHQuIFRoZSBDbGllbnQgYW5kIFNlcnZl ciB1c2UgdGhlDQpHU1NfSW5pdF9zZWNfY29udGV4dCBhbmQgR1NTX0FjY2VwdF9zZWNfY29udGV4 dCBBUElzIHRvIGdlbmVyYXRlIHRoZQ0KdG9rZW5zIHRoYXQgdGhleSBwYXNzIHRvIGVhY2ggb3Ro ZXIgdXNpbmcgW1JGQzI5MzBdIGFzIGEgdHJhbnNwb3J0DQptZWNoYW5pc20uDQoNCklJLiBPbmNl IHRoZSBzZWN1cml0eSBjb250ZXh0IGlzIGVzdGFibGlzaGVkIGl0IGlzIHVzZWQgdG8gZ2VuZXJh dGUgYW5kDQp2ZXJpZnkgc2lnbmF0dXJlcyB1c2luZyBHU1NfR2V0TUlDIGFuZCBHU1NfVmVyaWZ5 TUlDIEFQSXMuIFRoZXNlDQpzaWduYXR1cmVzIGFyZSBleGNoYW5nZWQgYnkgdGhlIENsaWVudCBh bmQgU2VydmVyIGFzIGEgcGFydCBvZiB0aGUgVFNJRw0KcmVjb3JkcyBleGNoYW5nZWQgaW4gRE5T IG1lc3NhZ2VzIHNlbnQgYmV0d2VlbiB0aGUgQ2xpZW50IGFuZCBTZXJ2ZXIsDQphcyBkZXNjcmli ZWQgaW4gW1JGQzI4NDVdLg0KDQoNCjMuICBDbGllbnQgUHJvdG9jb2wgRGV0YWlscw0KDQpBIHVu aXF1ZSBjb250ZXh0IGlzIHJlcXVpcmVkIGZvciBlYWNoIHNlcnZlciB0byB3aGljaCB0aGUgY2xp ZW50IHNlbmRzDQpzZWN1cmUgbWVzc2FnZXMuICBBIGNvbnRleHQgaXMgaWRlbnRpZmllZCBieSBh IGNvbnRleHQgaGFuZGxlLiBBDQpjbGllbnQgbWFpbnRhaW5zIGEgbWFwcGluZyBvZiBzZXJ2ZXJz IHRvIGhhbmRsZXMsDQoNCiAgICAgKHRhcmdldF9uYW1lLCBrZXlfbmFtZSwgY29udGV4dF9oYW5k bGUpDQoNClRoZSB2YWx1ZSBrZXlfbmFtZSBhbHNvIGlkZW50aWZpZXMgYSBjb250ZXh0IGhhbmRs ZS4gVGhlIGtleV9uYW1lIGlzDQp0aGUgb3duZXIgbmFtZSBvZiB0aGUgVEtFWSBhbmQgVFNJRyBy ZWNvcmRzIHNlbnQgYmV0d2VlbiBhIGNsaWVudCBhbmQgYQ0Kc2VydmVyIHRvIGluZGljYXRlIHRv IGVhY2ggb3RoZXIgd2hpY2ggY29udGV4dCBNVVNUIGJlIHVzZWQgdG8gcHJvY2Vzcw0KdGhlIGN1 cnJlbnQgcmVxdWVzdC4NCg0KRE5TIGNsaWVudCBhbmQgc2VydmVyIE1BWSB1c2UgdmFyaW91cyB1 bmRlcmx5aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgdG8NCmVzdGFibGlzaCBzZWN1cml0eSBjb250 ZXh0IGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9ucyAzIGFuZCA0LiBBdCB0aGUNCnNhbWUgdGltZSwg aW4gb3JkZXIgdG8gZ3VhcmFudGVlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBETlMgY2xpZW50 cw0KYW5kIHNlcnZlcnMgdGhhdCBzdXBwb3J0IEdTUy1UU0lHIGl0IGlzIFJFUVVJUkVEIHRoYXQg c2VjdXJpdHkNCm1lY2hhbmlzbSB1c2VkIGJ5IGNsaWVudCBlbmFibGVzIHVzZSBvZiBLZXJiZXJv cyB2NSAoc2VlIFNlY3Rpb24gOQ0KZm9yIG1vcmUgaW5mb3JtYXRpb24pLg0KDQoNCjMuMSAgTmVn b3RpYXRpbmcgQ29udGV4dA0KDQpJbiBHU1MsIGVzdGFibGlzaGluZyBhIHNlY3VyaXR5IGNvbnRl eHQgaW52b2x2ZXMgdGhlIHBhc3Npbmcgb2Ygb3BhcXVlDQp0b2tlbnMgYmV0d2VlbiB0aGUgY2xp ZW50IGFuZCB0aGUgc2VydmVyLiAgVGhlIGNsaWVudCBnZW5lcmF0ZXMgdGhlDQppbml0aWFsIHRv a2VuIGFuZCBzZW5kcyBpdCB0byB0aGUgc2VydmVyLiAgVGhlIHNlcnZlciBwcm9jZXNzZXMgdGhl DQp0b2tlbiBhbmQgaWYgbmVjZXNzYXJ5LCByZXR1cm5zIGEgc3Vic2VxdWVudCB0b2tlbiB0byB0 aGUgY2xpZW50LiAgVGhlDQpjbGllbnQgcHJvY2Vzc2VzIHRoaXMgdG9rZW4sIGFuZCBzbyBvbiwg dW50aWwgdGhlIG5lZ290aWF0aW9uIGlzDQpjb21wbGV0ZS4gIFRoZSBudW1iZXIgb2YgdGltZXMg dGhlIGNsaWVudCBhbmQgc2VydmVyIGV4Y2hhbmdlIHRva2Vucw0KDQpFeHBpcmVzIEphbnVhcnkg MjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoN CklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICAg IEp1bHkgMjEsIDIwMDINCg0KZGVwZW5kcyBvbiB0aGUgdW5kZXJseWluZyBzZWN1cml0eSBtZWNo YW5pc20uICBBIGNvbXBsZXRlZCBuZWdvdGlhdGlvbg0KcmVzdWx0cyBpbiBhIGNvbnRleHQgaGFu ZGxlLg0KDQpUaGUgVEtFWSByZXNvdXJjZSByZWNvcmQgW1JGQzI5MzBdIGlzIHVzZWQgYXMgdGhl IHZlaGljbGUgdG8gdHJhbnNmZXINCnRva2VucyBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLiAg VGhlIFRLRVkgcmVjb3JkIGlzIGEgZ2VuZXJhbA0KbWVjaGFuaXNtIGZvciBlc3RhYmxpc2hpbmcg c2VjcmV0IGtleXMgZm9yIHVzZSB3aXRoIFRTSUcuICBGb3IgbW9yZQ0KaW5mb3JtYXRpb24sIHNl ZSBbUkZDMjkzMF0uDQoNCg0KMy4xLjEgQ2FsbCBHU1NfSW5pdF9zZWNfY29udGV4dA0KDQpUbyBv YnRhaW4gdGhlIGZpcnN0IHRva2VuIHRvIGJlIHNlbnQgdG8gYSBzZXJ2ZXIsIGEgY2xpZW50IE1V U1QgY2FsbA0KR1NTX0luaXRfc2VjX2NvbnRleHQgQVBJLg0KVGhlIGZvbGxvd2luZyBpbnB1dCBw YXJhbWV0ZXJzIE1VU1QgYmUgdXNlZC4gVGhlIG91dGNvbWUgb2YgdGhlIGNhbGwgaXMNCmluZGlj YXRlZCB3aXRoIHRoZSBvdXRwdXQgdmFsdWVzIGJlbG93LiAgQ29uc3VsdCBTZWN0aW9ucyAyLjIu MQ0KIkdTU19Jbml0X3NlY19jb250ZXh0IGNhbGwiIG9mIFtSRkMyNzQzXSBmb3Igc3ludGF4IGRl ZmluaXRpb25zLg0KDQogICBJTlBVVFMNCiAgICAgQ1JFREVOVElBTCBIQU5ETEUgY2xhaW1hbnRf Y3JlZF9oYW5kbGUgPSBOVUxMIChOVUxMIHNwZWNpZmllcyAidXNlDQogICAgICAgICBkZWZhdWx0 IikuIENsaWVudCBNQVkgaW5zdGVhZCBzcGVjaWZ5IHNvbWUgb3RoZXIgdmFsaWQgaGFuZGxlDQog ICAgICAgICB0byBpdHMgY3JlZGVudGlhbHMuDQogICAgIENPTlRFWFQgSEFORExFIGlucHV0X2Nv bnRleHRfaGFuZGxlICA9IDANCiAgICAgSU5URVJOQUwgTkFNRSAgdGFyZ19uYW1lICAgICAgICAg ICAgID0gIkROU0A8dGFyZ2V0X3NlcnZlcl9uYW1lPiINCiAgICAgT0JKRUNUIElERU5USUZJRVIg bWVjaF90eXBlICAgICAgICAgID0gVW5kZXJseWluZyBzZWN1cml0eQ0KICAgICAgICAgbWVjaGFu aXNtIGNob3NlbiBieSBpbXBsZW1lbnRlcnMuIFRvIGd1YXJhbnRlZQ0KICAgICAgICAgaW50ZXJv cGVyYWJpbGl0eSBvZiB0aGUgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBHU1MtVFNJRw0KICAgICAg ICAgbWVjaGFuaXNtIGNsaWVudCBNVVNUIHNwZWNpZnkgYSB2YWxpZCB1bmRlcmx5aW5nIHNlY3Vy aXR5DQogICAgICAgICBtZWNoYW5pc20gdGhhdCBlbmFibGVzIHVzZSBvZiBLZXJiZXJvcyB2NSAo c2VlIFNlY3Rpb24gOSBmb3INCiAgICAgICAgIG1vcmUgaW5mb3JtYXRpb24pLg0KICAgICBPQ1RF VCBTVFJJTkcgICBpbnB1dF90b2tlbiAgICAgICAgICAgPSBOVUxMDQogICAgIEJPT0xFQU4gICAg ICAgIHJlcGxheV9kZXRfcmVxX2ZsYWcgICA9IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0 dWFsX3JlcV9mbGFnICAgICAgID0gVFJVRQ0KICAgICBCT09MRUFOICAgICAgICBkZWxlZ19yZXFf ZmxhZyAgICAgICAgPSBUUlVFDQogICAgIEJPT0xFQU4gICAgICAgIHNlcXVlbmNlX3JlcV9mbGFn ICAgICA9IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgYW5vbl9yZXFfZmxhZyAgICAgICAgID0g RkFMU0UNCiAgICAgQk9PTEVBTiAgICAgICAgaW50ZWdfcmVxX2ZsYWcgICAgICAgID0gVFJVRQ0K ICAgICBJTlRFR0VSICAgICAgICBsaWZldGltZV9yZXEgICAgICAgICAgPSAwICgwIHJlcXVlc3Rz IGEgZGVmYXVsdA0KICAgICAgICAgdmFsdWUpLiBDbGllbnQgTUFZIGluc3RlYWQgc3BlY2lmeSBh bm90aGVyIHVwcGVyIGJvdW5kIGZvciB0aGUNCiAgICAgICAgIGxpZmV0aW1lIG9mIHRoZSBjb250 ZXh0IHRvIGJlIGVzdGFibGlzaGVkIGluIHNlY29uZHMuDQogICAgIE9DVEVUIFNUUklORyAgIGNo YW5fYmluZGluZ3MgICAgICAgICA9IEFueSB2YWxpZCBjaGFubmVsIGJpbmRpbmdzDQogICAgICAg ICBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAxLjEuNiAiQ2hhbm5lbCBCaW5kaW5ncyIgaW4gW1JG QzI3NDNdDQoNCiAgIE9VVFBVVFMNCiAgICAgSU5URUdFUiAgICAgICAgbWFqb3Jfc3RhdHVzDQog ICAgIENPTlRFWFQgSEFORExFIG91dHB1dF9jb250ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBTVFJJ TkcgICBvdXRwdXRfdG9rZW4NCiAgICAgQk9PTEVBTiAgICAgICAgcmVwbGF5X2RldF9zdGF0ZQ0K ICAgICBCT09MRUFOICAgICAgICBtdXR1YWxfc3RhdGUNCiAgICAgSU5URUdFUiAgICAgICAgbWlu b3Jfc3RhdHVzDQogICAgIE9CSkVDVCBJREVOVElGSUVSIG1lY2hfdHlwZQ0KICAgICBCT09MRUFO ICAgICAgICBkZWxlZ19zdGF0ZQ0KICAgICBCT09MRUFOICAgICAgICBzZXF1ZW5jZV9zdGF0ZQ0K ICAgICBCT09MRUFOICAgICAgICBhbm9uX3N0YXRlDQoNCkV4cGlyZXMgSmFudWFyeSAyMSwgMjAw MyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCg0KSU5URVJO RVQtRFJBRlQgICAgICAgICAgICAgICAgICAgR1NTLVRTSUcgICAgICAgICAgICAgICAgSnVseSAy MSwgMjAwMg0KDQogICAgIEJPT0xFQU4gICAgICAgIHRyYW5zX3N0YXRlDQogICAgIEJPT0xFQU4g ICAgICAgIHByb3RfcmVhZHlfc3RhdGUNCiAgICAgQk9PTEVBTiAgICAgICAgY29uZl9hdmFpbA0K ICAgICBCT09MRUFOICAgICAgICBpbnRlZ19hdmFpbA0KICAgICBJTlRFR0VSICAgICAgICBsaWZl dGltZV9yZWMNCg0KSWYgcmV0dXJuZWQgbWFqb3Jfc3RhdHVzIGlzIHNldCB0byBvbmUgb2YgdGhl IGZvbGxvd2luZyBlcnJvcnMNCg0KICAgICBHU1NfU19ERUZFQ1RJVkVfVE9LRU4NCiAgICAgR1NT X1NfREVGRUNUSVZFX0NSRURFTlRJQUwNCiAgICAgR1NTX1NfQkFEX1NJRyAoR1NTX1NfQkFEX01J QykNCiAgICAgR1NTX1NfTk9fQ1JFRA0KICAgICBHU1NfU19DUkVERU5USUFMU19FWFBJUkVEDQog ICAgIEdTU19TX0JBRF9CSU5ESU5HUw0KICAgICBHU1NfU19PTERfVE9LRU4NCiAgICAgR1NTX1Nf RFVQTElDQVRFX1RPS0VODQogICAgIEdTU19TX05PX0NPTlRFWFQNCiAgICAgR1NTX1NfQkFEX05B TUVUWVBFDQogICAgIEdTU19TX0JBRF9OQU1FDQogICAgIEdTU19TX0JBRF9NRUNIDQogICAgIEdT U19TX0ZBSUxVUkUNCg0KdGhlbiB0aGUgdGhlIGNsaWVudCBNVVNUIGFiYW5kb24gdGhlIGFsZ29y aXRobSBhbmQgTVVTVCBOT1QgdXNlIHRoZQ0KR1NTLVRTSUcgYWxnb3JpdGhtIHRvIGVzdGFibGlz aCB0aGlzIHNlY3VyaXR5IGNvbnRleC4gVGhpcyBkb2N1bWVudA0KZG9lcyBub3QgcHJlc2NyaWJl IHdoaWNoIG90aGVyIG1lY2hhbmlzbSBjb3VsZCBiZSB1c2VkIHRvIGVzdGFibGlzaA0KYSBzZWN1 cml0eSBjb250ZXh0LiBOZXh0IHRpbWUgd2hlbiB0aGlzIGNsaWVudCBuZWVkcyB0byBlc3RhYmxp c2gNCnNlY3VyaXR5IGNvbnRleHQsIHRoZSBjbGllbnQgTUFZIHVzZSBHU1MtVFNJRyBhbGdvcml0 aG0uDQoNClN1Y2Nlc3MgdmFsdWVzIG9mIG1ham9yX3N0YXR1cyBhcmUgR1NTX1NfQ09OVElOVUVf TkVFREVEIGFuZA0KR1NTX1NfQ09NUExFVEUuIFRoZSBleGFjdCBzdWNjZXNzIGNvZGUgaXMgaW1w b3J0YW50IGR1cmluZyBsYXRlcg0KcHJvY2Vzc2luZy4NCg0KVGhlIHZhbHVlcyBvZiByZXBsYXlf ZGV0X3N0YXRlIGFuZCBtdXR1YWxfc3RhdGUgaW5kaWNhdGUgaWYgdGhlDQpzZWN1cml0eSBwYWNr YWdlIHByb3ZpZGVzIHJlcGxheSBkZXRlY3Rpb24gYW5kIG11dHVhbCBhdXRoZW50aWNhdGlvbiwN CnJlc3BlY3RpdmVseS4gSWYgcmV0dXJuZWQgbWFqb3Jfc3RhdHVzIGlzIEdTU19TX0NPTVBMRVRF IEFORCBvbmUgb3IgYm90aA0Kb2YgdGhlc2UgdmFsdWVzIGFyZSBGQUxTRSwgdGhlIGNsaWVudCBN VVNUIGFiYW5kb24gdGhpcyBhbGdvcml0aG0uDQoNCkNsaWVudCdzIGJlaGF2aW9yIE1BWSBkZXBl bmQgb24gb3RoZXIgT1VUUFVUIHBhcmFtZXRlcnMgYWNjb3JkaW5nDQp0byB0aGUgcG9saWN5IGxv Y2FsIHRvIHRoZSBjbGllbnQuDQoNClRoZSBoYW5kbGUgb3V0cHV0X2NvbnRleHRfaGFuZGxlIGlz IHVuaXF1ZSB0byB0aGlzIG5lZ290aWF0aW9uIGFuZA0KaXMgc3RvcmVkIGluIHRoZSBjbGllbnQn cyBtYXBwaW5nIHRhYmxlIGFzIHRoZSBjb250ZXh0X2hhbmRsZSB0aGF0DQptYXBzIHRvIHRhcmdl dF9uYW1lLg0KDQoNCg0KMy4xLjIgU2VuZCBUS0VZIFF1ZXJ5IHRvIFNlcnZlcg0KDQpBbiBvcGFx dWUgb3V0cHV0X3Rva2VuIHJldHVybmVkIGJ5IEdTU19Jbml0X3NlY19jb250ZXh0IGlzIHRyYW5z bWl0dGVkDQp0byB0aGUgc2VydmVyIGluIGEgcXVlcnkgcmVxdWVzdCB3aXRoIFFUWVBFPVRLRVku ICBUaGUgdG9rZW4gaXRzZWxmDQp3aWxsIGJlIHBsYWNlZCBpbiBhIEtleSBEYXRhIGZpZWxkIG9m IHRoZSBSREFUQSBmaWVsZCBpbiB0aGUgVEtFWQ0KcmVzb3VyY2UgcmVjb3JkIGluIHRoZSBhZGRp dGlvbmFsIHJlY29yZHMgc2VjdGlvbiBvZiB0aGUgcXVlcnkuIFRoZQ0Kb3duZXIgbmFtZSBvZiB0 aGUgVEtFWSByZXNvdXJjZSByZWNvcmQgc2V0IHF1ZXJpZWQgZm9yIGFuZCB0aGUgb3duZXINCg0K RXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA2XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJ RyAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCm5hbWUgb2YgdGhlIHN1cHBsaWVkIFRL RVkgcmVzb3VyY2UgcmVjb3JkIGluIHRoZSBhZGRpdGlvbmFsIHJlY29yZHMNCnNlY3Rpb24gTVVT VCBiZSB0aGUgc2FtZS4gVGhpcyBuYW1lIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIHNlY3VyaXR5 DQpjb250ZXh0IHRvIGJvdGggdGhlIGNsaWVudCBhbmQgc2VydmVyLCBhbmQgdGh1cyB0aGUgY2xp ZW50IFNIT1VMRCB1c2UNCmEgdmFsdWUgd2hpY2ggaXMgZ2xvYmFsbHkgdW5pcXVlIGFzIGRlc2Ny aWJlZCBpbiBbUkZDMjkzMF0uIFRvIGFjaGlldmUNCmdsb2JhbCB1bmlxdWVuZXNzLCB0aGUgbmFt ZSBNQVkgY29udGFpbiBhIFVVSUQvR1VJRCBbSVNPMTE1NzhdLg0KDQogICBUS0VZIFJlY29yZA0K ICAgICBOQU1FID0gY2xpZW50LWdlbmVyYXRlZCBnbG9iYWxseSB1bmlxdWUgZG9tYWluIG5hbWUg c3RyaW5nDQogICAgICAgICAgICAoYXMgZGVzY3JpYmVkIGluIFtSRkMyOTMwXSkNCiAgICAgUkRB VEENCiAgICAgICAgQWxnb3JpdGhtIE5hbWUgICAgICA9IGdzcy10c2lnDQogICAgICAgIE1vZGUg ICAgICAgICAgICAgICAgPSAzIChHU1MtQVBJIG5lZ290aWF0aW9uIC0gcGVyIFtSRkMyOTMwXSkN CiAgICAgICAgS2V5IFNpemUgICAgICAgICAgICA9IHNpemUgb2Ygb3V0cHV0X3Rva2VuIGluIG9j dGV0cw0KICAgICAgICBLZXkgRGF0YSAgICAgICAgICAgID0gb3V0cHV0X3Rva2VuDQoNClRoZSBy ZW1haW5pbmcgZmllbGRzIGluIHRoZSBUS0VZIFJEQVRBLCBpLmUuIEluY2VwdGlvbiwgRXhwaXJh dGlvbiwNCkVycm9yLCBPdGhlciBTaXplIGFuZCBEYXRhIEZpZWxkcywgTVVTVCBiZSBzZXQgYWNj b3JkaW5nIHRvIFtSRkMyOTMwXS4NCg0KVGhlIHF1ZXJ5IGlzIHRyYW5zbWl0dGVkIHRvIHRoZSBz ZXJ2ZXIuDQoNCk5vdGU6IGlmIHRoZSBvcmlnaW5hbCBjbGllbnQgY2FsbCB0byBHU1NfSW5pdF9z ZWNfY29udGV4dCByZXR1cm5lZCBhbnkNCm1ham9yX3N0YXR1cyBvdGhlciB0aGFuIEdTU19TX0NP TlRJTlVFX05FRURFRCBvciBHU1NfU19DT01QTEVURSwgdGhlbg0KdGhlIGNsaWVudCBNVVNUIE5P VCBzZW5kIFRLRVkgcXVlcnkuIENsaWVudCdzIGJlaGF2aW9yIGluIHRoaXMgY2FzZSBpcw0KZGVz Y3JpYmVkIGFib3ZlIGluIFNlY3Rpb24gMy4xLjEuDQoNCg0KMy4xLjMgUmVjZWl2ZSBUS0VZIFF1 ZXJ5LVJlc3BvbnNlIGZyb20gU2VydmVyDQoNClVwb24gdGhlIHJlY2VwdGlvbiBvZiB0aGUgVEtF WSBxdWVyeSBETlMgc2VydmVyIE1VU1QgcmVzcG9uZCBhY2NvcmRpbmcNCnRvIHRoZSBkZXNjcmlw dGlvbiBpbiBTZWN0aW9uIDQuIFRoaXMgU2VjdGlvbiBzcGVjaWZpZXMgdGhlIGJlaGF2aW9yDQpv ZiB0aGUgY2xpZW50IGFmdGVyIGl0IHJlY2VpdmVzIHRoZSBtYXRjaGluZyByZXNwb25zZSB0byBp dHMgcXVlcnkuDQoNClRoZSBuZXh0IHByb2Nlc3Npbmcgc3RlcCBkZXBlbmRzIG9uIHRoZSB2YWx1 ZSBvZiBtYWpvcl9zdGF0dXMgZnJvbSB0aGUNCm1vc3QgcmVjZW50IGNhbGwgdGhhdCBjbGllbnQg cGVyZm9ybWVkIHRvIEdTU19Jbml0X3NlY19jb250ZXh0OiBlaXRoZXINCkdTU19TX0NPTVBMRVRF IG9yIEdTU19TX0NPTlRJTlVFLg0KDQoNCg0KMy4xLjMuMSBWYWx1ZSBvZiBtYWpvcl9zdGF0dXMg PT0gR1NTX1NfQ09NUExFVEUNCg0KSWYgdGhlIGxhc3QgY2FsbCB0byBHU1NfSW5pdF9zZWNfY29u dGV4dCB5aWVsZGVkIGEgbWFqb3Jfc3RhdHVzIHZhbHVlDQpvZiBHU1NfU19DT01QTEVURSBhbmQg YSBub24tTlVMTCBvdXRwdXRfdG9rZW4gd2FzIHNlbnQgdG8gdGhlIHNlcnZlciwNCnRoZW4gdGhl IGNsaWVudCBzaWRlIGNvbXBvbmVudCBvZiB0aGUgbmVnb3RpYXRpb24gaXMgY29tcGxldGUgYW5k IHRoZQ0KY2xpZW50IGlzIGF3YWl0aW5nIGNvbmZpcm1hdGlvbiBmcm9tIHRoZSBzZXJ2ZXIuDQoN CkNvbmZpcm1hdGlvbiBpcyBpbiB0aGUgZm9ybSBvZiBhIHF1ZXJ5IHJlc3BvbnNlIHdpdGggUkNP REU9Tk9FUlJPUiBhbmQNCndpdGggdGhlIGxhc3QgY2xpZW50IHN1cHBsaWVkIFRLRVkgcmVjb3Jk IGluIHRoZSBhbnN3ZXIgc2VjdGlvbiBvZiB0aGUNCnF1ZXJ5LiAgSWYgdGhlIHJlc3BvbnNlIGRv ZXMgbm90IG1hdGNoIHRoaXMgZm9ybWF0IHRoZW4gYW4gYXR0YWNrZXIgaGFzDQp0YW1wZXJlZCB3 aXRoIHRoZSBtZXNzYWdlIGluIHRyYW5zaXQgb3IgaGFzIGF0dGVtcHRlZCB0byBzZW5kIHRoZQ0K Y2xpZW50IGEgZmFsc2UgcmVzcG9uc2UuIEluIHRoaXMgY2FzZSB0aGUgY2xpZW50IE1BWSBjb250 aW51ZSB3YWl0aW5nDQpmb3IgYSByZXNwb25zZSB0byBpdHMgbGFzdCBUS0VZIHF1ZXJ5IHVudGls IHRoZSB0aW1lIHBlcmlvZCBzaW5jZSB0aGUNCmNsaWVudCBzZW50IGxhc3QgVEtFWSBxdWVyeSBl eHBpcmVzLiBTdWNoIGEgdGltZSBwZXJpb2QgaXMgc3BlY2lmaWVkIGJ5DQp0aGUgcG9saWN5IGxv Y2FsIHRvIHRoZSBjbGllbnQuIFRoaXMgaXMgYSBuZXcgb3B0aW9uIHRoYXQgYWxsb3dzIEROUw0K DQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDddDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1U U0lHICAgICAgICAgICAgICAgIEp1bHkgMjEsIDIwMDINCg0KY2xpZW50IHRvIGFjY2VwdCBtdWx0 aXBsZSBhbnN3ZXJzIGZvciBvbmUgcXVlcnkgSUQgYW5kIHNlbGVjdCBvbmUgKG5vdA0KbmVjZXNz YXJpbHkgdGhlIGZpcnN0IG9uZSkgYmFzZWQgb24gc29tZSBjcml0ZXJpYS4NCg0KSWYgdGhlIGFw cHJvcHJpYXRlIGNvbmZpcm1hdGlvbiBtZXNzYWdlIGlzIHJlY2VpdmVkIHRoZSBjb250ZXh0IHN0 YXRlDQppcyBhZHZhbmNlZCB0byBDb250ZXh0IEVzdGFibGlzaGVkLiAgUHJvY2VlZCB0byBzZWN0 aW9uIDMuMiBmb3IgdXNhZ2UNCm9mIHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KIA0KTm90aWNlOiBF YXJseSB2ZXJzaW9ucyBvZiBHU1MtVFNJRyBwcm90b2NvbCBhbmQgaW1wbGVtZW50YXRpb24gcmVx dWlyZWQNCnRoYXQNCi0gc2VydmVyknMgcmVzcG9uc2UgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlv biBpcyBzaWduZWQgd2l0aCBhIFRTSUcNCiAgcmVjb3JkOw0KLSB0aGUgc2lnbmF0dXJlIGluIHRo ZSBUU0lHIHJlY29yZCBpcyB2ZXJpZmllZCB1c2luZyB0aGUgcHJvY2VkdXJlDQogIGRldGFpbGVk IGluIHNlY3Rpb24gNSwgU2VuZGluZyBhbmQgVmVyaWZ5aW5nIFNpZ25lZCBNZXNzYWdlczsNCi0g aWYgdGhlIHJlc3BvbnNlIGlzIG5vdCBzaWduZWQgdGhlbiBjbGllbnQgaWdub3JlcyB0aGUgcmVz cG9uc2UgYW5kDQogIGRvZXMgbm90IGFkdmFuY2UgdGhlIGNvbnRleHQgdG8gQ29udGV4dCBFc3Rh Ymxpc2hlZC4NCg0KSWYgaW1wbGVtZW50ZXJzIGRlY2lkZSB0byBlbmFibGUgaW50ZXJvcGVyYWJp bGl0eSB3aXRoIHRoZSBlYXJseQ0KdmVyc2lvbnMgb2YgR1NTLVRTSUcgaW1wbGVtZW50YXRpb25z IChpbmNsdWRlZCBpbiBXaW5kb3dzIDIwMDANClByb2Zlc3Npb25hbCwgYWxsIHZlcnNpb25zIG9m IFdpbmRvd3MgMjAwMCBTZXJ2ZXIsIGFsbCB2ZXJzaW9ucyBvZg0KV2luZG93cyBYUCwgYWxsIHZl cnNpb25zIG9mIFdpbmRvd3MuTmV0IDIwMDMgU2VydmVyLCBMdWNlbnQgRE5TIFNlcnZpY2UNCjMu MSBhbmQgVml0YWxRSVAgNi4wKSBpbXBsZW1lbnRlcnMgb2YgdGhlIEdTUy1UU0lHIGNsaWVudCBt YXkgY29uc2lkZXINCmlnbm9yaW5nIHRoZSBUU0lHIHJlY29yZCBpbmNsdWRlZCBpbiB0aGUgcmVz cG9uc2VzIGZyb20gc3VjaCBzZXJ2ZXJzLg0KSW1wbGVtZW50ZXJzIG9mIHRoZSBHU1MtVFNJRyBz ZXJ2ZXJzIG1heSBjb25zaWRlciBzaWduaW5nIHRoZSByZXNwb25zZQ0KdG8gc3VjaCBjbGllbnQn cyByZXF1ZXN0IGFuZCBpbmNsdWRpbmcgYSBUU0lHIHJlY29yZCBjb250YWluaW5nIHRoZQ0Kc2ln bmF0dXJlIGluIGl0cyByZXNwb25zZS4gRG9pbmcgdGhpcyBpcyBub3QgY29tcGxpYW50IHdpdGgg UkZDIDI4NDUNCnJlcXVpcmluZyB0aGF0ICJUaGUgc2VydmVyIE1VU1Qgbm90IGdlbmVyYXRlIGEg c2lnbmVkIHJlc3BvbnNlIHRvIGFuDQp1bnNpZ25lZCByZXF1ZXN0IiwgYnV0IGFzIGxvbmcgYXMg dGhlcmUgYXJlIG5vIEdTUy1UU0lHIGNsaWVudHMgKGFuZA0KY3VycmVudGx5IHRoZXJlIGFyZSBu byBzdWNoIGNsaWVudHMpIHJlamVjdGluZyByZXNwb25zZXMgY29udGFpbmluZw0KVFNJRyByZWNv cmRzICh3aGljaCBpcyBub3QgcmVxdWlyZWQgYnkgUkZDIDI4NDUpIHNlcnZlcidzIGRldmlhdGlv bg0KZnJvbSBjb21wbGlhbmNlIHdpdGggUkZDIDI4NDUgc2hvdWxkIG5vdCBjYXVzZSBpbnRlcm9w ZXJhYmlsaXR5DQpwcm9ibGVtcy4NCg0KDQoNCjMuMS4zLjIgVmFsdWUgb2YgbWFqb3Jfc3RhdHVz ID09IEdTU19TX0NPTlRJTlVFDQoNCklmIHRoZSBsYXN0IGNhbGwgdG8gR1NTX0luaXRfc2VjX2Nv bnRleHQgeWllbGRlZCBhIG1ham9yX3N0YXR1cyB2YWx1ZQ0Kb2YgR1NTX1NfQ09OVElOVUUsIHRo ZW4gdGhlIG5lZ290aWF0aW9uIGlzIG5vdCB5ZXQgY29tcGxldGUuIFRoZSBzZXJ2ZXINCndpbGwg cmV0dXJuIHRvIHRoZSBjbGllbnQgYSBxdWVyeS1yZXNwb25zZSB3aXRoIGEgVEtFWSByZWNvcmQg aW4gdGhlDQpBbnN3ZXIgc2VjdGlvbi4gSWYgdGhlIEROUyBtZXNzYWdlIGVycm9yIGlzIG5vdCBO T19FUlJPUiBvciBlcnJvciBmaWVsZA0KaW4gdGhlIFRLRVkgcmVjb3JkIGlzIG5vdCAwIChpLmUu IG5vIGVycm9yKSwgdGhlbiB0aGUgY2xpZW50IE1VU1QNCmFiYW5kb24gdGhpcyBuZWdvdGlhdGlv biBzZXF1ZW5jZS4gVGhlIGNsaWVudCBNVVNUIGRlbGV0ZSBhbiBhY3RpdmUNCmNvbnRleHQgYnkg Y2FsbGluZyBHU1NfRGVsZXRlX3NlY19jb250ZXh0IHByb3ZpZGluZyB0aGUgYXNzb2NpYXRlZA0K Y29udGV4dF9oYW5kbGUuIFRoZSBjbGllbnQgTUFZIHJlcGVhdCB0aGUgbmVnb3RpYXRpb24gc2Vx dWVuY2Ugc3RhcnRpbmcNCndpdGggdGhlIHVuaW5pdGlhbGl6ZWQgc3RhdGUgYXMgZGVzY3JpYmVk IGluIHNlY3Rpb24gMy4xLiBUbyBwcmV2ZW50DQppbmZpbml0ZSBsb29waW5nIHRoZSBudW1iZXIg b2YgYXR0ZW1wdHMgdG8gZXN0YWJsaXNoIGEgc2VjdXJpdHkgY29udGV4dA0KTVVTVCBiZSBsaW1p dGVkIHRvIHRlbiBvciBsZXNzLg0KDQpJZiB0aGUgRE5TIG1lc3NhZ2UgZXJyb3IgaXMgTk9fRVJS T1IgYW5kIGVycm9yIGZpbGVkIGluIHRoZSBUS0VZIHJlY29yZA0KaXMgMCAoaS5lLiBubyBlcnJv ciksIHRoZW4gdGhlIGNsaWVudCBNVVNUIHBhc3MgYSB0b2tlbiBzcGVjaWZpZWQgaW4gdGhlDQpL ZXkgRGF0YSBmaWVsZCBpbiB0aGUgVEtFWSByZXNvdXJjZSByZWNvcmQgdG8gR1NTX0luaXRfc2Vj X2NvbnRleHQNCnVzaW5nIHRoZSBzYW1lIHBhcmFtZXRlcnMgdmFsdWVzIGFzIGluIHByZXZpb3Vz IGNhbGwgZXhjZXB0IHZhbHVlcyBmb3INCg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoNCklOVEVSTkVULURS QUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICAgIEp1bHkgMjEsIDIw MDINCg0KQ09OVEVYVCBIQU5ETEUgaW5wdXRfY29udGV4dF9oYW5kbGUgYW5kIE9DVEVUIFNUUklO RyBpbnB1dF90b2tlbiBhcw0KZGVzY3JpYmVkIGJlbG93Og0KDQogICBJTlBVVFMNCiAgICAgQ09O VEVYVCBIQU5ETEUgaW5wdXRfY29udGV4dF9oYW5kbGUgID0gY29udGV4dF9oYW5kbGUgKHRoaXMg aXMgdGhlDQogICAgICAgICAgY29udGV4dF9oYW5kbGUgY29ycmVzcG9uZGluZyB0byB0aGUga2V5 X25hbWUgd2hpY2ggaXMgdGhlDQogICAgICAgICAgb3duZXIgbmFtZSBvZiB0aGUgVEtFWSByZWNv cmQgaW4gdGhlIGFuc3dlciBzZWN0aW9uIGluIHRoZQ0KICAgICAgICAgIFRLRVkgcXVlcnkgcmVz cG9uc2UpDQogICAgIE9DVEVUIFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAgICA9IHRva2Vu IGZyb20gS2V5IGZpZWxkIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFRLRVkgcmVjb3JkDQoNCkRlcGVuZGluZyBvbiB0aGUgZm9sbG93aW5nIE9VVFBVVCB2 YWx1ZXMgb2YgR1NTX0luaXRfc2VjX2NvbnRleHQNCiAgICAgSU5URUdFUiAgICAgICAgbWFqb3Jf c3RhdHVzDQogICAgIE9DVEVUIFNUUklORyAgIG91dHB1dF90b2tlbg0KdGhlIGNsaWVudCBNVVNU IHRha2Ugb25lIG9mIHRoZSBmb2xsb3dpbmcgYWN0aW9uczoNCg0KSWYgT1VUUFVUIG1ham9yX3N0 YXR1cyBpcyBzZXQgdG8gb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzDQogICAgIEdTU19TX0RF RkVDVElWRV9UT0tFTg0KICAgICBHU1NfU19ERUZFQ1RJVkVfQ1JFREVOVElBTA0KICAgICBHU1Nf U19CQURfU0lHIChHU1NfU19CQURfTUlDKQ0KICAgICBHU1NfU19OT19DUkVEDQogICAgIEdTU19T X0NSRURFTlRJQUxTX0VYUElSRUQNCiAgICAgR1NTX1NfQkFEX0JJTkRJTkdTDQogICAgIEdTU19T X09MRF9UT0tFTg0KICAgICBHU1NfU19EVVBMSUNBVEVfVE9LRU4NCiAgICAgR1NTX1NfTk9fQ09O VEVYVA0KICAgICBHU1NfU19CQURfTkFNRVRZUEUNCiAgICAgR1NTX1NfQkFEX05BTUUNCiAgICAg R1NTX1NfQkFEX01FQ0gNCiAgICAgR1NTX1NfRkFJTFVSRQ0KDQp0aGUgY2xpZW50IE1VU1QgYWJh bmRvbiB0aGlzIG5lZ290aWF0aW9uIHNlcXVlbmNlLiBUaGlzIG1lYW5zIHRoYXQgdGhlDQpjbGll bnQgTVVTVCBkZWxldGUgYW4gYWN0aXZlIGNvbnRleHQgYnkgY2FsbGluZyBHU1NfRGVsZXRlX3Nl Y19jb250ZXh0DQpwcm92aWRpbmcgdGhlIGFzc29jaWF0ZWQgY29udGV4dF9oYW5kbGUuIFRoZSBj bGllbnQgTUFZIHJlcGVhdCB0aGUNCm5lZ290aWF0aW9uIHNlcXVlbmNlIHN0YXJ0aW5nIHdpdGgg dGhlIHVuaW5pdGlhbGl6ZWQgc3RhdGUgYXMgZGVzY3JpYmVkDQppbiBzZWN0aW9uIDMuMS4gVG8g cHJldmVudCBpbmZpbml0ZSBsb29waW5nIHRoZSBudW1iZXIgb2YgYXR0ZW1wdHMgdG8NCmVzdGFi bGlzaCBhIHNlY3VyaXR5IGNvbnRleHQgTVVTVCBiZSBsaW1pdGVkIHRvIHRlbiBvciBsZXNzLg0K DQpJZiBPVVRQVVQgbWFqb3Jfc3RhdHVzIGlzIEdTU19TX0NPTlRJTlVFX05FRURFRCBPUiBHU1Nf U19DT01QTEVURSB0aGVuDQpjbGllbnQgTVVTVCBhY3QgYXMgZGVzY3JpYmVkIGJlbG93Lg0KDQpJ ZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09OVElOVUVfTkVFREVEIHRoZSBuZWdvdGlhdGlvbiBp cyBub3QgeWV0DQpmaW5pc2hlZC4gIFRoZSB0b2tlbiBvdXRwdXRfdG9rZW4gTVVTVCBiZSBwYXNz ZWQgdG8gdGhlIHNlcnZlciBpbiBhIFRLRVkNCnJlY29yZCBieSByZXBlYXRpbmcgdGhlIG5lZ290 aWF0aW9uIHNlcXVlbmNlIGJlZ2lubmluZyB3aXRoIHNlY3Rpb24NCjMuMS4yLiAgVGhlIGNsaWVu dCBNVVNUIHBsYWNlIGEgbGltaXQgb24gdGhlIG51bWJlciBvZiBjb250aW51YXRpb25zIGluDQph IGNvbnRleHQgbmVnb3RpYXRpb24gdG8gcHJldmVudCBlbmRsZXNzIGxvb3BpbmcuIFN1Y2ggbGlt aXQgU0hPVUxEIE5PVA0KZXhjZWVkIHZhbHVlIG9mIDEwLg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMg R1NTX1NfQ09NUExFVEUgYW5kIG91dHB1dF90b2tlbiBpcyBub24tTlVMTCwgdGhlDQpjbGllbnQt c2lkZSBjb21wb25lbnQgb2YgdGhlIG5lZ290aWF0aW9uIGlzIGNvbXBsZXRlIGJ1dCB0aGUgdG9r ZW4NCm91dHB1dF90b2tlbiBNVVNUIGJlIHBhc3NlZCB0byB0aGUgc2VydmVyIGJ5IHJlcGVhdGlu ZyB0aGUgbmVnb3RpYXRpb24NCnNlcXVlbmNlIGJlZ2lubmluZyB3aXRoIHNlY3Rpb24gMy4xLjIu DQoNCg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBH U1MtVFNJRyAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCklmIG1ham9yX3N0YXR1cyBp cyBHU1NfU19DT01QTEVURSBhbmQgb3V0cHV0X3Rva2VuIGlzIE5VTEwsIGNvbnRleHQNCm5lZ290 aWF0aW9uIGlzIGNvbXBsZXRlLiAgVGhlIGNvbnRleHQgc3RhdGUgaXMgYWR2YW5jZWQgdG8gQ29u dGV4dA0KRXN0YWJsaXNoZWQuICBQcm9jZWVkIHRvIHNlY3Rpb24gMy4yIGZvciB1c2FnZSBvZiB0 aGUgc2VjdXJpdHkgY29udGV4dC4NCg0KDQozLjIgIENvbnRleHQgRXN0YWJsaXNoZWQNCg0KV2hl biBjb250ZXh0IG5lZ290aWF0aW9uIGlzIGNvbXBsZXRlLCB0aGUgaGFuZGxlIGNvbnRleHRfaGFu ZGxlIE1VU1QgYmUNCnVzZWQgZm9yIHRoZSBnZW5lcmF0aW9uIGFuZCB2ZXJpZmljYXRpb24gb2Yg dHJhbnNhY3Rpb24gc2lnbmF0dXJlcy4NCg0KVGhlIHByb2NlZHVyZXMgZm9yIHNlbmRpbmcgYW5k IHJlY2VpdmluZyBzaWduZWQgbWVzc2FnZXMgYXJlIGRlc2NyaWJlZA0KaW4gc2VjdGlvbiA1LCBT ZW5kaW5nIGFuZCBWZXJpZnlpbmcgU2lnbmVkIE1lc3NhZ2VzLg0KDQoNCjMuMi4xIFRlcm1pbmF0 aW5nIGEgQ29udGV4dA0KDQpXaGVuIHRoZSBjbGllbnQgaXMgbm90IGludGVuZGVkIHRvIGNvbnRp bnVlIHVzaW5nIHRoZSBlc3RhYmxpc2hlZA0Kc2VjdXJpdHkgY29udGV4dCwgdGhlIGNsaWVudCBT SE9VTEQgZGVsZXRlIGFuIGFjdGl2ZSBjb250ZXh0IGJ5DQpjYWxsaW5nIEdTU19EZWxldGVfc2Vj X2NvbnRleHQgcHJvdmlkaW5nIHRoZSBhc3NvY2lhdGVkIGNvbnRleHRfaGFuZGxlLA0KQU5EIGNs aWVudCBTSE9VTEQgZGVsZXRlIHRoZSBlc3RhYmxpc2hlZCBjb250ZXh0IG9uIHRoZSBETlMgc2Vy dmVyDQpieSB1c2luZyBUS0VZIFJSIHdpdGggdGhlIE1vZGUgZmllbGQgc2V0IHRvIDUsIGkuZS4g ImtleSBkZWxldGlvbiINCltSRkMyOTMwXS4NCg0KDQoNCjQuICBTZXJ2ZXIgUHJvdG9jb2wgRGV0 YWlscw0KDQpBcyBvbiB0aGUgY2xpZW50LXNpZGUsIHRoZSByZXN1bHQgb2YgYSBzdWNjZXNzZnVs IGNvbnRleHQgbmVnb3RpYXRpb24NCmlzIGEgY29udGV4dCBoYW5kbGUgdXNlZCBpbiBmdXR1cmUg Z2VuZXJhdGlvbiBhbmQgdmVyaWZpY2F0aW9uIG9mIHRoZQ0KdHJhbnNhY3Rpb24gc2lnbmF0dXJl cy4NCg0KQSBzZXJ2ZXIgTUFZIGJlIG1hbmFnaW5nIHNldmVyYWwgY29udGV4dHMgd2l0aCBzZXZl cmFsIGNsaWVudHMuDQpDbGllbnRzIGlkZW50aWZ5IHRoZWlyIGNvbnRleHRzIGJ5IHByb3ZpZGlu ZyBhIGtleSBuYW1lIGluIHRoZWlyDQpyZXF1ZXN0LiAgVGhlIHNlcnZlciBtYWludGFpbnMgYSBt YXBwaW5nIG9mIGtleSBuYW1lcyB0byBoYW5kbGVzOg0KDQogICAgIChrZXlfbmFtZSwgY29udGV4 dF9oYW5kbGUpDQoNCg0KDQo0LjEgTmVnb3RpYXRpbmcgQ29udGV4dA0KDQpBIHNlcnZlciBNVVNU IHJlY29nbml6ZSBUS0VZIHF1ZXJpZXMgYXMgc2VjdXJpdHkgY29udGV4dCBuZWdvdGlhdGlvbg0K bWVzc2FnZXMuDQoNCg0KNC4xLjEgUmVjZWl2ZSBUS0VZIFF1ZXJ5IGZyb20gQ2xpZW50DQoNClVw b24gcmVjZWl2aW5nIGEgcXVlcnkgd2l0aCBRVFlQRSA9IFRLRVksIHRoZSBzZXJ2ZXIgTVVTVCBl eGFtaW5lDQp3aGV0aGVyIHRoZSBNb2RlIGFuZCBBbGdvcml0aG0gTmFtZSBmaWVsZHMgb2YgdGhl IFRLRVkgcmVjb3JkIGluIHRoZQ0KYWRkaXRpb25hbCByZWNvcmRzIHNlY3Rpb24gb2YgdGhlIG1l c3NhZ2UgY29udGFpbiB2YWx1ZXMgb2YgMyBhbmQNCmdzcy10c2lnLCByZXNwZWN0aXZlbHkuIElm IHRoZXkgZG8sIHRoZW4gdGhlIChrZXlfbmFtZSwgY29udGV4dF9oYW5kbGUpDQptYXBwaW5nIHRh YmxlIGlzIHNlYXJjaGVkIGZvciB0aGUga2V5X25hbWUgbWF0Y2hpbmcgdGhlIG93bmVyIG5hbWUg b2YNCnRoZSBUS0VZIHJlY29yZCBpbiB0aGUgYWRkaXRpb25hbCByZWNvcmRzIHNlY3Rpb24gb2Yg dGhlIHF1ZXJ5LiBJZiB0aGUNCg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAg ICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCm5h bWUgaXMgZm91bmQgaW4gdGhlIHRhYmxlIGFuZCB0aGUgc2VjdXJpdHkgY29udGV4dCBmb3IgdGhp cyBuYW1lIGlzDQplc3RhYmxpc2hlZCBhbmQgbm90IGV4cGlyZWQsIHRoZW4gdGhlIHNlcnZlciBN VVNUIHJlc3BvbmQgdG8gdGhlIHF1ZXJ5DQp3aXRoIEJBRE5BTUUgZXJyb3IgaW4gdGhlIFRLRVkg ZXJyb3IgZmllbGQuICBJZiB0aGUgbmFtZSBpcyBmb3VuZCBpbiB0aGUNCnRhYmxlIGFuZCB0aGUg c2VjdXJpdHkgY29udGV4dCBpcyBub3QgZXN0YWJsaXNoZWQsIHRoZSBjb3JyZXNwb25kaW5nDQpj b250ZXh0X2hhbmRsZSBpcyB1c2VkIGluIHN1YnNlcXVlbnQgR1NTIG9wZXJhdGlvbnMuIElmIHRo ZSBuYW1lIGlzDQpmb3VuZCBidXQgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgZXhwaXJlZCwgdGhl biB0aGUgc2VydmVyIGRlbGV0ZXMgdGhpcw0Kc2VjdXJpdHkgY29udGV4dCwgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gNC4yLjEsIGFuZCBpbnRlcnByZXRzIHRoaXMNCnF1ZXJ5IGFzIGEgc3RhcnQg b2YgbmV3IHNlY3VyaXR5IGNvbnRleHQgbmVnb3RpYXRpb24gYW5kIHBlcmZvcm1zDQpvcGVyYXRp b25zIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMS4yIGFuZCA0LjEuMy4gSWYgdGhlIG5hbWUgaXMg bm90DQpmb3VuZCwgdGhlbiB0aGUgc2VydmVyIGludGVycHJldHMgdGhpcyBxdWVyeSBhcyBhIHN0 YXJ0IG9mIG5ldyBzZWN1cml0eQ0KY29udGV4dCBuZWdvdGlhdGlvbiBhbmQgcGVyZm9ybXMgb3Bl cmF0aW9ucyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuMg0KYW5kIDQuMS4zLg0KDQoNCjQuMS4y IENhbGwgR1NTX0FjY2VwdF9zZWNfY29udGV4dA0KDQpUaGUgc2VydmVyIHBlcmZvcm1zIGl0cyBz aWRlIG9mIGEgY29udGV4dCBuZWdvdGlhdGlvbiBieSBjYWxsaW5nDQpHU1NfQWNjZXB0X3NlY19j b250ZXh0LiBUaGUgZm9sbG93aW5nIGlucHV0IHBhcmFtZXRlcnMgTVVTVCBiZSB1c2VkLiBUaGUN Cm91dGNvbWUgb2YgdGhlIGNhbGwgaXMgaW5kaWNhdGVkIHdpdGggdGhlIG91dHB1dCB2YWx1ZXMg YmVsb3cuICBDb25zdWx0DQpTZWN0aW9ucyAyLjIuMiAiR1NTX0FjY2VwdF9zZWNfY29udGV4dCBj YWxsIiBvZiB0aGUgUkZDIDI3NDNbUkZDMjc0M10NCmZvciBzeW50YXggZGVmaW5pdGlvbnMuDQoN CiAgIElOUFVUUw0KICAgICBDT05URVhUIEhBTkRMRSBpbnB1dF9jb250ZXh0X2hhbmRsZSAgPSAw IGlmIG5ldyBuZWdvdGlhdGlvbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29udGV4dF9oYW5kbGUgbWF0Y2hpbmcNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAga2V5X25hbWUgaWYgb25nb2luZyBuZWdvdGlhdGlvbg0KICAgICBP Q1RFVCBTVFJJTkcgICBpbnB1dF90b2tlbiAgICAgICAgICAgPSB0b2tlbiBzcGVjaWZpZWQgaW4g dGhlIEtleQ0KICAgICAgICAgICBmaWVsZCBmcm9tIFRLRVkgUlIgKGZyb20gQWRkaXRpb25hbCBy ZWNvcmRzIFNlY3Rpb24gb2YNCiAgICAgICAgICAgdGhlIGNsaWVudCdzIHF1ZXJ5KQ0KICAgICBD UkVERU5USUFMIEhBTkRMRSBhY2NlcHRvcl9jcmVkX2hhbmRsZSA9IE5VTEwgKE5VTEwgc3BlY2lm aWVzICJ1c2UNCiAgICAgICAgICAgZGVmYXVsdCIpLiBTZXJ2ZXIgTUFZIGluc3RlYWQgc3BlY2lm eSBzb21lIG90aGVyIHZhbGlkIGhhbmRsZQ0KICAgICAgICAgICB0byBpdHMgY3JlZGVudGlhbHMu DQogICAgIE9DVEVUIFNUUklORyAgIGNoYW5fYmluZGluZ3MgICAgICAgICAgPSBBbnkgdmFsaWQg Y2hhbm5lbCBiaW5kaW5ncw0KICAgICAgICAgICBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAxLjEu NiAiQ2hhbm5lbCBCaW5kaW5ncyIgaW4gW1JGQzI3NDNdDQoNCiAgIE9VVFBVVFMNCiAgICAgSU5U RUdFUiAgICAgICAgbWFqb3Jfc3RhdHVzDQogICAgIENPTlRFWFRfSEFORExFIG91dHB1dF9jb250 ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBTVFJJTkcgICBvdXRwdXRfdG9rZW4NCiAgICAgSU5URUdF UiAgICAgICAgbWlub3Jfc3RhdHVzDQogICAgIElOVEVSTkFMIE5BTUUgIHNyY19uYW1lDQogICAg IE9CSkVDVCBJREVOVElGSUVSICBtZWNoX3R5cGUNCiAgICAgQk9PTEVBTiAgICAgICAgZGVsZWdf c3RhdGUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0dWFsX3N0YXRlDQogICAgIEJPT0xFQU4gICAg ICAgIHJlcGxheV9kZXRfc3RhdGUNCiAgICAgQk9PTEVBTiAgICAgICAgc2VxdWVuY2Vfc3RhdGUN CiAgICAgQk9PTEVBTiAgICAgICAgYW5vbl9zdGF0ZQ0KICAgICBCT09MRUFOICAgICAgICB0cmFu c19zdGF0ZQ0KICAgICBCT09MRUFOICAgICAgICBwcm90X3JlYWR5X3N0YXRlDQogICAgIEJPT0xF QU4gICAgICAgIGNvbmZfYXZhaWwNCiAgICAgQk9PTEVBTiAgICAgICAgaW50ZWdfYXZhaWwNCiAg ICAgSU5URUdFUiAgICAgICAgbGlmZXRpbWVfcmVjDQogICAgIENPTlRFWFRfSEFORExFIGRlbGVn YXRlZF9jcmVkX2hhbmRsZQ0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAg ICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQpJ ZiB0aGlzIGlzIHRoZSBmaXJzdCBjYWxsIHRvIEdTU19BY2NlcHRfc2VjX2NvbnRleHQgaW4gYSBu ZXcNCm5lZ290aWF0aW9uLCB0aGVuIG91dHB1dF9jb250ZXh0X2hhbmRsZSBpcyBzdG9yZWQgaW4g dGhlIHNlcnZlcidzDQprZXktbWFwcGluZyB0YWJsZSBhcyB0aGUgY29udGV4dF9oYW5kbGUgdGhh dCBtYXBzIHRvIHRoZSBuYW1lIG9mIHRoZQ0KVEtFWSByZWNvcmQuDQoNCg0KNC4xLjMgU2VuZCBU S0VZIFF1ZXJ5LVJlc3BvbnNlIHRvIENsaWVudA0KDQpUaGUgc2VydmVyIE1VU1QgcmVzcG9uZCB0 byB0aGUgY2xpZW50IHdpdGggYSBUS0VZIHF1ZXJ5IHJlc3BvbnNlIHdpdGgNClJDT0RFID0gTk9F UlJPUiwgdGhhdCBjb250YWlucyBhIFRLRVkgcmVjb3JkIGluIHRoZSBhbnN3ZXIgc2VjdGlvbi4N Cg0KSWYgT1VUUFVUIG1ham9yX3N0YXR1cyBpcyBvbmUgb2YgdGhlIGZvbGxvd2luZyBlcnJvcnMg dGhlIGVycm9yIGZpZWxkDQppbiB0aGUgVEtFWSByZWNvcmQgc2V0IHRvIEJBREtFWS4NCg0KICAg ICBHU1NfU19ERUZFQ1RJVkVfVE9LRU4NCiAgICAgR1NTX1NfREVGRUNUSVZFX0NSRURFTlRJQUwN CiAgICAgR1NTX1NfQkFEX1NJRyAoR1NTX1NfQkFEX01JQykNCiAgICAgR1NTX1NfRFVQTElDQVRF X1RPS0VODQogICAgIEdTU19TX09MRF9UT0tFTg0KICAgICBHU1NfU19OT19DUkVEDQogICAgIEdT U19TX0NSRURFTlRJQUxTX0VYUElSRUQNCiAgICAgR1NTX1NfQkFEX0JJTkRJTkdTDQogICAgIEdT U19TX05PX0NPTlRFWFQNCiAgICAgR1NTX1NfQkFEX01FQ0gNCiAgICAgR1NTX1NfRkFJTFVSRQ0K DQpJZiBPVVRQVVQgbWFqb3Jfc3RhdHVzIGlzIHNldCB0byAgR1NTX1NfQ09NUExFVEUgb3INCkdT U19TX0NPTlRJTlVFX05FRURFRCB0aGVuIHNlcnZlciBNVVNUIGFjdCBhcyBkZXNjcmliZWQgYmVs b3cuDQoNCklmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01QTEVURSB0aGUgc2VydmVyIGNvbXBv bmVudCBvZiB0aGUNCm5lZ290aWF0aW9uIGlzIGZpbmlzaGVkLiBJZiBvdXRwdXRfdG9rZW4gaXMg bm9uLU5VTEwsIHRoZW4gaXQgTVVTVCBiZQ0KcmV0dXJuZWQgdG8gdGhlIGNsaWVudCBpbiBhIEtl eSBEYXRhIGZpZWxkIG9mIHRoZSBSREFUQSBpbiBUS0VZLiBUaGUNCmVycm9yIGZpZWxkIGluIHRo ZSBUS0VZIHJlY29yZCBpcyBzZXQgdG8gTk9FUlJPUi4gVGhlIGNvbnRleHQgc3RhdGUNCmlzIGFk dmFuY2VkIHRvIENvbnRleHQgRXN0YWJsaXNoZWQuIFNlY3Rpb24gNC4yIGRpc2N1c3NlcyB0aGUg dXNhZ2Ugb2YNCnRoZSBzZWN1cml0eSBjb250ZXh0Lg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NT X1NfQ09NUExFVEUgYW5kIG91dHB1dF90b2tlbiBpcyBOVUxMLCB0aGVuIHRoZQ0KVEtFWSByZWNv cmQgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50IE1VU1QgYmUgcmV0dXJuZWQgaW4gdGhlIEFuc3dl cg0Kc2VjdGlvbiBvZiB0aGUgcmVzcG9uc2UuIFRoZSBjb250ZXh0IHN0YXRlIGlzIGFkdmFuY2Vk IHRvIENvbnRleHQNCkVzdGFibGlzaGVkLiBTZWN0aW9uIDQuMiBkaXNjdXNzZXMgdGhlIHVzYWdl IG9mIHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KDQpOb3RpY2U6IEVhcmx5IHZlcnNpb25zIG9mIEdT Uy1UU0lHIHByb3RvY29sIGFuZCBpbXBsZW1lbnRhdGlvbg0KcmVxdWlyZWQgdGhhdA0KLSBpZiBt YWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09NUExFVEUsIHRoZW4gc2VydmVyknMgcmVzcG9uc2UgZGVz Y3JpYmVkDQogIGluIHRoaXMgc2VjdGlvbiBpcyBzaWduZWQgd2l0aCBhIFRTSUcgcmVjb3JkOw0K LSB0aGUgc2lnbmF0dXJlIGluIHRoZSBUU0lHIHJlY29yZCBpcyB2ZXJpZmllZCBieSBhIGNsaWVu dCB1c2luZyB0aGUNCiAgcHJvY2VkdXJlIGRldGFpbGVkIGluIHNlY3Rpb24gNSwgU2VuZGluZyBh bmQgVmVyaWZ5aW5nIFNpZ25lZA0KICBNZXNzYWdlczsNCi0gaWYgdGhlIHJlc3BvbnNlIGlzIG5v dCBzaWduZWQgdGhlbiBjbGllbnQgaWdub3JlcyB0aGUgcmVzcG9uc2UgYW5kDQogIGRvZXMgbm90 IGFkdmFuY2UgdGhlIGNvbnRleHQgdG8gQ29udGV4dCBFc3RhYmxpc2hlZC4NCg0KSWYgaW1wbGVt ZW50ZXJzIG9mIHRoZSBHU1MtVFNJRyBzZXJ2ZXJzIGRlY2lkZSB0byBlbmFibGUNCmludGVyb3Bl cmFiaWxpdHkgd2l0aCB0aGUgZWFybHkgdmVyc2lvbnMgb2YgR1NTLVRTSUcgY2xpZW50IA0KDQpF eHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDEyXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJ RyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQppbXBsZW1lbnRhdGlvbnMgKGluY2x1 ZGVkIGluIFdpbmRvd3MgMjAwMCBQcm9mZXNzaW9uYWwsIGFsbCB2ZXJzaW9ucw0Kb2YgV2luZG93 cyAyMDAwIFNlcnZlciwgYWxsIHZlcnNpb25zIG9mIFdpbmRvd3MgWFAsIGFsbCB2ZXJzaW9ucyBv Zg0KV2luZG93cy5OZXQgMjAwMyBTZXJ2ZXIsIEx1Y2VudCBETlMgU2VydmljZSAzLjEgYW5kIFZp dGFsUUlQIDYuMCkgdGhlbg0KdGhleSBtYXkgY29uc2lkZXIgc2lnbmluZyB0aGUgcmVzcG9uc2Ug dG8gc3VjaCBjbGllbnQncyByZXF1ZXN0IGFuZA0KaW5jbHVkaW5nIGEgVFNJRyByZWNvcmQgY29u dGFpbmluZyB0aGUgc2lnbmF0dXJlIGluIGl0cyByZXNwb25zZS4NCkRvaW5nIHRoaXMgaXMgbm90 IGNvbXBsaWFudCB3aXRoIFJGQyAyODQ1IHJlcXVpcmluZyB0aGF0ICJUaGUgc2VydmVyDQpNVVNU IG5vdCBnZW5lcmF0ZSBhIHNpZ25lZCByZXNwb25zZSB0byBhbiB1bnNpZ25lZCByZXF1ZXN0Iiwg YnV0IGFzDQpsb25nIGFzIHRoZXJlIGFyZSBubyBHU1MtVFNJRyBjbGllbnRzIChhbmQgY3VycmVu dGx5IHRoZXJlIGFyZSBubyBzdWNoDQpjbGllbnRzKSByZWplY3RpbmcgcmVzcG9uc2VzIGNvbnRh aW5pbmcgVFNJRyByZWNvcmRzICh3aGljaCBpcyBub3QNCnJlcXVpcmVkIGJ5IFJGQyAyODQ1KSBz ZXJ2ZXIncyBkZXZpYXRpb24gZnJvbSBjb21wbGlhbmNlIHdpdGggUkZDIDI4NDUNCnNob3VsZCBu b3QgY2F1c2UgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcy4NCg0KSWYgbWFqb3Jfc3RhdHVzIGlz IEdTU19TX0NPTlRJTlVFLCB0aGUgc2VydmVyIGNvbXBvbmVudCBvZiB0aGUNCm5lZ290aWF0aW9u IGlzIG5vdCB5ZXQgZmluaXNoZWQuICBUaGUgc2VydmVyIHJlc3BvbmRzIHRvIHRoZSBUS0VZDQpx dWVyeSB3aXRoIGEgc3RhbmRhcmQgcXVlcnkgcmVzcG9uc2UsIHBsYWNpbmcgaW4gdGhlIGFuc3dl ciBzZWN0aW9uIGENClRLRVkgcmVjb3JkIGNvbnRhaW5pbmcgb3V0cHV0X3Rva2VuIGluIHRoZSBL ZXkgRGF0YSBSREFUQSBmaWVsZC4gVGhlDQplcnJvciBmaWVsZCBpbiB0aGUgVEtFWSByZWNvcmQg aXMgc2V0IHRvIE5PRVJST1IuIFRoZSBzZXJ2ZXIgTVVTVCBsaW1pdA0KdGhlIG51bWJlciBvZiB0 aW1lcyB0aGF0IGEgZ2l2ZW4gY29udGV4dCBpcyBhbGxvd2VkIHRvIHJlcGVhdCwgdG8NCnByZXZl bnQgZW5kbGVzcyBsb29waW5nLiBTdWNoIGxpbWl0IFNIT1VMRCBOT1QgZXhjZWVkIHZhbHVlIG9m IDEwLg0KDQpJbiBhbGwgY2FzZXMgZXhjZXB0IGlmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01Q TEVURSBhbmQgb3V0cHV0X3Rva2VuDQppcyBOVUxMIG90aGVyIFRLRVkgcmVjb3JkIGZpZWxkcyBN VVNUIGNvbnRhaW4gdGhlIGZvbGxvd2luZyB2YWx1ZXM6DQogICAgIE5BTUUgPSBrZXlfbmFtZQ0K ICAgICBSREFUQQ0KICAgICAgICBBbGdvcml0aG0gTmFtZSAgICAgID0gZ3NzLXRzaWcNCiAgICAg ICAgTW9kZSAgICAgICAgICAgICAgICA9IDMgKEdTUy1BUEkgbmVnb3RpYXRpb24gLSBwZXIgW1JG QzI5MzBdKQ0KICAgICAgICBLZXkgU2l6ZSAgICAgICAgICAgID0gc2l6ZSBvZiBvdXRwdXRfdG9r ZW4gaW4gb2N0ZXRzDQoNClRoZSByZW1haW5pbmcgZmllbGRzIGluIHRoZSBUS0VZIFJEQVRBLCBp LmUuIEluY2VwdGlvbiwgRXhwaXJhdGlvbiwNCkVycm9yLCBPdGhlciBTaXplIGFuZCBEYXRhIEZp ZWxkcywgTVVTVCBiZSBzZXQgYWNjb3JkaW5nIHRvIFtSRkMyOTMwXS4NCg0KDQo0LjIgQ29udGV4 dCBFc3RhYmxpc2hlZA0KDQpXaGVuIGNvbnRleHQgbmVnb3RpYXRpb24gaXMgY29tcGxldGUsIHRo ZSBoYW5kbGUgY29udGV4dF9oYW5kbGUNCmlzIHVzZWQgZm9yIHRoZSBnZW5lcmF0aW9uIGFuZCB2 ZXJpZmljYXRpb24gb2YgdHJhbnNhY3Rpb24gc2lnbmF0dXJlcy4NClRoZSBoYW5kbGUgaXMgdmFs aWQgZm9yIGEgZmluaXRlIGFtb3VudCBvZiB0aW1lIGRldGVybWluZWQgYnkgdGhlDQp1bmRlcmx5 aW5nIHNlY3VyaXR5IG1lY2hhbmlzbS4gQSBzZXJ2ZXIgTUFZIHVuaWxhdGVyYWxseSB0ZXJtaW5h dGUNCmEgY29udGV4dCBhdCBhbnkgdGltZSAoc2VlIHNlY3Rpb24gNC4yLjEpLg0KDQpTZXJ2ZXIg U0hPVUxEIGxpbWl0IHRoZSBhbW91bnQgb2YgbWVtb3J5IHVzZWQgdG8gY2FjaGUgZXN0YWJsaXNo ZWQNCmNvbnRleHRzLg0KDQpUaGUgcHJvY2VkdXJlcyBmb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5n IHNpZ25lZCBtZXNzYWdlcyBhcmUgZ2l2ZW4gaW4NCnNlY3Rpb24gNSwgU2VuZGluZyBhbmQgVmVy aWZ5aW5nIFNpZ25lZCBNZXNzYWdlcy4NCg0KDQo0LjIuMSBUZXJtaW5hdGluZyBhIENvbnRleHQN Cg0KQSBzZXJ2ZXIgY2FuIHRlcm1pbmF0ZSBhbnkgZXN0YWJsaXNoZWQgY29udGV4dCBhdCBhbnkg dGltZS4gIFRoZQ0Kc2VydmVyIE1BWSBoaW50IHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgY29udGV4 dCBpcyBiZWluZyBkZWxldGVkIGJ5DQppbmNsdWRpbmcgYSBUS0VZIFJSIGluIGEgcmVzcG9uc2Ug d2l0aCB0aGUgTW9kZSBmaWVsZCBzZXQgdG8gNSwgaS5lLg0KImtleSBkZWxldGlvbiIgW1JGQzI5 MzBdLg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQpBbiBhY3RpdmUgY29u dGV4dCBpcyBkZWxldGVkIGJ5IGNhbGxpbmcgR1NTX0RlbGV0ZV9zZWNfY29udGV4dA0KcHJvdmlk aW5nIHRoZSBhc3NvY2lhdGVkIGNvbnRleHRfaGFuZGxlLg0KDQoNCjUuIFNlbmRpbmcgYW5kIFZl cmlmeWluZyBTaWduZWQgTWVzc2FnZXMNCg0KNS4xIFNlbmRpbmcgYSBTaWduZWQgTWVzc2FnZSAt IENhbGwgR1NTX0dldE1JQw0KDQpUaGUgcHJvY2VkdXJlIGZvciBzZW5kaW5nIGEgc2lnbmF0dXJl LXByb3RlY3RlZCBtZXNzYWdlIGlzIHNwZWNpZmllZA0KaW4gW1JGQzI4NDVdLiAgVGhlIGRhdGEg dG8gYmUgcGFzc2VkIHRvIHRoZSBzaWduYXR1cmUgcm91dGluZSBpbmNsdWRlcw0KdGhlIHdob2xl IEROUyBtZXNzYWdlIHdpdGggc3BlY2lmaWMgVFNJRyB2YXJpYWJsZXMgYXBwZW5kZWQuICBGb3Ig dGhlDQpleGFjdCBmb3JtYXQsIHNlZSBbUkZDMjg0NV0uICBGb3IgdGhpcyBwcm90b2NvbCwgdXNl IHRoZSBmb2xsb3dpbmcNClRTSUcgdmFyaWFibGUgdmFsdWVzOg0KDQogICBUU0lHIFJlY29yZA0K ICAgICBOQU1FID0ga2V5X25hbWUgdGhhdCBpZGVudGlmaWVzIHRoaXMgY29udGV4dA0KICAgICBS REFUQQ0KICAgICAgICBBbGdvcml0aG0gTmFtZSA9IGdzcy10c2lnDQoNCkFzc2lnbiB0aGUgcmVt YWluaW5nIGZpZWxkcyBpbiB0aGUgVFNJRyBSREFUQSBhcHByb3ByaWF0ZSB2YWx1ZXMNCmFzIGRl c2NyaWJlZCBpbiBbUkZDMjg0NV0uDQoNClRoZSBzaWduYXR1cmUgaXMgZ2VuZXJhdGVkIGJ5IGNh bGxpbmcgR1NTX0dldE1JQy4gVGhlIGZvbGxvd2luZyBpbnB1dA0KcGFyYW1ldGVycyBNVVNUIGJl IHVzZWQuIFRoZSBvdXRjb21lIG9mIHRoZSBjYWxsIGlzIGluZGljYXRlZCB3aXRoIHRoZQ0Kb3V0 cHV0IHZhbHVlcyBzcGVjaWZpZWQgYmVsb3cuICBDb25zdWx0IFNlY3Rpb25zIDIuMy4xICJHU1Nf R2V0TUlDDQpjYWxsIiBvZiB0aGUgUkZDIDI3NDNbUkZDMjc0M10gZm9yIHN5bnRheCBkZWZpbml0 aW9ucy4NCg0KICAgSU5QVVRTDQogICAgIENPTlRFWFQgSEFORExFIGNvbnRleHRfaGFuZGxlID0g Y29udGV4dF9oYW5kbGUgZm9yIGtleV9uYW1lDQogICAgIE9DVEVUIFNUUklORyAgIG1lc3NhZ2Ug ICAgICAgID0gb3V0Z29pbmcgbWVzc2FnZSBwbHVzIFRTSUcNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB2YXJpYWJsZXMgKHBlciBbUkZDMjg0NV0pDQogICAgIElOVEVHRVIg cW9wX3JlcSAgICAgICAgICAgICAgID0gMCAoMCByZXF1ZXN0cyBhIGRlZmF1bHQNCiAgICAgICAg IHZhbHVlKS4gQ2FsbGVyIE1BWSBpbnN0ZWFkIHNwZWNpZnkgb3RoZXIgdmFsaWQgdmFsdWUgKGZv cg0KICAgICAgICAgZGV0YWlscyBzZWUgU2VjdGlvbiAxLjIuNCBpbiBbUkZDMjc0M10pDQoNCiAg IE9VVFBVVFMNCiAgICAgSU5URUdFUiAgICAgICAgbWFqb3Jfc3RhdHVzDQogICAgIElOVEVHRVIg ICAgICAgIG1pbm9yX3N0YXR1cw0KICAgICBPQ1RFVCBTVFJJTkcgICBwZXJfbXNnX3Rva2VuDQoN CklmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01QTEVURSwgdGhlbiBzaWduYXR1cmUgZ2VuZXJh dGlvbg0Kc3VjY2VlZGVkLiAgVGhlIHNpZ25hdHVyZSBpbiBwZXJfbXNnX3Rva2VuIGlzIGluc2Vy dGVkIGludG8gdGhlDQpTaWduYXR1cmUgZmllbGQgb2YgdGhlIFRTSUcgUlIgYW5kIHRoZSBtZXNz YWdlIGlzIHRyYW5zbWl0dGVkLg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09OVEVYVF9F WFBJUkVELCBHU1NfU19DUkVERU5USUFMU19FWFBJUkVEIG9yDQpHU1NfU19GQUlMVVJFIHRoZSBj YWxsZXIgTVVTVCBkZWxldGUgdGhlIHNlY3VyaXR5IGNvbnRleHQsIHJldHVybiB0byB0aGUNCnVu aW5pdGlhbGl6ZWQgc3RhdGUgYW5kIFNIT1VMRCBuZWdvdGlhdGUgYSBuZXcgc2VjdXJpdHkgY29u dGV4dCwgYXMNCmRlc2NyaWJlZCBhYm92ZSBpbiBTZWN0aW9uIDMuMQ0KDQpJZiBtYWpvcl9zdGF0 dXMgaXMgR1NTX1NfTk9fQ09OVEVYVCwgdGhlIGNhbGxlciBNVVNUIHJlbW92ZSB0aGUgZW50cnkN CmZvciBrZXlfbmFtZSBmcm9tIHRoZSAodGFyZ2V0XyBuYW1lLCBrZXlfbmFtZSwgY29udGV4dF9o YW5kbGUpIG1hcHBpbmcNCnRhYmxlLCByZXR1cm4gdG8gdGhlIHVuaW5pdGlhbGl6ZWQgc3RhdGUg YW5kIFNIT1VMRCBuZWdvdGlhdGUgYSBuZXcNCnNlY3VyaXR5IGNvbnRleHQsIGFzIGRlc2NyaWJl ZCBhYm92ZSBpbiBTZWN0aW9uIDMuMQ0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDQpJTlRFUk5FVC1EUkFG VCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAw Mg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQkFEX1FPUCwgdGhlIGNhbGxlciBTSE9VTEQg cmVwZWF0IHRoZQ0KR1NTX0dldE1JQyBjYWxsIHdpdGggYWxsb3dlZCBRT1AgdmFsdWUuIFRoZSBu dW1iZXIgb2Ygc3VjaCByZXBldGl0aW9ucw0KTVVTVCBiZSBsaW1pdGVkIHRvIHByZXZlbnQgaW5m aW5pdGUgbG9vcHMuDQoNCg0KNS4yIFZlcmlmeWluZyBhIFNpZ25lZCBNZXNzYWdlIC0gQ2FsbCBH U1NfVmVyaWZ5TUlDDQoNClRoZSBwcm9jZWR1cmUgZm9yIHZlcmlmeWluZyBhIHNpZ25hdHVyZS1w cm90ZWN0ZWQgbWVzc2FnZSBpcyBzcGVjaWZpZWQNCmluIFtSRkMyODQ1XS4NClRoZSBOQU1FIG9m IHRoZSBUU0lHIHJlY29yZCBkZXRlcm1pbmVzIHdoaWNoIGNvbnRleHRfaGFuZGxlIG1hcHMgdG8N CnRoZSBjb250ZXh0IHRoYXQgTVVTVCBiZSB1c2VkIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlLiAg SWYgdGhlIE5BTUUNCmRvZXMgbm90IG1hcCB0byBhbiBlc3RhYmxpc2hlZCBjb250ZXh0LCB0aGUg c2VydmVyIE1VU1Qgc2VuZCBhDQpzdGFuZGFyZCBUU0lHIGVycm9yIHJlc3BvbnNlIHRvIHRoZSBj bGllbnQgaW5kaWNhdGluZyBCQURLRVkgaW4gdGhlDQpUU0lHIGVycm9yIGZpZWxkIChhcyBkZXNj cmliZWQgaW4gW1JGQzI4NDVdKS4NCg0KRm9yIHRoZSBHU1MgYWxnb3JpdGhtLCBhIHNpZ25hdHVy ZSBpcyB2ZXJpZmllZCBieSB1c2luZyBHU1NfVmVyaWZ5TUlDOg0KICAgSU5QVVRTDQogICAgIENP TlRFWFQgSEFORExFIGNvbnRleHRfaGFuZGxlID0gY29udGV4dF9oYW5kbGUgZm9yIGtleV9uYW1l DQogICAgIE9DVEVUIFNUUklORyAgIG1lc3NhZ2UgICAgICAgID0gaW5jb21pbmcgbWVzc2FnZSBw bHVzIFRTSUcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YXJpYWJsZXMg KHBlciBbUkZDMjg0NV0pDQogICAgIE9DVEVUIFNUUklORyAgIHBlcl9tc2dfdG9rZW4gID0gU2ln bmF0dXJlIGZpZWxkIGZyb20gVFNJRyBSUg0KDQogICBPVVRQVVRTDQogICAgIElOVEVHRVIgICAg ICAgIG1ham9yX3N0YXR1cw0KICAgICBJTlRFR0VSICAgICAgICBtaW5vcl9zdGF0dXMNCiAgICAg SU5URUdFUiAgICAgICAgcW9wX3N0YXRlDQoNCklmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01Q TEVURSwgdGhlIHNpZ25hdHVyZSBpcyBhdXRoZW50aWMgYW5kIHRoZQ0KbWVzc2FnZSB3YXMgZGVs aXZlcmVkIGludGFjdC4gIFBlciBbUkZDMjg0NV0sIHRoZSB0aW1lciB2YWx1ZXMgb2YgdGhlDQpU U0lHIHJlY29yZCBNVVNUIGFsc28gYmUgdmFsaWQgYmVmb3JlIGNvbnNpZGVyaW5nIHRoZSBtZXNz YWdlIHRvIGJlDQphdXRoZW50aWMuICBUaGUgY2FsbGVyIE1VU1Qgbm90IGFjdCBvbiB0aGUgcmVx dWVzdCBvciByZXNwb25zZSBpbiB0aGUNCm1lc3NhZ2UgdW50aWwgdGhlc2UgY2hlY2tzIGFyZSB2 ZXJpZmllZC4NCg0KV2hlbiBhIHNlcnZlciBpcyBwcm9jZXNzaW5nIGEgY2xpZW50IHJlcXVlc3Qs DQp0aGUgc2VydmVyIE1VU1Qgc2VuZCBhIHN0YW5kYXJkIFRTSUcgZXJyb3IgcmVzcG9uc2UgdG8g dGhlIGNsaWVudA0KaW5kaWNhdGluZyBCQURLRVkgaW4gdGhlIFRTSUcgZXJyb3IgZmllbGQgYXMg ZGVzY3JpYmVkIGluIFtSRkMyODQ1XSwNCmlmIG1ham9yX3N0YXR1cyBpcyBzZXQgdG8gb25lIG9m IHRoZSBmb2xsb3dpbmcgdmFsdWVzDQogICAgIEdTU19TX0RFRkVDVElWRV9UT0tFTg0KICAgICBH U1NfU19CQURfU0lHIChHU1NfU19CQURfTUlDKQ0KICAgICBHU1NfU19EVVBMSUNBVEVfVE9LRU4N CiAgICAgR1NTX1NfT0xEX1RPS0VODQogICAgIEdTU19TX1VOU0VRX1RPS0VODQogICAgIEdTU19T X0dBUF9UT0tFTg0KICAgICBHU1NfU19DT05URVhUX0VYUElSRUQNCiAgICAgR1NTX1NfTk9fQ09O VEVYVA0KICAgICBHU1NfU19GQUlMVVJFDQoNCg0KSWYgdGhlIHRpbWVyIHZhbHVlcyBvZiB0aGUg VFNJRyByZWNvcmQgYXJlIGludmFsaWQsIHRoZSBtZXNzYWdlIE1VU1QNCk5PVCBiZSBjb25zaWRl cmVkIGF1dGhlbnRpYy4gSWYgdGhpcyBlcnJvciBjaGVja2luZyBmYWlscyB3aGVuIGEgc2VydmVy DQppcyBwcm9jZXNzaW5nIGEgY2xpZW50IHJlcXVlc3QsIHRoZSBhcHByb3ByaWF0ZSBlcnJvciBy ZXNwb25zZSBNVVNUIGJlDQpzZW50IHRvIHRoZSBjbGllbnQgYWNjb3JkaW5nIHRvIFtSRkMyODQ1 XS4NCg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQoNCjYuIEV4YW1wbGUg dXNhZ2Ugb2YgR1NTLVRTSUcgYWxnb3JpdGhtDQoNClRoaXMgU2VjdGlvbiBkZXNjcmliZXMgYW4g ZXhhbXBsZSB3aGVyZSBhIENsaWVudCwgY2xpZW50LmV4YW1wbGUuY29tLA0KYW5kIGEgU2VydmVy LCBzZXJ2ZXIuZXhhbXBsZS5jb20sIGVzdGFibGlzaCBhIHNlY3VyaXR5IGNvbnRleHQgYWNjb3Jk aW5nDQp0byB0aGUgYWxnb3JpdGhtIGRlc2NyaWJlZCBhYm92ZS4NCg0KDQogIEkuIENsaWVudCBp bml0aWFsaXplcyBzZWN1cml0eSBjb250ZXh0IG5lZ290aWF0aW9uDQogIFRvIGVzdGFibGlzaCBh IHNlY3VyaXR5IGNvbnRleHQgd2l0aCBhIHNlcnZlciwgc2VydmVyLmV4YW1wbGUuY29tLCB0aGUN CiAgQ2xpZW50IGNhbGxzIEdTU19Jbml0X3NlY19jb250ZXh0IHdpdGggdGhlIGZvbGxvd2luZyBw YXJhbWV0ZXJzDQogIChOb3RlIHRoYXQgc29tZSBJTlBVVCBhbmQgT1VUUFVUIHBhcmFtZXRlcnMg bm90IGNyaXRpY2FsIGZvciB0aGlzDQogIGFsZ29yaXRobSBhcmUgbm90IGRlc2NyaWJlZCBpbiB0 aGlzIGV4YW1wbGUpDQogICAgIENPTlRFWFQgSEFORExFIGlucHV0X2NvbnRleHRfaGFuZGxlICA9 IDANCiAgICAgSU5URVJOQUwgTkFNRSAgdGFyZ19uYW1lICAgICAgICAgICAgID0gIkROU0BzZXJ2 ZXIuZXhhbXBsZS5jb20iDQogICAgIE9DVEVUIFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAg ICA9IE5VTEwNCiAgICAgQk9PTEVBTiAgICAgICAgcmVwbGF5X2RldF9yZXFfZmxhZyAgID0gVFJV RQ0KICAgICBCT09MRUFOICAgICAgICBtdXR1YWxfcmVxX2ZsYWcgICAgICAgPSBUUlVFDQoNCiAg VGhlIE9VVFBVVFMgcGFyYW1ldGVycyByZXR1cm5lZCBieSBHU1NfSW5pdF9zZWNfY29udGV4dCBp bmNsdWRlDQogICAgIElOVEVHRVIgICAgICAgIG1ham9yX3N0YXR1cyA9IEdTU19TX0NPTlRJTlVF X05FRURFRA0KICAgICBDT05URVhUIEhBTkRMRSBvdXRwdXRfY29udGV4dF9oYW5kbGUgY29udGV4 dF9oYW5kbGUNCiAgICAgT0NURVQgU1RSSU5HICAgb3V0cHV0X3Rva2VuIG91dHB1dF90b2tlbg0K ICAgICBCT09MRUFOICAgICAgICByZXBsYXlfZGV0X3N0YXRlID0gVFJVRQ0KICAgICBCT09MRUFO ICAgICAgICBtdXR1YWxfc3RhdGUgPSBUUlVFDQoNCiAgQ2xpZW50IHZlcmlmaWVzIHRoYXQgcmVw bGF5X2RldF9zdGF0ZSBhbmQgbXV0dWFsX3N0YXRlIHZhbHVlcyBhcmUNCiAgVFJVRS4gU2luY2Ug dGhlIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT05USU5VRV9ORUVERUQsIHdoaWNoIGlzIGENCiAg c3VjY2VzcyBPVVRQVVQgbWFqb3Jfc3RhdHVzIHZhbHVlLCBjbGllbnQgc3RvcmVzIGNvbnRleHRf aGFuZGxlIHRoYXQNCiAgbWFwcyB0byAiRE5TQHNlcnZlci5leGFtcGxlLmNvbSIgYW5kIHByb2Nl ZWRzIHRvIHRoZSBuZXh0IHN0ZXAuDQoNCg0KICBJSS4gQ2xpZW50IHNlbmRzIGEgcXVlcnkgd2l0 aCBRVFlQRSA9IFRLRVkgdG8gc2VydmVyDQogIENsaWVudCBzZW5kcyBhIHF1ZXJ5IHdpdGggUVRZ UEUgPSBUS0VZIGZvciBhIGNsaWVudC1nZW5lcmF0ZWQgZ2xvYmFsbHkNCiAgdW5pcXVlIGRvbWFp biBuYW1lIHN0cmluZywgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIuZXhhbXBsZS5jb20u DQogIFF1ZXJ5IGNvbnRhaW5zIGEgVEtFWSByZWNvcmQgaW4gaXRzIEFkZGl0aW9uYWwgcmVjb3Jk cyBzZWN0aW9uIHdpdGgNCiAgdGhlIGZvbGxvd2luZyBmaWVsZHMgKE5vdGUgdGhhdCBzb21lIGZp ZWxkcyBub3Qgc3BlY2lmaWMgdG8gdGhpcw0KICBhbGdvcml0aG0gYXJlIG5vdCBzcGVjaWZpZWQp DQoNCiAgICAgTkFNRSA9IDc4OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUuY29t Lg0KICAgICBSREFUQQ0KICAgICAgICBBbGdvcml0aG0gTmFtZSAgICAgID0gZ3NzLXRzaWcNCiAg ICAgICAgTW9kZSAgICAgICAgICAgICAgICA9IDMgKEdTUy1BUEkgbmVnb3RpYXRpb24gLSBwZXIg W1JGQzI5MzBdKQ0KICAgICAgICBLZXkgU2l6ZSAgICAgICAgICAgID0gc2l6ZSBvZiBvdXRwdXRf dG9rZW4gaW4gb2N0ZXRzDQogICAgICAgIEtleSBEYXRhICAgICAgICAgICAgPSBvdXRwdXRfdG9r ZW4NCg0KICBBZnRlciB0aGUga2V5X25hbWUgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIu ZXhhbXBsZS5jb20uDQogIGlzIGdlbmVyYXRlZCBpdCBpcyBzdG9yZWQgaW4gdGhlIGNsaWVudCdz ICh0YXJnZXRfbmFtZSwga2V5X25hbWUsDQogIGNvbnRleHRfaGFuZGxlKSBtYXBwaW5nIHRhYmxl Lg0KDQoNCg0KDQoNCkV4cGlyZXMgSmFudWFyeSAyMSwgMjAwMyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAg ICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCg0KICBJSUku IFNlcnZlciByZWNlaXZlcyBhIHF1ZXJ5IHdpdGggUVRZUEUgPSBUS0VZDQogIFdoZW4gc2VydmVy IHJlY2VpdmVzIGEgcXVlcnkgd2l0aCBRVFlQRSA9IFRLRVksIHRoZSBzZXJ2ZXIgdmVyaWZpZXMN CiAgdGhhdCBNb2RlIGFuZCBBbGdvcml0aG0gZmllbGRzIGluIHRoZSBUS0VZIHJlY29yZCBpbiB0 aGUgQWRkaXRpb25hbA0KICByZWNvcmRzIHNlY3Rpb24gb2YgdGhlIHF1ZXJ5IGFyZSBzZXQgdG8g MyBhbmQgImdzcy10c2lnIiByZXNwZWN0aXZlbHkuDQogIEl0IGZpbmRzIHRoYXQgdGhlIGtleV9u YW1lIDc4OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUuY29tLg0KICBpcyBub3Qg bGlzdGVkIGluIGl0cyAoa2V5X25hbWUsIGNvbnRleHRfaGFuZGxlKSBtYXBwaW5nIHRhYmxlLg0K DQoNCiAgSVYuIFNlcnZlciBjYWxscyBHU1NfQWNjZXB0X3NlY19jb250ZXh0DQogIFRvIGNvbnRp bnVlIHNlY3VyaXR5IGNvbnRleHQgbmVnb3RpYXRpb24gc2VydmVyIGNhbGxzDQogIEdTU19BY2Nl cHRfc2VjX2NvbnRleHQgd2l0aCB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgKE5vdGUgdGhhdCBz b21lDQogIElOUFVUIGFuZCBPVVRQVVQgcGFyYW1ldGVycyBub3QgY3JpdGljYWwgZm9yIHRoaXMg YWxnb3JpdGhtIGFyZSBub3QNCiAgZGVzY3JpYmVkIGluIHRoaXMgZXhhbXBsZSkNCiAgIElOUFVU Uw0KICAgICBDT05URVhUIEhBTkRMRSBpbnB1dF9jb250ZXh0X2hhbmRsZSAgPSAwDQogICAgIE9D VEVUIFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAgICA9IHRva2VuIHNwZWNpZmllZCBpbiB0 aGUgS2V5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWVsZCBmcm9tIFRLRVkgUlIg KGZyb20gQWRkaXRpb25hbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjb3JkcyBz ZWN0aW9uIG9mIHRoZSBjbGllbnQncyBxdWVyeSkNCiAgVGhlIE9VVFBVVFMgcGFyYW1ldGVycyBy ZXR1cm5lZCBieSBHU1NfQWNjZXB0X3NlY19jb250ZXh0IGluY2x1ZGUNCiAgICAgSU5URUdFUiAg ICAgICAgbWFqb3Jfc3RhdHVzID0gR1NTX1NfQ09OVElOVUVfTkVFREVEDQogICAgIENPTlRFWFRf SEFORExFIG91dHB1dF9jb250ZXh0X2hhbmRsZSBjb250ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBT VFJJTkcgICBvdXRwdXRfdG9rZW4gb3V0cHV0X3Rva2VuDQoNCiAgU2VydmVyIHN0b3JlcyB0aGUg bWFwcGluZyBvZiB0aGUNCiAgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIuZXhhbXBsZS5j b20uIHRvIE9VVFBVVCBjb250ZXh0X2hhbmRsZQ0KICBpbiBpdHMgKGtleV9uYW1lLCBjb250ZXh0 X2hhbmRsZSkgbWFwcGluZyB0YWJsZS4NCg0KDQogIFYuIFNlcnZlciByZXNwb25kcyB0byB0aGUg VEtFWSBxdWVyeQ0KICBTaW5jZSB0aGUgbWFqb3Jfc3RhdHVzID0gR1NTX1NfQ09OVElOVUVfTkVF REVEIGluIHRoZSBsYXN0IHNlcnZlcidzDQogIGNhbGwgdG8gR1NTX0FjY2VwdF9zZWNfY29udGV4 dCwgdGhlIHNlcnZlciByZXNwb25kcyB0byB0aGUgVEtFWSBxdWVyeQ0KICBwbGFjaW5nIGluIHRo ZSBhbnN3ZXIgc2VjdGlvbiBhIFRLRVkgcmVjb3JkIGNvbnRhaW5pbmcgb3V0cHV0X3Rva2VuIGlu DQogIHRoZSBLZXkgRGF0YSBSREFUQSBmaWVsZC4gVGhlIGVycm9yIGZpZWxkIGluIHRoZSBUS0VZ IHJlY29yZCBpcyBzZXQgdG8NCiAgMC4gVGhlIFJDT0RFIGluIHRoZSBxdWVyeSByZXNwb25zZSBp cyBzZXQgdG8gTk9FUlJPUi4NCg0KDQogIFZJLiBDbGllbnQgcHJvY2Vzc2VzIHRva2VuIHJldHVy bmVkIGJ5IHNlcnZlcg0KICBXaGVuIHRoZSBjbGllbnQgcmVjZWl2ZXMgdGhlIFRLRVkgcXVlcnkg cmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyLCB0aGUNCiAgY2xpZW50IGNhbGxzIEdTU19Jbml0X3Nl Y19jb250ZXh0IHdpdGggdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIChOb3RlDQogIHRoYXQgc29t ZSBJTlBVVCBhbmQgT1VUUFVUIHBhcmFtZXRlcnMgbm90IGNyaXRpY2FsIGZvciB0aGlzIGFsZ29y aXRobQ0KICBhcmUgbm90IGRlc2NyaWJlZCBpbiB0aGlzIGV4YW1wbGUpDQogICAgIENPTlRFWFQg SEFORExFIGlucHV0X2NvbnRleHRfaGFuZGxlICA9IHRoZSBjb250ZXh0X2hhbmRsZSBzdG9yZWQN CiAgICAgICAgICBpbiB0aGUgY2xpZW50J3MgbWFwcGluZyB0YWJsZSBlbnRyeSAoRE5TQHNlcnZl ci5leGFtcGxlLmNvbS4sDQogICAgICAgICAgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIu ZXhhbXBsZS5jb20uLCBjb250ZXh0X2hhbmRsZSkNCiAgICAgSU5URVJOQUwgTkFNRSAgdGFyZ19u YW1lICAgICAgICAgICAgID0gIkROU0BzZXJ2ZXIuZXhhbXBsZS5jb20iDQogICAgIE9DVEVUIFNU UklORyAgIGlucHV0X3Rva2VuICAgICAgICAgICA9IHRva2VuIGZyb20gS2V5IGZpZWxkIG9mIFRL RVkNCiAgICAgICAgICByZWNvcmQgZnJvbSB0aGUgQW5zd2VyIHNlY3Rpb24gb2YgdGhlIHNlcnZl cidzIHJlc3BvbnNlDQogICAgIEJPT0xFQU4gICAgICAgIHJlcGxheV9kZXRfcmVxX2ZsYWcgICA9 IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0dWFsX3JlcV9mbGFnICAgICAgID0gVFJVRQ0K DQoNCg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQogIFRoZSBPVVRQVVRT IHBhcmFtZXRlcnMgcmV0dXJuZWQgYnkgR1NTX0luaXRfc2VjX2NvbnRleHQgaW5jbHVkZQ0KICAg ICBJTlRFR0VSICAgICAgICBtYWpvcl9zdGF0dXMgPSBHU1NfU19DT01QTEVURQ0KICAgICBDT05U RVhUIEhBTkRMRSBvdXRwdXRfY29udGV4dF9oYW5kbGUgPSBjb250ZXh0X2hhbmRsZQ0KICAgICBP Q1RFVCBTVFJJTkcgICBvdXRwdXRfdG9rZW4gPSBvdXRwdXRfdG9rZW4NCiAgICAgQk9PTEVBTiAg ICAgICAgcmVwbGF5X2RldF9zdGF0ZSA9IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0dWFs X3N0YXRlID0gVFJVRQ0KDQogIFNpbmNlIHRoZSBtYWpvcl9zdGF0dXMgaXMgc2V0IHRvIEdTU19T X0NPTVBMRVRFIHRoZSBjbGllbnQgc2lkZQ0KICBzZWN1cml0eSBjb250ZXh0IGlzIGVzdGFibGlz aGVkLCBidXQgc2luY2UgdGhlIG91dHB1dF90b2tlbiBpcyBub3QNCiAgTlVMTCBjbGllbnQgTVVT VCBzZW5kIGEgVEtFWSBxdWVyeSB0byB0aGUgc2VydmVyIGFzIGRlc2NyaWJlZCBiZWxvdy4NCg0K DQogIFZJSS4gQ2xpZW50IHNlbmRzIGEgcXVlcnkgd2l0aCBRVFlQRSA9IFRLRVkgdG8gc2VydmVy DQogIENsaWVudCBzZW5kcyB0byB0aGUgc2VydmVyIGEgVEtFWSBxdWVyeSBmb3IgdGhlDQogIDc4 OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUuY29tLiBuYW1lLiBRdWVyeSBjb250 YWlucyBhIFRLRVkNCiAgcmVjb3JkIGluIGl0cyBBZGRpdGlvbmFsIHJlY29yZHMgc2VjdGlvbiB3 aXRoIHRoZSBmb2xsb3dpbmcgZmllbGRzDQogIChOb3RlIHRoYXQgc29tZSBJTlBVVCBhbmQgT1VU UFVUIHBhcmFtZXRlcnMgbm90IGNyaXRpY2FsIHRvIHRoaXMNCiAgYWxnb3JpdGhtIGFyZSBub3Qg ZGVzY3JpYmVkIGluIHRoaXMgZXhhbXBsZSkNCiAgICAgTkFNRSA9IDc4OS5jbGllbnQuZXhhbXBs ZS5jb20uc2VydmVyLmV4YW1wbGUuY29tLg0KICAgICBSREFUQQ0KICAgICAgICBBbGdvcml0aG0g TmFtZSAgICAgID0gZ3NzLXRzaWcNCiAgICAgICAgTW9kZSAgICAgICAgICAgICAgICA9IDMgKEdT Uy1BUEkgbmVnb3RpYXRpb24gLSBwZXIgW1JGQzI5MzBdKQ0KICAgICAgICBLZXkgU2l6ZSAgICAg ICAgICAgID0gc2l6ZSBvZiBvdXRwdXRfdG9rZW4gaW4gb2N0ZXRzDQogICAgICAgIEtleSBEYXRh ICAgICAgICAgICAgPSBvdXRwdXRfdG9rZW4NCg0KDQogIFZJSUkuIFNlcnZlciByZWNlaXZlcyBh IFRLRVkgcXVlcnkNCiAgV2hlbiB0aGUgc2VydmVyIHJlY2VpdmVzIGEgVEtFWSBxdWVyeSwgdGhl IHNlcnZlciB2ZXJpZmllcyB0aGF0IE1vZGUNCiAgYW5kIEFsZ29yaXRobSBmaWVsZHMgaW4gdGhl IFRLRVkgcmVjb3JkIGluIHRoZSBBZGRpdGlvbmFsIHJlY29yZHMNCiAgc2VjdGlvbiBvZiB0aGUg cXVlcnkgYXJlIHNldCB0byAzIGFuZCBnc3MtdHNpZywgcmVwZWN0aXZlbHkuIEl0DQogIGZpbmRz IHRoYXQgdGhlIGtleV9uYW1lIDc4OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUu Y29tLiBpcw0KICBsaXN0ZWQgaW4gaXRzIChrZXlfbmFtZSwgY29udGV4dF9oYW5kbGUpIG1hcHBp bmcgdGFibGUuDQoNCg0KICBJWC4gU2VydmVyIGNhbGxzIEdTU19BY2NlcHRfc2VjX2NvbnRleHQN CiAgVG8gY29udGludWUgc2VjdXJpdHkgY29udGV4dCBuZWdvdGlhdGlvbiBzZXJ2ZXIgY2FsbHMN CiAgR1NTX0FjY2VwdF9zZWNfY29udGV4dCB3aXRoIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyAo Tm90ZSB0aGF0IHNvbWUNCiAgSU5QVVQgYW5kIE9VVFBVVCBwYXJhbWV0ZXJzIG5vdCBjcml0aWNh bCBmb3IgdGhpcyBhbGdvcml0aG0gYXJlIG5vdA0KICBkZXNjcmliZWQgaW4gdGhpcyBleGFtcGxl KQ0KICAgSU5QVVRTDQogICAgIENPTlRFWFQgSEFORExFIGlucHV0X2NvbnRleHRfaGFuZGxlICA9 IGNvbnRleHRfaGFuZGxlIGZyb20gdGhlDQogICAgICAgICAgICg3ODkuY2xpZW50LmV4YW1wbGUu Y29tLnNlcnZlci5leGFtcGxlLmNvbS4sIGNvbnRleHRfaGFuZGxlKQ0KICAgICAgICAgICBlbnRy eSBpbiB0aGUgc2VydmVyJ3MgbWFwcGluZyB0YWJsZQ0KICAgICBPQ1RFVCBTVFJJTkcgICBpbnB1 dF90b2tlbiAgICAgICAgICAgPSB0b2tlbiBzcGVjaWZpZWQgaW4gdGhlIEtleQ0KICAgICAgICAg ICBmaWVsZCBvZiBUS0VZIFJSIChmcm9tIEFkZGl0aW9uYWwgcmVjb3JkcyBTZWN0aW9uIG9mDQog ICAgICAgICAgIHRoZSBjbGllbnQncyBxdWVyeSkNCg0KICBUaGUgT1VUUFVUUyBwYXJhbWV0ZXJz IHJldHVybmVkIGJ5IEdTU19BY2NlcHRfc2VjX2NvbnRleHQgaW5jbHVkZQ0KICAgICBJTlRFR0VS ICAgICAgICBtYWpvcl9zdGF0dXMgPSBHU1NfU19DT01QTEVURQ0KICAgICBDT05URVhUX0hBTkRM RSBvdXRwdXRfY29udGV4dF9oYW5kbGUgPSBjb250ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBTVFJJ TkcgICBvdXRwdXRfdG9rZW4gPSBOVUxMDQoNCg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDQpJTlRFUk5F VC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAy MSwgMjAwMg0KDQogIFNpbmNlIG1ham9yX3N0YXR1cyA9IEdTU19TX0NPTVBMRVRFLCB0aGUgc2Vj dXJpdHkgY29udGV4dCBvbiB0aGUNCiAgc2VydmVyIHNpZGUgaXMgZXN0YWJsaXNoZWQsIGJ1dCB0 aGUgc2VydmVyIHN0aWxsIG5lZWRzIHRvIHJlc3BvbmQgdG8NCiAgdGhlIGNsaWVudCdzIFRLRVkg cXVlcnksIGFzIGRlc2NyaWJlZCBiZWxvdy4gVGhlIHNlY3VyaXR5IGNvbnRleHQNCiAgc3RhdGUg aXMgYWR2YW5jZWQgdG8gQ29udGV4dCBFc3RhYmxpc2hlZC4NCg0KDQogIFguIFNlcnZlciByZXNw b25kcyB0byB0aGUgVEtFWSBxdWVyeQ0KICBTaW5jZSB0aGUgbWFqb3Jfc3RhdHVzID0gR1NTX1Nf Q09NUExFVEUgaW4gdGhlIGxhc3Qgc2VydmVyJ3MgY2FsbCB0bw0KICBHU1NfQWNjZXB0X3NlY19j b250ZXh0IGFuZCB0aGUgb3V0cHV0X3Rva2VuIGlzIE5VTEwsIHRoZSBzZXJ2ZXINCiAgcmVzcG9u ZHMgdG8gdGhlIFRLRVkgcXVlcnkgcGxhY2luZyBpbiB0aGUgYW5zd2VyIHNlY3Rpb24gYSBUS0VZ IHJlY29yZA0KICB0aGF0IHdhcyBzZW50IGJ5IHRoZSBjbGllbnQgaW4gdGhlIEFkZGl0aW9uYWwg cmVjb3JkcyBzZWN0aW9uIG9mIHRoZQ0KICBjbGllbnQncyBsYXRlc3QgVEtFWSBxdWVyeS4NCg0K DQogIFhJLiBDbGllbnQgcHJvY2Vzc2VzIHRva2VuIHJldHVybmVkIGJ5IHNlcnZlcg0KICBDbGll bnQgcmVjZWl2ZXMgdGhlIFRLRVkgcXVlcnkgcmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyLiBTaW5j ZSB0aGUNCiAgbWFqb3Jfc3RhdHVzIHdhcyBHU1NfU19DT01QTEVURSBpbiB0aGUgbGFzdCBjbGll bnQncyBjYWxsIHRvDQogIEdTU19Jbml0X3NlY19jb250ZXh0LCB0aGUgY2xpZW50IHZlcmlmaWVz IHRoYXQgdGhlIHNlcnZlcidzIHJlc3BvbnNlDQogIG1hdGNoZXMgdGhlIHJlcXVpcmVkIGZvcm1h dC4NCg0KICBTaW5jZSB0aGUgT1VUUFVUUyBwYXJhbWV0ZXIgbWFqb3Jfc3RhdHVzID0gR1NTX1Nf Q09NUExFVEUsIHJlc3BvbnNlDQogIGZvcm1hdCBpcyB2YWxpZGF0ZWQsIHNlY3VyaXR5IG5lZ290 aWF0aW9uIGlzIGNvbXBsZXRlIGFuZCB0aGUNCiAgc2VjdXJpdHkgY29udGV4dCBzdGF0ZSBpcyBh ZHZhbmNlZCB0byBDb250ZXh0IEVzdGFibGlzaGVkLiBUaGVzZQ0KICBjbGllbnQgYW5kIHNlcnZl ciB3aWxsIHVzZSB0aGUgZXN0YWJsaXNoZWQgc2VjdXJpdHkgY29udGV4dCB0byBzaWduDQogIGFu ZCB2YWxpZGF0ZSB0aGUgc2lnbmF0dXJlcyB3aGVuIHRoZXkgZXhjaGFuZ2UgcGFja2V0cyB3aXRo IGVhY2gNCiAgb3RoZXIgdW50aWwgdGhlIGNvbnRleHQgZXhwaXJlcy4NCg0KDQo3LiBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHByb3RvY29sIGZv ciBETlMgc2VjdXJpdHkgdXNpbmcgR1NTLUFQSS4NClRoZSBzZWN1cml0eSBwcm92aWRlZCBieSB0 aGlzIHByb3RvY29sIGlzIG9ubHkgYXMgZWZmZWN0aXZlIGFzIHRoZQ0Kc2VjdXJpdHkgcHJvdmlk ZWQgYnkgdGhlIHVuZGVybHlpbmcgR1NTIG1lY2hhbmlzbXMuDQoNCkFsbCB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgZnJvbSBSRkMyODQ1LCBSRkMyOTMwIGFuZCBSRkMgMjc0Mw0KYXBwbHkg dG8gdGhlIHByb3RvY29sIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCjguIElBTkEg Q29uc2lkZXJhdGlvbnMNCg0KVGhlIGF1dGhvcnMgcmVxdWVzdCB0aGF0IHRoZSBJQU5BIHJlc2Vy dmUgdGhlIFRTSUcgQWxnb3JpdGhtIG5hbWUNCmdzcy10c2lnIGZvciB0aGUgdXNlIGluIHRoZSBB bGdvcml0aG0gZmllbGRzIG9mIFRLRVkgYW5kIFRTSUcgcmVzb3VyY2UNCnJlY29yZHMuIFRoaXMg QWxnb3JpdGhtIG5hbWUgcmVmZXJzIHRvIHRoZSBhbGdvcml0aG0gZGVzY3JpYmVkIGluIHRoaXMN CmRvY3VtZW50LiBUaGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSB0aGlzIG5hbWUgcmVnaXN0ZXJlZCB3 aXRoIElBTkEgaXMNCnNwZWNpZmllZCBpbiBSRkMgMjg0NS4NCg0KDQo5LiBDb25mb3JtYW5jZQ0K DQpUaGUgR1NTIEFQSSB1c2luZyBTUE5FR08gW1JGQzI0NzhdIHByb3ZpZGVzIG1heGltdW0gZmxl eGliaWxpdHkgdG8NCmNob29zZSB0aGUgdW5kZXJseWluZyBzZWN1cml0eSBtZWNoYW5pc21zIHRo YXQgZW5hYmxlcyBzZWN1cml0eSBjb250ZXh0DQpuZWdvdGlhdGlvbi4gR1NTIEFQSSB1c2luZyBT UE5FR08gW1JGQzI0NzhdIGVuYWJsZXMgY2xpZW50IGFuZCBzZXJ2ZXIgdG8NCg0KDQpFeHBpcmVz IEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDE5XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAg ICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQpuZWdvdGlhdGUgYW5kIGNob29zZSBzdWNoIHVu ZGVybHlpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcyBvbiB0aGUgZmx5LiBUbw0Kc3VwcG9ydCBzdWNo IGZsZXhpYmlsaXR5LCBETlMgY2xpZW50cyBhbmQgc2VydmVycyBTSE9VTEQgc3BlY2lmeSBTUE5F R08NCm1lY2hfdHlwZSBpbiB0aGVpciBHU1MgQVBJIGNhbGxzLiBBdCB0aGUgc2FtZSB0aW1lLCBp biBvcmRlciB0bw0KZ3VhcmFudGVlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBETlMgY2xpZW50 cyBhbmQgc2VydmVycyB0aGF0IHN1cHBvcnQNCkdTUy1UU0lHIGl0IGlzIHJlcXVpcmVkIHRoYXQN Cg0KLSBETlMgc2VydmVycyBzcGVjaWZ5IFNQTkVHTyBtZWNoX3R5cGUNCi0gR1NTIEFQSXMgY2Fs bGVkIGJ5IEROUyBjbGllbnQgc3VwcG9ydCBLZXJiZXJvcyB2NQ0KLSBHU1MgQVBJcyBjYWxsZWQg YnkgRE5TIHNlcnZlciBzdXBwb3J0IFNQTkVHTyBbUkZDMjQ3OF0gYW5kDQogIEtlcmJlcm9zIHY1 Lg0KDQpJbiBhZGRpdGlvbiB0byB0aGVzZSwgR1NTIEFQSXMgdXNlZCBieSBETlMgY2xpZW50IGFu ZCBzZXJ2ZXIgTUFZIGFsc28NCnN1cHBvcnQgb3RoZXIgdW5kZXJseWluZyBzZWN1cml0eSBtZWNo YW5pc21zLg0KDQoNCjEwLiBBY2tub3dsZWRnZW1lbnRzDQoNClRoZSBhdXRob3JzIG9mIHRoaXMg ZG9jdW1lbnQgd291bGQgbGlrZSB0byB0aGFuayB0aGUgZm9sbG93aW5nIHBlb3BsZQ0KZm9yIHRo ZWlyIGNvbnRyaWJ1dGlvbiB0byB0aGlzIHNwZWNpZmljYXRpb246ICBDaHVjayBDaGFuLCBNaWtl IFN3aWZ0LA0KUmFtIFZpc3dhbmF0aGFuLCBPbGFmdXIgR3VkbXVuZHNzb24sIERvbmFsZCBFLiBF YXN0bGFrZSAzcmQsIEVyaWsNCk5vcmRtYXJrIGFuZCBLZXZpbiBEdW5sYXAuDQoNCg0KMTEuIFJl ZmVyZW5jZXMNCg0KW1JGQzI3NDNdIEouIExpbm4sICJHZW5lcmljIFNlY3VyaXR5IFNlcnZpY2Ug QXBwbGljYXRpb24gUHJvZ3JhbQ0KICAgICAgICAgIEludGVyZmFjZSwgVmVyc2lvbiAyICwgVXBk YXRlIDEiLCBSRkMgMjc0MywgUlNBIExhYm9yYXRvcmllcywNCiAgICAgICAgICBKYW51YXJ5IDIw MDAuDQoNCltSRkMyODQ1XSBQLiBWaXhpZSwgTy4gR3VkbXVuZHNzb24sIEQuIEVhc3RsYWtlLCBC LiBXZWxsaW5ndG9uLA0KICAgICAgICAgICJTZWNyZXQgS2V5IFRyYW5zYWN0aW9uIEF1dGhlbnRp Y2F0aW9uIGZvciBETlMgKFRTSUcpIiwNCiAgICAgICAgICBSRkMgMjg0NSwgSVNDLCBOQUkgTGFi cywgTW90b3JvbGEsIE5vbWludW0sIE1heSwgMjAwMCwNCg0KW1JGQzI5MzBdIEQuIEVhc3RsYWtl IDNyZCwgIlNlY3JldCBLZXkgRXN0YWJsaXNobWVudCBmb3IgRE5TIChUS0VZIFJSKSIsDQogICAg ICAgICAgUkZDIDI5MzAsIE1vdG9yb2xhLCBTZXB0ZW1iZXIgMjAwMC4NCg0KW1JGQzI1MzVdIEQu IEVhc3RsYWtlIDNyZCwgIkRvbWFpbiBOYW1lIFN5c3RlbSBTZWN1cml0eSBFeHRlbnNpb25zLCIN CiAgICAgICAgICBSRkMgMjUzNSwgSUJNLCBNYXJjaCAxOTk5Lg0KDQpbUkZDMjEzN10gRC4gRWFz dGxha2UgM3JkLCAiU2VjdXJlIERvbWFpbiBOYW1lIFN5c3RlbSBEeW5hbWljIFVwZGF0ZSwiDQog ICAgICAgICAgUkZDIDIxMzcsIEN5YmVyQ2FzaCwgQXByaWwgMTk5Ny4NCg0KW1JGQzIxMTldIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoN CltSRkMxMDM0XSBNb2NrYXBldHJpcywgUC4sICJEb21haW4gTmFtZXMgLSBDb25jZXB0cyBhbmQg RmFjaWxpdGllcyIsDQogICAgICAgICAgU1REIDEzLCBSRkMgMTAzNCwgTm92ZW1iZXIgMTk4Ny4N Cg0KW1JGQzEwMzVdIE1vY2thcGV0cmlzLCBQLiwgIkRvbWFpbiBOYW1lcyAtIEltcGxlbWVudGF0 aW9uIGFuZA0KICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBTVEQgMTMsIFJGQyAxMDM0LCBOb3Zl bWJlciAxOTg3Lg0KDQpbUkZDMTk2NF0gTGlubiwgSi4sICJUaGUgS2VyYmVyb3MgVmVyc2lvbiA1 IEdTUy1BUEkgTWVjaGFuaXNtIiwNCiAgICAgICAgICBSRkMgMTk2NCwgT3BlblZpc2lvbiBUZWNo bm9sb2dpZXMsIEp1bmUgMTk5Ni4NCg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMF0NCg0KSU5URVJORVQtRFJBRlQg ICAgICAgICAgICAgICAgICAgR1NTLVRTSUcgICAgICAgICAgICAgICAgIEp1bHkgMjEsIDIwMDIN Cg0KW1JGQzIwMjVdIEFkYW1zLCBDLiwgIlRoZSBTaW1wbGUgUHVibGljLUtleSBHU1MtQVBJIE1l Y2hhbmlzbSAoU1BLTSkiLA0KICAgICAgICAgIFJGQyAyMDI1LCBCZWxsLU5vcnRoZXJuIFJlc2Vh cmNoLCBPY3RvYmVyIDE5OTYuDQoNCltSRkMyNDc4XSBCYWl6ZSwgRS4sIFBpbmthcywgRC4sICJU aGUgU2ltcGxlIGFuZCBQcm90ZWN0ZWQgR1NTLUFQSQ0KICAgICAgICAgIE5lZ290aWF0aW9uIE1l Y2hhbmlzbSIsIFJGQyAyNDc4LCBCdWxsLCBEZWNlbWJlciAxOTk4Lg0KDQpbSVNPMTE1NzhdIklu Zm9ybWF0aW9uIHRlY2hub2xvZ3kiLCAiT3BlbiBTeXN0ZW1zDQogICAgICAgICAgSW50ZXJjb25u ZWN0aW9uIiwgIlJlbW90ZSBQcm9jZWR1cmUgQ2FsbCIsDQogICAgICAgICAgSVNPL0lFQyAxMTU3 ODoxOTk2LCBodHRwOi8vd3d3Lmlzby5jaC9jYXRlL2QyMjI5Lmh0bWwuDQoNCg0KDQoNCjEyLiBB dXRob3IncyBBZGRyZXNzZXMNCg0KU3R1YXJ0IEt3YW4gICAgICAgICAgICAgICAgICAgICAgICAg UHJhZXJpdCBHYXJnDQpNaWNyb3NvZnQgQ29ycG9yYXRpb24gICAgICAgICAgICAgICBNaWNyb3Nv ZnQgQ29ycG9yYXRpb24NCk9uZSBNaWNyb3NvZnQgV2F5ICAgICAgICAgICAgICAgICAgIE9uZSBN aWNyb3NvZnQgV2F5DQpSZWRtb25kLCBXQSAgOTgwNTIgICAgICAgICAgICAgICAgICBSZWRtb25k LCBXQSAgOTgwNTINClVTQSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVTQQ0Kc2t3 YW5AbWljcm9zb2Z0LmNvbSAgICAgICAgICAgICAgICAgcHJhZXJpdGdAbWljcm9zb2Z0LmNvbQ0K DQpKYW1lcyBHaWxyb3kgICAgICAgICAgICAgICAgICAgICAgICBMZXZvbiBFc2lib3YNCk1pY3Jv c29mdCBDb3Jwb3JhdGlvbiAgICAgICAgICAgICAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0KT25l IE1pY3Jvc29mdCBXYXkgICAgICAgICAgICAgICAgICAgT25lIE1pY3Jvc29mdCBXYXkNClJlZG1v bmQsIFdBICA5ODA1MiAgICAgICAgICAgICAgICAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KVVNBICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVVNBDQpqYW1lc2dAbWljcm9zb2Z0LmNvbSAg ICAgICAgICAgICAgICBsZXZvbmVAbWljcm9zb2Z0LmNvbQ0KDQoNClJhbmR5IEhhbGwgICAgICAg ICAgICAgICAgICAgICAgICAgIEplZmYgV2VzdGhlYWQNCkx1Y2VudCBUZWNobm9sb2dpZXMgICAg ICAgICAgICAgICAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0KNDAwIExhcHAgUm9hZCAgICAgICAg ICAgICAgICAgICAgICAgT25lIE1pY3Jvc29mdCBXYXkNCk1hbHZlcm4gUEEgMTkzNTUgICAgICAg ICAgICAgICAgICAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KVVNBICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVVNBDQpyYW5keWhhbGxAbHVjZW50LmNvbSAgICAgICAgICAgICAgICBqd2Vz dGhAbWljcm9zb2Z0LmNvbQ0KDQoNCg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMV0NCg== ------_=_NextPart_001_01C23191.EBC52B46-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 13:30:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19530 for ; Mon, 22 Jul 2002 13:30:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WgkX-000IRC-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 10:13:33 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17WgkS-000IQw-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 10:13:28 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g6MH95il011131; Mon, 22 Jul 2002 10:09:06 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 10:14:59 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B38@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Masataka Ohta'" , Brad Knowles Cc: Mark.Andrews@isc.org, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se Subject: RE: dnssec discussion today at noon Date: Mon, 22 Jul 2002 10:14:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > This assumes perfect implementation of the cryptography and the > > manner in which cryptography is used (and the whole rest of the > > system). Schneier teaches us that this is a highly unlikely > > situation to occur anywhere. > > I'm teching you Schneier (whoever he is) is wrong, then. I am not too sure that Bruce made quite the point originally stated, and if he did make it one should take a look at some other statements Bruce has been known to state before necessarily taking his word as gospel. In fact I would suspect that a more accurate representation of Bruce's position would be 'think about the protocol, don't depend on dogma, including dogma that you might find attributed to me.' Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 13:39:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20456 for ; Mon, 22 Jul 2002 13:39:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Wh1n-000Ikc-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 10:31:23 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17Wh1i-000IkM-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 10:31:18 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g6MHPuYl012001; Mon, 22 Jul 2002 10:25:56 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 10:32:53 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B39@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , Masataka Ohta Cc: edlewis@arin.net, namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se Subject: RE: dnssec discussion today at noon Date: Mon, 22 Jul 2002 10:32:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Public Key Cryptography is absolutely necessary for any > store-and-forward protocol. I disagree with your characterization. I don't think that we need to state that public key cryptography is essential in this particular instance (authenticating the actual DNS records), however it is certainly going to be helpful as a part of the solution. First off, let us consider the nature of actual DNS deployments, OK so you can have services chained of services off services etc. But is this a typical deployment, a necessary deployment? More importantly, examine those deployments and ask yourself where the trust boundaries are situated. If I relay a request through DNS server X then I probably do so because I trust that service in some sense. If I don't trust the service I am going to bypass it and chain directly to authoritative services that I do trust. While transitive authentication is a nice feature of digital signatures I do not see that feature as being essential in this particular case. I think that a situation in which a client has a secure connection to a DNS server which has a secure connection to certain often used DNS servers is a significant step forward in security from where we are. I certainly think that we are going to need public key cryptography to establish the framework of trust between the endpoints. But that does not mean that the current DNS architecture with a signature for every record is the only solution. We could use Kerberos with PK_INIT or some other key agreement protocol to establish the trust relationships from public keys. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 13:51:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21708 for ; Mon, 22 Jul 2002 13:51:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Wh74-000Iu7-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 10:36:50 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17Wh6z-000Its-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 10:36:45 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25157; Mon, 22 Jul 2002 13:36:44 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA29250; Mon, 22 Jul 2002 13:36:43 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA15920; Mon, 22 Jul 2002 13:36:42 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id NAA19195; Mon, 22 Jul 2002 13:36:41 -0400 (EDT) To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se Subject: Re: dnssec discussion today at noon References: <2F3EC696EAEED311BB2D009027C3F4F405869B39@vhqpostal.verisign.com> From: Derek Atkins Date: 22 Jul 2002 13:36:41 -0400 In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869B39@vhqpostal.verisign.com> Message-ID: Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Hallam-Baker, Phillip" writes: > More importantly, examine those deployments and ask yourself > where the trust boundaries are situated. If I relay a request > through DNS server X then I probably do so because I trust > that service in some sense. If I don't trust the service I > am going to bypass it and chain directly to authoritative > services that I do trust. You have clearly never been to an hotel where their Internet services intercept all DNS queries regardless of where you send the message... You cannot trust the infrastructure not to misbehave. In fact just the other day I was hit with a DNS re-write attack where my ISP (an airport) re-wrote all my DNS queries to something of their choosing (their goal being to force me to read their webpage, but it caused ssh to fail until I figured that out). > While transitive authentication is a nice feature of digital > signatures I do not see that feature as being essential in this > particular case. Well, sure, if you have TSIG and use that, then you dont necessarily need public key crypto to the end user. However then you are still trusting the path between your TSIG peer and the authoritative server. > I think that a situation in which a client has a secure > connection to a DNS server which has a secure connection to > certain often used DNS servers is a significant step forward > in security from where we are. In fact, ANY secure connection is better than where we are... Using TSIG would be better than where we are. However I run a local caching nameserver on my laptop, so TSIG doesn't help me, as my resolver and "trusted nameserver" co-exist. I still need DNSSEC. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 14:34:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25957 for ; Mon, 22 Jul 2002 14:34:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WhnE-000K0v-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 11:20:24 -0700 Received: from [2001:418:1::10] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17Whn9-000K0f-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 11:20:19 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17Whn9-0007gQ-00; Mon, 22 Jul 2002 11:20:19 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Derek Atkins Cc: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se Subject: Re: dnssec discussion today at noon References: <2F3EC696EAEED311BB2D009027C3F4F405869B39@vhqpostal.verisign.com> Message-Id: Date: Mon, 22 Jul 2002 11:20:19 -0700 X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > You cannot trust the infrastructure not to misbehave. In fact just > the other day I was hit with a DNS re-write attack where my ISP (an > airport) re-wrote all my DNS queries to something of their choosing > (their goal being to force me to read their webpage, but it caused ssh > to fail until I figured that out). my fave was the one where i got layer three wireless fine, it spoofed everything, and all my spooled email dissapeared into a dns-spoofed smtp black hole. bye bye email. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 15:22:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00239 for ; Mon, 22 Jul 2002 15:22:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WiZp-000LF1-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 12:10:37 -0700 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 17WiZk-000LEP-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 12:10:32 -0700 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 12:10:28 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Jul 2002 12:10:27 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 22 Jul 2002 12:10:28 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 12:10:27 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 22 Jul 2002 12:09:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Mon, 22 Jul 2002 12:09:35 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013A9CB1@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIrOuNxH05SWoTDSsiYL3IM7qXS0wGVnuUQAAhdl5A= From: "Levon Esibov" To: , "Erik Nordmark" X-OriginalArrivalTime: 22 Jul 2002 19:09:35.0710 (UTC) FILETIME=[519017E0:01C231B3] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA00239 > -----Original Message----- > From: Levon Esibov > Sent: Monday, July 22, 2002 8:11 AM > To: 'Erik Nordmark'; rfc-editor@rfc-editor.org > Cc: rhall@quadritek.com; bmanning@ISI.EDU; mayer@gis.net; iesg- > secretary@ietf.org; rfc-editor@ISI.EDU; iab@ISI.EDU; > namedroppers@ops.ietf.org > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard > > Kevin Dunlap (who discovered this issue) and authors of the draft > continued investigation and determined that GSS-TSIG draft requires minor > modification to not contradict RFC 2845. The essence of the modification > is to not sign GSS-TSIG server's response in response to not-signed-query > sent by GSS-TSIG client. This modification makes GSS-TSIG compliant with > RFC 2845's requirement "The server MUST not generate a signed response to > an unsigned request" without jeopardizing security of GSS-TSIG algorithm. > > I attach the updated version of the draft (-06) that resolves this last > issue. Sections modified to resolve this issue are 3.1.3.1, 3.1.3.2, 4.1.3 > and 6. Please let us know if you find any problems with this modification. > If you have any feedback, please respond by the end of day Wednesday, July > 24, 2002. I'd like to submit the updated draft on Thursday. > [Levon Esibov] Olafur brought to my attention that in order to enable interoperability between the old clients and new servers we may need to introduce new "Algorithm Name". This will allow clients to request new behavior when they negotiate security context with servers that support both old and new GSS-TSIG behavior. Such servers will be able to decide whether to include or not include TSIG record in its response to client's TKEY query. If new client sends a TKEY query with new "Algorithm Name" to an old server, then server will not recognize the new name and client may need to restart negotiation of the security context using the old "Algorithm Name". An alternate suggestion to resolve the issue is to update Section 4.2 of RFC 2845 (TSIG). Namely, I propose to extend the statement "The server MUST not generate a signed response to an unsigned request." as follows: "The server MUST not generate a signed response to an unsigned request, except in case of response to client's unsigned TKEY query if secret key is established on server side after server processed client's query. Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of an individual secret key establishment algorithm." Allowing response to unsigned TKEY query to be signed enables client-recipient of such message to determine whether the secret key is established on the server's side, thus preventing signing of messages that are going to fail. Please respond with your feedback on which solution you prefer. Thanks, Levon. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 16:32:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06468 for ; Mon, 22 Jul 2002 16:32:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Wjff-000Mzf-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 13:20:43 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17Wjfb-000MzS-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 13:20:39 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g6MKGPil007438; Mon, 22 Jul 2002 13:16:25 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 13:22:20 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D1CB2B1@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Derek Atkins , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org, dnsop@cafax.se, dnssec@cafax.se Subject: RE: dnssec discussion today at noon Date: Mon, 22 Jul 2002 13:22:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > You have clearly never been to an hotel where their Internet services > intercept all DNS queries regardless of where you send the message... > You cannot trust the infrastructure not to misbehave. Answer, I tend not to pay $10 per night just to surf the Internet from a hotel room and when I have I have been using a VPN which encrypts all the trafic. Question, what do you want the infrastructure to do in this situation? I believe that what a secure DNS infrastructure should do is inform you that you are subject to a DNS MiM attack. If you are going to use secure DNS then you probably want to use IPSEC to protect you trafic from hotel rooms and the like. If the institution blocks IPSEC then you should probably apply Moscow rules and not use the Internet at all. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 17:14:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09938 for ; Mon, 22 Jul 2002 17:14:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WkIm-000ODA-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 14:01:08 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17WkIi-000OCq-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 14:01:04 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3D9591902 for ; Mon, 22 Jul 2002 17:00:51 -0400 (EDT) Date: Mon, 22 Jul 2002 17:00:51 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013A9CB1@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> References: <211DE638FE1F094E96E3042DDF531CF9013A9CB1@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigorymae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020722210051.3D9591902@thrintun.hactrn.net> X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 22 Jul 2002 12:09:35 -0700, Levon Esibov wrote: > > Please respond with your feedback on which solution you prefer. Well, if you're going to phrase it that way.... Other things being equal, I'd prefer a third option that you didn't list: fix the GSS-TSIG RFC-to-be and punt on backwards compatability with clients that implemented from the now-known-to-be-broken GSS-TSIG I-D. In theory, anybody who ships product code based on an I-D deserves what they get if the protocol changes out from under them. If we're going to bend over backwards trying to help such folks out, it'd be good if somebody could first explain why this is worth doing, perhaps in terms of how widely used the I-D-based code is and how seriously those users would be harmed if we ignored the issue. In other words: bug-compatibility has costs, so it'd be nice to know whether the problem is serious enough to be worth paying those costs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 22 17:54:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13458 for ; Mon, 22 Jul 2002 17:54:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WkoU-000PHl-00 for namedroppers-data@psg.com; Mon, 22 Jul 2002 14:33:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17WkoQ-000PHX-00 for namedroppers@ops.ietf.org; Mon, 22 Jul 2002 14:33:50 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17WkoP-000GgW-00; Mon, 22 Jul 2002 14:33:50 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard References: <211DE638FE1F094E96E3042DDF531CF9013A9CB1@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> <20020722210051.3D9591902@thrintun.hactrn.net> Message-Id: Date: Mon, 22 Jul 2002 14:33:50 -0700 X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'd prefer a third option that you didn't list: fix the GSS-TSIG > RFC-to-be and punt on backwards compatability with clients that > implemented from the now-known-to-be-broken GSS-TSIG I-D. this seems like the normal plan, yes? there is a doc/spec bug. we fix it. that's our normal job, yes? randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 23 07:19:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06131 for ; Tue, 23 Jul 2002 07:19:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WxBU-000Abp-00 for namedroppers-data@psg.com; Tue, 23 Jul 2002 03:46:28 -0700 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.36 #1) id 17WxBM-000AXb-00 for namedroppers@ops.ietf.org; Tue, 23 Jul 2002 03:46:21 -0700 Received: from localhost ([3ffe:501:4819:2000:8168:6a65:dc2b:48e]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6NAiCA49847; Tue, 23 Jul 2002 19:44:13 +0900 (JST) Date: Tue, 23 Jul 2002 19:44:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brad Knowles Cc: Mohsen.Souissi@nic.fr, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr Subject: Re: RFC 1886 Interop Tests & Results In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <20020714213532.84B6E4B22@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 29 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,CHARSET_FARAWAY_HEADERS version=2.30 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Mon, 15 Jul 2002 01:10:44 +0200, >>>>> Brad Knowles said: >> the co-existence of ip6.int and ip6.arpa tree will require us to: >> query ip6.arpa; >> if (no record) >> query ip6.int; >> for backward compatibility. was it taken into account, or did you >> test just "ip6.arpa" lookups? > I checked the source code for BIND 9.2.1, and IIRC it checks > ip6.int first and then ip6.arpa second. This allows us to stand up > ip6.arpa whenever, and then once that is set, we can tear down > ip6.int. What exactly do you mean by BIND 9.2.1? 1. the resolver library under lib/bind 2. the resolver routine in lwresd 3. both 1 and 2 4. others In my understanding (I've quickly checked the code again, too), both 1 and 2 only tries ip6.arpa with bitstring labels. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 23 07:59:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06920 for ; Tue, 23 Jul 2002 07:59:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17WyAA-000K24-00 for namedroppers-data@psg.com; Tue, 23 Jul 2002 04:49:10 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17WyA4-000JyD-00 for namedroppers@ops.ietf.org; Tue, 23 Jul 2002 04:49:04 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6N7mT23038043 for ; Tue, 23 Jul 2002 07:48:29 GMT Received: from [208.58.216.89] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id HAA03566; Tue, 23 Jul 2002 07:48:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 23 Jul 2002 07:48:37 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Summary of DNSSEC gathering at IETF 54 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=4.1 required=5.0 tests=OPT_IN,RCVD_IN_OSIRUSOFT_COM version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Meeting of Folks Interested in Furthering DNSSEC, July 16, 2002 (This message appears on the DNSOP and DNSEXT WG lists separately.) The context of this meeting is that DNSSEC is awakening from a period of general inactivity as a result of needing at least one implementation of the DS RR. Using fully qualified human names (FQHN), affiliation's can be inferred: David Conrad DS code is now in ISC's BIND 9.3-snapshots One workshop has already been held to test what's there Opt-In code is -at-least- close to being in a snapshot Olaf Kolkman RIPE wants to roll DNSSEC into the in-addr tree Developing tools as needed Wants to hear ideas on what is wanted But there's no guarantee that the tools will appear (resource const'ts) Training program being developed to train folks in DNSSEC Russ Mundy ds.tislabs.com is a DS-enabled place for testing dstest@tislabs.com - mailing list Dan Massey planning/running a DS testbed within ISI activites developing tools NLnetLabs-proxy (Olaf and Jaap Akerhuis) planning on running a shadow of .nl as a secured registry ramping up activity towards late August Jakob Schlyter & Patrik Faltstrom different activities, among them an effort to look at legal aspects want to get .se secured (soon? next year?) Mohsen Souissi getting .fr (AFNIC) into DNSSEC, interest in IPv6 angle Marcos Sanz feasibility study for .de restart of work now that DS is here (a common theme) Bill Manning experimenting with signing the upper level zones (mil, gov, more) root keying issues Scott Rose redo NIST studies done pre-DS test, internal (to gov) workshops APRICOT/APNIC - looking into continuation/expansion of DNS(SEC) training Others "soon" to be playing: JP registry, RIR's (APNIC/ARIN/RIPE, also as above) At the end of the discussion, there was a proposal put forward that various operators design/sketch out/implement the kind of key handling that best suits them - as opposed to trying to gather to define "the one true way" to do this. Before IETF55 (Nov 2002 in Atlanta) there may be a workshop to compare the result of the efforts. Results of this workshop will be reported to the relevant WG's during the IETF55 meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 23 12:34:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21945 for ; Tue, 23 Jul 2002 12:34:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17X2JM-0004fC-00 for namedroppers-data@psg.com; Tue, 23 Jul 2002 09:14:56 -0700 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 17X2JH-0004et-00 for namedroppers@ops.ietf.org; Tue, 23 Jul 2002 09:14:51 -0700 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:14:51 -0700 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Jul 2002 09:14:50 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 23 Jul 2002 09:14:50 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:14:50 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 23 Jul 2002 09:14:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Tue, 23 Jul 2002 09:14:09 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013A9CBA@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIxxFsY3eU/reV0RYiJDzOSGkVGjQAnFU/g From: "Levon Esibov" To: "Rob Austein" , X-OriginalArrivalTime: 23 Jul 2002 16:14:10.0018 (UTC) FILETIME=[FA2CB420:01C23263] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA21945 Hi Rob, please see my comments below. Thanks, Levon. > -----Original Message----- > From: Rob Austein [mailto:sra+namedroppers@hactrn.net] > Sent: Monday, July 22, 2002 2:01 PM > To: namedroppers@ops.ietf.org > Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard > > At Mon, 22 Jul 2002 12:09:35 -0700, Levon Esibov wrote: > > > > Please respond with your feedback on which solution you prefer. > > Well, if you're going to phrase it that way.... Other things being > equal, I'd prefer a third option that you didn't list: fix the > GSS-TSIG RFC-to-be and punt on backwards compatability with clients > that implemented from the now-known-to-be-broken GSS-TSIG I-D. > > In theory, anybody who ships product code based on an I-D deserves > what they get if the protocol changes out from under them. If we're > going to bend over backwards trying to help such folks out, it'd be > good if somebody could first explain why this is worth doing, perhaps > in terms of how widely used the I-D-based code is and how seriously > those users would be harmed if we ignored the issue. [Levon Esibov] I-D based code is widely deployed. Namely it is included in Windows 2000 Professional and Windows XP Professional, all versions of Windows 2000 Server and Windows.Net 2003 Server, Lucent DNS Service 3.1 and VitalQIP 6.0. > > In other words: bug-compatibility has costs, so it'd be nice to know > whether the problem is serious enough to be worth paying those costs. [Levon Esibov] Just to clarify, my proposal to update Section 4.2 of RFC 2845 (TSIG) addresses wider issue than enabling backward compatibility (enabling backward compat is just a side-effect of the proposed modification). Namely my proposed modification removes unnecessary restriction to use TSIG to sign server's response to un-signed TKEY query in case if secret key is established on the server side before it is established on the client side. For the record: here is my proposal to update Section 4.2 of RFC 2845 (TSIG): Replace: "The server MUST not generate a signed response to an unsigned request." With: "The server MUST not generate a signed response to an unsigned request, except in case of response to client's unsigned TKEY query if secret key is established on server side after server processed client's query. Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of an individual secret key establishment algorithm." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 23 13:46:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26034 for ; Tue, 23 Jul 2002 13:46:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17X3Zr-0008Iy-00 for namedroppers-data@psg.com; Tue, 23 Jul 2002 10:36:03 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17X3Zk-0008Il-00 for namedroppers@ops.ietf.org; Tue, 23 Jul 2002 10:35:56 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 66D2F1902 for ; Tue, 23 Jul 2002 13:35:55 -0400 (EDT) Date: Tue, 23 Jul 2002 13:35:55 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013A9CBA@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> References: <211DE638FE1F094E96E3042DDF531CF9013A9CBA@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigorymae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020723173555.66D2F1902@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 23 Jul 2002 09:14:09 -0700, Levon Esibov wrote: > > I-D based code is widely deployed. Namely it is included in Windows 2000 > Professional and Windows XP Professional, all versions of Windows 2000 > Server and Windows.Net 2003 Server, Lucent DNS Service 3.1 and VitalQIP > 6.0. Ok, it's deployed. Which leaves the other half of the question: how badly will lack of backwards compatability harm the users? In case it's not clear: there's a lot of stuff out there that's deployed but not used (in any operating system, I'm not picking on Windows here), so the fact that code has shipped doesn't automatically imply a need for backwards compatability. What will this break, and why is the correct solution not just for the vendors to ship patches? > Just to clarify, my proposal to update Section 4.2 of RFC 2845 (TSIG) > addresses wider issue than enabling backward compatibility (enabling > backward compat is just a side-effect of the proposed modification). > Namely my proposed modification removes unnecessary restriction to use > TSIG to sign server's response to un-signed TKEY query in case if secret > key is established on the server side before it is established on the > client side. Why is it that everybody who suggests adding additional complexity to DNS these days phrases it as removing unnecessary restrictions? :)/2 I don't have a serious problem with your proposed change per se, but (a) others who've been tracking TSIG and GSS-TSIG more closely might, and (b) I'm not (yet) convinced of the need to change RFC 2845. Thanks.... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 10:08:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17938 for ; Wed, 24 Jul 2002 10:08:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XKxA-00005D-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 05:09:16 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17XKx4-00004z-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 05:09:10 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02112; Wed, 24 Jul 2002 08:08:06 -0400 (EDT) Message-Id: <200207241208.IAA02112@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-obsolete-iquery-04.txt Date: Wed, 24 Jul 2002 08:08:05 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Obsoleting IQUERY Author(s) : D. Lawrence Filename : draft-ietf-dnsext-obsolete-iquery-04.txt Pages : 4 Date : 23-Jul-02 The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using PTR queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation and updates RFC 1035 to declare it entirely obsolete. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-obsolete-iquery-04.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-obsolete-iquery-04.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: <20020723145458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-obsolete-iquery-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-obsolete-iquery-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020723145458.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 10:17:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18314 for ; Wed, 24 Jul 2002 10:17:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XMQj-0005jI-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 06:43:53 -0700 Received: from [2001:418:1::39] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17XMQe-0005j6-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 06:43:48 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17XMQe-000Oc4-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 06:43:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 24 Jul 2002 11:44:56 +0200 (MEST) From: Erik Guttman To: zeroconf@merit.edu, namedroppers@ops.ietf.org Subject: ZEROCONF and multicast name resolution X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Folks, The appropriate place to discuss these matters is on the DNSEXT WG mailing list. I am cross posting this message to the ZEROCONF WG list only in order to end the thread which we do not have the charter to resolve and redirect discussion to the forum which does. Keith Moore and various interlocutors have been discussing multicast name resolution on the ZEROCONF WG mailing list. I will not summarize that discussion, but I believe the below captures most of the major points. If I fail to do justice to your particular concerns, please expand. Multicast-Based Name Resolution ------------------------------- Multicast-based name resolution has been a goal of the ZEROCONF WG since it was chartered. The work item, to create a standards track protocol, has been taken on by the DNSEXT WG. This effort has been troubled, again because of disagreements about the functional requirements, but also because of unease from many involved in DNS standardization at the IETF. The requirements expressed in ZEROCONF WG documents were either not clear, or they were not meet with agreement in the DNSEXT WG. I believe the goals for multicast name resolution arise from the following observations. - Peer to peer naming protocols exist today, and have for a long time (NetBIOS and AppleTalk). - It is possible to use these protocols to resolve names without the use of DNS. - NetBIOS and AppleTalk names can be *the same* as host names in the DNS. - Some hosts *ALREADY* use alternative naming mechanisms to resolve names when DNS is not available (NIS, NetBIOS, AppleTalk, others). As has been brought out on the list, this is common practice and in no way incorrect with respect to the resolver APIs. - There is no IETF standard way to provide this function, over IP. - It is desirable to retire NetBIOS and AppleTalk for many reasons but without a functionally equivalent IETF standard solution, this is not possible. The ZEROCONF WG has attempted to articulate the requirements for an IETF standard to allow this name to address (and reverse) resolution in environments without DNS support. There are numerous areas where we run into differences of opinion. - What does it mean for hosts to respond to fully qualified domain names which DNS would normally respond to? Should multicast name resolution use the same namespace as DNS? Some have held that we need a special 'local' namespace, while others believe that a host should be able to respond to requests for its 'own' name. - What we really want is applications that continue to function even when DNS fails or is not present: http://foo will succeed if there is a host which can respond to a name resolution request for 'foo' using the non-DNS multicast name resoultion protocol. Some seem to hold this is not an appropriate objective. - Should multicast name resolution be possible whether even when DNS *is* available? This would prevent 'local' name resolution from ever failing and ensure it always returns consistent information. Many have asserted that DNS has to be used, exclusively, for domain name resolution if it is available as this is the current and expected behavior. That these issues have not been clearly resolved has left work on LLMNR (draft-ietf-dnsext-mdns-10.txt) in an uncertain state. Let's try to resolve the issues and can come up with a solution which will serve the many users of local, unadministered networks. Thanks and regards, 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. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 10:19:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18407 for ; Wed, 24 Jul 2002 10:19:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XMYG-0006DE-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 06:51:40 -0700 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.36 #1) id 17XMYB-0006D2-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 06:51:36 -0700 Received: from localhost ([3ffe:501:4819:2000:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6ODoIA67007; Wed, 24 Jul 2002 22:50:18 +0900 (JST) Date: Wed, 24 Jul 2002 22:50:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: <20020721222414.1D7F64B22@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20020721222414.1D7F64B22@coconut.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 20 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,CHARSET_FARAWAY_HEADERS version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Mon, 22 Jul 2002 07:24:14 +0900, >>>>> itojun@iijlab.net said: >>> i may be asking a stupid question, but where do you get that private >>> key from? for instance, if a node responds with "www.ietf.org", >>> we could get a public key for www.ietf.org by KEY RR query, but >>> not the private key (it's on ietf.org authoritative server, and >>> is not accessible from outside). >> Presumably the device answering the ICMP request is the one named, >> and therefore knows the private key associated with its name. > no, the device answering ICMPv6 request is not named. ??? I'm a bit confused. Are you saying that we can *not always* assume the device answering ICMPv6 request runs a name server? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 10:23:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18618 for ; Wed, 24 Jul 2002 10:23:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XMdt-0006Zt-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 06:57:29 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17XMdo-0006Zh-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 06:57:24 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 62A954B24; Wed, 24 Jul 2002 22:56:04 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Wed, 24 Jul 2002 22:50:16 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Wed, 24 Jul 2002 22:56:04 +0900 Message-Id: <20020724135604.62A954B24@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> no, the device answering ICMPv6 request is not named. >??? I'm a bit confused. Are you saying that we can *not always* >assume the device answering ICMPv6 request runs a name server? the thread of email assumes the following diagram. itojun > client resolver ---------> named -------> the target > DNS query NI query > client resolver <--------- named <------- the target > DNS response NI response -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 10:37:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19402 for ; Wed, 24 Jul 2002 10:37:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XN9Z-0008pz-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 07:30:13 -0700 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.36 #1) id 17XN9Q-0008md-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 07:30:05 -0700 Received: from localhost ([3ffe:501:4819:2000:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6OESmA67631; Wed, 24 Jul 2002 23:28:48 +0900 (JST) Date: Wed, 24 Jul 2002 23:28:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: <20020724135604.62A954B24@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20020724135604.62A954B24@coconut.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 42 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,CHARSET_FARAWAY_HEADERS version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Wed, 24 Jul 2002 22:56:04 +0900, >>>>> itojun@iijlab.net said: >>> no, the device answering ICMPv6 request is not named. >> ??? I'm a bit confused. Are you saying that we can *not always* >> assume the device answering ICMPv6 request runs a name server? > the thread of email assumes the following diagram. >> client resolver ---------> named -------> the target >> DNS query NI query >> client resolver <--------- named <------- the target >> DNS response NI response Hmm, I read the Ted's message >>>>> On Sat, 20 Jul 2002 16:53:10 -0700, >>>>> Ted Lemon said: > What do people think of signing the ICMP packet with the private key that > corresponds to a KEY RR that is attached to the name mentioned in the ICMP > packet? to mean the diagram like this: NI query nodeinfo client ------------------> the target with named (authorizing the name) and private key <------------------ NI response signed by the private key (BTW: I understood the very original idea of this thread meant the diagram you showed.) But if I just misunderstood, please ignore me. I was just checking. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 10:44:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19739 for ; Wed, 24 Jul 2002 10:44:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XNFJ-0009Fi-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 07:36:09 -0700 Received: from [2001:418:1::39] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17XNFC-0009FR-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 07:36:02 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17XNFB-0001Cb-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 07:36:02 -0700 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 24 Jul 2002 16:17:53 +0200 (MEST) From: Erik Guttman To: namedroppers@ops.ietf.org, zeroconf@merit.edu cc: Erik Guttman , aboba@internaut.com Subject: Re: ZEROCONF and multicast name resolution X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Wed, 24 Jul 2002, Erik Guttman wrote: > That these issues have not been clearly resolved has left > work on LLMNR (draft-ietf-dnsext-mdns-10.txt) in an uncertain state. Oops. I have not been to the past two IETF meetings and have been relying on the mailing list to stay informed. I gather it was decided at the Yokohama DNSEXT meeting to take the next revision of the mdns draft to WG last call. So the doc isn't in an 'uncertain state' after all, except maybe now after my untimely comments :-/ 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. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 10:46:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19836 for ; Wed, 24 Jul 2002 10:46:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XNH6-0009QS-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 07:38:00 -0700 Received: from [2001:418:1::39] (helo=rip.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17XNGy-0009Pb-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 07:37:52 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17XNGy-0001Hf-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 07:37:52 -0700 Message-ID: <002301c2331d$77f81390$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <20020724135604.62A954B24@coconut.itojun.org> From: "Jeroen Massar" To: , "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" Cc: , Subject: RE: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Date: Wed, 24 Jul 2002 16:21:53 +0200 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] itojun@iijlab.net wrote: > >> no, the device answering ICMPv6 request is not named. > >??? I'm a bit confused. Are you saying that we can *not always* > >assume the device answering ICMPv6 request runs a name server? > > the thread of email assumes the following diagram. > > itojun > > > > client resolver ---------> named -------> the target > > DNS query NI query > > client resolver <--------- named <------- the target > > DNS response NI response As I was toying around with Opportunistic Encryption it shaded another light on this subject. Could there be a query type which requests the KEY (just like the DNS RR) of a host. This would allow for example FreeS/WAN and Racoon and other IPSec implementations to request the public KEY from the host itself in a standardized way. The proposed DNS<->nodeinfo could then also provide this information over DNS. Ofcourse one has no 100% ensurance that the replied KEY is valid at all. Greets, Jeroen -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 12:24:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22954 for ; Wed, 24 Jul 2002 12:24:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XOk8-000G09-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 09:12:04 -0700 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 17XOk3-000Fzw-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 09:11:59 -0700 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 09:11:58 -0700 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 09:11:58 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 09:11:58 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 09:11:58 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 24 Jul 2002 09:11:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Wed, 24 Jul 2002 09:11:22 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013A9CC8@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIycB+gnaZvyS65R4aE3zZWmCZMSwAuOhUQ From: "Levon Esibov" To: "Rob Austein" , X-OriginalArrivalTime: 24 Jul 2002 16:11:22.0701 (UTC) FILETIME=[C0DBE7D0:01C2332C] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA22954 Below, please. > -----Original Message----- > From: Rob Austein [mailto:sra+namedroppers@hactrn.net] > Sent: Tuesday, July 23, 2002 10:36 AM > To: namedroppers@ops.ietf.org > Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard > > At Tue, 23 Jul 2002 09:14:09 -0700, Levon Esibov wrote: > > > > I-D based code is widely deployed. Namely it is included in Windows 2000 > > Professional and Windows XP Professional, all versions of Windows 2000 > > Server and Windows.Net 2003 Server, Lucent DNS Service 3.1 and VitalQIP > > 6.0. > > Ok, it's deployed. Which leaves the other half of the question: how > badly will lack of backwards compatability harm the users? > > In case it's not clear: there's a lot of stuff out there that's > deployed but not used (in any operating system, I'm not picking on > Windows here), so the fact that code has shipped doesn't automatically > imply a need for backwards compatability. What will this break, and [Levon Esibov] GSS-TSIG algorithm enables secure dynamic DNS updates. Latter is widely used/deployed in the intranets of large number of organizations. If we break backward compatibility then new DNS servers will not be able to support the secure dynamic DNS updates based on the GSS-TSIG mechanism. > why is the correct solution not just for the vendors to ship patches? [Levon Esibov] Of course this is a legit possibility. But in my opinion such approach puts too large burden on users (read administrators) since administrator of each organization using secure dynamic update will have to deploy such patch on all (or at least on a large number) of the clients in the enterprise. Taking into account the number of organizations affected, I think we should consider alternate solution. > > > Just to clarify, my proposal to update Section 4.2 of RFC 2845 (TSIG) > > addresses wider issue than enabling backward compatibility (enabling > > backward compat is just a side-effect of the proposed modification). > > Namely my proposed modification removes unnecessary restriction to use > > TSIG to sign server's response to un-signed TKEY query in case if secret > > key is established on the server side before it is established on the > > client side. > > Why is it that everybody who suggests adding additional complexity to > DNS these days phrases it as removing unnecessary restrictions? :)/2 > > I don't have a serious problem with your proposed change per se, but > (a) others who've been tracking TSIG and GSS-TSIG more closely might, > and (b) I'm not (yet) convinced of the need to change RFC 2845. [Levon Esibov] Any TSIG experts care to comment whether they see any problems with proposed modification? Thanks, Levon. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 12:42:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23434 for ; Wed, 24 Jul 2002 12:42:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XP5H-000HkM-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 09:33:55 -0700 Received: from cpe-24-221-172-100.ca.sprintbbd.net ([24.221.172.100] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17XP5C-000Hj8-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 09:33:50 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g6OGXZ712754; Wed, 24 Jul 2002 09:33:35 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 24 Jul 2002 09:33:34 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Levon Esibov cc: Rob Austein , Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013A9CC8@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.5 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD,RCVD_IN_RFCI version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 24 Jul 2002, Levon Esibov wrote: > Any TSIG experts care to comment whether they see any problems with > proposed modification? It causes many clients to break, since a client may treat a signed response to an unsigned query as an error, and at least one common implementation does. 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. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 12:47:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23557 for ; Wed, 24 Jul 2002 12:47:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XPAO-000I9f-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 09:39:12 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17XPAJ-000I9K-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 09:39:07 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25795; Wed, 24 Jul 2002 12:38:54 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA11605; Wed, 24 Jul 2002 12:38:48 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20830; Wed, 24 Jul 2002 12:38:46 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA24375; Wed, 24 Jul 2002 12:38:47 -0400 (EDT) To: "Jeroen Massar" Cc: , "'JINMEI Tatuya / =?iso-8859-1?q?=90=5F-=BE?='=?iso-8859-1?q?B=8D=C6?='" , , From: Derek Atkins Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt References: <002301c2331d$77f81390$534510ac@cyan> Date: 24 Jul 2002 12:38:47 -0400 In-Reply-To: <002301c2331d$77f81390$534510ac@cyan> Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Jeroen Massar" writes: > As I was toying around with Opportunistic Encryption it shaded another > light on this subject. > Could there be a query type which requests the KEY (just like the DNS > RR) of a host. Yes, it's called IKE. It's already part of the IPsec protocol suite. > This would allow for example FreeS/WAN and Racoon and other IPSec > implementations to request > the public KEY from the host itself in a standardized way. The proposed > DNS<->nodeinfo could > then also provide this information over DNS. Ofcourse one has no 100% > ensurance that the replied > KEY is valid at all. This is exactly why it isn't done, and why you want keys in DNSSEC. > Greets, > Jeroen -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 12:47:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23570 for ; Wed, 24 Jul 2002 12:47:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XPCV-000IL1-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 09:41:23 -0700 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 17XPCP-000IKU-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 09:41:17 -0700 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 09:41:16 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 09:41:16 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 09:41:16 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 09:41:16 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 24 Jul 2002 09:40:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Wed, 24 Jul 2002 09:40:39 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013A9CC9@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIzL8foPsXuhs7ARLOWt+V5YuJtjAAAE3uA From: "Levon Esibov" To: "Brian Wellington" Cc: "Rob Austein" , X-OriginalArrivalTime: 24 Jul 2002 16:40:39.0492 (UTC) FILETIME=[D7FCF040:01C23330] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA23570 > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Wednesday, July 24, 2002 9:34 AM > To: Levon Esibov > Cc: Rob Austein; namedroppers@ops.ietf.org > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard > > On Wed, 24 Jul 2002, Levon Esibov wrote: > > > Any TSIG experts care to comment whether they see any problems with > > proposed modification? > > It causes many clients to break, since a client may treat a signed > response to an unsigned query as an error, and at least one common > implementation does. [Levon Esibov] Hi Brian, Please note that my proposal doesn't blindly allow any server to start signing responses to unsigned queries. My proposal reads: "The server MUST not generate a signed response to an unsigned request, except in case of response to client's unsigned TKEY query if secret key is established on server side after server processed client's query. Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of an individual secret key establishment algorithm." Please note that statement "Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of an individual secret key establishment algorithm." prevents breaking existing clients unless their individual secret key establishment algorithm allows such signing. Does that address your concern? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 13:19:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24880 for ; Wed, 24 Jul 2002 13:19:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XPTV-000JoT-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 09:58:57 -0700 Received: from cpe-24-221-172-100.ca.sprintbbd.net ([24.221.172.100] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17XPTP-000Jn5-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 09:58:51 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g6OGwfW12777; Wed, 24 Jul 2002 09:58:41 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 24 Jul 2002 09:58:41 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Levon Esibov cc: Rob Austein , Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013A9CC9@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.5 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD,RCVD_IN_RFCI version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 24 Jul 2002, Levon Esibov wrote: > > -----Original Message----- > > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > > Sent: Wednesday, July 24, 2002 9:34 AM > > To: Levon Esibov > > Cc: Rob Austein; namedroppers@ops.ietf.org > > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > > Proposed Standard > > > > On Wed, 24 Jul 2002, Levon Esibov wrote: > > > > > Any TSIG experts care to comment whether they see any problems with > > > proposed modification? > > > > It causes many clients to break, since a client may treat a signed > > response to an unsigned query as an error, and at least one common > > implementation does. > > [Levon Esibov] > Hi Brian, > Please note that my proposal doesn't blindly allow any server to start > signing responses to unsigned queries. My proposal reads: > "The server MUST not generate a signed response to an unsigned request, > except in case of response to client's unsigned TKEY query if secret key > is established on server side after server processed client's query. > Signing responses to unsigned TKEY queries MUST be explicitly specified > in the description of an individual secret key establishment algorithm." I don't think this is sufficient. Section 4.6 of RFC 2845 implies (it only states it when a TSIG is expected) that the TSIG check should be the first thing done, which would mean that the client wouldn't know that it was the last message of a secret key exchange. > Please note that statement "Signing responses to unsigned TKEY queries > MUST be explicitly specified in the description of an individual secret > key establishment algorithm." prevents breaking existing clients unless > their individual secret key establishment algorithm allows such signing. > > Does that address your concern? It still means that a compliant RFC 2845 client will need to deviate from strict compliance to deal with broken servers. I still think the bahavior should be disallowed in TSIG, and GSS-TSIG should mention that this might be necessary for backwards compatibility, but should not be the default behavior of any new implementations. 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. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 13:29:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25106 for ; Wed, 24 Jul 2002 13:29:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XPpR-000LZp-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 10:21:37 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17XPpL-000LZS-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 10:21:31 -0700 Received: from green.bisbee.fugue.com (az-ben-pm3-2-17.ppp.theriver.com [206.25.50.17]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6OHLDd02003; Wed, 24 Jul 2002 17:21:14 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6OHLefD001533; Wed, 24 Jul 2002 10:21:40 -0700 (MST) Date: Wed, 24 Jul 2002 10:21:39 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > to mean the diagram like this: > > NI query > nodeinfo client ------------------> the target > with named (authorizing the name) > and private key > <------------------ > NI response signed > by the private key > > (BTW: I understood the very original idea of this thread meant the > diagram you showed.) No, I was talking about securing the NI query, but not assuming that a "name server" would do that work, except in the sense that by definition anything that responds to a query for a name with a name could be called a name server. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 13:43:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25544 for ; Wed, 24 Jul 2002 13:43:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XQ1n-000MfB-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 10:34:23 -0700 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #1) id 17XQ1i-000Meu-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 10:34:18 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 10:34:17 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 10:34:17 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 10:34:17 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 10:34:16 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 24 Jul 2002 10:33:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Wed, 24 Jul 2002 10:33:37 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013A9CCA@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIzM0rrXi4IcA6zSbaKzooXhYjOIwAAxMiA From: "Levon Esibov" To: "Brian Wellington" Cc: "Rob Austein" , X-OriginalArrivalTime: 24 Jul 2002 17:33:38.0086 (UTC) FILETIME=[3E93E460:01C23338] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA25544 > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Wednesday, July 24, 2002 9:59 AM > To: Levon Esibov > Cc: Rob Austein; namedroppers@ops.ietf.org > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard > > On Wed, 24 Jul 2002, Levon Esibov wrote: > > > > -----Original Message----- > > > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > > > Sent: Wednesday, July 24, 2002 9:34 AM > > > To: Levon Esibov > > > Cc: Rob Austein; namedroppers@ops.ietf.org > > > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > > > Proposed Standard > > > > > > On Wed, 24 Jul 2002, Levon Esibov wrote: > > > > > > > Any TSIG experts care to comment whether they see any problems with > > > > proposed modification? > > > > > > It causes many clients to break, since a client may treat a signed > > > response to an unsigned query as an error, and at least one common > > > implementation does. > > > > [Levon Esibov] > > Hi Brian, > > Please note that my proposal doesn't blindly allow any server to start > > signing responses to unsigned queries. My proposal reads: > > "The server MUST not generate a signed response to an unsigned request, > > except in case of response to client's unsigned TKEY query if secret key > > is established on server side after server processed client's query. > > Signing responses to unsigned TKEY queries MUST be explicitly specified > > in the description of an individual secret key establishment algorithm." > > I don't think this is sufficient. Section 4.6 of RFC 2845 implies (it > only states it when a TSIG is expected) that the TSIG check should be the > first thing done, which would mean that the client wouldn't know that it > was the last message of a secret key exchange. [Levon Esibov] Section 4.6 of RFC 2845 reads "When a client receives a response from a server and expects to see a TSIG, it first checks if the TSIG RR is present in the response." There are two possible scenarios in secret key exchange: 1. when client knows that coming response must be the last message 2. when client doesn't know that coming response must be the last message Individual secret key establishment algorithm may require that in case 1. client first checks if the TSIG RR is present in the response. In case 2. client indeed doesn't know that the message it received is the last one and therefore doesn't check if the TSIG RR is present in the response when it receives the response, but this behavior does NOT violate Section 4.6 of RFC 2845 because it says "and expects to see a TSIG", while client in case 2. does not expect to see TSIG. > > > Please note that statement "Signing responses to unsigned TKEY queries > > MUST be explicitly specified in the description of an individual secret > > key establishment algorithm." prevents breaking existing clients unless > > their individual secret key establishment algorithm allows such signing. > > > > Does that address your concern? > > It still means that a compliant RFC 2845 client will need to deviate from > strict compliance to deal with broken servers. [Levon Esibov] I think my explanation above demonstrates that client will not deviate from strict compliance w/ RFC 2845. Agree? > I still think the bahavior > should be disallowed in TSIG, and GSS-TSIG should mention that > this might be necessary for backwards compatibility, but should > not be the default behavior of any new implementations. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 14:03:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25987 for ; Wed, 24 Jul 2002 14:03:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XQLM-000OHX-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 10:54:36 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17XQLH-000OHI-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 10:54:31 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g6OHsNN13360; Wed, 24 Jul 2002 10:54:24 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 24 Jul 2002 10:54:21 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Levon Esibov cc: Rob Austein , Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013A9CCA@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 24 Jul 2002, Levon Esibov wrote: > > > > On Wed, 24 Jul 2002, Levon Esibov wrote: > > > > > > > > > Any TSIG experts care to comment whether they see any problems > with > > > > > proposed modification? > > > > > > > > It causes many clients to break, since a client may treat a signed > > > > response to an unsigned query as an error, and at least one common > > > > implementation does. > > > > > > [Levon Esibov] > > > Hi Brian, > > > Please note that my proposal doesn't blindly allow any server to > start > > > signing responses to unsigned queries. My proposal reads: > > > "The server MUST not generate a signed response to an unsigned > request, > > > except in case of response to client's unsigned TKEY query if secret > key > > > is established on server side after server processed client's query. > > > Signing responses to unsigned TKEY queries MUST be explicitly > specified > > > in the description of an individual secret key establishment > algorithm." > > > > I don't think this is sufficient. Section 4.6 of RFC 2845 implies (it > > only states it when a TSIG is expected) that the TSIG check should be > the > > first thing done, which would mean that the client wouldn't know that > it > > was the last message of a secret key exchange. > > [Levon Esibov] > Section 4.6 of RFC 2845 reads "When a client receives a response from a > server and expects to see a TSIG, it first checks if the TSIG RR is > present in the response." > > There are two possible scenarios in secret key exchange: > 1. when client knows that coming response must be the last message > 2. when client doesn't know that coming response must be the last > message > > Individual secret key establishment algorithm may require that in case > 1. client first checks if the TSIG RR is present in the response. > > In case 2. client indeed doesn't know that the message it received is > the last one and therefore doesn't check if the TSIG RR is present in > the response when it receives the response, but this behavior does NOT > violate Section 4.6 of RFC 2845 because it says "and expects to see a > TSIG", while client in case 2. does not expect to see TSIG. You're assuming a particular implementation. Another implementation might see and attempt to verify the TSIG before doing anything else. This isn't too important, though, so I won't bother arguing. > > > Please note that statement "Signing responses to unsigned TKEY queries > > > MUST be explicitly specified in the description of an individual secret > > > key establishment algorithm." prevents breaking existing clients unless > > > their individual secret key establishment algorithm allows such signing. > > > > > > Does that address your concern? > > > > It still means that a compliant RFC 2845 client will need to deviate from > > strict compliance to deal with broken servers. > [Levon Esibov] > I think my explanation above demonstrates that client will not deviate > from strict compliance w/ RFC 2845. > Agree? It requires that a server have special case code to allow deviation from strict compliance in a special case. Is that any better? > > I still think the bahavior > > should be disallowed in TSIG, and GSS-TSIG should mention that > > this might be necessary for backwards compatibility, but should > > not be the default behavior of any new implementations. Do you have any opinion on this? 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. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 14:18:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26384 for ; Wed, 24 Jul 2002 14:18:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XQX9-000PHD-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 11:06:47 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17XQWz-000PGv-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 11:06:37 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g6OI5Jt15284; Wed, 24 Jul 2002 14:05:19 -0400 (EDT) Message-Id: <200207241805.g6OI5Jt15284@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman cc: zeroconf@merit.edu, namedroppers@ops.ietf.org Subject: Re: ZEROCONF and multicast name resolution In-reply-to: (Your message of "Wed, 24 Jul 2002 11:44:56 +0200.") Date: Wed, 24 Jul 2002 14:05:18 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik, thanks for the summary; to me it seems a reasonable reflection of the recent zeroconf discussion. I'll go look at the namedroppers archive and see if I can glean what that group has said about this. my concerns can briefly be summarized as follows: - in general, changing existing APIs will break applications. one way to do this is to change an existing name lookup function in such a way that the names no longer have the same semantics as before, or it treats names as valid that were formally invalid, or by introducing new error conditions that need to be distinguished from the old ones. such changes seem a likely result of changing an existing name lookup API to also handle name lookup in an ad hoc network. - local names can be useful, but they should be easily distinguished from fully qualified dns names, both by humans and by applications. the de facto standard way to do this is to omit dots from local names. if that convention is also adopted for ad hoc networks then fewer applications will break. - if you provide another way to look up DNS names (as opposed to local names), it needs to have results that are consistent with DNS. just as one example, it needs to never return "no such name" or "no records" when in fact it cannot tell whether the name exists or whether there are any such records. this is somewhat difficult to do in a disconnected network. - a name lookup protocol that works on an ad hoc network is useful. but expecting a name lookup protocol to also be usable for service discovery creates some conflicts that are not easily resolved. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 14:28:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26709 for ; Wed, 24 Jul 2002 14:28:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XQkg-0000XH-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 11:20:46 -0700 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 17XQka-0000Wm-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 11:20:40 -0700 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 11:20:38 -0700 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 11:20:38 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 24 Jul 2002 11:20:38 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 11:20:38 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 24 Jul 2002 11:19:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Wed, 24 Jul 2002 11:19:57 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013A9CCB@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIzOw6Y6wTd6DuATyi5gbh7u34y8QAAPYBQ From: "Levon Esibov" To: "Brian Wellington" Cc: "Rob Austein" , X-OriginalArrivalTime: 24 Jul 2002 18:19:57.0783 (UTC) FILETIME=[B767FE70:01C2333E] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA26709 > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Wednesday, July 24, 2002 10:54 AM > To: Levon Esibov > Cc: Rob Austein; namedroppers@ops.ietf.org > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard > > > [Levon Esibov] > > I think my explanation above demonstrates that client will not deviate > > from strict compliance w/ RFC 2845. > > Agree? > > It requires that a server have special case code to allow deviation from > strict compliance in a special case. Is that any better? [Levon Esibov] Frankly I don't see any negative impact of such server behavior. I'm also not sure why you refer to this as "special case code". Yes, I recommend specifying this "special case" server behavior in the RFC 2845, but as far as I understand it doesn't cause any "special case code" on the server side. It simply removes unnecessary restriction (/* I see Rob smiling... */) allowing implementations of secret key exchange algorithms to start using TSIG as soon as secret key is established. > > > > > I still think the bahavior > > > should be disallowed in TSIG, and GSS-TSIG should mention that > > > this might be necessary for backwards compatibility, but should > > > not be the default behavior of any new implementations. > > Do you have any opinion on this? [Levon Esibov] Yes, I prefer making modification to TSIG rather than prohibiting GSS-TSIG server to sign responses to unsigned TKEY queries for the following reasons: 1. Allowing response to unsigned TKEY query to be signed enables client-recipient of such message to determine whether the secret key is indeed established on the server's side. 2. Enabling GSS-TSIG servers to interoperate with old and new clients complicates server implementation. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 14:54:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27708 for ; Wed, 24 Jul 2002 14:54:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XR8i-0002dt-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 11:45:36 -0700 Received: from dhcp-167.wl.nominum.com ([128.177.195.167] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17XR8e-0002db-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 11:45:32 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g6OIjNi14124; Wed, 24 Jul 2002 11:45:23 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 24 Jul 2002 11:45:23 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Levon Esibov cc: Rob Austein , Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013A9CCB@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 24 Jul 2002, Levon Esibov wrote: > [Levon Esibov] > Frankly I don't see any negative impact of such server behavior. I'm > also not sure why you refer to this as "special case code". Yes, I > recommend specifying this "special case" server behavior in the RFC > 2845, but as far as I understand it doesn't cause any "special case > code" on the server side. It simply removes unnecessary restriction (/* > I see Rob smiling... */) allowing implementations of secret key exchange > algorithms to start using TSIG as soon as secret key is established. You're suggesting changing an existing (proposed) standard to allow backwards compatibility in a limited case with clients that implemented a fundamentally broken non-standard draft. Sure sounds like a special case to me. > > > > I still think the bahavior > > > > should be disallowed in TSIG, and GSS-TSIG should mention that > > > > this might be necessary for backwards compatibility, but should > > > > not be the default behavior of any new implementations. > > > > Do you have any opinion on this? > [Levon Esibov] > Yes, I prefer making modification to TSIG rather than prohibiting > GSS-TSIG server to sign responses to unsigned TKEY queries for the > following reasons: > 1. Allowing response to unsigned TKEY query to be signed enables > client-recipient of such message to determine whether the secret key is > indeed established on the server's side. Doesn't the verification of the GSSAPI token allow this too? > 2. Enabling GSS-TSIG servers to interoperate with old and new clients > complicates server implementation. Yes, but this is a GSS-TSIG issue, not a TSIG issue. TSIG works and is deployed. It shouldn't be changed to support old, broken applications. 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. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 15:21:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28852 for ; Wed, 24 Jul 2002 15:21:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XRV3-0004jh-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 12:08:41 -0700 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 17XRUy-0004jR-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 12:08:36 -0700 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 12:08:36 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 12:08:35 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 12:08:35 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 12:07:44 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 24 Jul 2002 12:07:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Wed, 24 Jul 2002 12:07:02 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013A9CCE@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIzQi7f5MdYMijrRTOslr8ML49x5wAAbdYw From: "Levon Esibov" To: "Brian Wellington" Cc: "Rob Austein" , X-OriginalArrivalTime: 24 Jul 2002 19:07:02.0686 (UTC) FILETIME=[4B2DFBE0:01C23345] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA28852 > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Wednesday, July 24, 2002 11:45 AM > To: Levon Esibov > Cc: Rob Austein; namedroppers@ops.ietf.org > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard > > > [Levon Esibov] > > Yes, I prefer making modification to TSIG rather than prohibiting > > GSS-TSIG server to sign responses to unsigned TKEY queries for the > > following reasons: > > 1. Allowing response to unsigned TKEY query to be signed enables > > client-recipient of such message to determine whether the secret key is > > indeed established on the server's side. > > Doesn't the verification of the GSSAPI token allow this too? [Levon Esibov] When secret key is established on the server side (major_status is GSS_S_COMPLETE) and output_token is NULL, then no token needs to be returned to the client and there is no further processing of any tokens on the client side. In this case TSIG returned in server's response would enable client to verify that secret key is indeed established on the server's side. > > > 2. Enabling GSS-TSIG servers to interoperate with old and new clients > > complicates server implementation. > > Yes, but this is a GSS-TSIG issue, not a TSIG issue. TSIG works and is > deployed. It shouldn't be changed to support old, broken applications. [Levon Esibov] Brian, I don't think this is the right approach. If modifying RFC 2845 (TSIG) is the "optimal" for customers and development community then we should do it. If namedroppers believe that modifying GSS-TSIG draft is more optimal - then I don't object it. But simply closing the door saying that "it's not TSIG issue" because it works and because it's a proposed standard is probably not the right approach, especially since suggested modification does NOT affect working implementations. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 15:22:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28914 for ; Wed, 24 Jul 2002 15:22:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XRd6-0005Wg-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 12:17:00 -0700 Received: from dhcp-167.wl.nominum.com ([128.177.195.167] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17XRcs-0005Rz-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 12:16:46 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g6OJGcX14429; Wed, 24 Jul 2002 12:16:38 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 24 Jul 2002 12:16:38 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Levon Esibov cc: Rob Austein , Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013A9CCE@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 24 Jul 2002, Levon Esibov wrote: > > -----Original Message----- > > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > > Sent: Wednesday, July 24, 2002 11:45 AM > > To: Levon Esibov > > Cc: Rob Austein; namedroppers@ops.ietf.org > > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > > Proposed Standard > > > > > > [Levon Esibov] > > > Yes, I prefer making modification to TSIG rather than prohibiting > > > GSS-TSIG server to sign responses to unsigned TKEY queries for the > > > following reasons: > > > 1. Allowing response to unsigned TKEY query to be signed enables > > > client-recipient of such message to determine whether the secret key > is > > > indeed established on the server's side. > > > > Doesn't the verification of the GSSAPI token allow this too? > > [Levon Esibov] > When secret key is established on the server side (major_status is > GSS_S_COMPLETE) and output_token is NULL, then no token needs to be > returned to the client and there is no further processing of any tokens > on the client side. In this case TSIG returned in server's response > would enable client to verify that secret key is indeed established on > the server's side. I wish someone had brought this up before. This is the first time I've seen anyone say that the TSIG in this message actually helps with the protocol's security. This really should have come up in April or May when the problem was first found. Maybe the right solution is to change GSS-TSIG so that this can be verified within the TKEY exchange, not relying on TSIG. > > > 2. Enabling GSS-TSIG servers to interoperate with old and new > clients > > > complicates server implementation. > > > > Yes, but this is a GSS-TSIG issue, not a TSIG issue. TSIG works and > is > > deployed. It shouldn't be changed to support old, broken > applications. > > [Levon Esibov] > Brian, > I don't think this is the right approach. If modifying RFC 2845 (TSIG) > is the "optimal" for customers and development community then we should > do it. If namedroppers believe that modifying GSS-TSIG draft is more > optimal - then I don't object it. But simply closing the door saying > that "it's not TSIG issue" because it works and because it's a proposed > standard is probably not the right approach, especially since suggested > modification does NOT affect working implementations. I've stated my opinion, but we'll see what other people have to say... 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. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 15:51:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29893 for ; Wed, 24 Jul 2002 15:51:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XS3l-0007z7-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 12:44:33 -0700 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 17XS3e-0007y3-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 12:44:26 -0700 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 12:44:25 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 12:44:25 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 12:44:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 12:44:24 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 24 Jul 2002 12:43:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Wed, 24 Jul 2002 12:43:41 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013A9CCF@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIzRoqq7jgUSEKVQd+PAIJ/kqr29AAATFNg From: "Levon Esibov" To: "Brian Wellington" Cc: "Rob Austein" , X-OriginalArrivalTime: 24 Jul 2002 19:43:41.0316 (UTC) FILETIME=[69AA4C40:01C2334A] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA29893 > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Wednesday, July 24, 2002 12:17 PM > To: Levon Esibov > Cc: Rob Austein; namedroppers@ops.ietf.org > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard > > On Wed, 24 Jul 2002, Levon Esibov wrote: > > > > -----Original Message----- > > > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > > > Sent: Wednesday, July 24, 2002 11:45 AM > > > To: Levon Esibov > > > Cc: Rob Austein; namedroppers@ops.ietf.org > > > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > > > Proposed Standard > > > > > > > > > [Levon Esibov] > > > > Yes, I prefer making modification to TSIG rather than prohibiting > > > > GSS-TSIG server to sign responses to unsigned TKEY queries for the > > > > following reasons: > > > > 1. Allowing response to unsigned TKEY query to be signed enables > > > > client-recipient of such message to determine whether the secret key > > is > > > > indeed established on the server's side. > > > > > > Doesn't the verification of the GSSAPI token allow this too? > > > > [Levon Esibov] > > When secret key is established on the server side (major_status is > > GSS_S_COMPLETE) and output_token is NULL, then no token needs to be > > returned to the client and there is no further processing of any tokens > > on the client side. In this case TSIG returned in server's response > > would enable client to verify that secret key is indeed established on > > the server's side. > > I wish someone had brought this up before. This is the first time I've > seen anyone say that the TSIG in this message actually helps with the > protocol's security. This really should have come up in April or May when > the problem was first found. > [Levon Esibov] Just to clarify, this is not a security issue. If secret key was not established on the server (while client believed it was) client will discover it when it tries to use the secret key for the first time, i.e. when client doesn't receive a properly signed response to its signed request. Ability of client to discover that secret key is not established on the server's side allows client to start a new secret key negotiation process earlier than later which may be useful in time-sensitive operations. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 16:17:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00958 for ; Wed, 24 Jul 2002 16:17:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XSRH-000ACv-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 13:08:51 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17XSRC-000ABZ-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 13:08:46 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 493BD28B6E; Wed, 24 Jul 2002 13:08:40 -0700 (PDT) From: Paul Vixie To: Brian Wellington Cc: Levon Esibov , Rob Austein , namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: Message from Brian Wellington of "Wed, 24 Jul 2002 12:16:38 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 24 Jul 2002 13:08:40 -0700 Message-Id: <20020724200840.493BD28B6E@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Maybe the right solution is to change GSS-TSIG so that this can be > verified within the TKEY exchange, not relying on TSIG. yes -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 16:20:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01077 for ; Wed, 24 Jul 2002 16:20:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XSJZ-0009UT-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 13:00:53 -0700 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #1) id 17XSJO-0009SG-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 13:00:42 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 13:00:40 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 13:00:40 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 13:00:10 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 13:00:09 -0700 Received: from WIN-MSG-06.wingroup.windeploy.ntdev.microsoft.com ([157.54.2.22]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 24 Jul 2002 12:59:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2334C.9C471D1F" Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Wed, 24 Jul 2002 12:59:25 -0700 Message-ID: <211DE638FE1F094E96E3042DDF531CF9013DCC30@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard thread-index: AcIzRoqq7jgUSEKVQd+PAIJ/kqr29AAA6e8Q From: "Levon Esibov" To: , "Brian Wellington" Cc: "Rob Austein" X-OriginalArrivalTime: 24 Jul 2002 19:59:25.0633 (UTC) FILETIME=[9C85A310:01C2334C] X-Spam-Status: No, hits=3.0 required=5.0 tests=DOUBLE_CAPSWORD,UPPERCASE_25_50 version=2.31 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2334C.9C471D1F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Wednesday, July 24, 2002 12:17 PM > To: Levon Esibov > Cc: Rob Austein; namedroppers@ops.ietf.org > Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to > Proposed Standard >=20 > > > > [Levon Esibov] > > Brian, > > I don't think this is the right approach. If modifying RFC 2845 (TSIG) > > is the "optimal" for customers and development community then we should > > do it. If namedroppers believe that modifying GSS-TSIG draft is more > > optimal - then I don't object it. But simply closing the door saying > > that "it's not TSIG issue" because it works and because it's a proposed > > standard is probably not the right approach, especially since suggested > > modification does NOT affect working implementations. >=20 > I've stated my opinion, but we'll see what other people have to say... >=20 > Brian [Levon Esibov] I absolutely agree, and encourage other members of the namedroppers to express their opinion. Below I summarize opinions/suggestions expressed so far to eliminate conflict between RFC 2845's (TSIG) requirement to not sign responses to unsigned queries and GSS-TSIG draft requiring servers to sign the responses to the TKEY queries as soon as the secret key is established. Here are the proposed solutions. 1. Modify RFC 2845 (TSIG) as follows: Replace: "The server MUST not generate a signed response to an unsigned request." With: "The server MUST not generate a signed response to an unsigned request, except in case of response to client's unsigned TKEY query if secret key is established on server side after server processed client's query. Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of an individual secret key establishment algorithm." 2. Update the GSS-TSIG draft to not require that Server signs with TSIG its last response to the client. 2a. In addition to 2 (above) mention in the updated GSS-TSIG draft that previous implementations of GSS-TSIG clients require TSIG to be present in the last server response and mention that implementers of the update GSS-TSIG protocol may consider including TSIG record on the server side to interop with old clients. Client may ignore TSIG record in response from old servers. (version of the draft reflecting these updates is attached) 2b. In addition to 2 (above) change the algorithm name in the GSS-TSIG protocol to allow new implementations to distinguish old implementations (using old algorithm name) from the new implementations. 2c. Do just what 2 above says. Do not even mention any previous implementations and let new implementations to not interop with widely deployed old implementations. Please let us know which solution you prefer. ------_=_NextPart_001_01C2334C.9C471D1F Content-Type: text/plain; name="draft-ietf-dnsext-gss-tsig-06.txt" Content-Description: draft-ietf-dnsext-gss-tsig-06.txt Content-Disposition: attachment; filename="draft-ietf-dnsext-gss-tsig-06.txt" Content-Transfer-Encoding: base64 SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFN0dWFydCBLd2FuDQo8ZHJhZnQtaWV0Zi1kbnNleHQtZ3NzLXRzaWctMDYudHh0PiAgICAg ICAgICAgICAgICAgICAgICAgICBQcmFlcml0IEdhcmcNCkp1bHkgMjEsIDIwMDIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEphbWVzIEdpbHJveQ0KRXhwaXJl cyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTGV2 b24gRXNpYm92DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEplZmYgV2VzdGhlYWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY3Jvc29mdCBDb3JwLg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSYW5keSBI YWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEx1Y2VudCBUZWNobm9sb2dpZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQogICAgICAgICAgICAgICAgIEdTUyBBbGdvcml0aG0gZm9y IFRTSUcgKEdTUy1UU0lHKQ0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KVGhpcyBkb2N1bWVu dCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZQ0Kd2l0aCBh bGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCkludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQpUYXNr IEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0 aGF0DQpvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBh cw0KSW50ZXJuZXQtRHJhZnRzLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50 cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeA0KbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlcg0KZG9jdW1lbnRzIGF0IGFueSB0aW1lLiAg SXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtDQpEcmFmdHMgYXMgcmVmZXJlbmNl IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzDQoid29yayBpbiBwcm9ncmVz cy4iDQoNClRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3Nl ZCBhdA0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoNClRoZSBs aXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQg YXQNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCg0KQWJzdHJhY3QNCg0KVGhl IFRTSUcgcHJvdG9jb2wgcHJvdmlkZXMgdHJhbnNhY3Rpb24gbGV2ZWwgYXV0aGVudGljYXRpb24g Zm9yIEROUy4NClRTSUcgaXMgZXh0ZW5zaWJsZSB0aHJvdWdoIHRoZSBkZWZpbml0aW9uIG9mIG5l dyBhbGdvcml0aG1zLiAgVGhpcw0KZG9jdW1lbnQgc3BlY2lmaWVzIGFuIGFsZ29yaXRobSBiYXNl ZCBvbiB0aGUgR2VuZXJpYyBTZWN1cml0eSBTZXJ2aWNlDQpBcHBsaWNhdGlvbiBQcm9ncmFtIElu dGVyZmFjZSAoR1NTLUFQSSkgKFJGQzI3NDMpLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRXhw aXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAxXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAg ICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCjE6IElu dHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjINCjI6IEFsZ29yaXRobSBPdmVydmlldy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjMNCiAgMi4xOiBHU1MgRGV0YWlscy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCjM6IENsaWVudCBQcm90b2Nv bCBEZXRhaWxzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQNCiAg My4xOiBOZWdvdGlhdGluZyBDb250ZXh0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjQNCiAgICAzLjEuMTogQ2FsbCBHU1NfSW5pdF9zZWNfY29udGV4dC4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICAzLjEuMjogU2VuZCBUS0VZIFF1ZXJ5IHRv IFNlcnZlci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYNCiAgICAzLjEuMzogUmVj ZWl2ZSBUS0VZIFF1ZXJ5LVJlc3BvbnNlIGZyb20gU2VydmVyLi4uLi4uLi4uLi4uLi4uLi4uLjcN CiAgMy4yOiBDb250ZXh0IEVzdGFibGlzaGVkLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMTANCiAgICAzLjIuMTogVGVybWluYXRpbmcgYSBDb250ZXh0Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCjQ6IFNlcnZlciBQcm90b2NvbCBEZXRhaWxz Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTANCiAgNC4xOiBOZWdv dGlhdGluZyBDb250ZXh0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTANCiAgICA0LjEuMTogUmVjZWl2ZSBUS0VZIFF1ZXJ5IGZyb20gQ2xpZW50Li4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMTANCiAgICA0LjEuMjogQ2FsbCBHU1NfQWNjZXB0X3NlY19jb250ZXh0 Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTENCiAgICA0LjEuMzogU2VuZCBUS0VZIFF1 ZXJ5LVJlc3BvbnNlIHRvIENsaWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTINCiAgNC4yOiBD b250ZXh0IEVzdGFibGlzaGVkLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTMNCiAgICA0LjIuMTogVGVybWluYXRpbmcgYSBDb250ZXh0Li4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTMNCjU6IFNlbmRpbmcgYW5kIFZlcmlmeWluZyBTaWduZWQgTWVz c2FnZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQNCiAgNS4xOiBTZW5kaW5nIGEgU2ln bmVkIE1lc3NhZ2UgLSBDYWxsIEdTU19HZXRNSUMuLi4uLi4uLi4uLi4uLi4uLi4uMTQNCiAgNS4y OiBWZXJpZnlpbmcgYSBTaWduZWQgTWVzc2FnZSAtIENhbGwgR1NTX1ZlcmlmeU1JQy4uLi4uLi4u Li4uLi4uMTUNCjY6IEV4YW1wbGUgdXNhZ2Ugb2YgR1NTLVRTSUcgYWxnb3JpdGhtLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTYNCjc6IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkNCjg6IElBTkEgQ29uc2lkZXJh dGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkNCjk6 IENvbmZvcm1hbmNlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTkNCjEwOkFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjANCjExOlJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjANCg0KDQoxLiBJbnRyb2R1 Y3Rpb24NCg0KVGhlIFNlY3JldCBLZXkgVHJhbnNhY3Rpb24gQXV0aGVudGljYXRpb24gZm9yIERO UyAoVFNJRykgW1JGQzI4NDVdDQpwcm90b2NvbCB3YXMgZGV2ZWxvcGVkIHRvIHByb3ZpZGUgYSBs aWdodHdlaWdodCBhdXRoZW50aWNhdGlvbiBhbmQNCmludGVncml0eSBvZiBtZXNzYWdlcyBiZXR3 ZWVuIHR3byBETlMgZW50aXRpZXMsIHN1Y2ggYXMgY2xpZW50IGFuZA0Kc2VydmVyIG9yIHNlcnZl ciBhbmQgc2VydmVyLiBUU0lHIGNhbiBiZSB1c2VkIHRvIHByb3RlY3QgZHluYW1pYw0KdXBkYXRl IG1lc3NhZ2VzLCBhdXRoZW50aWNhdGUgcmVndWxhciBtZXNzYWdlIG9yIHRvIG9mZi1sb2FkDQpj b21wbGljYXRlZCBETlNTRUMgW1JGQzI1MzVdIHByb2Nlc3NpbmcgZnJvbSBhIGNsaWVudCB0byBh IHNlcnZlciBhbmQNCnN0aWxsIGFsbG93IHRoZSBjbGllbnQgdG8gYmUgYXNzdXJlZCBvZiB0aGUg aW50ZWdyaXR5IG9mIHRoZSBhbnN3ZXJzLg0KDQpUaGUgVFNJRyBwcm90b2NvbCBbUkZDMjg0NV0g aXMgZXh0ZW5zaWJsZSB0aHJvdWdoIHRoZSBkZWZpbml0aW9uIG9mIG5ldw0KYWxnb3JpdGhtcy4g IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFuIGFsZ29yaXRobSBiYXNlZCBvbiB0aGUgR2VuZXJp Yw0KU2VjdXJpdHkgU2VydmljZSBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZSAoR1NTLUFQ SSkgW1JGQzI3NDNdLg0KR1NTLUFQSSBpcyBhIGZyYW1ld29yayB0aGF0IHByb3ZpZGVzIGFuIGFi c3RyYWN0aW9uIG9mIHNlY3VyaXR5IHRvIHRoZQ0KYXBwbGljYXRpb24gcHJvdG9jb2wgZGV2ZWxv cGVyLiAgVGhlIHNlY3VyaXR5IHNlcnZpY2VzIG9mZmVyZWQgY2FuDQppbmNsdWRlIGF1dGhlbnRp Y2F0aW9uLCBpbnRlZ3JpdHksIGFuZCBjb25maWRlbnRpYWxpdHkuDQoNClRoZSBHU1MtQVBJIGZy YW1ld29yayBoYXMgc2V2ZXJhbCBiZW5lZml0czoNCiogTWVjaGFuaXNtIGFuZCBwcm90b2NvbCBp bmRlcGVuZGVuY2UuICBUaGUgdW5kZXJseWluZyBtZWNoYW5pc21zIHRoYXQNCnJlYWxpemUgdGhl IHNlY3VyaXR5IHNlcnZpY2VzIGNhbiBiZSBuZWdvdGlhdGVkIG9uIHRoZSBmbHkgYW5kIHZhcmll ZA0Kb3ZlciB0aW1lLiAgRm9yIGV4YW1wbGUsIGEgY2xpZW50IGFuZCBzZXJ2ZXIgTUFZIHVzZSBL ZXJiZXJvcyBbUkZDMTk2NF0NCmZvciBvbmUgdHJhbnNhY3Rpb24sIHdoZXJlYXMgdGhhdCBzYW1l IHNlcnZlciBNQVkgdXNlIFNQS00gW1JGQzIwMjVdDQp3aXRoIGEgZGlmZmVyZW50IGNsaWVudC4N Cg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAyXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1Mt VFNJRyAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCiogVGhlIHByb3RvY29sIGRldmVs b3BlciBpcyByZW1vdmVkIGZyb20gdGhlIHJlc3BvbnNpYmlsaXR5IG9mDQpjcmVhdGluZyBhbmQg bWFuYWdpbmcgYSBzZWN1cml0eSBpbmZyYXN0cnVjdHVyZS4gIEZvciBleGFtcGxlLCB0aGUNCmRl dmVsb3BlciBkb2VzIG5vdCBuZWVkIHRvIGNyZWF0ZSBuZXcga2V5IGRpc3RyaWJ1dGlvbiBvciBr ZXkNCm1hbmFnZW1lbnQgc3lzdGVtcy4gIEluc3RlYWQgdGhlIGRldmVsb3BlciByZWxpZXMgb24g dGhlIHNlY3VyaXR5DQpzZXJ2aWNlIG1lY2hhbmlzbSB0byBtYW5hZ2UgdGhpcyBvbiBpdHMgYmVo YWxmLg0KDQpUaGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBpcyBsaW1pdGVkIHRvIHRoZSBkZXNj cmlwdGlvbiBvZiBhbg0KYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIG9ubHkuIEl0IGRvZXMgbm90 IGRpc2N1c3MgYW5kL29yIHByb3Bvc2UgYW4NCmF1dGhvcml6YXRpb24gbWVjaGFuaXNtLiAgUmVh ZGVycyB0aGF0IGFyZSB1bmZhbWlsaWFyIHdpdGggR1NTLUFQSQ0KY29uY2VwdHMgYXJlIGVuY291 cmFnZWQgdG8gcmVhZCB0aGUgY2hhcmFjdGVyaXN0aWNzIGFuZCBjb25jZXB0cyBzZWN0aW9uDQpv ZiBbUkZDMjc0M10gYmVmb3JlIGV4YW1pbmluZyB0aGlzIHByb3RvY29sIGluIGRldGFpbC4gSXQg aXMgYWxzbw0KYXNzdW1lZCB0aGF0IHRoZSByZWFkZXIgaXMgZmFtaWxpYXIgd2l0aCBbUkZDMjg0 NV0sIFtSRkMyOTMwXSwgW1JGQzEwMzRdDQphbmQgW1JGQzEwMzVdLg0KDQpUaGUga2V5IHdvcmRz ICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwN CiJSRUNPTU1FTkRFRCIsIGFuZCAiTUFZIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl cnByZXRlZCBhcw0KZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4NCg0KDQoyLiBBbGdv cml0aG0gT3ZlcnZpZXcNCg0KSW4gR1NTLCBjbGllbnQgYW5kIHNlcnZlciBpbnRlcmFjdCB0byBj cmVhdGUgYSAic2VjdXJpdHkgY29udGV4dCIuDQpUaGUgc2VjdXJpdHkgY29udGV4dCBjYW4gYmUg dXNlZCB0byBjcmVhdGUgYW5kIHZlcmlmeSB0cmFuc2FjdGlvbg0Kc2lnbmF0dXJlcyBvbiBtZXNz YWdlcyBiZXR3ZWVuIHRoZSB0d28gcGFydGllcy4gIEEgdW5pcXVlIHNlY3VyaXR5DQpjb250ZXh0 IGlzIHJlcXVpcmVkIGZvciBlYWNoIHVuaXF1ZSBjb25uZWN0aW9uIGJldHdlZW4gY2xpZW50IGFu ZA0Kc2VydmVyLg0KDQpDcmVhdGluZyBhIHNlY3VyaXR5IGNvbnRleHQgaW52b2x2ZXMgYSBuZWdv dGlhdGlvbiBiZXR3ZWVuIGNsaWVudCBhbmQNCnNlcnZlci4gIE9uY2UgYSBjb250ZXh0IGhhcyBi ZWVuIGVzdGFibGlzaGVkLCBpdCBoYXMgYSBmaW5pdGUgbGlmZXRpbWUNCmZvciB3aGljaCBpdCBj YW4gYmUgdXNlZCB0byBzZWN1cmUgbWVzc2FnZXMuICBUaHVzIHRoZXJlIGFyZSB0aHJlZQ0Kc3Rh dGVzIG9mIGEgY29udGV4dCBhc3NvY2lhdGVkIHdpdGggYSBjb25uZWN0aW9uOg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgViAgICAgICAgICB8 DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgICAgICAgICAgICAg ICAgICB8IFVuaW5pdGlhbGl6ZWQgfCAgfA0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICB8ICB8DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgViAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsg IHwNCiAgICAgICAgICAgICAgICAgICB8IE5lZ290aWF0aW5nICAgfCAgfA0KICAgICAgICAgICAg ICAgICAgIHwgQ29udGV4dCAgICAgICB8ICB8DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLSsgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgViAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgICAgICAgICAgICAgICAgICB8IENvbnRleHQgICAgICAg fCAgfA0KICAgICAgICAgICAgICAgICAgIHwgRXN0YWJsaXNoZWQgICB8ICB8DQogICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rDQoN CkV4cGlyZXMgSmFudWFyeSAyMSwgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgM10NCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgR1NTLVRT SUcgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQoNCkV2ZXJ5IGNvbm5lY3Rpb24gYmVn aW5zIGluIHRoZSB1bmluaXRpYWxpemVkIHN0YXRlLg0KDQoNCjIuMSBHU1MgRGV0YWlscw0KDQpD bGllbnQgYW5kIHNlcnZlciBNVVNUIGJlIGxvY2FsbHkgYXV0aGVudGljYXRlZCBhbmQgaGF2ZSBh Y3F1aXJlZA0KZGVmYXVsdCBjcmVkZW50aWFscyBiZWZvcmUgdXNpbmcgdGhpcyBwcm90b2NvbCBh cyBzcGVjaWZpZWQgaW4NClNlY3Rpb24gMS4xLjEgIkNyZWRlbnRpYWxzIiBpbiBSRkMgMjc0MyBb UkZDMjc0M10uDQoNClRoZSBHU1MtVFNJRyBhbGdvcml0aG0gY29uc2lzdHMgb2YgdHdvIHN0YWdl czoNCg0KSS4gRXN0YWJsaXNoIHNlY3VyaXR5IGNvbnRleHQuIFRoZSBDbGllbnQgYW5kIFNlcnZl ciB1c2UgdGhlDQpHU1NfSW5pdF9zZWNfY29udGV4dCBhbmQgR1NTX0FjY2VwdF9zZWNfY29udGV4 dCBBUElzIHRvIGdlbmVyYXRlIHRoZQ0KdG9rZW5zIHRoYXQgdGhleSBwYXNzIHRvIGVhY2ggb3Ro ZXIgdXNpbmcgW1JGQzI5MzBdIGFzIGEgdHJhbnNwb3J0DQptZWNoYW5pc20uDQoNCklJLiBPbmNl IHRoZSBzZWN1cml0eSBjb250ZXh0IGlzIGVzdGFibGlzaGVkIGl0IGlzIHVzZWQgdG8gZ2VuZXJh dGUgYW5kDQp2ZXJpZnkgc2lnbmF0dXJlcyB1c2luZyBHU1NfR2V0TUlDIGFuZCBHU1NfVmVyaWZ5 TUlDIEFQSXMuIFRoZXNlDQpzaWduYXR1cmVzIGFyZSBleGNoYW5nZWQgYnkgdGhlIENsaWVudCBh bmQgU2VydmVyIGFzIGEgcGFydCBvZiB0aGUgVFNJRw0KcmVjb3JkcyBleGNoYW5nZWQgaW4gRE5T IG1lc3NhZ2VzIHNlbnQgYmV0d2VlbiB0aGUgQ2xpZW50IGFuZCBTZXJ2ZXIsDQphcyBkZXNjcmli ZWQgaW4gW1JGQzI4NDVdLg0KDQoNCjMuICBDbGllbnQgUHJvdG9jb2wgRGV0YWlscw0KDQpBIHVu aXF1ZSBjb250ZXh0IGlzIHJlcXVpcmVkIGZvciBlYWNoIHNlcnZlciB0byB3aGljaCB0aGUgY2xp ZW50IHNlbmRzDQpzZWN1cmUgbWVzc2FnZXMuICBBIGNvbnRleHQgaXMgaWRlbnRpZmllZCBieSBh IGNvbnRleHQgaGFuZGxlLiBBDQpjbGllbnQgbWFpbnRhaW5zIGEgbWFwcGluZyBvZiBzZXJ2ZXJz IHRvIGhhbmRsZXMsDQoNCiAgICAgKHRhcmdldF9uYW1lLCBrZXlfbmFtZSwgY29udGV4dF9oYW5k bGUpDQoNClRoZSB2YWx1ZSBrZXlfbmFtZSBhbHNvIGlkZW50aWZpZXMgYSBjb250ZXh0IGhhbmRs ZS4gVGhlIGtleV9uYW1lIGlzDQp0aGUgb3duZXIgbmFtZSBvZiB0aGUgVEtFWSBhbmQgVFNJRyBy ZWNvcmRzIHNlbnQgYmV0d2VlbiBhIGNsaWVudCBhbmQgYQ0Kc2VydmVyIHRvIGluZGljYXRlIHRv IGVhY2ggb3RoZXIgd2hpY2ggY29udGV4dCBNVVNUIGJlIHVzZWQgdG8gcHJvY2Vzcw0KdGhlIGN1 cnJlbnQgcmVxdWVzdC4NCg0KRE5TIGNsaWVudCBhbmQgc2VydmVyIE1BWSB1c2UgdmFyaW91cyB1 bmRlcmx5aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgdG8NCmVzdGFibGlzaCBzZWN1cml0eSBjb250 ZXh0IGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9ucyAzIGFuZCA0LiBBdCB0aGUNCnNhbWUgdGltZSwg aW4gb3JkZXIgdG8gZ3VhcmFudGVlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBETlMgY2xpZW50 cw0KYW5kIHNlcnZlcnMgdGhhdCBzdXBwb3J0IEdTUy1UU0lHIGl0IGlzIFJFUVVJUkVEIHRoYXQg c2VjdXJpdHkNCm1lY2hhbmlzbSB1c2VkIGJ5IGNsaWVudCBlbmFibGVzIHVzZSBvZiBLZXJiZXJv cyB2NSAoc2VlIFNlY3Rpb24gOQ0KZm9yIG1vcmUgaW5mb3JtYXRpb24pLg0KDQoNCjMuMSAgTmVn b3RpYXRpbmcgQ29udGV4dA0KDQpJbiBHU1MsIGVzdGFibGlzaGluZyBhIHNlY3VyaXR5IGNvbnRl eHQgaW52b2x2ZXMgdGhlIHBhc3Npbmcgb2Ygb3BhcXVlDQp0b2tlbnMgYmV0d2VlbiB0aGUgY2xp ZW50IGFuZCB0aGUgc2VydmVyLiAgVGhlIGNsaWVudCBnZW5lcmF0ZXMgdGhlDQppbml0aWFsIHRv a2VuIGFuZCBzZW5kcyBpdCB0byB0aGUgc2VydmVyLiAgVGhlIHNlcnZlciBwcm9jZXNzZXMgdGhl DQp0b2tlbiBhbmQgaWYgbmVjZXNzYXJ5LCByZXR1cm5zIGEgc3Vic2VxdWVudCB0b2tlbiB0byB0 aGUgY2xpZW50LiAgVGhlDQpjbGllbnQgcHJvY2Vzc2VzIHRoaXMgdG9rZW4sIGFuZCBzbyBvbiwg dW50aWwgdGhlIG5lZ290aWF0aW9uIGlzDQpjb21wbGV0ZS4gIFRoZSBudW1iZXIgb2YgdGltZXMg dGhlIGNsaWVudCBhbmQgc2VydmVyIGV4Y2hhbmdlIHRva2Vucw0KDQpFeHBpcmVzIEphbnVhcnkg MjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoN CklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICAg IEp1bHkgMjEsIDIwMDINCg0KZGVwZW5kcyBvbiB0aGUgdW5kZXJseWluZyBzZWN1cml0eSBtZWNo YW5pc20uICBBIGNvbXBsZXRlZCBuZWdvdGlhdGlvbg0KcmVzdWx0cyBpbiBhIGNvbnRleHQgaGFu ZGxlLg0KDQpUaGUgVEtFWSByZXNvdXJjZSByZWNvcmQgW1JGQzI5MzBdIGlzIHVzZWQgYXMgdGhl IHZlaGljbGUgdG8gdHJhbnNmZXINCnRva2VucyBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLiAg VGhlIFRLRVkgcmVjb3JkIGlzIGEgZ2VuZXJhbA0KbWVjaGFuaXNtIGZvciBlc3RhYmxpc2hpbmcg c2VjcmV0IGtleXMgZm9yIHVzZSB3aXRoIFRTSUcuICBGb3IgbW9yZQ0KaW5mb3JtYXRpb24sIHNl ZSBbUkZDMjkzMF0uDQoNCg0KMy4xLjEgQ2FsbCBHU1NfSW5pdF9zZWNfY29udGV4dA0KDQpUbyBv YnRhaW4gdGhlIGZpcnN0IHRva2VuIHRvIGJlIHNlbnQgdG8gYSBzZXJ2ZXIsIGEgY2xpZW50IE1V U1QgY2FsbA0KR1NTX0luaXRfc2VjX2NvbnRleHQgQVBJLg0KVGhlIGZvbGxvd2luZyBpbnB1dCBw YXJhbWV0ZXJzIE1VU1QgYmUgdXNlZC4gVGhlIG91dGNvbWUgb2YgdGhlIGNhbGwgaXMNCmluZGlj YXRlZCB3aXRoIHRoZSBvdXRwdXQgdmFsdWVzIGJlbG93LiAgQ29uc3VsdCBTZWN0aW9ucyAyLjIu MQ0KIkdTU19Jbml0X3NlY19jb250ZXh0IGNhbGwiIG9mIFtSRkMyNzQzXSBmb3Igc3ludGF4IGRl ZmluaXRpb25zLg0KDQogICBJTlBVVFMNCiAgICAgQ1JFREVOVElBTCBIQU5ETEUgY2xhaW1hbnRf Y3JlZF9oYW5kbGUgPSBOVUxMIChOVUxMIHNwZWNpZmllcyAidXNlDQogICAgICAgICBkZWZhdWx0 IikuIENsaWVudCBNQVkgaW5zdGVhZCBzcGVjaWZ5IHNvbWUgb3RoZXIgdmFsaWQgaGFuZGxlDQog ICAgICAgICB0byBpdHMgY3JlZGVudGlhbHMuDQogICAgIENPTlRFWFQgSEFORExFIGlucHV0X2Nv bnRleHRfaGFuZGxlICA9IDANCiAgICAgSU5URVJOQUwgTkFNRSAgdGFyZ19uYW1lICAgICAgICAg ICAgID0gIkROU0A8dGFyZ2V0X3NlcnZlcl9uYW1lPiINCiAgICAgT0JKRUNUIElERU5USUZJRVIg bWVjaF90eXBlICAgICAgICAgID0gVW5kZXJseWluZyBzZWN1cml0eQ0KICAgICAgICAgbWVjaGFu aXNtIGNob3NlbiBieSBpbXBsZW1lbnRlcnMuIFRvIGd1YXJhbnRlZQ0KICAgICAgICAgaW50ZXJv cGVyYWJpbGl0eSBvZiB0aGUgaW1wbGVtZW50YXRpb25zIG9mIHRoZSBHU1MtVFNJRw0KICAgICAg ICAgbWVjaGFuaXNtIGNsaWVudCBNVVNUIHNwZWNpZnkgYSB2YWxpZCB1bmRlcmx5aW5nIHNlY3Vy aXR5DQogICAgICAgICBtZWNoYW5pc20gdGhhdCBlbmFibGVzIHVzZSBvZiBLZXJiZXJvcyB2NSAo c2VlIFNlY3Rpb24gOSBmb3INCiAgICAgICAgIG1vcmUgaW5mb3JtYXRpb24pLg0KICAgICBPQ1RF VCBTVFJJTkcgICBpbnB1dF90b2tlbiAgICAgICAgICAgPSBOVUxMDQogICAgIEJPT0xFQU4gICAg ICAgIHJlcGxheV9kZXRfcmVxX2ZsYWcgICA9IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0 dWFsX3JlcV9mbGFnICAgICAgID0gVFJVRQ0KICAgICBCT09MRUFOICAgICAgICBkZWxlZ19yZXFf ZmxhZyAgICAgICAgPSBUUlVFDQogICAgIEJPT0xFQU4gICAgICAgIHNlcXVlbmNlX3JlcV9mbGFn ICAgICA9IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgYW5vbl9yZXFfZmxhZyAgICAgICAgID0g RkFMU0UNCiAgICAgQk9PTEVBTiAgICAgICAgaW50ZWdfcmVxX2ZsYWcgICAgICAgID0gVFJVRQ0K ICAgICBJTlRFR0VSICAgICAgICBsaWZldGltZV9yZXEgICAgICAgICAgPSAwICgwIHJlcXVlc3Rz IGEgZGVmYXVsdA0KICAgICAgICAgdmFsdWUpLiBDbGllbnQgTUFZIGluc3RlYWQgc3BlY2lmeSBh bm90aGVyIHVwcGVyIGJvdW5kIGZvciB0aGUNCiAgICAgICAgIGxpZmV0aW1lIG9mIHRoZSBjb250 ZXh0IHRvIGJlIGVzdGFibGlzaGVkIGluIHNlY29uZHMuDQogICAgIE9DVEVUIFNUUklORyAgIGNo YW5fYmluZGluZ3MgICAgICAgICA9IEFueSB2YWxpZCBjaGFubmVsIGJpbmRpbmdzDQogICAgICAg ICBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAxLjEuNiAiQ2hhbm5lbCBCaW5kaW5ncyIgaW4gW1JG QzI3NDNdDQoNCiAgIE9VVFBVVFMNCiAgICAgSU5URUdFUiAgICAgICAgbWFqb3Jfc3RhdHVzDQog ICAgIENPTlRFWFQgSEFORExFIG91dHB1dF9jb250ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBTVFJJ TkcgICBvdXRwdXRfdG9rZW4NCiAgICAgQk9PTEVBTiAgICAgICAgcmVwbGF5X2RldF9zdGF0ZQ0K ICAgICBCT09MRUFOICAgICAgICBtdXR1YWxfc3RhdGUNCiAgICAgSU5URUdFUiAgICAgICAgbWlu b3Jfc3RhdHVzDQogICAgIE9CSkVDVCBJREVOVElGSUVSIG1lY2hfdHlwZQ0KICAgICBCT09MRUFO ICAgICAgICBkZWxlZ19zdGF0ZQ0KICAgICBCT09MRUFOICAgICAgICBzZXF1ZW5jZV9zdGF0ZQ0K ICAgICBCT09MRUFOICAgICAgICBhbm9uX3N0YXRlDQoNCkV4cGlyZXMgSmFudWFyeSAyMSwgMjAw MyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCg0KSU5URVJO RVQtRFJBRlQgICAgICAgICAgICAgICAgICAgR1NTLVRTSUcgICAgICAgICAgICAgICAgSnVseSAy MSwgMjAwMg0KDQogICAgIEJPT0xFQU4gICAgICAgIHRyYW5zX3N0YXRlDQogICAgIEJPT0xFQU4g ICAgICAgIHByb3RfcmVhZHlfc3RhdGUNCiAgICAgQk9PTEVBTiAgICAgICAgY29uZl9hdmFpbA0K ICAgICBCT09MRUFOICAgICAgICBpbnRlZ19hdmFpbA0KICAgICBJTlRFR0VSICAgICAgICBsaWZl dGltZV9yZWMNCg0KSWYgcmV0dXJuZWQgbWFqb3Jfc3RhdHVzIGlzIHNldCB0byBvbmUgb2YgdGhl IGZvbGxvd2luZyBlcnJvcnMNCg0KICAgICBHU1NfU19ERUZFQ1RJVkVfVE9LRU4NCiAgICAgR1NT X1NfREVGRUNUSVZFX0NSRURFTlRJQUwNCiAgICAgR1NTX1NfQkFEX1NJRyAoR1NTX1NfQkFEX01J QykNCiAgICAgR1NTX1NfTk9fQ1JFRA0KICAgICBHU1NfU19DUkVERU5USUFMU19FWFBJUkVEDQog ICAgIEdTU19TX0JBRF9CSU5ESU5HUw0KICAgICBHU1NfU19PTERfVE9LRU4NCiAgICAgR1NTX1Nf RFVQTElDQVRFX1RPS0VODQogICAgIEdTU19TX05PX0NPTlRFWFQNCiAgICAgR1NTX1NfQkFEX05B TUVUWVBFDQogICAgIEdTU19TX0JBRF9OQU1FDQogICAgIEdTU19TX0JBRF9NRUNIDQogICAgIEdT U19TX0ZBSUxVUkUNCg0KdGhlbiB0aGUgdGhlIGNsaWVudCBNVVNUIGFiYW5kb24gdGhlIGFsZ29y aXRobSBhbmQgTVVTVCBOT1QgdXNlIHRoZQ0KR1NTLVRTSUcgYWxnb3JpdGhtIHRvIGVzdGFibGlz aCB0aGlzIHNlY3VyaXR5IGNvbnRleC4gVGhpcyBkb2N1bWVudA0KZG9lcyBub3QgcHJlc2NyaWJl IHdoaWNoIG90aGVyIG1lY2hhbmlzbSBjb3VsZCBiZSB1c2VkIHRvIGVzdGFibGlzaA0KYSBzZWN1 cml0eSBjb250ZXh0LiBOZXh0IHRpbWUgd2hlbiB0aGlzIGNsaWVudCBuZWVkcyB0byBlc3RhYmxp c2gNCnNlY3VyaXR5IGNvbnRleHQsIHRoZSBjbGllbnQgTUFZIHVzZSBHU1MtVFNJRyBhbGdvcml0 aG0uDQoNClN1Y2Nlc3MgdmFsdWVzIG9mIG1ham9yX3N0YXR1cyBhcmUgR1NTX1NfQ09OVElOVUVf TkVFREVEIGFuZA0KR1NTX1NfQ09NUExFVEUuIFRoZSBleGFjdCBzdWNjZXNzIGNvZGUgaXMgaW1w b3J0YW50IGR1cmluZyBsYXRlcg0KcHJvY2Vzc2luZy4NCg0KVGhlIHZhbHVlcyBvZiByZXBsYXlf ZGV0X3N0YXRlIGFuZCBtdXR1YWxfc3RhdGUgaW5kaWNhdGUgaWYgdGhlDQpzZWN1cml0eSBwYWNr YWdlIHByb3ZpZGVzIHJlcGxheSBkZXRlY3Rpb24gYW5kIG11dHVhbCBhdXRoZW50aWNhdGlvbiwN CnJlc3BlY3RpdmVseS4gSWYgcmV0dXJuZWQgbWFqb3Jfc3RhdHVzIGlzIEdTU19TX0NPTVBMRVRF IEFORCBvbmUgb3IgYm90aA0Kb2YgdGhlc2UgdmFsdWVzIGFyZSBGQUxTRSwgdGhlIGNsaWVudCBN VVNUIGFiYW5kb24gdGhpcyBhbGdvcml0aG0uDQoNCkNsaWVudCdzIGJlaGF2aW9yIE1BWSBkZXBl bmQgb24gb3RoZXIgT1VUUFVUIHBhcmFtZXRlcnMgYWNjb3JkaW5nDQp0byB0aGUgcG9saWN5IGxv Y2FsIHRvIHRoZSBjbGllbnQuDQoNClRoZSBoYW5kbGUgb3V0cHV0X2NvbnRleHRfaGFuZGxlIGlz IHVuaXF1ZSB0byB0aGlzIG5lZ290aWF0aW9uIGFuZA0KaXMgc3RvcmVkIGluIHRoZSBjbGllbnQn cyBtYXBwaW5nIHRhYmxlIGFzIHRoZSBjb250ZXh0X2hhbmRsZSB0aGF0DQptYXBzIHRvIHRhcmdl dF9uYW1lLg0KDQoNCg0KMy4xLjIgU2VuZCBUS0VZIFF1ZXJ5IHRvIFNlcnZlcg0KDQpBbiBvcGFx dWUgb3V0cHV0X3Rva2VuIHJldHVybmVkIGJ5IEdTU19Jbml0X3NlY19jb250ZXh0IGlzIHRyYW5z bWl0dGVkDQp0byB0aGUgc2VydmVyIGluIGEgcXVlcnkgcmVxdWVzdCB3aXRoIFFUWVBFPVRLRVku ICBUaGUgdG9rZW4gaXRzZWxmDQp3aWxsIGJlIHBsYWNlZCBpbiBhIEtleSBEYXRhIGZpZWxkIG9m IHRoZSBSREFUQSBmaWVsZCBpbiB0aGUgVEtFWQ0KcmVzb3VyY2UgcmVjb3JkIGluIHRoZSBhZGRp dGlvbmFsIHJlY29yZHMgc2VjdGlvbiBvZiB0aGUgcXVlcnkuIFRoZQ0Kb3duZXIgbmFtZSBvZiB0 aGUgVEtFWSByZXNvdXJjZSByZWNvcmQgc2V0IHF1ZXJpZWQgZm9yIGFuZCB0aGUgb3duZXINCg0K RXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA2XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJ RyAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCm5hbWUgb2YgdGhlIHN1cHBsaWVkIFRL RVkgcmVzb3VyY2UgcmVjb3JkIGluIHRoZSBhZGRpdGlvbmFsIHJlY29yZHMNCnNlY3Rpb24gTVVT VCBiZSB0aGUgc2FtZS4gVGhpcyBuYW1lIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIHNlY3VyaXR5 DQpjb250ZXh0IHRvIGJvdGggdGhlIGNsaWVudCBhbmQgc2VydmVyLCBhbmQgdGh1cyB0aGUgY2xp ZW50IFNIT1VMRCB1c2UNCmEgdmFsdWUgd2hpY2ggaXMgZ2xvYmFsbHkgdW5pcXVlIGFzIGRlc2Ny aWJlZCBpbiBbUkZDMjkzMF0uIFRvIGFjaGlldmUNCmdsb2JhbCB1bmlxdWVuZXNzLCB0aGUgbmFt ZSBNQVkgY29udGFpbiBhIFVVSUQvR1VJRCBbSVNPMTE1NzhdLg0KDQogICBUS0VZIFJlY29yZA0K ICAgICBOQU1FID0gY2xpZW50LWdlbmVyYXRlZCBnbG9iYWxseSB1bmlxdWUgZG9tYWluIG5hbWUg c3RyaW5nDQogICAgICAgICAgICAoYXMgZGVzY3JpYmVkIGluIFtSRkMyOTMwXSkNCiAgICAgUkRB VEENCiAgICAgICAgQWxnb3JpdGhtIE5hbWUgICAgICA9IGdzcy10c2lnDQogICAgICAgIE1vZGUg ICAgICAgICAgICAgICAgPSAzIChHU1MtQVBJIG5lZ290aWF0aW9uIC0gcGVyIFtSRkMyOTMwXSkN CiAgICAgICAgS2V5IFNpemUgICAgICAgICAgICA9IHNpemUgb2Ygb3V0cHV0X3Rva2VuIGluIG9j dGV0cw0KICAgICAgICBLZXkgRGF0YSAgICAgICAgICAgID0gb3V0cHV0X3Rva2VuDQoNClRoZSBy ZW1haW5pbmcgZmllbGRzIGluIHRoZSBUS0VZIFJEQVRBLCBpLmUuIEluY2VwdGlvbiwgRXhwaXJh dGlvbiwNCkVycm9yLCBPdGhlciBTaXplIGFuZCBEYXRhIEZpZWxkcywgTVVTVCBiZSBzZXQgYWNj b3JkaW5nIHRvIFtSRkMyOTMwXS4NCg0KVGhlIHF1ZXJ5IGlzIHRyYW5zbWl0dGVkIHRvIHRoZSBz ZXJ2ZXIuDQoNCk5vdGU6IGlmIHRoZSBvcmlnaW5hbCBjbGllbnQgY2FsbCB0byBHU1NfSW5pdF9z ZWNfY29udGV4dCByZXR1cm5lZCBhbnkNCm1ham9yX3N0YXR1cyBvdGhlciB0aGFuIEdTU19TX0NP TlRJTlVFX05FRURFRCBvciBHU1NfU19DT01QTEVURSwgdGhlbg0KdGhlIGNsaWVudCBNVVNUIE5P VCBzZW5kIFRLRVkgcXVlcnkuIENsaWVudCdzIGJlaGF2aW9yIGluIHRoaXMgY2FzZSBpcw0KZGVz Y3JpYmVkIGFib3ZlIGluIFNlY3Rpb24gMy4xLjEuDQoNCg0KMy4xLjMgUmVjZWl2ZSBUS0VZIFF1 ZXJ5LVJlc3BvbnNlIGZyb20gU2VydmVyDQoNClVwb24gdGhlIHJlY2VwdGlvbiBvZiB0aGUgVEtF WSBxdWVyeSBETlMgc2VydmVyIE1VU1QgcmVzcG9uZCBhY2NvcmRpbmcNCnRvIHRoZSBkZXNjcmlw dGlvbiBpbiBTZWN0aW9uIDQuIFRoaXMgU2VjdGlvbiBzcGVjaWZpZXMgdGhlIGJlaGF2aW9yDQpv ZiB0aGUgY2xpZW50IGFmdGVyIGl0IHJlY2VpdmVzIHRoZSBtYXRjaGluZyByZXNwb25zZSB0byBp dHMgcXVlcnkuDQoNClRoZSBuZXh0IHByb2Nlc3Npbmcgc3RlcCBkZXBlbmRzIG9uIHRoZSB2YWx1 ZSBvZiBtYWpvcl9zdGF0dXMgZnJvbSB0aGUNCm1vc3QgcmVjZW50IGNhbGwgdGhhdCBjbGllbnQg cGVyZm9ybWVkIHRvIEdTU19Jbml0X3NlY19jb250ZXh0OiBlaXRoZXINCkdTU19TX0NPTVBMRVRF IG9yIEdTU19TX0NPTlRJTlVFLg0KDQoNCg0KMy4xLjMuMSBWYWx1ZSBvZiBtYWpvcl9zdGF0dXMg PT0gR1NTX1NfQ09NUExFVEUNCg0KSWYgdGhlIGxhc3QgY2FsbCB0byBHU1NfSW5pdF9zZWNfY29u dGV4dCB5aWVsZGVkIGEgbWFqb3Jfc3RhdHVzIHZhbHVlDQpvZiBHU1NfU19DT01QTEVURSBhbmQg YSBub24tTlVMTCBvdXRwdXRfdG9rZW4gd2FzIHNlbnQgdG8gdGhlIHNlcnZlciwNCnRoZW4gdGhl IGNsaWVudCBzaWRlIGNvbXBvbmVudCBvZiB0aGUgbmVnb3RpYXRpb24gaXMgY29tcGxldGUgYW5k IHRoZQ0KY2xpZW50IGlzIGF3YWl0aW5nIGNvbmZpcm1hdGlvbiBmcm9tIHRoZSBzZXJ2ZXIuDQoN CkNvbmZpcm1hdGlvbiBpcyBpbiB0aGUgZm9ybSBvZiBhIHF1ZXJ5IHJlc3BvbnNlIHdpdGggUkNP REU9Tk9FUlJPUiBhbmQNCndpdGggdGhlIGxhc3QgY2xpZW50IHN1cHBsaWVkIFRLRVkgcmVjb3Jk IGluIHRoZSBhbnN3ZXIgc2VjdGlvbiBvZiB0aGUNCnF1ZXJ5LiAgSWYgdGhlIHJlc3BvbnNlIGRv ZXMgbm90IG1hdGNoIHRoaXMgZm9ybWF0IHRoZW4gYW4gYXR0YWNrZXIgaGFzDQp0YW1wZXJlZCB3 aXRoIHRoZSBtZXNzYWdlIGluIHRyYW5zaXQgb3IgaGFzIGF0dGVtcHRlZCB0byBzZW5kIHRoZQ0K Y2xpZW50IGEgZmFsc2UgcmVzcG9uc2UuIEluIHRoaXMgY2FzZSB0aGUgY2xpZW50IE1BWSBjb250 aW51ZSB3YWl0aW5nDQpmb3IgYSByZXNwb25zZSB0byBpdHMgbGFzdCBUS0VZIHF1ZXJ5IHVudGls IHRoZSB0aW1lIHBlcmlvZCBzaW5jZSB0aGUNCmNsaWVudCBzZW50IGxhc3QgVEtFWSBxdWVyeSBl eHBpcmVzLiBTdWNoIGEgdGltZSBwZXJpb2QgaXMgc3BlY2lmaWVkIGJ5DQp0aGUgcG9saWN5IGxv Y2FsIHRvIHRoZSBjbGllbnQuIFRoaXMgaXMgYSBuZXcgb3B0aW9uIHRoYXQgYWxsb3dzIEROUw0K DQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDddDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgIEdTUy1U U0lHICAgICAgICAgICAgICAgIEp1bHkgMjEsIDIwMDINCg0KY2xpZW50IHRvIGFjY2VwdCBtdWx0 aXBsZSBhbnN3ZXJzIGZvciBvbmUgcXVlcnkgSUQgYW5kIHNlbGVjdCBvbmUgKG5vdA0KbmVjZXNz YXJpbHkgdGhlIGZpcnN0IG9uZSkgYmFzZWQgb24gc29tZSBjcml0ZXJpYS4NCg0KSWYgdGhlIGFw cHJvcHJpYXRlIGNvbmZpcm1hdGlvbiBtZXNzYWdlIGlzIHJlY2VpdmVkIHRoZSBjb250ZXh0IHN0 YXRlDQppcyBhZHZhbmNlZCB0byBDb250ZXh0IEVzdGFibGlzaGVkLiAgUHJvY2VlZCB0byBzZWN0 aW9uIDMuMiBmb3IgdXNhZ2UNCm9mIHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KIA0KTm90aWNlOiBF YXJseSB2ZXJzaW9ucyBvZiBHU1MtVFNJRyBwcm90b2NvbCBhbmQgaW1wbGVtZW50YXRpb24gcmVx dWlyZWQNCnRoYXQNCi0gc2VydmVyknMgcmVzcG9uc2UgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlv biBpcyBzaWduZWQgd2l0aCBhIFRTSUcNCiAgcmVjb3JkOw0KLSB0aGUgc2lnbmF0dXJlIGluIHRo ZSBUU0lHIHJlY29yZCBpcyB2ZXJpZmllZCB1c2luZyB0aGUgcHJvY2VkdXJlDQogIGRldGFpbGVk IGluIHNlY3Rpb24gNSwgU2VuZGluZyBhbmQgVmVyaWZ5aW5nIFNpZ25lZCBNZXNzYWdlczsNCi0g aWYgdGhlIHJlc3BvbnNlIGlzIG5vdCBzaWduZWQgdGhlbiBjbGllbnQgaWdub3JlcyB0aGUgcmVz cG9uc2UgYW5kDQogIGRvZXMgbm90IGFkdmFuY2UgdGhlIGNvbnRleHQgdG8gQ29udGV4dCBFc3Rh Ymxpc2hlZC4NCg0KSWYgaW1wbGVtZW50ZXJzIGRlY2lkZSB0byBlbmFibGUgaW50ZXJvcGVyYWJp bGl0eSB3aXRoIHRoZSBlYXJseQ0KdmVyc2lvbnMgb2YgR1NTLVRTSUcgaW1wbGVtZW50YXRpb25z IChpbmNsdWRlZCBpbiBXaW5kb3dzIDIwMDANClByb2Zlc3Npb25hbCwgYWxsIHZlcnNpb25zIG9m IFdpbmRvd3MgMjAwMCBTZXJ2ZXIsIGFsbCB2ZXJzaW9ucyBvZg0KV2luZG93cyBYUCwgYWxsIHZl cnNpb25zIG9mIFdpbmRvd3MuTmV0IDIwMDMgU2VydmVyLCBMdWNlbnQgRE5TIFNlcnZpY2UNCjMu MSBhbmQgVml0YWxRSVAgNi4wKSBpbXBsZW1lbnRlcnMgb2YgdGhlIEdTUy1UU0lHIGNsaWVudCBt YXkgY29uc2lkZXINCmlnbm9yaW5nIHRoZSBUU0lHIHJlY29yZCBpbmNsdWRlZCBpbiB0aGUgcmVz cG9uc2VzIGZyb20gc3VjaCBzZXJ2ZXJzLg0KSW1wbGVtZW50ZXJzIG9mIHRoZSBHU1MtVFNJRyBz ZXJ2ZXJzIG1heSBjb25zaWRlciBzaWduaW5nIHRoZSByZXNwb25zZQ0KdG8gc3VjaCBjbGllbnQn cyByZXF1ZXN0IGFuZCBpbmNsdWRpbmcgYSBUU0lHIHJlY29yZCBjb250YWluaW5nIHRoZQ0Kc2ln bmF0dXJlIGluIGl0cyByZXNwb25zZS4gRG9pbmcgdGhpcyBpcyBub3QgY29tcGxpYW50IHdpdGgg UkZDIDI4NDUNCnJlcXVpcmluZyB0aGF0ICJUaGUgc2VydmVyIE1VU1Qgbm90IGdlbmVyYXRlIGEg c2lnbmVkIHJlc3BvbnNlIHRvIGFuDQp1bnNpZ25lZCByZXF1ZXN0IiwgYnV0IGFzIGxvbmcgYXMg dGhlcmUgYXJlIG5vIEdTUy1UU0lHIGNsaWVudHMgKGFuZA0KY3VycmVudGx5IHRoZXJlIGFyZSBu byBzdWNoIGNsaWVudHMpIHJlamVjdGluZyByZXNwb25zZXMgY29udGFpbmluZw0KVFNJRyByZWNv cmRzICh3aGljaCBpcyBub3QgcmVxdWlyZWQgYnkgUkZDIDI4NDUpIHNlcnZlcidzIGRldmlhdGlv bg0KZnJvbSBjb21wbGlhbmNlIHdpdGggUkZDIDI4NDUgc2hvdWxkIG5vdCBjYXVzZSBpbnRlcm9w ZXJhYmlsaXR5DQpwcm9ibGVtcy4NCg0KDQoNCjMuMS4zLjIgVmFsdWUgb2YgbWFqb3Jfc3RhdHVz ID09IEdTU19TX0NPTlRJTlVFDQoNCklmIHRoZSBsYXN0IGNhbGwgdG8gR1NTX0luaXRfc2VjX2Nv bnRleHQgeWllbGRlZCBhIG1ham9yX3N0YXR1cyB2YWx1ZQ0Kb2YgR1NTX1NfQ09OVElOVUUsIHRo ZW4gdGhlIG5lZ290aWF0aW9uIGlzIG5vdCB5ZXQgY29tcGxldGUuIFRoZSBzZXJ2ZXINCndpbGwg cmV0dXJuIHRvIHRoZSBjbGllbnQgYSBxdWVyeS1yZXNwb25zZSB3aXRoIGEgVEtFWSByZWNvcmQg aW4gdGhlDQpBbnN3ZXIgc2VjdGlvbi4gSWYgdGhlIEROUyBtZXNzYWdlIGVycm9yIGlzIG5vdCBO T19FUlJPUiBvciBlcnJvciBmaWVsZA0KaW4gdGhlIFRLRVkgcmVjb3JkIGlzIG5vdCAwIChpLmUu IG5vIGVycm9yKSwgdGhlbiB0aGUgY2xpZW50IE1VU1QNCmFiYW5kb24gdGhpcyBuZWdvdGlhdGlv biBzZXF1ZW5jZS4gVGhlIGNsaWVudCBNVVNUIGRlbGV0ZSBhbiBhY3RpdmUNCmNvbnRleHQgYnkg Y2FsbGluZyBHU1NfRGVsZXRlX3NlY19jb250ZXh0IHByb3ZpZGluZyB0aGUgYXNzb2NpYXRlZA0K Y29udGV4dF9oYW5kbGUuIFRoZSBjbGllbnQgTUFZIHJlcGVhdCB0aGUgbmVnb3RpYXRpb24gc2Vx dWVuY2Ugc3RhcnRpbmcNCndpdGggdGhlIHVuaW5pdGlhbGl6ZWQgc3RhdGUgYXMgZGVzY3JpYmVk IGluIHNlY3Rpb24gMy4xLiBUbyBwcmV2ZW50DQppbmZpbml0ZSBsb29waW5nIHRoZSBudW1iZXIg b2YgYXR0ZW1wdHMgdG8gZXN0YWJsaXNoIGEgc2VjdXJpdHkgY29udGV4dA0KTVVTVCBiZSBsaW1p dGVkIHRvIHRlbiBvciBsZXNzLg0KDQpJZiB0aGUgRE5TIG1lc3NhZ2UgZXJyb3IgaXMgTk9fRVJS T1IgYW5kIGVycm9yIGZpbGVkIGluIHRoZSBUS0VZIHJlY29yZA0KaXMgMCAoaS5lLiBubyBlcnJv ciksIHRoZW4gdGhlIGNsaWVudCBNVVNUIHBhc3MgYSB0b2tlbiBzcGVjaWZpZWQgaW4gdGhlDQpL ZXkgRGF0YSBmaWVsZCBpbiB0aGUgVEtFWSByZXNvdXJjZSByZWNvcmQgdG8gR1NTX0luaXRfc2Vj X2NvbnRleHQNCnVzaW5nIHRoZSBzYW1lIHBhcmFtZXRlcnMgdmFsdWVzIGFzIGluIHByZXZpb3Vz IGNhbGwgZXhjZXB0IHZhbHVlcyBmb3INCg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoNCklOVEVSTkVULURS QUZUICAgICAgICAgICAgICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICAgIEp1bHkgMjEsIDIw MDINCg0KQ09OVEVYVCBIQU5ETEUgaW5wdXRfY29udGV4dF9oYW5kbGUgYW5kIE9DVEVUIFNUUklO RyBpbnB1dF90b2tlbiBhcw0KZGVzY3JpYmVkIGJlbG93Og0KDQogICBJTlBVVFMNCiAgICAgQ09O VEVYVCBIQU5ETEUgaW5wdXRfY29udGV4dF9oYW5kbGUgID0gY29udGV4dF9oYW5kbGUgKHRoaXMg aXMgdGhlDQogICAgICAgICAgY29udGV4dF9oYW5kbGUgY29ycmVzcG9uZGluZyB0byB0aGUga2V5 X25hbWUgd2hpY2ggaXMgdGhlDQogICAgICAgICAgb3duZXIgbmFtZSBvZiB0aGUgVEtFWSByZWNv cmQgaW4gdGhlIGFuc3dlciBzZWN0aW9uIGluIHRoZQ0KICAgICAgICAgIFRLRVkgcXVlcnkgcmVz cG9uc2UpDQogICAgIE9DVEVUIFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAgICA9IHRva2Vu IGZyb20gS2V5IGZpZWxkIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFRLRVkgcmVjb3JkDQoNCkRlcGVuZGluZyBvbiB0aGUgZm9sbG93aW5nIE9VVFBVVCB2 YWx1ZXMgb2YgR1NTX0luaXRfc2VjX2NvbnRleHQNCiAgICAgSU5URUdFUiAgICAgICAgbWFqb3Jf c3RhdHVzDQogICAgIE9DVEVUIFNUUklORyAgIG91dHB1dF90b2tlbg0KdGhlIGNsaWVudCBNVVNU IHRha2Ugb25lIG9mIHRoZSBmb2xsb3dpbmcgYWN0aW9uczoNCg0KSWYgT1VUUFVUIG1ham9yX3N0 YXR1cyBpcyBzZXQgdG8gb25lIG9mIHRoZSBmb2xsb3dpbmcgdmFsdWVzDQogICAgIEdTU19TX0RF RkVDVElWRV9UT0tFTg0KICAgICBHU1NfU19ERUZFQ1RJVkVfQ1JFREVOVElBTA0KICAgICBHU1Nf U19CQURfU0lHIChHU1NfU19CQURfTUlDKQ0KICAgICBHU1NfU19OT19DUkVEDQogICAgIEdTU19T X0NSRURFTlRJQUxTX0VYUElSRUQNCiAgICAgR1NTX1NfQkFEX0JJTkRJTkdTDQogICAgIEdTU19T X09MRF9UT0tFTg0KICAgICBHU1NfU19EVVBMSUNBVEVfVE9LRU4NCiAgICAgR1NTX1NfTk9fQ09O VEVYVA0KICAgICBHU1NfU19CQURfTkFNRVRZUEUNCiAgICAgR1NTX1NfQkFEX05BTUUNCiAgICAg R1NTX1NfQkFEX01FQ0gNCiAgICAgR1NTX1NfRkFJTFVSRQ0KDQp0aGUgY2xpZW50IE1VU1QgYWJh bmRvbiB0aGlzIG5lZ290aWF0aW9uIHNlcXVlbmNlLiBUaGlzIG1lYW5zIHRoYXQgdGhlDQpjbGll bnQgTVVTVCBkZWxldGUgYW4gYWN0aXZlIGNvbnRleHQgYnkgY2FsbGluZyBHU1NfRGVsZXRlX3Nl Y19jb250ZXh0DQpwcm92aWRpbmcgdGhlIGFzc29jaWF0ZWQgY29udGV4dF9oYW5kbGUuIFRoZSBj bGllbnQgTUFZIHJlcGVhdCB0aGUNCm5lZ290aWF0aW9uIHNlcXVlbmNlIHN0YXJ0aW5nIHdpdGgg dGhlIHVuaW5pdGlhbGl6ZWQgc3RhdGUgYXMgZGVzY3JpYmVkDQppbiBzZWN0aW9uIDMuMS4gVG8g cHJldmVudCBpbmZpbml0ZSBsb29waW5nIHRoZSBudW1iZXIgb2YgYXR0ZW1wdHMgdG8NCmVzdGFi bGlzaCBhIHNlY3VyaXR5IGNvbnRleHQgTVVTVCBiZSBsaW1pdGVkIHRvIHRlbiBvciBsZXNzLg0K DQpJZiBPVVRQVVQgbWFqb3Jfc3RhdHVzIGlzIEdTU19TX0NPTlRJTlVFX05FRURFRCBPUiBHU1Nf U19DT01QTEVURSB0aGVuDQpjbGllbnQgTVVTVCBhY3QgYXMgZGVzY3JpYmVkIGJlbG93Lg0KDQpJ ZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09OVElOVUVfTkVFREVEIHRoZSBuZWdvdGlhdGlvbiBp cyBub3QgeWV0DQpmaW5pc2hlZC4gIFRoZSB0b2tlbiBvdXRwdXRfdG9rZW4gTVVTVCBiZSBwYXNz ZWQgdG8gdGhlIHNlcnZlciBpbiBhIFRLRVkNCnJlY29yZCBieSByZXBlYXRpbmcgdGhlIG5lZ290 aWF0aW9uIHNlcXVlbmNlIGJlZ2lubmluZyB3aXRoIHNlY3Rpb24NCjMuMS4yLiAgVGhlIGNsaWVu dCBNVVNUIHBsYWNlIGEgbGltaXQgb24gdGhlIG51bWJlciBvZiBjb250aW51YXRpb25zIGluDQph IGNvbnRleHQgbmVnb3RpYXRpb24gdG8gcHJldmVudCBlbmRsZXNzIGxvb3BpbmcuIFN1Y2ggbGlt aXQgU0hPVUxEIE5PVA0KZXhjZWVkIHZhbHVlIG9mIDEwLg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMg R1NTX1NfQ09NUExFVEUgYW5kIG91dHB1dF90b2tlbiBpcyBub24tTlVMTCwgdGhlDQpjbGllbnQt c2lkZSBjb21wb25lbnQgb2YgdGhlIG5lZ290aWF0aW9uIGlzIGNvbXBsZXRlIGJ1dCB0aGUgdG9r ZW4NCm91dHB1dF90b2tlbiBNVVNUIGJlIHBhc3NlZCB0byB0aGUgc2VydmVyIGJ5IHJlcGVhdGlu ZyB0aGUgbmVnb3RpYXRpb24NCnNlcXVlbmNlIGJlZ2lubmluZyB3aXRoIHNlY3Rpb24gMy4xLjIu DQoNCg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBH U1MtVFNJRyAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCklmIG1ham9yX3N0YXR1cyBp cyBHU1NfU19DT01QTEVURSBhbmQgb3V0cHV0X3Rva2VuIGlzIE5VTEwsIGNvbnRleHQNCm5lZ290 aWF0aW9uIGlzIGNvbXBsZXRlLiAgVGhlIGNvbnRleHQgc3RhdGUgaXMgYWR2YW5jZWQgdG8gQ29u dGV4dA0KRXN0YWJsaXNoZWQuICBQcm9jZWVkIHRvIHNlY3Rpb24gMy4yIGZvciB1c2FnZSBvZiB0 aGUgc2VjdXJpdHkgY29udGV4dC4NCg0KDQozLjIgIENvbnRleHQgRXN0YWJsaXNoZWQNCg0KV2hl biBjb250ZXh0IG5lZ290aWF0aW9uIGlzIGNvbXBsZXRlLCB0aGUgaGFuZGxlIGNvbnRleHRfaGFu ZGxlIE1VU1QgYmUNCnVzZWQgZm9yIHRoZSBnZW5lcmF0aW9uIGFuZCB2ZXJpZmljYXRpb24gb2Yg dHJhbnNhY3Rpb24gc2lnbmF0dXJlcy4NCg0KVGhlIHByb2NlZHVyZXMgZm9yIHNlbmRpbmcgYW5k IHJlY2VpdmluZyBzaWduZWQgbWVzc2FnZXMgYXJlIGRlc2NyaWJlZA0KaW4gc2VjdGlvbiA1LCBT ZW5kaW5nIGFuZCBWZXJpZnlpbmcgU2lnbmVkIE1lc3NhZ2VzLg0KDQoNCjMuMi4xIFRlcm1pbmF0 aW5nIGEgQ29udGV4dA0KDQpXaGVuIHRoZSBjbGllbnQgaXMgbm90IGludGVuZGVkIHRvIGNvbnRp bnVlIHVzaW5nIHRoZSBlc3RhYmxpc2hlZA0Kc2VjdXJpdHkgY29udGV4dCwgdGhlIGNsaWVudCBT SE9VTEQgZGVsZXRlIGFuIGFjdGl2ZSBjb250ZXh0IGJ5DQpjYWxsaW5nIEdTU19EZWxldGVfc2Vj X2NvbnRleHQgcHJvdmlkaW5nIHRoZSBhc3NvY2lhdGVkIGNvbnRleHRfaGFuZGxlLA0KQU5EIGNs aWVudCBTSE9VTEQgZGVsZXRlIHRoZSBlc3RhYmxpc2hlZCBjb250ZXh0IG9uIHRoZSBETlMgc2Vy dmVyDQpieSB1c2luZyBUS0VZIFJSIHdpdGggdGhlIE1vZGUgZmllbGQgc2V0IHRvIDUsIGkuZS4g ImtleSBkZWxldGlvbiINCltSRkMyOTMwXS4NCg0KDQoNCjQuICBTZXJ2ZXIgUHJvdG9jb2wgRGV0 YWlscw0KDQpBcyBvbiB0aGUgY2xpZW50LXNpZGUsIHRoZSByZXN1bHQgb2YgYSBzdWNjZXNzZnVs IGNvbnRleHQgbmVnb3RpYXRpb24NCmlzIGEgY29udGV4dCBoYW5kbGUgdXNlZCBpbiBmdXR1cmUg Z2VuZXJhdGlvbiBhbmQgdmVyaWZpY2F0aW9uIG9mIHRoZQ0KdHJhbnNhY3Rpb24gc2lnbmF0dXJl cy4NCg0KQSBzZXJ2ZXIgTUFZIGJlIG1hbmFnaW5nIHNldmVyYWwgY29udGV4dHMgd2l0aCBzZXZl cmFsIGNsaWVudHMuDQpDbGllbnRzIGlkZW50aWZ5IHRoZWlyIGNvbnRleHRzIGJ5IHByb3ZpZGlu ZyBhIGtleSBuYW1lIGluIHRoZWlyDQpyZXF1ZXN0LiAgVGhlIHNlcnZlciBtYWludGFpbnMgYSBt YXBwaW5nIG9mIGtleSBuYW1lcyB0byBoYW5kbGVzOg0KDQogICAgIChrZXlfbmFtZSwgY29udGV4 dF9oYW5kbGUpDQoNCg0KDQo0LjEgTmVnb3RpYXRpbmcgQ29udGV4dA0KDQpBIHNlcnZlciBNVVNU IHJlY29nbml6ZSBUS0VZIHF1ZXJpZXMgYXMgc2VjdXJpdHkgY29udGV4dCBuZWdvdGlhdGlvbg0K bWVzc2FnZXMuDQoNCg0KNC4xLjEgUmVjZWl2ZSBUS0VZIFF1ZXJ5IGZyb20gQ2xpZW50DQoNClVw b24gcmVjZWl2aW5nIGEgcXVlcnkgd2l0aCBRVFlQRSA9IFRLRVksIHRoZSBzZXJ2ZXIgTVVTVCBl eGFtaW5lDQp3aGV0aGVyIHRoZSBNb2RlIGFuZCBBbGdvcml0aG0gTmFtZSBmaWVsZHMgb2YgdGhl IFRLRVkgcmVjb3JkIGluIHRoZQ0KYWRkaXRpb25hbCByZWNvcmRzIHNlY3Rpb24gb2YgdGhlIG1l c3NhZ2UgY29udGFpbiB2YWx1ZXMgb2YgMyBhbmQNCmdzcy10c2lnLCByZXNwZWN0aXZlbHkuIElm IHRoZXkgZG8sIHRoZW4gdGhlIChrZXlfbmFtZSwgY29udGV4dF9oYW5kbGUpDQptYXBwaW5nIHRh YmxlIGlzIHNlYXJjaGVkIGZvciB0aGUga2V5X25hbWUgbWF0Y2hpbmcgdGhlIG93bmVyIG5hbWUg b2YNCnRoZSBUS0VZIHJlY29yZCBpbiB0aGUgYWRkaXRpb25hbCByZWNvcmRzIHNlY3Rpb24gb2Yg dGhlIHF1ZXJ5LiBJZiB0aGUNCg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAg ICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCm5h bWUgaXMgZm91bmQgaW4gdGhlIHRhYmxlIGFuZCB0aGUgc2VjdXJpdHkgY29udGV4dCBmb3IgdGhp cyBuYW1lIGlzDQplc3RhYmxpc2hlZCBhbmQgbm90IGV4cGlyZWQsIHRoZW4gdGhlIHNlcnZlciBN VVNUIHJlc3BvbmQgdG8gdGhlIHF1ZXJ5DQp3aXRoIEJBRE5BTUUgZXJyb3IgaW4gdGhlIFRLRVkg ZXJyb3IgZmllbGQuICBJZiB0aGUgbmFtZSBpcyBmb3VuZCBpbiB0aGUNCnRhYmxlIGFuZCB0aGUg c2VjdXJpdHkgY29udGV4dCBpcyBub3QgZXN0YWJsaXNoZWQsIHRoZSBjb3JyZXNwb25kaW5nDQpj b250ZXh0X2hhbmRsZSBpcyB1c2VkIGluIHN1YnNlcXVlbnQgR1NTIG9wZXJhdGlvbnMuIElmIHRo ZSBuYW1lIGlzDQpmb3VuZCBidXQgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMgZXhwaXJlZCwgdGhl biB0aGUgc2VydmVyIGRlbGV0ZXMgdGhpcw0Kc2VjdXJpdHkgY29udGV4dCwgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gNC4yLjEsIGFuZCBpbnRlcnByZXRzIHRoaXMNCnF1ZXJ5IGFzIGEgc3RhcnQg b2YgbmV3IHNlY3VyaXR5IGNvbnRleHQgbmVnb3RpYXRpb24gYW5kIHBlcmZvcm1zDQpvcGVyYXRp b25zIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMS4yIGFuZCA0LjEuMy4gSWYgdGhlIG5hbWUgaXMg bm90DQpmb3VuZCwgdGhlbiB0aGUgc2VydmVyIGludGVycHJldHMgdGhpcyBxdWVyeSBhcyBhIHN0 YXJ0IG9mIG5ldyBzZWN1cml0eQ0KY29udGV4dCBuZWdvdGlhdGlvbiBhbmQgcGVyZm9ybXMgb3Bl cmF0aW9ucyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuMg0KYW5kIDQuMS4zLg0KDQoNCjQuMS4y IENhbGwgR1NTX0FjY2VwdF9zZWNfY29udGV4dA0KDQpUaGUgc2VydmVyIHBlcmZvcm1zIGl0cyBz aWRlIG9mIGEgY29udGV4dCBuZWdvdGlhdGlvbiBieSBjYWxsaW5nDQpHU1NfQWNjZXB0X3NlY19j b250ZXh0LiBUaGUgZm9sbG93aW5nIGlucHV0IHBhcmFtZXRlcnMgTVVTVCBiZSB1c2VkLiBUaGUN Cm91dGNvbWUgb2YgdGhlIGNhbGwgaXMgaW5kaWNhdGVkIHdpdGggdGhlIG91dHB1dCB2YWx1ZXMg YmVsb3cuICBDb25zdWx0DQpTZWN0aW9ucyAyLjIuMiAiR1NTX0FjY2VwdF9zZWNfY29udGV4dCBj YWxsIiBvZiB0aGUgUkZDIDI3NDNbUkZDMjc0M10NCmZvciBzeW50YXggZGVmaW5pdGlvbnMuDQoN CiAgIElOUFVUUw0KICAgICBDT05URVhUIEhBTkRMRSBpbnB1dF9jb250ZXh0X2hhbmRsZSAgPSAw IGlmIG5ldyBuZWdvdGlhdGlvbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY29udGV4dF9oYW5kbGUgbWF0Y2hpbmcNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAga2V5X25hbWUgaWYgb25nb2luZyBuZWdvdGlhdGlvbg0KICAgICBP Q1RFVCBTVFJJTkcgICBpbnB1dF90b2tlbiAgICAgICAgICAgPSB0b2tlbiBzcGVjaWZpZWQgaW4g dGhlIEtleQ0KICAgICAgICAgICBmaWVsZCBmcm9tIFRLRVkgUlIgKGZyb20gQWRkaXRpb25hbCBy ZWNvcmRzIFNlY3Rpb24gb2YNCiAgICAgICAgICAgdGhlIGNsaWVudCdzIHF1ZXJ5KQ0KICAgICBD UkVERU5USUFMIEhBTkRMRSBhY2NlcHRvcl9jcmVkX2hhbmRsZSA9IE5VTEwgKE5VTEwgc3BlY2lm aWVzICJ1c2UNCiAgICAgICAgICAgZGVmYXVsdCIpLiBTZXJ2ZXIgTUFZIGluc3RlYWQgc3BlY2lm eSBzb21lIG90aGVyIHZhbGlkIGhhbmRsZQ0KICAgICAgICAgICB0byBpdHMgY3JlZGVudGlhbHMu DQogICAgIE9DVEVUIFNUUklORyAgIGNoYW5fYmluZGluZ3MgICAgICAgICAgPSBBbnkgdmFsaWQg Y2hhbm5lbCBiaW5kaW5ncw0KICAgICAgICAgICBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAxLjEu NiAiQ2hhbm5lbCBCaW5kaW5ncyIgaW4gW1JGQzI3NDNdDQoNCiAgIE9VVFBVVFMNCiAgICAgSU5U RUdFUiAgICAgICAgbWFqb3Jfc3RhdHVzDQogICAgIENPTlRFWFRfSEFORExFIG91dHB1dF9jb250 ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBTVFJJTkcgICBvdXRwdXRfdG9rZW4NCiAgICAgSU5URUdF UiAgICAgICAgbWlub3Jfc3RhdHVzDQogICAgIElOVEVSTkFMIE5BTUUgIHNyY19uYW1lDQogICAg IE9CSkVDVCBJREVOVElGSUVSICBtZWNoX3R5cGUNCiAgICAgQk9PTEVBTiAgICAgICAgZGVsZWdf c3RhdGUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0dWFsX3N0YXRlDQogICAgIEJPT0xFQU4gICAg ICAgIHJlcGxheV9kZXRfc3RhdGUNCiAgICAgQk9PTEVBTiAgICAgICAgc2VxdWVuY2Vfc3RhdGUN CiAgICAgQk9PTEVBTiAgICAgICAgYW5vbl9zdGF0ZQ0KICAgICBCT09MRUFOICAgICAgICB0cmFu c19zdGF0ZQ0KICAgICBCT09MRUFOICAgICAgICBwcm90X3JlYWR5X3N0YXRlDQogICAgIEJPT0xF QU4gICAgICAgIGNvbmZfYXZhaWwNCiAgICAgQk9PTEVBTiAgICAgICAgaW50ZWdfYXZhaWwNCiAg ICAgSU5URUdFUiAgICAgICAgbGlmZXRpbWVfcmVjDQogICAgIENPTlRFWFRfSEFORExFIGRlbGVn YXRlZF9jcmVkX2hhbmRsZQ0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAg ICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQpJ ZiB0aGlzIGlzIHRoZSBmaXJzdCBjYWxsIHRvIEdTU19BY2NlcHRfc2VjX2NvbnRleHQgaW4gYSBu ZXcNCm5lZ290aWF0aW9uLCB0aGVuIG91dHB1dF9jb250ZXh0X2hhbmRsZSBpcyBzdG9yZWQgaW4g dGhlIHNlcnZlcidzDQprZXktbWFwcGluZyB0YWJsZSBhcyB0aGUgY29udGV4dF9oYW5kbGUgdGhh dCBtYXBzIHRvIHRoZSBuYW1lIG9mIHRoZQ0KVEtFWSByZWNvcmQuDQoNCg0KNC4xLjMgU2VuZCBU S0VZIFF1ZXJ5LVJlc3BvbnNlIHRvIENsaWVudA0KDQpUaGUgc2VydmVyIE1VU1QgcmVzcG9uZCB0 byB0aGUgY2xpZW50IHdpdGggYSBUS0VZIHF1ZXJ5IHJlc3BvbnNlIHdpdGgNClJDT0RFID0gTk9F UlJPUiwgdGhhdCBjb250YWlucyBhIFRLRVkgcmVjb3JkIGluIHRoZSBhbnN3ZXIgc2VjdGlvbi4N Cg0KSWYgT1VUUFVUIG1ham9yX3N0YXR1cyBpcyBvbmUgb2YgdGhlIGZvbGxvd2luZyBlcnJvcnMg dGhlIGVycm9yIGZpZWxkDQppbiB0aGUgVEtFWSByZWNvcmQgc2V0IHRvIEJBREtFWS4NCg0KICAg ICBHU1NfU19ERUZFQ1RJVkVfVE9LRU4NCiAgICAgR1NTX1NfREVGRUNUSVZFX0NSRURFTlRJQUwN CiAgICAgR1NTX1NfQkFEX1NJRyAoR1NTX1NfQkFEX01JQykNCiAgICAgR1NTX1NfRFVQTElDQVRF X1RPS0VODQogICAgIEdTU19TX09MRF9UT0tFTg0KICAgICBHU1NfU19OT19DUkVEDQogICAgIEdT U19TX0NSRURFTlRJQUxTX0VYUElSRUQNCiAgICAgR1NTX1NfQkFEX0JJTkRJTkdTDQogICAgIEdT U19TX05PX0NPTlRFWFQNCiAgICAgR1NTX1NfQkFEX01FQ0gNCiAgICAgR1NTX1NfRkFJTFVSRQ0K DQpJZiBPVVRQVVQgbWFqb3Jfc3RhdHVzIGlzIHNldCB0byAgR1NTX1NfQ09NUExFVEUgb3INCkdT U19TX0NPTlRJTlVFX05FRURFRCB0aGVuIHNlcnZlciBNVVNUIGFjdCBhcyBkZXNjcmliZWQgYmVs b3cuDQoNCklmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01QTEVURSB0aGUgc2VydmVyIGNvbXBv bmVudCBvZiB0aGUNCm5lZ290aWF0aW9uIGlzIGZpbmlzaGVkLiBJZiBvdXRwdXRfdG9rZW4gaXMg bm9uLU5VTEwsIHRoZW4gaXQgTVVTVCBiZQ0KcmV0dXJuZWQgdG8gdGhlIGNsaWVudCBpbiBhIEtl eSBEYXRhIGZpZWxkIG9mIHRoZSBSREFUQSBpbiBUS0VZLiBUaGUNCmVycm9yIGZpZWxkIGluIHRo ZSBUS0VZIHJlY29yZCBpcyBzZXQgdG8gTk9FUlJPUi4gVGhlIGNvbnRleHQgc3RhdGUNCmlzIGFk dmFuY2VkIHRvIENvbnRleHQgRXN0YWJsaXNoZWQuIFNlY3Rpb24gNC4yIGRpc2N1c3NlcyB0aGUg dXNhZ2Ugb2YNCnRoZSBzZWN1cml0eSBjb250ZXh0Lg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NT X1NfQ09NUExFVEUgYW5kIG91dHB1dF90b2tlbiBpcyBOVUxMLCB0aGVuIHRoZQ0KVEtFWSByZWNv cmQgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50IE1VU1QgYmUgcmV0dXJuZWQgaW4gdGhlIEFuc3dl cg0Kc2VjdGlvbiBvZiB0aGUgcmVzcG9uc2UuIFRoZSBjb250ZXh0IHN0YXRlIGlzIGFkdmFuY2Vk IHRvIENvbnRleHQNCkVzdGFibGlzaGVkLiBTZWN0aW9uIDQuMiBkaXNjdXNzZXMgdGhlIHVzYWdl IG9mIHRoZSBzZWN1cml0eSBjb250ZXh0Lg0KDQpOb3RpY2U6IEVhcmx5IHZlcnNpb25zIG9mIEdT Uy1UU0lHIHByb3RvY29sIGFuZCBpbXBsZW1lbnRhdGlvbg0KcmVxdWlyZWQgdGhhdA0KLSBpZiBt YWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09NUExFVEUsIHRoZW4gc2VydmVyknMgcmVzcG9uc2UgZGVz Y3JpYmVkDQogIGluIHRoaXMgc2VjdGlvbiBpcyBzaWduZWQgd2l0aCBhIFRTSUcgcmVjb3JkOw0K LSB0aGUgc2lnbmF0dXJlIGluIHRoZSBUU0lHIHJlY29yZCBpcyB2ZXJpZmllZCBieSBhIGNsaWVu dCB1c2luZyB0aGUNCiAgcHJvY2VkdXJlIGRldGFpbGVkIGluIHNlY3Rpb24gNSwgU2VuZGluZyBh bmQgVmVyaWZ5aW5nIFNpZ25lZA0KICBNZXNzYWdlczsNCi0gaWYgdGhlIHJlc3BvbnNlIGlzIG5v dCBzaWduZWQgdGhlbiBjbGllbnQgaWdub3JlcyB0aGUgcmVzcG9uc2UgYW5kDQogIGRvZXMgbm90 IGFkdmFuY2UgdGhlIGNvbnRleHQgdG8gQ29udGV4dCBFc3RhYmxpc2hlZC4NCg0KSWYgaW1wbGVt ZW50ZXJzIG9mIHRoZSBHU1MtVFNJRyBzZXJ2ZXJzIGRlY2lkZSB0byBlbmFibGUNCmludGVyb3Bl cmFiaWxpdHkgd2l0aCB0aGUgZWFybHkgdmVyc2lvbnMgb2YgR1NTLVRTSUcgY2xpZW50IA0KDQpF eHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDEyXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJ RyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQppbXBsZW1lbnRhdGlvbnMgKGluY2x1 ZGVkIGluIFdpbmRvd3MgMjAwMCBQcm9mZXNzaW9uYWwsIGFsbCB2ZXJzaW9ucw0Kb2YgV2luZG93 cyAyMDAwIFNlcnZlciwgYWxsIHZlcnNpb25zIG9mIFdpbmRvd3MgWFAsIGFsbCB2ZXJzaW9ucyBv Zg0KV2luZG93cy5OZXQgMjAwMyBTZXJ2ZXIsIEx1Y2VudCBETlMgU2VydmljZSAzLjEgYW5kIFZp dGFsUUlQIDYuMCkgdGhlbg0KdGhleSBtYXkgY29uc2lkZXIgc2lnbmluZyB0aGUgcmVzcG9uc2Ug dG8gc3VjaCBjbGllbnQncyByZXF1ZXN0IGFuZA0KaW5jbHVkaW5nIGEgVFNJRyByZWNvcmQgY29u dGFpbmluZyB0aGUgc2lnbmF0dXJlIGluIGl0cyByZXNwb25zZS4NCkRvaW5nIHRoaXMgaXMgbm90 IGNvbXBsaWFudCB3aXRoIFJGQyAyODQ1IHJlcXVpcmluZyB0aGF0ICJUaGUgc2VydmVyDQpNVVNU IG5vdCBnZW5lcmF0ZSBhIHNpZ25lZCByZXNwb25zZSB0byBhbiB1bnNpZ25lZCByZXF1ZXN0Iiwg YnV0IGFzDQpsb25nIGFzIHRoZXJlIGFyZSBubyBHU1MtVFNJRyBjbGllbnRzIChhbmQgY3VycmVu dGx5IHRoZXJlIGFyZSBubyBzdWNoDQpjbGllbnRzKSByZWplY3RpbmcgcmVzcG9uc2VzIGNvbnRh aW5pbmcgVFNJRyByZWNvcmRzICh3aGljaCBpcyBub3QNCnJlcXVpcmVkIGJ5IFJGQyAyODQ1KSBz ZXJ2ZXIncyBkZXZpYXRpb24gZnJvbSBjb21wbGlhbmNlIHdpdGggUkZDIDI4NDUNCnNob3VsZCBu b3QgY2F1c2UgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcy4NCg0KSWYgbWFqb3Jfc3RhdHVzIGlz IEdTU19TX0NPTlRJTlVFLCB0aGUgc2VydmVyIGNvbXBvbmVudCBvZiB0aGUNCm5lZ290aWF0aW9u IGlzIG5vdCB5ZXQgZmluaXNoZWQuICBUaGUgc2VydmVyIHJlc3BvbmRzIHRvIHRoZSBUS0VZDQpx dWVyeSB3aXRoIGEgc3RhbmRhcmQgcXVlcnkgcmVzcG9uc2UsIHBsYWNpbmcgaW4gdGhlIGFuc3dl ciBzZWN0aW9uIGENClRLRVkgcmVjb3JkIGNvbnRhaW5pbmcgb3V0cHV0X3Rva2VuIGluIHRoZSBL ZXkgRGF0YSBSREFUQSBmaWVsZC4gVGhlDQplcnJvciBmaWVsZCBpbiB0aGUgVEtFWSByZWNvcmQg aXMgc2V0IHRvIE5PRVJST1IuIFRoZSBzZXJ2ZXIgTVVTVCBsaW1pdA0KdGhlIG51bWJlciBvZiB0 aW1lcyB0aGF0IGEgZ2l2ZW4gY29udGV4dCBpcyBhbGxvd2VkIHRvIHJlcGVhdCwgdG8NCnByZXZl bnQgZW5kbGVzcyBsb29waW5nLiBTdWNoIGxpbWl0IFNIT1VMRCBOT1QgZXhjZWVkIHZhbHVlIG9m IDEwLg0KDQpJbiBhbGwgY2FzZXMgZXhjZXB0IGlmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01Q TEVURSBhbmQgb3V0cHV0X3Rva2VuDQppcyBOVUxMIG90aGVyIFRLRVkgcmVjb3JkIGZpZWxkcyBN VVNUIGNvbnRhaW4gdGhlIGZvbGxvd2luZyB2YWx1ZXM6DQogICAgIE5BTUUgPSBrZXlfbmFtZQ0K ICAgICBSREFUQQ0KICAgICAgICBBbGdvcml0aG0gTmFtZSAgICAgID0gZ3NzLXRzaWcNCiAgICAg ICAgTW9kZSAgICAgICAgICAgICAgICA9IDMgKEdTUy1BUEkgbmVnb3RpYXRpb24gLSBwZXIgW1JG QzI5MzBdKQ0KICAgICAgICBLZXkgU2l6ZSAgICAgICAgICAgID0gc2l6ZSBvZiBvdXRwdXRfdG9r ZW4gaW4gb2N0ZXRzDQoNClRoZSByZW1haW5pbmcgZmllbGRzIGluIHRoZSBUS0VZIFJEQVRBLCBp LmUuIEluY2VwdGlvbiwgRXhwaXJhdGlvbiwNCkVycm9yLCBPdGhlciBTaXplIGFuZCBEYXRhIEZp ZWxkcywgTVVTVCBiZSBzZXQgYWNjb3JkaW5nIHRvIFtSRkMyOTMwXS4NCg0KDQo0LjIgQ29udGV4 dCBFc3RhYmxpc2hlZA0KDQpXaGVuIGNvbnRleHQgbmVnb3RpYXRpb24gaXMgY29tcGxldGUsIHRo ZSBoYW5kbGUgY29udGV4dF9oYW5kbGUNCmlzIHVzZWQgZm9yIHRoZSBnZW5lcmF0aW9uIGFuZCB2 ZXJpZmljYXRpb24gb2YgdHJhbnNhY3Rpb24gc2lnbmF0dXJlcy4NClRoZSBoYW5kbGUgaXMgdmFs aWQgZm9yIGEgZmluaXRlIGFtb3VudCBvZiB0aW1lIGRldGVybWluZWQgYnkgdGhlDQp1bmRlcmx5 aW5nIHNlY3VyaXR5IG1lY2hhbmlzbS4gQSBzZXJ2ZXIgTUFZIHVuaWxhdGVyYWxseSB0ZXJtaW5h dGUNCmEgY29udGV4dCBhdCBhbnkgdGltZSAoc2VlIHNlY3Rpb24gNC4yLjEpLg0KDQpTZXJ2ZXIg U0hPVUxEIGxpbWl0IHRoZSBhbW91bnQgb2YgbWVtb3J5IHVzZWQgdG8gY2FjaGUgZXN0YWJsaXNo ZWQNCmNvbnRleHRzLg0KDQpUaGUgcHJvY2VkdXJlcyBmb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5n IHNpZ25lZCBtZXNzYWdlcyBhcmUgZ2l2ZW4gaW4NCnNlY3Rpb24gNSwgU2VuZGluZyBhbmQgVmVy aWZ5aW5nIFNpZ25lZCBNZXNzYWdlcy4NCg0KDQo0LjIuMSBUZXJtaW5hdGluZyBhIENvbnRleHQN Cg0KQSBzZXJ2ZXIgY2FuIHRlcm1pbmF0ZSBhbnkgZXN0YWJsaXNoZWQgY29udGV4dCBhdCBhbnkg dGltZS4gIFRoZQ0Kc2VydmVyIE1BWSBoaW50IHRvIHRoZSBjbGllbnQgdGhhdCB0aGUgY29udGV4 dCBpcyBiZWluZyBkZWxldGVkIGJ5DQppbmNsdWRpbmcgYSBUS0VZIFJSIGluIGEgcmVzcG9uc2Ug d2l0aCB0aGUgTW9kZSBmaWVsZCBzZXQgdG8gNSwgaS5lLg0KImtleSBkZWxldGlvbiIgW1JGQzI5 MzBdLg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQpBbiBhY3RpdmUgY29u dGV4dCBpcyBkZWxldGVkIGJ5IGNhbGxpbmcgR1NTX0RlbGV0ZV9zZWNfY29udGV4dA0KcHJvdmlk aW5nIHRoZSBhc3NvY2lhdGVkIGNvbnRleHRfaGFuZGxlLg0KDQoNCjUuIFNlbmRpbmcgYW5kIFZl cmlmeWluZyBTaWduZWQgTWVzc2FnZXMNCg0KNS4xIFNlbmRpbmcgYSBTaWduZWQgTWVzc2FnZSAt IENhbGwgR1NTX0dldE1JQw0KDQpUaGUgcHJvY2VkdXJlIGZvciBzZW5kaW5nIGEgc2lnbmF0dXJl LXByb3RlY3RlZCBtZXNzYWdlIGlzIHNwZWNpZmllZA0KaW4gW1JGQzI4NDVdLiAgVGhlIGRhdGEg dG8gYmUgcGFzc2VkIHRvIHRoZSBzaWduYXR1cmUgcm91dGluZSBpbmNsdWRlcw0KdGhlIHdob2xl IEROUyBtZXNzYWdlIHdpdGggc3BlY2lmaWMgVFNJRyB2YXJpYWJsZXMgYXBwZW5kZWQuICBGb3Ig dGhlDQpleGFjdCBmb3JtYXQsIHNlZSBbUkZDMjg0NV0uICBGb3IgdGhpcyBwcm90b2NvbCwgdXNl IHRoZSBmb2xsb3dpbmcNClRTSUcgdmFyaWFibGUgdmFsdWVzOg0KDQogICBUU0lHIFJlY29yZA0K ICAgICBOQU1FID0ga2V5X25hbWUgdGhhdCBpZGVudGlmaWVzIHRoaXMgY29udGV4dA0KICAgICBS REFUQQ0KICAgICAgICBBbGdvcml0aG0gTmFtZSA9IGdzcy10c2lnDQoNCkFzc2lnbiB0aGUgcmVt YWluaW5nIGZpZWxkcyBpbiB0aGUgVFNJRyBSREFUQSBhcHByb3ByaWF0ZSB2YWx1ZXMNCmFzIGRl c2NyaWJlZCBpbiBbUkZDMjg0NV0uDQoNClRoZSBzaWduYXR1cmUgaXMgZ2VuZXJhdGVkIGJ5IGNh bGxpbmcgR1NTX0dldE1JQy4gVGhlIGZvbGxvd2luZyBpbnB1dA0KcGFyYW1ldGVycyBNVVNUIGJl IHVzZWQuIFRoZSBvdXRjb21lIG9mIHRoZSBjYWxsIGlzIGluZGljYXRlZCB3aXRoIHRoZQ0Kb3V0 cHV0IHZhbHVlcyBzcGVjaWZpZWQgYmVsb3cuICBDb25zdWx0IFNlY3Rpb25zIDIuMy4xICJHU1Nf R2V0TUlDDQpjYWxsIiBvZiB0aGUgUkZDIDI3NDNbUkZDMjc0M10gZm9yIHN5bnRheCBkZWZpbml0 aW9ucy4NCg0KICAgSU5QVVRTDQogICAgIENPTlRFWFQgSEFORExFIGNvbnRleHRfaGFuZGxlID0g Y29udGV4dF9oYW5kbGUgZm9yIGtleV9uYW1lDQogICAgIE9DVEVUIFNUUklORyAgIG1lc3NhZ2Ug ICAgICAgID0gb3V0Z29pbmcgbWVzc2FnZSBwbHVzIFRTSUcNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB2YXJpYWJsZXMgKHBlciBbUkZDMjg0NV0pDQogICAgIElOVEVHRVIg cW9wX3JlcSAgICAgICAgICAgICAgID0gMCAoMCByZXF1ZXN0cyBhIGRlZmF1bHQNCiAgICAgICAg IHZhbHVlKS4gQ2FsbGVyIE1BWSBpbnN0ZWFkIHNwZWNpZnkgb3RoZXIgdmFsaWQgdmFsdWUgKGZv cg0KICAgICAgICAgZGV0YWlscyBzZWUgU2VjdGlvbiAxLjIuNCBpbiBbUkZDMjc0M10pDQoNCiAg IE9VVFBVVFMNCiAgICAgSU5URUdFUiAgICAgICAgbWFqb3Jfc3RhdHVzDQogICAgIElOVEVHRVIg ICAgICAgIG1pbm9yX3N0YXR1cw0KICAgICBPQ1RFVCBTVFJJTkcgICBwZXJfbXNnX3Rva2VuDQoN CklmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01QTEVURSwgdGhlbiBzaWduYXR1cmUgZ2VuZXJh dGlvbg0Kc3VjY2VlZGVkLiAgVGhlIHNpZ25hdHVyZSBpbiBwZXJfbXNnX3Rva2VuIGlzIGluc2Vy dGVkIGludG8gdGhlDQpTaWduYXR1cmUgZmllbGQgb2YgdGhlIFRTSUcgUlIgYW5kIHRoZSBtZXNz YWdlIGlzIHRyYW5zbWl0dGVkLg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQ09OVEVYVF9F WFBJUkVELCBHU1NfU19DUkVERU5USUFMU19FWFBJUkVEIG9yDQpHU1NfU19GQUlMVVJFIHRoZSBj YWxsZXIgTVVTVCBkZWxldGUgdGhlIHNlY3VyaXR5IGNvbnRleHQsIHJldHVybiB0byB0aGUNCnVu aW5pdGlhbGl6ZWQgc3RhdGUgYW5kIFNIT1VMRCBuZWdvdGlhdGUgYSBuZXcgc2VjdXJpdHkgY29u dGV4dCwgYXMNCmRlc2NyaWJlZCBhYm92ZSBpbiBTZWN0aW9uIDMuMQ0KDQpJZiBtYWpvcl9zdGF0 dXMgaXMgR1NTX1NfTk9fQ09OVEVYVCwgdGhlIGNhbGxlciBNVVNUIHJlbW92ZSB0aGUgZW50cnkN CmZvciBrZXlfbmFtZSBmcm9tIHRoZSAodGFyZ2V0XyBuYW1lLCBrZXlfbmFtZSwgY29udGV4dF9o YW5kbGUpIG1hcHBpbmcNCnRhYmxlLCByZXR1cm4gdG8gdGhlIHVuaW5pdGlhbGl6ZWQgc3RhdGUg YW5kIFNIT1VMRCBuZWdvdGlhdGUgYSBuZXcNCnNlY3VyaXR5IGNvbnRleHQsIGFzIGRlc2NyaWJl ZCBhYm92ZSBpbiBTZWN0aW9uIDMuMQ0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDQpJTlRFUk5FVC1EUkFG VCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAw Mg0KDQpJZiBtYWpvcl9zdGF0dXMgaXMgR1NTX1NfQkFEX1FPUCwgdGhlIGNhbGxlciBTSE9VTEQg cmVwZWF0IHRoZQ0KR1NTX0dldE1JQyBjYWxsIHdpdGggYWxsb3dlZCBRT1AgdmFsdWUuIFRoZSBu dW1iZXIgb2Ygc3VjaCByZXBldGl0aW9ucw0KTVVTVCBiZSBsaW1pdGVkIHRvIHByZXZlbnQgaW5m aW5pdGUgbG9vcHMuDQoNCg0KNS4yIFZlcmlmeWluZyBhIFNpZ25lZCBNZXNzYWdlIC0gQ2FsbCBH U1NfVmVyaWZ5TUlDDQoNClRoZSBwcm9jZWR1cmUgZm9yIHZlcmlmeWluZyBhIHNpZ25hdHVyZS1w cm90ZWN0ZWQgbWVzc2FnZSBpcyBzcGVjaWZpZWQNCmluIFtSRkMyODQ1XS4NClRoZSBOQU1FIG9m IHRoZSBUU0lHIHJlY29yZCBkZXRlcm1pbmVzIHdoaWNoIGNvbnRleHRfaGFuZGxlIG1hcHMgdG8N CnRoZSBjb250ZXh0IHRoYXQgTVVTVCBiZSB1c2VkIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlLiAg SWYgdGhlIE5BTUUNCmRvZXMgbm90IG1hcCB0byBhbiBlc3RhYmxpc2hlZCBjb250ZXh0LCB0aGUg c2VydmVyIE1VU1Qgc2VuZCBhDQpzdGFuZGFyZCBUU0lHIGVycm9yIHJlc3BvbnNlIHRvIHRoZSBj bGllbnQgaW5kaWNhdGluZyBCQURLRVkgaW4gdGhlDQpUU0lHIGVycm9yIGZpZWxkIChhcyBkZXNj cmliZWQgaW4gW1JGQzI4NDVdKS4NCg0KRm9yIHRoZSBHU1MgYWxnb3JpdGhtLCBhIHNpZ25hdHVy ZSBpcyB2ZXJpZmllZCBieSB1c2luZyBHU1NfVmVyaWZ5TUlDOg0KICAgSU5QVVRTDQogICAgIENP TlRFWFQgSEFORExFIGNvbnRleHRfaGFuZGxlID0gY29udGV4dF9oYW5kbGUgZm9yIGtleV9uYW1l DQogICAgIE9DVEVUIFNUUklORyAgIG1lc3NhZ2UgICAgICAgID0gaW5jb21pbmcgbWVzc2FnZSBw bHVzIFRTSUcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2YXJpYWJsZXMg KHBlciBbUkZDMjg0NV0pDQogICAgIE9DVEVUIFNUUklORyAgIHBlcl9tc2dfdG9rZW4gID0gU2ln bmF0dXJlIGZpZWxkIGZyb20gVFNJRyBSUg0KDQogICBPVVRQVVRTDQogICAgIElOVEVHRVIgICAg ICAgIG1ham9yX3N0YXR1cw0KICAgICBJTlRFR0VSICAgICAgICBtaW5vcl9zdGF0dXMNCiAgICAg SU5URUdFUiAgICAgICAgcW9wX3N0YXRlDQoNCklmIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT01Q TEVURSwgdGhlIHNpZ25hdHVyZSBpcyBhdXRoZW50aWMgYW5kIHRoZQ0KbWVzc2FnZSB3YXMgZGVs aXZlcmVkIGludGFjdC4gIFBlciBbUkZDMjg0NV0sIHRoZSB0aW1lciB2YWx1ZXMgb2YgdGhlDQpU U0lHIHJlY29yZCBNVVNUIGFsc28gYmUgdmFsaWQgYmVmb3JlIGNvbnNpZGVyaW5nIHRoZSBtZXNz YWdlIHRvIGJlDQphdXRoZW50aWMuICBUaGUgY2FsbGVyIE1VU1Qgbm90IGFjdCBvbiB0aGUgcmVx dWVzdCBvciByZXNwb25zZSBpbiB0aGUNCm1lc3NhZ2UgdW50aWwgdGhlc2UgY2hlY2tzIGFyZSB2 ZXJpZmllZC4NCg0KV2hlbiBhIHNlcnZlciBpcyBwcm9jZXNzaW5nIGEgY2xpZW50IHJlcXVlc3Qs DQp0aGUgc2VydmVyIE1VU1Qgc2VuZCBhIHN0YW5kYXJkIFRTSUcgZXJyb3IgcmVzcG9uc2UgdG8g dGhlIGNsaWVudA0KaW5kaWNhdGluZyBCQURLRVkgaW4gdGhlIFRTSUcgZXJyb3IgZmllbGQgYXMg ZGVzY3JpYmVkIGluIFtSRkMyODQ1XSwNCmlmIG1ham9yX3N0YXR1cyBpcyBzZXQgdG8gb25lIG9m IHRoZSBmb2xsb3dpbmcgdmFsdWVzDQogICAgIEdTU19TX0RFRkVDVElWRV9UT0tFTg0KICAgICBH U1NfU19CQURfU0lHIChHU1NfU19CQURfTUlDKQ0KICAgICBHU1NfU19EVVBMSUNBVEVfVE9LRU4N CiAgICAgR1NTX1NfT0xEX1RPS0VODQogICAgIEdTU19TX1VOU0VRX1RPS0VODQogICAgIEdTU19T X0dBUF9UT0tFTg0KICAgICBHU1NfU19DT05URVhUX0VYUElSRUQNCiAgICAgR1NTX1NfTk9fQ09O VEVYVA0KICAgICBHU1NfU19GQUlMVVJFDQoNCg0KSWYgdGhlIHRpbWVyIHZhbHVlcyBvZiB0aGUg VFNJRyByZWNvcmQgYXJlIGludmFsaWQsIHRoZSBtZXNzYWdlIE1VU1QNCk5PVCBiZSBjb25zaWRl cmVkIGF1dGhlbnRpYy4gSWYgdGhpcyBlcnJvciBjaGVja2luZyBmYWlscyB3aGVuIGEgc2VydmVy DQppcyBwcm9jZXNzaW5nIGEgY2xpZW50IHJlcXVlc3QsIHRoZSBhcHByb3ByaWF0ZSBlcnJvciBy ZXNwb25zZSBNVVNUIGJlDQpzZW50IHRvIHRoZSBjbGllbnQgYWNjb3JkaW5nIHRvIFtSRkMyODQ1 XS4NCg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQoNCjYuIEV4YW1wbGUg dXNhZ2Ugb2YgR1NTLVRTSUcgYWxnb3JpdGhtDQoNClRoaXMgU2VjdGlvbiBkZXNjcmliZXMgYW4g ZXhhbXBsZSB3aGVyZSBhIENsaWVudCwgY2xpZW50LmV4YW1wbGUuY29tLA0KYW5kIGEgU2VydmVy LCBzZXJ2ZXIuZXhhbXBsZS5jb20sIGVzdGFibGlzaCBhIHNlY3VyaXR5IGNvbnRleHQgYWNjb3Jk aW5nDQp0byB0aGUgYWxnb3JpdGhtIGRlc2NyaWJlZCBhYm92ZS4NCg0KDQogIEkuIENsaWVudCBp bml0aWFsaXplcyBzZWN1cml0eSBjb250ZXh0IG5lZ290aWF0aW9uDQogIFRvIGVzdGFibGlzaCBh IHNlY3VyaXR5IGNvbnRleHQgd2l0aCBhIHNlcnZlciwgc2VydmVyLmV4YW1wbGUuY29tLCB0aGUN CiAgQ2xpZW50IGNhbGxzIEdTU19Jbml0X3NlY19jb250ZXh0IHdpdGggdGhlIGZvbGxvd2luZyBw YXJhbWV0ZXJzDQogIChOb3RlIHRoYXQgc29tZSBJTlBVVCBhbmQgT1VUUFVUIHBhcmFtZXRlcnMg bm90IGNyaXRpY2FsIGZvciB0aGlzDQogIGFsZ29yaXRobSBhcmUgbm90IGRlc2NyaWJlZCBpbiB0 aGlzIGV4YW1wbGUpDQogICAgIENPTlRFWFQgSEFORExFIGlucHV0X2NvbnRleHRfaGFuZGxlICA9 IDANCiAgICAgSU5URVJOQUwgTkFNRSAgdGFyZ19uYW1lICAgICAgICAgICAgID0gIkROU0BzZXJ2 ZXIuZXhhbXBsZS5jb20iDQogICAgIE9DVEVUIFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAg ICA9IE5VTEwNCiAgICAgQk9PTEVBTiAgICAgICAgcmVwbGF5X2RldF9yZXFfZmxhZyAgID0gVFJV RQ0KICAgICBCT09MRUFOICAgICAgICBtdXR1YWxfcmVxX2ZsYWcgICAgICAgPSBUUlVFDQoNCiAg VGhlIE9VVFBVVFMgcGFyYW1ldGVycyByZXR1cm5lZCBieSBHU1NfSW5pdF9zZWNfY29udGV4dCBp bmNsdWRlDQogICAgIElOVEVHRVIgICAgICAgIG1ham9yX3N0YXR1cyA9IEdTU19TX0NPTlRJTlVF X05FRURFRA0KICAgICBDT05URVhUIEhBTkRMRSBvdXRwdXRfY29udGV4dF9oYW5kbGUgY29udGV4 dF9oYW5kbGUNCiAgICAgT0NURVQgU1RSSU5HICAgb3V0cHV0X3Rva2VuIG91dHB1dF90b2tlbg0K ICAgICBCT09MRUFOICAgICAgICByZXBsYXlfZGV0X3N0YXRlID0gVFJVRQ0KICAgICBCT09MRUFO ICAgICAgICBtdXR1YWxfc3RhdGUgPSBUUlVFDQoNCiAgQ2xpZW50IHZlcmlmaWVzIHRoYXQgcmVw bGF5X2RldF9zdGF0ZSBhbmQgbXV0dWFsX3N0YXRlIHZhbHVlcyBhcmUNCiAgVFJVRS4gU2luY2Ug dGhlIG1ham9yX3N0YXR1cyBpcyBHU1NfU19DT05USU5VRV9ORUVERUQsIHdoaWNoIGlzIGENCiAg c3VjY2VzcyBPVVRQVVQgbWFqb3Jfc3RhdHVzIHZhbHVlLCBjbGllbnQgc3RvcmVzIGNvbnRleHRf aGFuZGxlIHRoYXQNCiAgbWFwcyB0byAiRE5TQHNlcnZlci5leGFtcGxlLmNvbSIgYW5kIHByb2Nl ZWRzIHRvIHRoZSBuZXh0IHN0ZXAuDQoNCg0KICBJSS4gQ2xpZW50IHNlbmRzIGEgcXVlcnkgd2l0 aCBRVFlQRSA9IFRLRVkgdG8gc2VydmVyDQogIENsaWVudCBzZW5kcyBhIHF1ZXJ5IHdpdGggUVRZ UEUgPSBUS0VZIGZvciBhIGNsaWVudC1nZW5lcmF0ZWQgZ2xvYmFsbHkNCiAgdW5pcXVlIGRvbWFp biBuYW1lIHN0cmluZywgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIuZXhhbXBsZS5jb20u DQogIFF1ZXJ5IGNvbnRhaW5zIGEgVEtFWSByZWNvcmQgaW4gaXRzIEFkZGl0aW9uYWwgcmVjb3Jk cyBzZWN0aW9uIHdpdGgNCiAgdGhlIGZvbGxvd2luZyBmaWVsZHMgKE5vdGUgdGhhdCBzb21lIGZp ZWxkcyBub3Qgc3BlY2lmaWMgdG8gdGhpcw0KICBhbGdvcml0aG0gYXJlIG5vdCBzcGVjaWZpZWQp DQoNCiAgICAgTkFNRSA9IDc4OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUuY29t Lg0KICAgICBSREFUQQ0KICAgICAgICBBbGdvcml0aG0gTmFtZSAgICAgID0gZ3NzLXRzaWcNCiAg ICAgICAgTW9kZSAgICAgICAgICAgICAgICA9IDMgKEdTUy1BUEkgbmVnb3RpYXRpb24gLSBwZXIg W1JGQzI5MzBdKQ0KICAgICAgICBLZXkgU2l6ZSAgICAgICAgICAgID0gc2l6ZSBvZiBvdXRwdXRf dG9rZW4gaW4gb2N0ZXRzDQogICAgICAgIEtleSBEYXRhICAgICAgICAgICAgPSBvdXRwdXRfdG9r ZW4NCg0KICBBZnRlciB0aGUga2V5X25hbWUgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIu ZXhhbXBsZS5jb20uDQogIGlzIGdlbmVyYXRlZCBpdCBpcyBzdG9yZWQgaW4gdGhlIGNsaWVudCdz ICh0YXJnZXRfbmFtZSwga2V5X25hbWUsDQogIGNvbnRleHRfaGFuZGxlKSBtYXBwaW5nIHRhYmxl Lg0KDQoNCg0KDQoNCkV4cGlyZXMgSmFudWFyeSAyMSwgMjAwMyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgICAg ICAgICAgIEdTUy1UU0lHICAgICAgICAgICAgICAgICBKdWx5IDIxLCAyMDAyDQoNCg0KICBJSUku IFNlcnZlciByZWNlaXZlcyBhIHF1ZXJ5IHdpdGggUVRZUEUgPSBUS0VZDQogIFdoZW4gc2VydmVy IHJlY2VpdmVzIGEgcXVlcnkgd2l0aCBRVFlQRSA9IFRLRVksIHRoZSBzZXJ2ZXIgdmVyaWZpZXMN CiAgdGhhdCBNb2RlIGFuZCBBbGdvcml0aG0gZmllbGRzIGluIHRoZSBUS0VZIHJlY29yZCBpbiB0 aGUgQWRkaXRpb25hbA0KICByZWNvcmRzIHNlY3Rpb24gb2YgdGhlIHF1ZXJ5IGFyZSBzZXQgdG8g MyBhbmQgImdzcy10c2lnIiByZXNwZWN0aXZlbHkuDQogIEl0IGZpbmRzIHRoYXQgdGhlIGtleV9u YW1lIDc4OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUuY29tLg0KICBpcyBub3Qg bGlzdGVkIGluIGl0cyAoa2V5X25hbWUsIGNvbnRleHRfaGFuZGxlKSBtYXBwaW5nIHRhYmxlLg0K DQoNCiAgSVYuIFNlcnZlciBjYWxscyBHU1NfQWNjZXB0X3NlY19jb250ZXh0DQogIFRvIGNvbnRp bnVlIHNlY3VyaXR5IGNvbnRleHQgbmVnb3RpYXRpb24gc2VydmVyIGNhbGxzDQogIEdTU19BY2Nl cHRfc2VjX2NvbnRleHQgd2l0aCB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgKE5vdGUgdGhhdCBz b21lDQogIElOUFVUIGFuZCBPVVRQVVQgcGFyYW1ldGVycyBub3QgY3JpdGljYWwgZm9yIHRoaXMg YWxnb3JpdGhtIGFyZSBub3QNCiAgZGVzY3JpYmVkIGluIHRoaXMgZXhhbXBsZSkNCiAgIElOUFVU Uw0KICAgICBDT05URVhUIEhBTkRMRSBpbnB1dF9jb250ZXh0X2hhbmRsZSAgPSAwDQogICAgIE9D VEVUIFNUUklORyAgIGlucHV0X3Rva2VuICAgICAgICAgICA9IHRva2VuIHNwZWNpZmllZCBpbiB0 aGUgS2V5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWVsZCBmcm9tIFRLRVkgUlIg KGZyb20gQWRkaXRpb25hbA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjb3JkcyBz ZWN0aW9uIG9mIHRoZSBjbGllbnQncyBxdWVyeSkNCiAgVGhlIE9VVFBVVFMgcGFyYW1ldGVycyBy ZXR1cm5lZCBieSBHU1NfQWNjZXB0X3NlY19jb250ZXh0IGluY2x1ZGUNCiAgICAgSU5URUdFUiAg ICAgICAgbWFqb3Jfc3RhdHVzID0gR1NTX1NfQ09OVElOVUVfTkVFREVEDQogICAgIENPTlRFWFRf SEFORExFIG91dHB1dF9jb250ZXh0X2hhbmRsZSBjb250ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBT VFJJTkcgICBvdXRwdXRfdG9rZW4gb3V0cHV0X3Rva2VuDQoNCiAgU2VydmVyIHN0b3JlcyB0aGUg bWFwcGluZyBvZiB0aGUNCiAgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIuZXhhbXBsZS5j b20uIHRvIE9VVFBVVCBjb250ZXh0X2hhbmRsZQ0KICBpbiBpdHMgKGtleV9uYW1lLCBjb250ZXh0 X2hhbmRsZSkgbWFwcGluZyB0YWJsZS4NCg0KDQogIFYuIFNlcnZlciByZXNwb25kcyB0byB0aGUg VEtFWSBxdWVyeQ0KICBTaW5jZSB0aGUgbWFqb3Jfc3RhdHVzID0gR1NTX1NfQ09OVElOVUVfTkVF REVEIGluIHRoZSBsYXN0IHNlcnZlcidzDQogIGNhbGwgdG8gR1NTX0FjY2VwdF9zZWNfY29udGV4 dCwgdGhlIHNlcnZlciByZXNwb25kcyB0byB0aGUgVEtFWSBxdWVyeQ0KICBwbGFjaW5nIGluIHRo ZSBhbnN3ZXIgc2VjdGlvbiBhIFRLRVkgcmVjb3JkIGNvbnRhaW5pbmcgb3V0cHV0X3Rva2VuIGlu DQogIHRoZSBLZXkgRGF0YSBSREFUQSBmaWVsZC4gVGhlIGVycm9yIGZpZWxkIGluIHRoZSBUS0VZ IHJlY29yZCBpcyBzZXQgdG8NCiAgMC4gVGhlIFJDT0RFIGluIHRoZSBxdWVyeSByZXNwb25zZSBp cyBzZXQgdG8gTk9FUlJPUi4NCg0KDQogIFZJLiBDbGllbnQgcHJvY2Vzc2VzIHRva2VuIHJldHVy bmVkIGJ5IHNlcnZlcg0KICBXaGVuIHRoZSBjbGllbnQgcmVjZWl2ZXMgdGhlIFRLRVkgcXVlcnkg cmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyLCB0aGUNCiAgY2xpZW50IGNhbGxzIEdTU19Jbml0X3Nl Y19jb250ZXh0IHdpdGggdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIChOb3RlDQogIHRoYXQgc29t ZSBJTlBVVCBhbmQgT1VUUFVUIHBhcmFtZXRlcnMgbm90IGNyaXRpY2FsIGZvciB0aGlzIGFsZ29y aXRobQ0KICBhcmUgbm90IGRlc2NyaWJlZCBpbiB0aGlzIGV4YW1wbGUpDQogICAgIENPTlRFWFQg SEFORExFIGlucHV0X2NvbnRleHRfaGFuZGxlICA9IHRoZSBjb250ZXh0X2hhbmRsZSBzdG9yZWQN CiAgICAgICAgICBpbiB0aGUgY2xpZW50J3MgbWFwcGluZyB0YWJsZSBlbnRyeSAoRE5TQHNlcnZl ci5leGFtcGxlLmNvbS4sDQogICAgICAgICAgNzg5LmNsaWVudC5leGFtcGxlLmNvbS5zZXJ2ZXIu ZXhhbXBsZS5jb20uLCBjb250ZXh0X2hhbmRsZSkNCiAgICAgSU5URVJOQUwgTkFNRSAgdGFyZ19u YW1lICAgICAgICAgICAgID0gIkROU0BzZXJ2ZXIuZXhhbXBsZS5jb20iDQogICAgIE9DVEVUIFNU UklORyAgIGlucHV0X3Rva2VuICAgICAgICAgICA9IHRva2VuIGZyb20gS2V5IGZpZWxkIG9mIFRL RVkNCiAgICAgICAgICByZWNvcmQgZnJvbSB0aGUgQW5zd2VyIHNlY3Rpb24gb2YgdGhlIHNlcnZl cidzIHJlc3BvbnNlDQogICAgIEJPT0xFQU4gICAgICAgIHJlcGxheV9kZXRfcmVxX2ZsYWcgICA9 IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0dWFsX3JlcV9mbGFnICAgICAgID0gVFJVRQ0K DQoNCg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQogIFRoZSBPVVRQVVRT IHBhcmFtZXRlcnMgcmV0dXJuZWQgYnkgR1NTX0luaXRfc2VjX2NvbnRleHQgaW5jbHVkZQ0KICAg ICBJTlRFR0VSICAgICAgICBtYWpvcl9zdGF0dXMgPSBHU1NfU19DT01QTEVURQ0KICAgICBDT05U RVhUIEhBTkRMRSBvdXRwdXRfY29udGV4dF9oYW5kbGUgPSBjb250ZXh0X2hhbmRsZQ0KICAgICBP Q1RFVCBTVFJJTkcgICBvdXRwdXRfdG9rZW4gPSBvdXRwdXRfdG9rZW4NCiAgICAgQk9PTEVBTiAg ICAgICAgcmVwbGF5X2RldF9zdGF0ZSA9IFRSVUUNCiAgICAgQk9PTEVBTiAgICAgICAgbXV0dWFs X3N0YXRlID0gVFJVRQ0KDQogIFNpbmNlIHRoZSBtYWpvcl9zdGF0dXMgaXMgc2V0IHRvIEdTU19T X0NPTVBMRVRFIHRoZSBjbGllbnQgc2lkZQ0KICBzZWN1cml0eSBjb250ZXh0IGlzIGVzdGFibGlz aGVkLCBidXQgc2luY2UgdGhlIG91dHB1dF90b2tlbiBpcyBub3QNCiAgTlVMTCBjbGllbnQgTVVT VCBzZW5kIGEgVEtFWSBxdWVyeSB0byB0aGUgc2VydmVyIGFzIGRlc2NyaWJlZCBiZWxvdy4NCg0K DQogIFZJSS4gQ2xpZW50IHNlbmRzIGEgcXVlcnkgd2l0aCBRVFlQRSA9IFRLRVkgdG8gc2VydmVy DQogIENsaWVudCBzZW5kcyB0byB0aGUgc2VydmVyIGEgVEtFWSBxdWVyeSBmb3IgdGhlDQogIDc4 OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUuY29tLiBuYW1lLiBRdWVyeSBjb250 YWlucyBhIFRLRVkNCiAgcmVjb3JkIGluIGl0cyBBZGRpdGlvbmFsIHJlY29yZHMgc2VjdGlvbiB3 aXRoIHRoZSBmb2xsb3dpbmcgZmllbGRzDQogIChOb3RlIHRoYXQgc29tZSBJTlBVVCBhbmQgT1VU UFVUIHBhcmFtZXRlcnMgbm90IGNyaXRpY2FsIHRvIHRoaXMNCiAgYWxnb3JpdGhtIGFyZSBub3Qg ZGVzY3JpYmVkIGluIHRoaXMgZXhhbXBsZSkNCiAgICAgTkFNRSA9IDc4OS5jbGllbnQuZXhhbXBs ZS5jb20uc2VydmVyLmV4YW1wbGUuY29tLg0KICAgICBSREFUQQ0KICAgICAgICBBbGdvcml0aG0g TmFtZSAgICAgID0gZ3NzLXRzaWcNCiAgICAgICAgTW9kZSAgICAgICAgICAgICAgICA9IDMgKEdT Uy1BUEkgbmVnb3RpYXRpb24gLSBwZXIgW1JGQzI5MzBdKQ0KICAgICAgICBLZXkgU2l6ZSAgICAg ICAgICAgID0gc2l6ZSBvZiBvdXRwdXRfdG9rZW4gaW4gb2N0ZXRzDQogICAgICAgIEtleSBEYXRh ICAgICAgICAgICAgPSBvdXRwdXRfdG9rZW4NCg0KDQogIFZJSUkuIFNlcnZlciByZWNlaXZlcyBh IFRLRVkgcXVlcnkNCiAgV2hlbiB0aGUgc2VydmVyIHJlY2VpdmVzIGEgVEtFWSBxdWVyeSwgdGhl IHNlcnZlciB2ZXJpZmllcyB0aGF0IE1vZGUNCiAgYW5kIEFsZ29yaXRobSBmaWVsZHMgaW4gdGhl IFRLRVkgcmVjb3JkIGluIHRoZSBBZGRpdGlvbmFsIHJlY29yZHMNCiAgc2VjdGlvbiBvZiB0aGUg cXVlcnkgYXJlIHNldCB0byAzIGFuZCBnc3MtdHNpZywgcmVwZWN0aXZlbHkuIEl0DQogIGZpbmRz IHRoYXQgdGhlIGtleV9uYW1lIDc4OS5jbGllbnQuZXhhbXBsZS5jb20uc2VydmVyLmV4YW1wbGUu Y29tLiBpcw0KICBsaXN0ZWQgaW4gaXRzIChrZXlfbmFtZSwgY29udGV4dF9oYW5kbGUpIG1hcHBp bmcgdGFibGUuDQoNCg0KICBJWC4gU2VydmVyIGNhbGxzIEdTU19BY2NlcHRfc2VjX2NvbnRleHQN CiAgVG8gY29udGludWUgc2VjdXJpdHkgY29udGV4dCBuZWdvdGlhdGlvbiBzZXJ2ZXIgY2FsbHMN CiAgR1NTX0FjY2VwdF9zZWNfY29udGV4dCB3aXRoIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyAo Tm90ZSB0aGF0IHNvbWUNCiAgSU5QVVQgYW5kIE9VVFBVVCBwYXJhbWV0ZXJzIG5vdCBjcml0aWNh bCBmb3IgdGhpcyBhbGdvcml0aG0gYXJlIG5vdA0KICBkZXNjcmliZWQgaW4gdGhpcyBleGFtcGxl KQ0KICAgSU5QVVRTDQogICAgIENPTlRFWFQgSEFORExFIGlucHV0X2NvbnRleHRfaGFuZGxlICA9 IGNvbnRleHRfaGFuZGxlIGZyb20gdGhlDQogICAgICAgICAgICg3ODkuY2xpZW50LmV4YW1wbGUu Y29tLnNlcnZlci5leGFtcGxlLmNvbS4sIGNvbnRleHRfaGFuZGxlKQ0KICAgICAgICAgICBlbnRy eSBpbiB0aGUgc2VydmVyJ3MgbWFwcGluZyB0YWJsZQ0KICAgICBPQ1RFVCBTVFJJTkcgICBpbnB1 dF90b2tlbiAgICAgICAgICAgPSB0b2tlbiBzcGVjaWZpZWQgaW4gdGhlIEtleQ0KICAgICAgICAg ICBmaWVsZCBvZiBUS0VZIFJSIChmcm9tIEFkZGl0aW9uYWwgcmVjb3JkcyBTZWN0aW9uIG9mDQog ICAgICAgICAgIHRoZSBjbGllbnQncyBxdWVyeSkNCg0KICBUaGUgT1VUUFVUUyBwYXJhbWV0ZXJz IHJldHVybmVkIGJ5IEdTU19BY2NlcHRfc2VjX2NvbnRleHQgaW5jbHVkZQ0KICAgICBJTlRFR0VS ICAgICAgICBtYWpvcl9zdGF0dXMgPSBHU1NfU19DT01QTEVURQ0KICAgICBDT05URVhUX0hBTkRM RSBvdXRwdXRfY29udGV4dF9oYW5kbGUgPSBjb250ZXh0X2hhbmRsZQ0KICAgICBPQ1RFVCBTVFJJ TkcgICBvdXRwdXRfdG9rZW4gPSBOVUxMDQoNCg0KDQpFeHBpcmVzIEphbnVhcnkgMjEsIDIwMDMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDQpJTlRFUk5F VC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAgICAgICAgICAgICAgSnVseSAy MSwgMjAwMg0KDQogIFNpbmNlIG1ham9yX3N0YXR1cyA9IEdTU19TX0NPTVBMRVRFLCB0aGUgc2Vj dXJpdHkgY29udGV4dCBvbiB0aGUNCiAgc2VydmVyIHNpZGUgaXMgZXN0YWJsaXNoZWQsIGJ1dCB0 aGUgc2VydmVyIHN0aWxsIG5lZWRzIHRvIHJlc3BvbmQgdG8NCiAgdGhlIGNsaWVudCdzIFRLRVkg cXVlcnksIGFzIGRlc2NyaWJlZCBiZWxvdy4gVGhlIHNlY3VyaXR5IGNvbnRleHQNCiAgc3RhdGUg aXMgYWR2YW5jZWQgdG8gQ29udGV4dCBFc3RhYmxpc2hlZC4NCg0KDQogIFguIFNlcnZlciByZXNw b25kcyB0byB0aGUgVEtFWSBxdWVyeQ0KICBTaW5jZSB0aGUgbWFqb3Jfc3RhdHVzID0gR1NTX1Nf Q09NUExFVEUgaW4gdGhlIGxhc3Qgc2VydmVyJ3MgY2FsbCB0bw0KICBHU1NfQWNjZXB0X3NlY19j b250ZXh0IGFuZCB0aGUgb3V0cHV0X3Rva2VuIGlzIE5VTEwsIHRoZSBzZXJ2ZXINCiAgcmVzcG9u ZHMgdG8gdGhlIFRLRVkgcXVlcnkgcGxhY2luZyBpbiB0aGUgYW5zd2VyIHNlY3Rpb24gYSBUS0VZ IHJlY29yZA0KICB0aGF0IHdhcyBzZW50IGJ5IHRoZSBjbGllbnQgaW4gdGhlIEFkZGl0aW9uYWwg cmVjb3JkcyBzZWN0aW9uIG9mIHRoZQ0KICBjbGllbnQncyBsYXRlc3QgVEtFWSBxdWVyeS4NCg0K DQogIFhJLiBDbGllbnQgcHJvY2Vzc2VzIHRva2VuIHJldHVybmVkIGJ5IHNlcnZlcg0KICBDbGll bnQgcmVjZWl2ZXMgdGhlIFRLRVkgcXVlcnkgcmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyLiBTaW5j ZSB0aGUNCiAgbWFqb3Jfc3RhdHVzIHdhcyBHU1NfU19DT01QTEVURSBpbiB0aGUgbGFzdCBjbGll bnQncyBjYWxsIHRvDQogIEdTU19Jbml0X3NlY19jb250ZXh0LCB0aGUgY2xpZW50IHZlcmlmaWVz IHRoYXQgdGhlIHNlcnZlcidzIHJlc3BvbnNlDQogIG1hdGNoZXMgdGhlIHJlcXVpcmVkIGZvcm1h dC4NCg0KICBTaW5jZSB0aGUgT1VUUFVUUyBwYXJhbWV0ZXIgbWFqb3Jfc3RhdHVzID0gR1NTX1Nf Q09NUExFVEUsIHJlc3BvbnNlDQogIGZvcm1hdCBpcyB2YWxpZGF0ZWQsIHNlY3VyaXR5IG5lZ290 aWF0aW9uIGlzIGNvbXBsZXRlIGFuZCB0aGUNCiAgc2VjdXJpdHkgY29udGV4dCBzdGF0ZSBpcyBh ZHZhbmNlZCB0byBDb250ZXh0IEVzdGFibGlzaGVkLiBUaGVzZQ0KICBjbGllbnQgYW5kIHNlcnZl ciB3aWxsIHVzZSB0aGUgZXN0YWJsaXNoZWQgc2VjdXJpdHkgY29udGV4dCB0byBzaWduDQogIGFu ZCB2YWxpZGF0ZSB0aGUgc2lnbmF0dXJlcyB3aGVuIHRoZXkgZXhjaGFuZ2UgcGFja2V0cyB3aXRo IGVhY2gNCiAgb3RoZXIgdW50aWwgdGhlIGNvbnRleHQgZXhwaXJlcy4NCg0KDQo3LiBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHByb3RvY29sIGZv ciBETlMgc2VjdXJpdHkgdXNpbmcgR1NTLUFQSS4NClRoZSBzZWN1cml0eSBwcm92aWRlZCBieSB0 aGlzIHByb3RvY29sIGlzIG9ubHkgYXMgZWZmZWN0aXZlIGFzIHRoZQ0Kc2VjdXJpdHkgcHJvdmlk ZWQgYnkgdGhlIHVuZGVybHlpbmcgR1NTIG1lY2hhbmlzbXMuDQoNCkFsbCB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgZnJvbSBSRkMyODQ1LCBSRkMyOTMwIGFuZCBSRkMgMjc0Mw0KYXBwbHkg dG8gdGhlIHByb3RvY29sIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCjguIElBTkEg Q29uc2lkZXJhdGlvbnMNCg0KVGhlIGF1dGhvcnMgcmVxdWVzdCB0aGF0IHRoZSBJQU5BIHJlc2Vy dmUgdGhlIFRTSUcgQWxnb3JpdGhtIG5hbWUNCmdzcy10c2lnIGZvciB0aGUgdXNlIGluIHRoZSBB bGdvcml0aG0gZmllbGRzIG9mIFRLRVkgYW5kIFRTSUcgcmVzb3VyY2UNCnJlY29yZHMuIFRoaXMg QWxnb3JpdGhtIG5hbWUgcmVmZXJzIHRvIHRoZSBhbGdvcml0aG0gZGVzY3JpYmVkIGluIHRoaXMN CmRvY3VtZW50LiBUaGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSB0aGlzIG5hbWUgcmVnaXN0ZXJlZCB3 aXRoIElBTkEgaXMNCnNwZWNpZmllZCBpbiBSRkMgMjg0NS4NCg0KDQo5LiBDb25mb3JtYW5jZQ0K DQpUaGUgR1NTIEFQSSB1c2luZyBTUE5FR08gW1JGQzI0NzhdIHByb3ZpZGVzIG1heGltdW0gZmxl eGliaWxpdHkgdG8NCmNob29zZSB0aGUgdW5kZXJseWluZyBzZWN1cml0eSBtZWNoYW5pc21zIHRo YXQgZW5hYmxlcyBzZWN1cml0eSBjb250ZXh0DQpuZWdvdGlhdGlvbi4gR1NTIEFQSSB1c2luZyBT UE5FR08gW1JGQzI0NzhdIGVuYWJsZXMgY2xpZW50IGFuZCBzZXJ2ZXIgdG8NCg0KDQpFeHBpcmVz IEphbnVhcnkgMjEsIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDE5XQ0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICBHU1MtVFNJRyAgICAg ICAgICAgICAgICAgSnVseSAyMSwgMjAwMg0KDQpuZWdvdGlhdGUgYW5kIGNob29zZSBzdWNoIHVu ZGVybHlpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcyBvbiB0aGUgZmx5LiBUbw0Kc3VwcG9ydCBzdWNo IGZsZXhpYmlsaXR5LCBETlMgY2xpZW50cyBhbmQgc2VydmVycyBTSE9VTEQgc3BlY2lmeSBTUE5F R08NCm1lY2hfdHlwZSBpbiB0aGVpciBHU1MgQVBJIGNhbGxzLiBBdCB0aGUgc2FtZSB0aW1lLCBp biBvcmRlciB0bw0KZ3VhcmFudGVlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBETlMgY2xpZW50 cyBhbmQgc2VydmVycyB0aGF0IHN1cHBvcnQNCkdTUy1UU0lHIGl0IGlzIHJlcXVpcmVkIHRoYXQN Cg0KLSBETlMgc2VydmVycyBzcGVjaWZ5IFNQTkVHTyBtZWNoX3R5cGUNCi0gR1NTIEFQSXMgY2Fs bGVkIGJ5IEROUyBjbGllbnQgc3VwcG9ydCBLZXJiZXJvcyB2NQ0KLSBHU1MgQVBJcyBjYWxsZWQg YnkgRE5TIHNlcnZlciBzdXBwb3J0IFNQTkVHTyBbUkZDMjQ3OF0gYW5kDQogIEtlcmJlcm9zIHY1 Lg0KDQpJbiBhZGRpdGlvbiB0byB0aGVzZSwgR1NTIEFQSXMgdXNlZCBieSBETlMgY2xpZW50IGFu ZCBzZXJ2ZXIgTUFZIGFsc28NCnN1cHBvcnQgb3RoZXIgdW5kZXJseWluZyBzZWN1cml0eSBtZWNo YW5pc21zLg0KDQoNCjEwLiBBY2tub3dsZWRnZW1lbnRzDQoNClRoZSBhdXRob3JzIG9mIHRoaXMg ZG9jdW1lbnQgd291bGQgbGlrZSB0byB0aGFuayB0aGUgZm9sbG93aW5nIHBlb3BsZQ0KZm9yIHRo ZWlyIGNvbnRyaWJ1dGlvbiB0byB0aGlzIHNwZWNpZmljYXRpb246ICBDaHVjayBDaGFuLCBNaWtl IFN3aWZ0LA0KUmFtIFZpc3dhbmF0aGFuLCBPbGFmdXIgR3VkbXVuZHNzb24sIERvbmFsZCBFLiBF YXN0bGFrZSAzcmQsIEVyaWsNCk5vcmRtYXJrIGFuZCBLZXZpbiBEdW5sYXAuDQoNCg0KMTEuIFJl ZmVyZW5jZXMNCg0KW1JGQzI3NDNdIEouIExpbm4sICJHZW5lcmljIFNlY3VyaXR5IFNlcnZpY2Ug QXBwbGljYXRpb24gUHJvZ3JhbQ0KICAgICAgICAgIEludGVyZmFjZSwgVmVyc2lvbiAyICwgVXBk YXRlIDEiLCBSRkMgMjc0MywgUlNBIExhYm9yYXRvcmllcywNCiAgICAgICAgICBKYW51YXJ5IDIw MDAuDQoNCltSRkMyODQ1XSBQLiBWaXhpZSwgTy4gR3VkbXVuZHNzb24sIEQuIEVhc3RsYWtlLCBC LiBXZWxsaW5ndG9uLA0KICAgICAgICAgICJTZWNyZXQgS2V5IFRyYW5zYWN0aW9uIEF1dGhlbnRp Y2F0aW9uIGZvciBETlMgKFRTSUcpIiwNCiAgICAgICAgICBSRkMgMjg0NSwgSVNDLCBOQUkgTGFi cywgTW90b3JvbGEsIE5vbWludW0sIE1heSwgMjAwMCwNCg0KW1JGQzI5MzBdIEQuIEVhc3RsYWtl IDNyZCwgIlNlY3JldCBLZXkgRXN0YWJsaXNobWVudCBmb3IgRE5TIChUS0VZIFJSKSIsDQogICAg ICAgICAgUkZDIDI5MzAsIE1vdG9yb2xhLCBTZXB0ZW1iZXIgMjAwMC4NCg0KW1JGQzI1MzVdIEQu IEVhc3RsYWtlIDNyZCwgIkRvbWFpbiBOYW1lIFN5c3RlbSBTZWN1cml0eSBFeHRlbnNpb25zLCIN CiAgICAgICAgICBSRkMgMjUzNSwgSUJNLCBNYXJjaCAxOTk5Lg0KDQpbUkZDMjEzN10gRC4gRWFz dGxha2UgM3JkLCAiU2VjdXJlIERvbWFpbiBOYW1lIFN5c3RlbSBEeW5hbWljIFVwZGF0ZSwiDQog ICAgICAgICAgUkZDIDIxMzcsIEN5YmVyQ2FzaCwgQXByaWwgMTk5Ny4NCg0KW1JGQzIxMTldIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoN CltSRkMxMDM0XSBNb2NrYXBldHJpcywgUC4sICJEb21haW4gTmFtZXMgLSBDb25jZXB0cyBhbmQg RmFjaWxpdGllcyIsDQogICAgICAgICAgU1REIDEzLCBSRkMgMTAzNCwgTm92ZW1iZXIgMTk4Ny4N Cg0KW1JGQzEwMzVdIE1vY2thcGV0cmlzLCBQLiwgIkRvbWFpbiBOYW1lcyAtIEltcGxlbWVudGF0 aW9uIGFuZA0KICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBTVEQgMTMsIFJGQyAxMDM0LCBOb3Zl bWJlciAxOTg3Lg0KDQpbUkZDMTk2NF0gTGlubiwgSi4sICJUaGUgS2VyYmVyb3MgVmVyc2lvbiA1 IEdTUy1BUEkgTWVjaGFuaXNtIiwNCiAgICAgICAgICBSRkMgMTk2NCwgT3BlblZpc2lvbiBUZWNo bm9sb2dpZXMsIEp1bmUgMTk5Ni4NCg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMF0NCg0KSU5URVJORVQtRFJBRlQg ICAgICAgICAgICAgICAgICAgR1NTLVRTSUcgICAgICAgICAgICAgICAgIEp1bHkgMjEsIDIwMDIN Cg0KW1JGQzIwMjVdIEFkYW1zLCBDLiwgIlRoZSBTaW1wbGUgUHVibGljLUtleSBHU1MtQVBJIE1l Y2hhbmlzbSAoU1BLTSkiLA0KICAgICAgICAgIFJGQyAyMDI1LCBCZWxsLU5vcnRoZXJuIFJlc2Vh cmNoLCBPY3RvYmVyIDE5OTYuDQoNCltSRkMyNDc4XSBCYWl6ZSwgRS4sIFBpbmthcywgRC4sICJU aGUgU2ltcGxlIGFuZCBQcm90ZWN0ZWQgR1NTLUFQSQ0KICAgICAgICAgIE5lZ290aWF0aW9uIE1l Y2hhbmlzbSIsIFJGQyAyNDc4LCBCdWxsLCBEZWNlbWJlciAxOTk4Lg0KDQpbSVNPMTE1NzhdIklu Zm9ybWF0aW9uIHRlY2hub2xvZ3kiLCAiT3BlbiBTeXN0ZW1zDQogICAgICAgICAgSW50ZXJjb25u ZWN0aW9uIiwgIlJlbW90ZSBQcm9jZWR1cmUgQ2FsbCIsDQogICAgICAgICAgSVNPL0lFQyAxMTU3 ODoxOTk2LCBodHRwOi8vd3d3Lmlzby5jaC9jYXRlL2QyMjI5Lmh0bWwuDQoNCg0KDQoNCjEyLiBB dXRob3IncyBBZGRyZXNzZXMNCg0KU3R1YXJ0IEt3YW4gICAgICAgICAgICAgICAgICAgICAgICAg UHJhZXJpdCBHYXJnDQpNaWNyb3NvZnQgQ29ycG9yYXRpb24gICAgICAgICAgICAgICBNaWNyb3Nv ZnQgQ29ycG9yYXRpb24NCk9uZSBNaWNyb3NvZnQgV2F5ICAgICAgICAgICAgICAgICAgIE9uZSBN aWNyb3NvZnQgV2F5DQpSZWRtb25kLCBXQSAgOTgwNTIgICAgICAgICAgICAgICAgICBSZWRtb25k LCBXQSAgOTgwNTINClVTQSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVTQQ0Kc2t3 YW5AbWljcm9zb2Z0LmNvbSAgICAgICAgICAgICAgICAgcHJhZXJpdGdAbWljcm9zb2Z0LmNvbQ0K DQpKYW1lcyBHaWxyb3kgICAgICAgICAgICAgICAgICAgICAgICBMZXZvbiBFc2lib3YNCk1pY3Jv c29mdCBDb3Jwb3JhdGlvbiAgICAgICAgICAgICAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0KT25l IE1pY3Jvc29mdCBXYXkgICAgICAgICAgICAgICAgICAgT25lIE1pY3Jvc29mdCBXYXkNClJlZG1v bmQsIFdBICA5ODA1MiAgICAgICAgICAgICAgICAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KVVNBICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVVNBDQpqYW1lc2dAbWljcm9zb2Z0LmNvbSAg ICAgICAgICAgICAgICBsZXZvbmVAbWljcm9zb2Z0LmNvbQ0KDQoNClJhbmR5IEhhbGwgICAgICAg ICAgICAgICAgICAgICAgICAgIEplZmYgV2VzdGhlYWQNCkx1Y2VudCBUZWNobm9sb2dpZXMgICAg ICAgICAgICAgICAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0KNDAwIExhcHAgUm9hZCAgICAgICAg ICAgICAgICAgICAgICAgT25lIE1pY3Jvc29mdCBXYXkNCk1hbHZlcm4gUEEgMTkzNTUgICAgICAg ICAgICAgICAgICAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KVVNBICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVVNBDQpyYW5keWhhbGxAbHVjZW50LmNvbSAgICAgICAgICAgICAgICBqd2Vz dGhAbWljcm9zb2Z0LmNvbQ0KDQoNCg0KRXhwaXJlcyBKYW51YXJ5IDIxLCAyMDAzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMV0NCg== ------_=_NextPart_001_01C2334C.9C471D1F-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 17:42:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03364 for ; Wed, 24 Jul 2002 17:42:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XTbM-000HJl-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 14:23:20 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17XTbD-000HJU-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 14:23:11 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6F1BF28B6E for ; Wed, 24 Jul 2002 14:23:11 -0700 (PDT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: Message from "Levon Esibov" of "Wed, 24 Jul 2002 12:59:25 PDT." <211DE638FE1F094E96E3042DDF531CF9013DCC30@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 24 Jul 2002 14:23:11 -0700 Message-Id: <20020724212311.6F1BF28B6E@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Here are the proposed solutions. > 1. Modify RFC 2845 (TSIG) as follows: > Replace: > "The server MUST not generate a signed response to an unsigned request." > > With: > "The server MUST not generate a signed response to an unsigned request, > except in case of response to client's unsigned TKEY query if secret key > is established on server side after server processed client's query. > Signing responses to unsigned TKEY queries MUST be explicitly specified > in the description of an individual secret key establishment algorithm." right now the base tsig document is independent of tkey. this was originally due to the order of their creation, but it's still a good property to have. so if approach #1 is taken, i recommend broader wording: The server MUST NOT generate a signed response to an unsigned request, unless the signature algorythm's specification allows this (for example, see GSS-TSIG). (though i would have preferred to see GSS-TSIG always sign its requests, and to see TKEY specified in a way that made this possible.) > 2. Update the GSS-TSIG draft to not require that Server signs with TSIG > its last response to the client. > > 2a. In addition to 2 (above) mention in the updated GSS-TSIG draft that > previous implementations of GSS-TSIG clients require TSIG to be present > in the last server response and mention that implementers of the update > GSS-TSIG protocol may consider including TSIG record on the server side > to interop with old clients. Client may ignore TSIG record in response > from old servers. (version of the draft reflecting these updates is > attached) > > 2b. In addition to 2 (above) change the algorithm name in the GSS-TSIG > protocol to allow new implementations to distinguish old implementations > (using old algorithm name) from the new implementations. > > 2c. Do just what 2 above says. Do not even mention any previous > implementations and let new implementations to not interop with widely > deployed old implementations. none of these are practical due to the installed base. > Please let us know which solution you prefer. those were my two cents. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 20:24:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07152 for ; Wed, 24 Jul 2002 20:24:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XW7j-0007Lb-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 17:04:55 -0700 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17XW7c-0007L4-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 17:04:48 -0700 Received: from tecotoo.www.gis.net ([63.209.234.231]) by mx05.gis.net; Wed, 24 Jul 2002 20:04:45 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ia027932 for ; Wed, 24 Jul 2002 19:27:23 -0400 Message-Id: <4.3.1.2.20020724185748.00e35100@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 24 Jul 2002 19:27:07 -0400 To: "Levon Esibov" , , "Brian Wellington" From: Danny Mayer Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Cc: "Rob Austein" In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013DCC30@win-msg-06.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:59 PM 7/24/02, Levon Esibov wrote: >2. Update the GSS-TSIG draft to not require that Server signs with TSIG >its last response to the client. > >2a. In addition to 2 (above) mention in the updated GSS-TSIG draft that >previous implementations of GSS-TSIG clients require TSIG to be present >in the last server response and mention that implementers of the update >GSS-TSIG protocol may consider including TSIG record on the server side >to interop with old clients. Client may ignore TSIG record in response >from old servers. (version of the draft reflecting these updates is >attached) > >2b. In addition to 2 (above) change the algorithm name in the GSS-TSIG >protocol to allow new implementations to distinguish old implementations >(using old algorithm name) from the new implementations. > >2c. Do just what 2 above says. Do not even mention any previous >implementations and let new implementations to not interop with widely >deployed old implementations. I'm stepping into this debate rather gingerly since I'm not totally familiar with the draft and implementation. With that caveat, I'd like to say that 2c is really the right approach since an implementation prior to the adoption of a standard takes that risk knowing that they may have to change their implementation due to valid issues and changes that have to be made to a draft. Also the last paragraph of section 3.1.3.1 should be eliminated. Specific behaviors of implementations of the flawed draft don't belong there. Those are business decisions. I am aware that Microsoft has millions of desktops that depend on this previous behavior but that problem is a business issue that should not be part of an IETF wg discussion. Though I sympathise with your need to solve that issue too. The underlying issue here is that GSS-TSIG is being used as an authentication mechanism for allowing dynamic updates to DNS by clients. That updating mechanism should have been the responsibility of the DHCP server which is responsible for issuing the IP addresses and ensuring non-duplicate names for the client PC's. Only PC's using a DHCP server to get an address need to have the DNS updated, since PC's with static addresses should already be registered in the DNS. Unfortunately the strategy of having the clients do the update results in "dynamic update denied" messages appearing in everyone's syslog all over the Internet, masking real security problems. Unfortunately more than 99% of all users of Windows 2000 and later systems are ignorant of these update attempts. Moving the dynamic updates to the DHCP Server, eliminates more than 99% of the underlying problem. Moreover there is already some sort of trust relationship between the DHCP server and the PC clients, or at least we hope so since the clients are relying on it for IP addresses and other information. FWIW. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 21:31:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09041 for ; Wed, 24 Jul 2002 21:31:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XXLK-000Ftl-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 18:23:02 -0700 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.36 #1) id 17XXLD-000Fsj-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 18:22:55 -0700 Received: from localhost ([3ffe:501:4819:2000:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6P1LaA71458; Thu, 25 Jul 2002 10:21:36 +0900 (JST) Date: Thu, 25 Jul 2002 10:21:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 34 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,CHARSET_FARAWAY_HEADERS version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Wed, 24 Jul 2002 10:21:39 -0700, >>>>> Ted Lemon said: >> to mean the diagram like this: >> >> NI query >> nodeinfo client ------------------> the target >> with named (authorizing the name) >> and private key >> <------------------ >> NI response signed >> by the private key >> >> (BTW: I understood the very original idea of this thread meant the >> diagram you showed.) > No, I was talking about securing the NI query, but not assuming that a > "name server" would do that work, except in the sense that by definition > anything that responds to a query for a name with a name could be called a > name server. So more accurately, you meant like this? NI query nodeinfo client ------------------> the target with some private key <------------------ NI response signed by the private key JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 21:43:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09409 for ; Wed, 24 Jul 2002 21:43:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XXaW-000HaW-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 18:38:44 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17XXaN-000HaL-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 18:38:35 -0700 Received: from green.bisbee.fugue.com (a47.tc43.theriver.com [206.26.123.239]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6P1cKd03026; Thu, 25 Jul 2002 01:38:20 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6P1ckfD001837; Wed, 24 Jul 2002 18:38:46 -0700 (MST) Date: Wed, 24 Jul 2002 18:38:45 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= From: Ted Lemon In-Reply-To: Message-Id: <4250B782-9F6F-11D6-9D45-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So more accurately, you meant like this? > > NI query > nodeinfo client ------------------> the target > with some private key > <------------------ > NI response signed > by the private key Yes, where the name in the response is a valid domain name, and when the client looks for a KEY record on that domain name, it finds a public key that can be used to successfully validate the signature on the response. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 22:42:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11646 for ; Wed, 24 Jul 2002 22:42:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XYGQ-000MMj-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 19:22:02 -0700 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.36 #1) id 17XYGL-000MMW-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 19:21:57 -0700 Received: from localhost ([3ffe:501:4819:2000:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6P2KeA72510; Thu, 25 Jul 2002 11:20:40 +0900 (JST) Date: Thu, 25 Jul 2002 11:20:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: <4250B782-9F6F-11D6-9D45-00039317663C@nominum.com> References: <4250B782-9F6F-11D6-9D45-00039317663C@nominum.com> <20020721222414.1D7F64B22@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Thu_Jul_25_11:20:39_2002-1" X-Dispatcher: imput version 20000228(IM140) Lines: 144 X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,CHARSET_FARAWAY_HEADERS version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Multipart_Thu_Jul_25_11:20:39_2002-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Wed, 24 Jul 2002 18:38:45 -0700, >>>>> Ted Lemon said: >> So more accurately, you meant like this? >> >> NI query >> nodeinfo client ------------------> the target >> with some private key >> <------------------ >> NI response signed >> by the private key > Yes, where the name in the response is a valid domain name, and when the > client looks for a KEY record on that domain name, it finds a public key > that can be used to successfully validate the signature on the response. okay, so I guess you and itojun (attached) were talking about different things. Returning to your idea, it sounds attractive. However, I'm not sure if this approach is applicable widely. In particular, I'm not sure if "edge devices" such as personal laptops, PDAs, cell phones..., for which the nodeinfo-revlookup would be most useful, have private keys authorized in the DNSSEC framework. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_Jul_25_11:20:39_2002-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.12.3/8.12.3) with ESMTP id g6M11bMR044819 for ; Mon, 22 Jul 2002 10:02:07 +0900 (JST) (envelope-from owner-ipng@sunroof.eng.sun.com) Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-5.9.11) for jinmei@localhost (single-drop); Mon, 22 Jul 2002 10:02:07 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6LMQUA30841 for ; Mon, 22 Jul 2002 07:26:30 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id g6LMQTv04148 for ; Mon, 22 Jul 2002 07:26:29 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id HAA10807 for ; Mon, 22 Jul 2002 07:26:29 +0900 (JST) Received: from mx2.toshiba.co.jp (mx2.toshiba.co.jp [133.199.160.163]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id g6LMQSe27775 for ; Mon, 22 Jul 2002 07:26:28 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id HAA04660; Mon, 22 Jul 2002 07:26:28 +0900 (JST) Received: from inet-tsb2.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp (8.9.3/3.7W) with ESMTP id HAA26519 for ; Mon, 22 Jul 2002 07:26:28 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb2.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id HAA22741 for ; Mon, 22 Jul 2002 07:26:27 +0900 (JST) Received: by orange.kame.net (Postfix) id 3BF1E71CE; Mon, 22 Jul 2002 07:26:27 +0900 (JST) Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (kame202.kame.net [203.178.141.202]) by orange.kame.net (Postfix) with ESMTP id AAAFC71B2 for ; Mon, 22 Jul 2002 07:26:26 +0900 (JST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by sh.wide.ad.jp (8.11.6+3.4W/8.11.0) with ESMTP id g6LMQOF10436 for ; Mon, 22 Jul 2002 07:26:25 +0900 (JST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00565; Sun, 21 Jul 2002 15:25:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26295; Sun, 21 Jul 2002 15:25:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LMOLoN001049; Sun, 21 Jul 2002 15:24:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LMOL8T001048; Sun, 21 Jul 2002 15:24:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LMOHoN001041 for ; Sun, 21 Jul 2002 15:24:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05208 for ; Sun, 21 Jul 2002 15:24:18 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08550 for ; Sun, 21 Jul 2002 15:24:17 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1D7F64B22; Mon, 22 Jul 2002 07:24:14 +0900 (JST) To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: Ted.Lemon's message of Sat, 20 Jul 2002 23:29:13 MST. <2C521845-9C73-11D6-B03B-00039317663C@nominum.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Mon, 22 Jul 2002 07:24:14 +0900 Message-Id: <20020721222414.1D7F64B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-UIDL: p5)#!'E1"!%(1"!I\9"! MIME-Version: 1.0 >> i may be asking a stupid question, but where do you get that private >> key from? for instance, if a node responds with "www.ietf.org", >> we could get a public key for www.ietf.org by KEY RR query, but >> not the private key (it's on ietf.org authoritative server, and >> is not accessible from outside). >Presumably the device answering the ICMP request is the one named, >and therefore knows the private key associated with its name. no, the device answering ICMPv6 request is not named. with the "type ipv6nodeinfo" directive, named will work like this: - accept DNS query from a DNS client resolver. - send NI query to the target address. - receive NI response from the target. - send DNS response to the original DNS client resolver. since the NI query target can return arbitrary FQDN (like "www.ietf.org") named does not have the private key. client resolver ---------> named -------> the target DNS query NI query client resolver <--------- named <------- the target DNS response NI response itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --Multipart_Thu_Jul_25_11:20:39_2002-1-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 23:16:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12043 for ; Wed, 24 Jul 2002 23:16:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XYxk-000PFE-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 20:06:48 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17XYxc-000PEq-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 20:06:40 -0700 Received: from green.bisbee.fugue.com (az-ben-pm3-2-14.ppp.theriver.com [206.25.50.14]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6P36Od03189; Thu, 25 Jul 2002 03:06:25 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6P36pfD001859; Wed, 24 Jul 2002 20:06:51 -0700 (MST) Date: Wed, 24 Jul 2002 20:06:51 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= From: Ted Lemon In-Reply-To: Message-Id: <90AF0F5A-9F7B-11D6-9D45-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Returning to your idea, it sounds attractive. However, I'm not sure > if this approach is applicable widely. In particular, I'm not sure if > "edge devices" such as personal laptops, PDAs, cell phones..., for > which the nodeinfo-revlookup would be most useful, have private keys > authorized in the DNSSEC framework. Why not? I think they do probably have private keys, and configuring them with the private side of a DNSSEC key doesn't sound very hard. It does sound like it would be quite useful. :') -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 24 23:49:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12655 for ; Wed, 24 Jul 2002 23:49:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XZVx-0000sr-00 for namedroppers-data@psg.com; Wed, 24 Jul 2002 20:42:09 -0700 Received: from ms2-gw.noc.ntt.com ([210.163.32.67]) by psg.com with esmtp (Exim 3.36 #1) id 17XZVs-0000sJ-00 for namedroppers@ops.ietf.org; Wed, 24 Jul 2002 20:42:04 -0700 Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id MAA24655; Thu, 25 Jul 2002 12:41:58 +0900 (JST) Received: from mail1.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id MAA24646; Thu, 25 Jul 2002 12:41:57 +0900 (JST) Received: from kamite-bsd2 by mail1.noc.ntt.com (8.9.3/3.7W) id MAA04897; Thu, 25 Jul 2002 12:41:57 +0900 (JST) Date: Thu, 25 Jul 2002 12:42:42 +0900 From: Yuji KAMITE To: namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Message-Id: <20020725124242.262c1d9e.y.kamite@ntt.com> In-Reply-To: <211DE638FE1F094E96E3042DDF531CF9013DCC30@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> References: <211DE638FE1F094E96E3042DDF531CF9013DCC30@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Organization: NTT Communications X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1. Modify RFC 2845 (TSIG) as follows: > Replace: > "The server MUST not generate a signed response to an unsigned request." > > With: > "The server MUST not generate a signed response to an unsigned request, > except in case of response to client's unsigned TKEY query if secret key > is established on server side after server processed client's query. > Signing responses to unsigned TKEY queries MUST be explicitly specified > in the description of an individual secret key establishment algorithm." If you take this alternative, the meaning which MAC in the response implies comes to differ according to protcol (GSS-TSIG or the others). I think it might be better to add some kinds of description for notice. For example: In GSS-TSIG, the MAC in a response (to an unsigned request) means confirmation and notification telling that secret is successfully established via GSSAPI; meanwhile, in the original TSIG, MAC in a response (to a signed request) means that the response validly corresponds to the received request itself (i.e. secures the transaction), as well as authenticates the host's identity. client-recipient must be aware of this difference by checking which algorithm is now being used. --- Yuji Kamite (mailto: y.kamite@ntt.com) NTT Communications Tel:+81-3-6800-3261, Fax:+81-3-5365-2990 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 25 08:27:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00814 for ; Thu, 25 Jul 2002 08:27:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XhP3-000Ebm-00 for namedroppers-data@psg.com; Thu, 25 Jul 2002 05:07:33 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17XhOv-000EbX-00 for namedroppers@ops.ietf.org; Thu, 25 Jul 2002 05:07:25 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29763; Thu, 25 Jul 2002 08:06:19 -0400 (EDT) Message-Id: <200207251206.IAA29763@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-mdns-11.txt Date: Thu, 25 Jul 2002 08:06:18 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,DOUBLE_CAPSWORD,EXCUSE_6 version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-11.txt Pages : 20 Date : 24-Jul-02 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-11.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: <20020724142737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142737.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 25 09:40:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03619 for ; Thu, 25 Jul 2002 09:40:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17XiaM-000GNT-00 for namedroppers-data@psg.com; Thu, 25 Jul 2002 06:23:18 -0700 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 17XiaB-000GNB-00 for namedroppers@ops.ietf.org; Thu, 25 Jul 2002 06:23:07 -0700 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA05569; Thu, 25 Jul 2002 16:23:05 +0300 Date: Thu, 25 Jul 2002 16:23:05 +0300 Message-Id: <200207251323.QAA05569@burp.tkv.asdf.org> From: Markku Savela To: namedroppers@ops.ietf.org In-reply-to: <200207251206.IAA29763@ietf.org> (Internet-Drafts@ietf.org) Subject: Re: I-D ACTION:draft-ietf-dnsext-mdns-11.txt References: <200207251206.IAA29763@ietf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I may have other comments later, but first this: the introduction contains a paragraph: Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server for IPv4, while remaining unconfigured with a DNS server suitable for use with IPv6. ... I think this contains a fundamental misunderstanding how a nameresolving on the dual stack host works. If a dual stack host has even one DNS server address (either IPv4 or IPv6), it can be used for both IPv4 (A) and IPv6 (AAAA) queries. It makes no difference how this DNS server address was obtained (/etc/resolv.conf, DHCP, DHCPv6 or whatever). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 25 13:23:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13409 for ; Thu, 25 Jul 2002 13:23:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Xm3K-000MuC-00 for namedroppers-data@psg.com; Thu, 25 Jul 2002 10:05:26 -0700 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.36 #1) id 17Xm3E-000Mtn-00 for namedroppers@ops.ietf.org; Thu, 25 Jul 2002 10:05:20 -0700 Received: from localhost (PPP40.air128.dti.ne.jp [210.170.212.43]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6PH3gA84678; Fri, 26 Jul 2002 02:03:43 +0900 (JST) Date: Fri, 26 Jul 2002 02:03:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: <90AF0F5A-9F7B-11D6-9D45-00039317663C@nominum.com> References: <90AF0F5A-9F7B-11D6-9D45-00039317663C@nominum.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 33 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,CHARSET_FARAWAY_HEADERS version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Wed, 24 Jul 2002 20:06:51 -0700, >>>>> Ted Lemon said: >> Returning to your idea, it sounds attractive. However, I'm not sure >> if this approach is applicable widely. In particular, I'm not sure if >> "edge devices" such as personal laptops, PDAs, cell phones..., for >> which the nodeinfo-revlookup would be most useful, have private keys >> authorized in the DNSSEC framework. > Why not? I think they do probably have private keys, and configuring them > with the private side of a DNSSEC key doesn't sound very hard. It does > sound like it would be quite useful. :') It is probably okay to assume the devices have some private keys. My concerns (or what I'm not sure about) are: - how to register the keys to DNS. Manual configuration (by an administrator) is not realistic for general cases, but I'm not sure if DNS dynamic update is effective. - how to construct the trust chain of DNSSEC toward the root zone. The zone to which the edge devices belong is presumably a kind of "personal" one, and we may not always assume it is a secure zone. In fact, in my understanding the current trend of DNSSEC is to restrict signed zones to some "well-known" ones such as a zone containing famous commercial web servers. Some may have an idea to deal with this, though. If there is a concrete idea of an entire system, I'm very interested in it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 25 15:16:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17760 for ; Thu, 25 Jul 2002 15:16:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Xnw4-0000w1-00 for namedroppers-data@psg.com; Thu, 25 Jul 2002 12:06:04 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Xnvt-0000vk-00 for namedroppers@ops.ietf.org; Thu, 25 Jul 2002 12:05:53 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 154897; Thu, 25 Jul 2002 14:03:04 -0500 Message-ID: <3D404C0D.1090507@ehsco.com> Date: Thu, 25 Jul 2002 14:05:49 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Guttman CC: zeroconf@merit.edu, namedroppers@ops.ietf.org Subject: Re: ZEROCONF [IS NOT] multicast name resolution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 7/24/2002 4:44 AM Erik Guttman wrote: > Multicast-Based Name Resolution > ------------------------------- > > Multicast-based name resolution has been a goal of the ZEROCONF > WG since it was chartered. The work item, to create a standards > track protocol, has been taken on by the DNSEXT WG. First off, there needs to be a clarification in terminology. We keep running into this. Party A interprets it as when talking to Party B who interprets it as , and they end up talking around each other. Please fix your [zeroconf] wording so that we at least know what we are NOT talking about. There are at least two different concepts of multicast name resolution. On the one hand, there is the typical DNS resolver operating in a typical environment, but using multicast destinations instead of static unicast server addresses. In this model, the stub resolver can use multicast to query any locally available server which might be able to answer the query, rather than have to ask a known server, but is otherwise identical to the existing protocol: the servers are the only systems that "listen" for queries, they process the queries against the existing namespace and partition hierarchy, and they use the same message formats to do their work. This is what most people in the DNS community think about when you say "multicast DNS" or "multicast name resolution" in the context of "work for the DNSEXT WG." Conversely, the model that the Zeroconf folks appear to be describing (based on the last time I read the documents anyway) is for two strangers to be able to identify each other through peer-level lookups, such as having two users on a train communicate via friendly names. For all practical purposes, this is not DNS. The nodes are peers (capable of acting as servers) rather than clients, and there is no partition hierarchy although the namespace respresents a shadow node of a particular partition. In the end, it is an entirely different application which just so happens to reuse the DNS message format. Therefore it is not DNS, and it follows that this cannot be multicast DNS. Please call it something else, "zeroconf neighbor naming lookup service" or anything. It is also worth noting that these two uses do not conflict (although the terminology sure does). Both are admirable objectives. > - Peer to peer naming protocols exist today, and have for a > long time (NetBIOS and AppleTalk). > > - It is possible to use these protocols to resolve names without > the use of DNS. > > - NetBIOS and AppleTalk names can be *the same* as host names in > the DNS. > > - Some hosts *ALREADY* use alternative naming mechanisms to resolve > names when DNS is not available (NIS, NetBIOS, AppleTalk, others). > As has been brought out on the list, this is common practice and in > no way incorrect with respect to the resolver APIs. > > - There is no IETF standard way to provide this function, over IP. > > - It is desirable to retire NetBIOS and AppleTalk for many reasons > but without a functionally equivalent IETF standard solution, this > is not possible. All very true and reasonable claims, for the specific application scenario you are describing. These problems can be dealt with differently in a typical wired hierarchy installation. EG, netbios and appletalk naming can be glued onto the existing DNS easily if the user is configured for a specific environment, essentially using DNS as a replacement for broadcasting. I can provide more information on how this could work but it is OT for now. The point here is that you are trying to use the DNS message as a container for a vendor-neutral name lookup service in a multicast domain, and your list of "facts" above represent this specific application naturally. > The ZEROCONF WG has attempted to articulate the requirements for > an IETF standard to allow this name to address (and reverse) > resolution in environments without DNS support. > > There are numerous areas where we run into differences of opinion. > > - What does it mean for hosts to respond to fully qualified > domain names which DNS would normally respond to? Should > multicast name resolution use the same namespace as DNS? > > Some have held that we need a special 'local' namespace, > while others believe that a host should be able to respond > to requests for its 'own' name. The DNS namespace is a logical view of the partition hierarchy (it is not a mirror). Since you are not using the partition hierarchy, there is no NEED for you to use the namespace. However, if you want to prevent the collisions which are bound to occur in anarchist naming systems, then using the DNS namespace is a reasonable first-stab at ensuring that two nodes will have the same name. This is BS, BTW, since there are lots of organizations that use the same domain name (in traditional wired hierarchies, collisions are avoided since the local servers only deal with authoritative sources). Also consider that not all of the nodes will ever have touched a real DNS domain name, and therefore may not have any preconceived notion of what their actual FQDN should be. From this perspective, the use of the DNS namespace gets you nothing substantive over any other namespace. There is another consideration here, which is that the question section of a DNS message is a fixed structure (EG, regardless of the QClass, labels are restricted to 63 octets). You could get a lot more flexibility in your naming if you used something else. Issues with conflicting names, coordination between the friendly name and other namespaces (such as DNS) would have to be resolved, but it would actually be simpler if you used something else entirely. There are plenty of well-known techniques available here -- automatic renaming on collision, using additional data such as a full name or some other informational string to supplement the name -- and these options are not available in a DNS-strict model. > - What we really want is applications that continue to > function even when DNS fails or is not present: http://foo > will succeed if there is a host which can respond to a > name resolution request for 'foo' using the non-DNS multicast > name resoultion protocol. > > Some seem to hold this is not an appropriate objective. Sounds reasonable to me. Make it so. :p > - Should multicast name resolution be possible whether even when > DNS *is* available? This would prevent 'local' name resolution > from ever failing and ensure it always returns consistent > information. > > Many have asserted that DNS has to be used, exclusively, > for domain name resolution if it is available as this is the > current and expected behavior. The use of nsswitch.conf files (or their ilk) is well-known to be workable for this kind of dual usage. In order to make this seamless, you have to be able to negotiate priority, but that is outside the scope of the protocol spec. One possiblility here is that if the application knows it is connected to a traditional wired infrastructure (it got a DHCP lease, the DNS server is answering, whatever) then it should try DNS first and then fail over to ZNNS, but again I would think that is outside the scope of the protocol specification. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 25 15:24:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17859 for ; Thu, 25 Jul 2002 15:24:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Xo5n-0001Hb-00 for namedroppers-data@psg.com; Thu, 25 Jul 2002 12:16:07 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17Xo5h-0001HK-00 for namedroppers@ops.ietf.org; Thu, 25 Jul 2002 12:16:01 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 154899; Thu, 25 Jul 2002 14:13:12 -0500 Message-ID: <3D404E69.4030504@ehsco.com> Date: Thu, 25 Jul 2002 14:15:53 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: Erik Guttman , zeroconf@merit.edu, namedroppers@ops.ietf.org Subject: Re: ZEROCONF [IS NOT] multicast name resolution References: <3D404C0D.1090507@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=MISSING_HEADERS version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [I should have read/edited this before sending] on 7/25/2002 2:05 PM Eric A. Hall wrote: > netbios and appletalk naming can be glued onto the existing DNS easily > if the user is configured for a specific environment, essentially using > DNS as a replacement for broadcasting. I can provide more information > on how this could work but it is OT for now. This model would essentially provide fixed ZNNS servers for situations where the peer-level registration and discovery was undesirable or untenable. Think of it as providing WINS-like functionality if you want. There are some tricks that can be done here with things like protocol- specific SRV RRs, service-specific NBP/NBT RRs, etc. If the user is attached to the network (as detected from whatever clues) then this would be used as preferred since naming conflicts could be avoided. > the use of the DNS namespace gets you nothing substantive over any > other namespace. That's not entirely true. See above. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 26 08:30:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16522 for ; Fri, 26 Jul 2002 08:30:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Y3uh-0002xC-00 for namedroppers-data@psg.com; Fri, 26 Jul 2002 05:09:43 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17Y3ua-0002x1-00 for namedroppers@ops.ietf.org; Fri, 26 Jul 2002 05:09:36 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15545; Fri, 26 Jul 2002 08:08:29 -0400 (EDT) Message-Id: <200207261208.IAA15545@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-02.txt Date: Fri, 26 Jul 2002 08:08:29 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, M. Larson, D. Massey, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-02.txt Pages : 19 Date : 25-Jul-02 The Domain Name System Security Extensions (DNSSEC) provide data origin authentication and data integrity. This document introduces these extensions and describes their capabilities and limitations. The services that the security extensions provide and do not provide are discussed. Lastly, the group of documents that describe the DNS security extensions and their interrelationships is discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-02.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: <20020725150932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020725150932.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 26 11:12:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24418 for ; Fri, 26 Jul 2002 11:12:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Y6XQ-0007s8-00 for namedroppers-data@psg.com; Fri, 26 Jul 2002 07:57:52 -0700 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 17Y6XF-0007rH-00 for namedroppers@ops.ietf.org; Fri, 26 Jul 2002 07:57:41 -0700 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA07732; Fri, 26 Jul 2002 17:57:39 +0300 Date: Fri, 26 Jul 2002 17:57:39 +0300 Message-Id: <200207261457.RAA07732@burp.tkv.asdf.org> From: Markku Savela To: namedroppers@ops.ietf.org In-reply-to: <200207251323.QAA05569@burp.tkv.asdf.org> (message from Markku Savela on Thu, 25 Jul 2002 16:23:05 +0300) Subject: More comments on draft-ietf-dnsext-mdns-11.txt References: <200207251206.IAA29763@ietf.org> <200207251323.QAA05569@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've more comments about 20 July 2002 ----------------- 1.2. Terminology Responder A host that listens to (but not necessarily responds to) a LLMNR query is called "responder". Sender A host that sends an LLMNR query. The same host may be configured as a "sender", but not a "responder" and vice versa, i.e. as a "responder", but not a "sender". ----------------- I thought the idea was that each host knows it's own name and address and is an authority on those. Thus each host must be a 'responder'. But, if it cannot be 'sender' at same time, it cannot query any other names. And if host is a 'sender', it cannot listen and respond to queries that match its name? To me it seems that the most common and useful configuration would exactly be combined 'sender' + 'responder', which seems to be ruled out by above! ------------------ 2. Name resolution using LLMNR ... network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of IPv4 hosts on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing DHCPv6 for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of IPv6 hosts on the local network. .... ------------------ In above I see again some confusion. Any DNS server either over IPv6 or over IPv4 can serve BOTH IPv6 and IPv4 queries. It does not matter whether this server was obtained through DHCPv4 or DCHPv6 (or by any other means). The corollary to this is that enabling both IPv4 and IPv6 LLMNR on the same link, means that you just have two "nameservers" to choose, and a host (sender) should be able send query to either one (regardless of the query type: A, AAAA or PTR). However, if it is expected that there are IPv4-only or IPv6-only hosts on the link, then it should send query to both "servers"? Does it send them in parallel or after one timeouts? ------------------ 2.5. No/multiple responses ... Since the responder MUST NOT respond to queries for names it is not authoritative for, a responder MUST NOT respond to an A, A6 or AAAA RR query with an NXRRSET. However, for other queries, such a response is possible; for example, if the host has a AAAA RR, but no MX RR, and an MX RR query is received. ... ------------------- Perhaps, better or additional example would be "AAAA" and "A" (instead of "AAAA" and "MX"): e.g. "if the host has a AAAA RR, but no A RR, and an A RR query is received" (or vice versa). ------------------- ... The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When this occurs, the responses MAY first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would, ordinarily. ... ------------------- Concatenated? Isn't receiving multiple replies an indication of a conflict? Two hosts on the link use same name? At least for A and AAAA queries? ------------------- 3.1. LLMNR configuration LLMNR usage can be configured manually or automatically. On interfaces where no manual or automatic DNS configuration has been performed for a given protocol (IPv4 or IPv6), LLMNR SHOULD be enabled for that protocol. ... ------------------- Again the same confusion. DNS is not configured for single interface. When a host finds a DNS server address, it will apply to ALL interfaces. Thus, the logical conclusion is: if host has "real" DNS server address, then NONE of the interfaces can have LLNMR. Or, you have to accept the fact that in such situation you have both GLOBAL DNS and LLNMR applying to the same interface and specify sensible rules to deal with situation. [NOTE: I do realise there are such beasts as split DNS servers or intranet local servers, but handling these require some new "namespace" concepts that are not present in "standard traditional" DNS semantics and resolver stubs.] -------------------- ... Note that it is possible for LLMNR to be enabled for use with IPv6 at the same time it is disabled for IPv4, and vice versa. ... -------------------- Yes, but this just means that you have "LLMNR" over IPv4 or IPv6. You can still use either to query A or AAAA. -------------------- 5. Conflict resolution ... ... - multiple hosts may respond to a query for a SRV type record - multiple hosts may respond to a query for an A type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A type record for a hostname. -------------------- When querying a name and getting multiple replies, how does host know whether name was "hostname" or "cluster name"? Each "...for an A type..." in above should be replaced with text "...for an A or AAAA type..." --------------------- ... Where a host is configured to respond to LLMNR queries on more than one interface, the host MUST verify resource record uniqueness on each interface for each UNIQUE resource record that could be used on that interface. ... --------------------- LLMNR is "LINK LOCAL MULTICAST NAME RESOLUTION". I think all text concerning about synchronizing the names across links should be removed. Each link should have it's own independent LLMNR cache. regards, -- Markku Savela Esibov, Aboba & Thaler Standards Track [Page 20] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 26 15:12:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04766 for ; Fri, 26 Jul 2002 15:12:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YADc-000FT6-00 for namedroppers-data@psg.com; Fri, 26 Jul 2002 11:53:40 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17YADY-000FSt-00 for namedroppers@ops.ietf.org; Fri, 26 Jul 2002 11:53:36 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 3F74B431; Fri, 26 Jul 2002 11:52:20 -0700 (PDT) Date: Fri, 26 Jul 2002 11:52:20 -0700 From: David Terrell To: JINMEI Tatuya / ??????????? Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Message-ID: <20020726185220.GA2585@pianosa.catch22.org> Reply-To: David Terrell References: <90AF0F5A-9F7B-11D6-9D45-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 11:50AM up 18 days, 11:42, 52 users, load averages: 0.74, 0.48, 0.38 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jul 26, 2002 at 02:03:39AM +0900, JINMEI Tatuya / ??????????? wrote: > >>>>> On Wed, 24 Jul 2002 20:06:51 -0700, > >>>>> Ted Lemon said: > > >> Returning to your idea, it sounds attractive. However, I'm not sure > >> if this approach is applicable widely. In particular, I'm not sure if > >> "edge devices" such as personal laptops, PDAs, cell phones..., for > >> which the nodeinfo-revlookup would be most useful, have private keys > >> authorized in the DNSSEC framework. > > > Why not? I think they do probably have private keys, and configuring them > > with the private side of a DNSSEC key doesn't sound very hard. It does > > sound like it would be quite useful. :') > > It is probably okay to assume the devices have some private keys. My > concerns (or what I'm not sure about) are: > > - how to register the keys to DNS. Manual configuration (by an > administrator) is not realistic for general cases, but I'm not sure > if DNS dynamic update is effective. In the mobile, dynamic IPv6 world, it seems like having public keys in DNS would be fairly common for things like secured NSUPDATE, so the host would already be doing this. > - how to construct the trust chain of DNSSEC toward the root zone. > The zone to which the edge devices belong is presumably a kind of > "personal" one, and we may not always assume it is a secure zone. > In fact, in my understanding the current trend of DNSSEC is to > restrict signed zones to some "well-known" ones such as a zone > containing famous commercial web servers. Something tells me that a lot of people on this mailling list will have signed, secure zones long before these famous commercial web servers... -- David Terrell | Step 1: "configure one system using your GUI" dbt@meat.net | Step 2: "now configure 1000 more" Nebcorp Prime Minister | - Casper H.S. Dik http://wwn.nebcorp.com | -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 26 17:25:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09512 for ; Fri, 26 Jul 2002 17:25:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YCFr-000JoV-00 for namedroppers-data@psg.com; Fri, 26 Jul 2002 14:04:07 -0700 Received: from pianosa.catch22.org ([64.81.48.19]) by psg.com with esmtp (Exim 3.36 #1) id 17YCFn-000JoI-00 for namedroppers@ops.ietf.org; Fri, 26 Jul 2002 14:04:03 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 980634AD; Fri, 26 Jul 2002 14:02:47 -0700 (PDT) Date: Fri, 26 Jul 2002 14:02:47 -0700 From: David Terrell To: Markku Savela Cc: namedroppers@ops.ietf.org Subject: Re: More comments on draft-ietf-dnsext-mdns-11.txt Message-ID: <20020726210247.GB2585@pianosa.catch22.org> Reply-To: David Terrell References: <200207251206.IAA29763@ietf.org> <200207251323.QAA05569@burp.tkv.asdf.org> <200207261457.RAA07732@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200207261457.RAA07732@burp.tkv.asdf.org> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:41PM up 18 days, 12:33, 44 users, load averages: 0.46, 0.39, 0.33 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Jul 26, 2002 at 05:57:39PM +0300, Markku Savela wrote: > I've more comments about 20 July 2002 > > ----------------- > 1.2. Terminology > > Responder A host that listens to (but not necessarily responds to) > a LLMNR query is called "responder". > > Sender A host that sends an LLMNR query. The same host may be > configured as a "sender", but not a "responder" and vice > versa, i.e. as a "responder", but not a "sender". > > > I thought the idea was that each host knows it's own name and > address and is an authority on those. Thus each host must be a > 'responder'. But, if it cannot be 'sender' at same time, it > cannot query any other names. It's just vague wording. The problem with the term responder, of course, is that it's not always a responder. What's wrong with the more common multicast term "listener"? I would suggest: 1.2 Terminology Listener - A host that listens to a LLMNR query is called a "listener". A listener need not actually send a response to any particular query. Sender - A host that originates an LLMNR query is called a sender. A sender need not be a listener, and vice versa. But after 11 revisions I don't know if you really want to change your terminology that drastically. :) Even if you don't, the new definition wording seems clearer (to me) as to what defines a [responder] or sender. -- David Terrell | "When we said that you needed to cut the dbt@meat.net | wires for ultimate security, we didn't Nebcorp Prime Minister | mean that you should go wireless instead." http://wwn.nebcorp.com/ | - Casper Dik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 28 04:36:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23485 for ; Sun, 28 Jul 2002 04:36:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YjH2-000Kpo-00 for namedroppers-data@psg.com; Sun, 28 Jul 2002 01:19:32 -0700 Received: from host1.btamail.net.cn ([202.106.196.71] helo=btmail.net.cn) by psg.com with smtp (Exim 3.36 #1) id 17YjGs-000KoA-00 for namedroppers@ops.ietf.org; Sun, 28 Jul 2002 01:19:24 -0700 Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm43d4403f1; Sun, 28 Jul 2002 08:19:11 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmbc3d3ee74f; Wed, 24 Jul 2002 14:18:22 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA01504 for ietf-123-outbound.01@ietf.org; Wed, 24 Jul 2002 08:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA01307 for ; Wed, 24 Jul 2002 08:09:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02112; Wed, 24 Jul 2002 08:08:06 -0400 (EDT) Message-Id: <200207241208.IAA02112@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-obsolete-iquery-04.txt Date: Wed, 24 Jul 2002 08:08:05 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Obsoleting IQUERY Author(s) : D. Lawrence Filename : draft-ietf-dnsext-obsolete-iquery-04.txt Pages : 4 Date : 23-Jul-02 The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using PTR queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation and updates RFC 1035 to declare it entirely obsolete. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-obsolete-iquery-04.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-obsolete-iquery-04.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: <20020723145458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-obsolete-iquery-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-obsolete-iquery-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020723145458.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 28 11:40:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27780 for ; Sun, 28 Jul 2002 11:40:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17YpxV-000E0B-00 for namedroppers-data@psg.com; Sun, 28 Jul 2002 08:27:49 -0700 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17YpxO-000Dzz-00 for namedroppers@ops.ietf.org; Sun, 28 Jul 2002 08:27:42 -0700 Received: from tecotoo.www.gis.net ([216.41.29.221]) by mx03.gis.net; Sun, 28 Jul 2002 11:27:38 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id da027953 for ; Sun, 28 Jul 2002 09:20:43 -0400 Message-Id: <4.3.1.2.20020728091739.00e51b90@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 28 Jul 2002 09:20:23 -0400 To: Rob Austein , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <20020723173555.66D2F1902@thrintun.hactrn.net> References: <211DE638FE1F094E96E3042DDF531CF9013A9CBA@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> <211DE638FE1F094E96E3042DDF531CF9013A9CBA@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:35 PM 7/23/02, Rob Austein wrote: >At Tue, 23 Jul 2002 09:14:09 -0700, Levon Esibov wrote: > > > > I-D based code is widely deployed. Namely it is included in Windows 2000 > > Professional and Windows XP Professional, all versions of Windows 2000 > > Server and Windows.Net 2003 Server, Lucent DNS Service 3.1 and VitalQIP > > 6.0. > >Ok, it's deployed. Which leaves the other half of the question: how >badly will lack of backwards compatability harm the users? > >In case it's not clear: there's a lot of stuff out there that's >deployed but not used (in any operating system, I'm not picking on >Windows here), so the fact that code has shipped doesn't automatically >imply a need for backwards compatability. What will this break, and >why is the correct solution not just for the vendors to ship patches? > > > Just to clarify, my proposal to update Section 4.2 of RFC 2845 (TSIG) > > addresses wider issue than enabling backward compatibility (enabling > > backward compat is just a side-effect of the proposed modification). > > Namely my proposed modification removes unnecessary restriction to use > > TSIG to sign server's response to un-signed TKEY query in case if secret > > key is established on the server side before it is established on the > > client side. > >Why is it that everybody who suggests adding additional complexity to >DNS these days phrases it as removing unnecessary restrictions? :)/2 > >I don't have a serious problem with your proposed change per se, but >(a) others who've been tracking TSIG and GSS-TSIG more closely might, >and (b) I'm not (yet) convinced of the need to change RFC 2845. Has someone looked at the security implications of this? Could this result in someone being able to break the security of the key? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 28 23:35:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07880 for ; Sun, 28 Jul 2002 23:35:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Z14U-0009Mx-00 for namedroppers-data@psg.com; Sun, 28 Jul 2002 20:19:46 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.36 #1) id 17Z14Q-0009Ml-00 for namedroppers@ops.ietf.org; Sun, 28 Jul 2002 20:19:42 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0722E4B22; Mon, 29 Jul 2002 12:18:23 +0900 (JST) To: Ted Lemon Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: Ted.Lemon's message of Wed, 24 Jul 2002 18:38:45 MST. <4250B782-9F6F-11D6-9D45-00039317663C@nominum.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Mon, 29 Jul 2002 12:18:23 +0900 Message-Id: <20020729031823.0722E4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> So more accurately, you meant like this? >> >> NI query >> nodeinfo client ------------------> the target >> with some private key >> <------------------ >> NI response signed >> by the private key >Yes, where the name in the response is a valid domain name, and when the >client looks for a KEY record on that domain name, it finds a public key >that can be used to successfully validate the signature on the response. again, there's no protocol for signing ICMPv6 using private key. IPsec (AH/ESP) doesn't work here. do you have any proposal? itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 29 08:21:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26123 for ; Mon, 29 Jul 2002 08:21:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Z9FK-000JQs-00 for namedroppers-data@psg.com; Mon, 29 Jul 2002 05:03:30 -0700 Received: from host1.btamail.net.cn ([202.106.196.71] helo=btmail.net.cn) by psg.com with smtp (Exim 3.36 #1) id 17Z9FE-000JQh-00 for namedroppers@ops.ietf.org; Mon, 29 Jul 2002 05:03:24 -0700 Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm23d453396; Mon, 29 Jul 2002 12:03:20 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmc3d4040eb; Thu, 25 Jul 2002 18:02:13 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA11490 for ietf-123-outbound.01@ietf.org; Thu, 25 Jul 2002 08:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA11164 for ; Thu, 25 Jul 2002 08:07:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29763; Thu, 25 Jul 2002 08:06:19 -0400 (EDT) Message-Id: <200207251206.IAA29763@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-mdns-11.txt Date: Thu, 25 Jul 2002 08:06:18 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,DOUBLE_CAPSWORD,EXCUSE_6 version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-11.txt Pages : 20 Date : 24-Jul-02 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-11.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: <20020724142737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142737.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 29 11:56:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05247 for ; Mon, 29 Jul 2002 11:56:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ZCdM-0001YS-00 for namedroppers-data@psg.com; Mon, 29 Jul 2002 08:40:32 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.36 #1) id 17ZCdE-0001YF-00 for namedroppers@ops.ietf.org; Mon, 29 Jul 2002 08:40:24 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 29 Jul 2002 15:40:24 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Mon, 29 Jul 2002 11:39:59 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002072911395908151 ; Mon, 29 Jul 2002 11:39:59 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 11:39:51 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2D1A@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Danny Mayer'" Cc: namedroppers@ops.ietf.org Subject: RE: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Mon, 29 Jul 2002 11:39:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wednesday, 24 July, 2002 at 18:27 Danny Mayer wrote: > The underlying issue here is that GSS-TSIG is being used as an > authentication mechanism for allowing dynamic updates to DNS by > clients. That updating mechanism should have been the responsibility > of the DHCP server which is responsible for issuing the IP addresses > and ensuring non-duplicate names for the client PC's. Only PC's > using a DHCP server to get an address need to have the DNS updated, > since PC's with static addresses should already be registered > in the DNS. Well, not really IMHO. Not to completely excuse the Win2K "enable dynamic update by default even for statically-assigned IP addresses", but there are several cases in which a host could benefit from an ability to update its own DNS info independent of DHCP servers: 1. System gets its IP address by DHCP, but has more than one valid DNS entry (usually in multiple domains). It's quite likely that the DHCP server does not have the power to update DNS information in all the appropriate places. Example: I might have a system that I want to be able to contact as gateway.vanitydomain.com, but which gets its IP address as part of the PPP negotiation when dialing into an ISP. 2. System has multiple static IP addresses assigned, but the "preferred" IP address may change over time. Example: at one time recently my laptop had separate static addresses when on two separate corporate networks, plus a third static address for my home network. At any one time, only one of these addresses was valid--and there were times when it would have been nice to update contact info in DNS for that laptop when the IP changed. (Yes, there are automagic ways to do this without a DHCP server, although they're fairly painful). Both of the above are limited/unusual cases, but I believe that they are valid. TSIG in general (not just GSS-TSIG) has the concept of secure dynamic update, and it's there for good reason--without being in any way limited to DHCP servers only. So the underlying issue is not that GSS-TSIG is being used as an authentication mechanism...that's by design. The underlying issue appears to be that GSS-TSIG escaped from the lab as a highly proprietary protocol rather than being worked on in the standards arena first. -- Rip Loomis Senior Systems Security Engineer SAIC Secure Business Solutions Group www.saic.com/securebiz Center for Information Security Technology www.cist-east.saic.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 30 07:46:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13041 for ; Tue, 30 Jul 2002 07:46:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ZV0m-000IeK-00 for namedroppers-data@psg.com; Tue, 30 Jul 2002 04:17:56 -0700 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 17ZV0c-000Idg-00 for namedroppers@ops.ietf.org; Tue, 30 Jul 2002 04:17:46 -0700 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA25378; Tue, 30 Jul 2002 14:17:43 +0300 Date: Tue, 30 Jul 2002 14:17:43 +0300 Message-Id: <200207301117.OAA25378@burp.tkv.asdf.org> From: Markku Savela To: namedroppers@ops.ietf.org Subject: We need "Scoped name resolution reference model" ? References: <200207251206.IAA29763@ietf.org> <200207251323.QAA05569@burp.tkv.asdf.org> <200207261457.RAA07732@burp.tkv.asdf.org> <20020726210247.GB2585@pianosa.catch22.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=2.8 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Having read and commented on , I think we might need a "Scoped name resolution reference model" or something, that specifies the framework for handling overlapping situations. - we have "traditional" global DNS - we have this new Link Local Name resolution - we may hava site local name resolution The includes some text about not having global DNS and LLMNR active at same time. This assumption requires highly special conditions (a closed meeting room without any outside network connections, permanently isolated network segments). In normal practise I would claim most useful ad hoc networks (bluetooth, wlan..) will also have occational access to the global internet and thus global DNS. There is a need to accept situation where a node can - has neither LLMNR nor global DNS - has LLMNR (on at least one link) - has global DNS - has both LLMNR and global DNS and node can transition between these states unpredictably. Then add possible site local DNS into this soup... It should be noted that LLMNR is somewhat different "taxonomically" from global DNS. LLMNR is P2P, global DNS is peer-to-server. One could consider P2P on site-local level (SLMNR?) or peer-to-server. Howabout global P2P name resolution, based on global multicast (yeah, does not scale? Unless you have IPSEC protected multicast group, and only limited membership :-) The reference model should tell how to behave in enviroment that has multiple enclosing name resolutions: - which order are queries sent (global -> site - > local or local -> site - > global, or something else?) - are gueries sent in parallel or one at time - how are conflicts handled (at least each level must have own cache, and each LLMNR must be cached separately per interface) [you can use from IPv6 scoped addressing architecture as cache id, for example] - if there are multiple LLMNR interfaces, how are queries handled? (send queries in parallel to all?) - can LLMNR contain only link local addresses in A and AAAA? Should name already tell the scope? Eg. only "*.local" names are resolved with LLMNR? "*.site"? Or can, any name "foo.bar.com" or address appear in any of the levels and you just get what is first found based on the search order? - what happens when some name resolution level becomes reachable or unreachable? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 31 17:33:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18869 for ; Wed, 31 Jul 2002 17:33:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17a0pj-000JtJ-00 for namedroppers-data@psg.com; Wed, 31 Jul 2002 14:16:39 -0700 Received: from [198.200.138.211] (helo=quadntweb.quadritek.com) by psg.com with esmtp (Exim 3.36 #1) id 17a0pd-000Jt4-00 for namedroppers@ops.ietf.org; Wed, 31 Jul 2002 14:16:33 -0700 Received: from quadritek.com ([198.200.138.158]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with ESMTP id com for ; Wed, 31 Jul 2002 17:15:44 -0400 Message-ID: <3D4853E9.BEA215BF@quadritek.com> Date: Wed, 31 Jul 2002 17:17:29 -0400 From: rhall@quadritek.com (Randy Hall) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard References: <211DE638FE1F094E96E3042DDF531CF9013DCBC5@win-msg-06.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > Here are the proposed solutions. > > 1. Modify RFC 2845 (TSIG) as follows: > > Replace: > > "The server MUST not generate a signed response to an unsigned > > request." > > > > With: > > "The server MUST not generate a signed response to an unsigned > > request, except in case of response to client's unsigned TKEY > > query if secret key is established on server side after server > > processed client's query. Signing responses to unsigned TKEY > > queries MUST be explicitly specified in the description of an > > individual secret key establishment algorithm." > > right now the base tsig document is independent of tkey. this was > originally due to the order of their creation, but it's still a > good property to have. so if approach #1 is taken, i recommend > broader wording: > > The server MUST NOT generate a signed response to an unsigned > request, unless the signature algorythm's specification allows > this (for example, see GSS-TSIG). I read thru the archives on this discussion and this seems to make the most sense of the options presented. I'm unaware of a technical downside to this change, and there appears to be less pain for the installed base (in the interest of disclosure - certainly less pain for Lucent and its customers). I wasn't around when 2845 was developed, nor am I an expert on it, but it seems to me that if all the protocols were developed at the same time, that it would not have been unreasonable to have written 2845 this way, since it doesn't seem unreasonable to me to allow the server to append a signature if it has the means to do so (and the algorithm allows this). Cheers Randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: