From owner-namedroppers@ops.ietf.org Wed Mar 01 02:40:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELwX-0003Zt-OK for dnsext-archive@lists.ietf.org; Wed, 01 Mar 2006 02:40:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FELwW-0001jX-81 for dnsext-archive@lists.ietf.org; Wed, 01 Mar 2006 02:40:17 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FELrW-000GAY-OZ for namedroppers-data@psg.com; Wed, 01 Mar 2006 07:35:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FELrT-000G9F-Ho for namedroppers@ops.ietf.org; Wed, 01 Mar 2006 07:35:03 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k217Z1mN002513 for ; Wed, 1 Mar 2006 08:35:01 +0100 (CET) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id k217Z0hq002512 for namedroppers@ops.ietf.org; Wed, 1 Mar 2006 08:35:00 +0100 (CET) (envelope-from olaf) Date: Wed, 1 Mar 2006 08:35:00 +0100 (CET) From: Olaf Kolkman Message-Id: <200603010735.k217Z0hq002512@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 01 10:17:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FET4u-00006o-7e for dnsext-archive@lists.ietf.org; Wed, 01 Mar 2006 10:17:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FET4s-0001Ry-NS for dnsext-archive@lists.ietf.org; Wed, 01 Mar 2006 10:17:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FET1L-00025q-TR for namedroppers-data@psg.com; Wed, 01 Mar 2006 15:13:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FET1K-00025a-Pb for namedroppers@ops.ietf.org; Wed, 01 Mar 2006 15:13:43 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k21FDb5i089965 for ; Wed, 1 Mar 2006 10:13:37 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k21FDarQ089964 for namedroppers@ops.ietf.org; Wed, 1 Mar 2006 10:13:36 -0500 (EST) (envelope-from namedroppers) Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEIZw-0003Zv-N1 for namedroppers@ops.ietf.org; Wed, 01 Mar 2006 04:04:44 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Feb 2006 20:04:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,155,1139212800"; d="scan'208"; a="22765136:sNHT22461384" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2144hqM023220; Tue, 28 Feb 2006 23:04:43 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 23:04:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Updated draft - draft-ietf-dnsext-dhcid-rr-12.txt Date: Tue, 28 Feb 2006 23:04:42 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21014DC4F1@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated draft - draft-ietf-dnsext-dhcid-rr-12.txt Thread-Index: AcY85UTAFxA+PKOdTk2lIWV8Rdd3cA== From: "Bernie Volz \(volz\)" To: , X-OriginalArrivalTime: 01 Mar 2006 04:04:43.0543 (UTC) FILETIME=[455B5A70:01C63CE5] X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] I've just submitted another update of the dhcid-rr draft. The changes are: 1. Added DHCID RDATA that was missing. Three people (myself, Mark Stapp, and Olafur) independently calculated the values. Thanks to Mark and Olafur for doing this. 2. Updated references from RFC 2535 to RFC 3548 in section 3.2 and RFC 4034 in section 3.5. 3. Revised the wording to clarify what is used from the DHCPv4 client identifier option, i.e., the entire option's data (type and identifier) is used. 4. Broke out the last 3 paragraphs as subsections to section 3.5 (3.5.1, 3.5.2, and 3.5.3) to separate out how the RDATA is generated. These changes were suggested by Olafur to improve the quality of the draft. Thanks Olafur. What I submitted is available at ftp://ftpeng.cisco.com/volz/draft-ietf-dnsext-dhcid-rr-12.txt until it is published on the IETF site. - Bernie -- to unsubscribe send a message to namedroppers-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 Mar 02 02:32:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEiIO-00014Y-Gp for dnsext-archive@lists.ietf.org; Thu, 02 Mar 2006 02:32:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEiIJ-00005K-6z for dnsext-archive@lists.ietf.org; Thu, 02 Mar 2006 02:32:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEiD3-0007Zu-Jd for namedroppers-data@psg.com; Thu, 02 Mar 2006 07:26:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [202.214.123.16] (helo=ns.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEiCt-0007Xs-Vs for namedroppers@ops.ietf.org; Thu, 02 Mar 2006 07:26:40 +0000 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id k227QXDE006632 for ; Thu, 2 Mar 2006 16:26:33 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id k227QK5J072680 for ; Thu, 2 Mar 2006 16:26:26 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Thu, 2 Mar 2006 16:26:16 +0900 From: Yukiyo Akisada To: namedroppers@ops.ietf.org Subject: DNS conformance tester version 1.0 is available Message-Id: <20060302162616.65517763.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi, all. We (TAHI Project) had released the newest DNS conformance tester. This release includes tests for server and client, and these are using IPv4 and IPv6 as transport protocol. The coverage is following. * RFC 1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES * RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION * RFC 1123 - Requirements for Internet Hosts -- Application and Support * RFC 1995 - Incremental Zone Transfer in DNS * RFC 1996 - A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) * RFC 2181 - Clarifications to the DNS Specification * RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) * RFC 2671 - Extension Mechanisms for DNS (EDNS0) * RFC 2782 - A DNS RR for specifying the location of services (DNS SRV) * RFC 3401 - Dynamic Delegation Discovery System (DDDS) - Part One: The Comprehensive DDDS * RFC 3402 - Dynamic Delegation Discovery System (DDDS) - Part Two: The Algorithm * RFC 3403 - Dynamic Delegation Discovery System (DDDS) - Part Three: The Domain Name System (DNS) Database * RFC 3404 - Dynamic Delegation Discovery System (DDDS) - Part Four: The Uniform Resource Identifiers (URI) Resolution Application * RFC 3405 - Dynamic Delegation Discovery System (DDDS) - Part Five: URI.ARPA Assignment Procedures * RFC 3425 - Obsoleting IQUERY * RFC 3596 - DNS Extensions to Support IP Version 6 You can get them from our web site. Please check them at Test Tool section on following URL. http://www.tahi.org/dns/ If you have some comments or question, please contact to contact@tahi.org. And you may have already known that we also have prepared ML for discussion about DNS test. If you have any interesting in it, please subscribe it. You can see detail information about ML at Discussion ssection on following URL. http://www.tahi.org/dns/ Thanks, ------------------------------------------------------------------------ Yukiyo Akisada -- to unsubscribe send a message to namedroppers-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 Mar 03 16:56:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHld-0000qd-Ii for dnsext-archive@lists.ietf.org; Fri, 03 Mar 2006 16:24:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFHJ3-0005yf-En for dnsext-archive@lists.ietf.org; Fri, 03 Mar 2006 15:55:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFHE7-000CMw-0H for namedroppers-data@psg.com; Fri, 03 Mar 2006 20:50:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFHDy-000CKt-6N for namedroppers@ops.ietf.org; Fri, 03 Mar 2006 20:50:06 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k23Ko1vP022408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Mar 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FFHDt-0005HS-OU; Fri, 03 Mar 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-12.txt Message-Id: Date: Fri, 03 Mar 2006 15:50:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for Encoding DHCP Information (DHCID RR) Author(s) : M. Stapp, et al. Filename : draft-ietf-dnsext-dhcid-rr-12.txt Pages : 12 Date : 2006-3-3 It is possible for DHCP clients to attempt to update the same DNS FQDN or attempt to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the "DHCID" RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-12.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-dhcid-rr-12.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: <2006-3-3130903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-3130903.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 Mar 05 11:25:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFw37-00031q-Kn for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 11:25:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFw36-0002P5-1J for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 11:25:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFvyZ-000Aja-Dg for namedroppers-data@psg.com; Sun, 05 Mar 2006 16:20:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFvyP-000AiK-NP for namedroppers@ops.ietf.org; Sun, 05 Mar 2006 16:20:45 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0017A9; 5 Mar 2006 11:20:25 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 5 Mar 2006 11:20:09 -0500 Received: from connotech.com (209.71.204.114) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0017A8; 5 Mar 2006 11:20:03 -0500 Message-ID: <440B18A9.4010407@connotech.com> Date: Sun, 05 Mar 2006 11:58:17 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: DNSSEC is almost worthless! Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Dear all: Some non-participants to the dnsext wg may assess the DNSSEC as a useless effort to solve a marginal security issue in Internet. For these persons, there is no reason to participate in dnsext activities related to DNSSEC. This message reviews the elements of DNSSEC added value, and then discusses a condition which may vary the DNSSEC added value according to the participant perspective. This is relevant to the discussion of trust anchor key requirements document: if DNSSEC has only some marginal value, it is justified to put little effort in coming up with a "rigorous" set of requirements. First, what does DNSSEC actually do? It provides DNS resolvers with end-to-end cryptographic assurance about data retrieved from the DNS. More precisely, it provides 1) a user feedback like a red-yellow-green light besides a domain name (resp. for bogus-insecure-secure DNSSEC name resolution status), or a turned-off traffic light (for an indeterminate DNSSEC status), 2) the same indication as in 1) above, but for a managed nameserver instead of an end-user system (e.g. bogus name resolution being logged in a corporate nameserver system), 3) key management support for other security schemes, i.e. secure applications that would retrieve data (typically public keys of remote parties in cryptographic protocols) from the secured DNS and accept the data only if its DNSSEC status is "secure". Item 1) requires a end-user education, which proved mostly ineffective for many IT security schemes. Item 1) is thus only valuable to financial institutions for maintaining the onus of on-line banking security to the account holders (so the bank can claim that it offered a "commercial-grade security procedure" allowing the account holder to protect himself from phishing/pharming attacks). Item 2) can assist a corporate IT department to protect its internal users from bogus data from the Internet DNS, provided sufficient attention is paid to the operation of the nameservice. Items 1) and 2) both require adoption of DNSSEC technology at various stages of the end-to-end process, and a noticeable penetration rate of DNSSEC. In the meantime, DNSSEC deployment without genuine value added is deemed to be insufficiently supported for proper implementation and troubleshooting. Some comments were made that DNSSEC is just too complex for effective deployment (e.g. message from Bert Hubert to namedroppers in Feb 2006). In addition, the end-to-end cryptographic assurance is perhaps justified mostly because there are too many nameservers operating with BIND version prior to 8.4 (these are vulnerable to the DNS cache poisoning attack). Items 1) and 2) obviously need trust anchor key configuration, but are not critically dependent on "rigorous" trust anchor rollover procedures. Item 3) is not strictly part of the DNSSEC service definition, but DNSSEC deployment would be instrumental in providing this novel means of authenticated public key distribution. This item 3) is perhaps the most tangible value from DNSSEC, but it is a niche application as the cryptographic application protocol usage is marginal in the first place. I may provide references supporting the existence of this item 3). DNSSEC-supported encryption (a by-product of item 3) is certainly not a welcome development for governmental organizations concerned with "national security interests". So, from the perspective of governments, DNSSEC application to public key distribution would not contribute to DNSSEC value. Many dnsext active participants work for organizations funded by, or receiving significant contracts from, the US or OECD governments, including two editors of draft-ietf-dnsext-rollover-requirements-00.txt. The item 3) needs trust anchor key configuration, just like items 1) and 2), but this time "rigorous" trust anchor rollover procedures would make a difference in the effectiveness of the "service" (from a security perspective). My understanding of the ietf dnsext current activities is much influenced by the marginal value of DNSSEC from items 1) and 2), and the negative value of item 3) from the perspective of governments. I don't know to which extent there are dnsext active participants who see positive value in item 3) to the point of contributing to the TAK rollover debate. TAKREM for DNSSEC (draft-moreau-dnsext-sdda-rr-01.txt, draft-moreau-dnsext-takrem-dns-01.txt) is *both* rigorous *and* efficient. Efficiency would be beneficial to DNSSEC deployment if there was value in DNSSEC to justify its deployment in the first place. About TAKREM rigor, the above suggests that the intrinsic security properties of TAKREM might appear as *lowering* the value of DNSSEC for governments. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Sun Mar 05 11:25:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFw3A-00034c-3v for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 11:25:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFw39-0002P9-Me for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 11:25:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFvyh-000Ajr-76 for namedroppers-data@psg.com; Sun, 05 Mar 2006 16:21:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFvyY-000AjO-1I for namedroppers@ops.ietf.org; Sun, 05 Mar 2006 16:20:54 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0017AB; 5 Mar 2006 11:20:33 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 5 Mar 2006 11:20:20 -0500 Received: from connotech.com (209.71.204.114) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0017AA; 5 Mar 2006 11:20:11 -0500 Message-ID: <440B18B2.2040500@connotech.com> Date: Sun, 05 Mar 2006 11:58:26 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Dear all: This message discusses the implications of a no-IPR encumberment requirement for trust anchor key rollover in DNSSEC, being considered by ietf dnsext wg in section 5.2 in draft-ietf-dnsext-rollover-requirements-00.txt. First of all, here is a relevant citation from an ietf wg process perspective, from RFC 3668 section 8: "But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses." In other words, there exists an *opportunity* for an IETF wg to evaluate alternate technologies in the presence of IPR claims. The current wording of section 5.2 in draft-ietf-dnsext-rollover-requirements-00.txt is an a-priori option abandonment formulation. In rational terms, a person or organization having an option would not renounce of it or abandon it earlier than the option exercise time. In saying e.g. "... in applying the discretion granted by RFC3668 section 8, as the case may be, the evaluation process should assign heavy ponderation to IPR hindrance ..." the wg governance would have kept its options open and, at the same time, give a clear indication for its future solution assessment. A working group is a political entity to which a single-actor rationale behavior model does not always apply. Why did the editors of draft-ietf-dnsext-rollover-requirements-00.txt jumped into the a- priori option abandonment formulation in the drafting of section 5.2? I suggest the following answer: the editors (or someone who influenced them) saw that an IPR-encumbered solution was technologically superior to another one that they preferred, so an a-priori abandonment strategy would fit their own purpose. If the IPR-encumbered technology is inferior or even equal to the free and preferred alternative, the a-priori option abandonment would have no appeal to the proposer. Then why nobody in the community yet objected to the a-priori option abandonment (once proposed)? Suppose DNSSEC has a greater than negligible value for some participants. A rational behavior would be to optimize its implementation, given the engineering constraints. If such participant has no bias for a trust anchor key solution, he/she would normally argue against an a-priori option abandonment. In the present case, trust anchor key configuration is the very first thing to do when a DNSSEC-aware resolver is installed. The need for rollover comes from the need to preserve security over time (i.e. maintaining the end-to-end cryptographic assurance about data retrieved from the DNS). It is thus somehow linked to the DNSSEC implementation optimization in the previous paragraph. So there are two possible conclusions: a) some active participants are biased towards a free alternative that they are satisfied with, and/or b) no remaining active participants see value in DNSSEC to the point where its implementation optimization is worth some efforts. Having reviewed the DNSSEC deployment issues, I think DNSSEC is almost worthless. So the dnsext active participants would be justified to let the requirement draft proceed with the a-priori option abandonment formulation of section 5.2. A separate message is posted about "DNSSEC is almost worthless!" Does anybody knows why DNSSEC deployment would be significantly valuable but keeping open an option (to study an IPR-encumbered implementation alternative) should be banned? Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Sun Mar 05 13:53:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFyLy-0007SQ-3T for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 13:53:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFyLx-0006bK-HP for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 13:53:14 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFyJZ-000OP5-Px for namedroppers-data@psg.com; Sun, 05 Mar 2006 18:50:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFyJY-000OOs-No for namedroppers@ops.ietf.org; Sun, 05 Mar 2006 18:50:44 +0000 Received: from ngarcha.here (ksanti.fugue.com [66.93.162.128]) (using SSLv3 with cipher EXP1024-RC4-SHA (56/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 1AFA156833; Sun, 5 Mar 2006 10:50:44 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: Thierry Moreau Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Sun, 5 Mar 2006 11:50:58 -0700 User-Agent: KMail/1.9.1 Cc: namedroppers@ops.ietf.org References: <440B18B2.2040500@connotech.com> In-Reply-To: <440B18B2.2040500@connotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603051150.58807.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Thierry, I can tell you from my perspective as a person who has no emotional involvement whatsoever in the choice between rollover models (other than that I'd like for a choice to be made) that the fact that your draft is encumbered with a patent makes it extremely unattractive to me. I know the people who do DNSSEC. I've known them for a long time. They are good folks. They've been working on this thankless task for over a decade. They've had various smart people and various idiots stand in their way, and they've dealt with these afflictions with a dignity that I admire. At one point one of the (corporate) proponents of DNSSEC held a conference that I attended to look into doing DNSSEC and DHCP together; they didn't charge me a penny for my participation, which did cost them money. They were even nice to me when I got paranoid about whether the restaurant we were going to would have vegetarian food and made a small scene about it. And I happen to know that this is not the only such conference that has occurred - it's just the only one I've been to, because I personally don't have that much to do with DNSSEC. So it's not appropriate for you to frame the discussion of the patent on your technique for key rollover in terms of value. Real money has been spent by the proponents of DNSSEC to make it happen, and real sweat equity as well. And frankly the main thing that's prevented DNSSEC from being deployed is people trying to figure out how they can make money from it. Generally speaking, the answer has been "exclude most domain names, because the owners of those domains can't afford to pay what we want to charge." The point of promoting the standard is to get everyone to use it, not to create a small fenced-in world where a few people who can pay use it. It's not to make a gigabuck taxing access to the technology. It's to get the technology out there, to make peoples safer from hack attacks, even if they don't know they're safer. The fear that I have, and that perhaps others in this working group share, is that you want a tax on every DNS lookup. I've seen many people ask, "what is your intention with respect to this patent? How do you intend to license it?" You haven't said anything about this that I can recall seeing - please correct me if I am wrong. I can attribute this to one of two explanations: either you actually expect to get some tax on DNS lookups, and don't want to mention this until you have captured the market by getting your draft turned into an RFC, or we as a group have stepped on some cultural norm we weren't aware of, and offended you so extremely that you can't even bring yourself to make explicit that you feel offended in this way. I can see how this could have happened, particularly if you are more accustomed to other standards bodies, where patents are part of the cultural norm, and small royalties are as well. But that's not the cultural norm of the IETF. We aren't culturally okay with monetizing mainstream protocols, whatever it says in the IPR RFCs (which, by the way, are studiously neutral on this topic). Whichever explanation of your motivation is true, if you persist in not talking about your motivation, I think what's going to happen is that the working group is going to assume the worst, and your draft is never going to be seriously considered. This may or may not be fair to you - since I can't read your mind, I don't know. You do have a knob you can turn: tell us what you want. If it turns out that we're not willing to give it to you, the outcome is going to be no worse than what happens if you say nothing. -- to unsubscribe send a message to namedroppers-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 Mar 05 14:09:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFyc8-0005C6-EP for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 14:09:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFyc7-0006x9-Ut for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 14:09:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFyaH-0000Dq-GH for namedroppers-data@psg.com; Sun, 05 Mar 2006 19:08:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFyaG-0000De-R9 for namedroppers@ops.ietf.org; Sun, 05 Mar 2006 19:08:00 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 78F7411425 for ; Sun, 5 Mar 2006 19:08:00 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Sun, 05 Mar 2006 11:58:26 EST." <440B18B2.2040500@connotech.com> References: <440B18B2.2040500@connotech.com> Date: Sun, 05 Mar 2006 19:08:00 +0000 Message-Id: <20060305190800.78F7411425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 # Why did the editors of # draft-ietf-dnsext-rollover-requirements-00.txt jumped into the a- # priori option abandonment formulation in the drafting of section # 5.2? I suggest the following answer: the editors (or someone who # influenced them) saw that an IPR-encumbered solution was # technologically superior to another one that they preferred, so # an a-priori abandonment strategy would fit their own purpose. as an influencer, i should speak up as to my motives. i don't know whether TAKREM is good enough, better, worse, or inadequate compared to other solutions in the space. i do know that it smells like a "patent binary arithmetic" or "copyright the happy birthday song" approach, where there is no actual new idea, just a new presentation of straightforward ideas already present in the field. if my instinct is right, then TAKREM's IPR claims could be trivially overcome by anyone implementing commercial technology in this field, but it will cost money. in that sense, TAKREM smells like an extortion attempt -- "it's cheaper to license it than fight". lastly, TAKREM's IPR claims smell bad because they are so broad that almost any solution to trust anchor rollover could be accused of infringing on the TAKREM IPR. taken together, TAKREM is the most wholly unprofessional money-grab i've seen since the beginning of the blackberry/R.I.M. affair or the SCO-vs-IBM battle, and my strongest personal reaction to it is "don't even want to dignify it with a reply." however, my personal reaction won't matter to ISC (publisher of BIND). what matters to ISC is that we have to be able to publish reference implementations of the DNS protocol under a BSD-style copyright. TAKREM would require that we switch to a GPL-style copyright, which we will not do. therefore if TAKREM were to be standardized, then it would not be implemented in ISC BIND, and i'm pretty sure it would be harder to deploy technology in this niche without ISC. (perhaps this overstates ISC's importance, but some large BIND Forum members have indicated solidarity for this position.) so, i havn't reviewed TAKREM because it protected IPR can have no part of the future of the DNS protocol. not because i'm somehow afraid that it's better, but because it self-disqualifies without reference to its quality/usability. # If the IPR-encumbered technology is inferior or even equal to the free and # preferred alternative, the a-priori option abandonment would have no appeal # to the proposer. that's so nonsequitur that i don't even know how to parse it. if you want to be taken seriously as a protocol engineer, then stop trying to monetize the standardization process. -- to unsubscribe send a message to namedroppers-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 Mar 05 14:17:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFyjo-0003DK-TG for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 14:17:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFyjm-0007C2-Jr for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 14:17:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFyhr-00019j-TO for namedroppers-data@psg.com; Sun, 05 Mar 2006 19:15:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FFyhr-00019V-CF for namedroppers@ops.ietf.org; Sun, 05 Mar 2006 19:15:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1397411425 for ; Sun, 5 Mar 2006 19:15:51 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSSEC is almost worthless! In-Reply-To: Your message of "Sun, 05 Mar 2006 11:58:17 EST." <440B18A9.4010407@connotech.com> References: <440B18A9.4010407@connotech.com> Date: Sun, 05 Mar 2006 19:15:51 +0000 Message-Id: <20060305191551.1397411425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 # In addition, the end-to-end cryptographic assurance is perhaps justified # mostly because there are too many nameservers operating with BIND version # prior to 8.4 (these are vulnerable to the DNS cache poisoning attack). no part of the justification of DNSSEC relates to poison-susceptible name server implementations. any cache can be poisoned, including modern BIND9 or DJBDNS with all known anti-poison features enabled. # TAKREM for DNSSEC (draft-moreau-dnsext-sdda-rr-01.txt, # draft-moreau-dnsext-takrem-dns-01.txt) is *both* rigorous *and* # efficient. Efficiency would be beneficial to DNSSEC deployment if there was # value in DNSSEC to justify its deployment in the first place. About TAKREM # rigor, the above suggests that the intrinsic security properties of TAKREM # might appear as *lowering* the value of DNSSEC for governments. i believe that we'll be able to resolve trust anchor management without subjecting ourselves to anyone's IPR claims. the first step toward this will be to ignore known-encumbered technology. an eventual step will be to try to avoid submarine IPR with field surveys. the final step will be to fight (in the market and/or in the courts) the IPR holders who will claim overbroad coverage for their IPR. -- to unsubscribe send a message to namedroppers-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 Mar 05 15:44:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG05z-0003X6-W2 for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 15:44:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG05y-0001BF-9i for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 15:44:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG02x-0009gJ-Aj for namedroppers-data@psg.com; Sun, 05 Mar 2006 20:41:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [66.119.143.51] (helo=mail.rfburst.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG02w-0009g8-G9 for namedroppers@ops.ietf.org; Sun, 05 Mar 2006 20:41:42 +0000 Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k25KfV70018878; Sun, 5 Mar 2006 13:41:33 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k25KfpCj032323; Sun, 5 Mar 2006 13:41:52 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k25Kfo2N032319; Sun, 5 Mar 2006 13:41:50 -0700 Date: Sun, 5 Mar 2006 13:41:50 -0700 Message-Id: <200603052041.k25Kfo2N032319@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" Reply-To: "The Purple Streak, Hilarie Orman" To: paul@vix.com Cc: namedroppers@ops.ietf.org In-reply-to: Yourmessage <20060305190800.78F7411425@sa.vix.com> X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hoping to direct the conversation to its most salient points ... > what > matters to ISC is that we have to be able to publish reference implementations > of the DNS protocol under a BSD-style copyright. What's the source of this requirement on ISC? > TAKREM would require that > we switch to a GPL-style copyright, which we will not do. I think someone from Verisign said the same thing a few months ago. Why won't ISC adopt GPL? Hilarie -- to unsubscribe send a message to namedroppers-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 Mar 05 21:35:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG5Yr-0003Kb-49 for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 21:35:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG5Yp-0003OR-P5 for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 21:35:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG5Uq-000DVo-JJ for namedroppers-data@psg.com; Mon, 06 Mar 2006 02:30:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG5Up-000DVa-T4 for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 02:30:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3A8AD11426 for ; Mon, 6 Mar 2006 02:30:51 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Sun, 05 Mar 2006 13:41:50 MST." <200603052041.k25Kfo2N032319@localhost.localdomain> References: <200603052041.k25Kfo2N032319@localhost.localdomain> Date: Mon, 06 Mar 2006 02:30:51 +0000 Message-Id: <20060306023051.3A8AD11426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 # Hoping to direct the conversation to its most salient points ... imho, this isn't one (a salient point). # > what matters to ISC is that we have to be able to publish reference # > implementations of the DNS protocol under a BSD-style copyright. # # What's the source of this requirement on ISC? in 1994 rick adams (then president of uunet) handed me a check to found isc and he said "none of that gnu public virus crap, got it?" i got it. every dollar/yen/yuan/mark/franc/euro/ruble/etc we've taken in since that time (including yours, hilarie, while at DoD) was with the understanding that all funded work would be released under a BSD-style license. that's what the board believed when they signed on, it's what our occasional grant funding angels believe, it's what much of our staff believes, it's what several large BIND Forum members believe, and of course it's what i believe, and is part of the "why paul vixie is at ISC at all" equation. but none of that matters. # > TAKREM would require that we switch to a GPL-style copyright, which we # > will not do. # # I think someone from Verisign said the same thing a few months ago. # Why won't ISC adopt GPL? because it's far too restrictive. before we continue, and before anyone else jumps in, please realize three things: (1) you probably have not read both licenses and you really should, and (2) this is religion and politics and economics, not technology, and (3) this topic is about ISC not DNS, and only ISC's relevance to DNS is on-topic here -- not ISC's licensing religion. -- to unsubscribe send a message to namedroppers-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 Mar 05 23:17:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG79z-00053K-ST for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 23:17:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG79y-0006Cy-H5 for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 23:17:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG77H-000N1F-5L for namedroppers-data@psg.com; Mon, 06 Mar 2006 04:14:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG77G-000N10-LV for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 04:14:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 444BE11425 for ; Mon, 6 Mar 2006 04:14:38 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Sun, 05 Mar 2006 20:15:39 MST." <200603060315.k263FdtR015573@localhost.localdomain> References: <200603060315.k263FdtR015573@localhost.localdomain> Date: Mon, 06 Mar 2006 04:14:38 +0000 Message-Id: <20060306041438.444BE11425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 # > (including yours, hilarie, while at DoD) # # Goodness, Paul, that was US taxpayer money! the US taxpayers weren't who i would've felt like i'd disappointed if i'd screwed up, though. (i suspect that most folks on namedroppers don't know that without you and russ mundy, BIND9 would have been designed without any kind of DNSSEC or even the latent capability for adding it in later, which is my real reason for mentioning it here.) -- to unsubscribe send a message to namedroppers-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 Mar 05 23:59:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG7od-0004zL-Tt for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 23:59:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG7oc-00079T-Kb for dnsext-archive@lists.ietf.org; Sun, 05 Mar 2006 23:59:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG7md-0001JH-H8 for namedroppers-data@psg.com; Mon, 06 Mar 2006 04:57:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG7mc-0001J3-H0 for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 04:57:22 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k264vCci020008 for ; Sun, 5 Mar 2006 23:57:12 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k264vCov020007 for namedroppers@ops.ietf.org; Sun, 5 Mar 2006 23:57:12 -0500 (EST) (envelope-from namedroppers) Received: from [66.119.143.51] (helo=mail.rfburst.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FG6G7-000Hx3-ON for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 03:19:44 +0000 Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k263JS70005337; Sun, 5 Mar 2006 20:19:29 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k263FeCj015578; Sun, 5 Mar 2006 20:15:40 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k263FdtR015573; Sun, 5 Mar 2006 20:15:39 -0700 Date: Sun, 5 Mar 2006 20:15:39 -0700 Message-Id: <200603060315.k263FdtR015573@localhost.localdomain> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: paul@vix.com Cc: namedroppers@ops.ietf.org In-reply-to: Yourmessage <20060306023051.3A8AD11426@sa.vix.com> X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > i got it. every > dollar/yen/yuan/mark/franc/euro/ruble/etc we've taken in since that time > (including yours, hilarie, while at DoD) Goodness, Paul, that was US taxpayer money! Hilarie -- to unsubscribe send a message to namedroppers-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 Mar 06 05:09:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGCeo-00049C-47 for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 05:09:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGCem-0002Ne-O4 for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 05:09:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGCc9-0000zr-49 for namedroppers-data@psg.com; Mon, 06 Mar 2006 10:06:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGCc8-0000zf-Fd for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 10:06:52 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D5365C2DAB; Mon, 6 Mar 2006 10:06:55 +0000 (GMT) Date: Mon, 06 Mar 2006 10:06:44 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <16A00D5CE200CBF7943FF27D@[192.168.100.25]> In-Reply-To: <20060306023051.3A8AD11426@sa.vix.com> References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d --On 06 March 2006 02:30 +0000 Paul Vixie wrote: > because it's far too restrictive. before we continue, and before anyone > else jumps in, please realize three things: (1) you probably have not read > both licenses and you really should, and (2) this is religion and politics > and economics, not technology, and (3) this topic is about ISC not DNS, > and only ISC's relevance to DNS is on-topic here -- not ISC's licensing > religion. Actually, it's about a rather wider issue than that. It's about whether or not ANY author of a resolver library (not just ISC) should have the ability to publish it under a license of his/her choice without then being in hoc to a patent holder. Sure ISC is a (very) significant such author, but it is not guaranteed to be the only one in perpetuity. So even if ISC /did/ support a GPL carveout on patents, I would be arguing strongly against it. DNS is fundamentally about interoperability. Resolver libraries tend to live pretty low down the system stack, and need to link (directly or indirectly) to everything. Ensuring we have sensible licensing here is vital. Patent encumbered technologies (albeit with GPL carveouts) are not sufficient. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 06 05:45:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGDDC-0003ka-Uq for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 05:45:10 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGBuN-0007yo-5z for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 04:21:39 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGBjD-0006aB-68 for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 04:10:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGBg0-000MME-EV for namedroppers-data@psg.com; Mon, 06 Mar 2006 09:06:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGBfr-000MKX-BW for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 09:06:39 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4F7FA33C1C; Mon, 6 Mar 2006 09:06:32 +0000 (GMT) Message-ID: <440BFB1D.7070503@algroup.co.uk> Date: Mon, 06 Mar 2006 09:04:29 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "The Purple Streak, Hilarie Orman" CC: paul@vix.com, namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <200603052041.k25Kfo2N032319@localhost.localdomain> In-Reply-To: <200603052041.k25Kfo2N032319@localhost.localdomain> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 The Purple Streak, Hilarie Orman wrote: > Hoping to direct the conversation to its most salient points ... > >> what >> matters to ISC is that we have to be able to publish reference implementations >> of the DNS protocol under a BSD-style copyright. > > What's the source of this requirement on ISC? Just so its clear that it isn't only ISC that feels this way, all the free software I've put any significant effort into is BSD-licensed, and that's by design. Indeed, The Apache Software Foundation, which I helped found, is also BSD-only (though it now uses its own licence which includes language about patents). The reason for this is that I (and the ASF) want to write software that people can use. The GPL prevents use in environments where other software that will be combined cannot be made free, either through religion or licensing agreements or something else. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 06 07:21:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEit-0005eM-9M for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 07:21:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGEir-0006EJ-SI for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 07:21:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGEfO-0009cx-VZ for namedroppers-data@psg.com; Mon, 06 Mar 2006 12:18:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_00,FUZZY_REFINANCE, RCVD_IN_SBL,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGEfN-0009cf-Lb for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 12:18:21 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0017C6; 6 Mar 2006 07:18:02 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 6 Mar 2006 07:17:55 -0500 Received: from connotech.com (209.71.204.105) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0017C5; 6 Mar 2006 07:17:52 -0500 Message-ID: <440C3161.9060701@connotech.com> Date: Mon, 06 Mar 2006 07:56:01 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <440B18B2.2040500@connotech.com> <20060305190800.78F7411425@sa.vix.com> In-Reply-To: <20060305190800.78F7411425@sa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Paul Vixie wrote, in part: > [W]hat > matters to ISC is that we have to be able to publish reference implementations > of the DNS protocol under a BSD-style copyright. TAKREM would require that > we switch to a GPL-style copyright, which we will not do. [T]herefore if TAKREM > were to be standardized, then it would not be implemented in ISC BIND, and i'm > pretty sure it would be harder to deploy technology in this niche without ISC. > (perhaps this overstates ISC's importance, but some large BIND Forum members > have indicated solidarity for this position.) It is clear that the ISC's ability to *publish* a reference implementation of the DNS protocol using BSD-style licensing is a well-established practice in the DNS field, to the benefit of the Internet, and without direct rewards for the ISC financial contributors. As a requirement in the requirement draft, this would be phrased like "In the presence of IPR, attention should be paid to the ability to publish reference implementations of the DNS protocol as such publication represents an important mechanism of ietf protocol standardization activities." Keeping in mind that 1)turning a reference implementation into "proprietary fork", and 2)deploying it, e.g. by service organizations that are financed by DNS name registration fees goes beyond mere reference implementation publication, the above requirement might be accommodated by well-delineated licensing terms (i.e. allowing free publication but requiring additional license for proprietary fork and/or fee-based deployment). Actually, the separation of TAKREM specifications in two drafts and some software structure in the source code posted on the CONNOTECH web site are meant to ease such licensing practice. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 06 09:15:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGUk-0001yW-Bg for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 09:15:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGUi-0003hG-Uq for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 09:15:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGGRc-000Ikk-Q4 for namedroppers-data@psg.com; Mon, 06 Mar 2006 14:12:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGGRb-000IkU-Ox for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 14:12:16 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO0017CD; 6 Mar 2006 09:11:57 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 6 Mar 2006 09:11:46 -0500 Received: from connotech.com (209.71.204.108) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG0017CC; 6 Mar 2006 09:11:41 -0500 Message-ID: <440C4C10.5010602@connotech.com> Date: Mon, 06 Mar 2006 09:49:52 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lemon , Namedroppers Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <440B18B2.2040500@connotech.com> <200603051150.58807.Ted.Lemon@nominum.com> In-Reply-To: <200603051150.58807.Ted.Lemon@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 In a long post, Ted Lemon wrote: > > [... intro and vegetarian restaurant ...] > > So it's not appropriate for you to frame the discussion of the patent on your > technique for key rollover in terms of value. > The value in DNSSEC that I refer is from no deployment to some deployment, and *not* from no specifications/working-code to some specifications/working-code. The latter is where most of the money has been spent so far, in the collaborative mode that you describe. > [...] > And frankly the main thing that's prevented DNSSEC from being deployed is > people trying to figure out how they can make money from it. Generally > speaking, the answer has been "exclude most domain names, because the owners > of those domains can't afford to pay what we want to charge." > There is a cost structure associated with the DNSSEC deployment. The benefits are accrued to the resolver side, and the bulk of the costs are incurred on the nameserver side. > > [...] > > The fear that I have, and that perhaps others in this working group share, is > that you want a tax on every DNS lookup. I've seen many people ask, "what > is your intention with respect to this patent? How do you intend to license > it?" You haven't said anything about this that I can recall seeing - please > correct me if I am wrong. > See http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01694.html and http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01804.html Some details might need to be updated, but the main ideas remain. > > [... about "the cultural norm of the IETF" ...] > I take good note of this. > We aren't culturally okay with > monetizing mainstream protocols. > However, DNS name registration and nameserver operations is an industry which is even studied by OECD economists. There is thus a mismatch between the cultural norm of the IETF and deployment contingencies. > [...] I don't know to which extent your post relates to draft-ietf-dnsext-rollover-requirements-00.txt, but anyway thanks for it. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 06 10:45:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHtV-0004WV-LT for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 10:45:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGHtU-0006ya-B6 for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 10:45:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGHr2-000PNA-2S for namedroppers-data@psg.com; Mon, 06 Mar 2006 15:42:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGHr1-000PMt-Fd for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 15:42:35 +0000 Received: from roaming19.int.libertyrms.com ([10.1.3.249]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FGHr0-0006bZ-1j for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 10:42:34 -0500 Received: by roaming19.int.libertyrms.com (Postfix, from userid 1019) id 5163818E8D8; Mon, 6 Mar 2006 10:42:10 -0500 (EST) Date: Mon, 6 Mar 2006 10:42:10 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <20060306154209.GB23680@afilias.info> Reply-To: Andrew Sullivan References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> <16A00D5CE200CBF7943FF27D@[192.168.100.25]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16A00D5CE200CBF7943FF27D@[192.168.100.25]> User-Agent: Mutt/1.5.11 X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Mon, Mar 06, 2006 at 10:06:44AM +0000, Alex Bligh wrote: > Resolver libraries tend to live pretty low down the system stack, and > need to link (directly or indirectly) to everything. Ensuring we have > sensible licensing here is vital. Patent encumbered technologies (albeit > with GPL carveouts) are not sufficient. I think the above highlights something that I believe is correct in the requirements draft: the IPR restrictions, if any, are not incidental to the technology that is to be picked in this case, but are instead central. As RFC 3979 says, "In all matters of Intellectual Property Rights, the intent is to benefit the Internet community and the public at large, while respecting the legitimate rights of others." There simply isn't a way to benefit the Internet community and the public at large by adopting any sort of potential encumbrance in a technology totally fundamental to the operation of the Net, because there's a significant portion of the Internet community that relies on BSD software. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Mar 06 13:39:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKc7-0002Gf-Cf for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 13:39:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKc6-000537-VS for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 13:39:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGKXC-0006Mu-C3 for namedroppers-data@psg.com; Mon, 06 Mar 2006 18:34:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGKXB-0006Mb-L1 for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 18:34:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E90791142C for ; Mon, 6 Mar 2006 18:34:16 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Mon, 06 Mar 2006 10:06:44 GMT." <16A00D5CE200CBF7943FF27D@[192.168.100.25]> References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> <16A00D5CE200CBF7943FF27D@[192.168.100.25]> Date: Mon, 06 Mar 2006 18:34:16 +0000 Message-Id: <20060306183416.E90791142C@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 # > ... only ISC's relevance to DNS is on-topic here -- not ISC's licensing # > religion. # # Actually, it's about a rather wider issue than that. It's about whether # or not ANY author of a resolver library (not just ISC) should have the # ability to publish it under a license of his/her choice without then # being in hoc to a patent holder. Sure ISC is a (very) significant such # author, but it is not guaranteed to be the only one in perpetuity. ISC is already not the only author/publisher of free-ish resolver libraries. # So even if ISC /did/ support a GPL carveout on patents, I would be arguing # strongly against it. DNS is fundamentally about interoperability. Resolver # libraries tend to live pretty low down the system stack, and need to link # (directly or indirectly) to everything. Ensuring we have sensible licensing # here is vital. Patent encumbered technologies (albeit with GPL carveouts) # are not sufficient. note that a patent would probably not proscribe ISC from publishing code that implemented an claimed algorithm. it would proscribe folks from using it in commerce, either by selling products that implemented the claimed algorithm, or by operating a revenue-generating service that implemented the claimed algorithm. coming after ISC would make no sense since there's no revenue stream associated with our publication of BSD-licensed software. interestingly, ISC makes no assurances that our software is IPR-free, but we do make a best effort to ensure such. (no _assurance_ is possible, due to possible submarine patents.) knowing in advance that a given algorithm is encumbered would prevent us from implementing/publishing code using such. that having been said, you are right that the real issue is in monetization itself, not in where it occurs. i strongly believe that any encumbered technology should either be available with a royalty-free license to all internet users, service providers, and technology vendors; or it should not be made an internet standard. this was my position on the use of RSA, and RSADSI kindly created a "dnssafe" package with a license permitting unlimited royalty-free use for DNSSEC, which we then used in BIND8 where we needed RSA. (thanks are due from all of us to steve crocker for brokering that deal, btw.) this whole thread is a distraction. the author of TAKREM isn't going to grant a world wide perpetual royalty-free license for all uses commercial or otherwise for his claimed IPR -- indeed, that would be against the purpose he has stated for even claiming the IPR in the first place. this means we have to press on with technology approaches we believe to be unencumbered. in the end, we will have some kind of trust key rollover mechanism, and the TAKREM author can do a SCO or R.I.M. style attack against anyone who successfully monetizes the result (that is, claiming that ALL possible ways to solve this problem are covered under the TAKREM patent) and we'll all deal with the mess at that time. for now, let's focus on solutions, not licensing religion? -- to unsubscribe send a message to namedroppers-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 Mar 06 13:45:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKiU-0006x9-Kl for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 13:45:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKiS-0005AQ-B8 for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 13:45:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGKgF-0006yS-Fg for namedroppers-data@psg.com; Mon, 06 Mar 2006 18:43:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGKgE-0006yH-U1 for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 18:43:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8DFEE1142B for ; Mon, 6 Mar 2006 18:43:38 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Mon, 06 Mar 2006 10:42:10 EST." <20060306154209.GB23680@afilias.info> References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> <16A00D5CE200CBF7943FF27D@[192.168.100.25]> <20060306154209.GB23680@afilias.info> Date: Mon, 06 Mar 2006 18:43:38 +0000 Message-Id: <20060306184338.8DFEE1142B@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d # ... There simply isn't a way to benefit the Internet community and the # public at large by adopting any sort of potential encumbrance in a # technology totally fundamental to the operation of the Net, because there's # a significant portion of the Internet community that relies on BSD software. i agree with your conclusion, but not with your reasoning. what the internet community relies on is unencumbered technology. one expects that if somebody were to come forward with a patent that they believed covered TCP or IP, and tried to get everyone in the world to pay a millicent per packet, that we'd very quickly see the rapid development and deployment of some non-encumbered alternatives. (and in the course of developing such alternatives, we would disqualify any proposal that had known encumberances, unless the IPR-holder were to grant a permanent, world wide, royalty free license for all uses either commercial or not.) so it's not really a question about BSD vs GPL at all. it's a question of encumberances. internet technology standards must be unencumbered to the best of our ability. by disclosing his encumberances, the TAKREM author has disqualified himself, or at least his work, from further consideration. now can we talk about possible approaches? i still like my modified version of the ihren/kolkman proposal, but i've been waiting for the requirements doc to be done, and now there's mud in THAT water as well. (don't'cha sometimes wish that something like MODA existed to fund this kind of protocol scutwork?) -- to unsubscribe send a message to namedroppers-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 Mar 06 15:40:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMVQ-0001ef-D9 for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 15:40:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMVQ-0000ox-3k for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 15:40:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGMRD-000Dnx-Uu for namedroppers-data@psg.com; Mon, 06 Mar 2006 20:36:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGMRD-000Dnl-3B for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 20:36:15 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k26KZxvP010314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Mar 2006 20:35:59 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGMQx-0003FS-MA; Mon, 06 Mar 2006 15:35:59 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair , dnsext chair Subject: Protocol Action: 'Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)' to Proposed Standard Message-Id: Date: Mon, 06 Mar 2006 15:35:59 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb The IESG has approved the following document: - 'Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) ' as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-05.txt Technical Summary Given the crumbling confidence in SHA-1, DNSEXT with the urging of Russ Housley,decided to address the weakest part of the DNSSEC chain, the long lived digest in the DS record. DS is used to transfer trust from a parent zone to a DNSKEY atchild. The DS record stores a digest of the public part of the key that child uses to sign its own DNSKEY set. The change to SHA-256 is considered significant improvement in resilience, the Working group is aware that this might be a temporary measure until new generation of standardized Digest algorithms becomes available This document also contains some guidance on how implementations treat DS sets where there are multiple digest algorithms used. This part of the document has seen most discussion and clarifications of text. There is a strong consensus behind this document. Working Group Summary This document is a work item of the DNSEXT WG. The WG has consensus to publish this document as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. -- to unsubscribe send a message to namedroppers-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 Mar 06 16:14:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGN2g-0003NN-Nz for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 16:14:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGN2f-0006Ua-FQ for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 16:14:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGN0u-000GZU-FN for namedroppers-data@psg.com; Mon, 06 Mar 2006 21:13:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGN0t-000GYk-R3 for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 21:13:08 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k26LCvIV023665; Mon, 6 Mar 2006 21:12:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k26LCvZB023664; Mon, 6 Mar 2006 21:12:57 GMT Date: Mon, 6 Mar 2006 21:12:57 +0000 From: bmanning@vacation.karoshi.com To: Thierry Moreau Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <20060306211257.GB23456@vacation.karoshi.com.> References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> <16A00D5CE200CBF7943FF27D@[192.168.100.25]> <20060306183416.E90791142C@sa.vix.com> <440CAA21.40103@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <440CAA21.40103@connotech.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On Mon, Mar 06, 2006 at 04:31:13PM -0500, Thierry Moreau wrote: > > > Paul Vixie wrote: > > >[...] > >[T]he TAKREM > >author can do a SCO or R.I.M. style attack against anyone who successfully > >monetizes the result (that is, claiming that ALL possible ways to solve > >this > >problem are covered under the TAKREM patent) [...]. > > > > This is completely ridiculous! Please record my disagreement. > > > -- > > - Thierry Moreau > i'm going to have to agree w/ Thierry here. Now if Paul said "[T]he TAKREM *patent holder* can do..." then i'd have to jump w/ Paul. It just silly to think that the author would always remain the patent holder. So regardless of the authors benign intentions, the mere existance of such encumbrence gives one pause. (consider the estate of Heddy Lamar) --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 Mar 06 16:34:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGMk3-00009i-SH for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 15:55:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGMk1-0003V4-Tc for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 15:55:43 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGMiF-000F6U-9r for namedroppers-data@psg.com; Mon, 06 Mar 2006 20:53:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGMiE-000F6G-53 for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 20:53:50 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO001836; 6 Mar 2006 15:53:31 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 6 Mar 2006 15:53:17 -0500 Received: from connotech.com (209.71.204.102) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001835; 6 Mar 2006 15:53:09 -0500 Message-ID: <440CAA21.40103@connotech.com> Date: Mon, 06 Mar 2006 16:31:13 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> <16A00D5CE200CBF7943FF27D@[192.168.100.25]> <20060306183416.E90791142C@sa.vix.com> In-Reply-To: <20060306183416.E90791142C@sa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Paul Vixie wrote: > [...] > [T]he TAKREM > author can do a SCO or R.I.M. style attack against anyone who successfully > monetizes the result (that is, claiming that ALL possible ways to solve this > problem are covered under the TAKREM patent) [...]. > This is completely ridiculous! Please record my disagreement. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 06 18:23:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGP3S-0003Pi-4Q for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 18:23:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGP3R-0006Tm-Lu for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 18:23:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGOzw-000OaE-RO for namedroppers-data@psg.com; Mon, 06 Mar 2006 23:20:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGOzw-000OZz-4a for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 23:20:16 +0000 Received: from [10.0.0.13] ([::ffff:195.157.120.101]) (AUTH: PLAIN matt, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 06 Mar 2006 18:20:14 -0500 id 002D000A.440CC3AE.00004116 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <440C4C10.5010602@connotech.com> References: <440B18B2.2040500@connotech.com> <200603051150.58807.Ted.Lemon@nominum.com> <440C4C10.5010602@connotech.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98E6A676-A197-4DAC-A096-0B92D6052D7B@verisign.com> Content-Transfer-Encoding: 7bit From: Matt Larson Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Mon, 6 Mar 2006 18:20:08 -0500 To: Namedroppers X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Mar 6, 2006, at 9:49 AM, Thierry Moreau wrote: >> We aren't culturally okay with monetizing mainstream protocols. > > However, DNS name registration and nameserver operations is an > industry > which is even studied by OECD economists. There is thus a mismatch > between the cultural norm of the IETF and deployment contingencies. Translation: "People are making money here and I want some, too." I'm in agreement with Paul that this whole thread is a distraction. I continue to remain happily ignorant of the details of TAKEM because the author--both by what he has said and done and by what he has not said and not done--has made it clear that there will not be acceptable license terms that will result in this technology being unencumbered. Thus it is best ignored and set aside. We should redouble our efforts to improve the rollover requirements draft, pick a solution and move on. We should also resist temptation and ignore self-serving distractions. We don't have the time or energy to do otherwise. Matt -- to unsubscribe send a message to namedroppers-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 Mar 06 20:20:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGQsW-0005YQ-LG for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 20:20:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGQsU-0002F7-BT for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 20:20:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGQo6-0005PD-Tv for namedroppers-data@psg.com; Tue, 07 Mar 2006 01:16:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGQo6-0005Ot-9L for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 01:16:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A3A9611426 for ; Tue, 7 Mar 2006 01:16:09 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Mon, 06 Mar 2006 16:31:13 EST." <440CAA21.40103@connotech.com> References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> <16A00D5CE200CBF7943FF27D@[192.168.100.25]> <20060306183416.E90791142C@sa.vix.com> <440CAA21.40103@connotech.com> Date: Tue, 07 Mar 2006 01:16:09 +0000 Message-Id: <20060307011609.A3A9611426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f # > [...] [T]he TAKREM author can do a SCO or R.I.M. style attack against # > anyone who successfully monetizes the result (that is, claiming that ALL # > possible ways to solve this problem are covered under the TAKREM patent) # > [...]. # # This is completely ridiculous! Please record my disagreement. so noted, for whatever that's worth. perhaps you can help, out of the spirit of professionalism, to steer this WG toward solutions that do not infringe? i'm thinking that you could send out a patent number, page, and paragraph number any time you think a proposal here would ultimately lead the eventual holder of your IPR to come knocking? -- to unsubscribe send a message to namedroppers-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 Mar 06 20:32:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGR4D-0007FE-9D for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 20:32:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGR4B-0002YA-Tj for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 20:32:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGR2c-0006Eg-F5 for namedroppers-data@psg.com; Tue, 07 Mar 2006 01:31:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGR2b-0006Dd-KA for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 01:31:09 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00184A; 6 Mar 2006 20:30:51 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 6 Mar 2006 20:30:32 -0500 Received: from connotech.com (209.71.204.109) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001849; 6 Mar 2006 20:30:26 -0500 Message-ID: <440CEB19.5070508@connotech.com> Date: Mon, 06 Mar 2006 21:08:25 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org, "(DNSSEC deployment)" Subject: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Dear all: I realized that the DLV scheme has been approved as the informational RFC4431, and that the DLV RR and the TA RR has been approved by IANA according to http://www.iana.org/assignments/dns-parameters . The TA RR interworking specification is in http://www.watson.org/~weiler/INI1999-19.pdf . Does anybody know the details of procedural compliance with section 3.1 in RFC2929 and section 2 in RFC2434 in these two cases? In other words, how were RFC4431 and INI1999-19.pdf reviewed to ensure that they provided "sufficient detail so that interoperability between independent implementations is possible" ? We may observe that both the DLV RR and TA RR are intended to cope with the situation where the DNS root zone signature is missing for DNSSEC deployment. In addition, the recently approved ICANN-Verisign settlement (in http://www.icann.org/topics/vrsn-settlement/ revised-root-transition-agreement-redline-29jan06.pdf) previously hoped to "sign and publish the root and ARPA zones commencing in 2005 and completing by 2006," and is now only "commencing in 2006." Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 06 20:33:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGR4Y-0007Re-3m for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 20:33:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGR4X-0002YH-Qe for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 20:33:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGR2D-0006Co-0x for namedroppers-data@psg.com; Tue, 07 Mar 2006 01:30:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGR2B-0006CY-60 for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 01:30:43 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO001848; 6 Mar 2006 20:30:25 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 6 Mar 2006 20:29:59 -0500 Received: from connotech.com (209.71.204.109) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001847; 6 Mar 2006 20:29:52 -0500 Message-ID: <440CEAF7.9090602@connotech.com> Date: Mon, 06 Mar 2006 21:07:51 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lemon , Namedroppers Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306183416.E90791142C@sa.vix.com> <440CAA21.40103@connotech.com> <200603061453.49016.mellon@fugue.com> In-Reply-To: <200603061453.49016.mellon@fugue.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Ted Lemon wrote: > > I don't pay extra to use SSH. I don't pay extra to use SSL. I don't pay > extra to use PGP. I don't pay extra to use IPSEC. So why do you think > it's okay that I should pay extra to use DNSSEC? > Short answer: infrastrusture-based ubiquitous key management. I.e. with SSH, PGP, and IPSEC the key management burden rests on you. As an unauthenticated client in SSL, the remote server paid for the security certificate that you "rely" upon. > > And I think, I hope, that the > working group as a whole does not want the outcome of the long process of > inventing DNSSEC to be that only those who can pay extra for it get to enjoy > the benefits of all this work. > If I understand this, there would be an analogy between DNSSEC and smallpox vaccine which was so beneficial to the world that it deserved (government-funded) no-fee distribution. Indeed it worked: smallpox has been eradicated from the planet. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 06 21:10:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRez-0005vm-3c for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 21:10:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRey-0003aw-QF for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 21:10:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGRb8-0008Wz-NK for namedroppers-data@psg.com; Tue, 07 Mar 2006 02:06:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [32.97.182.144] (helo=e4.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGRb7-0008Wn-Sg for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 02:06:50 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2726mwj031833 for ; Mon, 6 Mar 2006 21:06:48 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2726llL225806 for ; Mon, 6 Mar 2006 21:06:47 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2726lJn009227 for ; Mon, 6 Mar 2006 21:06:47 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-81.mts.ibm.com [9.65.201.81]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2726ltm009209; Mon, 6 Mar 2006 21:06:47 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k2726jpS014525; Mon, 6 Mar 2006 21:06:45 -0500 Message-Id: <200603070206.k2726jpS014525@cichlid.raleigh.ibm.com> To: Thierry Moreau cc: namedroppers@ops.ietf.org, "(DNSSEC deployment)" Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus In-Reply-To: Message from Thierry Moreau of "Mon, 06 Mar 2006 21:08:25 EST." <440CEB19.5070508@connotech.com> Date: Mon, 06 Mar 2006 21:06:45 -0500 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > In other words, how were RFC4431 and INI1999-19.pdf reviewed to > ensure that they provided "sufficient detail so that > interoperability between independent implementations is possible" > ? Without answering your specific question (I do not know the actual answer), I'll point out that I (as one of the authors of RFC 2434 responsible for the quoted text) have long considered that text to be a bug, precisely because it doesn't specify _who_ should do the evaluation. Clearly, IANA doesn't have such expertise. Going forward, the proposed text in draft-narten-iana-considerations-rfc2434bis-04.txt (submitted earlier today) to address this point is: > Specification required - Values and their meaning must be > documented in an RFC or other permanent and readily > available public specification, in sufficient detail so > that interoperability between independent implementations > is possible. When used, Specification Required also implies > useage of a Designated Expert, who will review the public > specification and evaluate whether it is sufficiently clear > to allow interoperable implementations. Thomas -- to unsubscribe send a message to namedroppers-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 Mar 06 21:12:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRgH-0006oj-UY for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 21:12:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRgG-0003c5-Ks for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 21:12:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGReX-0008lK-Oe for namedroppers-data@psg.com; Tue, 07 Mar 2006 02:10:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGReX-0008kl-3Z for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 02:10:21 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00184C; 6 Mar 2006 21:10:03 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 6 Mar 2006 21:09:58 -0500 Received: from connotech.com (209.71.204.109) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00184B; 6 Mar 2006 21:09:52 -0500 Message-ID: <440CF451.7090501@connotech.com> Date: Mon, 06 Mar 2006 21:47:45 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> <16A00D5CE200CBF7943FF27D@[192.168.100.25]> <20060306183416.E90791142C@sa.vix.com> <440CAA21.40103@connotech.com> <20060307011609.A3A9611426@sa.vix.com> In-Reply-To: <20060307011609.A3A9611426@sa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Paul Vixie wrote: > # > [...] [T]he TAKREM author can do a SCO or R.I.M. style attack against > # > anyone who successfully monetizes the result (that is, claiming that ALL > # > possible ways to solve this problem are covered under the TAKREM patent) > # > [...]. > # > # This is completely ridiculous! Please record my disagreement. > > so noted, for whatever that's worth. > > perhaps you can help, out of the spirit of professionalism, to steer this > WG toward solutions that do not infringe? So I'm a SCO-raider on one post, then a messianic professional WG steersman on the next! > i'm thinking that you could send > out a patent number, page, and paragraph number any time you think a proposal > here would ultimately lead the eventual holder of your IPR to come knocking? More seriously, in good faith, I abide by the disclosure rules in RFC3979. The documents for which an IPR disclosure has been made in relation to TAKREM are 1) draft-moreau-dnsext-takrem-dns 2) draft-moreau-pkix-takrem That's it. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 06 21:13:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRhZ-00075J-3y for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 21:13:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRhX-0003ed-Nh for dnsext-archive@lists.ietf.org; Mon, 06 Mar 2006 21:13:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGRfs-0008sq-GN for namedroppers-data@psg.com; Tue, 07 Mar 2006 02:11:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGRfj-0008ri-GZ for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 02:11:35 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 979F3E60C8 for ; Tue, 7 Mar 2006 02:11:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k272BSeb091487; Tue, 7 Mar 2006 13:11:28 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200603070211.k272BSeb091487@drugs.dv.isc.org> To: Thierry Moreau Cc: namedroppers@ops.ietf.org, "(DNSSEC deployment)" From: Mark Andrews Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus In-reply-to: Your message of "Mon, 06 Mar 2006 21:08:25 CDT." <440CEB19.5070508@connotech.com> Date: Tue, 07 Mar 2006 13:11:28 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 > Dear all: > > I realized that the DLV scheme has been approved as the > informational RFC4431, and that the DLV RR and the TA RR has been > approved by IANA according to > http://www.iana.org/assignments/dns-parameters . The TA RR > interworking specification is in > http://www.watson.org/~weiler/INI1999-19.pdf . > > Does anybody know the details of procedural compliance with > section 3.1 in RFC2929 and section 2 in RFC2434 in these two > cases? > > In other words, how were RFC4431 and INI1999-19.pdf reviewed to > ensure that they provided "sufficient detail so that > interoperability between independent implementations is possible" > ? RFC4431 does nothing more that provide a way to publish a collection of DS record equivalents in the DNS. We could have done the same thing via HTTPS. DNS is just more practical as the software that uses the records generally has the ability to request missing records via the DNS. It's up to the validator local policy to decide to use them or not. INI1999-19.pdf discusses a number of different mechanisms to do this. > We may observe that both the DLV RR and TA RR are intended to > cope with the situation where the DNS root zone signature is > missing for DNSSEC deployment. > > In addition, the recently approved ICANN-Verisign settlement (in > http://www.icann.org/topics/vrsn-settlement/ > revised-root-transition-agreement-redline-29jan06.pdf) previously > hoped to "sign and publish the root and ARPA zones commencing in > 2005 and completing by 2006," and is now only "commencing in > 2006." > > Regards, > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau@connotech.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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 00:17:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGUZZ-00038a-8z for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 00:17:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGUP5-0000pU-RP for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 00:06:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGULA-000KNz-0L for namedroppers-data@psg.com; Tue, 07 Mar 2006 05:02:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGUL9-000KNl-Av for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 05:02:31 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BFC8E11429 for ; Tue, 7 Mar 2006 05:02:30 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Mon, 06 Mar 2006 21:47:45 EST." <440CF451.7090501@connotech.com> References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306023051.3A8AD11426@sa.vix.com> <16A00D5CE200CBF7943FF27D@[192.168.100.25]> <20060306183416.E90791142C@sa.vix.com> <440CAA21.40103@connotech.com> <20060307011609.A3A9611426@sa.vix.com> <440CF451.7090501@connotech.com> Date: Tue, 07 Mar 2006 05:02:30 +0000 Message-Id: <20060307050230.BFC8E11429@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 > > > This is completely ridiculous! Please record my disagreement. > > so noted, for whatever that's worth. > > > > perhaps you can help, out of the spirit of professionalism, to steer this > > WG toward solutions that do not infringe? # So I'm a SCO-raider on one post, then a messianic professional WG steersman # on the next! i wasn't trying to be funny. if, as i hope and expect, it turns out that encumbered technologies are considered self-disqualified for this, then you have lost your bid to standardize a moneyfunnel from the world to your door. in that case, you could choose to... 1. keep fighting about it (if anyone will further engage you, it won't be me). 2. grant a worldwide perpetual royalty free license for all DNS uses of TAKREM whether commercial or otherwise, and try to monetize it in some other way like writing a book, consulting, or going on Oprah. 3. hope that no viable alternative is found and the WG decides to look at TAKREM in spite of its encumberances. 4. something bizarre. because of who i am and what i've done and where i've been, i like #4 best, and so i'm suggesting, in all seriousness, that you help the WG -- in the best spirit of professionalism -- to reach the goal of avoiding your encumberances. -- to unsubscribe send a message to namedroppers-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 Mar 07 00:25:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGUho-0001ZP-B2 for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 00:25:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGUhm-0001Ok-O8 for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 00:25:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGUfx-000M1G-D2 for namedroppers-data@psg.com; Tue, 07 Mar 2006 05:24:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [207.171.160.37] (helo=smtp-out-2001.amazon.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGUfw-000M12-1q for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 05:24:00 +0000 X-Amazon-Corporate-Relay: smtp-out-2001.iad2.amazon.com X-AMAZON-TRACK: namedroppers@ops.ietf.org Received: from smtp-in-2004.iad2.amazon.com by smtp-out-2001.amazon.com with ESMTP (peer crosscheck: smtp-in-2004.iad2.amazon.com) Received: from ex-gate-01.ant.amazon.com (ex-gate-01.ant.amazon.com [172.20.21.33]) by smtp-in-2004.iad2.amazon.com (8.12.10/8.12.10) with ESMTP id k275NoGj018802; Tue, 7 Mar 2006 05:23:58 GMT Received: from mail pickup service by ex-gate-01.ant.amazon.com with Microsoft SMTPSVC; Mon, 6 Mar 2006 21:23:54 -0800 Received: from smtp-in-2001.iad2.amazon.com ([10.207.1.45]) by ex-gate-01.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 17:32:50 -0800 Received: from smtp-border-fw-2101.amazon.com (smtp-border-fw-2101.iad2.amazon.com [10.5.48.15]) by smtp-in-2001.iad2.amazon.com (8.12.10/8.12.10) with ESMTP id k271Wjhf007085 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 7 Mar 2006 01:32:46 GMT Received: from psg.com ([147.28.0.62]) by smtp-border-fw-2101.amazon.com with ESMTP/TLS/AES256-SHA; 07 Mar 2006 01:32:46 +0000 X-Amazon-External-Envelope-Sender: owner-namedroppers@ops.ietf.org X-Amazon-External-Envelope-Recipient: tomk@amazon.com X-Amazon-External-Source: yes X-Amazon-Approved-Domain: no X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,169,1139184000"; d="scan'208"; a="178789109:sNHT24397420" Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGR2c-0006Eg-F5 for namedroppers-data@psg.com; Tue, 07 Mar 2006 01:31:10 +0000 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGR2b-0006Dd-KA for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 01:31:09 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00184A; 6 Mar 2006 20:30:51 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 6 Mar 2006 20:30:32 -0500 Received: from connotech.com (209.71.204.109) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001849; 6 Mar 2006 20:30:26 -0500 Message-ID: <440CEB19.5070508@connotech.com> Date: Mon, 06 Mar 2006 21:08:25 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org, "(DNSSEC deployment)" Subject: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2006 01:32:50.0905 (UTC) FILETIME=[0C47A490:01C64187] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Dear all: I realized that the DLV scheme has been approved as the informational RFC4431, and that the DLV RR and the TA RR has been approved by IANA according to http://www.iana.org/assignments/dns-parameters . The TA RR interworking specification is in http://www.watson.org/~weiler/INI1999-19.pdf . Does anybody know the details of procedural compliance with section 3.1 in RFC2929 and section 2 in RFC2434 in these two cases? In other words, how were RFC4431 and INI1999-19.pdf reviewed to ensure that they provided "sufficient detail so that interoperability between independent implementations is possible" ? We may observe that both the DLV RR and TA RR are intended to cope with the situation where the DNS root zone signature is missing for DNSSEC deployment. In addition, the recently approved ICANN-Verisign settlement (in http://www.icann.org/topics/vrsn-settlement/ revised-root-transition-agreement-redline-29jan06.pdf) previously hoped to "sign and publish the root and ARPA zones commencing in 2005 and completing by 2006," and is now only "commencing in 2006." Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Tue Mar 07 00:27:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGUjA-0002VQ-Rd for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 00:27:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGUjA-0001Px-DF for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 00:27:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGUhm-000MCX-QP for namedroppers-data@psg.com; Tue, 07 Mar 2006 05:25:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [207.171.164.41] (helo=smtp-out-1001.amazon.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGUhm-000MC9-2b for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 05:25:54 +0000 X-Amazon-Corporate-Relay: smtp-out-1001.vdc.amazon.com X-AMAZON-TRACK: namedroppers@ops.ietf.org Received: from smtp-in-0102.sea3.amazon.com by smtp-out-1001.amazon.com with ESMTP (peer crosscheck: smtp-in-0102.sea3.amazon.com) Received: from ex-gate-01.ant.amazon.com (ex-gate-01.ant.amazon.com [172.20.21.33]) by smtp-in-0102.sea3.amazon.com (8.12.10/8.12.10) with ESMTP id k275Ph2m015678; Tue, 7 Mar 2006 05:25:44 GMT Received: from mail pickup service by ex-gate-01.ant.amazon.com with Microsoft SMTPSVC; Mon, 6 Mar 2006 21:25:42 -0800 Received: from smtp-in-2004.iad2.amazon.com ([10.205.17.45]) by ex-gate-01.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 17:33:10 -0800 Received: from smtp-border-fw-2101.amazon.com (smtp-border-fw-2101.iad2.amazon.com [10.5.48.15]) by smtp-in-2004.iad2.amazon.com (8.12.10/8.12.10) with ESMTP id k271X8tf008618 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 7 Mar 2006 01:33:08 GMT Received: from psg.com ([147.28.0.62]) by smtp-border-fw-2101.amazon.com with ESMTP/TLS/AES256-SHA; 07 Mar 2006 01:33:08 +0000 X-Amazon-External-Envelope-Sender: owner-namedroppers@ops.ietf.org X-Amazon-External-Envelope-Recipient: tomk@amazon.com X-Amazon-External-Source: yes X-Amazon-Approved-Domain: no X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,169,1139184000"; d="scan'208"; a="178789256:sNHT25485084" Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGR2D-0006Co-0x for namedroppers-data@psg.com; Tue, 07 Mar 2006 01:30:45 +0000 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGR2B-0006CY-60 for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 01:30:43 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO001848; 6 Mar 2006 20:30:25 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 6 Mar 2006 20:29:59 -0500 Received: from connotech.com (209.71.204.109) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001847; 6 Mar 2006 20:29:52 -0500 Message-ID: <440CEAF7.9090602@connotech.com> Date: Mon, 06 Mar 2006 21:07:51 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lemon , Namedroppers Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306183416.E90791142C@sa.vix.com> <440CAA21.40103@connotech.com> <200603061453.49016.mellon@fugue.com> In-Reply-To: <200603061453.49016.mellon@fugue.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2006 01:33:11.0406 (UTC) FILETIME=[187FD8E0:01C64187] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Ted Lemon wrote: > > I don't pay extra to use SSH. I don't pay extra to use SSL. I don't pay > extra to use PGP. I don't pay extra to use IPSEC. So why do you think > it's okay that I should pay extra to use DNSSEC? > Short answer: infrastrusture-based ubiquitous key management. I.e. with SSH, PGP, and IPSEC the key management burden rests on you. As an unauthenticated client in SSL, the remote server paid for the security certificate that you "rely" upon. > > And I think, I hope, that the > working group as a whole does not want the outcome of the long process of > inventing DNSSEC to be that only those who can pay extra for it get to enjoy > the benefits of all this work. > If I understand this, there would be an analogy between DNSSEC and smallpox vaccine which was so beneficial to the world that it deserved (government-funded) no-fee distribution. Indeed it worked: smallpox has been eradicated from the planet. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Tue Mar 07 01:09:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGVOI-0001Lp-0W for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 01:09:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGVOE-0002SQ-IZ for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 01:09:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGVLn-000P2U-Ks for namedroppers-data@psg.com; Tue, 07 Mar 2006 06:07:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [207.171.180.182] (helo=smtp-out-0101.amazon.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGVLm-000P2H-C0 for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 06:07:14 +0000 X-Amazon-Corporate-Relay: smtp-out-0101.sea3.amazon.com X-AMAZON-TRACK: namedroppers@ops.ietf.org Received: from smtp-in-2001.iad2.amazon.com by smtp-out-0101.amazon.com with ESMTP (peer crosscheck: smtp-in-2001.iad2.amazon.com) Received: from ex-gate-01.ant.amazon.com (ex-gate-01.ant.amazon.com [172.20.21.33]) by smtp-in-2001.iad2.amazon.com (8.12.10/8.12.10) with ESMTP id k275xnY1025797; Tue, 7 Mar 2006 06:07:09 GMT Received: from mail pickup service by ex-gate-01.ant.amazon.com with Microsoft SMTPSVC; Mon, 6 Mar 2006 22:05:55 -0800 Received: from smtp-in-1002.vdc.amazon.com ([10.130.7.45]) by ex-gate-01.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 18:10:53 -0800 Received: from smtp-border-fw-2101.amazon.com (smtp-border-fw-2101.iad2.amazon.com [10.5.48.15]) by smtp-in-1002.vdc.amazon.com (8.12.10/8.12.10) with ESMTP id k272AZI7013816 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 7 Mar 2006 02:10:47 GMT Received: from psg.com ([147.28.0.62]) by smtp-border-fw-2101.amazon.com with ESMTP/TLS/AES256-SHA; 07 Mar 2006 02:10:47 +0000 X-Amazon-External-Envelope-Sender: owner-namedroppers@ops.ietf.org X-Amazon-External-Envelope-Recipient: tomk@amazon.com X-Amazon-External-Source: yes X-Amazon-Approved-Domain: no X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,169,1139184000"; d="scan'208"; a="178803101:sNHT23639900" Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGRb8-0008Wz-NK for namedroppers-data@psg.com; Tue, 07 Mar 2006 02:06:50 +0000 Received: from [32.97.182.144] (helo=e4.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGRb7-0008Wn-Sg for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 02:06:50 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2726mwj031833 for ; Mon, 6 Mar 2006 21:06:48 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2726llL225806 for ; Mon, 6 Mar 2006 21:06:47 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2726lJn009227 for ; Mon, 6 Mar 2006 21:06:47 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-81.mts.ibm.com [9.65.201.81]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2726ltm009209; Mon, 6 Mar 2006 21:06:47 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k2726jpS014525; Mon, 6 Mar 2006 21:06:45 -0500 Message-Id: <200603070206.k2726jpS014525@cichlid.raleigh.ibm.com> To: Thierry Moreau cc: namedroppers@ops.ietf.org, "(DNSSEC deployment)" Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus In-Reply-To: Message from Thierry Moreau of "Mon, 06 Mar 2006 21:08:25 EST." <440CEB19.5070508@connotech.com> Date: Mon, 06 Mar 2006 21:06:45 -0500 From: Thomas Narten X-OriginalArrivalTime: 07 Mar 2006 02:10:53.0432 (UTC) FILETIME=[5CC59F80:01C6418C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 > In other words, how were RFC4431 and INI1999-19.pdf reviewed to > ensure that they provided "sufficient detail so that > interoperability between independent implementations is possible" > ? Without answering your specific question (I do not know the actual answer), I'll point out that I (as one of the authors of RFC 2434 responsible for the quoted text) have long considered that text to be a bug, precisely because it doesn't specify _who_ should do the evaluation. Clearly, IANA doesn't have such expertise. Going forward, the proposed text in draft-narten-iana-considerations-rfc2434bis-04.txt (submitted earlier today) to address this point is: > Specification required - Values and their meaning must be > documented in an RFC or other permanent and readily > available public specification, in sufficient detail so > that interoperability between independent implementations > is possible. When used, Specification Required also implies > useage of a Designated Expert, who will review the public > specification and evaluate whether it is sufficiently clear > to allow interoperable implementations. Thomas -- to 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 Mar 07 01:37:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGVp2-0006ky-Bw for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 01:37:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGVoy-0003AG-Qf for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 01:37:28 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGVn1-0000tQ-SV for namedroppers-data@psg.com; Tue, 07 Mar 2006 06:35:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.1.0 Received: from [207.171.180.182] (helo=smtp-out-0101.amazon.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGVn1-0000tE-0q for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 06:35:23 +0000 X-Amazon-Corporate-Relay: smtp-out-0101.sea3.amazon.com X-AMAZON-TRACK: namedroppers@ops.ietf.org Received: from smtp-in-2001.iad2.amazon.com by smtp-out-0101.amazon.com with ESMTP (peer crosscheck: smtp-in-2001.iad2.amazon.com) Received: from ex-gate-01.ant.amazon.com (ex-gate-01.ant.amazon.com [172.20.21.33]) by smtp-in-2001.iad2.amazon.com (8.12.10/8.12.10) with ESMTP id k276S816013138; Tue, 7 Mar 2006 06:35:19 GMT Received: from mail pickup service by ex-gate-01.ant.amazon.com with Microsoft SMTPSVC; Mon, 6 Mar 2006 22:23:17 -0800 Received: from smtp-in-0104.sea3.amazon.com ([172.20.19.37]) by ex-gate-01.ant.amazon.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 18:13:29 -0800 Received: from smtp-border-fw-0101.amazon.com (smtp-border-fw-0101.amazon.com [10.16.42.69]) by smtp-in-0104.sea3.amazon.com (8.12.11/8.12.10) with ESMTP id k272BurS025464 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 6 Mar 2006 18:13:26 -0800 Received: from psg.com ([147.28.0.62]) by smtp-border-fw-0101.amazon.com with ESMTP/TLS/AES256-SHA; 07 Mar 2006 02:13:26 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,169,1139184000"; d="scan'208"; a="217529940:sNHT35464644" Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGRfs-0008sq-GN for namedroppers-data@psg.com; Tue, 07 Mar 2006 02:11:44 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGRfj-0008ri-GZ for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 02:11:35 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 979F3E60C8 for ; Tue, 7 Mar 2006 02:11:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k272BSeb091487; Tue, 7 Mar 2006 13:11:28 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200603070211.k272BSeb091487@drugs.dv.isc.org> To: Thierry Moreau Cc: namedroppers@ops.ietf.org, "(DNSSEC deployment)" From: Mark Andrews Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus In-reply-to: Your message of "Mon, 06 Mar 2006 21:08:25 CDT." <440CEB19.5070508@connotech.com> Date: Tue, 07 Mar 2006 13:11:28 +1100 X-OriginalArrivalTime: 07 Mar 2006 02:13:31.0312 (UTC) FILETIME=[BAE03300:01C6418C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 > Dear all: > > I realized that the DLV scheme has been approved as the > informational RFC4431, and that the DLV RR and the TA RR has been > approved by IANA according to > http://www.iana.org/assignments/dns-parameters . The TA RR > interworking specification is in > http://www.watson.org/~weiler/INI1999-19.pdf . > > Does anybody know the details of procedural compliance with > section 3.1 in RFC2929 and section 2 in RFC2434 in these two > cases? > > In other words, how were RFC4431 and INI1999-19.pdf reviewed to > ensure that they provided "sufficient detail so that > interoperability between independent implementations is possible" > ? RFC4431 does nothing more that provide a way to publish a collection of DS record equivalents in the DNS. We could have done the same thing via HTTPS. DNS is just more practical as the software that uses the records generally has the ability to request missing records via the DNS. It's up to the validator local policy to decide to use them or not. INI1999-19.pdf discusses a number of different mechanisms to do this. > We may observe that both the DLV RR and TA RR are intended to > cope with the situation where the DNS root zone signature is > missing for DNSSEC deployment. > > In addition, the recently approved ICANN-Verisign settlement (in > http://www.icann.org/topics/vrsn-settlement/ > revised-root-transition-agreement-redline-29jan06.pdf) previously > hoped to "sign and publish the root and ARPA zones commencing in > 2005 and completing by 2006," and is now only "commencing in > 2006." > > Regards, > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau@connotech.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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-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 Mar 07 01:57:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGW8c-0004tl-Dm for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 01:57:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGW2f-0003X6-Pg for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 01:51:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGW0u-0001oA-2W for namedroppers-data@psg.com; Tue, 07 Mar 2006 06:49:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGW0t-0001ny-Bc for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 06:49:43 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 4C77611D9DC; Mon, 6 Mar 2006 22:49:38 -0800 (PST) From: Wes Hardaker To: Thierry Moreau Cc: Ted Lemon , Namedroppers Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Organization: Sparta References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306183416.E90791142C@sa.vix.com> <440CAA21.40103@connotech.com> <200603061453.49016.mellon@fugue.com> <440CEAF7.9090602@connotech.com> Date: Mon, 06 Mar 2006 22:49:37 -0800 In-Reply-To: <440CEAF7.9090602@connotech.com> (Thierry Moreau's message of "Mon, 06 Mar 2006 21:07:51 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >>>>> On Mon, 06 Mar 2006 21:07:51 -0500, Thierry Moreau said: Thierry> If I understand this, there would be an analogy between Thierry> DNSSEC and smallpox vaccine which was so beneficial to the Thierry> world that it deserved (government-funded) no-fee Thierry> distribution. Indeed it worked: smallpox has been eradicated Thierry> from the planet. If you want to achieve maximum DNSSEC deployment, yes you must be willing to offer a solution to not just the rich but to everyone. Doing anything else would not be providing a full solution. If we believe that trust management is a problem and if we want to achieve the widest deployment of a trust management solution then we need to use an unencumbered solution. The only other alternative is to offer a solution to a smaller number of people. When it comes to deploying security protocols, we should always strive to create solutions that achieve the best deployment spread possible for all potential users. We should never strive to create solutions that are only usable by the rich, the intelligent, the powerful or the elite. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-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 Mar 07 03:55:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXyg-0000Qj-0n for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 03:55:34 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGXyf-0001ME-Vb for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 03:55:34 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGXuc-0004nQ-5Z for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 03:51:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGXrS-0008qD-3k for namedroppers-data@psg.com; Tue, 07 Mar 2006 08:48:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGXrQ-0008q0-Ft for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 08:48:04 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k278m2Ne022525 for ; Tue, 7 Mar 2006 09:48:02 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <440B18B2.2040500@connotech.com> References: <440B18B2.2040500@connotech.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-37-205329752" Message-Id: Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Tue, 7 Mar 2006 09:48:06 +0100 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-37-205329752 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Since this is one of the issues that can drag on forever if we are not careful I propose some process that sets a timeline to this discussion. On the basis of previous discussion on the list I think we can go for a consensus call on the text below: 5.2 No Intellectual Property Encumbrance The solution SHOULD not have any intellectual property encumbrance on either the technologies used by the solution nor implementations of the solution. The solution MUST be covered by one of options (a) or (c) of section 6.5 of [RFC3979]. If the technology is covered by option (a), the license SHOULD be compatible with the BSD open source license I'd like to ask participants to state on-list a: That they consent with section 5.2 as above. b: They would like to see section 5.2 as above modified. Then send argumentation and "patch" c: They would like to see any mention of IPR dropped from the requirements. Please respond by mail, try not to go into battle over arguments, state your own arguments once and trust others to be able to read. If you need clarification of arguments please ask. We'll assess the outcome of the discussion slightly before or during the face2face meeting in Dallas. Please remain courteous and civil. Please respect the motivations for peoples opinions. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-37-205329752 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEDUjHtN/ca3YJIocRAjy1AKC5QD4gU5mvrWnNHob/TwmMkPOcXACgg4gY a1km1NXfrt+ECQmyRVxDb/k= =Ve8M -----END PGP SIGNATURE----- --Apple-Mail-37-205329752-- -- to unsubscribe send a message to namedroppers-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 Mar 07 04:27:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYTn-0004C1-Hh for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 04:27:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGYTl-0002sA-HJ for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 04:27:43 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGYR2-000BEg-4e for namedroppers-data@psg.com; Tue, 07 Mar 2006 09:24:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [203.217.30.81] (helo=mail.mindrot.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGYR0-000BET-PR for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 09:24:51 +0000 Received: by mail.mindrot.org (Postfix, from userid 1000) id 90D6917E609; Tue, 7 Mar 2006 20:24:47 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 8A50D17E604; Tue, 7 Mar 2006 20:24:47 +1100 (EST) Date: Tue, 7 Mar 2006 20:24:47 +1100 (EST) From: Damien Miller To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Message-ID: References: <440B18B2.2040500@connotech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, 7 Mar 2006, Olaf M. Kolkman wrote: > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license (delurking) I would suggest that this is necessary, but not sufficient; the license should also allow unencumbered commercial exploitation of the technology otherwise the main benefit of the BSD licence (conducive to reference implementations that may be freely incorporated into free and proprietary products) are lost. -d -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 04:34:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYaL-0001qJ-OD for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 04:34:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGYaJ-000318-Bg for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 04:34:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGYYf-000BjP-0A for namedroppers-data@psg.com; Tue, 07 Mar 2006 09:32:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGYYe-000Bj9-2C for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 09:32:44 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k279WYvf029117; Tue, 7 Mar 2006 04:32:35 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <440B18B2.2040500@connotech.com> Date: Tue, 7 Mar 2006 04:32:32 -0500 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Cc: Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 At 9:48 +0100 3/7/06, Olaf M. Kolkman wrote: >c: They would like to see any mention of IPR dropped from the requirements. I think I'd favor this. Only because this is a DNS document and IPR is something I don't understand and I find quite boring. Still, I would not accept an encumbered technology in a IETF standard. Perhaps there is an IPR WG document that explains this and we should reference that. I have no qualms about paying for encumbered technology. (I have yet to fly in an airplane that was built without encumbered technology.) But it has no place in an IETF standard because the goal is interoperability. As far as the TAKRAM proposal, I ignore it on principle that it is encumbered and will therefore be unlikely a solid base for an interoperable standard. It doesn't matter to me whether I will have to pay for something, it bothers me that "the other side" may not be able to pay for the improvement. It's like this, an example from DNSSEC. If I design a cryptographic algorithm that is far superior to RSA/SHA1, code it up, and sign my zones only with my algorithm, resolvers only equipped with RSA/SHA1 will see my zone as unsigned. Instead of enhancing my security with super cryptography, I cripple my security by not using the common algorithm. For interoperability, commonality is more important that optimization. Any possible benefit of TAKRAM is erased by the threat of it not being available to any *any* implementation of DNS. The argument against encumbered technology is not about money, return on contribution (politer word than investment), market control, etc. It's about interoperability. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 07 04:56:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGYvU-0003WD-5g for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 04:56:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGYvS-0003xx-TB for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 04:56:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGYtc-000D8r-BC for namedroppers-data@psg.com; Tue, 07 Mar 2006 09:54:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGYtb-000D8d-8q for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 09:54:23 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k279sFVL023436; Tue, 7 Mar 2006 10:54:15 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <440B18B2.2040500@connotech.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-41-209303033" Message-Id: <3D7150A8-53E1-4D3F-9629-D7E628F6FBBF@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Tue, 7 Mar 2006 10:54:20 +0100 To: Damien Miller X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-41-209303033 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > (delurking) > Welcome :-) > I would suggest that this is necessary, but not sufficient; the > license should also allow unencumbered commercial exploitation of the > technology otherwise the main benefit of the BSD licence (conducive to > reference implementations that may be freely incorporated into free > and > proprietary products) are lost. I thought that was covered by "should be compatible with BSD license" (but that is just me trying to find wording on which we can consent) If you know better wording do send a patch to the text please; If current text is not perfect but you can consent than please indicate that. Otherwise we are keep running in circles by making statements and not getting to a text we can all agree on. I will try to back off now :-) --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-41-209303033 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEDVhMtN/ca3YJIocRAmg8AKD6CXAVdkqTJvS2oUbTo2APXDSTcgCgwCrB k9F/sVg700eaB1WUkmZY+to= =vScM -----END PGP SIGNATURE----- --Apple-Mail-41-209303033-- -- to unsubscribe send a message to namedroppers-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 Mar 07 05:05:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZ4O-0003a6-Tt for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 05:05:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZ4N-0004gC-LG for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 05:05:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGZ2u-000Dpw-QR for namedroppers-data@psg.com; Tue, 07 Mar 2006 10:04:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [203.217.30.81] (helo=mail.mindrot.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGZ2u-000Dpa-3n for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 10:04:00 +0000 Received: by mail.mindrot.org (Postfix, from userid 1000) id 255C617E609; Tue, 7 Mar 2006 21:03:56 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id B053617E604; Tue, 7 Mar 2006 21:03:56 +1100 (EST) Date: Tue, 7 Mar 2006 21:03:56 +1100 (EST) From: Damien Miller To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: <3D7150A8-53E1-4D3F-9629-D7E628F6FBBF@NLnetLabs.nl> Message-ID: References: <440B18B2.2040500@connotech.com> <3D7150A8-53E1-4D3F-9629-D7E628F6FBBF@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Tue, 7 Mar 2006, Olaf M. Kolkman wrote: > I thought that was covered by "should be compatible with BSD license" (but > that is just me trying to find wording on which we can consent) I have seen licenses (on software, not patents though) where payment provisions are activated when the source is not made available, so while these are technically compatible with the BSD license, they somewhat scuttle its spirit of non-discrimination. This is what I was trying to avoid, but reading the text of RFC3979 section 6.5 option (a), it isn't an issue anyway. So, please ignore my rant :) -d -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 05:48:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZjn-0005Bl-5E for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 05:48:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZjl-000626-O6 for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 05:48:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGZhd-000GOM-2A for namedroppers-data@psg.com; Tue, 07 Mar 2006 10:46:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGZhb-000GOB-Rq for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 10:46:04 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k27AjxeE066678; Tue, 7 Mar 2006 11:45:59 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <440CEB19.5070508@connotech.com> References: <440CEB19.5070508@connotech.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-45-212406721" Message-Id: Cc: namedroppers@ops.ietf.org, "(DNSSEC deployment)" Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus Date: Tue, 7 Mar 2006 11:46:03 +0100 To: Thierry Moreau X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-45-212406721 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 7, 2006, at 3:08 AM, Thierry Moreau wrote: > Dear all: > > I realized that the DLV scheme has been approved as the > informational RFC4431, and that the DLV RR and the TA RR has been > approved by IANA according to > http://www.iana.org/assignments/dns-parameters . The TA RR > interworking specification is in > http://www.watson.org/~weiler/INI1999-19.pdf . This is not correct. The DLV _scheme_ has not been approved. It is the DLV _resource record_ has been specified in RFC4431. 4431 is not an RFC that defines the DLV _scheme_ nor does it standardize its use. Actually 4431 does not contain any language on how the RR ought to be used, although it hints to use by validators during the validation process. The RR types have been assigned based on "specification required" (RFC 2929). The specification only defines the content of the RR it specifies the on-the-wire format, has a well defined zone-file format, does not require compression, and does not rely on special processing in any component in the DNS. That means that it is just a blob of data carried through the DNS as an RR. IMHO this is sufficient any RR type to get an RR code. (We trying to deal with the fact that many people put blobs of data in TXT RRs because it seems so difficult to get a type code assigned.) If you were to argue that the DLV is a special case because it could be used for making policy decisions at the validator end, I would be able to follow that argument. But the point is that that behavior has not been described in the RFC and that look aside validation has not entered the IETF. In other words: That IANA has assigned type codes does not mean that the Look aside validation mechanism has been standarized by the IETF. By the way, there is an individual submission that describes the mechanism draft-weiler-dnssec-dlv-00.txt. The author of that draft has (not yet?) chosen not to bring that document to this working group. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-45-212406721 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEDWRstN/ca3YJIocRAvDkAKCPu3m4ygYJWj0eEkG0mgpol/waEwCfZd/i aL38K4wQpe2tBJBf2x7Imy4= =l6tn -----END PGP SIGNATURE----- --Apple-Mail-45-212406721-- -- to unsubscribe send a message to namedroppers-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 Mar 07 05:58:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZta-0004jb-0L for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 05:58:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZtY-0006Lv-Nr for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 05:58:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGZr5-000H6p-F7 for namedroppers-data@psg.com; Tue, 07 Mar 2006 10:55:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGZr2-000H6Y-OT for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 10:55:48 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k27AtZS4017614; Tue, 7 Mar 2006 02:55:35 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k27AtZKV017611; Tue, 7 Mar 2006 02:55:35 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 7 Mar 2006 02:55:35 -0800 (PST) From: "william(at)elan.net" To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Message-ID: References: <440B18B2.2040500@connotech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Tue, 7 Mar 2006, Olaf M. Kolkman wrote: > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license Would having license compatible with BSD open source license also automatically cover those that want to release software under GPL? The reason I ask is that we had a problem on another WG (MARID) where offered license was compatible with most of BSD-style licenses, but was not compatible with GPL. That did not go very well with large portion of those interested and ultimately WG failed in big part because of this issue. So my preference would be to see your line modified to read "(a), the license SHOULD be compatible with the BSD and GPL open source licenses" -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 06:12:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGa72-0006CQ-9J for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:12:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGa70-0006jK-Vb for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:12:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGa5m-000IGE-QJ for namedroppers-data@psg.com; Tue, 07 Mar 2006 11:11:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGa5l-000IG2-VZ for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 11:11:02 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k27BAnIV027741; Tue, 7 Mar 2006 11:10:49 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k27BAnbP027740; Tue, 7 Mar 2006 11:10:49 GMT Date: Tue, 7 Mar 2006 11:10:49 +0000 From: bmanning@vacation.karoshi.com To: "Olaf M. Kolkman" Cc: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <20060307111049.GB27709@vacation.karoshi.com.> References: <440B18B2.2040500@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 ed is wise in the ways of protoocol development. C: is the most prudent course. otherwise, if there is a need to refer to IPR at all, i'd take A: - since that is the path of least resistance. --bill On Tue, Mar 07, 2006 at 09:48:06AM +0100, Olaf M. Kolkman wrote: > > Since this is one of the issues that can drag on forever if we are > not careful I propose some process that sets a timeline to this > discussion. > > On the basis of previous discussion on the list I think we can go for > a consensus call on the text below: > > 5.2 No Intellectual Property Encumbrance > > The solution SHOULD not have any intellectual > property encumbrance on either the technologies > used by the solution nor implementations > of the solution. > > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license > > > > I'd like to ask participants to state on-list > > > a: That they consent with section 5.2 as above. > > b: They would like to see section 5.2 as above modified. Then send > argumentation and "patch" > > c: They would like to see any mention of IPR dropped from the > requirements. > > > Please respond by mail, try not to go into battle over arguments, > state your own arguments once and trust others to be able to read. If > you need clarification of arguments please ask. > > We'll assess the outcome of the discussion slightly before or during > the face2face meeting in Dallas. > > Please remain courteous and civil. Please respect the motivations for > peoples opinions. > > --Olaf > > > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > -- to unsubscribe send a message to namedroppers-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 Mar 07 06:13:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGa7w-0006RN-Db for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:13:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGa7v-0006km-4U for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:13:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGa5S-000IF1-Bi for namedroppers-data@psg.com; Tue, 07 Mar 2006 11:10:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGa5R-000IEo-M3 for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 11:10:41 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k27BAanu017919; Tue, 7 Mar 2006 03:10:36 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k27BAata017916; Tue, 7 Mar 2006 03:10:36 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 7 Mar 2006 03:10:36 -0800 (PST) From: "william(at)elan.net" To: "Olaf M. Kolkman" cc: Thierry Moreau , namedroppers@ops.ietf.org, "(DNSSEC deployment)" Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus In-Reply-To: Message-ID: References: <440CEB19.5070508@connotech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Tue, 7 Mar 2006, Olaf M. Kolkman wrote: > This is not correct. The DLV _scheme_ has not been approved. It is the DLV > _resource record_ has been specified in RFC4431. 4431 is not an RFC that > defines the DLV _scheme_ nor does it standardize its use. Actually 4431 > does not contain any language on how the RR ought to be used, although > it hints to use by validators during the validation process. Is there reason TA and DLV got such high numbers for their RR? And in general how is it decided which numbers are assigned based on the drafts? [I see some new drafts causing RRs in 0-50 range, some below 100 and TA & DLV got 32768 & 32769] -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 06:15:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGa9u-0007Tj-9z for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:15:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGa9t-0006rf-Tt for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:15:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGa7w-000IUT-Qw for namedroppers-data@psg.com; Tue, 07 Mar 2006 11:13:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGa7v-000IUB-NR for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 11:13:16 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k27BD0Jb029603; Tue, 7 Mar 2006 06:13:06 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <440B18B2.2040500@connotech.com> Date: Tue, 7 Mar 2006 06:13:03 -0500 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: ISSUE 1: IPR , response #2 Cc: Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 I'd prefer... 5.2 Conformance with IETF standards The solution MUST be covered by one of options (a) or (c) of section 6.5 of [RFC3979]. No specific mention of IPR (ick), but compatibility with IETF standards for, umm, standards. I.e., it's not that I want BSD licences, I don't want any (other) licenses. If you try to argue with me over the beauty of the BSD license my eyes will glaze over, I'll stick my fingers in my ears, hum the national anthem of Elbonia and dream of the man page for ld(1). ;) I.e., I don't care about license discussions. I want interoperability. At 9:48 +0100 3/7/06, Olaf M. Kolkman wrote: >Since this is one of the issues that can drag on forever if we are >not careful I propose some process that sets a timeline to this >discussion. > >On the basis of previous discussion on the list I think we can go >for a consensus call on the text below: > >5.2 No Intellectual Property Encumbrance > > The solution SHOULD not have any intellectual > property encumbrance on either the technologies > used by the solution nor implementations > of the solution. > > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license > > > >I'd like to ask participants to state on-list > > >a: That they consent with section 5.2 as above. > >b: They would like to see section 5.2 as above modified. Then send >argumentation and "patch" > >c: They would like to see any mention of IPR dropped from the requirements. > > >Please respond by mail, try not to go into battle over arguments, >state your own arguments once and trust others to be able to read. >If you need clarification of arguments please ask. > >We'll assess the outcome of the discussion slightly before or during >the face2face meeting in Dallas. > >Please remain courteous and civil. Please respect the motivations >for peoples opinions. > >--Olaf > > > > >----------------------------------------------------------- >Olaf M. Kolkman >NLnet Labs >http://www.nlnetlabs.nl/ > > > > > >content-type: application/pgp-signature; x-mac-type=70674453; > name=PGP.sig >content-description: This is a digitally signed message part >content-disposition: inline; filename=PGP.sig >content-transfer-encoding: 7bit > >Attachment converted: Macintosh HD:PGP 146.sig (pgDS/ ) (001AFBAB) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 07 06:20:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaET-0005Sx-9e for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:20:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGaES-00070S-T2 for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:20:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGaBQ-000InL-Qr for namedroppers-data@psg.com; Tue, 07 Mar 2006 11:16:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGaBP-000In0-QT for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 11:16:52 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k27BGZWW029643; Tue, 7 Mar 2006 06:16:36 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060307111049.GB27709@vacation.karoshi.com.> References: <440B18B2.2040500@connotech.com> <20060307111049.GB27709@vacation.karoshi.com.> Date: Tue, 7 Mar 2006 06:16:39 -0500 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Cc: "Olaf M. Kolkman" , Namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Great - I'm called "wise" minutes after threatening to glaze my eyes over, stick my fingers in my ears, hum a tune and dream of a man page. ;) At 11:10 +0000 3/7/06, bmanning@vacation.karoshi.com wrote: > ed is wise in the ways of protoocol development. C: is the most prudent > course. otherwise, if there is a need to refer to IPR at all, i'd take > A: - since that is the path of least resistance. > >--bill > >On Tue, Mar 07, 2006 at 09:48:06AM +0100, Olaf M. Kolkman wrote: >> >> Since this is one of the issues that can drag on forever if we are >> not careful I propose some process that sets a timeline to this >> discussion. >> >> On the basis of previous discussion on the list I think we can go for >> a consensus call on the text below: >> >> 5.2 No Intellectual Property Encumbrance >> >> The solution SHOULD not have any intellectual >> property encumbrance on either the technologies >> used by the solution nor implementations >> of the solution. >> >> The solution MUST be covered by one of options >> (a) or (c) of section 6.5 of [RFC3979]. If the >> technology is covered by option (a), the license SHOULD >> be compatible with the BSD open source license >> >> >> >> I'd like to ask participants to state on-list >> >> >> a: That they consent with section 5.2 as above. >> >> b: They would like to see section 5.2 as above modified. Then send >> argumentation and "patch" >> >> c: They would like to see any mention of IPR dropped from the >> requirements. >> >> >> Please respond by mail, try not to go into battle over arguments, >> state your own arguments once and trust others to be able to read. If >> you need clarification of arguments please ask. >> >> We'll assess the outcome of the discussion slightly before or during >> the face2face meeting in Dallas. >> >> Please remain courteous and civil. Please respect the motivations for >> peoples opinions. >> >> --Olaf >> >> >> >> >> ----------------------------------------------------------- >> Olaf M. Kolkman >> NLnet Labs >> http://www.nlnetlabs.nl/ >> >> >> > > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 07 06:21:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaFR-0006YU-MU for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:21:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGaFQ-00072d-DU for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 06:21:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGaCQ-000Itv-Vy for namedroppers-data@psg.com; Tue, 07 Mar 2006 11:17:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGaCQ-000Itb-5H for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 11:17:54 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k27BHmM3067294; Tue, 7 Mar 2006 12:17:48 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <440CEB19.5070508@connotech.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-50-214315844" Message-Id: Cc: Thierry Moreau , namedroppers@ops.ietf.org, "(DNSSEC deployment)" Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus Date: Tue, 7 Mar 2006 12:17:52 +0100 To: "william(at)elan.net" X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-50-214315844 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 7, 2006, at 12:10 PM, william(at)elan.net wrote: > > On Tue, 7 Mar 2006, Olaf M. Kolkman wrote: > >> This is not correct. The DLV _scheme_ has not been approved. It is >> the DLV _resource record_ has been specified in RFC4431. 4431 is >> not an RFC that defines the DLV _scheme_ nor does it standardize >> its use. Actually 4431 does not contain any language on how the RR >> ought to be used, although it hints to use by validators during >> the validation process. > > Is there reason TA and DLV got such high numbers for their RR? > Yes, the RR types have been assigned based on "specification required" (RFC 2929). To paraphrase: one type code range require standard actions, other type codes are for grabs, and some type codes need a stable reference. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-50-214315844 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEDWvhtN/ca3YJIocRAqdzAJ9OrHjNq5ArUZ4MOXResAu1LPjqjACgz1DI eV+msi6FdrCevhZlTJN5QEg= =4u/B -----END PGP SIGNATURE----- --Apple-Mail-50-214315844-- -- to unsubscribe send a message to namedroppers-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 Mar 07 07:33:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGbNO-0006sT-Gs for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 07:33:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGbNO-0000lo-3b for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 07:33:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGbIZ-00030D-Mt for namedroppers-data@psg.com; Tue, 07 Mar 2006 12:28:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGbIX-0002zn-QL for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 12:28:18 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k27CRo9J023460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Mar 2006 13:27:52 +0100 From: Simon Josefsson To: "Olaf M. Kolkman" Cc: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <440B18B2.2040500@connotech.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060307:olaf@nlnetlabs.nl::dKTYZxOOd6NTxXbo:6sP X-Hashcash: 1:21:060307:namedroppers@ops.ietf.org::XNTZ/KSKk8L6mwMX:6OcK X-Hashcash: 1:21:060307:olaf@nlnetlabs.nl::5qQMqucX9di1XrF6:GEq9 Date: Tue, 07 Mar 2006 13:27:48 +0100 In-Reply-To: (Olaf M. Kolkman's message of "Tue, 7 Mar 2006 09:48:06 +0100") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 "Olaf M. Kolkman" writes: > On the basis of previous discussion on the list I think we can go for > a consensus call on the text below: > > 5.2 No Intellectual Property Encumbrance > > The solution SHOULD not have any intellectual I suggest SHOULD NOT here. > property encumbrance on either the technologies > used by the solution nor implementations > of the solution. The word "intellectual property" seems odd. IP include copyrights, and most likely the technology that will be proposed for this problem will be copyrighted. If this text is kept at all, I suggest modifying "intellectual property" into "patent", if that is what you really are referring to. > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license Again, I believe that this should be changed to include more licenses, such as the GPL. If the text is kept at all, of course. BSD code is not necessarily possible to use under the GPL. For completeness, mentioning Microsoft EULA may be useful too, the DNS resolver in Windows is widely used today. I believe we should require (a) _and_ (c). Obtaining a license may be difficult enough to prohibit some usages, and I don't see why including that option would improve the technology. > I'd like to ask participants to state on-list > > > a: That they consent with section 5.2 as above. With my modifications, yes. > b: They would like to see section 5.2 as above modified. Then send > argumentation and "patch" See the two changes above. > c: They would like to see any mention of IPR dropped from the > requirements. The term IPR often confuse things, please say patents if that is the problem. In theory, I'd prefer if we solved this without any IPR concerns at all, and stuck to the technology issues, but I don't think it is practical to expect that to work in the field. So I think we'll need to include something to this effect, to make sure everyone can implement it without problems. Note that I'm not implying that TAKREM's license is too problematic to consider. If the "GPL" was changed into "GPL, LGPL or BSD", it might very well be a candidate for the final solution. Even if TAKREM is patented. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 08:44:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGcU5-0004Ne-JK for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 08:44:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGcU2-0002cI-9w for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 08:44:17 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGcQu-0007dq-Ea for namedroppers-data@psg.com; Tue, 07 Mar 2006 13:41:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGcQt-0007de-Qq for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 13:40:59 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FGcQs-0001ku-Q8 for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 08:40:58 -0500 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 0E08B13744; Tue, 7 Mar 2006 08:40:45 -0500 (EST) Date: Tue, 7 Mar 2006 08:40:44 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <20060307134044.GA18555@dba3> Reply-To: Andrew Sullivan References: <440B18B2.2040500@connotech.com> <3D7150A8-53E1-4D3F-9629-D7E628F6FBBF@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D7150A8-53E1-4D3F-9629-D7E628F6FBBF@NLnetLabs.nl> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On Tue, Mar 07, 2006 at 10:54:20AM +0100, Olaf M. Kolkman wrote: > I thought that was covered by "should be compatible with BSD > license" (but that is just me trying to find wording on which we can > consent) Would this do: If the technology is covered by option (a), the license SHOULD NOT be more restrictive than the BSD open source license or this If the technology is covered by option (a), the license SHOULD permit implementation and distribution under the terms of the BSD open source license ? I am aware that both of these are stronger than the original text, so I can see why they'd be objectionable to some. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Mar 07 09:37:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdJy-00057R-C2 for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:37:54 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdJy-0004tc-Ah for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:37:54 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGdJV-0006gb-5I for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:37:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGdHr-000BRl-Sw for namedroppers-data@psg.com; Tue, 07 Mar 2006 14:35:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGdHq-000BRO-OY for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 14:35:43 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k27EZTRd030595 for ; Tue, 7 Mar 2006 09:35:29 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k27EZT3h030594 for namedroppers@ops.ietf.org; Tue, 7 Mar 2006 09:35:29 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGNdu-000JHs-JJ for namedroppers@ops.ietf.org; Mon, 06 Mar 2006 21:53:26 +0000 Received: from ngarcha.here (ksanti.fugue.com [66.93.162.128]) by toccata.fugue.com (Postfix) with ESMTP id 1A22F1B2192; Mon, 6 Mar 2006 14:53:22 -0700 (MST) From: Ted Lemon Organization: Diamond Mountain To: Thierry Moreau Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Mon, 6 Mar 2006 14:53:48 -0700 User-Agent: KMail/1.9.1 Cc: namedroppers@ops.ietf.org References: <200603052041.k25Kfo2N032319@localhost.localdomain> <20060306183416.E90791142C@sa.vix.com> <440CAA21.40103@connotech.com> In-Reply-To: <440CAA21.40103@connotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603061453.49016.mellon@fugue.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Monday 06 March 2006 14:31, Thierry Moreau wrote: > This is completely ridiculous! Please record my disagreement. I don't think that you intend anything that you think is unreasonable, but that's immaterial, because your model for how DNSSEC should be deployed is not what I want. Your model as stated in one of the two emails to which you referred me is that some people will pay extra for DNSSEC, and everyone else will not have it. And you'd like a cut of the transactions where people do pay for it. I don't care about you getting a cut of the proceeds. But what I do care about is that in order for you to get what you want, the business model for DNSSEC has to be a two-tier model where I have to pay extra to get security. I don't pay extra to use SSH. I don't pay extra to use SSL. I don't pay extra to use PGP. I don't pay extra to use IPSEC. So why do you think it's okay that I should pay extra to use DNSSEC? There is a difference between designing a protocol that *forces* a two-tier model, and designing a protocol that *allows* a two-tier model. In the former case, if the two-tier model fails, the protocol fails. In the latter case, if the two-tier model fails, we're okay - a lot of us didn't want the two-tier model anyway. By structuring things the way you intend to, you force anyone who charges to register a domain name, even if they charge the same price for secure versus not secure, to pay you a fee. So your proposal creates an economic incentive for exactly the opposite of what I hope to see as the outcome of the process of standardizing DNSSEC. So even though it's not technically a protocol issue, designing into the protocol a requirement like the one you've stated is completely unacceptable to me. I realize that this sucks for you. You've created something, which you at least think is cool enough that you felt it was worthy of patent protection. And nobody even wants to talk about the thing you created - they just want to talk about the patent issue. And people are even making somewhat unkind accusations. But the working group can't be concerned with what sucks or doesn't suck for you. This isn't a negotiation over terms. This is a discussion about what the working group wants as an outcome. And I think, I hope, that the working group as a whole does not want the outcome of the long process of inventing DNSSEC to be that only those who can pay extra for it get to enjoy the benefits of all this work. -- to unsubscribe send a message to namedroppers-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 Mar 07 09:38:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdKf-0005dj-IX for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:38:37 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdKf-0004vR-GK for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:38:37 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGdKd-0006ig-OX for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:38:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGdJB-000BZm-TF for namedroppers-data@psg.com; Tue, 07 Mar 2006 14:37:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGdJB-000BZS-5x for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 14:37:05 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k27Eb0H3030612 for ; Tue, 7 Mar 2006 09:37:00 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k27Eb0CP030611 for namedroppers@ops.ietf.org; Tue, 7 Mar 2006 09:37:00 -0500 (EST) (envelope-from namedroppers) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGT52-000EtR-1T for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 03:41:48 +0000 Received: from ngarcha.here (ksanti.fugue.com [66.93.162.128]) by toccata.fugue.com (Postfix) with ESMTP id 84A541B2215; Mon, 6 Mar 2006 20:41:43 -0700 (MST) From: Ted Lemon Organization: Diamond Mountain To: Thierry Moreau Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Mon, 6 Mar 2006 20:42:10 -0700 User-Agent: KMail/1.9.1 Cc: Namedroppers References: <200603052041.k25Kfo2N032319@localhost.localdomain> <200603061453.49016.mellon@fugue.com> <440CEAF7.9090602@connotech.com> In-Reply-To: <440CEAF7.9090602@connotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603062042.10970.mellon@fugue.com> X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Monday 06 March 2006 19:07, Thierry Moreau wrote: > If I understand this, there would be an analogy between DNSSEC and > smallpox vaccine which was so beneficial to the world that it deserved > (government-funded) no-fee distribution. Indeed it worked: smallpox has > been eradicated from the planet. Your analogy is flawed: you haven't invented the only cure for the key rollover problem, and there is no need for the governments of the world to buy you out. If you'd care to dispute that point by claiming that you have in fact invented and patented all possible key rollover solutions, then perhaps we are at your mercy. But you have made no such assertion, so at least for now it is fair for us to assume that we are not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 09:55:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdb5-00037T-4h for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:55:35 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdK2-0004tc-5Y for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:37:58 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGd8a-0006e5-JN for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:26:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGd6U-000ATg-KU for namedroppers-data@psg.com; Tue, 07 Mar 2006 14:23:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [32.97.110.152] (helo=e34.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGd6T-000ASf-AX for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 14:23:57 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k27ENnGI030647 for ; Tue, 7 Mar 2006 09:23:49 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k27EQcLf191986 for ; Tue, 7 Mar 2006 07:26:38 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k27ENmkp021985 for ; Tue, 7 Mar 2006 07:23:48 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-81.mts.ibm.com [9.65.201.81]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k27ENlrE021952; Tue, 7 Mar 2006 07:23:48 -0700 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k27ENa5d025383; Tue, 7 Mar 2006 09:23:46 -0500 Message-Id: <200603071423.k27ENa5d025383@cichlid.raleigh.ibm.com> To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Message from "Olaf M. Kolkman" of "Tue, 07 Mar 2006 09:48:06 +0100." Date: Tue, 07 Mar 2006 09:23:35 -0500 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 "Olaf M. Kolkman" writes: > Since this is one of the issues that can drag on forever if we are > not careful I propose some process that sets a timeline to this > discussion. Thank you! > On the basis of previous discussion on the list I think we can go for > a consensus call on the text below: > 5.2 No Intellectual Property Encumbrance > The solution SHOULD not have any intellectual > property encumbrance on either the technologies > used by the solution nor implementations > of the solution. > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license IMO, Section 5.2 is completely misguided. Here, we have the classic case of a "requirements document" trying to pick (or exclude) a particular solution, in advance of actually working on a solution. But the approach being used is a hammer (e.g., "no IPR is acceptable"), when at the end of the day, we'd be better off doing an evaluation of the specific case at hand, and making a decision based on the available information. I believe I understand what the above section is attempting to achieve. And I support that general goal. But, the WG would be a lot better off taking each IPR claim as it stands. Look at the technology, look at the IPR issues, and then simply decide (on a case-by-case basis), does the WG want to adopt the technology, or does it want to (try to) route around it and use something different? The only way to answer this question (as engineers -- where one weighs the pros and cons) is to evaluate two proposals, one with the IPR, and one that is believed to route around it. If the latter is an adequate technical solution, the WG should just go for it. If not, it needs to reevaluate its options. > I'd like to ask participants to state on-list > c: They would like to see any mention of IPR dropped from the > requirements. I'm for choice c. Thomas -- to unsubscribe send a message to namedroppers-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 Mar 07 10:52:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeUN-0007ka-TW for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 10:52:43 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdJy-0004tc-Qi for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:37:54 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGdFz-0006fh-IU for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 09:33:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGdDk-000B4R-N1 for namedroppers-data@psg.com; Tue, 07 Mar 2006 14:31:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGdDi-000B44-1a for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 14:31:26 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id C3114154 for ; Tue, 7 Mar 2006 09:31:24 -0500 (EST) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E9CC541AC for ; Tue, 7 Mar 2006 09:31:23 -0500 (EST) Date: Tue, 07 Mar 2006 09:31:23 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: References: <440B18B2.2040500@connotech.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060307143123.E9CC541AC@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a At Tue, 7 Mar 2006 09:48:06 +0100, Olaf M Kolkman wrote: > > On the basis of previous discussion on the list I think we can go for > a consensus call on the text below: > > 5.2 No Intellectual Property Encumbrance > > The solution SHOULD not have any intellectual > property encumbrance on either the technologies > used by the solution nor implementations > of the solution. > > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license > > I'd like to ask participants to state on-list > > a: That they consent with section 5.2 as above. 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 Tue Mar 07 10:55:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeXH-0001Rn-LE for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 10:55:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGeXG-0007ze-8k for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 10:55:43 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGeUF-000Geo-RS for namedroppers-data@psg.com; Tue, 07 Mar 2006 15:52:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGeUE-000Geb-Nl for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 15:52:34 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00187E; 7 Mar 2006 10:52:17 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 7 Mar 2006 10:52:02 -0500 Received: from connotech.com (209.71.204.120) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00187D; 7 Mar 2006 10:51:59 -0500 Message-ID: <440DB50C.1020001@connotech.com> Date: Tue, 07 Mar 2006 11:30:04 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <440B18B2.2040500@connotech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Olaf M. Kolkman wrote: > > I'd like to ask participants to state on-list > > > a: [...] > > b: [... > > c: They would like to see any mention of IPR dropped from the > requirements. > I vote for c. I.e. not closing a-priori an option the wg may use later. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 07 10:55:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeXK-0001c0-ML for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 10:55:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGeXK-0007zo-8J for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 10:55:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGeUw-000Ghz-EK for namedroppers-data@psg.com; Tue, 07 Mar 2006 15:53:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGeUv-000Ghb-PA for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 15:53:17 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO001880; 7 Mar 2006 10:53:00 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 7 Mar 2006 10:52:46 -0500 Received: from connotech.com (209.71.204.120) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00187F; 7 Mar 2006 10:52:34 -0500 Message-ID: <440DB530.7050805@connotech.com> Date: Tue, 07 Mar 2006 11:30:40 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: namedroppers@ops.ietf.org Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus References: <440CEB19.5070508@connotech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Olaf M. Kolkman wrote: > > On Mar 7, 2006, at 3:08 AM, Thierry Moreau wrote: > >> Dear all: >> >> I realized that the DLV scheme has been approved as the >> informational RFC4431, and that the DLV RR [...] has been >> approved by IANA according to >> http://www.iana.org/assignments/dns-parameters . [...] > > > This is not correct. The DLV _scheme_ has not been approved. It is the > DLV _resource record_ has been specified in RFC4431. 4431 is not an RFC > that defines the DLV _scheme_ nor does it standardize its use. Actually > 4431 does not contain any language on how the RR ought to be used, > although it hints to use by validators during the validation process. > > The RR types have been assigned based on "specification required" (RFC > 2929). > I did read the "specification required" as requiring that "interoperability between independent implementations is possible", and so I concluded that RFC4431 provided an interoperability specification between independent implementations of the DLV RR functionality (OK, admittedly I froze my reading skills for a moment when loking at RFC4431). > The specification only defines the content of the RR it specifies the > on-the-wire format, has a well defined zone-file format, does not > require compression, and does not rely on special processing in any > component in the DNS. That means that it is just a blob of data carried > through the DNS as an RR. IMHO this is sufficient any RR type to get an > RR code. (We trying to deal with the fact that many people put blobs of > data in TXT RRs because it seems so difficult to get a type code > assigned.) > > If you were to argue that the DLV is a special case because it could be > used for making policy decisions at the validator end, I would be able > to follow that argument. I don't. > But the point is that that behavior has not > been described in the RFC [...]. > Then why did DLV move from a "private use" code point (value 65323, according to BIND 9.3.2 source code) to a "specification required" code point (value 32769)? Since one of the RFC4431 authors is affiliated with the publisher of BIND 9.3.2, I assume that the dual use of the acronym "DLV" is not accidental. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 07 13:07:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgaq-0003Aa-Jh for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 13:07:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgap-0004tS-7j for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 13:07:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGgXN-000PbL-8v for namedroppers-data@psg.com; Tue, 07 Mar 2006 18:03:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGgXM-000Pb8-Fh for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 18:03:56 +0000 Received: from ngarcha.here (ksanti.fugue.com [66.93.162.128]) (using SSLv3 with cipher EXP1024-RC4-SHA (56/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 926445684B; Tue, 7 Mar 2006 10:03:55 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: "Olaf M. Kolkman" Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Tue, 7 Mar 2006 11:04:26 -0700 User-Agent: KMail/1.9.1 Cc: Namedroppers References: <440B18B2.2040500@connotech.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603071104.27071.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Tuesday 07 March 2006 01:48, you wrote: > 5.2 No Intellectual Property Encumbrance > > The solution SHOULD not have any intellectual > property encumbrance on either the technologies > used by the solution nor implementations > of the solution. > > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license For those who haven't read it, the section referenced in RFC3979 in fact already covers both the BSD license and the GPL - it specifies a royalty-free, reasonable and non-discriminatory license. So I don't think there's any need to mention either license here. Having said that, I think that the text is fine, and I agree to it as written (but would not object to removing the last sentence of the second paragraph). -- to unsubscribe send a message to namedroppers-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 Mar 07 13:28:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgut-0002b5-Ht for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 13:28:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgur-0005iR-6K for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 13:28:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGgtB-0001B7-IN for namedroppers-data@psg.com; Tue, 07 Mar 2006 18:26:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGgtA-0001Au-Pi for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 18:26:28 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 9E0162D7 for ; Tue, 7 Mar 2006 13:26:27 -0500 (EST) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E52B841AC for ; Tue, 7 Mar 2006 13:26:26 -0500 (EST) Date: Tue, 07 Mar 2006 13:26:26 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus In-Reply-To: <440DB530.7050805@connotech.com> References: <440CEB19.5070508@connotech.com> <440DB530.7050805@connotech.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060307182626.E52B841AC@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad At Tue, 07 Mar 2006 11:30:40 -0500, Thierry Moreau wrote: > > Then why did DLV move from a "private use" code point (value 65323, > according to BIND 9.3.2 source code) to a "specification required" code > point (value 32769)? Because using a well-known type code avoids possible confusion with unrelated uses of the "private use" type code 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 Mar 07 14:00:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhNb-0001AK-23 for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 13:57:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGhI7-0006TX-Ua for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 13:52:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGhFJ-0002iU-Ui for namedroppers-data@psg.com; Tue, 07 Mar 2006 18:49:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGhFI-0002iG-Rm for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 18:49:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6E44A11425 for ; Tue, 7 Mar 2006 18:49:20 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Tue, 07 Mar 2006 09:23:35 EST." <200603071423.k27ENa5d025383@cichlid.raleigh.ibm.com> References: <200603071423.k27ENa5d025383@cichlid.raleigh.ibm.com> Date: Tue, 07 Mar 2006 18:49:20 +0000 Message-Id: <20060307184920.6E44A11425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd i've had the benefit of reading several other replies to olaf's request, and as olaf requested, this will be my last word on this topic until the current issue (ISSUE 1) has been decided. i think that the entire document (RFC3979) deserves careful review by those weighing in on this point, not just section 6.5. in section 4.1, constraints are placed on the IESG as to whether a document can be progressed from one standards state to the next, and a presumption is made as to the reasonableness and discriminatoryness of licensing terms that i think are very significant to the points that ed lewis and ted lemon have made here today. If the two unrelated implementations of the specification that are required to advance from Proposed Standard to Draft Standard have been produced by different organizations or individuals, or if the "significant implementation and successful operational experience" required to advance from Draft Standard to Standard has been achieved, the IESG will presume that the terms are reasonable and to some degree non-discriminatory. (See RFC 2026, Section 4.1.3.) Note that this also applies to the case where multiple implementers have concluded that no licensing is required. This presumption may be challenged at any time, including during the Last-Call period by sending email to the IESG. fundamentally, RFC3979 is about "what the IESG will do" and not about what a WG will do. if the WG believes that significant implementation and successful operational experience is unlikely to result from a technology choice then we are entirely within our rights to disqualify that choice on that basis without evaluating it for quality at all. in section 6.5, we see: Since IPR disclosures will be used by IETF working groups during their evaluation of alternative technical solutions, it is helpful if an IPR disclosure includes information about licensing of the IPR in case Implementing Technologies require a license. Specifically, it is helpful to indicate whether, upon approval by the IESG for publication as RFCs of the relevant IETF specification(s), all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to an Implementing Technology a) under a royalty-free and otherwise reasonable and non- discriminatory license, or b) under a license that contains reasonable and non-discriminatory terms and conditions, including a reasonable royalty or other payment, or c) without the need to obtain a license from the IPR holder. (a) (b) and (c) are meant to be fully inclusive, as though no fourth choice is even a theoretical possibility. since (b) is highly subjective -- no doubt many licensors will disagree with many potential licensees as to the precise meaning of "reasonable and non-discriminatory" -- i think that these three choices are not fully inclusive. (that'll teach me not to skip POISED meetings, i suppose.) section 6.5 continues, in toto: The inclusion of licensing information in IPR disclosures is not mandatory but it is encouraged so that the working groups will have as much information as they can during their deliberations. If the inclusion of licensing information in an IPR disclosure would significantly delay its submission it is quite reasonable to submit a disclosure without licensing information and then submit a new disclosure when the licensing information becomes available. i don't believe that anyone here is claiming that any trust anchor IPR holder has failed to comply with either the letter or the spirit of RFC3979. what we appear to be doing, instead, is talking about issues unrelated to RFC3979, specifically whether encumbered technology is likely to achieve significant and successful deployment. there appears to be consensus on that point ("no") but i recognize that the WG chairs are responsible for determining consensus, so i won't harp further on that (not today anyway.) in section 8, we see: In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. i'm torn between saying that the above text is wrong-headed, vs. saying that a WG also has the discretion to disqualify encumbered technology outright if they believe that wide deployment will not occur without a world wide royalty free perpetual license (as was given by RSA for their "dnssafe" a decade ago.) but if we assume that the above text ought to guide us, then we're being told to use our discretion. that seems to argue that we solicit several alternatives so that we can decide which one is superior and then, if the one we think is superior happens to be encumbered, we can subsequently decide whether it is "superior enough". this, in turn, would seem to argue against any kind of IPR restriction in the requirements document under discussion here. but wait -- there's more! Over the last few years the IETF has adopted stricter requirements for some security technologies. It has become common to have a mandatory-to-implement security technology in IETF technology specifications. This is to ensure that there will be at least one common security technology present in all implementations of such a specification that can be used in all cases. This does not limit the specification from including other security technologies, the use of which could be negotiated between implementations. An IETF consensus has developed that no mandatory-to-implement security technology can be specified in an IETF specification unless it has no known IPR claims against it or a royalty-free license is available to implementers of the specification unless there is a very good reason to do so. This limitation does not extend to other security technologies in the same specification if they are not listed as mandatory-to-implement. if we believe that trust anchor management is mandatory-to-implement, then the WG has no choice at all except to disqualify encumbered technology. i'm pretty sure that this WG has already "consensed" on this point, and that "we" believe that deploying DNSSEC-bis without some way to roll over trust anchors (especially the root trust anchor) would be a mistake. that makes trust anchor management a mandatory-to-implement technology for DNSSEC-bis, and if we are to be guided by the above text, we have no reason to even evaluate any encumbered technology in the absence of a world wide royalty-free perpetual license. (section 8 continues but i don't see it as relevant to this thread.) RFC3979 does not define "royalty-free" or "implementors of the specification". this leaves open a possible challenge where, for example, DNSSEC technology vendors (whether proprietary/commercial, or F/OSS; whether GPL or BSD style) are allowed to ship (for free or for a fee) software without paying royalties, but the consumers of this technology would have to pay royalties based perhaps on the revenue they can generate using said technology. so, RFC3979 is weak even where it applies to us at all, but i think we can make something of it. with that preamble, here's olaf's question: > On the basis of previous discussion on the list I think we can go for > a consensus call on the text below: > > 5.2 No Intellectual Property Encumbrance > > The solution SHOULD not have any intellectual > property encumbrance on either the technologies > used by the solution nor implementations > of the solution. > > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license > > I'd like to ask participants to state on-list > > a: That they consent with section 5.2 as above. > > b: They would like to see section 5.2 as above modified. Then send > argumentation and "patch" > > c: They would like to see any mention of IPR dropped from the requirements. > > Please respond by mail, try not to go into battle over arguments, state your > own arguments once and trust others to be able to read. If you need > clarification of arguments please ask. > > We'll assess the outcome of the discussion slightly before or during the > face2face meeting in Dallas. > > Please remain courteous and civil. Please respect the motivations for > peoples opinions. and here's my answer. count me as (b). argumentation as above. patch is: 5.2 No Intellectual Property Encumbrance Because trust anchor rollover is considered "mandatory-to-implement", section 8 of [RFC3979] requires that the technology solution chosen must be unencumbered or must be available under royalty-free terms. For this purpose, "royalty-free" is defined as follows: world wide, perpetual right to use, without fee, in commerce or otherwise, where "use" includes descriptions of algorithms, distribution and/or use of hardware implementations, distribution and/or use of software systems in source and/or binary form, in all DNS or DNSSEC applications including registry, registrar, domain name service including authority, recursion, caching, forwarding, stub resolver, or similar. In summary, no implementor, distributor, or operator of the technology chosen for trust anchor management shall be expected or required to pay any fee to any IPR holder for the right to implement, distribute, or operate a system which includes the chosen mandatory-to-implement solution. i might not be in dallas. i do however "trust others to be able to read." -- to unsubscribe send a message to namedroppers-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 Mar 07 15:05:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGiR2-0007vf-2f for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 15:05:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGiR1-0000es-Ob for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 15:05:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGiOZ-0007wf-BS for namedroppers-data@psg.com; Tue, 07 Mar 2006 20:02:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGiOV-0007vO-Tl for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 20:02:56 +0000 Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FGiOU-0008SJ-HZ for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 15:02:54 -0500 Received: by dba3.int.libertyrms.info (ca.afilias.info, from userid 1019) id 90AB313744; Tue, 7 Mar 2006 15:02:40 -0500 (EST) Date: Tue, 7 Mar 2006 15:02:40 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <20060307200240.GP18555@dba3> Reply-To: Andrew Sullivan References: <200603071423.k27ENa5d025383@cichlid.raleigh.ibm.com> <20060307184920.6E44A11425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060307184920.6E44A11425@sa.vix.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Tue, Mar 07, 2006 at 06:49:20PM +0000, Paul Vixie wrote: > alternatives so that we can decide which one is superior and then, > if the one we think is superior happens to be encumbered, we can > subsequently decide whether it is "superior enough". this, in > turn, would seem to argue against any kind of IPR restriction in > the requirements document under discussion here. I disagree a little with the above; but similar reasoning was the basis on which I posted, recently, that any restriction that prevented BSD distribution was automatically disqualified essentially, and not just accidentally. It is a requirements document that is under discussion, and not a specification. So, the draft outlines what are the necessary (and maybe sufficient) conditions for a key rollover mechanism. Such a document cannot consider merely the technical issues related to the mechanism. It must, by nature, take into consideration whether a scheme is implementable, given the Internet with which we find ourselves. (By way of comparison, I think everyone would agree that there are items that could be better handled if one of the acceptable criteria were, "All the resolvers in the world are replaced in 6 months." But that's not the environment we're designing things for, I take it.) If I am right, one of the requirements is that whatever we adopt has to be acceptable to the community of developers who actually provide most of this infrastructure. I don't see that as an add-on requirement, to be thought about after the technology is decided upon, any more than, "It doesn't entail a resolver flag day," is something we think about after we evaluate all the possible technology. And since this isn't a protocol we're discussing, yet, RFC 3979 is only relevant in terms of what targets we're picking. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Mar 07 16:10:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjRn-0003Ym-Mp for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 16:10:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGjRn-0006oj-Es for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 16:10:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGjP2-000CT3-E7 for namedroppers-data@psg.com; Tue, 07 Mar 2006 21:07:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGjP1-000CSr-Mu for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 21:07:31 +0000 Received: from [192.168.0.6] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 0997EC2DA9; Tue, 7 Mar 2006 21:07:35 +0000 (GMT) Date: Tue, 07 Mar 2006 21:02:44 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , Namedroppers Cc: Alex Bligh Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: In-Reply-To: <20060307184920.6E44A11425@sa.vix.com> References: <200603071423.k27ENa5d025383@cichlid.raleigh.ibm.com> <20060307184920.6E44A11425@sa.vix.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c --On 07 March 2006 18:49 +0000 Paul Vixie wrote: > and here's my answer. count me as (b). argumentation as above. patch > is: I think Paul has it right. So count me as (b) with his patch too. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 16:10:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjRf-0003XZ-7w for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 16:10:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGjRd-0006mu-SB for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 16:10:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGjPB-000CU7-Il for namedroppers-data@psg.com; Tue, 07 Mar 2006 21:07:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGjPB-000CTu-2n for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 21:07:41 +0000 Received: from [192.168.0.6] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id AE34EC2DFF; Tue, 7 Mar 2006 21:07:35 +0000 (GMT) Date: Tue, 07 Mar 2006 21:07:27 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , Namedroppers Cc: Alex Bligh Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <1C82E71AF96301D0D4EE9C81@[10.20.30.41]> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c --On 07 March 2006 18:49 +0000 Paul Vixie wrote: > and here's my answer. count me as (b). argumentation as above. patch > is: I think Paul has it right. So count me as (b) with his patch too. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 16:10:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjRg-0003Xf-O6 for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 16:10:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGjRg-0006n1-Ea for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 16:10:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGjP5-000CTV-2j for namedroppers-data@psg.com; Tue, 07 Mar 2006 21:07:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [195.177.253.212] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGjP4-000CTI-KI for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 21:07:34 +0000 Received: from [192.168.0.6] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 6DF82C2DB4; Tue, 7 Mar 2006 21:07:35 +0000 (GMT) Date: Tue, 07 Mar 2006 21:04:29 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , Namedroppers Cc: Alex Bligh Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c --On 07 March 2006 18:49 +0000 Paul Vixie wrote: > and here's my answer. count me as (b). argumentation as above. patch > is: I think Paul has it right. So count me as (b) with his patch too. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 07 17:07:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGkLI-0005Ew-HY for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 17:07:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGkLF-00057c-2C for dnsext-archive@lists.ietf.org; Tue, 07 Mar 2006 17:07:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGkIu-000Gv4-Ur for namedroppers-data@psg.com; Tue, 07 Mar 2006 22:05:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGkIt-000Gut-QA for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 22:05:15 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id DC37CE60CC for ; Tue, 7 Mar 2006 22:05:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.1) with ESMTP id k27M4GQ0003136; Wed, 8 Mar 2006 09:04:22 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200603072204.k27M4GQ0003136@drugs.dv.isc.org> To: Thierry Moreau Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: DLV now an informational section of DNS protocol suite, plus the TA RR as a bonus In-reply-to: Your message of "Tue, 07 Mar 2006 11:30:40 CDT." <440DB530.7050805@connotech.com> Date: Wed, 08 Mar 2006 09:04:16 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db > > > Olaf M. Kolkman wrote: > > > > On Mar 7, 2006, at 3:08 AM, Thierry Moreau wrote: > > > >> Dear all: > >> > >> I realized that the DLV scheme has been approved as the > >> informational RFC4431, and that the DLV RR [...] has been > >> approved by IANA according to > >> http://www.iana.org/assignments/dns-parameters . [...] > > > > > > This is not correct. The DLV _scheme_ has not been approved. It is the > > DLV _resource record_ has been specified in RFC4431. 4431 is not an RFC > > that defines the DLV _scheme_ nor does it standardize its use. Actually > > 4431 does not contain any language on how the RR ought to be used, > > although it hints to use by validators during the validation process. > > > > The RR types have been assigned based on "specification required" (RFC > > 2929). > > > > I did read the "specification required" as requiring that > "interoperability between independent implementations is possible", and > so I concluded that RFC4431 provided an interoperability specification > between independent implementations of the DLV RR functionality (OK, > admittedly I froze my reading skills for a moment when loking at RFC4431). > > > The specification only defines the content of the RR it specifies the > > on-the-wire format, has a well defined zone-file format, does not > > require compression, and does not rely on special processing in any > > component in the DNS. That means that it is just a blob of data carried > > through the DNS as an RR. IMHO this is sufficient any RR type to get an > > RR code. (We trying to deal with the fact that many people put blobs of > > data in TXT RRs because it seems so difficult to get a type code > > assigned.) > > > > If you were to argue that the DLV is a special case because it could be > > used for making policy decisions at the validator end, I would be able > > to follow that argument. > > I don't. > > > But the point is that that behavior has not > > been described in the RFC [...]. > > > > Then why did DLV move from a "private use" code point (value 65323, > according to BIND 9.3.2 source code) to a "specification required" code > point (value 32769)? Since one of the RFC4431 authors is affiliated with > the publisher of BIND 9.3.2, I assume that the dual use of the acronym > "DLV" is not accidental. Private use was good enough for testbeds. It is not good enough for longer term deployment. That required that the type be registered (both by name and code point). We really should have kept it called TYPE65323 rather than naming it DLV. As of 9.4.0/9.3.3 TYPE65323 will go back to being treated as opaque. Mark > Regards, > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau@connotech.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: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 08 04:04:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGubF-0007sV-9S for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 04:04:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGubD-0008U9-Ve for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 04:04:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGuXV-0008Gv-TI for namedroppers-data@psg.com; Wed, 08 Mar 2006 09:01:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGuXT-0008GM-Ln for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 09:01:00 +0000 Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k2890bnc022520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 10:00:39 +0100 From: Simon Josefsson To: Thomas Narten Cc: Namedroppers , "Olaf M. Kolkman" Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <200603071423.k27ENa5d025383@cichlid.raleigh.ibm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060308:namedroppers@ops.ietf.org::taqFhWxbnKLOqdaS:Mya X-Hashcash: 1:21:060308:olaf@nlnetlabs.nl::8Z6bAfZcZDX3bEJM:adY X-Hashcash: 1:21:060308:narten@us.ibm.com::8lW2YSxLJp+pRH8e:Feur X-Hashcash: 1:21:060308:olaf@nlnetlabs.nl::KuqkkYA4u8G4Zlgc:2mKL Date: Wed, 08 Mar 2006 10:00:35 +0100 In-Reply-To: <200603071423.k27ENa5d025383@cichlid.raleigh.ibm.com> (Thomas Narten's message of "Tue, 07 Mar 2006 09:23:35 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Thomas Narten writes: > IMO, Section 5.2 is completely misguided. Here, we have the classic > case of a "requirements document" trying to pick (or exclude) a > particular solution, in advance of actually working on a solution. But > the approach being used is a hammer (e.g., "no IPR is acceptable"), > when at the end of the day, we'd be better off doing an evaluation of > the specific case at hand, and making a decision based on the > available information. > > I believe I understand what the above section is attempting to > achieve. And I support that general goal. > > But, the WG would be a lot better off taking each IPR claim as it > stands. Look at the technology, look at the IPR issues, and then > simply decide (on a case-by-case basis), does the WG want to adopt the > technology, or does it want to (try to) route around it and use > something different? The only way to answer this question (as > engineers -- where one weighs the pros and cons) is to evaluate two > proposals, one with the IPR, and one that is believed to route around > it. If the latter is an adequate technical solution, the WG should > just go for it. If not, it needs to reevaluate its options. This is very convincing, and have made me change my opinion. I now support c) and believe that we should review patent entanglement on a case-by-case basis. It seems the arguments for a) and b) are now more slanted towards making sure Thierry's proposal is disqualified without review, and I believe that is unprofessional. If text related to this is adopted, I'd prefer if my proposed changes were applied, though. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 08 04:05:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGuc1-0008SL-CY for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 04:05:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGuc0-0008Um-0N for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 04:05:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGuaj-0008Yh-NB for namedroppers-data@psg.com; Wed, 08 Mar 2006 09:04:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGuag-0008Y3-66 for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 09:04:18 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2894FWG069247; Wed, 8 Mar 2006 10:04:15 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <1C82E71AF96301D0D4EE9C81@[10.20.30.41]> References: <1C82E71AF96301D0D4EE9C81@[10.20.30.41]> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-62-292703674" Message-Id: <83515255-C25A-4E2B-8BD3-9249BC17BEF5@NLnetLabs.nl> Cc: Paul Vixie Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Wed, 8 Mar 2006 10:04:20 +0100 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-62-292703674 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > >> and here's my answer. count me as (b). argumentation as above. >> patch >> is: > > I think Paul has it right. So count me as (b) with his patch too. Paul's text as the property that it does not mention the specific licenses; that does remove one the topics we are ratholing on (I do not think this working group should try to figure out what is the better license BSD, GPL2 or GPL3). Paul's premisses is that we had consented on the "mandatory-to- implement" part of the key-rollover. The exact RFC2119 form (MUST, SHOULD or MAY NOT implement) of that requirement is open to discussion but I think we do consent to the spirit of the "mandatory- to-implement" part; "mandatory-to-implement" should be in between quotes indeed. So in order to try and reach convergence --- which is incredibly difficult --- Are there more takers for this position? Remember that we are looking for rough consensus; please put some water with your wine for the sake of progress. Is this a text you can consent with: > > 5.2 No Intellectual Property Encumbrance > > Because trust anchor rollover is considered "mandatory-to- > implement", > section 8 of [RFC3979] requires that the technology solution > chosen must > be unencumbered or must be available under royalty-free terms. > > For this purpose, "royalty-free" is defined as follows: world > wide, > perpetual right to use, without fee, in commerce or otherwise, > where "use" > includes descriptions of algorithms, distribution and/or use of > hardware > implementations, distribution and/or use of software systems in > source > and/or binary form, in all DNS or DNSSEC applications including > registry, > registrar, domain name service including authority, recursion, > caching, > forwarding, stub resolver, or similar. > > In summary, no implementor, distributor, or operator of the > technology > chosen for trust anchor management shall be expected or > required to pay > any fee to any IPR holder for the right to implement, > distribute, or > operate a system which includes the chosen mandatory-to-implement > solution. > --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-62-292703674 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEDp4UtN/ca3YJIocRAmRrAKCZKGVA67b4H7m5/uGHPN/sdgRA+ACfQ/UA K5SYc+/oXyQL6R/JrGZMNMM= =338O -----END PGP SIGNATURE----- --Apple-Mail-62-292703674-- -- to unsubscribe send a message to namedroppers-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 Mar 08 05:08:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGvau-0005rl-Fy for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 05:08:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGvat-0002l6-0i for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 05:08:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGvXb-000D64-H1 for namedroppers-data@psg.com; Wed, 08 Mar 2006 10:05:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGvXY-000D4P-90 for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 10:05:08 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k28A4rt1038270; Wed, 8 Mar 2006 05:04:54 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <83515255-C25A-4E2B-8BD3-9249BC17BEF5@NLnetLabs.nl> References: <1C82E71AF96301D0D4EE9C81@[10.20.30.41]> <83515255-C25A-4E2B-8BD3-9249BC17BEF5@NLnetLabs.nl> Date: Wed, 8 Mar 2006 05:04:45 -0500 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Cc: Namedroppers , Paul Vixie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da I've been told that my opinions don't count for much because I haven't read everything under the sun pertaining to this issue. (Sorry, I can't afford to become an expert on copyright law this week.) So, for what it's worth, I will just react to this. At 10:04 +0100 3/8/06, Olaf M. Kolkman wrote: >Is this a text you can consent with: Short answer is no. >> 5.2 No Intellectual Property Encumbrance >> >> Because trust anchor rollover is considered "mandatory-to-implement", >> section 8 of [RFC3979] requires that the technology solution chosen must >> be unencumbered or must be available under royalty-free terms. The first paragraph is okay. >> For this purpose, "royalty-free" is defined as follows: world wide, >> perpetual right to use, without fee, in commerce or otherwise, where "use" >> includes descriptions of algorithms, distribution and/or use of hardware >> implementations, distribution and/or use of software systems in source >> and/or binary form, in all DNS or DNSSEC applications including registry, >> registrar, domain name service including authority, recursion, caching, >> forwarding, stub resolver, or similar. The second paragraph I strongly (but arguing from weakness) object to. I am sure that there is a more reliable definition of "royalty-free" than what a bunch of DNS engineers can come up with on this mailing list. As much as we don't like middle-boxes implementing subsets of the DNS protocol (such as fire-walls that don't parse EDNS0 correctly), we shouldn't try to hack at legal and economic concepts in the same manner. E.g., http://en.wikipedia.org/wiki/Royalty_free. 'Course, that's in the context of photographic images. >> In summary, no implementor, distributor, or operator of the technology >> chosen for trust anchor management shall be expected or required to pay >> any fee to any IPR holder for the right to implement, distribute, or >> operate a system which includes the chosen mandatory-to-implement >> solution. I would say that our goal is give interoperability every chance to succeed by deriving a solution that anyone is free to implement without having to succumb to the whims of any person or entity not under the auspices of the IETF. I'm being obstinate because this is a topic best handled by legal and economic people, not network engineers. As engineers, we understand interoperabilty, we aren't fluent in "right to implement..." kind of concepts, or what "pay any fee" means to the limits of the law. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 08 07:08:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGxSx-00072I-Mn for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 07:08:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGxSw-0006o6-Aj for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 07:08:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGxPr-000Lld-M0 for namedroppers-data@psg.com; Wed, 08 Mar 2006 12:05:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [209.5.206.8] (helo=r1.mycybernet.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGxPq-000LlQ-Na for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 12:05:19 +0000 Received: from 227-54-222-209.mycybernet.net ([209.222.54.227]:50712 helo=phlogiston.dydns.org) by r1.mycybernet.net with esmtp (Exim 4.50 (FreeBSD)) id 1FGxPp-000Pnf-6U for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 07:05:17 -0500 Received: by phlogiston.dydns.org (Postfix, from userid 1000) id 5E9D14040; Wed, 8 Mar 2006 07:05:16 -0500 (EST) Date: Wed, 8 Mar 2006 07:05:16 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <20060308120516.GA4381@phlogiston.dyndns.org> References: <200603071423.k27ENa5d025383@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f This is my response to the request for a consensus call on the proposed text: > 5.2 No Intellectual Property Encumbrance > The solution SHOULD not have any intellectual > property encumbrance on either the technologies > used by the solution nor implementations > of the solution. > The solution MUST be covered by one of options > (a) or (c) of section 6.5 of [RFC3979]. If the > technology is covered by option (a), the license SHOULD > be compatible with the BSD open source license I am persuaded by the argument that, there being remarkably few lawyers among us, we should not get into the business of defining what royalty-free, or non-discriminatory, or other such words mean. But I remain convinced that it is a good idea to make explicit that option (b) of RFC 3979, section 6.5 is not a viable option in this case. So I would prefer (as others have suggested) that the last sentence of paragraph two be removed, but that the text otherwise stays as above. We can then leave it open to consensus what might qualify as "otherwise reasonable and non-discriminatory license". A -- Andrew Sullivan | ajs@crankycanuck.ca A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton -- to unsubscribe send a message to namedroppers-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 Mar 08 08:56:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGz97-0006Pd-59 for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 08:56:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGz96-0001ut-GV for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 08:56:09 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGz4v-0004SD-9C for namedroppers-data@psg.com; Wed, 08 Mar 2006 13:51:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGz4u-0004S2-HI for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 13:51:48 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k28DpAdR012293 for ; Wed, 8 Mar 2006 08:51:10 -0500 (EST) Received: from unknown(158.69.81.107) by nutshell.tislabs.com via csmap (V6.0) id srcAAARwaWYx; Wed, 8 Mar 06 08:50:36 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3561AB98-44A5-4901-ACFC-7C85EB567896@tislabs.com> Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: DNSSEC Validator API Date: Wed, 8 Mar 2006 08:51:11 -0500 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b An initial version of the DNSSEC validator API draft is available from the Internet-Drafts repository. This API is based on our implementation of the validator library and our experiences with building DNSSEC-aware applications that make use of its functions. Comments are most welcome! Suresh > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : DNSSEC Validator API > Author(s) : A. Hayatnagarkar, S. Krishnaswamy > Filename : draft-hayatnagarkar-dnsext-validator-api-00.txt > Pages : 20 > Date : 2006-3-2 > > The DNS Security Extensions (DNSSEC) provide origin authentication > and integrity of DNS data. However, the current resolver API does > not allow a security-aware resolver to communicate detailed results > of DNSSEC processing back to the application. This document > describes an Application Programming Interface between applications > and a validating security-aware stub resolver that allows > applications to control the validation process and obtain > results of > DNSSEC processing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hayatnagarkar-dnsext- > validator-api-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 Wed Mar 08 10:30:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0c6-0008Ez-5U for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 10:30:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH0c4-0005Td-T2 for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 10:30:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH0Zg-000CM4-EK for namedroppers-data@psg.com; Wed, 08 Mar 2006 15:27:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH0Zf-000CLq-Dz for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 15:27:39 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k28FRQwd039618 for ; Wed, 8 Mar 2006 10:27:26 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k28FRPEB039617 for namedroppers@ops.ietf.org; Wed, 8 Mar 2006 10:27:25 -0500 (EST) (envelope-from namedroppers) Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FGdvL-000EJR-Rb for namedroppers@ops.ietf.org; Tue, 07 Mar 2006 15:16:32 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k27FFs2Q001790 for ; Tue, 7 Mar 2006 10:15:54 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQnaWAd; Tue, 7 Mar 06 10:15:42 -0500 Received: from albook.sp.vb.futz.org (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k27FDeqa008182; Tue, 7 Mar 2006 10:13:40 -0500 (EST) Date: Tue, 7 Mar 2006 10:15:24 -0500 From: Robert Story To: "Olaf M. Kolkman" Cc: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Message-ID: <20060307101524.193c1b77@albook.sp.vb.futz.org> In-Reply-To: References: <440B18B2.2040500@connotech.com> Organization: SPARTA X-Mailer: Sylpheed-Claws 2.0.0 (GTK+ 2.6.10; powerpc-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_4UWp3Z6h3BPwV=+xqPiwJOi"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Scanned-By: MIMEDefang 2.54 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] --Sig_4UWp3Z6h3BPwV=+xqPiwJOi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 7 Mar 2006 09:48:06 +0100 Olaf wrote: OMK> I'd like to ask participants to state on-list OMK>=20 OMK> a: That they consent with section 5.2 as above. Yes. --=20 Robert Story SPARTA --Sig_4UWp3Z6h3BPwV=+xqPiwJOi Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEDaOR7/fVLLY1mngRArSDAKCNDn8o7lpUn8zNKnXI5epdcPco3wCdG375 5b0gWtBpBAv6xP8Opi2Hw0Q= =jU8i -----END PGP SIGNATURE----- --Sig_4UWp3Z6h3BPwV=+xqPiwJOi-- -- to unsubscribe send a message to namedroppers-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 Mar 08 10:45:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0qm-0008Jd-KD for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 10:45:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH0ql-0005vH-BG for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 10:45:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH0ok-000Ddy-9A for namedroppers-data@psg.com; Wed, 08 Mar 2006 15:43:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_BOGONS autolearn=no version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH0oi-000Ddk-SL for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 15:43:13 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k28Fh9Ht014650; Wed, 8 Mar 2006 16:43:09 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-76-316634865" Message-Id: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Reminder: WGLC dnssec-experiments and dnssec-opt-in Date: Wed, 8 Mar 2006 16:43:11 +0100 To: "Olaf M. Kolkman" X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-76-316634865 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Before people forget that we are collecting statements for dnssec- experiments, here is a reminder. > This working group last call will terminate March 15. We request at > least 5 people to state that they thoroughly read said documents > before we forward to the IESG. We have not reached a head count of 5 yet. One more week for review! --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-76-316634865 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEDvuQtN/ca3YJIocRAqyLAKCd++BJPcPlRbKcBKlP5FYe+9ij0wCg3La8 ULqQkOFSH/uauE7A0pYaMn8= =sIeH -----END PGP SIGNATURE----- --Apple-Mail-76-316634865-- -- to unsubscribe send a message to namedroppers-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 Mar 08 11:04:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH19U-0005mG-SS for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 11:04:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH19T-0006iy-Gs for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 11:04:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH16n-000FPL-6N for namedroppers-data@psg.com; Wed, 08 Mar 2006 16:01:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH16k-000FOa-Fv; Wed, 08 Mar 2006 16:01:50 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 08 Mar 2006 16:01:49 +0000 X-IronPort-AV: i="4.02,176,1139184000"; d="scan'208"; a="3038146:sNHT27446500" In-Reply-To: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> To: "Olaf M. Kolkman" Cc: Namedroppers , "Olaf M. Kolkman" , owner-namedroppers@ops.ietf.org Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 Message-ID: From: "Roy Arends" Date: Wed, 8 Mar 2006 17:00:25 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 03/08/2006 04:00:26 PM, Serialize complete at 03/08/2006 04:00:26 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 owner-namedroppers@ops.ietf.org wrote on 08-03-2006 16:43:11: > Before people forget that we are collecting statements for dnssec- > experiments, here is a reminder. > > > > This working group last call will terminate March 15. We request at > > least 5 people to state that they thoroughly read said documents > > before we forward to the IESG. > > > We have not reached a head count of 5 yet. One more week for review! I will review dnssec-experiments and will send comments (if any). Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 08 11:11:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1Fy-0002ub-GZ for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 11:11:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1Fw-0006rI-SC for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 11:11:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH1E3-000G8u-V4 for namedroppers-data@psg.com; Wed, 08 Mar 2006 16:09:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH1E2-000G8b-S7 for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 16:09:23 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k28G9Ghi017375 for ; Wed, 8 Mar 2006 11:09:18 -0500 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id k28G8dDe002079 for ; Wed, 8 Mar 2006 11:08:39 -0500 (EST) From: "Scott Rose" To: "Namedroppers" Subject: RE: Reminder: WGLC dnssec-experiments and dnssec-opt-in Date: Wed, 8 Mar 2006 11:08:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 I read previous versions of these drafts. I will go over them again. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf M. Kolkman > Sent: Wednesday, March 08, 2006 10:43 AM > To: Olaf M. Kolkman > Cc: Namedroppers > Subject: Reminder: WGLC dnssec-experiments and dnssec-opt-in > > > > > Before people forget that we are collecting statements for dnssec- > experiments, here is a reminder. > > > > This working group last call will terminate March 15. We request at > > least 5 people to state that they thoroughly read said documents > > before we forward to the IESG. > > > We have not reached a head count of 5 yet. One more week for review! > > > --Olaf > > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > > -- to unsubscribe send a message to namedroppers-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 Mar 08 11:13:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1Ho-00055X-BL for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 11:13:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1Hm-0006up-VX for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 11:13:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH1GT-000GTo-LX for namedroppers-data@psg.com; Wed, 08 Mar 2006 16:11:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH1GS-000GTZ-Qg for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 16:11:52 +0000 Received: from ngarcha.fugue.com (dsl093-162-134.tus1.dsl.speakeasy.net [66.93.162.134]) (using SSLv3 with cipher EXP1024-RC4-SHA (56/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 4BF4956823; Wed, 8 Mar 2006 08:11:52 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: "Olaf M. Kolkman" Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Wed, 8 Mar 2006 09:11:51 -0700 User-Agent: KMail/1.9.1 Cc: Namedroppers , Paul Vixie References: <1C82E71AF96301D0D4EE9C81@[10.20.30.41]> <83515255-C25A-4E2B-8BD3-9249BC17BEF5@NLnetLabs.nl> In-Reply-To: <83515255-C25A-4E2B-8BD3-9249BC17BEF5@NLnetLabs.nl> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200603080911.51827.Ted.Lemon@nominum.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Wednesday 08 March 2006 02:04, Olaf M. Kolkman wrote: > So in order to try and reach convergence --- which is incredibly   > difficult --- Are there more takers for this position? I'm perfectly happy with Paul's section instead of yours; I'm also perfectly happy with yours. I don't think either one is "unprofessional." The point is not to exclude "Thierry's proposal." The point is to say what kind of IPR restrictions the working group is willing to accept on any protocol specification for a piece of technology that is be needed in some form or other in order for the whole protocol suite to be useful to users of the Internet: the people whom we ultimately serve when we do work for the IETF. -- to unsubscribe send a message to namedroppers-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 Mar 08 11:46:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1nk-0006vc-EF for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 11:46:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1ni-0007xC-WC for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 11:46:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH1kZ-000JA4-4Q for namedroppers-data@psg.com; Wed, 08 Mar 2006 16:42:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH1kX-000J9l-Sc for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 16:42:58 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00191D; 8 Mar 2006 11:42:42 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 8 Mar 2006 11:42:24 -0500 Received: from connotech.com (209.71.204.116) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00191C; 8 Mar 2006 11:42:21 -0500 Message-ID: <440F1257.3040704@connotech.com> Date: Wed, 08 Mar 2006 12:20:23 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Namedroppers Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in References: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> In-Reply-To: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Dear Olaf: I reviewed (thoroughly read and assessed it) draft-ietf-dnsext-dnssec-experiments-02.txt. I have no objection that it proceeds. So you may count me as a reviewer who accepts this draft to be forwarded to the IESG. Olaf M. Kolkman wrote: -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 08 12:19:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2JX-0004zM-DR for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 12:19:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2JW-0000j5-39 for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 12:19:07 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH2H0-000MAh-24 for namedroppers-data@psg.com; Wed, 08 Mar 2006 17:16:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH2Gz-000MAP-0h for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 17:16:29 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO00192E; 8 Mar 2006 12:16:13 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 8 Mar 2006 12:15:57 -0500 Received: from connotech.com (209.71.204.116) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG00192D; 8 Mar 2006 12:15:54 -0500 Message-ID: <440F1A33.7050507@connotech.com> Date: Wed, 08 Mar 2006 12:53:55 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <440B18B2.2040500@connotech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Olaf M. Kolkman wrote: > > Since this is one of the issues that can drag on forever if we are not > careful I propose some process that sets a timeline to this discussion. > > Please respond by mail, try not to go into battle over arguments, state > your own arguments once and trust others to be able to read. > > Please remain courteous and civil. Please respect the motivations for > peoples opinions. > If I read correctly some ot the other opinions, the clause 5.2 should state a *principle* by which the wg will address IPR issues, for a broader scope than just trust anchor key automated rollover, and asking more determinism in the IPR status of ietf specifications than that what has been anticipated by the authors of RFC3979. In order to support the opposite view that each IPR situation should be considered on its own merit, background, etc. I submit the following factual argument: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=624 see also http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220020152382%22.PGNR.&OS=DN/20020152382&RS=DN/20020152382 You may call this the "DS RR patent pending issue". I have absolutely no association, neither directly nor indirectly, with this United States Patent Application 20020152382, its inventor(s), owner(s), assignee(s), or agent(s). It is unfortunate that my name pops up in the title of this ietf IPR detail page: there seems to be a hidden reputation cost in good faith behavior suggested by RFC3979 (Please carry any discussion on this sentence in the appropriate IPR wg forum, i.e. ipr-wg@ietf.org). Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 08 12:53:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2rB-0003pB-Vy for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 12:53:53 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2rA-0002C9-NB for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 12:53:53 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH2no-000P4b-KM for namedroppers-data@psg.com; Wed, 08 Mar 2006 17:50:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [158.69.80.164] (helo=hobbes.columbia.sparta.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH2nm-000P4O-2F for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 17:50:22 +0000 Received: from [157.185.80.164] (localhost [127.0.0.1]) by hobbes.columbia.sparta.com (Postfix) with ESMTP id 083D93B9843; Wed, 8 Mar 2006 12:50:20 -0500 (EST) Date: Wed, 8 Mar 2006 12:50:18 -0500 From: Russ Mundy Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft To: Edward Lewis Cc: "Olaf M. Kolkman" , Namedroppers , Paul Vixie X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.1.5 (Blindsider) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On 3/8/06 at 5:04 AM -0500, Edward Lewis wrote: -------------- snip -------------- > >>> 5.2 No Intellectual Property Encumbrance >>> >>> Because trust anchor rollover is considered "mandatory-to-implement", >>> section 8 of [RFC3979] requires that the technology solution chosen mu= st >>> be unencumbered or must be available under royalty-free terms. > >The first paragraph is okay. > --------- snip ------------------ Editor hat ON My impression was that the requirement in section 5.6 _removed_ automated k= ey rollover from being a "mandatory-to-implement". =20 I think that those speaking for the NOT mandatory-to-implement position wer= e present in the Vancouver WG meeting but I have not seen any statements to t= hat effect on the list. We may need to have statements either way on the 'mandatory-to-implement' requirement. Should this be Issue 2?? Russ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 08 12:54:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH2rf-0004FM-5M for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 12:54:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH2re-0002Co-KZ for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 12:54:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH2oz-000PCV-1N for namedroppers-data@psg.com; Wed, 08 Mar 2006 17:51:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [32.97.182.141] (helo=e1.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH2oy-000PCK-6B for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 17:51:36 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k28HpYWe006273 for ; Wed, 8 Mar 2006 12:51:34 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k28HoYvM196636 for ; Wed, 8 Mar 2006 12:50:34 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k28HoYx1031660 for ; Wed, 8 Mar 2006 12:50:34 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k28HoYJb031633; Wed, 8 Mar 2006 12:50:34 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k28HoXl1031095; Wed, 8 Mar 2006 12:50:33 -0500 Message-Id: <200603081750.k28HoXl1031095@rotala.raleigh.ibm.com> To: "Olaf M. Kolkman" cc: Namedroppers Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: Message from olaf@NLnetLabs.nl of "Wed, 08 Mar 2006 16:43:11 +0100." <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> Date: Wed, 08 Mar 2006 12:50:33 -0500 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 > > This working group last call will terminate March 15. We request at > > least 5 people to state that they thoroughly read said documents > > before we forward to the IESG. High-level, coming from someone who may not be terrible DNSSEC savvy. I'm a bit confused about exactly what one is testing under this methodology. There is a lot of discussion about using a private algorithm, in which case those not participating in the experiment will simply not recognize the signature and ignore it. That part seems fine. But, what exactly is being tested here? Is it real modifications to the DNS protocols (i.e., changing/extending semantics of existing operatiosn)? Or is it _just_ experimenting with a new signing algorithm? Is the idea that knowing the private algorithm (which often isn't really an unknown algorithm, since the purpose apparently isn't to test new algorithms) provides a way of indicating that "the DNS protocol behaves differently for names in this zone"? It might help to show a concrete example of an example extension (e.g., a past proposal) that could be tested using this scheme. Specific comments: abstract says: > In the long history of the development of the DNS security extensions > [1] (DNSSEC), a number of alternate methodologies and modifications > have been proposed and rejected for practical, rather than strictly > technical, reasons. There is a desire to be able to experiment with > these alternate methods in the public DNS. This document describes a > methodology for deploying alternate, non-backwards-compatible, DNSSEC > methodologies in an experimental fashion without disrupting the > deployment of standard DNSSEC. IMO, the first sentence can be struck completely, as it adds nothing to the purpose of the document. I also don't like the wording, since I don't know the difference between "technical" and "practical" reasons. > For example, an experiment might specify in its description the DNS > name "dnssec-experiment-a.example.com" as the base name, and provide > the mapping of "3.dnssec-experiment-a.example.com" is an alias of parsing problem??? Perhaps: s/and provide the mapping of/and declare that/ > DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is > an alias of DNSSEC algorithm 5 (RSASHA1). same issue. > Resolvers MUST then only recognize the experiment's semantics when > present in a zone signed by one or more of these private algorithms. Awkword wording (and I am not sure at all MUST is appropriate here, or indeed what it is that is intended to be said here.) Do you mean something like: Only resolvers participating in the experiment would recognize the experiment's semantics when present in a zone signed by one or more of these private algorithms. > 6. Considerations > > There are a number of considerations with using this methodology. > > 1. Under some circumstances, it may be that the experiment will not > be sufficiently masked by this technique and may cause resolution > problem for resolvers not aware of the experiment. For instance, > the resolver may look at the not validatable response and > conclude that the response is bogus, either due to local policy > or implementation details. This is not expected to be the common > case, however. Odd to say this, since the above is essentially a violation of existing specs, as indicated earlier. Right? > 2. It will not be possible for DNSSEC-aware resolvers not aware of > the experiment to build a chain of trust through an experimental > zone. Can't an experimental zone co-exist with a regular zone (i.e., one using a standard signature)? If so, the above wording seems wrong. > 7. Transitions > > If an experiment is successful, there may be a desire to move the > experiment to a standards-track extension. One way to do so would be > to move from private algorithm numbers to IANA allocated algorithm > numbers, with otherwise the same meaning. This would still leave a > divide between resolvers that understood the extension versus > resolvers that did not. It would, in essence, create an additional > version of DNSSEC. This is funny defn. of "version". [note: I think answering earlier question will clarify my confusion here.] > 9. IANA Considerations > > IANA may need to allocate new DNSSEC algorithm numbers if that > transition approach is taken, or the experiment decides to use > allocated numbers to begin with. No IANA action is required to > deploy an experiment using private algorithm identifiers. Better (for IANA, and for this document): This document provides a way of experimenting with DNSSEC using the existing DNSSEC Private Algorithm Identifier space. No coordination with IANA is needed. This document has no IANA actions. -- to unsubscribe send a message to namedroppers-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 Mar 08 13:16:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3Ct-0007yg-K3 for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:16:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3Cs-00036t-B7 for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:16:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3Al-0001He-T7 for namedroppers-data@psg.com; Wed, 08 Mar 2006 18:14:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,SPF_FAIL autolearn=no version=3.1.0 Received: from [216.168.239.87] (helo=ns1.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3Ak-0001HJ-Ma for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 18:14:06 +0000 Received: from localhost.localdomain (roadie [127.0.0.1]) by ns1.verisignlabs.com (8.12.11/8.12.8) with ESMTP id k28IE3tB007468; Wed, 8 Mar 2006 13:14:03 -0500 Received: (from markk@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id k28IE3SM007467; Wed, 8 Mar 2006 13:14:03 -0500 Date: Wed, 8 Mar 2006 13:14:03 -0500 From: Mark Kosters To: "Olaf M. Kolkman" Cc: Namedroppers Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in Message-ID: <20060308181403.GI4083@verisignlabs.com> References: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Wed, Mar 08, 2006 at 04:43:11PM +0100, Olaf M. Kolkman wrote: > Before people forget that we are collecting statements for dnssec- > experiments, here is a reminder. > > > >This working group last call will terminate March 15. We request at > >least 5 people to state that they thoroughly read said documents > >before we forward to the IESG. > > > We have not reached a head count of 5 yet. One more week for review! I have thoroughly read these both of these documents* and think they are ready to send to the IESG. Regards, Mark *I'm one of the co-authors of draft-ietf-dnsext-dnssec-opt-in-08. -- Mark Kosters markk@verisignlabs.com VeriSign -- to unsubscribe send a message to namedroppers-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 Mar 08 13:29:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3PL-0003HY-Lt for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:29:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3PL-0003Fw-CN for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:29:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3MD-0002PB-3y for namedroppers-data@psg.com; Wed, 08 Mar 2006 18:25:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3MC-0002Oz-2u for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 18:25:56 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k28IPHl9003805 for ; Wed, 8 Mar 2006 13:25:17 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAcAaauh; Wed, 8 Mar 06 13:24:54 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k28IHQqb027596; Wed, 8 Mar 2006 13:17:27 -0500 (EST) Date: Wed, 8 Mar 2006 13:19:38 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Thomas Narten cc: Namedroppers Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: <200603081750.k28HoXl1031095@rotala.raleigh.ibm.com> Message-ID: References: <200603081750.k28HoXl1031095@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 > But, what exactly is being tested here? Is it real modifications to > the DNS protocols (i.e., changing/extending semantics of existing > operatiosn)? Or is it _just_ experimenting with a new signing > algorithm? Is the idea that knowing the private algorithm (which > often isn't really an unknown algorithm, since the purpose > apparently isn't to test new algorithms) provides a way of > indicating that "the DNS protocol behaves differently for names in > this zone"? > > It might help to show a concrete example of an example extension > (e.g., a past proposal) that could be tested using this scheme. It is _not_ just experimenting with new algorithms, nor is it for experiments with non-DNSSEC parts of the protocol. We're talking about experimenting with DNSSEC flavors, extensions, and bad ideas. The unknown algorithm tells DNSSEC-aware resolvers that aren't part of the experiment "you don't know what's going on here -- just ignore any DNSSEC bits you see in this zone and treat it as unsigned". Classic examples include NSEC3 and opt-in. We MIGHT have been able to use this method to test DS (RFC3658). We could also use this method to signal a change in typecodes (RFC3755), though the new typecodes would probably be used as part of some larger experiment (like NSEC3). > > 2. It will not be possible for DNSSEC-aware resolvers not aware of > > the experiment to build a chain of trust through an > > experimental zone. > > Can't an experimental zone co-exist with a regular zone (i.e., one > using a standard signature)? If so, the above wording seems wrong. In general, no. There is only one zone. It may use no DNSSEC, "standard" DNSSEC, or some "experimental" DNSSEC. It may be that the extension is backwards compatible, allow a zone to be validated by both "standard" and "experimental" resolvers at the same time, but I imagine that to be an exceptional case. Example: a zone could publish (and return) both NSEC and NSEC3 RR's, potentially allowing it to be validated by both "standard" and "NSEC3" resolvers. But the mechanics of doing that might prove challenging. So the text is a reasonable generalization. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 08 13:33:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3TO-0006Zg-7n for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:33:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3TL-0003Rn-VQ for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:33:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3Ro-00031N-7z for namedroppers-data@psg.com; Wed, 08 Mar 2006 18:31:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3Rm-000317-F2 for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 18:31:42 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 75A1C11D9DD; Wed, 8 Mar 2006 10:31:40 -0800 (PST) From: Wes Hardaker To: Edward Lewis Cc: bmanning@vacation.karoshi.com, "Olaf M. Kolkman" , Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Organization: Sparta References: <440B18B2.2040500@connotech.com> <20060307111049.GB27709@vacation.karoshi.com.> Date: Wed, 08 Mar 2006 10:31:39 -0800 In-Reply-To: (Edward Lewis's message of "Tue, 7 Mar 2006 06:16:39 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 >>>>> On Tue, 7 Mar 2006 06:16:39 -0500, Edward Lewis said: Edward> Great - I'm called "wise" minutes after threatening to glaze my eyes Edward> over, stick my fingers in my ears, hum a tune and dream of a man Edward> page. ;) What's the problem? Your actions sound wise to me. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-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 Mar 08 13:36:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3Wb-00086E-Tx for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:36:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3Wa-0003bk-LP for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:36:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3VG-0003Th-Ux for namedroppers-data@psg.com; Wed, 08 Mar 2006 18:35:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3VG-0003TT-Hz for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 18:35:18 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 2EA4911D9DD; Wed, 8 Mar 2006 10:35:16 -0800 (PST) From: Wes Hardaker To: "Olaf M. Kolkman" Cc: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Organization: Sparta References: <440B18B2.2040500@connotech.com> Date: Wed, 08 Mar 2006 10:35:15 -0800 In-Reply-To: (Olaf M. Kolkman's message of "Tue, 7 Mar 2006 09:48:06 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> On Tue, 7 Mar 2006 09:48:06 +0100, "Olaf M. Kolkman" said: Olaf> I'd like to ask participants to state on-list Olaf> a: That they consent with section 5.2 as above. Olaf> b: They would like to see section 5.2 as above modified. Then send Olaf> argumentation and "patch" (a or b) but not c. There have been many b's floated by, many of which I agree with. -- Wes Hardaker Sparta, Inc. -- to unsubscribe send a message to namedroppers-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 Mar 08 13:40:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3ac-0004xX-4Q for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:40:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3aa-0003kg-Ru for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:40:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3Z1-0003w6-8h for namedroppers-data@psg.com; Wed, 08 Mar 2006 18:39:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3Yz-0003vn-NF for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 18:39:09 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 567B911426 for ; Wed, 8 Mar 2006 18:39:09 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Wed, 08 Mar 2006 12:50:18 EST." References: Date: Wed, 08 Mar 2006 18:39:09 +0000 Message-Id: <20060308183909.567B911426@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 # My impression was that the requirement in section 5.6 _removed_ automated key # rollover from being a "mandatory-to-implement". that would be good news in and of itself, since we (isc) could start pushing for wider deployment, even though it would require DLV and completely miss the NSEC3 wave. # I think that those speaking for the NOT mandatory-to-implement position were # present in the Vancouver WG meeting but I have not seen any statements to # that effect on the list. # # We may need to have statements either way on the 'mandatory-to-implement' # requirement. # # Should this be Issue 2?? i think so, yes. if trust anchor management is not mandatory to implement, then DNSSEC-bis is ready for wide scale deployment, and this whole debate, as well as the NSEC3 technology wave, are way less relevant than we've all been treating 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 Wed Mar 08 13:52:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3lk-00081l-QE for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:52:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3lk-00042F-7L for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 13:52:20 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3j0-000552-So for namedroppers-data@psg.com; Wed, 08 Mar 2006 18:49:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.0 Received: from [32.97.182.142] (helo=e2.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3iz-00054k-4d for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 18:49:29 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k28InRU4012160 for ; Wed, 8 Mar 2006 13:49:27 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k28InSvM224526 for ; Wed, 8 Mar 2006 13:49:28 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k28InSEO017329 for ; Wed, 8 Mar 2006 13:49:28 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k28InRUL017310; Wed, 8 Mar 2006 13:49:27 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k28InRZX031365; Wed, 8 Mar 2006 13:49:27 -0500 Message-Id: <200603081849.k28InRZX031365@rotala.raleigh.ibm.com> To: Sam Weiler cc: Namedroppers Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: Message from weiler@tislabs.com of "Wed, 08 Mar 2006 13:19:38 EST." Date: Wed, 08 Mar 2006 13:49:27 -0500 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Sam Weiler writes: > It is _not_ just experimenting with new algorithms, nor is it for > experiments with non-DNSSEC parts of the protocol. OK. > We're talking about experimenting with DNSSEC flavors, extensions, > and bad ideas. The unknown algorithm tells DNSSEC-aware resolvers > that aren't part of the experiment "you don't know what's going on > here -- just ignore any DNSSEC bits you see in this zone and treat > it as unsigned". And for those resolvers that do understand the particular flavor, it is saying "do flavor X" of DNSSEC here. And since it doesn't make sense to do "normal" DNSSEC and "flavor X" simultaneously, this is what is being described as another "different version" of DNSSEC? > Classic examples include NSEC3 and opt-in. We MIGHT have been able to > use this method to test DS (RFC3658). Only "MIGHT have"? > We could also use this method to signal a change in typecodes > (RFC3755), though the new typecodes would probably be used as part > of some larger experiment (like NSEC3). Again, the basic point here is that "flavor X" can mean whatever "X" is defined to be, and the normal DNSSEC rules don't apply. > > > 2. It will not be possible for DNSSEC-aware resolvers not aware of > > > the experiment to build a chain of trust through an > > > experimental zone. > > > > Can't an experimental zone co-exist with a regular zone (i.e., one > > using a standard signature)? If so, the above wording seems wrong. > In general, no. There is only one zone. It may use no DNSSEC, > "standard" DNSSEC, or some "experimental" DNSSEC. Why can't a zone use both "standard" and "experimental"? I.e., signed different sets of keys/algorithms, as the document says up front? That is, any one resolver choose one or the other (but not both) for a particular zone. If that is the case, both can co-exist, though the defn. of coexistance is maybe different that you are thinking of. > It may be that the extension is backwards compatible, allow a zone > to be validated by both "standard" and "experimental" resolvers at > the same time, but I imagine that to be an exceptional case. > Example: a zone could publish (and return) both NSEC and NSEC3 RR's, > potentially allowing it to be validated by both "standard" and "NSEC3" > resolvers. But the mechanics of doing that might prove challenging. Here is the rub. This technique allows zones to identify extensions that only extension-aware resolvers will process. But it does not really allow DNS servers (e.g., those in zones implementing the experiment) to know they are talking to "experiment-aware" resolvers and thus return answers appropriate for implementors of the experiment (but not others). So there are some clear limitations here. If one has a zone only implement standard DNSSEC or "experimental flavor" DNSSEC, no problem. It might be good for the document to say a bit more about these limitations. Thomas -- to unsubscribe send a message to namedroppers-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 Mar 08 14:09:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH427-0004cN-4A for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 14:09:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH425-0004Wg-7z for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 14:09:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3yV-0006dL-Of for namedroppers-data@psg.com; Wed, 08 Mar 2006 19:05:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH3yU-0006d8-9l for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 19:05:30 +0000 Received: from [213.248.194.112] ([::ffff:213.248.194.112]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Wed, 08 Mar 2006 14:05:28 -0500 id 002C038F.440F2AF8.00002D81 In-Reply-To: <200603081750.k28HoXl1031095@rotala.raleigh.ibm.com> References: <200603081750.k28HoXl1031095@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93E71F27-FA08-41FC-9BDA-5F7236A1C7A8@verisignlabs.com> Cc: "Olaf M. Kolkman" , Namedroppers Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in Date: Wed, 8 Mar 2006 19:05:25 +0000 To: Thomas Narten X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 On Mar 8, 2006, at 5:50 PM, Thomas Narten wrote: >>> This working group last call will terminate March 15. We request at >>> least 5 people to state that they thoroughly read said documents >>> before we forward to the IESG. > > High-level, coming from someone who may not be terrible DNSSEC savvy. No problem, your comments are still appreciated ;) > I'm a bit confused about exactly what one is testing under this > methodology. There is a lot of discussion about using a private > algorithm, in which case those not participating in the experiment > will simply not recognize the signature and ignore it. That part seems > fine. > > But, what exactly is being tested here? Is it real modifications to > the DNS protocols (i.e., changing/extending semantics of existing > operatiosn)? Or is it _just_ experimenting with a new signing > algorithm? Is the idea that knowing the private algorithm (which > often isn't really an unknown algorithm, since the purpose apparently > isn't to test new algorithms) provides a way of indicating that "the > DNS protocol behaves differently for names in this zone"? This document isn't about experimenting with anything in particular. It is describing a methodology for doing an experiment safely, not describing a particular experiment. As for what exactly is being tested: section 3 is an attempt to define the basic boundaries of what sorts of things may be tested. However, I suspect that section 3 is too clumsily stated. > It might help to show a concrete example of an example extension > (e.g., a past proposal) that could be tested using this scheme. Like draft-ietf-dnsext-dnssec-opt-in-08 ? Since this is just documenting an approach for shielding unaware DNSSEC validators from non-backwards-compatible changes to DNSSEC it didn't seem appropriate to point to a particular experiment. > Specific comments: > > abstract says: > >> In the long history of the development of the DNS security >> extensions >> [1] (DNSSEC), a number of alternate methodologies and >> modifications >> have been proposed and rejected for practical, rather than >> strictly >> technical, reasons. There is a desire to be able to experiment >> with >> these alternate methods in the public DNS. This document >> describes a >> methodology for deploying alternate, non-backwards-compatible, >> DNSSEC >> methodologies in an experimental fashion without disrupting the >> deployment of standard DNSSEC. > > IMO, the first sentence can be struck completely, as it adds nothing > to the purpose of the document. I also don't like the wording, since > I don't know the difference between "technical" and "practical" > reasons. Fair enough. How about reducing to just the last sentence? >> For example, an experiment might specify in its description the >> DNS >> name "dnssec-experiment-a.example.com" as the base name, and >> provide >> the mapping of "3.dnssec-experiment-a.example.com" is an alias of > > parsing problem??? > Perhaps: s/and provide the mapping of/and declare that/ Yes, that sentence doesn't make sense, and your modification works fine. >> DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment- >> a.example.com" is >> an alias of DNSSEC algorithm 5 (RSASHA1). > > same issue. Ok. >> Resolvers MUST then only recognize the experiment's semantics when >> present in a zone signed by one or more of these private >> algorithms. > > Awkword wording (and I am not sure at all MUST is appropriate here, or > indeed what it is that is intended to be said here.) Do you mean > something like: > > Only resolvers participating in the experiment would recognize the > experiment's semantics when present in a zone signed by one or > more > of these private algorithms. No, that isn't the intent. The intent is to mandate that a resolver that understands the experimental semantics (e.g., the opt-in flag) only treats the response as signed if and only if the zone was signed only by one or more of the private algorithms. Or, in other words, the resolver must treat the zone as unsigned, even though it could treat the zone as signed. >> 6. Considerations >> >> There are a number of considerations with using this methodology. >> >> 1. Under some circumstances, it may be that the experiment >> will not >> be sufficiently masked by this technique and may cause >> resolution >> problem for resolvers not aware of the experiment. For >> instance, >> the resolver may look at the not validatable response and >> conclude that the response is bogus, either due to local >> policy >> or implementation details. This is not expected to be the >> common >> case, however. > > Odd to say this, since the above is essentially a violation of > existing specs, as indicated earlier. Right? Well, technically no. The existing specs only use "SHOULD". The assertion in section 4 is essentially pointing out that while the specs say "SHOULD", it is effectively (or maybe just believed to be) a MUST. So this is basically a caveat that while this technique is *believed* to work, it might not. OTOH, you can basically read this as "there may be bugs out there", which is, of course, obvious. >> 2. It will not be possible for DNSSEC-aware resolvers not >> aware of >> the experiment to build a chain of trust through an >> experimental >> zone. > > Can't an experimental zone co-exist with a regular zone (i.e., one > using a standard signature)? If so, the above wording seems wrong. No, it can't. > >> 7. Transitions >> >> If an experiment is successful, there may be a desire to move the >> experiment to a standards-track extension. One way to do so >> would be >> to move from private algorithm numbers to IANA allocated algorithm >> numbers, with otherwise the same meaning. This would still >> leave a >> divide between resolvers that understood the extension versus >> resolvers that did not. It would, in essence, create an >> additional >> version of DNSSEC. > > This is funny defn. of "version". [note: I think answering earlier > question will clarify my confusion here.] Really? I'm using "version" in the sense of protocol versioning. Does that not make sense? That sentence is not strictly necessary, so I'll delete it if it is unclear. > >> 9. IANA Considerations >> >> IANA may need to allocate new DNSSEC algorithm numbers if that >> transition approach is taken, or the experiment decides to use >> allocated numbers to begin with. No IANA action is required to >> deploy an experiment using private algorithm identifiers. > > Better (for IANA, and for this document): > > This document provides a way of experimenting with DNSSEC using > the existing DNSSEC Private Algorithm Identifier space. No > coordination with IANA is needed. > > This document has no IANA actions. Well, to be precise, it only RECOMMENDS the use of private algorithms, it does not require them. And, if they aren't used, then IANA would need to allocate DNSSEC algorithm numbers. So, Thomas, are you suggesting that the document REQUIRE use of private algorithm identifiers? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 08 16:51:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Yq-0007UO-6J for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 16:51:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6Yo-0001ZK-BA for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 16:51:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH6VB-000Lxr-Kg for namedroppers-data@psg.com; Wed, 08 Mar 2006 21:47:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH6VA-000Lxc-1Z for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 21:47:24 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k28LlJgl025033 for ; Wed, 8 Mar 2006 16:47:20 -0500 Received: from gorilla ([129.6.220.42]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id k28LkvDd013754 for ; Wed, 8 Mar 2006 16:46:58 -0500 (EST) From: "Scott Rose" To: "Namedroppers" Subject: RE: Reminder: WGLC dnssec-experiments and dnssec-opt-in Date: Wed, 8 Mar 2006 16:47:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I have finished going over the documents. I do not have any objections to both drafts proceeding. Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Olaf M. Kolkman > Sent: Wednesday, March 08, 2006 10:43 AM > To: Olaf M. Kolkman > Cc: Namedroppers > Subject: Reminder: WGLC dnssec-experiments and dnssec-opt-in > > > > > Before people forget that we are collecting statements for dnssec- > experiments, here is a reminder. > > > > This working group last call will terminate March 15. We request at > > least 5 people to state that they thoroughly read said documents > > before we forward to the IESG. > > > We have not reached a head count of 5 yet. One more week for review! > > > --Olaf > > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > > -- to unsubscribe send a message to namedroppers-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 Mar 08 17:05:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6mp-0007qH-7H for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 17:05:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6mn-0003FF-HC for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 17:05:39 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH6ks-000NZs-Kl for namedroppers-data@psg.com; Wed, 08 Mar 2006 22:03:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH6kr-000NZc-Fv for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 22:03:37 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k28M2pf6006639; Wed, 8 Mar 2006 17:02:51 -0500 (EST) Received: from unknown(158.69.81.107) by nutshell.tislabs.com via csmap (V6.0) id srcAAAkta48m; Wed, 8 Mar 06 17:02:48 -0500 In-Reply-To: References: <440B18B2.2040500@connotech.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A4B74AD-D30F-4F5B-A401-71906A6C29B6@tislabs.com> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Wed, 8 Mar 2006 17:03:24 -0500 To: "Olaf M. Kolkman" X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c I vote in favor of > c: They would like to see any mention of IPR dropped from the > requirements. However, I _would_ like to see the scope of '5.3 General Applicability' expanded to say something along the lines of "the technology must be globally implementable and usable without bias. " Suresh -- to unsubscribe send a message to namedroppers-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 Mar 08 17:23:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH73x-0002wW-1i for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 17:23:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH73v-0004YN-JM for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 17:23:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH71e-000PM0-BJ for namedroppers-data@psg.com; Wed, 08 Mar 2006 22:20:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH71d-000PLm-7C for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 22:20:57 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k28MKD6c008815; Wed, 8 Mar 2006 17:20:13 -0500 (EST) Received: from unknown(158.69.81.107) by nutshell.tislabs.com via csmap (V6.0) id srcAAAp5aOkr; Wed, 8 Mar 06 17:20:07 -0500 In-Reply-To: <440B18B2.2040500@connotech.com> References: <440B18B2.2040500@connotech.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85DBC0C3-148B-4E5C-A129-64C50AC06DF7@tislabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Wed, 8 Mar 2006 17:20:43 -0500 To: Thierry Moreau X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Once we do get down to comparing different proposals against the set of requirements its quite possible that we may find each approach lacking in some respect. I don't think the intent of the requirements document was to impose an "a-priori option abandonment formulation" of any one approach. From what I understand, its a collection of requirements that the working group *itself* has proposed at some point or the other. Its really up to the working group to decide the order in which these requirements are important in order to identify the "preferred" solution. Suresh On Mar 5, 2006, at 11:58 AM, Thierry Moreau wrote: > Dear all: > > This message discusses the implications of a no-IPR encumberment > requirement for trust anchor key rollover in DNSSEC, being > considered by ietf dnsext wg in section 5.2 in > draft-ietf-dnsext-rollover-requirements-00.txt. > > First of all, here is a relevant citation from an ietf wg process > perspective, from RFC 3668 section 8: > "But IETF working groups have the discretion to adopt > technology with a commitment of fair and non-discriminatory > terms, or even with no licensing commitment, if they feel > that this technology is superior enough to alternatives with > fewer IPR claims or free licensing to outweigh the potential > cost of the licenses." > > In other words, there exists an *opportunity* for an IETF wg to > evaluate alternate technologies in the presence of IPR claims. > The current wording of section 5.2 in > draft-ietf-dnsext-rollover-requirements-00.txt is an a-priori > option abandonment formulation. > > In rational terms, a person or organization having an option > would not renounce of it or abandon it earlier than the option > exercise time. In saying e.g. "... in applying the discretion > granted by RFC3668 section 8, as the case may be, the evaluation > process should assign heavy ponderation to IPR hindrance ..." the > wg governance would have kept its options open and, at the same > time, give a clear indication for its future solution assessment. > A working group is a political entity to which a single-actor > rationale behavior model does not always apply. > > Why did the editors of > draft-ietf-dnsext-rollover-requirements-00.txt jumped into the a- > priori option abandonment formulation in the drafting of section > 5.2? I suggest the following answer: the editors (or someone who > influenced them) saw that an IPR-encumbered solution was > technologically superior to another one that they preferred, so > an a-priori abandonment strategy would fit their own purpose. If > the IPR-encumbered technology is inferior or even equal to the > free and preferred alternative, the a-priori option abandonment > would have no appeal to the proposer. > > Then why nobody in the community yet objected to the a-priori > option abandonment (once proposed)? Suppose DNSSEC has a greater > than negligible value for some participants. A rational behavior > would be to optimize its implementation, given the engineering > constraints. If such participant has no bias for a trust anchor > key solution, he/she would normally argue against an a-priori > option abandonment. > > In the present case, trust anchor key configuration is the very > first thing to do when a DNSSEC-aware resolver is installed. The > need for rollover comes from the need to preserve security over > time (i.e. maintaining the end-to-end cryptographic assurance > about data retrieved from the DNS). It is thus somehow linked to > the DNSSEC implementation optimization in the previous paragraph. > > So there are two possible conclusions: a) some active > participants are biased towards a free alternative that they are > satisfied with, and/or b) no remaining active participants see > value in DNSSEC to the point where its implementation > optimization is worth some efforts. > > Having reviewed the DNSSEC deployment issues, I think DNSSEC is > almost worthless. So the dnsext active participants would be > justified to let the requirement draft proceed with the a-priori > option abandonment formulation of section 5.2. A separate message > is posted about "DNSSEC is almost worthless!" > > Does anybody knows why DNSSEC deployment would be significantly > valuable but keeping open an option (to study an IPR-encumbered > implementation alternative) should be banned? > > Regards, > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau@connotech.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 Wed Mar 08 18:41:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH8Hv-0003C3-9b for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 18:41:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH8Ht-0008Ri-R7 for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 18:41:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH8Fk-0006Hz-6M for namedroppers-data@psg.com; Wed, 08 Mar 2006 23:39:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH8Fj-0006He-0s for namedroppers@ops.ietf.org; Wed, 08 Mar 2006 23:39:35 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 686CE56823; Wed, 8 Mar 2006 15:39:34 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060308183322.07cdf588@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 08 Mar 2006 18:40:55 -0500 To: Thierry Moreau , "Olaf M. Kolkman" From: Mike StJohns Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Cc: Namedroppers In-Reply-To: <440F1A33.7050507@connotech.com> References: <440B18B2.2040500@connotech.com> <440F1A33.7050507@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 With respect to DS - this patent (or application) is invalid on its face. The original DS draft was dated May 2001 - 18 months prior to the date of the patent application. At 12:53 PM 3/8/2006, Thierry Moreau wrote: >In order to support the opposite view that each IPR situation should >be considered on its own merit, background, etc. I submit the >following factual argument: > >https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=624 > >see also > >http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220020152382%22.PGNR.&OS=DN/20020152382&RS=DN/20020152382 > >You may call this the "DS RR patent pending issue". > >I have absolutely no association, neither directly nor indirectly, >with this United States Patent Application 20020152382, its >inventor(s), owner(s), assignee(s), or agent(s). It is unfortunate >that my name pops up in the title of this ietf IPR detail page: >there seems to be a hidden reputation cost in good faith behavior >suggested by RFC3979 (Please carry any discussion on this sentence >in the appropriate IPR wg forum, i.e. ipr-wg@ietf.org). As I understand this - you're the one who filed the disclosure - it was your "Personal Belief" that referenced this application. So your association or lack thereof is a non-issue. Fortunately, so is your IPR disclosure. And for that matter, so is your "factual" argument. -- to unsubscribe send a message to namedroppers-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 Mar 08 20:16:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH9lm-0001ap-9W for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 20:16:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH9lk-00055h-Sl for dnsext-archive@lists.ietf.org; Wed, 08 Mar 2006 20:16:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH9j1-000Fhu-CZ for namedroppers-data@psg.com; Thu, 09 Mar 2006 01:13:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SBL, UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [66.163.8.251] (helo=SMTP.Lamicro.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FH9j0-000Fhf-EK for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 01:13:54 +0000 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v4.01b) ID MO001976; 8 Mar 2006 20:13:39 -0500 Received: from spooler by Lamicro.com (Mercury/32 v4.01b); 8 Mar 2006 20:13:21 -0500 Received: from connotech.com (209.71.204.124) by SMTP.Lamicro.com (Mercury/32 v4.01b) with ESMTP ID MG001975; 8 Mar 2006 20:13:16 -0500 Message-ID: <440F8A14.7000800@connotech.com> Date: Wed, 08 Mar 2006 20:51:16 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike StJohns CC: "Olaf M. Kolkman" , Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft References: <440B18B2.2040500@connotech.com> <440F1A33.7050507@connotech.com> <7.0.1.0.2.20060308183322.07cdf588@nominum.com> In-Reply-To: <7.0.1.0.2.20060308183322.07cdf588@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Mike StJohns wrote: > With respect to DS - this patent (or application) is invalid on its > face. The original DS draft was dated May 2001 - 18 months prior to the > date of the patent application. > Thanks for pointing this relevant prior art fact. I expected this to be the case but I didn't know the details. When I submitted this to the IETF IPR disclosure mechanism, I expected that such relevant fact would be quickly brought up by experts, then appropriately forwarded to the inventor/agent/patent office so that the claim is appropriately dropped before, or rejected during, patent examination. This didn't occur, as far as I can tell. Will it occur? I don't know. Is it a patent office duty to become self-aware of dnsext public forum back in May 2001 in relation to this X.509 patent? I don't think so. If nothing happens, will such a generic claim be approved by the USPTO (United States Patent and Trademark Office) on the basis of leaner X.509 prior art? (Perhaps the DNSSEC prior art will assist X.509 technology unencumberance here.) If approved by the USPTO, the annoyance of having this patent voided after issuance is certainly greater than the annoyance of acting now for the claim to be withdrawn or rejected in the first place. This has been presented now in this forum as an example of IPR issues which are best handled on a case by case basis, on specific result oriented approaches applicable to each of the circumstances. A blanket statement about an idealistic view of the end-result would not have helped this "DS RR patent pending issue". -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 09 02:46:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHFqr-0004tz-8B for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 02:46:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHFqo-0007Uw-Q9 for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 02:46:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHFlw-0009GM-Rv for namedroppers-data@psg.com; Thu, 09 Mar 2006 07:41:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHFlw-0009GA-0r for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 07:41:20 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 8 Mar 2006 23:41:19 -0800 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 23:41:18 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 23:41:18 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 23:41:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Wed, 8 Mar 2006 23:40:56 -0800 Message-ID: In-Reply-To: <440F8A14.7000800@connotech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Thread-Index: AcZDF0K4cVIhyPzGTNK2dlAN4ABL4wANVQkw From: "Christian Huitema" To: "Thierry Moreau" , "Mike StJohns" Cc: "Olaf M. Kolkman" , "Namedroppers" X-OriginalArrivalTime: 09 Mar 2006 07:41:18.0500 (UTC) FILETIME=[DA426E40:01C6434C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d =20 > Mike StJohns wrote: >=20 > > With respect to DS - this patent (or application) is invalid on its > > face. The original DS draft was dated May 2001 - 18 months prior to the > > date of the patent application. > > >=20 > Thanks for pointing this relevant prior art fact. I expected this to be > the case but I didn't know the details. When I submitted this to the > IETF IPR disclosure mechanism, I expected that such relevant fact would > be quickly brought up by experts, then appropriately forwarded to the > inventor/agent/patent office so that the claim is appropriately dropped > before, or rejected during, patent examination. This didn't occur, as > far as I can tell. It is also the inventors' duty to signal to the patent office any prior art that they know about. -- 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 Thu Mar 09 04:00:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHH0K-0000Tr-6Y for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 04:00:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHH0H-0001S4-MW for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 04:00:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHGxm-000GQA-LO for namedroppers-data@psg.com; Thu, 09 Mar 2006 08:57:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_BOGONS autolearn=no version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHGxl-000GPv-6E for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 08:57:37 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k298vZ9l032646 for ; Thu, 9 Mar 2006 09:57:35 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-83-378699574" Message-Id: Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft Date: Thu, 9 Mar 2006 09:57:36 +0100 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-83-378699574 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 8, 2006, at 6:50 PM, Russ Mundy wrote: (...) > > My impression was that the requirement in section 5.6 _removed_ > automated key > rollover from being a "mandatory-to-implement". > Note that I wrote: > Paul's premisses is that we had consented on the "mandatory-to- > implement" part of the key-rollover. The exact RFC2119 form (MUST, > SHOULD or MAY NOT implement) of that requirement is open to > discussion but I think we do consent to the spirit of the > "mandatory-to-implement" part; "mandatory-to-implement" should be > in between quotes indeed. The spirit of the "mandatory-to-implement" is that automatic keyrollover is a key component of successful deployment of DNSSECbis. There is broad, better than rough, consensus in this WG that automatic key rollover is a missing and necessary addition to DNSSECbis. That means that if we develop such protocol it must be widely available and for operational successful deployment operators of validating devices will have to deploy this (otherwise their life becomes a mess). I read 5.6 to say that if we have developed a mechanism than people should be able to either ignore the technology or use manual means to perform the rollover. As a metaphor: I can have a robot swap the keys or do it myself. We can no start to quibble if "mandatory to implement" has to be defined in the same manner as "royalty free" is defined for this particular text. I prefer we rather not do this. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-83-378699574 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFED+4FtN/ca3YJIocRAoFVAJ9P221oQ7/YSFWEQXtvchjcTaZulACg/WD1 R7EUEbL8kKl+kxzMu8U8K3w= =vbjg -----END PGP SIGNATURE----- --Apple-Mail-83-378699574-- -- to unsubscribe send a message to namedroppers-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 Mar 09 10:00:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMcW-0003hp-VF for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 10:00:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHMcW-0004lP-L0 for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 10:00:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHMZJ-000HWt-99 for namedroppers-data@psg.com; Thu, 09 Mar 2006 14:56:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHMZI-000HWh-Hv for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 14:56:44 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A7BAF11425 for ; Thu, 9 Mar 2006 14:56:43 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: ISSUE 1: IPR was Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft In-Reply-To: Your message of "Thu, 09 Mar 2006 09:57:36 +0100." References: Date: Thu, 09 Mar 2006 14:56:43 +0000 Message-Id: <20060309145643.A7BAF11425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b we are apparently out of "issue 1" mode, and having a free exchange of ideas, therefore i will re-enter the discussion. # I read 5.6 to say that if we have developed a mechanism than people should # be able to either ignore the technology or use manual means to perform the # rollover. As a metaphor: I can have a robot swap the keys or do it myself. # # We can no[w] start to quibble if "mandatory to implement" has to be defined # in the same manner as "royalty free" is defined for this particular text. I # prefer we rather not do this. i don't think "mandatory-to-implement" requires further definition, but i do think that 5.6 is ambiguous on this point if you can interpret as you describe. in particular, if an implementation can fail to include the automation nec'y for this feature, but make it possible for human hands to manually insert new keys, then the automation is optional, and therefore not mandatory to implement. this also opens the possibility of an "early adopter" class of implementations who, lacking this automation, rely on human hands to roll keys, where we know from the history of root hints that this won't occur. if what we want to say is that IETF standard automation is required, but it can either follow the specification whose requirements we are now defining or some later specification, then that would make this first specification mandatory-to-implement (since it will be, for a time at least, the only IETF standard automation), but in the future if there are ever multiple IETF standards for automation in this area, no single one will be mandatory to implement. i consider that a rather muddy puddle. in my view the right thing to do is either declare DNSSEC-bis "done", which means automated key rollover isn't mandatory, and wide scale implementation ought to occur immediately; or we ought to declare DNSSEC-bis "undeployable in its current form" and then itemize the missing features (likely this means automated key rollover and NSEC3) and get back to work on those. i do not care which path is chosen, but i do believe that the choice has to be one or the other. -- to unsubscribe send a message to namedroppers-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 Mar 09 14:07:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHQTX-0003rA-8t for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 14:07:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHQTS-0004C4-Su for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 14:07:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHQQ7-000AY1-EU for namedroppers-data@psg.com; Thu, 09 Mar 2006 19:03:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.127.148.224] (helo=mail4.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHQQ6-000AXk-H8 for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 19:03:30 +0000 Received: by mail4.sea.safepages.com (Postfix, from userid 1012) id 86F5E133882; Thu, 9 Mar 2006 19:03:28 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.61]) by mail4.sea.safepages.com (Postfix) with ESMTP id 0A31C133C61 for ; Thu, 9 Mar 2006 19:02:35 +0000 (GMT) Message-ID: <441084A3.6070605@connotech.com> Date: Thu, 09 Mar 2006 14:40:19 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Namedroppers Subject: MUST vs SHOULD for trust anchor rollover, nameserver side Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Dear all: The question has been raised as which portions of a Trust Anchor Key (TAK) management solution should be mandatory to implement. I restrict my post to the nameserver side. The short answer is that the automated TAK rollover protocol elements would be mandatory for the DNS root for each of the mandatory signature algorithms, and optional for other zones and optional signature algorithms. I don't think there is a realistic way to specify that such TAK rollover is mandatory for islands of trust other than the root because a normal zone (i.e. having a secure delegation from a secure parent) might become an island of trust suddenly because the parent zone turns DNSSEC-oblivious without warning. Some participants insist that anything mandatory-to-implement must be absolutely free for *anyone* to implement. They would now promote the freedom of entry into the alternate DNS root business. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 09 15:03:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRLy-0000Uo-Th for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 15:03:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHRLy-0005pO-GN for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 15:03:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHRJy-000FFq-LF for namedroppers-data@psg.com; Thu, 09 Mar 2006 20:01:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHRJx-000FFJ-D7 for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 20:01:13 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k29K0sMD076283; Thu, 9 Mar 2006 15:00:54 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060309145343.03d80320@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 09 Mar 2006 15:00:48 -0500 To: margaret@thingmagic.com, Sam Hartman , Ralph Droms , Stig Venaas From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs Cc: namedroppers@ops.ietf.org, dhcwg@ietf.org, "Bernie Volz \(volz\)" In-Reply-To: <6.2.5.6.2.20060224210949.03b72d20@ogud.com> References: <8E296595B6471A4689555D5D725EBB210147208B@xmb-rtp-20a.amer.cisco.com> <6.2.5.6.2.20060224210949.03b72d20@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Margaret, The publication of dhcid-12 resolves all DNSEXT issues with this document set, raised in the IETF last call and IESG discussion on the documents. DNSEXT consider these documents complete and requests they be forwarded to the RFC editor ASAP. Links to the new documents at the bottom of this= message. Sam Hartman, Does the new document set address all the issues you voiced in your discuss messages ? Ralph, Stig, Does this document set close all DHC issues ? Olafur (who wants this finished before Dallas IETF meeting) At 13:20 25/02/2006, =D3lafur Gu=F0mundsson /DNSEXT wrote: >At 22:57 22/02/2006, Bernie Volz \(volz\) wrote: > >>Hi: >> >>I have just submitted revised versions of the=20 >>drafts. Copies of what I submitted are available at: >> >>Ralph had sent a list of 11 issues to the=20 >>mailing list. And, then followed up with 19=20 >>more raised by Pekka Savola but that list of=20 >>issues did not go to the DHC WG. Both emails=20 >>are below so you can see the full list of 30 issues. >> >>I believe I have addressed all of them. > > >Bernie, thank you for your diligent work on getting the document >set updated. > > >>Some key changes are that the DHCID RR now has=20 >>an additional field to specify the digest type=20 >>and we've switched to using SHA-256 instead of MD5. > > >To give a little background on this change. >During the document revision there was a off-list discussion that involved >Ralph Droms, Olafur Gudmundsson, David Harkins, Sam Hartman, Ted Lemon >and Bernie Volz. This recollection is mine apologies to anyone that I >misrepresent/misunderstood/omitted. > >This results of discussion need to be documented, and I'm doing that here. > 1. Without obfuscation of the client ID, it is trivial to track clients > as the move around. > 1.5 No protocol change can protect a client that exposes its Client ID > over a public network, such as the IETF wireless net. But= obfuscation > still provides large number of clients with increased privacy. > > 2. In the overall schema of things he cost difference between using MD5, > SHA1 and SHA256 is not that great, thus=20 > the strongest one should be used. > > 3. Changing obfuscation functions over time can either > be accomplished by using a new field in DHCID or new RR type. > It is better not having to do a type code rollover. The rollover > to a new digest function MUST be defined by the NEW definition, > by this document. The reason for this is we are not sure if there > is ever a need so spending time on that right now is not productive, > and by selecting the one of the strongest functions available > right now we hope to push this far into the future, i.e. after > Ted, Ralph and I retire from the ietf :-). > > >>We need to figure out what the next step is --=20 >>do we need another DHC / DNSEXT WG last-call or=20 >>do we send these to the IESG directly? > > > > >Most of the changes are "minor" and I do not see need for a last call, >either at the WG level or IETF. >Scanning the documents I'm concerned that the examples are TBD, thus >I request that at least 3 parties calculate the new digests and post >their results. After which the DHCID document is needs to be updated. > >>If there is strong demand, I can develop diff=20 >>files but as there were a lot of minor edits=20 >>and changes to references, it likely will be rather large set of= differences. > >Diffs and (partial history are available at >http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dhcid-rr/ > >http://tools.ietf.org/wg/dhc/draft-ietf-dhc-ddns-resolution/ > >http://tools.ietf.org/wg/dhc/draft-ietf-dhc-fqdn-option/ > >http://tools.ietf.org/wg/dhc/draft-ietf-dhc-dhcpv6-fqdn/ > > =D3lafur > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > -- to unsubscribe send a message to namedroppers-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 Mar 09 16:04:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHS7d-0005VH-HC for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 15:52:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHS7W-0007oe-GS for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 15:52:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHS5G-000JDs-7o for namedroppers-data@psg.com; Thu, 09 Mar 2006 20:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHS5F-000JDP-FN for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 20:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k29Ko10e020904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHS5B-0008VI-Io; Thu, 09 Mar 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec3-04.txt Message-Id: Date: Thu, 09 Mar 2006 15:50:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 Hash Authenticated Denial of Existence Author(s) : B. Laurie, et al. Filename : draft-ietf-dnsext-nsec3-04.txt Pages : 42 Date : 2006-3-9 The DNS Security Extensions introduces the NSEC resource record for authenticated denial of existence. This document introduces a new resource record as an alternative to NSEC that provides measures against zone enumeration and allows for gradual expansion of delegation-centric zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec3-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-nsec3-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: <2006-3-9103315.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec3-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec3-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-9103315.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 Mar 09 17:24:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTYI-0002v5-Us for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 17:24:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHTYI-0002iW-7w for dnsext-archive@lists.ietf.org; Thu, 09 Mar 2006 17:24:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHTVX-00016w-Pm for namedroppers-data@psg.com; Thu, 09 Mar 2006 22:21:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHTVW-00016j-RU for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 22:21:19 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k29ML1vP026286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Mar 2006 22:21:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FHTVF-0006qp-GD; Thu, 09 Mar 2006 17:21:01 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair , dnsext chair Subject: Protocol Action: 'HMAC SHA TSIG Algorithm Identifiers' to Proposed Standard Message-Id: Date: Thu, 09 Mar 2006 17:21:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d The IESG has approved the following document: - 'HMAC SHA TSIG Algorithm Identifiers ' as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-06.txt Technical Summary Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC MD5 (Message Digest) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. Working Group Summary This document was produced by the DNSEXT WG. The Wg has consesnsus to publish this document as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. Elwyn Davies performede a very helpful review of this document during IETF LC. -- to unsubscribe send a message to namedroppers-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 Mar 10 08:34:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhl8-0000vd-2I for dnsext-archive@lists.ietf.org; Fri, 10 Mar 2006 08:34:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHhl4-0006ct-W0 for dnsext-archive@lists.ietf.org; Fri, 10 Mar 2006 08:34:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHhgh-0000d3-I1 for namedroppers-data@psg.com; Fri, 10 Mar 2006 13:29:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHhgg-0000cp-53 for namedroppers@ops.ietf.org; Fri, 10 Mar 2006 13:29:46 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 10 Mar 2006 13:29:44 +0000 X-IronPort-AV: i="4.02,181,1139184000"; d="scan'208"; a="3062753:sNHT24975956" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k2ADThIT016410; Fri, 10 Mar 2006 13:29:43 GMT Date: Fri, 10 Mar 2006 13:29:43 GMT From: Geoffrey Sisson Message-Id: <200603101329.k2ADThIT016410@staff.nominet.org.uk> To: dnssec-deployment@shinkuro.com, namedroppers@ops.ietf.org, nsec3-testing@nsec3.org Subject: NSEC3 Pre-Workshop Report Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad An NSEC3 pre-workshop meeting was held on 6-8 March at Nominet's offices. The aim of this meeting was to prepare for the first NSEC3 workshop, which is scheduled for 8-10 May 2006 at DENIC's offices in Frankfurt. A report from this meeting is now available at: http://www.nsec3.org/cgi-bin/trac.cgi/wiki/Workshop0 Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 10 09:52:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHiye-0004Ye-88 for dnsext-archive@lists.ietf.org; Fri, 10 Mar 2006 09:52:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHiyc-0000XJ-Qq for dnsext-archive@lists.ietf.org; Fri, 10 Mar 2006 09:52:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHivO-0005di-8j for namedroppers-data@psg.com; Fri, 10 Mar 2006 14:49:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHivN-0005dW-HG for namedroppers@ops.ietf.org; Fri, 10 Mar 2006 14:49:01 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2AEmtrX082046 for ; Fri, 10 Mar 2006 09:48:55 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k2AEmtEm082045 for namedroppers@ops.ietf.org; Fri, 10 Mar 2006 09:48:55 -0500 (EST) (envelope-from namedroppers) Received: from [206.117.31.194] (helo=carter-zimmerman.mit.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHRPE-000Fjr-Eh for namedroppers@ops.ietf.org; Thu, 09 Mar 2006 20:06:40 +0000 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AD8F3E0053; Thu, 9 Mar 2006 15:06:33 -0500 (EST) To: =?iso-8859-1?q?lafur_Gu=F0mundsson_=2FDNSEXT_co-chair?= Cc: margaret@thingmagic.com, Ralph Droms , Stig Venaas , namedroppers@ops.ietf.org, dhcwg@ietf.org, "Bernie Volz (volz)" Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs References: <8E296595B6471A4689555D5D725EBB210147208B@xmb-rtp-20a.amer.cisco.com> <6.2.5.6.2.20060224210949.03b72d20@ogud.com> <6.2.5.6.2.20060309145343.03d80320@ogud.com> From: Sam Hartman Date: Thu, 09 Mar 2006 15:06:32 -0500 In-Reply-To: <6.2.5.6.2.20060309145343.03d80320@ogud.com> =?iso-8859-1?q?=28=D3lafur_Gu=F0mundsson's?= message of "Thu, 09 Mar 2006 15:00:48 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] >>>>> "lafur" == lafur Guðmundsson /DNSEXT co-chair writes: lafur> Sam Hartman, Does the new document set address all the lafur> issues you voiced in your discuss messages ? I think I've already cleared my discuss position. -- to unsubscribe send a message to namedroppers-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 Mar 10 14:06:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHmwT-0004sl-Ib for dnsext-archive@lists.ietf.org; Fri, 10 Mar 2006 14:06:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHmwT-0000xF-7v for dnsext-archive@lists.ietf.org; Fri, 10 Mar 2006 14:06:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHmr6-0004Rt-3D for namedroppers-data@psg.com; Fri, 10 Mar 2006 19:00:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHmr5-0004Rf-9M for namedroppers@ops.ietf.org; Fri, 10 Mar 2006 19:00:51 +0000 Received: from wormhole2.int.libertyrms.com ([10.1.2.130] helo=trilby.local) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FHmr4-0005mQ-1l for namedroppers@ops.ietf.org; Fri, 10 Mar 2006 14:00:50 -0500 Received: by trilby.local (Postfix, from userid 1019) id 27E301914DE; Fri, 10 Mar 2006 14:00:21 -0500 (EST) Date: Fri, 10 Mar 2006 14:00:21 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: review of draft-ietf-dnsext-dnssec-experiments-02 Message-ID: <20060310190020.GA1027@afilias.info> Reply-To: Andrew Sullivan Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Dear colleagues, I have reviewed the document draft-ietf-dnsext-dnssec-experiments-02. Here are my comments. First, I strongly support the goal of this document. I think it's a good idea to have a well-defined methodology for these experiments. It seems to me that the first bit under 4 could be clarified: The core of the methodology is the use of strictly "unknown" algorithms to sign the experimental zone isn't strictly true, if I'm reading this right, because it isn't the _algorithm_ that is unknown, but its identifier (that seems to be what the clarification in paragraph 6 actually says). I don't think this is a big deal, but it might be worth altering if other changes are being made. Even without the above clarification, however, I would support the document going forward. Nits ==== Section 1, 1st paragraph: Throughout this document, familiarity with the DNS system (RFC1035 [4]) and the DNS security extensions ([1], [2], and [3]. * this doesn't seem to be a sentence. Maybe This document assumes the reader's familiarity with RFC1035 ([4]) and the DNS security extensions ([1], [2], and [3]). Section 9 IANA may need to allocate new DNSSEC algorithm numbers if that transition approach is taken, or the experiment decides to use allocated numbers to begin with. * the antecedent of the "that transition" was a little muddy to me. Here's a suggested replacement, a little verbose: IANA may need to allocate new DNSSEC algorithm numbers in two cases: in case of a successful experiment that elects to move to standards track by the adoption of newly allocated algorithm numbers (as outlined in section 7); and in case the experiment uses allocated numbers to begin with. Best regards, A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Mar 10 17:13:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHprx-0005wQ-Pf for dnsext-archive@lists.ietf.org; Fri, 10 Mar 2006 17:13:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHprv-0001ko-GF for dnsext-archive@lists.ietf.org; Fri, 10 Mar 2006 17:13:57 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHppF-000ExD-02 for namedroppers-data@psg.com; Fri, 10 Mar 2006 22:11:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,INFO_TLD autolearn=no version=3.1.0 Received: from [207.219.45.62] (helo=mail.libertyrms.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FHppE-000Ex2-7m for namedroppers@ops.ietf.org; Fri, 10 Mar 2006 22:11:08 +0000 Received: from wormhole2.int.libertyrms.com ([10.1.2.130] helo=trilby.local) by mail.libertyrms.com with esmtp (Exim 4.22) id 1FHppD-0005pB-Bl for namedroppers@ops.ietf.org; Fri, 10 Mar 2006 17:11:07 -0500 Received: by trilby.local (Postfix, from userid 1019) id 8E39E191CA6; Fri, 10 Mar 2006 17:10:38 -0500 (EST) Date: Fri, 10 Mar 2006 17:10:38 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: comments on draft-ietf-dnsext-dnssec-opt-in-08 Message-ID: <20060310221038.GE1027@afilias.info> Reply-To: Andrew Sullivan Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-SA-Exim-Mail-From: andrew@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Dear colleagues, I have read draft-ietf-dnsext-dnssec-opt-in-08. Here are my comments. I compared the methodology of the experiment to the methodology outlined in draft-ietf-dnsext-dnssec-experiments-02. I believe that it is consistent. Therefore, assuming the latter draft is the community's view of how such experiments should proceed, I agree that the opt-in draft should go forward as an experimental RFC. Per the Chairs' instructions, I have not evaluated the mechanism in the experiment. Nits ==== I have a question about section 4.1.4. I wondered about the reasoning for specifying RCODE=REFUSED as a SHOULD rather than a MUST there, given the requirement that the processing mustn't happen. (If people think this is part of an evaluation of the mechanisms in the experiment, I withdraw the question.) Also, I note that RFC2137 has been obsolted by RFC3007. I don't know whether that matters for this document, though. Best regards, Andrew Sullivan -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 -- to unsubscribe send a message to namedroppers-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 Mar 13 00:16:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIfQC-000707-9G for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 00:16:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIfQ9-00009U-Px for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 00:16:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIfKG-000F4H-6r for namedroppers-data@psg.com; Mon, 13 Mar 2006 05:10:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIfKE-000F3y-BY for namedroppers@ops.ietf.org; Mon, 13 Mar 2006 05:10:34 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2D5AKMq095626; Mon, 13 Mar 2006 00:10:20 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060313000314.035ebd40@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 13 Mar 2006 00:10:15 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Draft agenda Cc: ogud@ogud.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_387164833==_" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 --=====================_387164833==_ Content-Type: text/plain; charset="us-ascii"; format=flowed We have posted the first version of the agenda at the proceedings website http://www3.ietf.org/proceedings/06mar/agenda/dnsext.html please refer to that as the most up to date version as we will try to keep the on-line version current. We will try to post all presentations before the meeting starts. Olafur & Olaf --=====================_387164833==_ Content-Type: text/plain; name="agenda-65-00.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="agenda-65-00.txt" CldHOiAgICAgICAgICAgICBETlNFWFQgQCBJRVRGLTY1ICBpbiBEYWxsYXMKRGF0ZTogICAgICAg ICAgIDIwMDYvMDMvMjEgVHVlc2F5ClRpbWU6ICAgICAgICAgICAxMzswMCAtIDE1OjAwCkxvY2F0 aW9uICAgICAgICBDb3J0ZXogQUIgICAgCkNoYWlyczogICAgICAgICBPbGFmdXIgR3VkbXVuZHNz b24gWzFdb2d1ZEBvZ3VkLmNvbQogICAgICAgICAgICAgICAgT2xhZiBLb2xrbWFuIFsyXW9sYWZA bmxuZXRsYWJzLm5sClZlcnNpb246ICAgICAgICAwLjkuMAoKICAgQWdlbmRhIEJhc2hpbmcgYW5k IGFwcG9pbnRtZW50IG9mIHNjcmliZXM6CgpEb2N1bWVudHMgU3RhdHVzOgoKICBEb2N1bWVudHMg QWR2YW5jZWQ6CgogICBDYXNlIEluc2Vuc2l0aXZlOiBbM11SRkM0MzQzCgogICBDRVJUIFJSIGJp czoKICAgICAgQW4gaXNzdWUgcmFpc2VkIGluIEFVVEg0OCwgd29ya2luZyBvbiByZXNvbHZpbmcK ICAgICAgWzRdaHR0cDovL2lldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRuc2V4 dC1yZmMyNTM4YmlzLTA5LnR4dAoKICAgTi1QIERlcml2YXRpb24gb2YgRE5TIE5hbWUgUHJlZGVj ZXNzb3IgYW5kIFN1Y2Nlc3NvcgogICAgICBJbiBSRkMtRWRpdG9ycyBxdWV1ZQogICAgICBbNV1o dHRwOi8vaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LWRucy1uYW1l LXAtcy0wMS50eHQKCiAgIEVwc2lsb24gTWluaW1hbGx5IENvdmVyaW5nIE5TRUMgUmVjb3JkcyBh bmQgRE5TU0VDIE9uLWxpbmUgU2lnbmluZwogICAgICBJbiBSRkMtRWRpdG9ycyBxdWV1ZQogICAg ICBbNl1odHRwOi8vaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LWRu c3NlYy1vbmxpbmUtc2lnbmluCmctMDAudHh0CgogICBEUyBTSEEtMjU2CiAgICAgIEluIFJGQy1F ZGl0b3JzIHF1ZXVlCiAgICAgIFs3XWh0dHA6Ly9pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1kbnNleHQtZHMtc2hhLTI1Ni0wNS50eHQKCiAgIFdpbGRjYXJkIENsYXJpZnkgCiAg ICAgIElFU0cgYXBwcm92ZWQgd2FpdGluZyBmb3IgZWRpdG9yIHRvIGFwcGx5IGZldyBjaGFuZ2Vz CiAgICAgIFs4XWh0dHA6Ly9pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNl eHQtd2NhcmQtY2xhcmlmeS0xMC50eHQKCiAgIERIQ0lECiAgICAgIFdhaXRpbmcgZm9yIElFU0cg dG8gYXBwcm92ZSB1cGF0ZWQgdmVyc2lvbgogICAgICBbOV1odHRwOi8vaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LWRoY2lkLXJyLTEyLnR4dAoKICAgTlNJRCBOYW1l IFNlcnZlciBJZGVudGlmaWVyIE9wdGlvbgoKICAgICAgV2FpdGluZyBmb3IgSUVURiBsYXN0IGNh bGwgdG8gc3RhcnQuCiAgICAgIFsxMF1odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWRuc2V4dC1uc2lkLTAxLnR4dAoKICAgTExNTlIKICAgICBpbiBhIGxpbWJv CiAgICAgWzExXWh0dHA6Ly9pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNl eHQtbWRucy00NS50eHQKCkxhc3QgY2FsbCBjb21wbGV0ZWQgd2FpdGluZyBmb3IgY2hhaXI6Cgog ICBEU0EgS2V5aW5nIGFuZCBTaWduYXR1cmUgSW5mb3JtYXRpb24gaW4gdGhlIEROUyAKICAgICAg U3RpbGwgbmVlZHMgbW9yZSByZXZpZXdlcnMgdG8gc2F5IHRoZXkgcmVhZCBpdC4KICAgICAgWzEy XWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LXJm YzI1MzZiaXMtZHNhLQowNi50eHQKCiAgIFN0b3JhZ2Ugb2YgRGlmZmllLUhlbGxtYW4gS2V5aW5n IEluZm9ybWF0aW9uIGluIHRoZSBETlMKICAgICAgU3RpbGwgbmVlZHMgbW9yZSByZXZpZXdlcnMg dG8gc2F5IHRoZXkgcmVhZCBpdC4KICAgICAgWzEzXWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LXJmYzI1MzliaXMtZGhrLQowNi50eHQKCkRyYWZ0 cyBpbiBsYXN0IGNhbGxzOgoKICAgRE5TU0VDIGV4cGVyaW1lbnRzCiAgICAgIFsxNF1odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRuc2V4dC1kbnNzZWMtZXhw ZXJpbWUKbnRzLTAyLnR4dAoKRHJhZnRzIHdhaXRpbmcgZm9yIExhc3QgY2FsbHM6CgogICBFdmFs dWF0aW5nIEROU1NFQyBUcmFuc2l0aW9uIE1lY2hhbmlzbXMKICAgICAgRWRpdG9ycyBmYWlsZWQg dG8gdXBkYXRlIGRvY3VtZW50IGJlZm9yZSBkZWFkbGluZSAoQkFEKQogICAgICBbMTVdaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQtZG5zc2VjLXRy YW5zLTAzCi50eHQKCiAgIEVsbGlwdGljIEN1cnZlIEtleXMgaW4gdGhlIEROUwoKICAgICAgWzE2 XWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LWVj Yy1rZXktMDgudHh0CgpPbmdvaW5nCgogICBDbGFyaWZpY2F0aW9ucyBhbmQgSW1wbGVtZW50YXRp b24gTm90ZXMgZm9yIEROU1NFQ2JpcwogICAgWzE3XWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LWRuc3NlYy1iaXMtdXBkYXRlCnMtMDIudHh0Cgog ICBEb21haW4gTmFtZSBTeXN0ZW0gKEROUykgSUFOQSBDb25zaWRlcmF0aW9ucwogICAgICBbMThd aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQtMjky OWJpcy0wMS50eHQKCiAgIEVuaGFuY2VkIFByaXZhY3kgb24gTmVnYXRpdmUgYW5zd2VycwogICAg IE5TRUMgcmVwbGFjZW1lbnQgUmVxdWlyZW1lbnRzCiAgICAgICBbMTldaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQtc2lnbmVkLW5vbmV4aXMKdGVu Y2UtcmVxdWlyZW1lbnRzLTAyLnR4dAoKICAgICBETlNTRUMgSGFzaCBBdXRoZW50aWNhdGVkIERl bmlhbCBvZiBFeGlzdGVuY2UKICAgICAgICBbMjBdaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQtbnNlYzMtMDQudHh0ClsyMV0KCiAgIGh0dHA6Ly93 d3cubnNlYzMub3JnIE5TRUMzIGluZm9ybWF0aW9uIHdlYiBzaXRlLgoKTlNFQzMgc3RhdHVzIGFu ZCBpc3N1ZXMKCiAgIEdlb2ZmcmV5IFNpc3NvbgoKQXV0b21hdGVkIEROU1NFQyBUcnVzdCBhbmNo b3IgbWFuYWdlbWVudDoKCiAgVHJ1c3QgQW5jaG9yIFVwZGF0ZSByZXF1aXJlbWVudHMgaW4gRE5T U0VDCgogICBSdXNzIE11bmR5CiAgICAgWzIyXWh0dHA6Ly93d3cuaWV0Zi5vcmcvd2cvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LXJvbGxvdmVyLXJlcXUKaXJtZW50cy0wMC50eHQK CmFuZAogICAgIFsyM11odHRwOi8vd3d3LmlldGYub3JnL3dnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1tb3JlYXUtZG5zZXh0LXRhay1yZXEtMDAuCnR4dAoKCgogIEtleSBSb2xsb3ZlciBEaXNjdXNz aW9uCgoKT3RoZXIgRHJhZnRzIGRpc2N1c3Npb246CgogIEludGVyb3BlcmFiaWx0eSB0ZXN0aW5n IHJlcG9ydHM6CgogIEROUyBDb21wbGlhbmNlIHRlc3RpbmcgcmVwb3J0OgoKICAgWXVraXlvIEFr aXNhZGEgWzI0XWh0dHA6Ly93d3cudGFoaS5vcmcvZG5zLwoKICBEcmFmdHMgZnJvbSBvdGhlciBX RydzIHJlcXVlc3RpbmcgcmV2aWV3OgoKICAgTm9uZSBhdCB0aGlzIHBvaW50CgogIFdyYXB1cAoK UmVmZXJlbmNlcwoKICAgMS4gbWFpbHRvOm9ndWRAb2d1ZC5jb20KICAgMi4gbWFpbHRvOm9sYWZA bmxuZXRsYWJzLm5sCiAgIDMuIGh0dHA6Ly9yZmM0MzQzLng0MmNvbS8KICAgNC4gaHR0cDovL2ll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRuc2V4dC1yZmMyNTM4YmlzLTA5LnR4 dAogICA1LiBodHRwOi8vaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0 LWRucy1uYW1lLXAtcy0wMS50eHQKICAgNi4gaHR0cDovL2lldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWRuc2V4dC1kbnNzZWMtb25saW5lLXNpZ25pbmctMDAudHh0CiAgIDcuIGh0 dHA6Ly9pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQtZHMtc2hhMjU2 LTA1LnR4dAogICA4LiBodHRwOi8vaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt ZG5zZXh0LXdjYXJkLWNsYXJpZnktMTAudHh0CiAgIDkuIGh0dHA6Ly9pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQtZGhjaWQtcnItMTIudHh0CiAgMTAuIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LW5zaWQtMDEudHh0 CiAgMTEuIGh0dHA6Ly9pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQt bWRucy00NS50eHQKICAxMi4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1kbnNleHQtcmZjMjUzNmJpcy1kc2EtMDYudHh0CiAgMTMuIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LXJmYzI1MzliaXMtZGhrLTA2 LnR4dAogIDE0LiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LWRuc2V4dC1kbnNzZWMtZXhwZXJpbWVudHMtMDIudHh0CiAgMTUuIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG5zZXh0LWRuc3NlYy10cmFucy0wMy50eHQK ICAxNi4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNl eHQtZWNjLWtleS0wOC50eHQKICAxNy4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1kbnNleHQtZG5zc2VjLWJpcy11cGRhdGVzLTAyLnR4dAogIDE4LiBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRuc2V4dC0yOTI5Ymlz LTAxLnR4dAogIDE5LiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLWRuc2V4dC1zaWduZWQtbm9uZXhpc3RlbmNlLXJlcXVpcmVtZW50cy0wMi50eHQKICAyMC4g aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kbnNleHQtbnNl YzMtMDQudHh0CiAgMjEuIGh0dHA6Ly93d3cubnNlYzMub3JnLwogIDIyLiBodHRwOi8vd3d3Lmll dGYub3JnL3dnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRuc2V4dC1yb2xsb3Zlci1yZXF1 aXJlbWVudHMtMDAudHh0CiAgMjMuIGh0dHA6Ly93d3cuaWV0Zi5vcmcvd2cvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LW1vcmVhdS1kbnNleHQtdGFrLXJlcS0wMC50eHQKICAyNC4gaHR0cDovL3d3dy50 YWhpLm9yZy9kbnMvCg== --=====================_387164833==_-- -- to unsubscribe send a message to namedroppers-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 Mar 13 09:48:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoLa-0001ss-E3 for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 09:48:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIoLY-0000Gr-W7 for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 09:48:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIoHw-000NsV-Bs for namedroppers-data@psg.com; Mon, 13 Mar 2006 14:44:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIoHu-000NsF-Od for namedroppers@ops.ietf.org; Mon, 13 Mar 2006 14:44:47 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2DEihJq066952; Mon, 13 Mar 2006 15:44:43 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <20060309145643.A7BAF11425@sa.vix.com> References: <20060309145643.A7BAF11425@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-129-745132593" Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: ISSUE 2: Mandatory to implement Date: Mon, 13 Mar 2006 15:44:49 +0100 To: Paul Vixie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-129-745132593 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Paul, I think DNSSEC bis is not ready without a mechanism that allows for automatic key rollover. For the client device there is an operational need to configure keys once, turn the device on and let the device automagically reconfigure its trust anchors. I do not think there is a dispute about this. We would like to have one single protocol that our clients need to understand for that purpose. Such protocol will set operational requirements on the DNS service provider; there will have to be bits set, RRsets published, RRsets pulled and specific signatures generated. Those operational procedures, the rollover mechanism as I will call it, will be mandatory to implement at the server side by anybody who is in the business of operating a zone that is intended to be a "public" entry point in the chain of trust. The exact set of zones which are in that business is not known to me but the root is definitely a member. So the "rollover mechanism" will be mandatory for the root. If there is no single rollover protocol there might be multiple rollover mechanisms required at the root. That would be bad. So we do need one protocol with one set of "rollover mechanism" instructions for the zone owners. The client must be able to implement the protocol in software (the protocol must be implementable); but may choose not to do so. Still for a successful rollover the operator of such client should follow the steps described in the protocol or reconfigure the trust-anchors from scratch. Essentially we should have one set of rules to play this game which can be fully automated. Another way of phrasing is: This would be the "mandatory to implement" mechanism for everybody who would want to perform automatic rollover of DNSKEYs. Section 5.6 just says that you may choose not to perform automatic rollovers. If you take a car you MUST wear seatbelts, you MAY still choose to walk, it just won't get you very far. --Olaf > i don't think "mandatory-to-implement" requires further definition, > but i do > think that 5.6 is ambiguous on this point if you can interpret as you > describe. in particular, if an implementation can fail to include the > automation nec'y for this feature, but make it possible for human > hands to > manually insert new keys, then the automation is optional, and > therefore not > mandatory to implement. this also opens the possibility of an > "early adopter" > class of implementations who, lacking this automation, rely on > human hands to > roll keys, where we know from the history of root hints that this > won't occur. > > if what we want to say is that IETF standard automation is > required, but it > can either follow the specification whose requirements we are now > defining or > some later specification, then that would make this first > specification > mandatory-to-implement (since it will be, for a time at least, the > only IETF > standard automation), but in the future if there are ever multiple > IETF > standards for automation in this area, no single one will be > mandatory to > implement. i consider that a rather muddy puddle. > > in my view the right thing to do is either declare DNSSEC-bis > "done", which > means automated key rollover isn't mandatory, and wide scale > implementation > ought to occur immediately; or we ought to declare DNSSEC-bis > "undeployable > in its current form" and then itemize the missing features (likely > this means > automated key rollover and NSEC3) and get back to work on those. i > do not > care which path is chosen, but i do believe that the choice has to > be one or > the other. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-129-745132593 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEFYVmtN/ca3YJIocRAuS5AKDSTjyNi8ZHF68SkIimrYCXJ71BhQCeKo3g RlNLE189nvtrBVzmspDVzsA= =hSOh -----END PGP SIGNATURE----- --Apple-Mail-129-745132593-- -- to unsubscribe send a message to namedroppers-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 Mar 13 10:05:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIoc7-0004Ez-9X for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 10:05:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIoc5-00014i-Vt for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 10:05:39 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIoZu-000OtU-QH for namedroppers-data@psg.com; Mon, 13 Mar 2006 15:03:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIoZu-000OtI-5b for namedroppers@ops.ietf.org; Mon, 13 Mar 2006 15:03:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C008811425 for ; Mon, 13 Mar 2006 15:03:21 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: ISSUE 2: Mandatory to implement In-Reply-To: Your message of "Mon, 13 Mar 2006 15:44:49 +0100." References: <20060309145643.A7BAF11425@sa.vix.com> Date: Mon, 13 Mar 2006 15:03:21 +0000 Message-Id: <20060313150321.C008811425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 # Another way of phrasing is: # # This would be the "mandatory to implement" mechanism for everybody who would # want to perform automatic rollover of DNSKEYs. Section 5.6 just says that # you may choose not to perform automatic rollovers. so it's mandatory-to-implement for the root zone and for any other zone ``that is intended to be a "public" entry point in the chain of trust,'' but it isn't mandatory-to-implement for requestors, who must be considered to comply with the DNSSEC protocol even if they don't automate this particular functional. let me register my disagreement with this position by quoting my own words: this ... opens the possibility of an "early adopter" class of implementations who, lacking this automation, rely on human hands to roll keys, where we know from the history of root hints that this won't occur. another way of phrasing it is, if automation of this function is optional, then i predict market failure of virtually every implementation which lacks it, and if these implementations have critical mass, then i predict market failure of the DNSSEC protocol itself. however, i must also note that for the purposes of RFC 3979, the fact that some zone operators (including the root zone) must implement this means it is "mandatory-to-implement". so for the purpose of answering issue 1, your vision of one-sided mandatoryness (while dangerous) supports my proposed text for 5.2 in the "ISSUE 1" thread. -- to unsubscribe send a message to namedroppers-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 Mar 13 11:28:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIpto-0005mM-JK for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 11:28:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIptn-0003sa-9P for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 11:28:00 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIprW-0003HK-4r for namedroppers-data@psg.com; Mon, 13 Mar 2006 16:25:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.74.78.12] (helo=lde.centergate.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIprV-0003Gw-EJ for namedroppers@ops.ietf.org; Mon, 13 Mar 2006 16:25:37 +0000 In-Reply-To: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> References: <664AA895-5B87-407D-A910-7F0D0C032415@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-751160483" Message-Id: <1D635911-08B8-4138-A8CE-B22DCB6EB605@centergate.com> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: Rodney Joffe Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in Date: Mon, 13 Mar 2006 09:25:17 -0700 To: "Olaf M. Kolkman" X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-751160483 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Olaf, On Mar 8, 2006, at 8:43 AM, Olaf M. Kolkman wrote: > > > Before people forget that we are collecting statements for dnssec- > experiments, here is a reminder. > > >> This working group last call will terminate March 15. We request at >> least 5 people to state that they thoroughly read said documents >> before we forward to the IESG. > > > We have not reached a head count of 5 yet. One more week for review! > I've reviewed both of these latest drafts in detail: draft-ietf-dnsext-dnssec-experiments-02 draft-ietf-dnsext-dnssec-opt-in-08 I'll leave the nits for others, but add me to the list of reviewers who agree with these versions and approve them going forward to the IESG. Rodney Joffe UltraDNS Corp. --Apple-Mail-1-751160483 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFEFZzyRrelm2onc7ARAqvxAJ4yFx7JQLnuJaCR+8OAeQSMGTUpuwCg3TdP Wxp2s7ncI63uKMAwv/EUZ/4= =4hUi -----END PGP SIGNATURE----- --Apple-Mail-1-751160483-- -- to unsubscribe send a message to namedroppers-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 Mar 13 15:01:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FItE0-0006H5-Ev for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 15:01:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FItDy-0002hG-TG for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 15:01:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FItAH-000G7l-Ht for namedroppers-data@psg.com; Mon, 13 Mar 2006 19:57:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_SOFTFAIL autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FItAG-000G7O-AW for namedroppers@ops.ietf.org; Mon, 13 Mar 2006 19:57:12 +0000 Received: from mistral.verisignlabs.com ([::ffff:216.168.239.87]) (AUTH: PLAIN matt, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Mon, 13 Mar 2006 14:57:11 -0500 id 002C03C1.4415CE97.00007058 Date: Mon, 13 Mar 2006 14:57:10 -0500 From: Matt Larson To: "Olaf M. Kolkman" Cc: Namedroppers Subject: Re: WGLC dnssec-experiments and dnssec-opt-in Message-ID: <20060313195710.GA23131@mistral.verisignlabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Mon, 27 Feb 2006, Olaf M. Kolkman wrote: > Please carefully review the methodology described in > dnssec-experiments and review if the methodology has been correctly > applied to the opt-in draft. I have read both documents and recommend that they go forward to the IESG. Matt -- to unsubscribe send a message to namedroppers-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 Mar 13 15:24:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FItal-0005Km-Fr for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 15:24:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FItak-0003vh-4W for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 15:24:35 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FItYu-000HUu-Et for namedroppers-data@psg.com; Mon, 13 Mar 2006 20:22:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FItYt-000HUh-NC for namedroppers@ops.ietf.org; Mon, 13 Mar 2006 20:22:40 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k2DKMVIV012319; Mon, 13 Mar 2006 20:22:31 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k2DKMVw8012318; Mon, 13 Mar 2006 20:22:31 GMT Date: Mon, 13 Mar 2006 20:22:31 +0000 From: bmanning@vacation.karoshi.com To: olaf@NLnetLabs.nl, namedroppers@ops.ietf.org Cc: bmanning@vacation.karoshi.com Subject: Re: WGLC dnssec-experiments and dnssec-opt-in Message-ID: <20060313202231.GA12290@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Olaf writes... > Please carefully review the methodology described in > dnssec-experiments and review if the methodology has been correctly > applied to the opt-in draft. I have read both documents - the IESG should review these documents. --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 Mar 13 15:53:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIu2p-0007sH-So for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 15:53:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIu2o-0004iN-HJ for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 15:53:35 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIu0p-000JGC-1W for namedroppers-data@psg.com; Mon, 13 Mar 2006 20:51:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIu0o-000JFw-EJ for namedroppers@ops.ietf.org; Mon, 13 Mar 2006 20:51:30 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 13 Mar 2006 15:51:29 -0500 id 002C03F4.4415DB51.000003ED In-Reply-To: <200603081750.k28HoXl1031095@rotala.raleigh.ibm.com> References: <200603081750.k28HoXl1031095@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42E960AD-61DA-4A34-BBAC-833A8162B0CE@verisignlabs.com> Cc: Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in Date: Mon, 13 Mar 2006 15:51:29 -0500 To: Thomas Narten X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Mar 8, 2006, at 12:50 PM, Thomas Narten wrote: > Specific comments: > > abstract says: > >> In the long history of the development of the DNS security >> extensions >> [1] (DNSSEC), a number of alternate methodologies and >> modifications >> have been proposed and rejected for practical, rather than >> strictly >> technical, reasons. There is a desire to be able to experiment >> with >> these alternate methods in the public DNS. This document >> describes a >> methodology for deploying alternate, non-backwards-compatible, >> DNSSEC >> methodologies in an experimental fashion without disrupting the >> deployment of standard DNSSEC. > > IMO, the first sentence can be struck completely, as it adds nothing > to the purpose of the document. I also don't like the wording, since > I don't know the difference between "technical" and "practical" > reasons. It has occurred to me after a private conversation that it might be useful to explain what I was trying to get at here, so maybe someone can suggest better language. In this paragraph, the alluded-to "practical" reasons have all actually been pretty must just one practical reason: If we start work on X, then we will delay [widespread] deployment of DNSSEC. That is, it is trying to say that an experimental methodology is useful in the sense that it provides a way around that practical, but not technical, sentiment. I don't particularly think that this is a useless concept to convey, but I also recognize that it isn't strictly necessary either. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 13 16:12:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIuLK-00036R-Pt for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 16:12:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIuLK-0005V2-AW for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 16:12:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIuIu-000KbY-4O for namedroppers-data@psg.com; Mon, 13 Mar 2006 21:10:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIuIt-000KbK-C4 for namedroppers@ops.ietf.org; Mon, 13 Mar 2006 21:10:11 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 13 Mar 2006 16:10:10 -0500 id 002C03F4.4415DFB2.00000868 In-Reply-To: <200603081849.k28InRZX031365@rotala.raleigh.ibm.com> References: <200603081849.k28InRZX031365@rotala.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F31DF13-12B0-43FD-9F46-FB259D4B0ECD@verisignlabs.com> Cc: Sam Weiler , Namedroppers WG Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in Date: Mon, 13 Mar 2006 16:10:10 -0500 To: Thomas Narten X-Mailer: Apple Mail (2.746.2) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 On Mar 8, 2006, at 1:49 PM, Thomas Narten wrote: > Sam Weiler writes: > >> It is _not_ just experimenting with new algorithms, nor is it for >> experiments with non-DNSSEC parts of the protocol. > > OK. > >> We're talking about experimenting with DNSSEC flavors, extensions, >> and bad ideas. The unknown algorithm tells DNSSEC-aware resolvers >> that aren't part of the experiment "you don't know what's going on >> here -- just ignore any DNSSEC bits you see in this zone and treat >> it as unsigned". > > And for those resolvers that do understand the particular flavor, it > is saying "do flavor X" of DNSSEC here. And since it doesn't make > sense to do "normal" DNSSEC and "flavor X" simultaneously, this is > what is being described as another "different version" of DNSSEC? Yes. >> Classic examples include NSEC3 and opt-in. We MIGHT have been >> able to >> use this method to test DS (RFC3658). > > Only "MIGHT have"? Well, the rules that this technique rely on postdate DS. So I assume Sam was using MIGHT in the sense that had things unfolded differently... >> We could also use this method to signal a change in typecodes >> (RFC3755), though the new typecodes would probably be used as part >> of some larger experiment (like NSEC3). > > Again, the basic point here is that "flavor X" can mean whatever "X" > is defined to be, and the normal DNSSEC rules don't apply. Yes. >>>> 2. It will not be possible for DNSSEC-aware resolvers not >>>> aware of >>>> the experiment to build a chain of trust through an >>>> experimental zone. >>> >>> Can't an experimental zone co-exist with a regular zone (i.e., one >>> using a standard signature)? If so, the above wording seems wrong. > >> In general, no. There is only one zone. It may use no DNSSEC, >> "standard" DNSSEC, or some "experimental" DNSSEC. > > Why can't a zone use both "standard" and "experimental"? I.e., signed > different sets of keys/algorithms, as the document says up front? That > is, any one resolver choose one or the other (but not both) for a > particular zone. If that is the case, both can co-exist, though the > defn. of coexistance is maybe different that you are thinking of. Honestly, I'm not sure how to answer this. Right now, I think I have to say that the reason why a zone can't serve both normal and experimental DNSSEC at the same time is that there is no way for the server to know which to serve. That is, there is no way for the resolver to signal to the server which set of semantics to use. One could construct such a proposal, I suppose, but that is not the purpose of this draft. >> It may be that the extension is backwards compatible, allow a zone >> to be validated by both "standard" and "experimental" resolvers at >> the same time, but I imagine that to be an exceptional case. > >> Example: a zone could publish (and return) both NSEC and NSEC3 RR's, >> potentially allowing it to be validated by both "standard" and >> "NSEC3" >> resolvers. But the mechanics of doing that might prove challenging. > > Here is the rub. This technique allows zones to identify extensions > that only extension-aware resolvers will process. But it does not > really allow DNS servers (e.g., those in zones implementing the > experiment) to know they are talking to "experiment-aware" resolvers > and thus return answers appropriate for implementors of the experiment > (but not others). So there are some clear limitations here. If one > has a zone only implement standard DNSSEC or "experimental flavor" > DNSSEC, no problem. Well, that is the situation that the draft describes. The experimental technique described by the draft should work *today*. Right now, there is no way for a resolver to reliably signal anything to a (possibly-more-than-one-hop-away) resolver without a widespread protocol change. > It might be good for the document to say a bit more about these > limitations. I'll see what I can do, but this sort of feels to me like starting to document the infinite list of things you can't do. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 13 21:22:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIzB1-0006QC-OC for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 21:22:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIzAy-0007Tu-0d for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 21:22:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIz7g-000A04-2w for namedroppers-data@psg.com; Tue, 14 Mar 2006 02:18:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FIz7d-0009zk-4u for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 02:18:53 +0000 Received: (qmail 52447 invoked from network); 14 Mar 2006 03:22:05 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 14 Mar 2006 03:22:05 -0000 Message-ID: <441627F4.10001@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Mar 2006 11:18:28 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Secure DNS is just weakly secure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca For those of you who are vigorously working on secure DNS, it should be noted that secure DNS is just weakly secure. Weak security, in general, means just blindly believe infrastructure is secure. As you know, plain DNS is weakly secure just blindly believing infrastructures of ISPs and registries (and registrars) along with their directors and employees secure. If some ISP between you and your peer betrays you, your record can be forged by, say, rewriting your reply. If some registry between you and your peer betrays you, your record can be forged by, say, redirection to wrong NS addresses. There are numerous ways to hide the forgery from casual inspection by you. Fortunately, weak security is just enough for most purposes that we can live with plain DNS. Instead, if you use secure DNS, you no longer believe ISP infrastructure secure but still believe registries secure. If some registry between you and your peer betrays you, your record can be forged by, say, redirection to wrong NS addresses with forged certificates and forged signatures. There are numerous ways to hide the forgery from casual inspection by you. That is, secure DNS is just weakly secure. Fortunately, weak security is just enough for most purposes that we can live with secure DNS. But, why do you bother? Masataka Ohta PS In general, PKI (public key cryptography with third party CAs) is just weakly secure. -- to unsubscribe send a message to namedroppers-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 Mar 13 23:04:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ0mB-0007LB-AV for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 23:04:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ0mA-0001pp-0Y for dnsext-archive@lists.ietf.org; Mon, 13 Mar 2006 23:04:51 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ0id-000F5y-B3 for namedroppers-data@psg.com; Tue, 14 Mar 2006 04:01:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ0ic-000F5i-LM for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 04:01:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 072BA11425 for ; Tue, 14 Mar 2006 04:01:10 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure In-Reply-To: Your message of "Tue, 14 Mar 2006 11:18:28 +0900." <441627F4.10001@necom830.hpcl.titech.ac.jp> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Mar 2006 04:01:10 +0000 Message-Id: <20060314040110.072BA11425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 # ... # Instead, if you use secure DNS, you no longer believe ISP # infrastructure secure but still believe registries secure. # # If some registry between you and your peer betrays you, your # record can be forged by, say, redirection to wrong NS addresses # with forged certificates and forged signatures. there is no kind of cryptographic digital security for which it is untrue that if someone gets your private key material including any passcode you might be using, they can masquerade as you. dnssec is no more secure in that sense than kerberos or pgp or ssh. # There are numerous ways to hide the forgery from casual # inspection by you. # # That is, secure DNS is just weakly secure. # # Fortunately, weak security is just enough for most purposes # that we can live with secure DNS. # # But, why do you bother? here, you have asked the question that leads me to bother answering. why do i lead the struggle to universally deploy BCP38, even though many DDoS attacks will still be possible even if this goal is reached, and many current attacks don't utilize spoofed source addresses? why do i push for bright-line reputation systems whereby a TCP/SMTP source address is either known to sometimes emit spam or known never to do so, even though there's as much spam sent now as before i began? why do i request (and spend) a lot of money adding security features to DNS even though we'll all have to accept and use some untrusted data for the rest of our careers since deployment will never be universal? why, in short, do i try to improve systems where the human element is and will always remain the weak link in the chain? because if nobody works to improve the situation, it WILL NOT improve. # PS # # In general, PKI (public key cryptography with third party CAs) # is just weakly secure. any system with human elements will have all the weaknesses of humanity. but some humans are stronger than others, and we have to give those humans opportunities to excel, and we have to try to work beneficially with those who want to work beneficially with us. i do not envy you the darkness of your world, where these things are not important, or are not tried, or are never successfully accomplished. -- to unsubscribe send a message to namedroppers-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 Mar 14 01:38:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ3BH-0005GP-V5 for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 01:38:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ31f-0006JF-1A for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 01:29:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ2x7-000Lgt-3W for namedroppers-data@psg.com; Tue, 14 Mar 2006 06:24:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ2x6-000Lfp-5r for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 06:24:16 +0000 Received: (qmail 57446 invoked from network); 14 Mar 2006 07:27:09 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 14 Mar 2006 07:27:09 -0000 Message-ID: <44166161.90902@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Mar 2006 15:23:29 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <20060314040110.072BA11425@sa.vix.com> In-Reply-To: <20060314040110.072BA11425@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Paul Vixie wrote: > # If some registry between you and your peer betrays you, your > # record can be forged by, say, redirection to wrong NS addresses > # with forged certificates and forged signatures. > > there is no kind of cryptographic digital security for which it is > untrue that if someone gets your private key material including any > passcode you might be using, they can masquerade as you. So? Your point has nothing to do with my point. > because if nobody works to improve the situation, it WILL NOT improve. Misdirected works to improve the situnation WILL NOT improve 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 Mar 14 03:16:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ4hH-0002W2-Vs for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 03:16:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ4hH-0000xX-Fs for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 03:16:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ4dN-0000ur-P5 for namedroppers-data@psg.com; Tue, 14 Mar 2006 08:12:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [81.228.11.159] (helo=pne-smtpout2-sn1.fre.skanova.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ4dM-0000ue-JB for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 08:12:00 +0000 Received: from arport2v (81.232.45.196) by pne-smtpout2-sn1.fre.skanova.net (7.2.070) id 43F9B8E90051BC07; Tue, 14 Mar 2006 09:11:26 +0100 Message-ID: <00d301c6473e$e3b4cfe0$82c5a8c0@arport2v> From: "Anders Rundgren" To: "Masataka Ohta" Cc: References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <20060314040110.072BA11425@sa.vix.com> <44166161.90902@necom830.hpcl.titech.ac.jp> Subject: Re: Secure DNS is just weakly secure Date: Tue, 14 Mar 2006 09:11:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Working with X.509 PKI, I sometimes get similar input: If some CA is bad they can trick you. This is of course correct. And it will probably even happen. But does this mean that PKI is broken? No, because it will cost the CA to err. I guess the same is valid for a DNS registrar. Since cryptographic keys bind issuers pretty hard to their acts, I don't think this crime is very tempting, since most criminals abstain from activities where you get fully exposed and have to run or hide. Naturally CAs and registrars that cover a wider sector should be accredited in the same way as notaries and lawyers. The most likely problem is that some entity provides fraudulent information tricking the CA or registrar to issue something it should not. Although bad, this is not a high-volume fraud that threatens the Internet, it is only about a single entity. Anders Rundgren ----- Original Message ----- From: "Masataka Ohta" To: "Paul Vixie" Cc: Sent: Tuesday, March 14, 2006 07:23 Subject: Re: Secure DNS is just weakly secure Paul Vixie wrote: > # If some registry between you and your peer betrays you, your > # record can be forged by, say, redirection to wrong NS addresses > # with forged certificates and forged signatures. > > there is no kind of cryptographic digital security for which it is > untrue that if someone gets your private key material including any > passcode you might be using, they can masquerade as you. So? Your point has nothing to do with my point. > because if nobody works to improve the situation, it WILL NOT improve. Misdirected works to improve the situnation WILL NOT improve 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: -- to unsubscribe send a message to namedroppers-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 Mar 14 03:25:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ4qH-0006dC-Nh for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 03:25:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ4qG-0001DP-Eo for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 03:25:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ4oV-0001UU-K4 for namedroppers-data@psg.com; Tue, 14 Mar 2006 08:23:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ4oU-0001UD-BI for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 08:23:30 +0000 Received: (qmail 59781 invoked from network); 14 Mar 2006 09:26:47 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 14 Mar 2006 09:26:47 -0000 Message-ID: <44167D6A.9030002@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Mar 2006 17:23:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Anders Rundgren CC: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <20060314040110.072BA11425@sa.vix.com> <44166161.90902@necom830.hpcl.titech.ac.jp> <00d301c6473e$e3b4cfe0$82c5a8c0@arport2v> In-Reply-To: <00d301c6473e$e3b4cfe0$82c5a8c0@arport2v> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Anders Rundgren wrote: > Working with X.509 PKI, I sometimes get similar input: > If some CA is bad they can trick you. > > This is of course correct. And it will probably even happen. > But does this mean that PKI is broken? > > No, So, the conclusions in my original mail are: Fortunately, weak security is just enough for most purposes that we can live with plain DNS. Fortunately, weak security is just enough for most purposes that we can live with secure DNS. and the quesiton is: But, why do you bother? > because it will cost the CA to err. I guess the same is > valid for a DNS registrar. and an ISP. 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 Mar 14 04:09:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ5X0-0002S0-3l for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 04:09:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ5Wy-0002lN-I8 for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 04:09:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ5RF-0000kI-8F for namedroppers-data@psg.com; Tue, 14 Mar 2006 09:03:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ5RE-0000k5-5A for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 09:03:32 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 7DAC123FDF; Tue, 14 Mar 2006 10:03:35 +0100 (CET) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 972B323EFC for ; Tue, 14 Mar 2006 10:03:34 +0100 (CET) Received: from brettxp2 (brett-xp2.singel.ripe.net [193.0.2.180]) by herring.ripe.net (Postfix) with ESMTP id 9465A2F59A for ; Tue, 14 Mar 2006 10:03:34 +0100 (CET) From: "Brett Carr" To: Subject: RE: Secure DNS is just weakly secure Date: Tue, 14 Mar 2006 10:05:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <44166161.90902@necom830.hpcl.titech.ac.jp> Thread-Index: AcZHMIo+OGGh6thOTYSvx0q2BrjaiwAFXduw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20060314090334.9465A2F59A@herring.ripe.net> X-RIPE-Spam-Level: X-RIPE-Spam-Tests: BAYES_00,MSGID_FROM_MTA_ID X-RIPE-Spam-Status: N 0.000001 / -0.9 X-RIPE-Signature: 6cbcf061a401ef11b146182313f988f3 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Masataka Ohta > Sent: Tuesday, March 14, 2006 7:23 AM > To: Paul Vixie > Cc: namedroppers@ops.ietf.org > Subject: Re: Secure DNS is just weakly secure > > Paul Vixie wrote: > > > # If some registry between you and your peer betrays you, your # > > record can be forged by, say, redirection to wrong NS > addresses # with > > forged certificates and forged signatures. > > > > there is no kind of cryptographic digital security for which it is > > untrue that if someone gets your private key material including any > > passcode you might be using, they can masquerade as you. > > So? Your point has nothing to do with my point. > > > because if nobody works to improve the situation, it WILL > NOT improve. > > Misdirected works to improve the situnation WILL NOT improve it. > Well I'm sure the people who worked on designing dnssec and those of us currently deploying it do not believe they are misdirected. Of course the IETF is an open communtity so you are perfectly free to come up with a solution that is better than we currently have. Brett.. -- to unsubscribe send a message to namedroppers-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 Mar 14 06:14:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ7Tz-0008Kl-Cv for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 06:14:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ7Tx-0005mx-0A for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 06:14:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ7Qp-0006uw-Af for namedroppers-data@psg.com; Tue, 14 Mar 2006 11:11:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=ham version=3.1.0 Received: from [131.111.8.130] (helo=ppsw-0.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ7Qm-0006uk-VV for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 11:11:13 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:46929) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FJ7Qi-0003A9-1a (Exim 4.54) (return-path ); Tue, 14 Mar 2006 11:11:08 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FJ7Qi-0005q1-Er (Exim 4.53) (return-path ); Tue, 14 Mar 2006 11:11:08 +0000 Date: Tue, 14 Mar 2006 11:11:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Masataka Ohta cc: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure In-Reply-To: <441627F4.10001@necom830.hpcl.titech.ac.jp> Message-ID: References: <441627F4.10001@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Tue, 14 Mar 2006, Masataka Ohta wrote: > > But, why do you bother? DNSSEC reduces the number of possible attacks. In particular, it protects you from attacks from random third party hackers. If you are wanting to talk to my domain dotat.at, then in order to do so you are implicitly trusting all the infrastructure behind that domain, including NIC.AT, chiark, me, etc. This is unavoidable if you want to talk to me. Tony. -- f.a.n.finch http://dotat.at/ LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: SOUTH OR SOUTHWEST 4 OR 5, BECOMING VARIABLE THEN EAST 4 OVERNIGHT. OCCASIONAL SHOWERS IN THE WEST. MODERATE OR GOOD, BUT WITH FOG PATCHES CLOSE TO SHORE OVERNIGHT. SLIGHT OR MODERATE, BUT ROUGH AT FIRST IN THE WEST. -- to unsubscribe send a message to namedroppers-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 Mar 14 08:39:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ9kj-0007zZ-0C for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 08:39:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ9kd-0001P2-LV for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 08:39:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ9hi-000GE8-Fb for namedroppers-data@psg.com; Tue, 14 Mar 2006 13:36:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.127.133.22] (helo=mail7.mdx.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ9hh-000GDs-Cr for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 13:36:49 +0000 Received: by mail7.mdx.safepages.com (Postfix, from userid 1012) id F207E1BC9FC; Tue, 14 Mar 2006 13:36:51 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.64]) by mail7.mdx.safepages.com (Postfix) with ESMTP id 5EDA01BCADB; Tue, 14 Mar 2006 13:36:44 +0000 (GMT) Message-ID: <4416CFB1.8070502@connotech.com> Date: Tue, 14 Mar 2006 09:14:09 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Finch CC: Masataka Ohta , namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Tony Finch wrote: > > DNSSEC reduces the number of possible attacks. In particular, it protects > you from attacks from random third party hackers. > Indeed. This is called end-to-end security. Cryptographically merely shifts "control". With the DNSSEC use of digital signatures, cryptography shifts control from the set of DNS distributed components (e.g. caching nameservers where efficient control means are unavailable), to just a few, i.e. the registries from the queried DNS name up to the root (or island of security). This leaves registry operators as the human link. Obvisouly, the end-user systems remain as a target of trojan horse attacks and the like. DNSSEC does provide an intrinsicly valuable information control mechanism, assuming the zone walking and trust anchor key management issues are resolved. Whether application use of DNSSEC is justified on a cost-benefit analysis remains an open question. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 14 09:00:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJA4j-0002Ru-7Z for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 09:00:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJA4g-0001u2-LH for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 09:00:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJA33-000HnV-KW for namedroppers-data@psg.com; Tue, 14 Mar 2006 13:58:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJA32-000Hn4-C7 for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 13:58:52 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id BE2514562; Tue, 14 Mar 2006 14:58:45 +0100 (CET) Date: Tue, 14 Mar 2006 14:58:45 +0100 From: bert hubert To: Thierry Moreau Cc: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure Message-ID: <20060314135845.GB1130@outpost.ds9a.nl> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4416CFB1.8070502@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4416CFB1.8070502@connotech.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Tue, Mar 14, 2006 at 09:14:09AM -0500, Thierry Moreau wrote: > issues are resolved. Whether application use of DNSSEC is justified on a > cost-benefit analysis remains an open question. This makes me think of a pet project of mine, 'ARPSEC'. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Mar 14 09:45:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAmd-0007fO-98 for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 09:45:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJAmb-0003Fk-W6 for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 09:45:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJAkA-000Khv-Tp for namedroppers-data@psg.com; Tue, 14 Mar 2006 14:43:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJAkA-000Khj-8T for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 14:43:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9AE7011425 for ; Tue, 14 Mar 2006 14:43:25 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure In-Reply-To: Your message of "Tue, 14 Mar 2006 15:23:29 +0900." <44166161.90902@necom830.hpcl.titech.ac.jp> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <20060314040110.072BA11425@sa.vix.com> <44166161.90902@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Mar 2006 14:43:25 +0000 Message-Id: <20060314144325.9AE7011425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 # > # If some registry between you and your peer betrays you, your # > # record can be forged by, say, redirection to wrong NS addresses # > # with forged certificates and forged signatures. # > # > there is no kind of cryptographic digital security for which it is # > untrue that if someone gets your private key material including any # > passcode you might be using, they can masquerade as you. # # So? Your point has nothing to do with my point. i thought that you might think that. # > because if nobody works to improve the situation, it WILL NOT improve. # # Misdirected works to improve the situnation WILL NOT improve it. "misdirected" is the assertion under discussion here. there are threats to dns authenticity for which DNSSEC-bis is good protection. there will always be other or new threats not answered by a particular technology. as with spam and ddos, there will never be a final and ultimate solution to all problems related to DNS insecurity -- merely a long chain of point-solutions. -- to unsubscribe send a message to namedroppers-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 Mar 14 09:54:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJAuu-0003Lq-71 for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 09:54:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJAus-0003W8-SE for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 09:54:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJAtR-000LKB-Lx for namedroppers-data@psg.com; Tue, 14 Mar 2006 14:53:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJAtQ-000LJp-Pj for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 14:53:01 +0000 Received: from [10.31.32.57] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2EEqmtX026187; Tue, 14 Mar 2006 09:52:49 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <441627F4.10001@necom830.hpcl.titech.ac.jp> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Mar 2006 09:52:51 -0500 To: Masataka Ohta From: Edward Lewis Subject: Re: Secure DNS is just weakly secure Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 At 11:18 +0900 3/14/06, Masataka Ohta wrote: Q: >But, why do you bother? A: >Fortunately, weak security is just enough for most purposes >that we can live with secure DNS. Q: Why would you want to *over* secure something? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 14 11:17:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCDG-0001N4-Nt for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 11:17:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJCDF-0006H3-E2 for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 11:17:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJCA0-0000x0-6r for namedroppers-data@psg.com; Tue, 14 Mar 2006 16:14:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [131.111.8.139] (helo=ppsw-9.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJC9r-0000w3-9M for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 16:14:03 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from virgo.cus.cam.ac.uk ([131.111.8.20]:40229) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FJC9T-0007Gs-Uy (Exim 4.54) for namedroppers@ops.ietf.org (return-path ); Tue, 14 Mar 2006 16:13:39 +0000 Received: from cet1 by virgo.cus.cam.ac.uk with local (Exim 4.60) (envelope-from ) id 1FJC9T-0000LC-GS for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 16:13:39 +0000 Subject: Re: Secure DNS is just weakly secure To: namedroppers@ops.ietf.org Date: Tue, 14 Mar 2006 16:13:39 +0000 (GMT) In-Reply-To: <44167D6A.9030002@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Mar 14, 6 05:23:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1286 Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Masataka Ohta writes > So, the conclusions in my original mail are: > > Fortunately, weak security is just enough for most purposes > that we can live with plain DNS. > > Fortunately, weak security is just enough for most purposes > that we can live with secure DNS. I suppose this represents progress, of a sort. You have argued in the past that DNSSEC will be _less_ secure (because of the extra complexity of the implementations). > and the quesiton is: > > But, why do you bother? I would like to address that question to you. It's not as though everyone following this list doesn't know that you think DNSSEC worthless, if not postively malign. I recall extended threads on the subject in Jan-Feb 2004, May-Jun 2004, Mar 2005. Of course, you have every right to keep on reminding us of this. But I do wonder whether you feel you are actually making converts to your point of view. I see little sign of that on the list itself. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 14 11:20:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCG3-0003no-2l for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 11:20:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJCG0-0006K8-JN for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 11:20:27 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJCDv-0001K1-HC for namedroppers-data@psg.com; Tue, 14 Mar 2006 16:18:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJCDu-0001Ja-8r for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 16:18:14 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1EC5C33C1C; Tue, 14 Mar 2006 16:18:12 +0000 (GMT) Message-ID: <4416ECCB.10905@algroup.co.uk> Date: Tue, 14 Mar 2006 16:18:19 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Masataka Ohta CC: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> In-Reply-To: <441627F4.10001@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Masataka Ohta wrote: > If some registry between you and your peer betrays you, your > record can be forged by, say, redirection to wrong NS addresses > with forged certificates and forged signatures. There is no requirement in DNSSEC to trust the registry. If you would prefer to trust your peer, then you should add his key as a trusted key to your resolver. This is the same as PKI - if you don't trust the CA, then do your own key validation. BTW, I would say that "forged" is not the word to use in the scenario you describe, since they are correctly constructed and genuine certificates/signatures. A better description would be "incorrect certificates with correct signatures". Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 14 17:21:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJHti-0002jJ-Ju for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 17:21:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJHtg-0007qb-QK for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 17:21:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJHnG-000Kqt-Jg for namedroppers-data@psg.com; Tue, 14 Mar 2006 22:15:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJHnF-000Kq7-Mc for namedroppers@ops.ietf.org; Tue, 14 Mar 2006 22:15:06 +0000 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3) with ESMTP id k2EMEpxf014130 for ; Tue, 14 Mar 2006 23:14:51 +0100 From: Simon Josefsson To: namedroppers@ops.ietf.org Subject: Proposed RFC 2538bis AUTH48 problem resolution OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060314:namedroppers@ops.ietf.org::KvPwHxVkwQkDNVTy:HKcQ Date: Tue, 14 Mar 2006 23:14:48 +0100 Message-ID: <8764mgekrr.fsf@latte.josefsson.org> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Dear WG: RFC 4398 (2538bis) has been in the AUTH48 state with the RFC Editor for some time now, pending a problem the GnuPG developers found when implement support for storing PGP data in CERT records. This e-mail describe the problem and propose how to solve it, so we can get the document out. The problem is that it is impossible to strongly identify the intended OpenPGP key based on the URL in the IPGP type from any DNSSEC trust, i.e., you don't know that what you download from the URL contains the DNSSEC-trusted OpenPGP key. The solution to this is add a field to the IPGP type that contain the OpenPGP key fingerprint. This is David Shaw's proposal. What remains is to deal with the other indirect I* types. The problem is similar to all of them, you may need a hash of the URL data to bridge DNSSEC trust further. We believe nobody care about SPKI strongly enough to care about ISPKI, so we wish to postpone the definition of both SPKI and ISPKI until later. For IPKIX and IACPKIX, the problem isn't as applicable because X.509 certs are self-authentication and in particular RFC 4387 describe URL access that can embed hashes of the certificate. We propose to keep the IPKIX and IACPKIX types, but note that if someone need a hash inside those CERT sub-types, such new sub-types can be specified in the future. Here are the proposed changes that will be sent to the RFC editor unless someone has a better suggestion. Please, please, review RFC 4398: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4398.txt with the patch below for consistency. Thanks, Simon Section 2.1, OLD: 6 IPGP The URL of an OpenPGP packet NEW: 6 IPGP The fingerprint and URL of an OpenPGP packet OLD: The SPKI type is reserved to indicate the SPKI certificate format [15], for use when the SPKI documents are moved from experimental status. NEW: The SPKI and ISPKI type is reserved to indicate the SPKI certificate format [15], for use when the SPKI documents are moved from experimental status. The format for these two CERT RR types will need to be specified later. OLD: The IPKIX, ISPKI, IPGP, and IACPKIX types indicate a URL that will serve the content that would have been in the "certificate, CRL, or URL" field of the corresponding types; PKIX, SPKI, PGP, or ACPKIX respectively. The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect". NEW: The IPKIX and IACPKIX types indicate a URL that will serve the content that would have been in the "certificate, CRL, or URL" field of the corresponding types; PKIX or ACPKIX respectively. The IPGP type contains both an OpenPGP fingerprint for the key in question, as well as a URL. The certificate portion of the IPGP CERT RR is defined as a one-octet fingerprint length, followed by the OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is calculated as defined in RFC-2440 [5]. A zero-length fingerprint or a zero-length URL are legal, and indicate URL-only IPGP data or fingerprint-only IPGP data respectively. A zero-length fingerprint and a zero-length URL is meaningless and invalid. The IPKIX, ISPKI, IPGP and IACPKIX types are known as "indirect". Section 8, OLD: 6 IPGP The URL of an OpenPGP packet RFC 4398 NEW: 6 IPGP The fingerprint and URL RFC 4398 of an OpenPGP 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 Tue Mar 14 22:01:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJMGR-0002T0-39 for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 22:01:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJMGP-0007dK-J5 for dnsext-archive@lists.ietf.org; Tue, 14 Mar 2006 22:01:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJMD5-000E2o-Nu for namedroppers-data@psg.com; Wed, 15 Mar 2006 02:58:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJMD4-000E2W-Ni for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 02:58:03 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2F2vZnJ028994; Tue, 14 Mar 2006 21:57:38 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060314215134.03b3d8e0@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 Mar 2006 21:57:28 -0500 To: Simon Josefsson , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Proposed RFC 2538bis AUTH48 problem resolution Cc: Margaret Wasserman In-Reply-To: <8764mgekrr.fsf@latte.josefsson.org> References: <8764mgekrr.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Thanks Simon, for your diligent work on bringing this issue to resolution. Unless someone speaks up that this is unacceptable, the WG chairs will inform the AD that making these text changes is supported by the working group and recommend RFC2338bis be publish with these changes. Speak up before Tuesday March 21'st. Olafur. At 17:14 14/03/2006, Simon Josefsson wrote: >Dear WG: > >RFC 4398 (2538bis) has been in the AUTH48 state with the RFC Editor >for some time now, pending a problem the GnuPG developers found when >implement support for storing PGP data in CERT records. This e-mail >describe the problem and propose how to solve it, so we can get the >document out. > >The problem is that it is impossible to strongly identify the intended >OpenPGP key based on the URL in the IPGP type from any DNSSEC trust, >i.e., you don't know that what you download from the URL contains the >DNSSEC-trusted OpenPGP key. > >The solution to this is add a field to the IPGP type that contain the >OpenPGP key fingerprint. This is David Shaw's proposal. > >What remains is to deal with the other indirect I* types. The problem >is similar to all of them, you may need a hash of the URL data to >bridge DNSSEC trust further. We believe nobody care about SPKI >strongly enough to care about ISPKI, so we wish to postpone the >definition of both SPKI and ISPKI until later. For IPKIX and IACPKIX, >the problem isn't as applicable because X.509 certs are >self-authentication and in particular RFC 4387 describe URL access >that can embed hashes of the certificate. We propose to keep the >IPKIX and IACPKIX types, but note that if someone need a hash inside >those CERT sub-types, such new sub-types can be specified in the >future. > >Here are the proposed changes that will be sent to the RFC editor >unless someone has a better suggestion. > >Please, please, review RFC 4398: > >ftp://ftp.rfc-editor.org/in-notes/authors/rfc4398.txt > >with the patch below for consistency. > >Thanks, >Simon > >Section 2.1, OLD: > > 6 IPGP The URL of an OpenPGP packet > >NEW: > > 6 IPGP The fingerprint and URL of an OpenPGP packet > >OLD: > > The SPKI type is reserved to indicate the SPKI certificate format > [15], for use when the SPKI documents are moved from experimental > status. > >NEW: > > The SPKI and ISPKI type is reserved to indicate the SPKI > certificate format [15], for use when the SPKI documents are moved > from experimental status. The format for these two CERT RR types > will need to be specified later. > >OLD: > > The IPKIX, ISPKI, IPGP, and IACPKIX types indicate a URL that will > serve the content that would have been in the "certificate, CRL, or > URL" field of the corresponding types; PKIX, SPKI, PGP, or ACPKIX > respectively. The IPKIX, ISPKI, IPGP, and IACPKIX types are known > as "indirect". > >NEW: > > The IPKIX and IACPKIX types indicate a URL that will serve the > content that would have been in the "certificate, CRL, or URL" > field of the corresponding types; PKIX or ACPKIX respectively. > > The IPGP type contains both an OpenPGP fingerprint for the key in > question, as well as a URL. The certificate portion of the IPGP > CERT RR is defined as a one-octet fingerprint length, followed by > the OpenPGP fingerprint, followed by the URL. The OpenPGP > fingerprint is calculated as defined in RFC-2440 [5]. A > zero-length fingerprint or a zero-length URL are legal, and > indicate URL-only IPGP data or fingerprint-only IPGP data > respectively. A zero-length fingerprint and a zero-length URL is > meaningless and invalid. > > The IPKIX, ISPKI, IPGP and IACPKIX types are known as "indirect". > > >Section 8, OLD: > > 6 IPGP The URL of an OpenPGP packet RFC 4398 > >NEW: > > 6 IPGP The fingerprint and URL RFC 4398 > of an OpenPGP 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 Wed Mar 15 04:40:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSU5-0005Tf-SW for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 04:40:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSU3-0002Sa-CH for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 04:40:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJSQL-000Flp-2E for namedroppers-data@psg.com; Wed, 15 Mar 2006 09:36:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJSQK-000Flc-CC for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 09:36:08 +0000 Received: (qmail 75994 invoked from network); 15 Mar 2006 10:39:44 -0000 Received: from p2014-ipad04yosemiya.okinawa.ocn.ne.jp (HELO necom830.hpcl.titech.ac.jp) (221.188.206.14) by necom830.hpcl.titech.ac.jp with SMTP; 15 Mar 2006 10:39:44 -0000 Message-ID: <4417DFED.30309@necom830.hpcl.titech.ac.jp> Date: Wed, 15 Mar 2006 18:35:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Thierry Moreau CC: Tony Finch , namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4416CFB1.8070502@connotech.com> In-Reply-To: <4416CFB1.8070502@connotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Thierry Moreau wrote: > Tony Finch wrote: >> DNSSEC reduces the number of possible attacks. In particular, it protects >> you from attacks from random third party hackers. First, random third party hackers would rather prefer attacks on security holes of complex implementations of complex protocols. Secondly, ISPs and DNS cache services you might use may be third parties but not random third parties. > Indeed. This is called end-to-end security. Cryptographically > merely shifts "control". Secure DNS removes "control" of ISPs, which are as reliable as registries, but still leaves "control" of registries. > With the DNSSEC use of digital signatures, > cryptography shifts control from the set of DNS distributed components > (e.g. caching nameservers where efficient control means are > unavailable), to just a few, i.e. the registries from the queried DNS > name up to the root (or island of security). Not at all. Chaching nameservers can be secure. As I have pointed out more than ten years ago, cache contamination of caching nameservers can be avoided by having tagged cache for glues with the information for which zone the glue is provided. Though, for efficiency, glues should be cached, the cached information should be used only as glues for the same referal. For example, if the zone "hpcl.titech.ac.jp" has the following referral and glue: hpcl.titech.ac.jp NS cypress.neustar.com cypress.neustar.com A 131.112.32.132 the glue A may be cached for referral reply to queries at or below "hpcl.titech.ac.jp" but should not be used to reply queries to "ietf.org" ("cypress.neustar.com" is a NS for "ietf.org") or any other purposed. This is the way how proper "control" is maintained with plain DNS. > This leaves registry operators as the human link. And the registry operators are as reliable as ISP operators. So, why do you bother? 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 Mar 15 04:46:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJSaQ-00006d-Di for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 04:46:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJSaQ-0002bB-4y for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 04:46:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJSYm-000GUO-3g for namedroppers-data@psg.com; Wed, 15 Mar 2006 09:44:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJSYl-000GUC-FH for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 09:44:51 +0000 Received: (qmail 76102 invoked from network); 15 Mar 2006 10:48:27 -0000 Received: from p2014-ipad04yosemiya.okinawa.ocn.ne.jp (HELO necom830.hpcl.titech.ac.jp) (221.188.206.14) by necom830.hpcl.titech.ac.jp with SMTP; 15 Mar 2006 10:48:27 -0000 Message-ID: <4417E1F9.1040406@necom830.hpcl.titech.ac.jp> Date: Wed, 15 Mar 2006 18:44:25 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Ben Laurie CC: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4416ECCB.10905@algroup.co.uk> In-Reply-To: <4416ECCB.10905@algroup.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Ben Laurie wrote: > There is no requirement in DNSSEC to trust the registry. If you would > prefer to trust your peer, then you should add his key as a trusted key > to your resolver. Indeed, there is no requirement in security to use DNSSEC. If I can receive key from my peer privately in trusted way, which is your requirement, I rather use shared key. > This is the same as PKI - if you don't trust the CA, then do your own > key validation. Yes, I do, but, it means PKI hardly is an infrastructure. 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 Mar 15 05:16:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJT3d-0007ZY-Lg for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 05:16:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJT3b-0003Rv-6M for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 05:16:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJT1C-000IxG-Ae for namedroppers-data@psg.com; Wed, 15 Mar 2006 10:14:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.54.233.67] (helo=wendolene.rfc1035.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJT1B-000Ix1-Es for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 10:14:13 +0000 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by wendolene.rfc1035.com (8.12.10/8.12.10) with ESMTP id k2FADsFN029956; Wed, 15 Mar 2006 10:13:54 GMT In-Reply-To: <4417DFED.30309@necom830.hpcl.titech.ac.jp> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4416CFB1.8070502@connotech.com> <4417DFED.30309@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30163CB7-40EA-4694-BE41-19AD17666712@rfc1035.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: Secure DNS is just weakly secure Date: Wed, 15 Mar 2006 10:13:48 +0000 To: Masataka Ohta X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On Mar 15, 2006, at 09:35, Masataka Ohta wrote: > First, random third party hackers would rather prefer attacks on > security holes of complex implementations of complex protocols. AHA! So that explains why X.509 certificates, crypto hash algorithms and PGP are forever being compromised by random third party attackers while unsecured Windows desktops are ignored. Your point about complexity being the enemy of security is well made. However vanilla flavour DNS is a complex protocol that's hard to implement, let alone interoperate with the installed base. It's already far beyond the point where security people would be comfortable. > Secondly, ISPs and DNS cache services you might use may be third > parties but not random third parties. So what? If they can't be trusted, I take my secure DNS resolution business elsewhere. Economic Darwinism takes its course. Problem solved. > As I have pointed out more than ten years ago, cache contamination of > caching nameservers can be avoided by having tagged cache for glues > with the information for which zone the glue is provided. That might minimise the impact of one attack vector. However there are plenty of other ways of poisoning a cache. As you should know. These attacks are not ameliorated by tagging glue. Besides, a fix for cache poisoning doesn't solve the DNS security problem. It's not even close. -- to unsubscribe send a message to namedroppers-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 Mar 15 05:25:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTBb-0003aj-Vt for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 05:24:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJTBb-0003jz-Hl for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 05:24:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJT9w-000Jgi-A8 for namedroppers-data@psg.com; Wed, 15 Mar 2006 10:23:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJT9v-000JgU-Cc for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 10:23:15 +0000 Received: from [IPv6:2001:620:20:1000:202:55ff:fee6:21e8] (unknown [IPv6:2001:620:20:1000:202:55ff:fee6:21e8]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 5C8B78070; Wed, 15 Mar 2006 11:23:05 +0100 (CET) Subject: Re: Secure DNS is just weakly secure From: Jeroen Massar To: Masataka Ohta Cc: Thierry Moreau , Tony Finch , namedroppers@ops.ietf.org In-Reply-To: <4417DFED.30309@necom830.hpcl.titech.ac.jp> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4416CFB1.8070502@connotech.com> <4417DFED.30309@necom830.hpcl.titech.ac.jp> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qOEPiIzUU1AONtZ6gIde" Organization: Unfix Date: Wed, 15 Mar 2006 11:23:00 +0100 Message-Id: <1142418181.4632.63.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --=-qOEPiIzUU1AONtZ6gIde Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-03-15 at 18:35 +0900, Masataka Ohta wrote: > Thierry Moreau wrote: >=20 > > Tony Finch wrote: [..] > > With the DNSSEC use of digital signatures,=20 > > cryptography shifts control from the set of DNS distributed components=20 > > (e.g. caching nameservers where efficient control means are=20 > > unavailable), to just a few, i.e. the registries from the queried DNS=20 > > name up to the root (or island of security). >=20 > Not at all. Chaching nameservers can be secure. >=20 > As I have pointed out more than ten years ago, cache contamination of > caching nameservers can be avoided by having tagged cache for glues > with the information for which zone the glue is provided. >=20 > Though, for efficiency, glues should be cached, the cached information > should be used only as glues for the same referal. >=20 > For example, if the zone "hpcl.titech.ac.jp" has the following referral > and glue: >=20 > hpcl.titech.ac.jp NS cypress.neustar.com > cypress.neustar.com A 131.112.32.132 >=20 > the glue A may be cached for referral reply to queries at or below > "hpcl.titech.ac.jp" but should not be used to reply queries to > "ietf.org" ("cypress.neustar.com" is a NS for "ietf.org") or any > other purposed. >=20 > This is the way how proper "control" is maintained with plain DNS. And thus I simply inject a caching DNS server with the above DNS response, even though it didn't ask for it and tada your cache is poisend. Thus why bother? It avoids many many many attacks. > > This leaves registry operators as the human link. >=20 > And the registry operators are as reliable as ISP operators. And there are only few registry operators compared to many ISP's. Making only a few registry places vulnerable to any attack instead of many unknown attack vectors over the many ISP's. (No I am not stating that registries are secure, far from) > So, why do you bother? No bothering is happening, just apt-get update and get over it ;) Long live DNSSEC! Greets, Jeroen --=-qOEPiIzUU1AONtZ6gIde Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBEF+sEKaooUjM+fCMRAmfiAJ9G56FVtR5y54txlOAyUlaJ0FvErACgn37+ NVn9dJ8RDXbMUnC1HYnWqCI= =8aQq -----END PGP SIGNATURE----- --=-qOEPiIzUU1AONtZ6gIde-- -- to unsubscribe send a message to namedroppers-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 Mar 15 06:02:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTlx-0005mS-N1 for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 06:02:33 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJTlw-00050m-Du for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 06:02:33 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJTis-000M9A-EB for namedroppers-data@psg.com; Wed, 15 Mar 2006 10:59:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJTir-000M8o-NR for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 10:59:22 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2B48E33C3F; Wed, 15 Mar 2006 10:59:20 +0000 (GMT) Message-ID: <4417F390.8000400@algroup.co.uk> Date: Wed, 15 Mar 2006 10:59:28 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Masataka Ohta CC: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4416ECCB.10905@algroup.co.uk> <4417E1F9.1040406@necom830.hpcl.titech.ac.jp> In-Reply-To: <4417E1F9.1040406@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Masataka Ohta wrote: > Ben Laurie wrote: > >> There is no requirement in DNSSEC to trust the registry. If you would >> prefer to trust your peer, then you should add his key as a trusted key >> to your resolver. > > Indeed, there is no requirement in security to use DNSSEC. > > If I can receive key from my peer privately in trusted way, > which is your requirement, I rather use shared key. Then: a) You could masquerade as your peer, which doesn't sound good to me - or your peer needs a key for each of his peers, which doesn't sound good either. b) You'd need to use a different standard. >> This is the same as PKI - if you don't trust the CA, then do your own >> key validation. > > Yes, I do, but, it means PKI hardly is an infrastructure. You will get no argument from me on that point. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 15 06:10:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJTtq-00014T-SM for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 06:10:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJTtp-0005Uv-E3 for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 06:10:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJTrd-000Mmc-CQ for namedroppers-data@psg.com; Wed, 15 Mar 2006 11:08:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJTrc-000MmO-Mt for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 11:08:25 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2FB8MEj052834 for ; Wed, 15 Mar 2006 12:08:22 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <441627F4.10001@necom830.hpcl.titech.ac.jp> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-11-904945076" Message-Id: Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Secure DNS is just weakly secure Date: Wed, 15 Mar 2006 12:08:22 +0100 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-11-904945076 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear colleagues, From this thread I do not see any consensus to request that DNSSEC work items are to be removed from our charter. Shall we close this discussion and get back to work. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-11-904945076 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEF/WmtN/ca3YJIocRAv0OAJ9CzXyyTcCDH6J3gauITITRrenOPACgt2rl F4S2ZaElha7XZfPjsuGDqNo= =Ngj+ -----END PGP SIGNATURE----- --Apple-Mail-11-904945076-- -- to unsubscribe send a message to namedroppers-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 Mar 15 08:36:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWAe-000522-9p for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 08:36:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJWAd-0001A7-0z for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 08:36:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJW7w-0007iO-Nm for namedroppers-data@psg.com; Wed, 15 Mar 2006 13:33:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJW7w-0007iC-1o for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 13:33:24 +0000 Received: (qmail 78520 invoked from network); 15 Mar 2006 14:37:03 -0000 Received: from p2014-ipad04yosemiya.okinawa.ocn.ne.jp (HELO necom830.hpcl.titech.ac.jp) (221.188.206.14) by necom830.hpcl.titech.ac.jp with SMTP; 15 Mar 2006 14:37:03 -0000 Message-ID: <4418178A.3040202@necom830.hpcl.titech.ac.jp> Date: Wed, 15 Mar 2006 22:32:58 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Namedroppers Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Olaf M. Kolkman wrote: > From this thread I do not see any consensus to request that DNSSEC > work items are to be removed from our charter. Who requested such a stupid request? At least, Paul Vixie demostrated that there are a lot of people including powerful implememters, who don't understand secure DNS dose not improve security. So, we should continue discussion until DNSSEC work items are removed from our charter. > Shall we close this discussion and get back to work. Indeed, we are readly to work to shutdown works on secure DNS. 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 Mar 15 08:59:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWX5-000781-8H for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 08:59:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJWX3-0001oK-Nm for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 08:59:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJWTo-0009dz-3Q for namedroppers-data@psg.com; Wed, 15 Mar 2006 13:56:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [207.71.200.29] (helo=itchy.wiggum.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJWTn-0009dl-07 for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 13:55:59 +0000 Received: from [10.1.11.250] (netblock-72-25-98-11.dslextreme.com [72.25.98.11]) by itchy.wiggum.com (Postfix) with ESMTP id AF7431B01F9; Wed, 15 Mar 2006 05:55:58 -0800 (PST) In-Reply-To: <4418178A.3040202@necom830.hpcl.titech.ac.jp> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4418178A.3040202@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DE3171B-BCBC-44E6-BB48-50CACBAEA17E@wiggum.com> Cc: "Olaf M. Kolkman" , Namedroppers Content-Transfer-Encoding: 7bit From: Sean Leach Subject: Re: Secure DNS is just weakly secure Date: Wed, 15 Mar 2006 05:55:56 -0800 To: Masataka Ohta X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Mar 15, 2006, at 5:32 AM, Masataka Ohta wrote: >> Shall we close this discussion and get back to work. > > Indeed, we are readly to work to shutdown works on secure DNS. Then stop working on it. Those of us that would LIKE to continue working on it will. Olaf - I would say this thread has outlived it's usefulness. > > 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: -- to unsubscribe send a message to namedroppers-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 Mar 15 09:55:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXPa-0002bH-FE for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 09:55:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJXPa-0003Sr-5Z for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 09:55:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJXMm-000EAM-LS for namedroppers-data@psg.com; Wed, 15 Mar 2006 14:52:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJXMl-000EA9-Su for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 14:52:48 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2FEqZPR031963; Wed, 15 Mar 2006 09:52:35 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060315094107.03b98de0@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 15 Mar 2006 09:52:20 -0500 To: Margaret Wasserman , Mark Townsley From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Publication Request: LLMNR-45 to Informational Cc: namedroppers@ops.ietf.org, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Dear Margaret and Mark, This is in response to your request to have the DNSEXT working group fix the problems that were brought up during the IETF Last Call and in IESG review[1]. We asked the working group a set of detailed questions [2]. We have to report that there was some discussion on the list but there was not sufficient quorum[3] during our working group last call to determine consensus on the last version of the document. This means that we as a working group can not provide satisfactory answers to these questions. However, we, chairs, think this document has gone to a large number of cycles where it has received reviews been commented upon and addressed number of issues that have broader significance. The WG thinks that this document should not be lost. We, chairs, suggest it is to be published as working group produced informational document. The DNSEXT work group has discussed the "API" question a bit. There has not yet been sufficient discussion to tell if there is agreement on adding such a work item to the working group. We the chairs think there should be a requirements document and/or comprehensive straw-man proposal on the table, what needs to be captured are the architectural requirements with respect to the name space and security status of resolved names. We think such a working item is useful both in the LLMNR and MDNS context as well as for secure resolution, but we also need sufficient number of people to show interest before the work is added to the charter. This has been a difficult call. And our question to one of the PROTO questions would be: "Yes there might be an appeal". --Olafur and Olaf. [1] https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6193&rfc_flag=0 [2] http://psg.com/lists/namedroppers/namedroppers.2006/msg00028.html [3] http://psg.com/lists/namedroppers/namedroppers.2006/msg00145.html -- to unsubscribe send a message to namedroppers-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 Mar 15 13:10:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJaRd-0000Sw-Dd for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 13:10:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJaRb-0002BU-TG for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 13:10:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJaKy-0000XR-Mk for namedroppers-data@psg.com; Wed, 15 Mar 2006 18:03:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJaKx-0000X0-6L for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 18:03:07 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 15 Mar 2006 18:03:08 +0000 X-IronPort-AV: i="4.02,195,1139184000"; d="scan'208"; a="3123657:sNHT27420012" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k2FI37YO018297 for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 18:03:07 GMT Date: Wed, 15 Mar 2006 18:03:07 GMT From: Geoffrey Sisson Message-Id: <200603151803.k2FI37YO018297@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: Review of draft-ietf-dnsext-dnssec-experiments-02 In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I have reviewed draft-ietf-dnsext-dnssec-experiments-02 and believe it is ready to be forwarded to the IESG for consideration for publication as a standards-track RFC. Nits: - Should RFC 2119 be a normative reference rather than informative? - "DNSSEC-aware" is presumably the same thing as "security-aware" in RFC 4033, but it may be a good idea to state this explicitly. - In Section 4, second-to-last paragraph, "experiments" should be "experiment's" (with apostrophe). - In Section 5, paragraph 2, "may" should probably be "MAY". Suggestions: - In Section 6.1, change "the not validatable response" to "a non-validatable response"? - In Section 6.2, change "not aware" to "unaware"? Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 15 13:11:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJaTD-0000oL-Gn for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 13:11:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJaTC-0002Dx-74 for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 13:11:39 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJaRZ-0001C8-N4 for namedroppers-data@psg.com; Wed, 15 Mar 2006 18:09:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [149.8.64.32] (helo=mclmx2.mail.saic.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJaRY-0001Bv-TK for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 18:09:57 +0000 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Wed, 15 Mar 2006 13:09:42 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006031513094200132 ; Wed, 15 Mar 2006 13:09:42 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 15 Mar 2006 13:09:42 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE0DB67366@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: Masataka Ohta Cc: namedroppers@ops.ietf.org Subject: RE: Secure DNS is just weakly secure Date: Wed, 15 Mar 2006 13:02:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 (I know that there have been requests to shut down this thread, so my apologies for continuing it, but...) > Secure DNS removes "control" of ISPs, which are as reliable as > registries, but still leaves "control" of registries. The assertion you make above is not only not provably true, but is in my experience completely false. Many providers of recursive DNS service with which I deal on a regular basis are *much* less reliable than the registries for DNS information that I use on a regular basis. And if you drop that assertion (since it's not generally true) I don't think your argument sheds any useful light. In particular, securing DNS based on shared keys (which you appear to advocate) does not scale well at all and has significant issues due to the inability to strongly correlate a key with a particular individual (since it is by definition shared with others). And if one tries to use public/private key pairs...well whaddaya know, that's what DNSSEC is doing! And yes, there are potential issues if a DNSSEC signing key at a registry is compromised--which is why that's an area of particular interest for me (and others). The good news is that there are, in fact, technologies and procedures that can address such issues. This will be my last message to you in response to one of these threads you occasionally start. Thanks very much for caring about securing DNS--I only wish that your efforts to date had come up with a useful way to address the real (but not fatal) flaws in the DNSSEC extensions as they stand today. I invite you to either propose an actual valid alternative or contribute on updates to the existing RFCs. --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 Mar 15 13:37:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJas3-0006Cw-Bw for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 13:37:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJas2-0002eH-VV for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 13:37:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJap2-0003SK-AY for namedroppers-data@psg.com; Wed, 15 Mar 2006 18:34:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJap1-0003S6-Mh for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 18:34:11 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k2FIYAIV027120; Wed, 15 Mar 2006 18:34:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k2FIYALV027119; Wed, 15 Mar 2006 18:34:10 GMT Date: Wed, 15 Mar 2006 18:34:10 +0000 From: bmanning@vacation.karoshi.com To: namedroppers@ops.ietf.org Cc: bmanning@vacation.karoshi.com Subject: Re: ISSUE 2: Mandatory to implement Message-ID: <20060315183410.GA27023@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa some kind soul said: # Another way of phrasing is: # # This would be the "mandatory to implement" mechanism for everybody who would # want to perform automatic rollover of DNSKEYs. Section 5.6 just says that # you may choose not to perform automatic rollovers. and i guess that i am of two minds here. ) from a DNS protocol perspective, rollover of keys is pretty much out of scope. Its a non-dns issue. the specs are (mostly) done - lets get the show on the road... time's a wasting. however.... ) trust is not a provable mathmatical construct... welcome to faith-based networking! operationally, in the absence of a published method on how a delegation point expects to roll its keys (if ever) will impact how its clients and "passers-by" view the integrity of the zone data. without some rigourous and fairly complete statement by the delegation holder on the issues of rollover, i expect interest in dns with the added majik DNSSEC bits to be lukewarm at best. and therein lies the rub. the IETF (imho) is ill-equiped to dictate operational processes/proceedures. They have never been very good at it and current actions suggest they are not getting better with practice. I'm not really in favor of the the IETF tryingto create YABCP that is late, flawed, and in most other respects out of touch w/ current operational realities. I'd be happy if the IETF limited itself to some simple statement along the lines of "For delegations that chose to implement DNSSEC features, it is suggested that a docuement be made available that describes the key management protocols, including how key-rollover is to be done. Such documentation will be critical for third parties to be able to evaluate the integrity of the chain of trust in following key/signature pairs to a known trust anchor"... --bill (malcontent) -- to unsubscribe send a message to namedroppers-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 Mar 15 14:24:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbbs-0003Dy-07 for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 14:24:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbbp-0004RK-LJ for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 14:24:39 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJbZ1-0009vO-VZ for namedroppers-data@psg.com; Wed, 15 Mar 2006 19:21:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJbZ0-0009vC-OH for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 19:21:43 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2492533C1C for ; Wed, 15 Mar 2006 19:21:41 +0000 (GMT) Message-ID: <4418694E.3030103@algroup.co.uk> Date: Wed, 15 Mar 2006 19:21:50 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: DNSEXT WG Subject: NSD patches available X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 During the pre-workshop we decided to drop support for NSEC3 in BIND and instead to focus on NSD. This was because the complexity of BIND meant we couldn't be sure we'd be feature complete by the workshop in May. I'm glad to say this decision appears to have paid dividends. Patches against NSD 2.3.3 are now available. In order to use them, you'll need a zone signer - either Roy's or David's should work fine, the BIND signer is not correct at present. A resolver is also needed, and to that end, I am also providing patches against BIND that allow dig to display NSEC3 records. The verification code appears to be faulty, so you'll need to use Unbound if you want to do verification other than by hand, but at least it can make queries and display the responses. These can all be found in the NSEC3 subversion repository, at http://www.nsec3.org/ NSD patches: http://www.nsec3.org/cgi-bin/trac.cgi/browser/dnssec/patches/nsd-2.3.3-ben1.diff BIND patches: http://www.nsec3.org/cgi-bin/trac.cgi/browser/dnssec/patches/bind-9.3.1-ws0-2.diff Note that you can download these as text if you scroll all the way to the bottom. There are also example zone, queries and expected responses in: http://www.nsec3.org/cgi-bin/trac.cgi/browser/dnssec/ws1/zones Some of them may be out-of-date as we modified the zone as we were testing, I'll update them soon, but right now my brain is fried :-) In order to understand some of the responses you may need to see the -05 version of the I-D, which doesn't yet exist. However, a preliminary (and somewhat incoherent, sorry) version exists at: http://www.nsec3.org/cgi-bin/trac.cgi/browser/dnssec/nsec%2B%2B/nsec3.xml Feedback on anything and everything _most_ welcome. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 15 14:40:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJbrc-0003UI-KG for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 14:40:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJbrb-0004hq-Bf for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 14:40:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJbq4-000BGA-Pv for namedroppers-data@psg.com; Wed, 15 Mar 2006 19:39:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJbq2-000BFr-7K for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 19:39:18 +0000 Received: from [10.31.32.57] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2FJd9wo033854; Wed, 15 Mar 2006 14:39:10 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE0DB67366@US-Columbia-CIST.mail.saic.com> References: <4E25ECBBC03F874CBAD03399254ADFDE0DB67366@US-Columbia-CIST.mail.saic.com> Date: Wed, 15 Mar 2006 14:39:08 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: RE: Secure DNS is just weakly secure Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 At 13:02 -0500 3/15/06, Loomis, Rip wrote: >stand today. I invite you to either propose an actual >valid alternative or contribute on updates to the existing >RFCs. For those not old enough to remember: http://www.watersprings.org/pub/id/draft-ohta-simple-dns-02.txt -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 15 16:27:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJdX0-0000IG-6O for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 16:27:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJdWy-0008O3-Qu for dnsext-archive@lists.ietf.org; Wed, 15 Mar 2006 16:27:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJdTt-0007QY-7R for namedroppers-data@psg.com; Wed, 15 Mar 2006 21:24:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJdTs-0007QK-4k for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 21:24:32 +0000 Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 15 Mar 2006 21:24:30 +0000 X-IronPort-AV: i="4.02,195,1139184000"; d="scan'208"; a="3124285:sNHT28053888" Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id k2FLOU9g018337 for namedroppers@ops.ietf.org; Wed, 15 Mar 2006 21:24:30 GMT Date: Wed, 15 Mar 2006 21:24:30 GMT From: Geoffrey Sisson Message-Id: <200603152124.k2FLOU9g018337@staff.nominet.org.uk> To: namedroppers@ops.ietf.org Subject: Review of draft-ietf-dnsext-dnssec-opt-in-08 In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 I have reviewed draft-ietf-dnsext-dnssec-opt-in-08 and believe it is ready to be forwarded to the IESG for consideration for publication as an experimental RFC. Nits: - Should RFC 2119 be a normative reference rather than informative? - RFC 3090 is obsoleted by RFCs 4033-4035? - RFC 3655 is obsoleted by RFCs 4033-4035? - Section 6: The example queries/responses appear to mix the idea of queries sent to an auth, non-recursive server with responses with meaningful AD bit values, which would only originate from a validating resolver. (The intent is clear, however, so could be left as-is.) Suggestions: - Section 2, paragraph 1: change "unsecured zones" to "insecure zones" - Section 2, paragraph 1: change "authenticating existence" to "authenticating the existence" - Section 3, paragraph 1: change: "Resolvers wishing to validate Opt-In zones MUST only do so when the zone is only signed using one or more of these private algorithms." to "Resolvers wishing to validate Opt-In zones MUST only do so when the zone is signed using only one or more of these private algorithms." (Parallelism with previous sentence.) Geoff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 16 04:03:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJoNq-0000Fx-0T for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 04:03:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJoNo-0001Xh-Gp for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 04:03:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJoKP-00021h-Qh for namedroppers-data@psg.com; Thu, 16 Mar 2006 08:59:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SUBJ_ALL_CAPS autolearn=no version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJoKP-00021Q-0f for namedroppers@ops.ietf.org; Thu, 16 Mar 2006 08:59:29 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2G8xQJj026126 for ; Thu, 16 Mar 2006 09:59:27 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-34-983604755" To: Namedroppers From: "Olaf M. Kolkman" Subject: RE-ISSUE 1: 5.6 Date: Thu, 16 Mar 2006 09:59:21 +0100 X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-34-983604755 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Colleagues, I should have known that introducing 3 various choices, with one choice providing all sorts of variations would not decrease but increase entropy. Besides I made the thread ambiguous by rephrasing the question mid-way. So let me re-issue the question with less ambiguity. First let me stress that this is will be a requirements document; it will be used to make trade-offs in the case that there are no technically solid en well engineered proposals that meet all requirements. It was Suresh who phrased that eloquently as: > Once we do get down to comparing different proposals against the > set of requirements its quite possible that we may find each > approach lacking in some respect. I don't think the intent of the > requirements document was to impose an "a-priori option abandonment > formulation" of any one approach. From what I understand, its a > collection of requirements that the working group *itself* has > proposed at some point or the other. (I read Simon's revised view and Thomas's arguments to be in this spirit --- and then arguing for dropping the paragraph altogether.) Maybe the editors can capture this in the introduction of the draft. On the other hand, I do think there is sufficient support in this group to capture the requirement for non-IPR as _one_ _of_ _the_ _tradeoffs_. Mentioning specific license text makes us rat-hole and since I have not seen a lot of resistance to Paul's latest proposal I would like to ask the group to (re)state their (non)-consent with the text below. > > 5.2 No Intellectual Property Encumbrance > > Because trust anchor rollover is considered "mandatory-to- > implement", > section 8 of [RFC3979] requires that the technology solution > chosen must > be unencumbered or must be available under royalty-free terms. > > For this purpose, "royalty-free" is defined as follows: world > wide, > perpetual right to use, without fee, in commerce or otherwise, > where "use" > includes descriptions of algorithms, distribution and/or use of > hardware > implementations, distribution and/or use of software systems in > source > and/or binary form, in all DNS or DNSSEC applications including > registry, > registrar, domain name service including authority, recursion, > caching, > forwarding, stub resolver, or similar. > > In summary, no implementor, distributor, or operator of the > technology > chosen for trust anchor management shall be expected or > required to pay > any fee to any IPR holder for the right to implement, > distribute, or > operate a system which includes the chosen mandatory-to-implement > solution. Kind regards, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-34-983604755 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEGSjutN/ca3YJIocRArCZAKDGCh//9nrFOSWa2kTq3Bfe2SwBNwCg4jB9 h/9n99TPgm/B1GqXzPUq6v0= =3WtE -----END PGP SIGNATURE----- --Apple-Mail-34-983604755-- -- to unsubscribe send a message to namedroppers-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 Mar 16 06:23:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJqZQ-0003KB-KW for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 06:23:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJqZN-0005mj-Ul for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 06:23:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJqW1-000Bob-M8 for namedroppers-data@psg.com; Thu, 16 Mar 2006 11:19:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJqW0-000BoP-Lx for namedroppers@ops.ietf.org; Thu, 16 Mar 2006 11:19:36 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id CC5D723FE8; Thu, 16 Mar 2006 12:19:35 +0100 (CET) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id A7C1E23EFE; Thu, 16 Mar 2006 12:19:35 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id A59642F594; Thu, 16 Mar 2006 12:19:35 +0100 (CET) Received: from localhost (brettcarr@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id k2GBJZBq028106; Thu, 16 Mar 2006 12:19:35 +0100 X-Authentication-Warning: cow.ripe.net: brettcarr owned process doing -bs Date: Thu, 16 Mar 2006 12:19:35 +0100 (CET) From: Brett Carr To: "Olaf M. Kolkman" Cc: Namedroppers Subject: Re: RE-ISSUE 1: 5.6 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.005065 / -4.4 X-RIPE-Signature: 72af8f69e9b8fedfe1a86a70fdfdac41 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 On Thu, 16 Mar 2006, Olaf M. Kolkman wrote: > On the other hand, I do think there is sufficient support in this > group to capture the requirement for non-IPR as _one_ _of_ _the_ > _tradeoffs_. Mentioning specific license text makes us rat-hole and > since I have not seen a lot of resistance to Paul's latest proposal I > would like to ask the group to (re)state their (non)-consent with the > text below. > I agree with the text as written. Brett.. -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL > > > > > 5.2 No Intellectual Property Encumbrance > > > > Because trust anchor rollover is considered "mandatory-to- > > implement", > > section 8 of [RFC3979] requires that the technology solution > > chosen must > > be unencumbered or must be available under royalty-free terms. > > > > For this purpose, "royalty-free" is defined as follows: world > > wide, > > perpetual right to use, without fee, in commerce or otherwise, > > where "use" > > includes descriptions of algorithms, distribution and/or use of > > hardware > > implementations, distribution and/or use of software systems in > > source > > and/or binary form, in all DNS or DNSSEC applications including > > registry, > > registrar, domain name service including authority, recursion, > > caching, > > forwarding, stub resolver, or similar. > > > > In summary, no implementor, distributor, or operator of the > > technology > > chosen for trust anchor management shall be expected or > > required to pay > > any fee to any IPR holder for the right to implement, > > distribute, or > > operate a system which includes the chosen mandatory-to-implement > > solution. > > > Kind regards, > > --Olaf > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > > -- to unsubscribe send a message to namedroppers-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 Mar 16 09:43:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJthU-0006Me-44 for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 09:43:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJthT-0004Ah-QV for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 09:43:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJtdq-0002E6-Tj for namedroppers-data@psg.com; Thu, 16 Mar 2006 14:39:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [64.39.31.27] (helo=server1.dns.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJtdh-0002DU-Uh for namedroppers@ops.ietf.org; Thu, 16 Mar 2006 14:39:46 +0000 Received: from localhost (localhost [[UNIX: localhost]]) by server1.dns.net (8.11.7/8.11.6) id k2GEdiV19311; Thu, 16 Mar 2006 14:39:44 GMT Date: Thu, 16 Mar 2006 16:34:50 +0200 From: Andras Salamon To: namedroppers@ops.ietf.org Subject: Re: RE-ISSUE 1: 5.6 Message-ID: <20060316143450.GA15609@dns.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Thu, Mar 16, 2006 at 09:59:21AM +0100, Olaf M. Kolkman wrote: > >5.2 No Intellectual Property Encumbrance > > > > Because trust anchor rollover is considered "mandatory-to- > >implement", > > section 8 of [RFC3979] requires that the technology solution > >chosen must > > be unencumbered or must be available under royalty-free terms. > > > > For this purpose, "royalty-free" is defined as follows: world > >wide, > > perpetual right to use, without fee, in commerce or otherwise, > >where "use" > > includes descriptions of algorithms, distribution and/or use of > >hardware > > implementations, distribution and/or use of software systems in > >source > > and/or binary form, in all DNS or DNSSEC applications including > >registry, > > registrar, domain name service including authority, recursion, > >caching, > > forwarding, stub resolver, or similar. > > > > In summary, no implementor, distributor, or operator of the > >technology > > chosen for trust anchor management shall be expected or > >required to pay > > any fee to any IPR holder for the right to implement, > >distribute, or > > operate a system which includes the chosen mandatory-to-implement > > solution. I support this phrasing. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 16 12:08:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJvxp-0007Rt-CF for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 12:08:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJvxn-0000sQ-Un for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 12:08:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJvuz-000DDR-0k for namedroppers-data@psg.com; Thu, 16 Mar 2006 17:05:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJvuy-000DD9-A0 for namedroppers@ops.ietf.org; Thu, 16 Mar 2006 17:05:44 +0000 Received: from vpn-38.vpn.nominum.com (vpn-38.vpn.nominum.com [128.177.199.38]) (using SSLv3 with cipher EXP1024-RC4-SHA (56/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id C731F5682F; Thu, 16 Mar 2006 09:05:43 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) From: Ted Lemon Organization: Nominum, Inc. To: "Olaf M. Kolkman" Subject: Re: RE-ISSUE 1: 5.6 Date: Thu, 16 Mar 2006 10:05:36 -0700 User-Agent: KMail/1.9.1 Cc: Namedroppers References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200603161005.36846.Ted.Lemon@nominum.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 On Thursday 16 March 2006 01:59, Olaf M. Kolkman wrote: > since I have not seen a lot of resistance to Paul's latest proposal I   > would like to ask the group to (re)state their (non)-consent with the   > text below. FWIW, I'm fine with 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 Thu Mar 16 18:27:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1sL-0006ND-Ov for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 18:27:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1sL-000717-9e for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 18:27:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FK1ne-000HSE-0d for namedroppers-data@psg.com; Thu, 16 Mar 2006 23:22:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FK1nV-000HRV-2S for namedroppers@ops.ietf.org; Thu, 16 Mar 2006 23:22:25 +0000 Received: (qmail 1586 invoked from network); 17 Mar 2006 00:26:24 -0000 Received: from p2014-ipad04yosemiya.okinawa.ocn.ne.jp (HELO necom830.hpcl.titech.ac.jp) (221.188.206.14) by necom830.hpcl.titech.ac.jp with SMTP; 17 Mar 2006 00:26:24 -0000 Message-ID: <4419F313.3010607@necom830.hpcl.titech.ac.jp> Date: Fri, 17 Mar 2006 08:21:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: "Loomis, Rip" CC: namedroppers@ops.ietf.org Subject: Re: Secure DNS is just weakly secure References: <4E25ECBBC03F874CBAD03399254ADFDE0DB67366@US-Columbia-CIST.mail.saic.com> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE0DB67366@US-Columbia-CIST.mail.saic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Loomis, Rip wrote: >>Secure DNS removes "control" of ISPs, which are as reliable as >>registries, but still leaves "control" of registries. > The assertion you make above is not only not provably > true, but is in my experience completely false. You may be running your own DNS server by yourself. However, many people use ISPs as registrars and ask them operate their name servers. Of course, they don't have to use DNS service of the providers. > Many providers > of recursive DNS service with which I deal on a regular basis > are *much* less reliable than the registries for DNS > information that I use on a regular basis. You don't have to use recursive DNS service of the providers. > In particular, securing DNS based on shared keys (which > you appear to advocate) does not scale well at all and It is just as scalable as the following suggestion of Ben Laurie. : There is no requirement in DNSSEC to trust the registry. If you would : prefer to trust your peer, then you should add his key as a trusted key : to your resolver. > has significant issues due to the inability to strongly > correlate a key with a particular individual (since it > is by definition shared with others). If you share your key with a KDC, which is as reliable as a CA, it is just as safe as public key cryptography (since the CA can forge a pair of public and private keys, which is signed by the CA). That is, your point is merely that secure DNS is just weakly secure and as secure as plain DNS. 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 Mar 16 18:36:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK21L-0005Ua-If for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 18:36:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK21L-0007Cw-9r for dnsext-archive@lists.ietf.org; Thu, 16 Mar 2006 18:36:43 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FK1zf-000IZU-C6 for namedroppers-data@psg.com; Thu, 16 Mar 2006 23:34:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FK1ze-000IZ8-JA for namedroppers@ops.ietf.org; Thu, 16 Mar 2006 23:34:58 +0000 Received: (qmail 1753 invoked from network); 17 Mar 2006 00:39:03 -0000 Received: from p2014-ipad04yosemiya.okinawa.ocn.ne.jp (HELO necom830.hpcl.titech.ac.jp) (221.188.206.14) by necom830.hpcl.titech.ac.jp with SMTP; 17 Mar 2006 00:39:03 -0000 Message-ID: <4419F60A.6080508@necom830.hpcl.titech.ac.jp> Date: Fri, 17 Mar 2006 08:34:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Namedroppers Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Olaf M. Kolkman wrote: > From this thread I do not see any consensus to request that DNSSEC > work items are to be removed from our charter. Though it is unfair to declare consensus or lack of it in only one or two days of discussion, so far, I can see the consensus that secure DNS is just weakly secure, though some says CAs are less weak than ISPs. If there is no counter argument, I can close the thread. Of course, the consensus (including that some says CAs are less weak than ISPs) should be documented in appropriate WG IDs. Then, let IESG decide whether the IDs should be published as standard track or just informational. Let people decide whether they should deploy secure DNS. Masataka Ohta PS I haven't requested that DNSSEC work items are to be removed from our charter, yet. -- to unsubscribe send a message to namedroppers-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 Mar 17 03:41:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAWA-0006fl-Ml for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 03:41:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKAW9-00066a-AL for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 03:41:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKASC-0005to-Px for namedroppers-data@psg.com; Fri, 17 Mar 2006 08:37:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKASB-0005tR-Eg for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 08:36:59 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2H8ZrGq021155; Fri, 17 Mar 2006 09:35:53 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <4419F60A.6080508@necom830.hpcl.titech.ac.jp> References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4419F60A.6080508@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-55-1068598062" Message-Id: <1A8579AE-E458-4E3F-AAA1-F079CDD63ECE@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Secure DNS is just weakly secure Date: Fri, 17 Mar 2006 09:35:55 +0100 To: Masataka Ohta X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-55-1068598062 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear Ohta san, > Though it is unfair to declare consensus or lack of it in only > one or two days of discussion Yes, I was going to fast, but I tried to focus on work that needs to get done. > Of course, the consensus (including that some says CAs are less weak > than ISPs) should be documented in appropriate WG IDs. Now you are going to fast :-) . I'd suggest you document your idea as personal submission. Ask if the appropriate WG, will support them as part of their charter, as working group document and then see if there will be consensus. > I haven't requested that DNSSEC work items are to be removed from > our charter, yet. We're trying to remove them by getting things done :-) --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-55-1068598062 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEGnTrtN/ca3YJIocRAjTyAKDBH8oHJ7ihGQG16ZjiwmTVf3dJUACeJ88w tiuKY0lCGbi0p6ot5Ln8ncw= =nUvA -----END PGP SIGNATURE----- --Apple-Mail-55-1068598062-- -- to unsubscribe send a message to namedroppers-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 Mar 17 03:43:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAYq-00085S-5A for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 03:43:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKAYo-00069K-SV for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 03:43:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKAXM-0006Ij-0Q for namedroppers-data@psg.com; Fri, 17 Mar 2006 08:42:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [202.214.123.16] (helo=ns.64translator.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKAXK-0006IM-6m for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 08:42:18 +0000 Received: from bahamas.64translator.com ([10.21.32.3]) by ns.64translator.com (8.13.1/8.13.1) with ESMTP id k2H8gAk6085344 for ; Fri, 17 Mar 2006 17:42:11 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.1/8.13.1) with SMTP id k2H8g1II075605 for ; Fri, 17 Mar 2006 17:42:02 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Fri, 17 Mar 2006 17:42:00 +0900 From: Yukiyo Akisada To: namedroppers@ops.ietf.org Subject: test event report Message-Id: <20060317174200.f2ab434a.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi, all. I will give you presentation at 65th IETF dnsext WG, but I want to post this report before it. Event Information: Name: 8th TAHI IPv6 Interoperability Test Event Term: 2006/01/23-2006/01/27 Venue: Nippon Convention Center (Makuhari Messe) in Chiba, Japan. We tested following items to just 1 DNS client from Japanese vendor. - Basic RFC's test - Extention RFC's test - SRV - AAAA - Negative Cache There are no issues for specification in this event, but the tester detects some SHOULD violations of inplimentation regarding SRV and Negative Cache. # I can't explain details, because of NDA. Anyway, It was 2nd time to have a event which had DNS testing service, but just only one vendor attendeds DNS test. I hope the number of vendors which have interesting in DNS test increases more. DNS conformance tester itself can be downloaded freely from our web site, and if you have any interesting in the DNS test, please contact me while next week. Thanks, ------------------------------------------------------------------------ Yukiyo Akisada -- to unsubscribe send a message to namedroppers-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 Mar 17 08:07:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKEgD-0003PQ-Rl for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 08:07:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKEgC-00063H-IM for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 08:07:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKEaF-0001TZ-9L for namedroppers-data@psg.com; Fri, 17 Mar 2006 13:01:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKEaE-0001Sr-B1 for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 13:01:34 +0000 Received: (qmail 11653 invoked from network); 17 Mar 2006 14:05:44 -0000 Received: from p2094-ipbf201yosemiya.okinawa.ocn.ne.jp (HELO necom830.hpcl.titech.ac.jp) (125.175.169.94) by necom830.hpcl.titech.ac.jp with SMTP; 17 Mar 2006 14:05:44 -0000 Message-ID: <441AB311.30308@necom830.hpcl.titech.ac.jp> Date: Fri, 17 Mar 2006 22:01:05 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Namedroppers Subject: Re: Secure DNS is just weakly secure References: <441627F4.10001@necom830.hpcl.titech.ac.jp> <4419F60A.6080508@necom830.hpcl.titech.ac.jp> <1A8579AE-E458-4E3F-AAA1-F079CDD63ECE@NLnetLabs.nl> In-Reply-To: <1A8579AE-E458-4E3F-AAA1-F079CDD63ECE@NLnetLabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Olaf M. Kolkman wrote: > Yes, I was going to fast, but I tried to focus on work that needs to > get done. You have misbehaved. Unlike time-limited presentation during IETF meetings, there is no reason to stop mailing list discussion, unless the discussion is against list policy. The list policy is: Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols > Now you are going to fast :-) . I'd suggest you document your idea as > personal submission. I have already posted it as a mail, because it is a comment to other IDs. And there are discussions, which should be reflected to IDs. If you think all the exchanges of ideas must be done by IDs and not by mails, I suggest you first write an ID saying so. > We're trying to remove them by getting things done :-) For more than 10 years, yes. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Mar 17 16:32:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMZ4-0008Li-SF for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 16:32:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMZ4-0006RS-D1 for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 16:32:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKMU0-000E3K-DH for namedroppers-data@psg.com; Fri, 17 Mar 2006 21:27:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKMTz-000E2i-9N for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 21:27:39 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2HLQx1N008104 for ; Fri, 17 Mar 2006 16:26:59 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoba4Yp; Fri, 17 Mar 06 16:26:53 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2HLPJqb016213; Fri, 17 Mar 2006 16:25:20 -0500 (EST) Date: Fri, 17 Mar 2006 16:27:26 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Thomas Narten cc: Namedroppers Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: <200603081849.k28InRZX031365@rotala.raleigh.ibm.com> Message-ID: References: <200603081849.k28InRZX031365@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 David answered most of this, but I'll go ahead and add my perspective. On Wed, 8 Mar 2006, Thomas Narten wrote: >> We MIGHT have been able to >> use this method to test DS (RFC3658). > > Only "MIGHT have"? Yes. Recall that DS changed the signalling at the zone cut, so we'd at least need a slightly different variant of this mechanism that worked with the last signaling semantics (SIG@child). I suspect that would have been tricky, at best. In the process of testing DS, we also found some interesting issues (e.g. "Jakob's bug") that MAY have existed with SIG@child code, also. We may not have been able to work around those with a signaling mechanism as "gentle" as this -- a typecode roll was (arguably) needed. >> In general, no. There is only one zone. It may use no DNSSEC, >> "standard" DNSSEC, or some "experimental" DNSSEC. > > Why can't a zone use both "standard" and "experimental"? I.e., signed > different sets of keys/algorithms, as the document says up front? That > is, any one resolver choose one or the other (but not both) for a > particular zone. If that is the case, both can co-exist, though the > defn. of coexistance is maybe different that you are thinking of. It could be that it's impossible to generate a zone that works with both "standard" and "experimental" (that may be the case with NSEC and NSEC3, where there might be an unresolvable circular dependence). And as you talked about later in your post, there's no way for a resolver to signal which "version" of the zone it wants. Doing so would have some interesting implications for caching. > Here is the rub. This technique allows zones to identify extensions > that only extension-aware resolvers will process. But it does not > really allow DNS servers (e.g., those in zones implementing the > experiment) to know they are talking to "experiment-aware" resolvers > and thus return answers appropriate for implementors of the experiment > (but not others). Correct. And the DNS caching architecture pretty much requires this. Otherwise each intermediate resolver would need to be able to cache multiple sets of data (one set per experiment) and respond to clients accordingly. We already agreed that it was okay to require a "clear path" of exclusively DNSSEC-aware resolvers and middlesboxes between authoritative servers and resolvers -- we don't want to impose that constraint separately for every experiment. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 17 16:47:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMnB-0005Q5-Fh for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 16:47:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMnB-0006bA-6X for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 16:47:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKMlZ-000FX4-By for namedroppers-data@psg.com; Fri, 17 Mar 2006 21:45:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKMlY-000FWn-Fw for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 21:45:48 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2HLj9ng009973 for ; Fri, 17 Mar 2006 16:45:09 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPGayEt; Fri, 17 Mar 06 16:45:05 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2HLhRqb016705; Fri, 17 Mar 2006 16:43:28 -0500 (EST) Date: Fri, 17 Mar 2006 16:45:34 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Geoffrey Sisson cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 8: NSEC3 Signaling Mechanism In-Reply-To: <200602211825.k1LIPQuT009658@staff.nominet.org.uk> Message-ID: References: <200602211825.k1LIPQuT009658@staff.nominet.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On Tue, 21 Feb 2006, Geoffrey Sisson wrote: > Should a name server for a DNSSEC zone that uses NSEC3 RRs only somehow > signal this to NSEC3-unaware DNSSEC applications? ... > 3. Use a new DS message digest number ... > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html > > However: > > - Only works if all subsequent children are NSEC3. If the chain of > trust is NSEC -> NSEC3 -> NSEC then the NSEC descendant will > appear bogus. I concur with Mark -- assuming a correct implementation, the NSEC descendant will be treated as insecure. Unless real legacy code does the Wrong Thing (tm) with unknown message digests, the omission of this detail from 403{3,4,5} is not a showstopper here. > 4. Use an unknown algorithm identifier .... > Proposed Resolution: > > Approach #4 appears to be the most promising. Thorough testing will be > required to determine whether any non-obvious issues exist, though it's > been shown to work in previous testing. While I'm pretty confident in the viability of #4, I'm also pretty confident in #3. I also think it's wisest for us to use the less populated and slower growing registry. While the hash function registry will be more populated over the time, the algorithm registry could grow as the product of hash function changes and public key signing algorithm changes -- let's not put further pressure on the algorithm number registry by using it for this signaling. So, again, unless we find a showstopper with #3, I think we should stay there. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 17 16:57:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMxH-0004pf-OP for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 16:57:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMxH-0006yp-FL for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 16:57:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKMvk-000GWK-By for namedroppers-data@psg.com; Fri, 17 Mar 2006 21:56:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKMvj-000GW2-Kk for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 21:56:19 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2HLteM6011250 for ; Fri, 17 Mar 2006 16:55:40 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAauay9v; Fri, 17 Mar 06 16:55:35 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2HLriqb017003; Fri, 17 Mar 2006 16:53:45 -0500 (EST) Date: Fri, 17 Mar 2006 16:55:51 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Ben Laurie cc: Wes Hardaker , Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers In-Reply-To: <43FEF8C5.9080508@algroup.co.uk> Message-ID: References: <43FEF8C5.9080508@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d On Fri, 24 Feb 2006, Ben Laurie wrote: >> Another related attack is actually not for people forging NSEC3 >> records and returning them to an attacker, but is actually much worse: > > Forgery is not an issue, since the signature won't check. This suggests that it may be wisest to check the signature BEFORE performing a large number of hash iterations to see if the NSEC3 record is applicable to the query (or, even, for which name it might be applicable). This does go against the common wisdom of "make sure the record, if it validates, would matter", so it probably worth calling out. But going back to the original question: > 1. Should an upper limit be specified in the standard? No. It seems reasonable to me for any given resolver to independently say "I'll never do more than X hash iterations -- any zone using NSEC3 with >X hash iterations will be treated as insecure". Those decisions, which need not be made in any coordinated fashion, won't break the net. A resolver could even do more subtle things like "I won't do more than N iterations UNLESS I've seen at least 50 NSEC3 records from that zone with at least that number of iterations set during the last month" or "I won't do more than N iterations per second -- any queries that would exceed that threshhold will be treated as insecure". These local decisions of what authentication data to ignore will happen anyway, with few ill effects. I'm fine with giving a recommendation to support a certain mimimun number, but I don't think we need to go any further. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 17 17:01:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKN1D-0006BI-1N for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 17:01:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKN1C-00075c-PE for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 17:01:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKMzg-000Grt-Bm for namedroppers-data@psg.com; Fri, 17 Mar 2006 22:00:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKMzf-000GrS-MB for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 22:00:23 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2HLxi2R011731 for ; Fri, 17 Mar 2006 16:59:44 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAkai5w; Fri, 17 Mar 06 16:59:40 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2HLw1qb017134; Fri, 17 Mar 2006 16:58:01 -0500 (EST) Date: Fri, 17 Mar 2006 17:00:08 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Geoffrey Sisson cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 10: Potential DoS on Servers In-Reply-To: <200602211827.k1LIRFB2009668@staff.nominet.org.uk> Message-ID: References: <200602211827.k1LIRFB2009668@staff.nominet.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Tue, 21 Feb 2006, Geoffrey Sisson wrote: > Issue: > > Significantly more work is required for a name server to respond to > queries which require negative proofs using NSEC3 than is required for > a client to compose and send them. For each such query, the name > server must repeat the hash function for the number of iterations > specified in the NSEC3 RRs. Consequently, name servers with NSEC3 > zones are susceptible to asymmetric DoS attacks. > > > Resolution: > > None at present. I don't think any resolution is needed. We just need to call out this possible problem and suggest that the obvious way to avoid the problem is by using NSEC. -- to unsubscribe send a message to namedroppers-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 Mar 17 17:08:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKN7Y-0006xf-EX for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 17:08:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKN7X-0007O6-5l for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 17:08:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKN5w-000HRj-7g for namedroppers-data@psg.com; Fri, 17 Mar 2006 22:06:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKN5v-000HRV-Hf for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 22:06:51 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2HM6BLu012511 for ; Fri, 17 Mar 2006 17:06:11 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFXaWAy; Fri, 17 Mar 06 17:06:08 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2HM4Tqb017323; Fri, 17 Mar 2006 17:04:30 -0500 (EST) Date: Fri, 17 Mar 2006 17:06:36 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Geoffrey Sisson cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 13: DDNS and Opt-In Determination In-Reply-To: <200602211829.k1LITCpJ009672@staff.nominet.org.uk> Message-ID: References: <200602211829.k1LITCpJ009672@staff.nominet.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Tue, 21 Feb 2006, Geoffrey Sisson wrote: > Issue: > > When a DDNS client sends an UPDATE transaction containing RRs for a new > unsigned delegation to be inserted into an NSEC3 zone, there is no > obvious way for the server to determine whether or not the new > delegation should be included in the NSEC3 chain. ... > Resolution: > > None. We are still investigating the problem space. I suggest not resolving this at this time (and, in particular, in this document). Assuming that we retain opt-in at all (why isn't there an open issue about that?), I imagine that zones will have different policies for which names to include in the NSEC3 chain v. not, and I see no compelling case for setting a default. If we need some DDNS extensions to handle NSEC3, we can handle that separately. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 17 18:13:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKO8i-0002g2-Ro for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 18:13:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKO8f-0000kE-Hl for dnsext-archive@lists.ietf.org; Fri, 17 Mar 2006 18:13:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKO5R-000MRj-U2 for namedroppers-data@psg.com; Fri, 17 Mar 2006 23:10:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKO5P-000MQl-AK for namedroppers@ops.ietf.org; Fri, 17 Mar 2006 23:10:23 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2HN9hjV019443 for ; Fri, 17 Mar 2006 18:09:43 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMLai9L; Fri, 17 Mar 06 18:09:40 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2HN86qb018899 for ; Fri, 17 Mar 2006 18:08:07 -0500 (EST) Date: Fri, 17 Mar 2006 18:10:14 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Namedroppers Subject: Re: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb I've reread the experiments draft. I have only one issue I'd like to see addressed before the document is advanced: in section 7 (Transitions), I'd like this draft to mention using new DS hash algorithm identifiers as another transition option. Otherwise, I believe this document should be published on the standards track. Nits: As others have said, add an explicit: "No IANA actions needed" to Section 9, possibly moving the rest of the text into section 7 (or otherwise highlighting that the text is for the benefit of the readers, not the IANA). Remove the citation from the abstract Fix incomplete sentence in 1. 2: remove comma OLD: There has typically been a desire to both introduce non-backwards-compatible changes to DNSSEC, and to try these changes on real zones in the public DNS. NEW: There has typically been a desire to both introduce non-backwards-compatible changes to DNSSEC and to try these changes on real zones in the public DNS. 2: explain or remove "public" OLD: This document describes a standard methodology for setting up public DNSSEC experiments. NEW: This document describes a standard methodology for setting up DNSSEC experiments. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 18 05:22:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKYZu-0005Ff-Bd for dnsext-archive@lists.ietf.org; Sat, 18 Mar 2006 05:22:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKYZt-0004Mi-1b for dnsext-archive@lists.ietf.org; Sat, 18 Mar 2006 05:22:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKYWP-000GGN-7S for namedroppers-data@psg.com; Sat, 18 Mar 2006 10:18:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKYWO-000GG8-2S for namedroppers@ops.ietf.org; Sat, 18 Mar 2006 10:18:56 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id EBE6B33C44; Sat, 18 Mar 2006 10:18:53 +0000 (GMT) Message-ID: <441BDE15.20808@algroup.co.uk> Date: Sat, 18 Mar 2006 10:16:53 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Sam Weiler CC: Wes Hardaker , Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers References: <43FEF8C5.9080508@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Sam Weiler wrote: > On Fri, 24 Feb 2006, Ben Laurie wrote: > >>> Another related attack is actually not for people forging NSEC3 >>> records and returning them to an attacker, but is actually much worse: >> >> Forgery is not an issue, since the signature won't check. > > This suggests that it may be wisest to check the signature BEFORE > performing a large number of hash iterations to see if the NSEC3 record > is applicable to the query (or, even, for which name it might be > applicable). This does go against the common wisdom of "make sure the > record, if it validates, would matter", so it probably worth calling out. > > But going back to the original question: > >> 1. Should an upper limit be specified in the standard? > > No. It seems reasonable to me for any given resolver to independently > say "I'll never do more than X hash iterations -- any zone using NSEC3 > with >X hash iterations will be treated as insecure". Those decisions, > which need not be made in any coordinated fashion, won't break the net. > A resolver could even do more subtle things like "I won't do more than N > iterations UNLESS I've seen at least 50 NSEC3 records from that zone > with at least that number of iterations set during the last month" or "I > won't do more than N iterations per second -- any queries that would > exceed that threshhold will be treated as insecure". These local > decisions of what authentication data to ignore will happen anyway, with > few ill effects. > > I'm fine with giving a recommendation to support a certain mimimun > number, but I don't think we need to go any further. The consequence of such a recommendation is that no public zone will be able to set their iterations higher, and so it will effectively be an upper limit. Which still leaves us with the question: what should that minimum number be? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 18 05:28:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKYfk-0001Bf-Gc for dnsext-archive@lists.ietf.org; Sat, 18 Mar 2006 05:28:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKYfk-0004Wp-7W for dnsext-archive@lists.ietf.org; Sat, 18 Mar 2006 05:28:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKYeD-000GuO-1e for namedroppers-data@psg.com; Sat, 18 Mar 2006 10:27:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKYeC-000Gu8-Er for namedroppers@ops.ietf.org; Sat, 18 Mar 2006 10:27:00 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C3AF233C40; Sat, 18 Mar 2006 10:26:58 +0000 (GMT) Message-ID: <441BDFFA.40106@algroup.co.uk> Date: Sat, 18 Mar 2006 10:24:58 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Sam Weiler CC: Wes Hardaker , Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers References: <43FEF8C5.9080508@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Sam Weiler wrote: > On Fri, 24 Feb 2006, Ben Laurie wrote: > >>> Another related attack is actually not for people forging NSEC3 >>> records and returning them to an attacker, but is actually much worse: >> >> Forgery is not an issue, since the signature won't check. > > This suggests that it may be wisest to check the signature BEFORE > performing a large number of hash iterations to see if the NSEC3 record > is applicable to the query (or, even, for which name it might be > applicable). This does go against the common wisdom of "make sure the > record, if it validates, would matter", so it probably worth calling out. I have added this to our issue tracker. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 18 05:29:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKYgw-0002kh-V9 for dnsext-archive@lists.ietf.org; Sat, 18 Mar 2006 05:29:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKYgw-0004Yu-Lw for dnsext-archive@lists.ietf.org; Sat, 18 Mar 2006 05:29:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKYfq-000H3G-Ku for namedroppers-data@psg.com; Sat, 18 Mar 2006 10:28:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FKYfq-000H31-1l for namedroppers@ops.ietf.org; Sat, 18 Mar 2006 10:28:42 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 72F9733C40; Sat, 18 Mar 2006 10:28:40 +0000 (GMT) Message-ID: <441BE060.3030400@algroup.co.uk> Date: Sat, 18 Mar 2006 10:26:40 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Sam Weiler CC: Geoffrey Sisson , namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 13: DDNS and Opt-In Determination References: <200602211829.k1LITCpJ009672@staff.nominet.org.uk> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Sam Weiler wrote: > On Tue, 21 Feb 2006, Geoffrey Sisson wrote: > >> Issue: >> >> When a DDNS client sends an UPDATE transaction containing RRs for a new >> unsigned delegation to be inserted into an NSEC3 zone, there is no >> obvious way for the server to determine whether or not the new >> delegation should be included in the NSEC3 chain. > ... >> Resolution: >> >> None. We are still investigating the problem space. > > I suggest not resolving this at this time (and, in particular, in this > document). > > Assuming that we retain opt-in at all (why isn't there an open issue > about that?), Because we do not believe it is an open issue. > I imagine that zones will have different policies for > which names to include in the NSEC3 chain v. not, and I see no > compelling case for setting a default. If we need some DDNS extensions > to handle NSEC3, we can handle that separately. I agree. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 20 20:22:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLVa5-0004jw-9D for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 20:22:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLVa4-0006bd-U9 for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 20:22:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLVVI-000OVx-Eq for namedroppers-data@psg.com; Tue, 21 Mar 2006 01:17:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLVVH-000OVk-Gg for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 01:17:43 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2L1H4kp014548 for ; Mon, 20 Mar 2006 20:17:04 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAznaqzC; Mon, 20 Mar 06 20:17:01 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2L1FFqb014713; Mon, 20 Mar 2006 20:15:22 -0500 (EST) Date: Mon, 20 Mar 2006 20:17:20 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Ben Laurie cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers In-Reply-To: <441BDE15.20808@algroup.co.uk> Message-ID: References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Sat, 18 Mar 2006, Ben Laurie wrote: >> I'm fine with giving a recommendation to support a certain mimimun >> number, but I don't think we need to go any further. > > The consequence of such a recommendation is that no public zone will > be able to set their iterations higher, and so it will effectively > be an upper limit. Why wouldn't a public zone be able to set their iterations higher? Your statement sounds remarkably like "no public zone will be able to use a new hash or crypto algorithm", which I certainly hope is untrue. Sure, some resolvers won't be able to validate answers from a zone using "too many" iterations, but they should still be able to see the zone. Likewise, an NSEC-only resolver won't be able to validate answers from an NSEC3 zone, and BIND 9.3.x won't be able to validate a zone signed with the CryptSam cipher suite. But these are limitations on what a resolver is able to do, not what a zone is able to do. If a zone owner wants the largest number of resolvers to be able to validate his zone, he can use NSEC-classic. If he's using NSEC3 at all, clearly he has a different priority. Using more iterations is a similar choice. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 20 20:25:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLVcp-0007xm-RJ for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 20:25:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLVco-0006iO-J1 for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 20:25:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLVan-000Ort-HR for namedroppers-data@psg.com; Tue, 21 Mar 2006 01:23:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLVam-000Org-TF for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 01:23:25 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2L1MjRE015377 for ; Mon, 20 Mar 2006 20:22:45 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0TaGYD; Mon, 20 Mar 06 20:22:10 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2L1KHqb014903; Mon, 20 Mar 2006 20:20:18 -0500 (EST) Date: Mon, 20 Mar 2006 20:22:22 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Ben Laurie cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 13: DDNS and Opt-In Determination In-Reply-To: <441BE060.3030400@algroup.co.uk> Message-ID: References: <200602211829.k1LITCpJ009672@staff.nominet.org.uk> <441BE060.3030400@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c On Sat, 18 Mar 2006, Ben Laurie wrote: >> (why isn't there an open issue about [opt-in]?), > > Because we do not believe it is an open issue. I don't recall DNSEXT reaching a happy consensus about it. Am I just being forgetful? -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 20 20:34:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLVlR-0004Ec-7o for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 20:34:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLVlO-000751-S7 for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 20:34:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLVje-000PQL-Ms for namedroppers-data@psg.com; Tue, 21 Mar 2006 01:32:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_BOGONS autolearn=no version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLVjd-000PQ3-HI for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 01:32:33 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2L1WRqj029273; Tue, 21 Mar 2006 02:32:27 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <200602211829.k1LITCpJ009672@staff.nominet.org.uk> <441BE060.3030400@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7--758695885" Message-Id: <22717E40-8C8D-4A3D-B1BD-4D68F62053FE@NLnetLabs.nl> Cc: Ben Laurie , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: NSEC3 Issue 13: DDNS and Opt-In Determination Date: Mon, 20 Mar 2006 19:32:24 -0600 To: Sam Weiler X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-7--758695885 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 20, 2006, at 7:22 PM, Sam Weiler wrote: > On Sat, 18 Mar 2006, Ben Laurie wrote: > >>> (why isn't there an open issue about [opt-in]?), >> >> Because we do not believe it is an open issue. > > I don't recall DNSEXT reaching a happy consensus about it. Am I > just being forgetful? If nobody has issues its no issue. As long its no issue, happy consensus will be declared after WGLC, if it is an issue we have to consent before. So if this is an issue for you then please motivate why; provide your arguments why it should not be there. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-7--758695885 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEH1eutN/ca3YJIocRAk/cAKCbYUeFcp1VMFAornERKB2nJ+GUXACfVl9m 8Gkkt2CrMsb4ebZR/GvrBAY= =+Xnx -----END PGP SIGNATURE----- --Apple-Mail-7--758695885-- -- to unsubscribe send a message to namedroppers-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 Mar 20 21:00:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLWAU-000184-NX for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 21:00:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLWAT-0007iu-B5 for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 21:00:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLW8S-0000ya-1O for namedroppers-data@psg.com; Tue, 21 Mar 2006 01:58:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLW8R-0000yL-6T for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 01:58:11 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2L1vWji019252 for ; Mon, 20 Mar 2006 20:57:32 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaba4LL; Mon, 20 Mar 06 20:57:29 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2L1ttqb015912 for ; Mon, 20 Mar 2006 20:55:55 -0500 (EST) Date: Mon, 20 Mar 2006 20:58:00 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Namedroppers Subject: Re: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 I've reread parts of the opt-in draft. I hope to review it more thoroughly, but in the interest of publishing my written objection in advance of tomorrow's meeting, I'm sending the partial review now. While I'm generally in favor of this document being published, I oppose it going forward in its present form. In particular, I don't share the level of certainty expressed in this sentence from the abstract: "Maintaining this cryptography is not practical or necessary." I think a few more qualifiers are appropriate. The above can be easily fixed, and I think the document is close to being publishable. That said, I suspect a few more eyes would be helpful -- this document has some subtle details that could benefit from extremely close scrutiny. Other substantive questions: A protocol correctness question, from section 4.2.1: As stated in the "Server Considerations" section above, this specification restricts the namespace covered by Opt-In tagged NSEC records to insecure delegations only. Thus, resolvers MUST generate a validation failure when encountering records other than NS or glue that fall within an Opt-In NSEC record's span. If a server is authoritative for both an opt-in signed parent and an unsigned child, what happens when the resolver receives an A record from the child zone? The resolver doesn't see the NS record ... Why the requirement for "clear path" in section 7? Why do intermediate caches (whether validating w/ non-opt-in DNSSEC or not) need to understand opt-in? Clarity/nits: In section 3, this paragraph could be confusing, and its second sentence seems particularly out of place (what's the antecedent for "this"?). OLD: Servers wishing to sign and serve zones that utilize Opt-In MUST sign the zone with only one or more of these private algorithms. This requires the signing tools and servers to support private algorithms, as well as Opt-In. NEW Servers wishing to sign and serve zones that utilize Opt-In MUST sign the zone with only one or more of these private algorithms and MUST NOT use any other algorithms. In particular, the zone MUST NOT mix these private algorithms with any non-experimental algorithms. Also: OLD Resolvers wishing to validate Opt-In zones MUST only do so when the zone is only signed using one or more of these private algorithms. NEW Resolvers MUST NOT apply the special opt-in validation rules in this document unless a zone is signed with one or more of these private algorithms. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 20 23:31:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLYWg-0002Mj-66 for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 23:31:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLYWe-0004K2-SD for dnsext-archive@lists.ietf.org; Mon, 20 Mar 2006 23:31:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLYU4-0008uq-9I for namedroppers-data@psg.com; Tue, 21 Mar 2006 04:28:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLYU3-0008uc-Ff for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 04:28:39 +0000 Received: from [204.96.114.118] ([::ffff:204.96.114.118]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 20 Mar 2006 23:28:37 -0500 id 002C40D1.441F80F5.00003B2B In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: WGLC dnssec-experiments and dnssec-opt-in Date: Mon, 20 Mar 2006 22:28:35 -0600 To: Sam Weiler X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 On Mar 20, 2006, at 7:58 PM, Sam Weiler wrote: > I've reread parts of the opt-in draft. I hope to review it more > thoroughly, but in the interest of publishing my written objection > in advance of tomorrow's meeting, I'm sending the partial review now. > > While I'm generally in favor of this document being published, I > oppose it going forward in its present form. I'm sorry to hear that. > In particular, I don't share the level of certainty expressed in > this sentence from the abstract: "Maintaining this cryptography is > not practical or necessary." I think a few more qualifiers are > appropriate. So noted. > The above can be easily fixed, and I think the document is close to > being publishable. That said, I suspect a few more eyes would be > helpful -- this document has some subtle details that could benefit > from extremely close scrutiny. Other than its experimental status, this document *has* benefited from extremely close scrutiny. I'm not sure why, specifically, you think it needs more. > Other substantive questions: > > A protocol correctness question, from section 4.2.1: > > As stated in the "Server Considerations" section above, this > specification restricts the namespace covered by Opt-In tagged NSEC > records to insecure delegations only. Thus, resolvers MUST > generate > a validation failure when encountering records other than NS or > glue > that fall within an Opt-In NSEC record's span. > > If a server is authoritative for both an opt-in signed parent and > an unsigned child, what happens when the resolver receives an A > record from the child zone? The resolver doesn't see the NS > record ... This isn't a special case. This happens in non-opt-in DNSSEC. What do you think happens there? > > Why the requirement for "clear path" in section 7? Why do > intermediate caches (whether validating w/ non-opt-in DNSSEC or > not) need to understand opt-in? Because an intermediate cache will not (necessarily) be able to reconstruct opt-in responses from its cache. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 21 01:32:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLaPu-00050L-Vw for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 01:32:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLaPp-0008Uj-Lh for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 01:32:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLaMc-000Hz9-Vb for namedroppers-data@psg.com; Tue, 21 Mar 2006 06:29:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLaMZ-000Hyo-PV for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 06:29:04 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id E39C533C1C; Tue, 21 Mar 2006 06:29:00 +0000 (GMT) Message-ID: <441F9CFC.8020306@algroup.co.uk> Date: Tue, 21 Mar 2006 06:28:12 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060305) MIME-Version: 1.0 To: Sam Weiler CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Sam Weiler wrote: > On Sat, 18 Mar 2006, Ben Laurie wrote: > >>> I'm fine with giving a recommendation to support a certain mimimun >>> number, but I don't think we need to go any further. >> >> The consequence of such a recommendation is that no public zone will >> be able to set their iterations higher, and so it will effectively be >> an upper limit. > > Why wouldn't a public zone be able to set their iterations higher? > > Your statement sounds remarkably like "no public zone will be able to > use a new hash or crypto algorithm", which I certainly hope is untrue. > > Sure, some resolvers won't be able to validate answers from a zone using > "too many" iterations, but they should still be able to see the zone. > Likewise, an NSEC-only resolver won't be able to validate answers from > an NSEC3 zone, and BIND 9.3.x won't be able to validate a zone signed > with the CryptSam cipher suite. But these are limitations on what a > resolver is able to do, not what a zone is able to do. If a zone owner > wants the largest number of resolvers to be able to validate his zone, > he can use NSEC-classic. If he's using NSEC3 at all, clearly he has a > different priority. Using more iterations is a similar choice. There is no knob I can turn in a resolver that will make it understand a new hash algorithm, in sharp contrast to number of iterations, so I totally don't buy this analogy. -- http://www.links.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 Mar 21 08:49:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhEo-0005BN-E9 for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 08:49:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhEn-0008LP-2P for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 08:49:30 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLhAh-000FR9-Up for namedroppers-data@psg.com; Tue, 21 Mar 2006 13:45:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLhAh-000FQy-6P for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 13:45:15 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2LDiap5012969 for ; Tue, 21 Mar 2006 08:44:36 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYAaOuz; Tue, 21 Mar 06 08:44:33 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2LDgqqb005196; Tue, 21 Mar 2006 08:42:54 -0500 (EST) Date: Tue, 21 Mar 2006 08:44:51 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Ben Laurie cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers In-Reply-To: <441F9CFC.8020306@algroup.co.uk> Message-ID: References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> <441F9CFC.8020306@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Tue, 21 Mar 2006, Ben Laurie wrote: >>> The consequence of such a recommendation is that no public zone will >>> be able to set their iterations higher, and so it will effectively be >>> an upper limit. >> >> Why wouldn't a public zone be able to set their iterations higher? >> >> Your statement sounds remarkably like "no public zone will be able to >> use a new hash or crypto algorithm", which I certainly hope is untrue. ... > There is no knob I can turn in a resolver that will make it understand a > new hash algorithm, in sharp contrast to number of iterations, so I > totally don't buy this analogy. Whether or not you "buy" the analogy, you could at least have the good grace to answer the direct question: why wouldn't a public zone be able to set their iterations higher? -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 21 08:51:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhGZ-0006iR-2X for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 08:51:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhGX-0008Nh-Mc for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 08:51:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLhES-000FjC-Pu for namedroppers-data@psg.com; Tue, 21 Mar 2006 13:49:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLhER-000FiW-6d for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 13:49:07 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2LDmwdi044663; Tue, 21 Mar 2006 14:48:59 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <200602211829.k1LITCpJ009672@staff.nominet.org.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--714505242" Message-Id: <3166F929-3E0D-46CB-B3BB-A355136FB7B0@NLnetLabs.nl> Cc: Geoffrey Sisson , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: NSEC3 Issue 13: DDNS and Opt-In Determination Date: Tue, 21 Mar 2006 07:48:55 -0600 To: Sam Weiler X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10--714505242 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 17, 2006, at 4:06 PM, Sam Weiler wrote: > On Tue, 21 Feb 2006, Geoffrey Sisson wrote: > >> Issue: >> >> When a DDNS client sends an UPDATE transaction containing RRs for >> a new >> unsigned delegation to be inserted into an NSEC3 zone, there is no >> obvious way for the server to determine whether or not the new >> delegation should be included in the NSEC3 chain. > ... >> Resolution: >> >> None. We are still investigating the problem space. > > I suggest not resolving this at this time (and, in particular, in > this document). > > Assuming that we retain opt-in at all (why isn't there an open > issue about that?), I imagine that zones will have different > policies for which names to include in the NSEC3 chain v. not, and > I see no compelling case for setting a default. If we need some > DDNS extensions to handle NSEC3, we can handle that separately. > > The opt-in spec has specific language on how to deal with (not being able to do) dynamic updates in section 4.1.4. I propose that you would add some similar text to the nsec3 doc. Related. The document updates reference [6] (dynamic update) but does not refer to it other than in the introduction. no hats, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-10--714505242 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEIARNtN/ca3YJIocRAgOoAJ4zkVlUaByc7AZSUBjHaOisXpaF2wCfTtc6 bPn4sZH7BW8imJsy1Ke/fvE= =DZiS -----END PGP SIGNATURE----- --Apple-Mail-10--714505242-- -- to unsubscribe send a message to namedroppers-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 Mar 21 14:24:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLmTJ-0006eh-1d for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 14:24:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLmTH-00052f-MT for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 14:24:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLmDi-0002cf-SS for namedroppers-data@psg.com; Tue, 21 Mar 2006 19:08:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLmDi-0002cC-3b for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 19:08:42 +0000 Received: from thangorodrim.hactrn.net (DHCP-Wireless-132-241.ietf65.org [130.129.132.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id EBD001AA for ; Tue, 21 Mar 2006 14:08:35 -0500 (EST) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 3BD7111448 for ; Tue, 21 Mar 2006 18:15:46 +0000 (UTC) Date: Tue, 21 Mar 2006 12:15:46 -0600 From: Rob Austein To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dnssec-rsasha256 security considerations MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060321181547.3BD7111448@thangorodrim.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c draft-ietf-dnsext-dnssec-rsasha256-00.txt (a good and worthy draft) needs security considerations text explaining why it's not vulnerable to a downgrade attack. To review: RRSIG RRs don't form RRsets, therefore one can't detect a nogoodnik filtering out an RRSIG, so DNSSECbis has a rule requiring every signed RRset to be signed with every algorithm listed in the zone apex DNSKEY RRset. This is "obvious" to anyone who has memorized the DNSSECbis specifications, but it'd be kind to explain it (again) for the benefit of other readers. -- to unsubscribe send a message to namedroppers-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 Mar 21 16:51:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLolR-0001PQ-JT for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 16:51:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLolO-0004ue-Fn for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 16:51:41 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLoiX-000A8k-TN for namedroppers-data@psg.com; Tue, 21 Mar 2006 21:48:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLoiW-000A8U-JQ for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 21:48:41 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2LLmNxZ023076; Tue, 21 Mar 2006 16:48:24 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060321164401.03b8f560@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 21 Mar 2006 16:48:16 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Proposed RFC 2538bis AUTH48 problem resolution Cc: Margaret Wasserman , Simon Josefsson In-Reply-To: <6.2.5.6.2.20060314215134.03b3d8e0@ogud.com> References: <8764mgekrr.fsf@latte.josefsson.org> <6.2.5.6.2.20060314215134.03b3d8e0@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 As there have been no objections to this change the chairs will request that the RFC-editor make this change after we do more due diligence by checked with our AD and a security AD. Olafur & Olaf At 21:57 14/03/2006, =D3lafur Gu=F0mundsson /DNSEXT wrote: >Thanks Simon, for your diligent work on bringing this issue to >resolution. > >Unless someone speaks up that this is unacceptable, the WG chairs >will inform the AD that making these text changes is supported by the >working group and recommend RFC2338bis be publish with these changes. >Speak up before Tuesday March 21'st. > > Olafur. > >At 17:14 14/03/2006, Simon Josefsson wrote: >>Dear WG: >> >>RFC 4398 (2538bis) has been in the AUTH48 state with the RFC Editor >>for some time now, pending a problem the GnuPG developers found when >>implement support for storing PGP data in CERT records. This e-mail >>describe the problem and propose how to solve it, so we can get the >>document out. >> >>The problem is that it is impossible to strongly identify the intended >>OpenPGP key based on the URL in the IPGP type from any DNSSEC trust, >>i.e., you don't know that what you download from the URL contains the >>DNSSEC-trusted OpenPGP key. >> >>The solution to this is add a field to the IPGP type that contain the >>OpenPGP key fingerprint. This is David Shaw's proposal. >> >>What remains is to deal with the other indirect I* types. The problem >>is similar to all of them, you may need a hash of the URL data to >>bridge DNSSEC trust further. We believe nobody care about SPKI >>strongly enough to care about ISPKI, so we wish to postpone the >>definition of both SPKI and ISPKI until later. For IPKIX and IACPKIX, >>the problem isn't as applicable because X.509 certs are >>self-authentication and in particular RFC 4387 describe URL access >>that can embed hashes of the certificate. We propose to keep the >>IPKIX and IACPKIX types, but note that if someone need a hash inside >>those CERT sub-types, such new sub-types can be specified in the >>future. >> >>Here are the proposed changes that will be sent to the RFC editor >>unless someone has a better suggestion. >> >>Please, please, review RFC 4398: >> >>ftp://ftp.rfc-editor.org/in-notes/authors/rfc4398.txt >> >>with the patch below for consistency. >> >>Thanks, >>Simon >> >>Section 2.1, OLD: >> >> 6 IPGP The URL of an OpenPGP packet >> >>NEW: >> >> 6 IPGP The fingerprint and URL of an OpenPGP packet >> >>OLD: >> >> The SPKI type is reserved to indicate the SPKI certificate format >> [15], for use when the SPKI documents are moved from experimental >> status. >> >>NEW: >> >> The SPKI and ISPKI type is reserved to indicate the SPKI >> certificate format [15], for use when the SPKI documents are moved >> from experimental status. The format for these two CERT RR types >> will need to be specified later. >> >>OLD: >> >> The IPKIX, ISPKI, IPGP, and IACPKIX types indicate a URL that will >> serve the content that would have been in the "certificate, CRL, or >> URL" field of the corresponding types; PKIX, SPKI, PGP, or ACPKIX >> respectively. The IPKIX, ISPKI, IPGP, and IACPKIX types are known >> as "indirect". >> >>NEW: >> >> The IPKIX and IACPKIX types indicate a URL that will serve the >> content that would have been in the "certificate, CRL, or URL" >> field of the corresponding types; PKIX or ACPKIX respectively. >> >> The IPGP type contains both an OpenPGP fingerprint for the key in >> question, as well as a URL. The certificate portion of the IPGP >> CERT RR is defined as a one-octet fingerprint length, followed by >> the OpenPGP fingerprint, followed by the URL. The OpenPGP >> fingerprint is calculated as defined in RFC-2440 [5]. A >> zero-length fingerprint or a zero-length URL are legal, and >> indicate URL-only IPGP data or fingerprint-only IPGP data >> respectively. A zero-length fingerprint and a zero-length URL is >> meaningless and invalid. >> >> The IPKIX, ISPKI, IPGP and IACPKIX types are known as "indirect". >> >> >>Section 8, OLD: >> >> 6 IPGP The URL of an OpenPGP packet RFC 4398 >> >>NEW: >> >> 6 IPGP The fingerprint and URL RFC 4398 >> of an OpenPGP 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 Tue Mar 21 17:02:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLovn-0002AB-9u for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 17:02:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLovl-0005ae-UH for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 17:02:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLou9-000B6w-C0 for namedroppers-data@psg.com; Tue, 21 Mar 2006 22:00:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLou8-000B6g-KZ for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 22:00:40 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 1810756855 for ; Tue, 21 Mar 2006 14:00:40 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060321164848.03948120@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 21 Mar 2006 17:02:07 -0500 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f During the DNSEXT meeting today I volunteered to review the above document with the goal of getting it off the DNSEXT rolls one way or the other. My findings: 1) It's currently expired. 2) It appears to be pretty much the same thing as RFC2535 minus the glue to actually describe the containing RR. 2535 described DSA in a SIG record or a KEY record and described algorithm identifiers etc. This document describes DSA info as part of a containing RDATA for SIG and KEY. The actual technical crypto grit hasn't changed. 3) There's no section describing these changes or the reasoning for them. 4) The tools page reports several nits as well as one warning. I can't support the advancement of this document at this time. In the attempt to make it RR agnostic the revisions took away too much connective tissue. I don't believe it to be prudent to describe the RDATA content without describing the specific applicable record (RR) type(s). If this update expanded the application of these into both the RRSIG and DNSKEY records (and left them available for SIG and KEY) I'd be much happier. If this document obsoleted the use in SIG and KEY and defined them for RRSIG and DNSKEY I'd be very happy. If the document also described the triggering event (e.g. typecode rollover of DNSSEC) I'd be ecstatic. Mike -- to unsubscribe send a message to namedroppers-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 Mar 21 17:11:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLp4w-0007Po-Sd for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 17:11:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLp4u-00068T-C8 for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 17:11:50 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLp2t-000C24-DI for namedroppers-data@psg.com; Tue, 21 Mar 2006 22:09:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLp2q-000C1Q-6g for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 22:09:40 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 83E8A33C3F; Tue, 21 Mar 2006 22:09:37 +0000 (GMT) Message-ID: <44207970.5000808@algroup.co.uk> Date: Tue, 21 Mar 2006 22:08:48 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060305) MIME-Version: 1.0 To: Sam Weiler CC: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> <441F9CFC.8020306@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Sam Weiler wrote: > On Tue, 21 Mar 2006, Ben Laurie wrote: > >>>> The consequence of such a recommendation is that no public zone will >>>> be able to set their iterations higher, and so it will effectively be >>>> an upper limit. >>> >>> Why wouldn't a public zone be able to set their iterations higher? >>> >>> Your statement sounds remarkably like "no public zone will be able to >>> use a new hash or crypto algorithm", which I certainly hope is untrue. > ... >> There is no knob I can turn in a resolver that will make it understand a >> new hash algorithm, in sharp contrast to number of iterations, so I >> totally don't buy this analogy. > > Whether or not you "buy" the analogy, you could at least have the good > grace to answer the direct question: why wouldn't a public zone be able > to set their iterations higher? You already answered it - because then some NSEC3-aware resolvers would be unable to validate answers from the zone. Your statement that a zone choosing to use NSEC3 at all would mean that some resolvers couldn't validate the zone doesn't strike me as motivation for increasing the number of resolvers that can't. As we all know, some zones _cannot_ deploy NSEC. I see no point in beating that dead horse further. -- http://www.links.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 Mar 21 17:26:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpIs-0001Ie-1W for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 17:26:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpIr-00073w-LF for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 17:26:14 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLpG8-000D46-E7 for namedroppers-data@psg.com; Tue, 21 Mar 2006 22:23:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLpG7-000D3t-Q5 for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 22:23:23 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 2636D56848 for ; Tue, 21 Mar 2006 14:23:23 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060321170911.03c2f898@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 21 Mar 2006 17:24:50 -0500 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: draft-ietf-dnsext-rfc2539bis-dhk-06.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_153480983==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --=====================_153480983==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed As part of the DNSEXT meeting I agreed to review the above document with a view to getting it off of the chair's list. It has passed WGLC, but hasn't had sufficient reviewers for AD comfort. 1) The document is currently expired. 2) The document appears to substantially share text with RFC2539 with the exception that the specific reference to how to incorporate DH data with a KEY record has been replaced with "within the RDATA portion of a RR". 3) The document includes text about a "work in progress" that was a work in progress back when 2539 was published. That either needs to be removed or cited. 4) There are several nits and warnings on the existing draft (e.g. old boilerplate) For at least some of the same reasons as I cited in for the DSA draft, I can't support advancement of this draft. E.g. there isn't enough connective tissue between this document and RFC4034 which specifies the various record formats. To be adequate for publication, this document should explicitly cite DNSKEY as the record reference and completely specify the part of the RDATA for the DNSKEY to which this applies. Also, the algorithm information identifier from 2535 should be added to this document. Also, the "PublicValue is the binary representation of the DH public value with most significant byte first." statement needs to clearly identify this is a positive integer (ditto for prime) with no leading zero octets or some such. - This is necessary to ensure implementers don't accidentally just plug the number into the "BigInteger" function and end up with negative numbers of some sort. In other words, the binary representative as stated is ambiguous. Mike --=====================_153480983==.ALT Content-Type: text/html; charset="us-ascii" As part of the DNSEXT meeting I agreed to review the above document with a view to getting it off of the chair's list.  It has passed WGLC, but hasn't had sufficient reviewers for AD comfort.

1) The document is currently expired.

2) The document appears to substantially share text with RFC2539 with the exception that the specific reference to how to incorporate DH data with a KEY record has been replaced with "
within the RDATA portion
of a RR". 
3) The document includes text about a "work in progress" that was a work in progress back when 2539 was published.  That either needs to be removed or cited.

4) There are several nits and warnings on the existing draft (e.g. old boilerplate)

For at least some of the same reasons as I cited in for the DSA draft, I can't support advancement of this draft.  E.g. there isn't enough connective tissue between this document and RFC4034 which specifies the various record formats.  To be adequate for publication, this document should explicitly cite DNSKEY as the record reference and completely specify the part of the RDATA for the DNSKEY to which this applies.  Also, the algorithm information identifier from 2535 should be added to this document.

Also, the "
PublicValue is the binary representation of
the DH public value with most significant byte first." statement
needs to clearly identify this is a positive integer (ditto for prime)
with no leading zero octets or some such. - This is necessary to ensure
implementers don't accidentally just plug the number into the
"BigInteger" function and end up with negative numbers of some
sort.  In other words, the binary representative as stated is
ambiguous.
Mike

 --=====================_153480983==.ALT-- -- to unsubscribe send a message to namedroppers-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 Mar 21 18:10:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpzc-0004dh-M5 for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 18:10:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpzb-0000Dm-Db for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 18:10:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLpxM-000HJJ-B8 for namedroppers-data@psg.com; Tue, 21 Mar 2006 23:08:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLpxL-000HJ2-Kn for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 23:08:03 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7FF3633C1C for ; Tue, 21 Mar 2006 23:08:01 +0000 (GMT) Message-ID: <44208720.7000801@algroup.co.uk> Date: Tue, 21 Mar 2006 23:07:12 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060305) MIME-Version: 1.0 To: "'namedroppers@ops.ietf.org'" Subject: DSA and D-H I-Ds? X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 I offered to review these, along with others. Now I can't find them. Where are they? Cheers, Ben. -- http://www.links.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 Mar 21 18:22:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqB0-00056e-2s for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 18:22:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqAy-0000Xw-Mh for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 18:22:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLq9K-000I5h-6W for namedroppers-data@psg.com; Tue, 21 Mar 2006 23:20:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLq9J-000I5F-Hx for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 23:20:25 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id EAFEB56837; Tue, 21 Mar 2006 15:20:24 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060321182118.03c18700@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 21 Mar 2006 18:21:51 -0500 To: Ben Laurie , "'namedroppers@ops.ietf.org'" From: Mike StJohns Subject: Re: DSA and D-H I-Ds? In-Reply-To: <44208720.7000801@algroup.co.uk> References: <44208720.7000801@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Go to http://tools.ietf.org/wg/dnsext/ Mike At 06:07 PM 3/21/2006, Ben Laurie wrote: >I offered to review these, along with others. Now I can't find them. >Where are they? > >Cheers, > >Ben. > >-- >http://www.links.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: -- to unsubscribe send a message to namedroppers-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 Mar 21 23:05:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLub0-00078k-Uk for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 23:05:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLuaz-0002aY-J5 for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 23:05:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLuWb-000F3v-I2 for namedroppers-data@psg.com; Wed, 22 Mar 2006 04:00:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLuWZ-000F3d-03 for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 04:00:43 +0000 Received: from [204.96.114.83] ([::ffff:204.96.114.83]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 21 Mar 2006 23:00:40 -0500 id 002C40E8.4420CBE9.0000065A In-Reply-To: <3166F929-3E0D-46CB-B3BB-A355136FB7B0@NLnetLabs.nl> References: <200602211829.k1LITCpJ009672@staff.nominet.org.uk> <3166F929-3E0D-46CB-B3BB-A355136FB7B0@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v746.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79FCF15E-0D30-47AA-953E-16B4B6B3DA6D@verisignlabs.com> Cc: Olaf Kolkman Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: NSEC3 Issue 13: DDNS and Opt-In Determination Date: Tue, 21 Mar 2006 22:00:37 -0600 To: Namedroppers WG X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Mar 21, 2006, at 7:48 AM, Olaf M. Kolkman wrote: > The opt-in spec has specific language on how to deal with (not > being able to do) dynamic updates in section 4.1.4. I propose that > you would add some similar text to the nsec3 doc. Just to be clear, the opt-in spec disallows dynamic update not because you cannot get dynamic update to work with opt-in, but because it required further specification and no one stepped up to produce that specification. Taking a similar route with NSEC3 seems reasonable to me. While I believe that defining how dynamic update works with NSEC3 is a doable task, I also think it isn't necessary to solve it before finishing the main work with NSEC3. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 21 23:10:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLug6-000117-Nw for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 23:10:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLug5-0002n8-Cs for dnsext-archive@lists.ietf.org; Tue, 21 Mar 2006 23:10:34 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLueV-000Fau-03 for namedroppers-data@psg.com; Wed, 22 Mar 2006 04:08:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLueU-000Fah-FF for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 04:08:54 +0000 Received: from [204.96.114.83] ([::ffff:204.96.114.83]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 21 Mar 2006 23:08:51 -0500 id 002C4032.4420CDD3.000007C3 In-Reply-To: <44207970.5000808@algroup.co.uk> References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> <441F9CFC.8020306@algroup.co.uk> <44207970.5000808@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0912AAEB-4CD9-42EC-B54D-2F260438137B@verisignlabs.com> Cc: Sam Weiler , Ben Laurie Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers Date: Tue, 21 Mar 2006 22:08:48 -0600 To: Namedroppers WG X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On Mar 21, 2006, at 4:08 PM, Ben Laurie wrote: > Sam Weiler wrote: >> On Tue, 21 Mar 2006, Ben Laurie wrote: >> >>>>> The consequence of such a recommendation is that no public zone >>>>> will >>>>> be able to set their iterations higher, and so it will >>>>> effectively be >>>>> an upper limit. >>>> >>>> Why wouldn't a public zone be able to set their iterations higher? >>>> >>>> Your statement sounds remarkably like "no public zone will be >>>> able to >>>> use a new hash or crypto algorithm", which I certainly hope is >>>> untrue. >> ... >>> There is no knob I can turn in a resolver that will make it >>> understand a >>> new hash algorithm, in sharp contrast to number of iterations, so I >>> totally don't buy this analogy. >> >> Whether or not you "buy" the analogy, you could at least have the >> good >> grace to answer the direct question: why wouldn't a public zone be >> able >> to set their iterations higher? > > You already answered it - because then some NSEC3-aware resolvers > would > be unable to validate answers from the zone. > > Your statement that a zone choosing to use NSEC3 at all would mean > that > some resolvers couldn't validate the zone doesn't strike me as > motivation for increasing the number of resolvers that can't. To try and salvage some use out of this thread, I thought I would point out that the real point that Sam has raised is that "too many iterations" should cause the validator to treat the response as INSECURE rather than BOGUS as the draft currently states. This certainly makes the consequences of setting the iterations too high more palatable, so I think it should be considered. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 22 00:20:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvly-0004As-9Z for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 00:20:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLvlx-0005wq-WF for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 00:20:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLvi5-000K9J-R1 for namedroppers-data@psg.com; Wed, 22 Mar 2006 05:16:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLvi0-000K8s-9E for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 05:16:41 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2M5FuQ3020356 for ; Wed, 22 Mar 2006 00:15:56 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXeaWUN; Wed, 22 Mar 06 00:15:53 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2M5EHqb008469; Wed, 22 Mar 2006 00:14:19 -0500 (EST) Date: Wed, 22 Mar 2006 00:16:27 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: David Blacka cc: Namedroppers WG Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers In-Reply-To: <0912AAEB-4CD9-42EC-B54D-2F260438137B@verisignlabs.com> Message-ID: References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> <441F9CFC.8020306@algroup.co.uk> <44207970.5000808@algroup.co.uk> <0912AAEB-4CD9-42EC-B54D-2F260438137B@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Tue, 21 Mar 2006, David Blacka wrote: > To try and salvage some use out of this thread, I thought I would > point out that the real point that Sam has raised is that "too many > iterations" should cause the validator to treat the response as > INSECURE rather than BOGUS as the draft currently states. Thanks for the help, David. This inspired me to think of one minor downgrade opportunity... If 1) a zone were to have multiple NSEC3 chains, perhaps because it was in the middle of rolling between NSEC3 parameters, or perhaps because it wanted to use different sets of NSEC3 parameters for different names, and 2) one of those NSEC3 chains used "too many iterations" (noting that "too many iterations" may be a resolver-specific number) and one those NSEC3 chains used "few iterations" (meaning that a given resolver can validate it)... Then, even if the zone was using entirely "few iteration" NSEC3's for most names, an attacker could take one of the "too many iteration" NSEC3's and replay it in response to a query which might normally be answered with a "few iteration" NSEC3, causing that answer to be marked as insecure (since the resolver can't tell if the NSEC3 is applicable to that particular query or not). In other words, if you have ANY "too many iteration" NSEC3's in the zone, your entire zone might be treated as insecure (just as if all of the NSEC3's used "too many iterations"). All in all, this doesn't worry me. If a zone has multiple NSEC3 chains, it's likely in the middle of a transition. And if some of those NSEC3's use "too many iterations", then some resolvers will not have been able to validate the old zone (if rolling from "too many") or will not be able to validate the new zone (if rolling to "too many"), anyway. This doesn't seem like a failure mode we need to do special engineering for. But we should probably mention it in the security considerations section. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 22 00:21:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvn9-00051L-SF for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 00:21:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLvn8-000602-Jb for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 00:21:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLvlv-000KP1-Q2 for namedroppers-data@psg.com; Wed, 22 Mar 2006 05:20:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLvlv-000KOj-1x for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 05:20:39 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2M5Jxje020851 for ; Wed, 22 Mar 2006 00:19:59 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAnzaWTO; Wed, 22 Mar 06 00:19:56 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2M5IDqb008591; Wed, 22 Mar 2006 00:18:14 -0500 (EST) Date: Wed, 22 Mar 2006 00:20:23 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Ben Laurie cc: namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers In-Reply-To: <44207970.5000808@algroup.co.uk> Message-ID: References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> <441F9CFC.8020306@algroup.co.uk> <44207970.5000808@algroup.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Tue, 21 Mar 2006, Ben Laurie wrote: > Your statement that a zone choosing to use NSEC3 at all would mean > that some resolvers couldn't validate the zone doesn't strike me as > motivation for increasing the number of resolvers that can't. I'm now lost. In what context do you think we were talking about "increasing the number of resolvers that can't [validate the zone]" and what is it you think we were proposing that that would have the effect of "increasing the number of resolvers that can't [validate the zone]"? -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 22 00:48:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLwCe-0004NV-22 for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 00:48:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLwCc-0006oz-Nz for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 00:48:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLwAu-000M5G-Aq for namedroppers-data@psg.com; Wed, 22 Mar 2006 05:46:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLwAt-000M54-8d for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 05:46:27 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2M62GQU013392 for ; Tue, 21 Mar 2006 23:02:17 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k2M622IH003458 for ; Wed, 22 Mar 2006 00:02:03 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DSA and D-H I-Ds? Date: Wed, 22 Mar 2006 00:46:24 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790B6DAB7@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSA and D-H I-Ds? Thread-Index: AcZNPwY7oJD04/7sSdyTTCCtnnmjbAAM4jwg From: "Eastlake III Donald-LDE008" To: "Mike StJohns" , "Ben Laurie" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Hi, They have just timed out and I will spin new version with just the version number (-07) and date incremented and boilerplate nits fixed and re-submit. You can get them as suggested below or at http://www.pothole.com/~dee3. Thanks, Donald=20 -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Mike StJohns Sent: Tuesday, March 21, 2006 6:22 PM To: Ben Laurie; namedroppers@ops.ietf.org Subject: Re: DSA and D-H I-Ds? Go to http://tools.ietf.org/wg/dnsext/ Mike At 06:07 PM 3/21/2006, Ben Laurie wrote: >I offered to review these, along with others. Now I can't find them. >Where are they? > >Cheers, > >Ben. > >-- >http://www.links.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: -- to 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 Mar 22 00:55:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLwJh-00080N-Db for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 00:55:33 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLwJh-0007Bd-1M for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 00:55:33 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLwIJ-000MYp-2d for namedroppers-data@psg.com; Wed, 22 Mar 2006 05:54:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.0 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLwII-000MYb-8I for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 05:54:06 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2M5rQGx025243 for ; Wed, 22 Mar 2006 00:53:26 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAwkaOmX; Wed, 22 Mar 06 00:53:14 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2M5pdqb009572; Wed, 22 Mar 2006 00:51:40 -0500 (EST) Date: Wed, 22 Mar 2006 00:53:49 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: David Blacka cc: Namedroppers Subject: Re: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> Message-ID: References: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 >> That said, I suspect a few more eyes would be helpful -- this >> document has some subtle details that could benefit from extremely close >> scrutiny. > > Other than its experimental status, this document *has* benefited > from extremely close scrutiny. I'm not sure why, specifically, you > think it needs more. (Assuming that you want your expression of uncertainty to be treated as a question...) In my limited reread of this document, I found an unexpectedly high density of phrases that puzzled me or that I feared could be misread (see examples in my last note). I also noticed that a number of those who responded to Olaf's WGLC reminder only commented on the experiments draft, not opt-in. And I noticed that of those who had read opt-in, most didn't send any nits to namedroppers. Given that the document contains some boring details (like the examples, which I entirely skipped on this reading), I feared that things had been missed. All that said, I didn't quite say it "needs" more -- I added a few more qualifiers to my attempt to draw out further reviewers. >> Other substantive questions: >> >> A protocol correctness question, from section 4.2.1: >> >> As stated in the "Server Considerations" section above, this >> specification restricts the namespace covered by Opt-In tagged NSEC >> records to insecure delegations only. Thus, resolvers MUST generate >> a validation failure when encountering records other than NS or glue >> that fall within an Opt-In NSEC record's span. >> >> If a server is authoritative for both an opt-in signed parent and an >> unsigned child, what happens when the resolver receives an A record from >> the child zone? The resolver doesn't see the NS record ... > > This isn't a special case. This happens in non-opt-in DNSSEC. > What do you think happens there? My fear is that we get a Failure validation result, for want of having clearly told resolvers how to distinguish between the case I described and the case where is there isn't a delegation (and the A record is in the parent zone). Would you walk through the process (whether from rfc4035 or 4.2 of this document) for this example? Query: child.example A (sent to server authoritative for both example and child.example) Answer: that A record (and nothing else) Does the resolution process then go on to prove that there's a delegation to child.example? If not, how do we separate this case from the one where this is no delegation to child.example (which, per the quoted text, MUST generate a validation failure)? >> Why the requirement for "clear path" in section 7? Why do >> intermediate caches (whether validating w/ non-opt-in DNSSEC or >> not) need to understand opt-in? > > Because an intermediate cache will not (necessarily) be able to > reconstruct opt-in responses from its cache. Would you give me an example? -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 22 05:30:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM0cB-0002Ro-4M for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 05:30:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM0c9-0000eJ-P2 for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 05:30:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM0YT-000Dsd-Qq for namedroppers-data@psg.com; Wed, 22 Mar 2006 10:27:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.0 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM0YS-000DsK-Oy for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 10:27:05 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1269633C3F for ; Wed, 22 Mar 2006 10:26:17 +0000 (GMT) Message-ID: <44212618.4030308@algroup.co.uk> Date: Wed, 22 Mar 2006 10:25:28 +0000 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060305) MIME-Version: 1.0 To: "'namedroppers@ops.ietf.org'" Subject: DH/DSA I-Ds X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Here's my review of the DSA/DH I-Ds. You may regret asking for volunteers in my presence :-) RFC 2536bis - DSA keys 1. When referring to FIPS 186-2 I believe it is called DSS Digital Signature Standard), not DSA. 2. I object to Schneier as a reference when Handbook of Applied Cryptography is a) better and b) freely available on the web. 3. This assumes a 160 bit hash. NIST has just approved all the other SHAs as appropriate hashes for DSS, so it seems silly not to revise the I-D to allow for that, especially since we should generally remove hard dependencies on SHA-1. 4. The prime is limited to 2560 bits, which may be small by modern standards. RFC 2539bis - DH 1. See 2 above. 2. The prime/generator pairs described in the appendix are generally known as Oakley Groups - it would be good to name them properly. 3. 768 bit primes are _weak_ and should be killed. 4. Perhaps larger "standard" primes should be included (the biggest is currently 1536 bits). Cheers, Ben. -- http://www.links.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 Wed Mar 22 14:07:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8fk-0006Fg-3x for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 14:07:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM8fi-0005iW-Kv for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 14:07:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM8cK-000Koy-2e for namedroppers-data@psg.com; Wed, 22 Mar 2006 19:03:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM8cI-000Koj-HC for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 19:03:34 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2MJ3Qbe080587; Wed, 22 Mar 2006 20:03:27 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <44207970.5000808@algroup.co.uk> References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> <441F9CFC.8020306@algroup.co.uk> <44207970.5000808@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-36--609277466" Message-Id: <6895E8C8-B2C4-4D71-AD75-E9225445794E@NLnetLabs.nl> Cc: Sam Weiler , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers Date: Wed, 22 Mar 2006 13:02:43 -0600 To: Ben Laurie X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-36--609277466 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 21, 2006, at 4:08 PM, Ben Laurie wrote: > You already answered it - because then some NSEC3-aware resolvers > would > be unable to validate answers from the zone. > > Your statement that a zone choosing to use NSEC3 at all would mean > that > some resolvers couldn't validate the zone doesn't strike me as > motivation for increasing the number of resolvers that can't. > > As we all know, some zones _cannot_ deploy NSEC. I see no point in > beating that dead horse further. During the WG meeting you mentioned that the number of iterations (section 8.3) could be increased sometime in the future. So what happens when at some time X the number of iterations 'allowed' will be increased. There is no (specified) way for a NSEC3 aware resolver to become aware of the increased allowed number of iterations. A zone owner will not know if and/or when the set of resolvers has been updated to comply with the new number of iterations. Which would mean that in practice a zone owner will not be able to upgrade. I therefore think that you will not be able to change the number of iterations field. You could say that the number of iterations can be increased when you introduce new key or hash algorithms but that probably only work for algorithms that MUST be supported. While skimming the ID again I did not find any text suggesting that the number of iterations may or should be modified in the future. I propose not to add such text and live with the fact that you will not be able to modify the costs once you set the numbers in 8.3. You may want to add text to the security section expanding on that. Not sure, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-36--609277466 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEIZ+DtN/ca3YJIocRAgGSAJ4nCOketT4d0tSdYCvOzirI4Tz5uwCgiqs8 6ZZsOP5wEO9tzrs6sxqBN3Q= =tvIY -----END PGP SIGNATURE----- --Apple-Mail-36--609277466-- -- to unsubscribe send a message to namedroppers-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 Mar 22 15:30:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9xw-0004ky-8w for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 15:30:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9xv-0000WL-0P for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 15:30:00 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM9t5-0000dT-T7 for namedroppers-data@psg.com; Wed, 22 Mar 2006 20:24:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM9t3-0000cp-1D for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 20:24:57 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2MKOnjj081712; Wed, 22 Mar 2006 21:24:50 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <6895E8C8-B2C4-4D71-AD75-E9225445794E@NLnetLabs.nl> References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> <441F9CFC.8020306@algroup.co.uk> <44207970.5000808@algroup.co.uk> <6895E8C8-B2C4-4D71-AD75-E9225445794E@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-40--604346435" Message-Id: <2FD007CA-073F-4A1C-BBFB-EF319535C707@NLnetLabs.nl> Cc: Ben Laurie , Sam Weiler , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers Date: Wed, 22 Mar 2006 14:24:54 -0600 To: "Olaf M. Kolkman" X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-40--604346435 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > During the WG meeting you mentioned that the number of iterations > (section 8.3) could be increased sometime in the future. When I wrote this message I had not seens David's remark yet. The "treat as INSECURE" is a good solution to this as well. Good thinking! --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-40--604346435 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEIbKWtN/ca3YJIocRAnuWAKCWGV8r7TzzZioCEuWDIh9rjA+wGQCg+ZLw DPus8C/RRRud9FkjDeR8Zes= =685O -----END PGP SIGNATURE----- --Apple-Mail-40--604346435-- -- to unsubscribe send a message to namedroppers-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 Mar 22 19:11:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMDAh-0004qp-Fi for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 18:55:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMDAg-0002I7-1u for dnsext-archive@lists.ietf.org; Wed, 22 Mar 2006 18:55:22 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMD5a-000CXe-OK for namedroppers-data@psg.com; Wed, 22 Mar 2006 23:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMD5Y-000CWw-8E for namedroppers@ops.ietf.org; Wed, 22 Mar 2006 23:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2MNo2vP026493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMD5W-0002Fr-E6; Wed, 22 Mar 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-11.txt Message-Id: Date: Wed, 22 Mar 2006 18:50:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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 : The Role of Wildcards in the Domain Name System Author(s) : E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-11.txt Pages : 30 Date : 2006-3-22 This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-wcard-clarify-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-wcard-clarify-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: <2006-3-22163822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-22163822.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 Mar 23 11:22:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSa1-0006WQ-SE for dnsext-archive@lists.ietf.org; Thu, 23 Mar 2006 11:22:33 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSa0-0001q0-J9 for dnsext-archive@lists.ietf.org; Thu, 23 Mar 2006 11:22:33 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMSUd-0003aA-Iq for namedroppers-data@psg.com; Thu, 23 Mar 2006 16:16:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMSUc-0003Zw-Mo for namedroppers@ops.ietf.org; Thu, 23 Mar 2006 16:16:58 +0000 Received: from [130.129.131.68] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2NGGg3L036057; Thu, 23 Mar 2006 11:16:48 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 23 Mar 2006 10:16:50 -0600 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-11.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Oh, that... At 18:50 -0500 3/22/06, Internet-Drafts@ietf.org wrote: > Title : The Role of Wildcards in the Domain Name System > Author(s) : E. Lewis > Filename : draft-ietf-dnsext-wcard-clarify-11.txt > Pages : 30 > Date : 2006-3-22 >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-11.txt FYI, as this has been dragging on for quite some time (college freshmen that entered school at the start of this effort are now preparing for their senior graduation exams ;))... ...this was to answer a gaggle of post-last-call comments (there were no during last-call comments) raised by discussions in the IESG and other mail that I received. I've been told that some were to send me comments now. To be warned, if it's not AUTH48'able, it'll wait until "Clarifications on the Role of Wildcards in the Domain Name System" or perhaps until "The Domain Name System, version 2." The last was a joke. I hope. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 23 19:57:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMac4-0000ea-Vp for dnsext-archive@lists.ietf.org; Thu, 23 Mar 2006 19:57:12 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMa79-0001dm-1B for dnsext-archive@lists.ietf.org; Thu, 23 Mar 2006 19:25:15 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMZwD-0008Vs-5q for dnsext-archive@lists.ietf.org; Thu, 23 Mar 2006 19:13:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZZC-0001FI-BL for namedroppers-data@psg.com; Thu, 23 Mar 2006 23:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZZB-0001F6-Lp for namedroppers@ops.ietf.org; Thu, 23 Mar 2006 23:50:09 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2NNo29W031356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMZZ4-0001Ej-6H; Thu, 23 Mar 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-2929bis-02.txt Message-Id: Date: Thu, 23 Mar 2006 18:50:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-2929bis-02.txt Pages : 18 Date : 2006-3-23 Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, RR types, operation codes, error codes, RR header bits, and AFSDB subtypes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-2929bis-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-2929bis-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: <2006-3-23165832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-2929bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-2929bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-23165832.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 Mar 23 20:11:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMaqA-0000rg-HJ for dnsext-archive@lists.ietf.org; Thu, 23 Mar 2006 20:11:46 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMa78-0001dm-AV for dnsext-archive@lists.ietf.org; Thu, 23 Mar 2006 19:25:14 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FMZxS-00006d-OS for dnsext-archive@lists.ietf.org; Thu, 23 Mar 2006 19:15:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZZ7-0001EJ-31 for namedroppers-data@psg.com; Thu, 23 Mar 2006 23:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMZZ6-0001DH-54 for namedroppers@ops.ietf.org; Thu, 23 Mar 2006 23:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2NNo2vP010949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMZZ4-0001EF-23; Thu, 23 Mar 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-13.txt Message-Id: Date: Thu, 23 Mar 2006 18:50:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for Encoding DHCP Information (DHCID RR) Author(s) : M. Stapp, et al. Filename : draft-ietf-dnsext-dhcid-rr-13.txt Pages : 12 Date : 2006-3-23 It is possible for DHCP clients to attempt to update the same DNS FQDN or attempt to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the "DHCID" RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-13.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-dhcid-rr-13.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: <2006-3-23164548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-23164548.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 Mar 24 13:34:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMr6y-0007wH-3m for dnsext-archive@lists.ietf.org; Fri, 24 Mar 2006 13:34:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMr6v-0005JB-GB for dnsext-archive@lists.ietf.org; Fri, 24 Mar 2006 13:34:12 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMr39-000LWn-Cj for namedroppers-data@psg.com; Fri, 24 Mar 2006 18:30:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HEADER_SPAM autolearn=no version=3.1.0 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FMr37-000LWY-Nd for namedroppers@ops.ietf.org; Fri, 24 Mar 2006 18:30:14 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2OIU6H1048385 for ; Fri, 24 Mar 2006 13:30:06 -0500 (EST) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k2OIU5HQ048384 for namedroppers@ops.ietf.org; Fri, 24 Mar 2006 13:30:05 -0500 (EST) (envelope-from namedroppers) Received: from [80.91.229.2] (helo=ciao.gmane.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FLnVM-0005Q7-4H for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 20:31:00 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FLnVE-0005lS-KA for namedroppers@ops.ietf.org; Tue, 21 Mar 2006 21:30:52 +0100 Received: from dhcp-wireless-131-219.ietf65.org ([130.129.131.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Mar 2006 21:30:52 +0100 Received: from mcr by dhcp-wireless-131-219.ietf65.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 21 Mar 2006 21:30:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: namedroppers@ops.ietf.org From: Michael Richardson Subject: draft-ietf-dnsext-rfc2536bis-dsa-06 Date: Tue, 21 Mar 2006 13:26:21 -0600 Lines: 31 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dhcp-wireless-131-219.ietf65.org User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) Cancel-Lock: sha1:ec3LKZnw5g8759ApgPumSkZnLW4= X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] --=-=-= I read this document and I think that I understand it. I would prefer to have an example vector, in both presentation format and "wire-format", also also an example of a SIG RR that has this. {that my request is perhaps that is a higher standard than exists for the other algorithms, I acknowledge} -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUARCBTYICLcPvd0N1lAQJlbAf/Y5p9WU0MHuoQ5CtmMsuMHmEB6x6NOcOW OxNr12QPOM6AS6LWRvUiZS4kyjwLjvcV6XPpKXTc8hHHKddCXJ8Ug86QV53qB7fz gCG2vB13WHhkavtlzGw1wdT9ntgnBDrSHYV/tZ0Q/mntr18VCSFbqpYxCI7E/8JK 8BbcEm0iQgw6MuUuIrBln4dSEzoA1vrPJ+i9O+hg1psulyeb7QNKySLBaMFHyYLY aaPGfMyDUAamigMrfj/5R64bsWlHRBQb37V5g4uq3zuD6SLeEfoDrVOfSFgsI5rw HeSjynHMLCqeTgZCsrq/bnB/kYtRWE6cTBvDzY7aj0DXH1SpHAMt7A== =QXsF -----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 mya@yahoo.co.jp Sat Mar 25 12:28:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNCYS-00076c-0Z for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 12:28:00 -0500 Received: from [222.160.101.119] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FNCYQ-0008UY-94 for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 12:27:59 -0500 To: From: =?iso-2022-jp?B?bXlh?= Subject: =?iso-2022-jp?B?GyRCJV4lOSVAJEckOSEjOTk/NyQ3JF4kNyQ/ISobKEI=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 $B%"%"%`%j%g%&!Z:G?79f![=U$NH/>p(B http://rightmyfire.co.uk/aa/ $BLd!K(B xin0@walla.com From owner-namedroppers@ops.ietf.org Sat Mar 25 18:51:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNIXm-0003wJ-Ae for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 18:51:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNIXl-0005z0-Vy for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 18:51:42 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNISp-0007H9-Ig for namedroppers-data@psg.com; Sat, 25 Mar 2006 23:46:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [144.189.100.103] (helo=motgate3.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNISo-0007Gv-Hi for namedroppers@ops.ietf.org; Sat, 25 Mar 2006 23:46:34 +0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k2Q07eib002806 for ; Sat, 25 Mar 2006 17:07:40 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k2Q07AT7002974 for ; Sat, 25 Mar 2006 18:07:11 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Date: Sat, 25 Mar 2006 18:46:29 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790BB2219@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Thread-Index: AcZNM+EbBljFr8EKTaKmfq+wK+l5sgDD8rwA From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi, See below at @@@ -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Mike StJohns Sent: Tuesday, March 21, 2006 5:02 PM To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review During the DNSEXT meeting today I volunteered to review the above document with the goal of getting it off the DNSEXT rolls one way or the other. My findings: 1) It's currently expired. @@@ I've submitted a revision that has just the date and version bumped and the boilerplate nits fixed. 2) It appears to be pretty much the same thing as RFC2535 minus the glue to actually describe the containing RR. 2535 described DSA in a SIG record or a KEY record and described algorithm identifiers etc.=20 This document describes DSA info as part of a containing RDATA for=20 SIG and KEY. The actual technical crypto grit hasn't changed. 3) There's no section describing these changes or the reasoning for them. 4) The tools page reports several nits as well as one warning. I can't support the advancement of this document at this time. In the attempt to make it RR agnostic the revisions took away too much connective tissue. I don't believe it to be prudent to describe the RDATA content without describing the specific applicable record (RR) type(s). @@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG RRs (if that's what you mean by "connective tissue") but not the algorithm dependent data format. At this point, the DNS DSA key format is usable in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support IPSEC). The DNS DSA signature format is usable in RRSIG and SIG (to support SIG(0)). Things like the "algorithm number" are different in DNSKEY and IPSECKEY. I believe it is contemplated that there might be additional application specific key RRs, like IPSECKEY, defined in the future. If this update expanded the application of these into both the RRSIG and DNSKEY records (and left them available for SIG and KEY) I'd be much happier. If this document obsoleted the use in SIG and KEY and defined them for RRSIG and DNSKEY I'd be very happy. If the document also described the triggering event (e.g. typecode rollover of DNSSEC) I'd be ecstatic. @@@ It's probably a good idea to give more background/motivational material in this document. And it might be a good idea to list the RRs (with a pointer to the best defining RFC) to which the data format defined in this document is applicable, as long as it is made clear that additional RRs may be defined in the future which would reference and use this format. However, I don't see any reason to obsolete its use in SIG or KEY since, as far as I know, those still exist to support SIG(0) and TKEY. Mike @@@ Thanks, @@@ Donald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 25 19:12:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNIsG-0001cm-PP for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 19:12:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNIsG-0007pL-8n for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 19:12:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNIq3-0009KB-SY for namedroppers-data@psg.com; Sun, 26 Mar 2006 00:10:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNIq2-0009Jw-W9 for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 00:10:35 +0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2Q0QUo8029054 for ; Sat, 25 Mar 2006 17:26:30 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k2Q0Qg5Q026152 for ; Sat, 25 Mar 2006 18:26:42 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-dnsext-rfc2539bis-dhk-06.txt Date: Sat, 25 Mar 2006 19:10:24 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790BB221A@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dnsext-rfc2539bis-dhk-06.txt Thread-Index: AcZNN4WaeBjuioP+QR+nSbjGNvLa2wDLtgQg From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Hi, =20 See below at @@@ ________________________________ From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Mike StJohns Sent: Tuesday, March 21, 2006 5:25 PM To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-rfc2539bis-dhk-06.txt As part of the DNSEXT meeting I agreed to review the above document with a view to getting it off of the chair's list. It has passed WGLC, but hasn't had sufficient reviewers for AD comfort. 1) The document is currently expired.=20 =20 @@@ As with the 2536bis draft, an update has been submitted with just the version and date bumped and the boilerplate nits fixed. 2) The document appears to substantially share text with RFC2539 with the exception that the specific reference to how to incorporate DH data with a KEY record has been replaced with " within the RDATA portion of a RR".=20 @@@ In addition, one more abbreviation for a standard Diffie-Hellman group has been included. Also, as per my 12/27/2005 posting to namedroppers, there are yet two more additional standard DH groups defined in RFC 3526 (in connection with IPsec), for which DNS DH key format abbreviations should be defined and, to avoid duplication and possible inconsistency, the details of these standard DH groups should be omitted and RFC 3526 referenced. =20 3) The document includes text about a "work in progress" that was a work in progress back when 2539=20 was published. That either needs to be removed or cited.=20 =20 @@@ This is just in the acknowledgements section, since some of the material in this draft was duplicated from another Internet-Draft which was long ago abandoned and has expired. I suppose I could change the acknowledgements to be less informative by removing that reference while leaving in the names of the people being acknowledged.=20 4) There are several nits and warnings on the existing draft (e.g. old boilerplate) For at least some of the same reasons as I cited in for the DSA draft, I can't support advancement of this draft. E.g. there isn't enough connective tissue between this document and RFC4034 which specifies the various record formats. To be adequate for publication, this document should explicitly cite DNSKEY as the record reference and completely specify the part of the RDATA for the DNSKEY to which this applies. Also, the algorithm information identifier from 2535 should be added to this document. @@@ The format in this document is usable in both DNSKEY and KEY (to support TKEY). It is probably a good idea to list the RR types in which it is used and cite their best RFC definition. I'm also fine with giving the motivations for this revision. But all the bits outside of the DH key format defined in this document are defined in other documents, like RFC 4034. While the same algorithm number is used in DNSKEY and KEY, it is the case that as shown by the IPSECKEY RR, it is quite possible that in the future application specific RRs might be defined which would want to reference this DH data format but use different algorithm numbers or identifiers. So, if the algorithm number is included in this document, it needs to be clear that the "DH" algorithm might be otherwise identified in future defined RRs. Also, the " PublicValue is the binary representation of the DH public value with most significant byte first." statement needs to clearly identify this is a positive integer (ditto for prime) with no leading zero octets or some such. - This is necessary to ensure implementers don't accidentally just plug the number into the "BigInteger" function and end up with negative numbers of some sort. In other words, the binary representative as stated is ambiguous. @@@ OK. This would be a good change to make. Mike @@@ Thanks, @@@ Donald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Mar 25 19:45:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNJNM-00055s-Fo for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 19:45:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNJNM-0000BI-2Q for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 19:45:00 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNJKn-000KGk-LQ for namedroppers-data@psg.com; Sun, 26 Mar 2006 00:42:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNJKm-000KGX-Mn for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 00:42:20 +0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2Q0wG83001658 for ; Sat, 25 Mar 2006 17:58:16 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k2Q0wS36000307 for ; Sat, 25 Mar 2006 18:58:28 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DH/DSA I-Ds Date: Sat, 25 Mar 2006 19:42:17 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790BB221B@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DH/DSA I-Ds Thread-Index: AcZNnSQ25NKsoa4ARv6VhtGB6Ss82gAN7LCg From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Hi, See below at @@@ -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Ben Laurie Sent: Wednesday, March 22, 2006 5:25 AM To: namedroppers@ops.ietf.org Subject: DH/DSA I-Ds Here's my review of the DSA/DH I-Ds. You may regret asking for volunteers in my presence :-) RFC 2536bis - DSA keys 1. When referring to FIPS 186-2 I believe it is called DSS Digital Signature Standard), not DSA. @@@ Indeed, the FIPS document is DSS. But this draft is intended to only cover DSA =3D Digital Signature Algorithm keys and signatures. The new = DSS document covers RSA and ECDSA signatures also. The right term needs to be used for the particular context. 2. I object to Schneier as a reference when Handbook of Applied Cryptography is a) better and b) freely available on the web. @@@ I assume you are referring to Menezes. I've got no problem with adding that as a reference but I'm more reluctant to remove an existing reference. What's the URL for Menezes on-line? 3. This assumes a 160 bit hash. NIST has just approved all the other SHAs as appropriate hashes for DSS, so it seems silly not to revise the I-D to allow for that, especially since we should generally remove hard dependencies on SHA-1. 4. The prime is limited to 2560 bits, which may be small by modern standards. @@@ Responding to both of the above comments, yes, I understand that FIPS 186-3 has just been approved. I'll look it over and see what changes would be needed. I do think that this document should cover the new extended DSA. In general, limitations on size of primes and the like ought to appear where the specific RR is defined that makes use of this DSA key/signature format. However, where that has not been done, as for example in RFC 4034, the limitations for pre-existing RR uses of the DSA format probably have to be in this document. @@@ You suggest raising the 2560 bit limit, I assume for DNSKEY. Would that break code? If it were to be changed, what new value would you suggest? I'm inclined to say that, to minimize change, the size limit should not change for DNSKEY and KEY. RFC 2539bis - DH 1. See 2 above. 2. The prime/generator pairs described in the appendix are generally known as Oakley Groups - it would be good to name them properly. @@@ OK. There are also two more of them now that have been adopted in IPSEC which should be added. See my response to Mike StJohns. 3. 768 bit primes are _weak_ and should be killed. @@@ What minimum size would you suggest? I'm inclined to leave this alone for existing RRs and to say that any future RRs that are defined to use this format need to also specify the limitations on use. 4. Perhaps larger "standard" primes should be included (the biggest is currently 1536 bits). @@@ Yes, the additional ones references in my response to point 2 above are larger and should be included. Cheers, Ben. @@@ Thanks, @@@ Donald -- http://www.links.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 Sat Mar 25 20:02:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNJeh-0007vc-1a for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 20:02:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNJef-0000kT-M2 for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 20:02:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNJbu-000LUv-35 for namedroppers-data@psg.com; Sun, 26 Mar 2006 01:00:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNJbt-000LUZ-D1 for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 01:00:01 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 1839956825; Sat, 25 Mar 2006 16:59:59 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060325190957.040929e8@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 25 Mar 2006 20:01:16 -0500 To: "Eastlake III Donald-LDE008" , From: Mike StJohns Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review In-Reply-To: <3870C46029D1F945B1472F170D2D9790BB2219@de01exm64.ds.mot.co m> References: <3870C46029D1F945B1472F170D2D9790BB2219@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 At 06:46 PM 3/25/2006, Eastlake III Donald-LDE008 wrote: >@@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG RRs (if >that's what you mean by "connective tissue") but not the algorithm >dependent data format. At this point, the DNS DSA key format is usable >in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support IPSEC). The >DNS DSA signature format is usable in RRSIG and SIG (to support SIG(0)). >Things like the "algorithm number" are different in DNSKEY and IPSECKEY. >I believe it is contemplated that there might be additional application >specific key RRs, like IPSECKEY, defined in the future. The problem is that you'd actually have to specify the actual way you fit this into DNSKEY and RRSIG to be useable. This document is not sufficient to do that without making some possibly ambiguous assumptions. Which means you'd need yet another document to fulfill that requirement. And that makes this document somewhat useless and pointless. Mike -- to unsubscribe send a message to namedroppers-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 Mar 25 20:32:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNK7Z-0002iI-Fz for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 20:32:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNK7Z-0002Bn-33 for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 20:32:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNK4L-000NL3-RW for namedroppers-data@psg.com; Sun, 26 Mar 2006 01:29:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNK4K-000NKq-Gm for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 01:29:24 +0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2Q1jKG1005833 for ; Sat, 25 Mar 2006 18:45:20 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k2Q1gMOH026176 for ; Sat, 25 Mar 2006 19:42:22 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Date: Sat, 25 Mar 2006 20:29:21 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790BB2222@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Thread-Index: AcZQcKOqcHpd4ifMQ1W3ejQj7534oAAATJAw From: "Eastlake III Donald-LDE008" To: "Mike StJohns" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi Mike, I'd like to know exactly what you mean. What assumptions do you have to make? Let's just talk about DNSKEY to be specific. Seems to me that RFC 4034 does a reasonable job of defining the wire encoding of DNSKEY except for the interior of the part of the RDATA which it calls "Public Key" in Section 2.1 of RFC 4034. Do you think the problem is that draft 2536bis is ambiguous in defining the wire encoding of DSA keys? I can see how it could be improved to be a little clearer in that regard. Or is that you alternatively or additionally think that, even in the face of a hypothetical perfect description in 2536bis of the octet wire encoding sequence for a DSA key in the DNS, that RFC 4034 isn't clear enough about where to stuff the data? Or what? 2536bis specifies the order of the subfields within the "Public Key" data for a DSA key and explicitly says the octets within a subfield are stored in 'stored in "big-endian" network order'... Thanks, Donald -----Original Message----- From: Mike StJohns [mailto:Mike.StJohns@nominum.com]=20 Sent: Saturday, March 25, 2006 8:01 PM To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review At 06:46 PM 3/25/2006, Eastlake III Donald-LDE008 wrote: >@@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG RRs (if=20 >that's what you mean by "connective tissue") but not the algorithm=20 >dependent data format. At this point, the DNS DSA key format is usable=20 >in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support IPSEC). The=20 >DNS DSA signature format is usable in RRSIG and SIG (to support SIG(0)). >Things like the "algorithm number" are different in DNSKEY and IPSECKEY. >I believe it is contemplated that there might be additional application >specific key RRs, like IPSECKEY, defined in the future. The problem is that you'd actually have to specify the actual way you fit this into DNSKEY and RRSIG to be useable. This document is not sufficient to do that without making some possibly ambiguous assumptions. Which means you'd need yet another document to fulfill that requirement. And that makes this document somewhat useless and pointless. Mike -- to unsubscribe send a message to namedroppers-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 Mar 25 20:56:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNKU6-0001I1-5g for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 20:56:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNKU5-0002px-MQ for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 20:56:02 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNKS4-000OzL-HI for namedroppers-data@psg.com; Sun, 26 Mar 2006 01:53:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNKS3-000Oz7-Nm for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 01:53:55 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 99A1856836; Sat, 25 Mar 2006 17:53:53 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060325204152.03e93ce8@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 25 Mar 2006 20:55:22 -0500 To: "Eastlake III Donald-LDE008" , From: Mike StJohns Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review In-Reply-To: <3870C46029D1F945B1472F170D2D9790BB2222@de01exm64.ds.mot.co m> References: <3870C46029D1F945B1472F170D2D9790BB2222@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_211510065==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e --=====================_211510065==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:29 PM 3/25/2006, Eastlake III Donald-LDE008 wrote: >Hi Mike, > >I'd like to know exactly what you mean. What assumptions do you have to >make? > >Let's just talk about DNSKEY to be specific. Seems to me that RFC 4034 >does a reasonable job of defining the wire encoding of DNSKEY except for >the interior of the part of the RDATA which it calls "Public Key" in >Section 2.1 of RFC 4034. Do you think the problem is that draft 2536bis >is ambiguous in defining the wire encoding of DSA keys? I can see how it >could be improved to be a little clearer in that regard. Or is that you >alternatively or additionally think that, even in the face of a >hypothetical perfect description in 2536bis of the octet wire encoding >sequence for a DSA key in the DNS, that RFC 4034 isn't clear enough >about where to stuff the data? Or what? How does " the structure of the relevant part of the RDATA part of the RR being used is the fields listed below in the order given." map to "put this in the PublicKey field of the DNSKEY RR"? E.g. why (without going back and reading 2536) should I assume that "relevant part of the RDATA part" maps to the PublicKey field? Also, "which algorithm ID do you use for this in the DNSKEY? 2536 explictly said it was ID 3 - but that's for 'DSA/SHA1' and that's obviously a signature algorithm not a key representation so WTF?" E.g. if the DNSKEY is now used for DSA/SHA256 does the algorithm ID change? Can I use the same DNSKEY for both DSA/SHA1 and DSA/SHA256? (Ditto for RSA....) A document which obsoletes another document should be able to be read on its own and have a complete meaning. This one can't be. This document needs to specify: 1) The algorithm ids specific to this representation both for DNSKEY and for RRSIG. 2) The actual and specific placement of the fields described here within the DNSKEY and RRSIG. Enjoy. Mike >2536bis specifies the order of the subfields within the "Public Key" >data for a DSA key and explicitly says the octets within a subfield are >stored in 'stored in "big-endian" network order'... > >Thanks, >Donald > >-----Original Message----- >From: Mike StJohns [mailto:Mike.StJohns@nominum.com] >Sent: Saturday, March 25, 2006 8:01 PM >To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org >Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review > >At 06:46 PM 3/25/2006, Eastlake III Donald-LDE008 wrote: > >@@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG RRs (if > >that's what you mean by "connective tissue") but not the algorithm > >dependent data format. At this point, the DNS DSA key format is usable > >in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support IPSEC). The > >DNS DSA signature format is usable in RRSIG and SIG (to support >SIG(0)). > >Things like the "algorithm number" are different in DNSKEY and >IPSECKEY. > >I believe it is contemplated that there might be additional application > > >specific key RRs, like IPSECKEY, defined in the future. > > >The problem is that you'd actually have to specify the actual way you >fit this into DNSKEY and RRSIG to be useable. This document is not >sufficient to do that without making some possibly ambiguous >assumptions. Which means you'd need yet another document to fulfill >that requirement. And that makes this document somewhat useless and >pointless. > >Mike --=====================_211510065==.ALT Content-Type: text/html; charset="us-ascii" At 08:29 PM 3/25/2006, Eastlake III Donald-LDE008 wrote:
Hi Mike,

I'd like to know exactly what you mean. What assumptions do you have to
make?

Let's just talk about DNSKEY to be specific. Seems to me that RFC 4034
does a reasonable job of defining the wire encoding of DNSKEY except for
the interior of the part of the RDATA which it calls "Public Key" in
Section 2.1 of RFC 4034. Do you think the problem is that draft 2536bis
is ambiguous in defining the wire encoding of DSA keys? I can see how it
could be improved to be a little clearer in that regard. Or is that you
alternatively or additionally think that, even in the face of a
hypothetical perfect description in 2536bis of the octet wire encoding
sequence for a DSA key in the DNS, that RFC 4034 isn't clear enough
about where to stuff the data? Or what?

How does "
the structure of the
   relevant part of the RDATA part of the RR being used is the
fields
   listed below in the order given." map to "put this
in the PublicKey field of the DNSKEY RR"?  E.g. why (without
going back and reading 2536) should I assume that "relevant part of
the RDATA part" maps to the PublicKey field?
Also, "which algorithm ID do you use for this in the DNSKEY?  2536 explictly said it was ID 3 - but that's for 'DSA/SHA1' and that's obviously a signature algorithm not a key representation so WTF?"  E.g. if the DNSKEY is now used for DSA/SHA256 does the algorithm ID change?  Can I use the same DNSKEY for both DSA/SHA1 and DSA/SHA256?  (Ditto for RSA....)

A document which obsoletes another document should be able to be read on its own and have a complete meaning. This one can't be. This document needs to specify:

1) The algorithm ids specific to this representation both for DNSKEY and for RRSIG.

2) The actual and specific placement of the fields described here within the DNSKEY and RRSIG.

Enjoy.  Mike




2536bis specifies the order of the subfields within the "Public Key"
data for a DSA key and explicitly says the octets within a subfield are
stored in 'stored in "big-endian" network order'...

Thanks,
Donald

-----Original Message-----
From: Mike StJohns [ mailto:Mike.StJohns@nominum.com]
Sent: Saturday, March 25, 2006 8:01 PM
To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org
Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

At 06:46 PM 3/25/2006, Eastlake III Donald-LDE008 wrote:
>@@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG RRs (if
>that's what you mean by "connective tissue") but not the algorithm
>dependent data format. At this point, the DNS DSA key format is usable
>in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support IPSEC). The
>DNS DSA signature format is usable in RRSIG and SIG (to support
SIG(0)).
>Things like the "algorithm number" are different in DNSKEY and
IPSECKEY.
>I believe it is contemplated that there might be additional application

>specific key RRs, like IPSECKEY, defined in the future.


The problem is that you'd actually have to specify the actual way you
fit this into DNSKEY and RRSIG to be useable.  This document is not
sufficient to do that without making some possibly ambiguous
assumptions.  Which means you'd need yet another document to fulfill
that requirement.  And that makes this document somewhat useless and
pointless.

Mike
--=====================_211510065==.ALT-- -- to unsubscribe send a message to namedroppers-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 Mar 25 23:44:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNN7P-0000Lw-Kh for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 23:44:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNN7K-0000l3-7N for dnsext-archive@lists.ietf.org; Sat, 25 Mar 2006 23:44:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNN29-0008NW-AT for namedroppers-data@psg.com; Sun, 26 Mar 2006 04:39:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNN28-0008NL-7k for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 04:39:20 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2Q4cd7o001245 for ; Sat, 25 Mar 2006 23:38:39 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA__aWAc; Sat, 25 Mar 06 23:38:36 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2Q4atqb020528; Sat, 25 Mar 2006 23:36:56 -0500 (EST) Date: Sat, 25 Mar 2006 23:39:04 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: Namedroppers cc: David Blacka Subject: Re: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: Message-ID: References: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Last week, David and I talked more about opt-in section 4.2.1, which results from the delegation-only requirement this WG imposed on opt-in some time ago. This section requires, with a 2119 MUST, resolvers to "generate a validation failure when encountering records other than NS or glue that fall within an Opt-In NSEC record's span." We concur (I think) that neither this document nor DNSSECbis specifically tell a resolver how to do that, and, in particular, that it may need to explicitly look for a delegation if it receives unsigned records from within an opt-in span (which might happen if a single server is authoritative for both the opt-in parent and an unsigned child). Absent clear instructions, I fear that resolvers will get this detail wrong, potentially leading to spurious validation failures. Rather than going into that detail, I propose that we choose the path of simplicity and eliminate the delegation-only requirement. -- Sam On Wed, 22 Mar 2006, Sam Weiler wrote: >>> A protocol correctness question, from section 4.2.1: >>> >>> As stated in the "Server Considerations" section above, this >>> specification restricts the namespace covered by Opt-In tagged NSEC >>> records to insecure delegations only. Thus, resolvers MUST generate >>> a validation failure when encountering records other than NS or glue >>> that fall within an Opt-In NSEC record's span. >>> >>> If a server is authoritative for both an opt-in signed parent and an >>> unsigned child, what happens when the resolver receives an A record from >>> the child zone? The resolver doesn't see the NS record ... >> >> This isn't a special case. This happens in non-opt-in DNSSEC. What do you >> think happens there? > > My fear is that we get a Failure validation result, for want of having > clearly told resolvers how to distinguish between the case I described and > the case where is there isn't a delegation (and the A record is in the parent > zone). > > Would you walk through the process (whether from rfc4035 or 4.2 of this > document) for this example? > > Query: child.example A (sent to server authoritative for both > example and child.example) > Answer: that A record (and nothing else) > > Does the resolution process then go on to prove that there's a delegation to > child.example? If not, how do we separate this case from the one where this > is no delegation to child.example (which, per the quoted text, MUST generate > a validation failure)? -- to unsubscribe send a message to namedroppers-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 Mar 26 05:46:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNSl6-00012I-Dz for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 05:46:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNSl5-0002F7-3m for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 05:46:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNShW-0006oP-Of for namedroppers-data@psg.com; Sun, 26 Mar 2006 10:42:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNShV-0006oB-G7 for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 10:42:25 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 607C333C1C; Sun, 26 Mar 2006 11:42:23 +0100 (BST) Message-ID: <44266F98.9030005@algroup.co.uk> Date: Sun, 26 Mar 2006 11:40:24 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Sam Weiler , namedroppers@ops.ietf.org Subject: Re: NSEC3 Issue 9: Potential DoS on Resolvers References: <43FEF8C5.9080508@algroup.co.uk> <441BDE15.20808@algroup.co.uk> <441F9CFC.8020306@algroup.co.uk> <44207970.5000808@algroup.co.uk> <6895E8C8-B2C4-4D71-AD75-E9225445794E@NLnetLabs.nl> In-Reply-To: <6895E8C8-B2C4-4D71-AD75-E9225445794E@NLnetLabs.nl> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Olaf M. Kolkman wrote: > > On Mar 21, 2006, at 4:08 PM, Ben Laurie wrote: > >> You already answered it - because then some NSEC3-aware resolvers would >> be unable to validate answers from the zone. >> >> Your statement that a zone choosing to use NSEC3 at all would mean that >> some resolvers couldn't validate the zone doesn't strike me as >> motivation for increasing the number of resolvers that can't. >> >> As we all know, some zones _cannot_ deploy NSEC. I see no point in >> beating that dead horse further. > > > > > During the WG meeting you mentioned that the number of iterations > (section 8.3) could be increased sometime in the future. > > So what happens when at some time X the number of iterations 'allowed' > will be increased. There is no (specified) way for a NSEC3 aware > resolver to become aware of the increased allowed number of iterations. > A zone owner will not know if and/or when the set of resolvers has been > updated to comply with the new number of iterations. Which would mean > that in practice a zone owner will not be able to upgrade. > > I therefore think that you will not be able to change the number of > iterations field. > > You could say that the number of iterations can be increased when you > introduce new key or hash algorithms but that probably only work for > algorithms that MUST be supported. > > While skimming the ID again I did not find any text suggesting that the > number of iterations may or should be modified in the future. I propose > not to add such text and live with the fact that you will not be able to > modify the costs once you set the numbers in 8.3. You may want to add > text to the security section expanding on that. That sounds fine to me. Obviously when we're all in our graves someone can change our mind for us by writing a new RFC. One thing that did occur to me, though, is that we might want to relate maximum number of iterations to verification cost rather than signing cost. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 26 08:12:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNV2V-0002hP-70 for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 08:12:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNV2S-00083B-QR for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 08:12:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNUzF-000Egm-PC for namedroppers-data@psg.com; Sun, 26 Mar 2006 13:08:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNUzE-000EgZ-Gr for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 13:08:53 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7F1A133C1C; Sun, 26 Mar 2006 14:08:50 +0100 (BST) Message-ID: <442691EB.6000300@algroup.co.uk> Date: Sun, 26 Mar 2006 14:06:51 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Eastlake III Donald-LDE008 CC: namedroppers@ops.ietf.org Subject: Re: DH/DSA I-Ds References: <3870C46029D1F945B1472F170D2D9790BB221B@de01exm64.ds.mot.com> In-Reply-To: <3870C46029D1F945B1472F170D2D9790BB221B@de01exm64.ds.mot.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Eastlake III Donald-LDE008 wrote: > Hi, > > See below at @@@ > > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Ben Laurie > Sent: Wednesday, March 22, 2006 5:25 AM > To: namedroppers@ops.ietf.org > Subject: DH/DSA I-Ds > > Here's my review of the DSA/DH I-Ds. You may regret asking for > volunteers in my presence :-) > > RFC 2536bis - DSA keys > > 1. When referring to FIPS 186-2 I believe it is called DSS Digital > Signature Standard), not DSA. > > @@@ Indeed, the FIPS document is DSS. But this draft is intended to only > cover DSA = Digital Signature Algorithm keys and signatures. The new DSS > document covers RSA and ECDSA signatures also. The right term needs to > be used for the particular context. OK. > 2. I object to Schneier as a reference when Handbook of Applied > Cryptography is a) better and b) freely available on the web. > > @@@ I assume you are referring to Menezes. I've got no problem with > adding that as a reference but I'm more reluctant to remove an existing > reference. What's the URL for Menezes on-line? http://www.cacr.math.uwaterloo.ca/hac/ > 3. This assumes a 160 bit hash. NIST has just approved all the other > SHAs as appropriate hashes for DSS, so it seems silly not to revise the > I-D to allow for that, especially since we should generally remove hard > dependencies on SHA-1. > > 4. The prime is limited to 2560 bits, which may be small by modern > standards. > > @@@ Responding to both of the above comments, yes, I understand that > FIPS 186-3 has just been approved. I'll look it over and see what > changes would be needed. I do think that this document should cover the > new extended DSA. In general, limitations on size of primes and the like > ought to appear where the specific RR is defined that makes use of this > DSA key/signature format. However, where that has not been done, as for > example in RFC 4034, the limitations for pre-existing RR uses of the DSA > format probably have to be in this document. > > @@@ You suggest raising the 2560 bit limit, I assume for DNSKEY. Would > that break code? If it were to be changed, what new value would you > suggest? I'm inclined to say that, to minimize change, the size limit > should not change for DNSKEY and KEY. You will have to change the limit to fully support 186-3. The largest prime used is 3072 bits. Also, there's less flexibility in size. The allowed parameters can be found in section 4.2 of 186-3 and are: L = 1024, N = 160 L = 2048, N = 224 L = 2048, N = 256 L = 3072, N = 256 where N is the hash size (and hence the size of Q) and L is the size of P. I would be inclined to provide a 2 for each of L and N (unless you want to deduce N from the hash). You'll also have to add a field to select the hash, of course. I'm not sure in what sense you are asking about breaking code - I would be surprised if the underlying DSA implementation would break as a result of using larger primes, but since the wire format has to change, code depending on that will obviously break. Also, current implementations are quite likely to have N hardwired as 160. > RFC 2539bis - DH > > 3. 768 bit primes are _weak_ and should be killed. > > @@@ What minimum size would you suggest? I'm inclined to leave this > alone for existing RRs and to say that any future RRs that are defined > to use this format need to also specify the limitations on use. 1024. > 4. Perhaps larger "standard" primes should be included (the biggest is > currently 1536 bits). > > @@@ Yes, the additional ones references in my response to point 2 above > are larger and should be included. OK. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 26 15:26:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNboy-0001Hr-BX for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 15:26:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNbow-0007OP-Te for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 15:26:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNbkz-000F0D-Me for namedroppers-data@psg.com; Sun, 26 Mar 2006 20:22:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNbky-000Eza-Oi for namedroppers@ops.ietf.org; Sun, 26 Mar 2006 20:22:36 +0000 Received: from [192.168.1.13] ([::ffff:71.246.231.8]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Sun, 26 Mar 2006 15:22:28 -0500 id 002C415A.4426F804.000034E3 In-Reply-To: References: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: WGLC dnssec-experiments and dnssec-opt-in Date: Sun, 26 Mar 2006 15:22:22 -0500 To: Sam Weiler X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On Mar 25, 2006, at 11:39 PM, Sam Weiler wrote: > Last week, David and I talked more about opt-in section 4.2.1, > which results from the delegation-only requirement this WG imposed > on opt-in some time ago. > > This section requires, with a 2119 MUST, resolvers to "generate a > validation failure when encountering records other than NS or glue > that fall within an Opt-In NSEC record's span." We concur (I > think) that neither this document nor DNSSECbis specifically tell a > resolver how to do that, and, in particular, that it may need to > explicitly look for a delegation if it receives unsigned records > from within an opt-in span (which might happen if a single server > is authoritative for both the opt-in parent and an unsigned > child). Absent clear instructions, I fear that resolvers will get > this detail wrong, potentially leading to spurious validation > failures. Sam is specifically arguing that a validator will have difficulty telling the difference between a non-delegation covered by an opt-in span and a response coming from an insecure subzone (with a delegation covered by an opt-in span) on the same authoritative server. Essentially, getting confused when the validator doesn't directly see the delegation. > Rather than going into that detail, I propose that we choose the > path of simplicity and eliminate the delegation-only requirement. I'm not sure that is the simplest path. A seemingly great number of questions about how opt-in works are essentially answered with "that can't happen because it is delegation-only". Like, for instance, can you opt out the zone apex (no) ? can you opt-out a wildcard (no) ? So we would have to replace "delegations only" with a possible more complex set of rules. Instead, I suggest that I add a sentence or two describing that, in some cases, the validator may not see the insecure delegation, and thus must probe to discover the delegation in such a way that it is clear that it is an insecure delegation. I.e., by issuing a query for possible-delegation/IN/NS to the parent. Or, alternately, just warning future implementors that this case exists and thus to handle it as they see fit. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Mar 26 23:24:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNjHP-0006Xj-Gr for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 23:24:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNjHL-0000U4-3y for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 23:24:35 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNjCB-000Fsw-Cx for namedroppers-data@psg.com; Mon, 27 Mar 2006 04:19:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.154.244] (helo=mail14.mdx.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNjC9-000Fsl-T9 for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 04:19:09 +0000 Received: by mail14.mdx.safepages.com (Postfix, from userid 1012) id C37D11ECDC3; Mon, 27 Mar 2006 04:19:09 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.104]) by mail14.mdx.safepages.com (Postfix) with ESMTP id 91FDC1ECCA7; Mon, 27 Mar 2006 04:19:08 +0000 (GMT) Message-ID: <442770A0.7040803@connotech.com> Date: Sun, 26 Mar 2006 23:57:04 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , Namedroppers Subject: Usefulness of ECC-DSA algorithm for DNSSEC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Dear Ólafur: In a different forum, you asked for guidance on using ECC-DSA for DNSSEC. See http://www1.ietf.org/mail-archive/web/cfrg/current/msg01170.html The single benefit from the ECC-DSA would be smaller signature size than with RSA. However, the RSA-SHA1 RRSIGs would still be mandatory in DNSSEC replies in any event, since RSA-SHA1 is mandatory-to-implement. Thus, the addition of small signature with the ECC-DSA algorithm can only ENLARGE responses from security-aware nameservers. Please correct me if I'm mis-reading the DNSSEC spec, e.g. if an island of security may exist without support for RSA-SHA1 and still be compliant with RFC4033/4/5. So, either there is no benefit in adding well-defined ECC-DSA to the mandatory-to-implement and you should abandon the idea, or you are investigating a move from RSA-SHA1 to ECC-DSA-SHA2 (instead of RSA-SHA2). Thanks in advance for your clarifications. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Sun Mar 26 23:36:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNjTO-0005c5-PP for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 23:36:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNjTN-0000zo-B8 for dnsext-archive@lists.ietf.org; Sun, 26 Mar 2006 23:36:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNjRK-000Gfd-QB for namedroppers-data@psg.com; Mon, 27 Mar 2006 04:34:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNjRK-000GfS-77 for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 04:34:50 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 49C5856838; Sun, 26 Mar 2006 20:34:49 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060326233411.03f2d910@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 26 Mar 2006 23:36:18 -0500 To: Thierry Moreau ,=?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= , Namedroppers From: Mike StJohns Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC In-Reply-To: <442770A0.7040803@connotech.com> References: <442770A0.7040803@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 At 11:57 PM 3/26/2006, Thierry Moreau wrote: >However, the RSA-SHA1 RRSIGs would still be mandatory in DNSSEC >replies in any event, since RSA-SHA1 is mandatory-to-implement. No. Mandatory to implement just means the resolvers and the signers have to understand the signatures. The actual zone data can be signed by some, all or none of the algorithms and keys that exists within the zone. So, having a zone signed with ECC vs RSA (not ECC *and* RSA) would actually reduce the size of replies. -- to unsubscribe send a message to namedroppers-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 Mar 27 00:46:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNkYH-0000Kg-H7 for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 00:46:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNkYG-0003WO-Q5 for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 00:46:05 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNkV5-000K5e-J0 for namedroppers-data@psg.com; Mon, 27 Mar 2006 05:42:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [144.189.100.103] (helo=motgate3.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNkV4-000K57-D3 for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 05:42:46 +0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k2R63tWg024493 for ; Sun, 26 Mar 2006 23:03:55 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k2R5wEZw025976 for ; Sun, 26 Mar 2006 23:58:14 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Date: Mon, 27 Mar 2006 00:42:42 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790BB22B6@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Thread-Index: AcZQeCegUnkWEVh3RpmDNQA6afqYkQAbRPCA From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Hi Mike, See below at @@@=20 ________________________________ From: Mike StJohns [mailto:Mike.StJohns@nominum.com]=20 Sent: Saturday, March 25, 2006 8:55 PM To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review At 08:29 PM 3/25/2006, Eastlake III Donald-LDE008 wrote: Hi Mike, =09 I'd like to know exactly what you mean. What assumptions do you have to make? =09 Let's just talk about DNSKEY to be specific. Seems to me that RFC 4034 does a reasonable job of defining the wire encoding of DNSKEY except for the interior of the part of the RDATA which it calls "Public Key" in Section 2.1 of RFC 4034. Do you think the problem is that draft 2536bis is ambiguous in defining the wire encoding of DSA keys? I can see how it could be improved to be a little clearer in that regard. Or is that you alternatively or additionally think that, even in the face of a hypothetical perfect description in 2536bis of the octet wire encoding sequence for a DSA key in the DNS, that RFC 4034 isn't clear enough about where to stuff the data? Or what? How does " the structure of the relevant part of the RDATA part of the RR being used is the fields listed below in the order given." map to "put this in the PublicKey field of the DNSKEY RR"? E.g. why (without going back and reading 2536) should I assume that "relevant part of the RDATA part" maps to the PublicKey field? @@@ Those words clearly don't map as you state, but so what? @@@ There are currently two kinds of documents relevant to storing keys/signatures in DNS RRs: what might be called "algorithm RFCs" and what might be called "RR RFCs". This draft is for an algorithm RFC. If you are only interested in the standard DNS format for DSA keys and signature without reference to any particular RR, this is the document for you. I make the assumption, which seems reasonable to me, that if you care about some particular RR, you would also read the relevant RR RFC. That RR RFC would normally be the place you would find out how, for that RR, to indicate which algorithm is in use and where to put the DNS encoding of the key/signature inside that RR. @@@ Someone worried about using DSA keys with DNSKEY should be familiar with RFC 4034, which is the most recent documentation for DNSKEY. RFC 4034 is the RR RFC which tells you how to indicate that you are using the DSA algorithm in a DNSKEY RR and where in the DNSKEY RR to put the DNS encoded DSA key. Similarly, someone worried about using DSA keys with IPSECKEY should be familiar with RFC 4025 which is the most recent documentation for the IPSECKEY RR. RFC 4025 is the RR RFC which tells you how to indicate that you are using the DSA algorithm in an IPSECKEY RR and where in the IPSECKEY RR to put the DNS encoded DSA key. Etc. @@@ It seems clear to me that this division between algorithm RFCs and RR RFCs should be described in both the 2536bis and 2539bis drafts, so I'd be happy to add text doing. And I'm not completely doctrinaire about this. It actually wouldn't hurt that much to redundantly put some stuff in this draft about how to indicate the DSA algorithm and where to insert the DNS encoding of the DSA key or signature in the RDATA for DNSKEY, or other existing RRs that can use DSA. The main disadvantage would be that, should this information change in the future, you would have to remember to indicate that the hypothetical future change RFC should be listed as changing both all applicable algorithm RFCs as well as changing its RR RFC. @@@ I think that, slowly over the years, DNS encoding for additional algorithms will be specified and additional application specific RRs, like IPSECKEY, will be specified. The situation your really, really want to avoid would be any *requirement* that algorithm RFCs include such RR algorithm indication information (e.g., "algorithm numbers") and RDATA placement information. The reason is that, if there was such a requirement, then the next time someone specifies a new application specific RR, they would have to spin new versions of every applicable algorithm RFC just to put this information in them. @@@ Sorry to be so long winded but, to summarize, people interested in using algorithm X with RR Y can reasonably be expected to read the algorithm RFC on algorithm X and the RR RFC on RR Y. Certainly, they need to know how, in RR Y, to indicate the use of algorithm X, and where in the RDATA of RR Y to put the encoded key/signature for algorithm X. As long as they can find that information in either the algorithm RFC or the RR RFC, things should be fine. But, given a choice, the RR RFC is a better place for this information for two reasons: this way the algorithm RFCs doesn't get gooped up with different information about a slowly growing number of different RRs and, more important, every time a new application specific RR is defined, you don't have to spin new versions of all applicable algorithms RFCs. Also, "which algorithm ID do you use for this in the DNSKEY? 2536 explicitly said it was ID 3 - but that's for 'DSA/SHA1' and that's obviously a signature algorithm not a key representation so WTF?" E.g. if the DNSKEY is now used for DSA/SHA256 does the algorithm ID change? Can I use the same DNSKEY for both DSA/SHA1 and DSA/SHA256? (Ditto for RSA....) @@@ If you want to know algorithm ID to use for DSA in DNSKEY, you should look at the RR RFC for DNSKEY, RFC 4034. Just as if you want to know the algorithm ID for DSA in IPSECKEY, which is different, you should look at the RR RFC for IPSECKEY, RFC 4025.=20 @@@ At the time RFC 2536 was published, it was thought that there would probably only ever be one RR that would contain DSA keys so there was no harm in giving information like algorithm numbers redundantly in both the RR RFC and the algorithm RFC. At the time RFC 4034 were published, DSA always used SHA-1 for its signatures and the string "DSA/SHA1" was just a redundant way of writing "DSA". By the way, the string "DSA/SHA1" you are complaining about appears, as far as I can see, no where in this draft or RFC 2536. @@@ As to the recently approved extensions of DSA for longer hashes, etc., those are not covered by the draft under review and whether they should be the same algorithm or not has not, as far as I can tell, been decided yet by the working group. I have no idea what you mean by "Can I use the same DNSKEY for both DSA/SHA1 and DSA/SHA256?". You can only include one key and only specify one algorithm id in any particular instance of the DNSKEY RR. And what does RSA have to do with this draft? A document which obsoletes another document should be able to be read on its own and have a complete meaning. This one can't be. This document needs to specify: @@@ I don't really understand what "read on its own and have a complete meaning" connotes to you but I certainly think this draft completely specified the DNS encoding of FIS 186-2 style DSA keys and signatures into precise octet sequences. And that's all it needs to do. @@@ Perhaps you meant to say that a document which obsoletes another document has to cover exactly the same information as the document it obsoletes. But I don't agree with that either. That would imply that the IETF could never, when revising a set of RFCs, change the boundaries as to what information is in which RFC or RFCs. It probably shouldn't do so without a reason but in this case there is a reason. As explained above, it is cleaner if the normal place for RR specific algorithm identifiers and RR specific algorithm data placement is with that RR RFC rather than having such data for all relevant RRs in all relevant algorithm RFCs. 1) The algorithm ids specific to this representation both for DNSKEY and for RRSIG. @@@ While it wouldn't hurt that much to include that data in this draft, there is absolutely no need to do so and some minor negative effects form doing so, as explained at length above. 2) The actual and specific placement of the fields described here within the DNSKEY and RRSIG.=20 @@@ While it wouldn't hurt that much to include that data in this draft, there is absolutely no need to do so and some minor negative effects form doing so, as explained at length above. Enjoy. Mike @@@ Donald 2536bis specifies the order of the subfields within the "Public Key" data for a DSA key and explicitly says the octets within a subfield are stored in 'stored in "big-endian" network order'... =09 Thanks, Donald =09 -----Original Message----- From: Mike StJohns [ mailto:Mike.StJohns@nominum.com ]=20 Sent: Saturday, March 25, 2006 8:01 PM To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review =09 At 06:46 PM 3/25/2006, Eastlake III Donald-LDE008 wrote: >@@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG RRs (if=20 >that's what you mean by "connective tissue") but not the algorithm=20 >dependent data format. At this point, the DNS DSA key format is usable=20 >in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support IPSEC). The=20 >DNS DSA signature format is usable in RRSIG and SIG (to support SIG(0)). >Things like the "algorithm number" are different in DNSKEY and IPSECKEY. >I believe it is contemplated that there might be additional application =09 >specific key RRs, like IPSECKEY, defined in the future. =09 =09 The problem is that you'd actually have to specify the actual way you fit this into DNSKEY and RRSIG to be useable. This document is not sufficient to do that without making some possibly ambiguous assumptions. Which means you'd need yet another document to fulfill that requirement. And that makes this document somewhat useless and pointless. =09 Mike -- to unsubscribe send a message to namedroppers-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 Mar 27 09:20:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNsaZ-0006ZA-Dh for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 09:20:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNsaV-0000NB-GL for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 09:20:59 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNsVI-0000E1-5T for namedroppers-data@psg.com; Mon, 27 Mar 2006 14:15:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.133.33] (helo=mail10.mdx.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNsVG-0000Dj-QU for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 14:15:30 +0000 Received: by mail10.mdx.safepages.com (Postfix, from userid 1012) id EACAC207FB; Mon, 27 Mar 2006 14:15:33 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.29]) by mail10.mdx.safepages.com (Postfix) with ESMTP id 0BC48206E3; Mon, 27 Mar 2006 14:14:49 +0000 (GMT) Message-ID: <4427FC37.7020001@connotech.com> Date: Mon, 27 Mar 2006 09:52:39 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike StJohns CC: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , Namedroppers Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC References: <442770A0.7040803@connotech.com> <7.0.1.0.2.20060326233411.03f2d910@nominum.com> In-Reply-To: <7.0.1.0.2.20060326233411.03f2d910@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Mike, thanks for this reply. I agree, but only in theory without much practical impact: the freedom to drop RSA-SHA1 seems restricted to the islands of security (including the root), by implication of RFC4035 section 2. Relevant RFC4035 citations: 2.2. Including RRSIG RRs in a Zone [...] There MUST be an RRSIG for each [authoritative] RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any). 2.4. Including DS RRs in a Zone [...] All DS RRsets in a zone MUST be signed, [...] A DS RR SHOULD point to a DNSKEY RR that is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed by the corresponding private key. DS RRs that fail to meet these conditions are not useful for validation, but because the DS RR and its corresponding DNSKEY RR are in different zones, and because the DNS is only loosely consistent, temporary mismatches can occur. [...] [end of citation] In other words, a DNSSEC signature algorithm present at an island of security is recursively mandated (except for temporary mismatches in DNS consistency) to secure child zones. Hence my original question to Ólafur and others who *might* be playing with the idea of droping RSA-SHA1 at the DNS root. Again, thanks in advance for your clarifications. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com Mike StJohns wrote: > At 11:57 PM 3/26/2006, Thierry Moreau wrote: > >> However, the RSA-SHA1 RRSIGs would still be mandatory in DNSSEC >> replies in any event, since RSA-SHA1 is mandatory-to-implement. > > > No. Mandatory to implement just means the resolvers and the signers > have to understand the signatures. The actual zone data can be signed > by some, all or none of the algorithms and keys that exists within the > zone. > > So, having a zone signed with ECC vs RSA (not ECC *and* RSA) would > actually reduce the size of replies. -- to unsubscribe send a message to namedroppers-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 Mar 27 09:49:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNt2I-0004IU-8b for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 09:49:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNt2G-0001F7-W5 for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 09:49:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNszp-0002I5-Hp for namedroppers-data@psg.com; Mon, 27 Mar 2006 14:47:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNszg-0002Hm-9K for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 14:46:56 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2REkhrb078568; Mon, 27 Mar 2006 16:46:44 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <4427FC37.7020001@connotech.com> References: <442770A0.7040803@connotech.com> <7.0.1.0.2.20060326233411.03f2d910@nominum.com> <4427FC37.7020001@connotech.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-20--192642210" Message-Id: <7DD6EE63-431E-44AB-A5A6-9CFF767D32B2@NLnetLabs.nl> Cc: Mike StJohns , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= , Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC Date: Mon, 27 Mar 2006 16:46:38 +0200 To: Thierry Moreau X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-20--192642210 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > In other words, a DNSSEC signature algorithm present at an island > of security is recursively mandated (except for temporary > mismatches in DNS consistency) to secure child zones. > No that is a wrong interpretation. The catch is in the "by each algorithm appearing in the DS RRset " part. So the algorithm field in the DS can point to "new" algorithms and you are not tied to one single algorithm recursively down the tree. As an example consider this: @origin example. example DNSKEY algo=RSASHA1 KSK id=1 example DNSKEY algo=RSASHA1 ZSK id=2 example RRSIG id=2 foo.example. DS algo=CRYPTSAM hash=deadbeef foo.example. RRSIG id=1 @originin foo.example foo.example DNSKEY algo=CRYPTSAM KSK id=5 foo.example DNSKEY algo=CRYPTSAM ZSK id=6 foo.example RRSIG id=6 etc etc --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-20--192642210 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEJ/rTtN/ca3YJIocRAq5dAJ9JCvC1jQqnEEVW8rd2yL7vf0d9FACgpsx0 lMotZX/+1dkR+BBkXGF6b74= =jbxH -----END PGP SIGNATURE----- --Apple-Mail-20--192642210-- -- to unsubscribe send a message to namedroppers-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 Mar 27 10:01:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtE4-0002ge-TK for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 10:01:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtE4-0001kB-L2 for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 10:01:48 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNtC7-0003D1-Vj for namedroppers-data@psg.com; Mon, 27 Mar 2006 14:59:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNtC7-0003Ag-3G for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 14:59:47 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2RExHeA078767; Mon, 27 Mar 2006 16:59:18 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-22--191884136" Message-Id: <31BFB721-5252-453B-ACE8-405D5D925966@NLnetLabs.nl> Cc: Sam Weiler , Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: WGLC dnssec-experiments and dnssec-opt-in Date: Mon, 27 Mar 2006 16:59:16 +0200 To: David Blacka X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-22--191884136 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 26, 2006, at 10:22 PM, David Blacka wrote: > >> Rather than going into that detail, I propose that we choose the >> path of simplicity and eliminate the delegation-only requirement. > > I'm not sure that is the simplest path. A seemingly great number > of questions about how opt-in works are essentially answered with > "that can't happen because it is delegation-only". Like, for > instance, can you opt out the zone apex (no) ? can you opt-out a > wildcard (no) ? So we would have to replace "delegations only" > with a possible more complex set of rules. > Besides, the delegation only requirement the result of endless and heated debates about the change in the security model that we had when opt-in first came to the table. I prefer we do not try to relive that era. > I.e., by issuing a query for possible-delegation/IN/NS to the parent. Would querying for a DS at that parent work? I would think that that would be the regular fall back when trying to build a chain of trust? --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-22--191884136 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEJ/3EtN/ca3YJIocRAvrVAKDYL7eWPjFqfhMK3oOllzFSW2MVPQCeK1sF QzTB74zLOIBHd9QHyTspUXs= =/z4v -----END PGP SIGNATURE----- --Apple-Mail-22--191884136-- -- to unsubscribe send a message to namedroppers-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 Mar 27 10:10:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtMB-0006Yu-7T for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 10:10:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtM9-0002Ep-N1 for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 10:10:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNtHJ-0003j6-V2 for namedroppers-data@psg.com; Mon, 27 Mar 2006 15:05:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNtHI-0003ir-K6 for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 15:05:09 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2RF4tpW069269; Mon, 27 Mar 2006 10:04:56 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060327093813.03d898e8@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Mar 2006 10:04:29 -0500 To: Thierry Moreau , Mike StJohns From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC Cc: Namedroppers In-Reply-To: <4427FC37.7020001@connotech.com> References: <442770A0.7040803@connotech.com> <7.0.1.0.2.20060326233411.03f2d910@nominum.com> <4427FC37.7020001@connotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b As some of you are aware of I asked an IRTF group on cryptograph CFRG some questions on use of ECC in DNSSEC. This is done to identify any potential research issues related to possible use of ECC in DNSSEC. Any output from CFRG (or other forums) will be fed into DNSEXT before any standards actions. The two reason I'm exploring ECC are the size issue, and to have an better answer next time someone ask why are you not using ECC. The DNSEXT working group has been considering for some time to add support for ECC. Any deployment of ECC will be gradual, there are no plans to retire RSA. It is possible that ECC might replace DSA as mandatory to implement. Currently ECC is a minefield of IPR claims, FUD etc. This requires careful consideration of ECC and different curves before the DNSEXT working group can proceed. Any zone can sign with any supported algorithm, using a algorithm that is not as widely supported as RSA has the risk that a zone appears unsigned to some resolvers. For background on this issue look at RFC3090, issues locally and globally secure. To answer your quotes from below, following is=20 perfectly valid from the protocol point. . signed by RSA/SHA256 COM signed by RSA/SHA1 EXAMPLE.com signed by DSA child.example.com signed by RSA/MD5 grandchild.example.com signed by DSA But for a validator the trust chain is broken when it is faced with the first algorithm it does not understand/support.=20 As some Validator's have removed support for RSA/MD5 that zone risks becoming=20 viewed as insecure, and its children are treated insecure because of the parent. Olafur At 09:52 27/03/2006, Thierry Moreau wrote: >Mike, thanks for this reply. > >I agree, but only in theory without much=20 >practical impact: the freedom to drop RSA-SHA1=20 >seems restricted to the islands of security=20 >(including the root), by implication of RFC4035 section 2. > >Relevant RFC4035 citations: > >2.2. Including RRSIG RRs in a Zone > >[...] There MUST be an RRSIG for each=20 >[authoritative] RRset using at least one DNSKEY=20 >of each algorithm in the zone apex DNSKEY=20 >RRset. The apex DNSKEY RRset itself MUST be=20 >signed by each algorithm appearing in the DS=20 >RRset located at the delegating parent (if any). > >2.4. Including DS RRs in a Zone > >[...] All DS RRsets in a zone MUST be signed, [...] > >A DS RR SHOULD point to a DNSKEY RR that is=20 >present in the child's apex DNSKEY RRset, and=20 >the child's apex DNSKEY RRset SHOULD be signed=20 >by the corresponding private key. DS RRs that=20 >fail to meet these conditions are not useful for=20 >validation, but because the DS RR and its=20 >corresponding DNSKEY RR are in different zones,=20 >and because the DNS is only loosely consistent,=20 >temporary mismatches can occur. [...] > >[end of citation] > >In other words, a DNSSEC signature algorithm=20 >present at an island of security is recursively=20 >mandated (except for temporary mismatches in DNS=20 >consistency) to secure child zones. > >Hence my original question to =D3lafur and others=20 >who *might* be playing with the idea of droping RSA-SHA1 at the DNS root. > >Again, thanks in advance for your clarifications. > >Regards, > >-- > >- Thierry Moreau > >CONNOTECH Experts-conseils inc. >9130 Place de Montgolfier >Montreal, Qc >Canada H2M 2A1 > >Tel.: (514)385-5691 >Fax: (514)385-5900 > >web site: http://www.connotech.com >e-mail: thierry.moreau@connotech.com > > >Mike StJohns wrote: >>At 11:57 PM 3/26/2006, Thierry Moreau wrote: >> >>>However, the RSA-SHA1 RRSIGs would still be=20 >>>mandatory in DNSSEC replies in any event,=20 >>>since RSA-SHA1 is mandatory-to-implement. >> >>No. Mandatory to implement just means the=20 >>resolvers and the signers have to understand=20 >>the signatures. The actual zone data can be=20 >>signed by some, all or none of the algorithms=20 >>and keys that exists within the zone. >>So, having a zone signed with ECC vs RSA (not=20 >>ECC *and* RSA) would actually reduce the size of replies. > -- to unsubscribe send a message to namedroppers-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 Mar 27 10:10:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtMM-0006aM-0J for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 10:10:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtMI-0002F9-QF for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 10:10:21 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNtJj-0003v0-Hm for namedroppers-data@psg.com; Mon, 27 Mar 2006 15:07:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.225] (helo=mail5.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNtJi-0003ui-O5 for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 15:07:38 +0000 Received: by mail5.sea.safepages.com (Postfix, from userid 1012) id 59FAD981E9; Mon, 27 Mar 2006 15:07:37 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.114]) by mail5.sea.safepages.com (Postfix) with ESMTP id D3F0398164; Mon, 27 Mar 2006 15:07:30 +0000 (GMT) Message-ID: <44280897.7040809@connotech.com> Date: Mon, 27 Mar 2006 10:45:27 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Olaf M. Kolkman" Cc: Mike StJohns , =?ISO-8859-1?Q?=D3lafur_Gu?= =?ISO-8859-1?Q?=F0mundsson?= , Namedroppers Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC References: <442770A0.7040803@connotech.com> <7.0.1.0.2.20060326233411.03f2d910@nominum.com> <4427FC37.7020001@connotech.com> <7DD6EE63-431E-44AB-A5A6-9CFF767D32B2@NLnetLabs.nl> In-Reply-To: <7DD6EE63-431E-44AB-A5A6-9CFF767D32B2@NLnetLabs.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Olaf M. Kolkman wrote: > > >> >> In other words, a DNSSEC signature algorithm present at an island of >> security is recursively mandated (except for temporary mismatches in >> DNS consistency) to secure child zones. >> > > No that is a wrong interpretation. The catch is in the "by each > algorithm appearing in the DS RRset " part. So the algorithm field in > the DS can point to "new" algorithms and you are not tied to one single > algorithm recursively down the tree. > Thanks for helping my education. I.e. I agree with you and I apologize for the temporary doubt perhaps caused by my posts to the group. This takes care of (what I thought was a radical) counter-argument to ECC-DSA as a signature algorithm in DNSSEC. Other issues about ECC (Elliptic Curve Cryptography) remain, but I'll leave other raise them if they se fit. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Mar 27 10:40:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtpD-0007IO-Dr for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 10:40:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtp9-0003lk-5W for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 10:40:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNtm4-00065e-3q for namedroppers-data@psg.com; Mon, 27 Mar 2006 15:36:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNtlw-000656-Eb for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 15:36:48 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id k2RFaUPD021849; Mon, 27 Mar 2006 07:36:30 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id k2RFaTtv021846; Mon, 27 Mar 2006 07:36:29 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 27 Mar 2006 07:36:29 -0800 (PST) From: "william(at)elan.net" To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: Thierry Moreau , Mike StJohns , Namedroppers Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC In-Reply-To: <6.2.5.6.2.20060327093813.03d898e8@ogud.com> Message-ID: References: <442770A0.7040803@connotech.com> <7.0.1.0.2.20060326233411.03f2d910@nominum.com> <4427FC37.7020001@connotech.com> <6.2.5.6.2.20060327093813.03d898e8@ogud.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1747400512-1057863467-1143473789=:24018" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1747400512-1057863467-1143473789=:24018 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 27 Mar 2006, Ólafur Guðmundsson /DNSEXT co-chair wrote: > To answer your quotes from below, following is perfectly valid from the > protocol point. > . signed by RSA/SHA256 > COM signed by RSA/SHA1 > EXAMPLE.com signed by DSA > child.example.com signed by RSA/MD5 > grandchild.example.com signed by DSA So if I wanted to express that there there are multiple types of signatures, that would or would not be possible, i.e. what if I have: EXAMPLE.com signed by RSA/SHA1 EXAMPLE.com signed by RSA/SHA256 > But for a validator the trust chain is broken when it is faced with the > first algorithm it does not understand/support. As some Validator's have > removed support for RSA/MD5 that zone risks becoming viewed as insecure, > and its children are treated insecure because of the parent. If multiple signatures are possible what needs to be done is to take care to separate into multiple RRs that can be requested independently. Not sure how to do it without breaking DNS other then by prefixes. -- William Leibzon Elan Networks william@elan.net ---1747400512-1057863467-1143473789=:24018-- -- to unsubscribe send a message to namedroppers-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 Mar 27 11:06:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuF4-0005PG-Th for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 11:06:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuF2-0004cc-Kf for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 11:06:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNuD4-00080c-Kp for namedroppers-data@psg.com; Mon, 27 Mar 2006 16:04:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNuD3-0007zo-8c for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 16:04:49 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7207933C1C; Mon, 27 Mar 2006 17:04:44 +0100 (BST) Message-ID: <44280CA7.9000005@algroup.co.uk> Date: Mon, 27 Mar 2006 17:02:47 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_co-chair?= CC: Thierry Moreau , Mike StJohns , Namedroppers Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC References: <442770A0.7040803@connotech.com> <7.0.1.0.2.20060326233411.03f2d910@nominum.com> <4427FC37.7020001@connotech.com> <6.2.5.6.2.20060327093813.03d898e8@ogud.com> In-Reply-To: <6.2.5.6.2.20060327093813.03d898e8@ogud.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Ólafur Guðmundsson /DNSEXT co-chair wrote: > The two reason I'm exploring ECC are the size issue, and to have an > better answer next time someone ask why are you not using ECC. If size is the problem, what's wrong with DSA? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 27 11:19:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuRF-0004Cp-MJ for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 11:19:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuRE-0005Kp-BI for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 11:19:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNuOI-0008uR-CZ for namedroppers-data@psg.com; Mon, 27 Mar 2006 16:16:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNuOH-0008u9-JL for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 16:16:25 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2RGF8qg069704; Mon, 27 Mar 2006 11:15:09 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060327111357.036dd998@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 27 Mar 2006 11:14:44 -0500 To: Ben Laurie , =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Usefulness of ECC-DSA algorithm for DNSSEC Cc: Thierry Moreau , Mike StJohns , Namedroppers In-Reply-To: <44280CA7.9000005@algroup.co.uk> References: <442770A0.7040803@connotech.com> <7.0.1.0.2.20060326233411.03f2d910@nominum.com> <4427FC37.7020001@connotech.com> <6.2.5.6.2.20060327093813.03d898e8@ogud.com> <44280CA7.9000005@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c At 11:02 27/03/2006, Ben Laurie wrote: >=D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: > > The two reason I'm exploring ECC are the size issue, and to have an > > better answer next time someone ask why are you not using ECC. > >If size is the problem, what's wrong with DSA? Key size. Olafur =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 Mon Mar 27 11:38:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNujK-0003HM-Jm for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 11:38:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNujK-00068r-4s for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 11:38:10 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNuhF-000AFZ-UM for namedroppers-data@psg.com; Mon, 27 Mar 2006 16:36:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNuhE-000AFA-0a for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 16:36:00 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 27 Mar 2006 11:35:53 -0500 id 002C404E.44281469.0000484C In-Reply-To: <31BFB721-5252-453B-ACE8-405D5D925966@NLnetLabs.nl> References: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> <31BFB721-5252-453B-ACE8-405D5D925966@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CA6BE82-CD0E-4A5A-A0DA-242FA247E8B6@verisignlabs.com> Cc: Sam Weiler , Namedroppers Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: WGLC dnssec-experiments and dnssec-opt-in Date: Mon, 27 Mar 2006 11:35:38 -0500 To: "Olaf M. Kolkman" X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 27, 2006, at 9:59 AM, Olaf M. Kolkman wrote: > > On Mar 26, 2006, at 10:22 PM, David Blacka wrote: > >> >>> Rather than going into that detail, I propose that we choose the >>> path of simplicity and eliminate the delegation-only requirement. >> >> I'm not sure that is the simplest path. A seemingly great number >> of questions about how opt-in works are essentially answered with >> "that can't happen because it is delegation-only". Like, for >> instance, can you opt out the zone apex (no) ? can you opt-out a >> wildcard (no) ? So we would have to replace "delegations only" >> with a possible more complex set of rules. >> > > Besides, the delegation only requirement the result of endless and > heated debates about the change in the security model that we had > when opt-in first came to the table. > > I prefer we do not try to relive that era. Exactly. > >> I.e., by issuing a query for possible-delegation/IN/NS to the parent. > > Would querying for a DS at that parent work? I would think that > that would be the regular fall back when trying to build a chain of > trust? Depends on what you mean by "work" :) I think you can certainly not generate false validation failures, but it would be difficult to enforce delegation-only. Essentially, in order to enforce the MUST in section 4.2.1 of opt-in, the validator MUST see the delegation in order to distinguish the case from an non-delegation-only opt-in zone. The DS query to the parent won't show that. Personally, I think that using the DS query is fine, as I don't see any actual security value from the validator actually enforcing delegation-only in this case. However, it doesn't match what the document says. > - -- David Blacka Sr. Engineer VeriSign Applied Research -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFEKBRpujy2e45Zk3URAncdAJ0Xn47JDZ6Ugz3LQd2pAAtK5A4aUQCfT2eb 5KTBlt+Ns8efWM5IRf/0AlE= =widg -----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 Mon Mar 27 11:54:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuyr-0005lB-Jz for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 11:54:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuyr-0006qs-2H for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 11:54:13 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNuwN-000Bau-2q for namedroppers-data@psg.com; Mon, 27 Mar 2006 16:51:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNuwM-000Bai-72 for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 16:51:38 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 1249956825; Mon, 27 Mar 2006 08:51:36 -0800 (PST) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060327112650.040ed9e0@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 27 Mar 2006 11:53:06 -0500 To: "Eastlake III Donald-LDE008" , From: Mike StJohns Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review In-Reply-To: <3870C46029D1F945B1472F170D2D9790BB22B6@de01exm64.ds.mot.co m> References: <3870C46029D1F945B1472F170D2D9790BB22B6@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 At 12:42 AM 3/27/2006, Eastlake III Donald-LDE008 wrote: >Hi Mike, > >See below at @@@ Trimmed all of the text - readers can see previous emails in this thread if they want more detail. Don - If I asked you a question of "how do I form a valid DNSKEY record containing a DSA key" I believe you would claim that this ID taken with 4034 provides sufficient detail to do so. I disagree. What I get from 4034 is the general format of a DNSKEY RR. What I get from this ID is the ordering of bits within a key blob of some form. What I am missing is what format identifier (e.g. Algorithm identifier) applies to this ID and where this key blob explicitly fits within the DNSKEY RR. If you're saying this isn't the job of this ID, then my question is "where is the ID that maps this ID into the DNSKEY RR"? I refer to the Algorithm Identifier field as a format id because that's really what it is. It describes the format of the PublicKey field and needs to reference a specific document to do so rather than the more generic algorithm name. To understand what I mean, let's consider the RSA algorithm. The RSA public key has two common representations - the Public/Exponent representation and the Chinese Remainder Theorem representation. Neither of the two RSA related Algorithm IDs in appendix a.1 of 4034 provide such representation. I would need to define a third (or more) RFC with this format and the assigned algorithm ID would refer specifically to that RFC. You're proposing obsoleting 2546 and 4034 points at 2546 as being the specific document which defines the format for Algorithm ID 3. You need a replacement document which links that algorithm ID (3) to a specific format. Its just a simple as that. This ID does not do that. Also, the more I think about it, the less I like the current system of assigning a single number for both the public key representation and an associated signature representation. We're about to re-do RSA with SHA1 into RSA with SHA256 and possibly other SHAs. I would expect similar actions for DSA. I suggest we split the algorithm assignments for key and signature as follows: Algorithm IDs for Key representations: 0 - Reserved 1 - RSA (modulus/exponent form) 2 - DH 3 - DSA (Fips 182-6) 4 - ECC - not yet defined 5 - RSA (modulus/exponent form - same as 1) Algorithm IDs for Signature representations 1 - RSA/MD5 - not recommended 2 - none (was DH) 3 - DSA with SHA1 4 - Reserved 5 - RSA/SHA1 6-127 reserved 127-255 - new signature algorithms. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 27 13:42:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwg3-0004UU-7O for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 13:42:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNwg2-0003JC-Rg for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 13:42:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNwcV-000JVd-EZ for namedroppers-data@psg.com; Mon, 27 Mar 2006 18:39:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNwcU-000JVP-EI for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 18:39:14 +0000 Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2RIcxJQ070545; Mon, 27 Mar 2006 13:38:59 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 27 Mar 2006 13:39:12 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: comments on dnssec-experiments Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Pendantic comments left in just to show that I did review the doc. (Count me in, doc.) Quoting from: http://ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-02.txt # DNSEXT D. Blacka # Internet-Draft Verisign, Inc. # Expires: August 27, 2006 February 23, 2006 # # DNSSEC Experiments # draft-ietf-dnsext-dnssec-experiments-02 # Abstract # In the long history of the development of the DNS security extensions # [1] (DNSSEC), a number of alternate methodologies and modifications # have been proposed and rejected for practical, rather than strictly # technical, reasons. There is a desire to be able to experiment with # these alternate methods in the public DNS. This document describes a # methodology for deploying alternate, non-backwards-compatible, DNSSEC # methodologies in an experimental fashion without disrupting the # deployment of standard DNSSEC. I think abstracts can be free of references (the "[1]" thing). # 1. Definitions and Terminology # The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", # "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this # document are to be interpreted as described in RFC 2119 [5]. Reference 5 ought to be normative then, right? # 4. Method # While this behavior isn't strictly mandatory (as marked by MUST), it # is unlikely that a validator would not implement the behavior, or, # more to the point, it will not violate this behavior in an unsafe way # (see below (Section 6).) Please restate this with fewer negatives. ;) "It is likely that a validator would implement" for example. Makes reasoning easier. (Yes - an extremely pedantic comment...) # 5. Defining an Experiment # In general, however, resolvers involved in the experiment are # expected to understand both standard DNSSEC and the defined # experimental DNSSEC protocol, although this isn't required. A resolver can also understand *multiple* experiments as well as stock DNSSEC. (Right?) # 6. Considerations # 2. It will not be possible for DNSSEC-aware resolvers not aware of # the experiment to build a chain of trust through an experimental # zone. "not be possible" & "not aware." # 8. Security Considerations # # Zones using this methodology will be considered insecure by all # resolvers except those aware of the experiment. It is not generally # possible to create a secure delegation from an experimental zone that # will be followed by resolvers unaware of the experiment. Hmmm. While I think that establishing an experiment in this way looks promising, the teardown might be problematic. (Maybe we need an exit strategy. ;)) (Section 7, elided, is on transitions. Haven't thought what to say about that.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 27 14:56:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxpA-0004QI-DI for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 14:56:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNxp9-0006V6-1D for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 14:56:24 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNxlt-000OJp-Es for namedroppers-data@psg.com; Mon, 27 Mar 2006 19:53:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNxls-000OJZ-2P for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 19:53:00 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k2RJqIbU011858 for ; Mon, 27 Mar 2006 14:52:18 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAANbaijx; Mon, 27 Mar 06 14:52:14 -0500 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k2RJoXqb006281; Mon, 27 Mar 2006 14:50:36 -0500 (EST) Date: Mon, 27 Mar 2006 14:52:42 -0500 (EST) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: "Olaf M. Kolkman" cc: David Blacka , Namedroppers Subject: Re: WGLC dnssec-experiments and dnssec-opt-in In-Reply-To: <31BFB721-5252-453B-ACE8-405D5D925966@NLnetLabs.nl> Message-ID: References: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> <31BFB721-5252-453B-ACE8-405D5D925966@NLnetLabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Mon, 27 Mar 2006, Olaf M. Kolkman wrote: >> I.e., by issuing a query for possible-delegation/IN/NS to the parent. > > Would querying for a DS at that parent work? I would think that that > would be the regular fall back when trying to build a chain of > trust? I'm not certain, but it could only work if you either were lucky enough to guess the proper name of the delegation point or tried them all (remembering that the parent could have a multi-label delegation). This is one of the reasons why the underspecification in 4.2.1 worries me. FWIW, I do concur with David's statement: "I don't see any actual security value from the validator actually enforcing delegation-only", which is one of the reasons I advocated removing the delegation-only restriction rather than add more complexity to the validator and the document. -- Sam -- to unsubscribe send a message to namedroppers-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 Mar 27 15:26:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNyIK-0003Sd-GD for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 15:26:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNyIJ-0007jk-W9 for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 15:26:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNyFa-0000SA-DT for namedroppers-data@psg.com; Mon, 27 Mar 2006 20:23:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNyFZ-0000Rt-Hn for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 20:23:41 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k2RKNflV003565 for ; Mon, 27 Mar 2006 12:23:41 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 12:23:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Proposal, DSA 2048 with 256 bit subgroup Date: Mon, 27 Mar 2006 12:23:37 -0800 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0038_01C651B2.6B7D9A60" Message-ID: <198A730C2044DE4A96749D13E167AD379E0EEB@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposal, DSA 2048 with 256 bit subgroup Thread-Index: AcZR3FRQ2CgvK67yTNCuPOvLtLafVw== From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 27 Mar 2006 20:23:40.0939 (UTC) FILETIME=[565035B0:01C651DC] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C651B2.6B7D9A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ben Laurie asks >> The two reason I'm exploring ECC are the size issue, and to have an >> better answer next time someone ask why are you not using ECC. >If size is the problem, what's wrong with DSA? Until recently the fact that the key size was limited to 512 bits and the hash function to 160 bits. NIST recently approved a new version that allows a 2048 bit key size and 256 bit (or 224 bit) subgroup. This means the keys are 256 bytes, the signatures are 64 bytes. This is not quite as good as the best ECC scheme but we can deploy this today and without the patent hassle that ECC would involve. I propose the folowing: 1) Drop DSA-SHA1 from the spec, it is obsolete. 2) Add DSA-2048-SHA256 as a MUST 3) Relegate the RSA algorithm to SHOULD Time is getting short if DNSSEC is going to meet the next window of opportunity for deployment. That is going to come with the deployment of DKIM. If you want to deploy a security infrastructure you have to meet a security requirement. The biggest deployment problem today is the fact that DNS is perceived to work too well to justify the cost of DNSSEC. The other picture change that has to occur here is the mistaken belief that the protocol must be perfectly secure on day one. Emprically it is much easier to upgrade a deployed infrastructure than to start deployment. The opposition to OPT-IN and anti-zone walking technologies is entirely misguided as is the entire thread on the level of security actually provided. DNSSEC is never going to be the last line of security defense. The DNS is a signaling infrastructure, it is not a discovery infrastructure and its naming capabilities are limited. The user should not expect 'ibm.com' to resolve to the IBM that they are most familiar with, all they can expect is that it will resolve consistently (over certain time intervals). What we need from DNSSEC is a good layer of security to protect the signaling layer infrastructure against attack and to allow the signaling layer to be leveraged by application level security solutions such as SenderID and DKIM. It does not have to be perfect for all purposes to do this. People seem to have a 'single break' security model. This is not appropriate to analysis of DNSSEC except with respect to zone signing keys for large, valuable domains. I would not be at all worried about deploying based on DSA-SHA1 causing problems within the next 5 years. The only reason I strongly urge a change now is that this fix is much easier to do now and has zero impact on the architecture (its just drop in of a new algorithm). It is going to be easier to SELL DNSSEC if the key strength matches expectations. WHEN security flaws are discovered in DNSSEC we will fix them. There have been flaws in every crypto implementation successfully deployed to date - SSL, WEP, PGP, SSH ... The only protocols that have escaped flaw discovery are the ones nobody ever used. Despite these well known flaws I am not aware of a single case where one has been exploited for criminal purposes. Even flawed crypto is not the weakest link in the system. What we cannot fix is a protocol that does not meet the deployment constraints in the field. ------=_NextPart_000_0038_01C651B2.6B7D9A60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjcyMDIzMzdaMCMGCSqGSIb3DQEJBDEWBBRa gkKifzmPCAPI3ywAD6zphPeGRDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYCHG8KbToPGcc+UIH3xDcZNWarQ Kz2WWk1kEd7IeA/lnaVlCRpnOFS1Q2UX7qY7ABE+zgUQhc83FO/nb6xrM2V2R9VC7f2JQQxjKYEc ZU/ctl3cNQ0Qh5h45dK6lacAraZcxOzcByFhQzHRMLT79McDJOlUVL1vwuPIBrSZnTpKvwAAAAAA AA== ------=_NextPart_000_0038_01C651B2.6B7D9A60-- -- to unsubscribe send a message to namedroppers-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 Mar 27 15:37:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNyTK-000371-MC for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 15:37:54 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNyTJ-00084L-CD for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 15:37:54 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNyRK-0001Ye-1U for namedroppers-data@psg.com; Mon, 27 Mar 2006 20:35:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNyRJ-0001YH-6Y for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 20:35:49 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Mon, 27 Mar 2006 15:35:42 -0500 id 002C4018.44284C9E.00001793 In-Reply-To: References: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> <31BFB721-5252-453B-ACE8-405D5D925966@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54AA2F96-C78C-4199-86DC-DD2CD28366F7@verisignlabs.com> Cc: "Olaf M. Kolkman" , Namedroppers Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: WGLC dnssec-experiments and dnssec-opt-in Date: Mon, 27 Mar 2006 15:35:41 -0500 To: Sam Weiler X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Mar 27, 2006, at 2:52 PM, Sam Weiler wrote: > On Mon, 27 Mar 2006, Olaf M. Kolkman wrote: > >>> I.e., by issuing a query for possible-delegation/IN/NS to the >>> parent. >> >> Would querying for a DS at that parent work? I would think that >> that would be the regular fall back when trying to build a chain >> of trust? > > I'm not certain, but it could only work if you either were lucky > enough to guess the proper name of the delegation point or tried > them all (remembering that the parent could have a multi-label > delegation). This is one of the reasons why the underspecification > in 4.2.1 worries me. The issue here isn't that you would have to guess the name of the delegation point. In normal 4035 DNSSEC, you would have to try them all, or at least, try them until you got an actual insecure delegation. The issue is that the response to the DS query doesn't really tell you if that name has a delegation or not. That is, the response looks the same if there is a delegation or just some other insecure RRSet. However, in general, I think that this is OK, even if it doesn't comply with the MUST in 4.2.1 of opt-in. I think this because, while it would allow some forms of non-delegation-only zones to actually work (assuming the authoritative nameserver knew how to serve it correctly), it wouldn't expose new corner-cases in the zone itself (such as: can the SOA be opted-out? can a wildcard?) > > FWIW, I do concur with David's statement: "I don't see any actual > security value from the validator actually enforcing delegation- > only", which is one of the reasons I advocated removing the > delegation-only restriction rather than add more complexity to the > validator and the document. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Mar 27 16:24:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNyiL-0005YD-Mf for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 15:53:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNyiK-0000bL-M3 for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 15:53:25 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNyfF-0002yW-4P for namedroppers-data@psg.com; Mon, 27 Mar 2006 20:50:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNyfE-0002yI-I7 for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 20:50:12 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2RKo1BX020075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Mar 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FNyf3-0008I6-Nf; Mon, 27 Mar 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2539bis-dhk-07.txt Message-Id: Date: Mon, 27 Mar 2006 15:50:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --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 : Storage of Diffie-Hellman Keying Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2539bis-dhk-07.txt Pages : 10 Date : 2006-3-27 The standard method for encoding Diffie-Hellman keys in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2539bis-dhk-07.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-rfc2539bis-dhk-07.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: <2006-3-27130401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2539bis-dhk-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-27130401.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 Mar 27 16:26:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNyiw-0005Zm-29 for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 15:54:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNyiv-0000ou-GO for dnsext-archive@lists.ietf.org; Mon, 27 Mar 2006 15:54:01 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNyfC-0002yA-BK for namedroppers-data@psg.com; Mon, 27 Mar 2006 20:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FNyfA-0002xf-Ji for namedroppers@ops.ietf.org; Mon, 27 Mar 2006 20:50:08 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2RKo1BX020076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Mar 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FNyf3-0008IG-P2; Mon, 27 Mar 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2536bis-dsa-07.txt Message-Id: Date: Mon, 27 Mar 2006 15:50:01 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --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 : DSA Keying and Signature Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-07.txt Pages : 8 Date : 2006-3-27 The standard method of encoding US Government Digital Signature Algorithm keying and signature information for use in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2536bis-dsa-07.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-rfc2536bis-dsa-07.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: <2006-3-27130632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2536bis-dsa-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-27130632.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 Mar 28 11:54:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOHSh-0001GN-S0 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 11:54:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOHSg-0002rA-Hu for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 11:54:31 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOHNk-000M13-L4 for namedroppers-data@psg.com; Tue, 28 Mar 2006 16:49:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOHNj-000M0n-Ir for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 16:49:24 +0000 Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2SGnAMK078660; Tue, 28 Mar 2006 11:49:11 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Tue, 28 Mar 2006 11:48:03 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: stopping amplification Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 I've been urged to send out this proposal, which even I think is rather goofy. Problem statement: Recently, there has been a lot of hub-bub about the use of recursive servers to amplify traffic sent in a DDoS attack. Problem Analysis: There are three thorns in folks' side about this. 1) The attacks use spoofed source addresses. This ain't something that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged. 2) The attacks make use of servers that will answer to arbitrarily sourced packets with lots of data. Currently only recursive servers can really to this, sooner or later any DNSSEC zone server will qualify for this duty. 3) The attacks make use of something called amplification, specifically the ability to send a little message in and get a lot of message out. Item 2 is something that is rather operations-ish. But is bodes not well for protocol developments in the future. Currently the only effective amplification that DNS affords is via recursive servers caching large data sets. In the future, authoritative servers will do so too, via DNSSEC and other means. (The pinata du jour on this one is DNSSEC.) (Ooh, English, Spanish, and French.) Item 3 is something that can be dealt with within the protocol. And this is what my goofy idea addresses. Potential Solution: The crux of the goofy idea is that the only way to prevent DNS from being an agent of amplification is to make the queries (almost) as big as or bigger than the responses. Via padding, of course. That would enable this: I could require that such a query be padded up to the size in the EDNS0 field before I'll deal with it? I know it's goofy to send the extra, useless bytes, but what's more important? Smaller messages or stopping the "baddies" out there? The proposal is to add an optional padding field to EDNS0.5 to allow for padding. A server operator *could* then have a policy that says: answer up to the lesser of the EDNS0 size field and the size of the query. Or, if the query is smaller than the EDNS0 size field, answer REFUSED. Obligatory disclaimer: Yes, this is goofy. But, if we want to stamp out amplification, how else can it be done? I am willing to accept that "we don't intend to stamp out amplification." Or, "is this a long term solution to a short term problem?" PS - Yes, April 1 is this Saturday. Take that for what it's worth. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 28 13:05:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIZc-0000i4-9T for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:05:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOIZZ-0006kj-VV for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:05:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOIWv-00021Q-3u for namedroppers-data@psg.com; Tue, 28 Mar 2006 18:02:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOIWs-000212-F4 for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 18:02:54 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 1789244F0; Tue, 28 Mar 2006 20:02:46 +0200 (CEST) Date: Tue, 28 Mar 2006 20:02:45 +0200 From: bert hubert To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: stopping amplification Message-ID: <20060328180245.GA16548@outpost.ds9a.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Tue, Mar 28, 2006 at 11:48:03AM -0500, Edward Lewis wrote: > I've been urged to send out this proposal, which even I think is rather > goofy. Exceptionally so. Apologies for not criticising this more deeply, but on a general note I'd like to draw attention to the 'amplification' that regular recursing nameservers perform. The PowerDNS recursor takes a lot of effort to prevent queries that have failed recently, and would probably fail again, and to direct queries to nameservers that do respond. Yet despite all this throttling effort, which routinely prevents up to 40% of queries in production, PowerDNS is only a packet-attenuator of 50-80%, iow, for each 100 queries, 20 to 50 packets are sent to the internet. See all this in gory detail on the graphs here: http://adsl-xs4all.ds9a.nl/rrd/ . A small dependency-light version of the recursor is available on http://svn.powerdns.com/pdns-recursor.tar.bz2 I wonder how well other recursors do, and might perhaps not be performing any useful role at all in attenuating packets. Bert. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Mar 28 13:25:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOIsd-0003xV-VJ for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:25:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOIsc-0007t5-M9 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:25:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOIqj-0003lJ-QX for namedroppers-data@psg.com; Tue, 28 Mar 2006 18:23:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOIqi-0003l0-SY for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 18:23:25 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k2SINC0e015702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Mar 2006 18:23:12 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FOIqW-0006wn-8l; Tue, 28 Mar 2006 13:23:12 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair , dnsext chair Subject: Protocol Action: 'The Role of Wildcards in the Domain Name System' to Proposed Standard Message-Id: Date: Tue, 28 Mar 2006 13:23:12 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 The IESG has approved the following document: - 'The Role of Wildcards in the Domain Name System ' as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-11.txt Technical Summary This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. Working Group Summary This document is a work item of the DNSEXT WG. The WG has consensus to publish this document as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. -- to unsubscribe send a message to namedroppers-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 Mar 28 13:36:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJ3W-0003Hh-P8 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:36:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJ3W-00009W-9W for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:36:38 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJ1Y-0004g6-FK for namedroppers-data@psg.com; Tue, 28 Mar 2006 18:34:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJ1X-0004fp-GG for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 18:34:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0CD7C11425 for ; Tue, 28 Mar 2006 18:34:35 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: stopping amplification In-Reply-To: Your message of "Tue, 28 Mar 2006 11:48:03 EST." References: Date: Tue, 28 Mar 2006 18:34:35 +0000 Message-Id: <20060328183435.0CD7C11425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 # Problem Analysis: # # There are three thorns in folks' side about this. # # 1) The attacks use spoofed source addresses. This ain't something # that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged. agreed. # 2) The attacks make use of servers that will answer to arbitrarily # sourced packets with lots of data. Currently only recursive servers # can really to this, sooner or later any DNSSEC zone server will # qualify for this duty. not agreed. authority servers are also willing to answer arbitrarily sourced packets with lots of data. and when we close all the open recursive servers, you can bet that the attacks will change to "pick 50,000 .COM names, find out who their nameservers are, issue spoofed source query streams for WWW..COM". recursion isn't the problem. and when DNSSEC makes it worse, it'll also be worse for authority responses. # 3) The attacks make use of something called amplification, # specifically the ability to send a little message in and get a lot of # message out. not agreed. the most valuable feature (to an attacker) of the current setup is that syntactically valid DNS datagrams get sent to UDP/53 on the victim servers. they can't be firewalled or filtered at line rate inside the victim's ISP since they look just like the packets that OUGHT to be delivered. (this distinguishes them from ICMP attacks, which can be rate limited or filtered far from the servers being attacked.) so, amplification isn't the problem. amplification is just "gravy." # Item 2 is something that is rather operations-ish. But is bodes not # well for protocol developments in the future. Currently the only # effective amplification that DNS affords is via recursive servers # caching large data sets. In the future, authoritative servers will # do so too, via DNSSEC and other means. (The pinata du jour on this # one is DNSSEC.) (Ooh, English, Spanish, and French.) since "dig @ns.watson.ibm.com. www.ibm.com a" sends a 29-octet query (plus UDP and IP headers) soliciting a 130-octet response (plus UDP/IP headers), i really think we should stop saying that you need DNSSEC to get amplification from an authority server. since there are enough authority servers out there, and enough bots available to stream spoofed-source queries to them, to overload pretty much any victim's pipe, i think we should also stop saying that amplification is even necessary. # Item 3 is something that can be dealt with within the protocol. And # this is what my goofy idea addresses. # # Potential Solution: # # The crux of the goofy idea is that the only way to prevent DNS from # being an agent of amplification is to make the queries (almost) as # big as or bigger than the responses. Via padding, of course. as you said, "yes, this is goofy." but not for the reasons you noted. what's wrong with this idea is that it solves only the problems we're not having, while leaving in place all the weaknesses that make today's DNS dangerous and fragile. # Obligatory disclaimer: # # Yes, this is goofy. But, if we want to stamp out amplification, how # else can it be done? I am willing to accept that "we don't intend to # stamp out amplification." Or, "is this a long term solution to a # short term problem?" # # PS - Yes, April 1 is this Saturday. Take that for what it's worth. since recursion and amplification aren't necessary to the success of this attack, i think we had better focus on reflection and spoofing. reflection as in open recursive nameservers. let's force the attackers into using authority servers for this, and then let's de-mix the mode of the authority servers so that there's no "authority and recursion in the same server image" so that authority servers can safely discard any UDP/53 packet from any other authority server (and from any known-open known-abused recursive nameserver.) -- to unsubscribe send a message to namedroppers-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 Mar 28 13:38:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJ4r-0003gM-0F for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:38:01 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOHv2-0004V2-6w for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 12:23:48 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOHkr-0003TF-SU for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 12:13:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOHiu-000NjS-FN for namedroppers-data@psg.com; Tue, 28 Mar 2006 17:11:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOHit-000NjG-Tb for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 17:11:16 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k2SHBDIV003439; Tue, 28 Mar 2006 17:11:13 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k2SHBDkh003438; Tue, 28 Mar 2006 17:11:13 GMT Date: Tue, 28 Mar 2006 17:11:12 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: stopping amplification Message-ID: <20060328171112.GA3328@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f > 1) The attacks use spoofed source addresses. This ain't something > that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged. the real problem.. :) > 2) The attacks make use of servers that will answer to arbitrarily > sourced packets with lots of data. Currently only recursive servers > can really to this, sooner or later any DNSSEC zone server will > qualify for this duty. other applications do this too. > 3) The attacks make use of something called amplification, > specifically the ability to send a little message in and get a lot of > message out. kind of like http, eh? > Item 3 is something that can be dealt with within the protocol. And > this is what my goofy idea addresses. > > Potential Solution: > > The crux of the goofy idea is that the only way to prevent DNS from > being an agent of amplification is to make the queries (almost) as > big as or bigger than the responses. Via padding, of course. so, we give the bad boys an -EXTRA- communications channel as an effective deterent? what could you do with those extra padding bits? --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 Mar 28 13:38:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJ55-0003iI-F5 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:38:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJ54-0000DC-62 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:38:15 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJ3A-0004rM-FM for namedroppers-data@psg.com; Tue, 28 Mar 2006 18:36:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJ39-0004qx-Lf for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 18:36:15 +0000 Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2SIa3mB079509; Tue, 28 Mar 2006 13:36:04 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060328171112.GA3328@vacation.karoshi.com.> References: <20060328171112.GA3328@vacation.karoshi.com.> Date: Tue, 28 Mar 2006 13:34:52 -0500 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: stopping amplification Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa At 17:11 +0000 3/28/06, bmanning@vacation.karoshi.com wrote: >> 1) The attacks use spoofed source addresses. This ain't something >> that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged. > > the real problem.. :) Yes, then we don't need to worry that DNS amplifies. I have no problem with that. > other applications do this too. As in "but, ma, the other kids were throwing rocks too." > kind of like http, eh? Kind of, but no. HTTP uses stream based transport, which is not suitable for the spoofed-packet-DNS-amplified attacks. >> Item 3 is something that can be dealt with within the protocol. And >> this is what my goofy idea addresses. The only reason why I bothered to pursue this is that it would be good if protocols "took care of their own laundry." They don't have to, but it would be good. >> Potential Solution: >> > so, we give the bad boys an -EXTRA- communications channel > as an effective deterent? > what could you do with those extra padding bits? No, we aren't. What the padding is doesn't matter. It's not like I can't hide secret messages in images or mail. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 28 13:42:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJ9b-000572-AY for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:42:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJ9a-0000SS-1g for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:42:55 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJ7c-0005Lm-6z for namedroppers-data@psg.com; Tue, 28 Mar 2006 18:40:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJ7b-0005LI-2f for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 18:40:51 +0000 Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2SIed97079562; Tue, 28 Mar 2006 13:40:40 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060328180245.GA16548@outpost.ds9a.nl> References: <20060328180245.GA16548@outpost.ds9a.nl> Date: Tue, 28 Mar 2006 13:40:54 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: moving on from:? Re: stopping amplification Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d So, it looks like DNS amplification isn't the problem to solve. (Based on a sample set of 2.) Do we branch into another set of questions, or live contentedly with status quo? At 20:02 +0200 3/28/06, bert hubert wrote: >I wonder how well other recursors do, and might perhaps not be performing >any useful role at all in attenuating packets. Okay - then let's address that. Is the resolver's algorithm something of concern to the interoperability of the protocol's implementations? (I ask because this is my gating function for what I think is a candidate for DNSEXT WG. Mind you - "my gating" - a non-authortiative measure.) Or should DNSOP make some judgement on the footprint of damage by a less than optimal resolver algorithm? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 28 13:49:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJFn-0001Uc-N4 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:49:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJFm-0000lQ-Cm for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 13:49:19 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJDL-0005xC-5i for namedroppers-data@psg.com; Tue, 28 Mar 2006 18:46:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJDK-0005wi-9f for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 18:46:46 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 7844844F0; Tue, 28 Mar 2006 20:46:39 +0200 (CEST) Date: Tue, 28 Mar 2006 20:46:39 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: ANY queries, recursing nameserver? Message-ID: <20060328184638.GC16548@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 People, I've trawled RFC 1034, 1035 and 2181, yet I can't find it written down on what a recursing nameserver should do on receiving an ANY query (aka QTYPE=*). http://www.faqts.com/knowledge_base/view.phtml/aid/30221 lists nonsense I think - step 4 of the algorithm is never reached if RD is turned on. 'Mr DNS' (why I think was Cricket), said in 1997: Actually, a T_ANY lookup isn't guaranteed to return the TXT records, unless you're querying the authoritative name server directly. On another name server, T_ANY will only return whatever the server already knows about the domain name. I'd love to believe this but it doesn't sound all too useful to me, but it sure makes coding simple. Anybody have an authoritative (haha) reference? Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Mar 28 14:02:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJSo-0001JD-Dy for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:02:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJSn-0001EJ-4X for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:02:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJQr-0006z9-Ty for namedroppers-data@psg.com; Tue, 28 Mar 2006 19:00:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJQr-0006yl-5A for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 19:00:45 +0000 Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2SJ0Xge079744; Tue, 28 Mar 2006 14:00:34 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060328183435.0CD7C11425@sa.vix.com> References: <20060328183435.0CD7C11425@sa.vix.com> Date: Tue, 28 Mar 2006 14:00:46 -0500 To: Paul Vixie From: Edward Lewis Subject: upon reflection, was Re: stopping amplification Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Ahh, yes, we chatted about this. Port 53 packets do have special status in fire wall rules. >since recursion and amplification aren't necessary to the success of this >attack, i think we had better focus on reflection and spoofing. reflection >as in open recursive nameservers. let's force the attackers into using >authority servers for this, But, one other person (I wish I could recall whom) said that it isn't even reflection that is the problem. If I could recall whom, I'd probably recall the reason. What is the difference between me spoofing the address of an authoritative server and port 53 and me sending a spoofed query from the intended victim to the authoritative server on port 53? (I'm asking for clarification, not as a challenge, although it might sound that way.) Let's assume that the query:response size is about 1:1.negligible, to write reflection off. > and then let's de-mix the mode of the authority >servers so that there's no "authority and recursion in the same server image" >so that authority servers can safely discard any UDP/53 packet from any other >authority server (and from any known-open known-abused recursive nameserver.) I don't get this as being part of the problem. So, to clarify, all me to ask: How does a receiving server know whether the incoming packet is from another authority server? As an aside - I can send queries from port 53 on my laptop, all I need to be is the privileged user. Conversely, can't (on BIND say) I tell the server to use a different port for sourcing packets? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 28 14:09:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJZg-0003jD-GG for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:09:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJZf-0001Pm-5a for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:09:52 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJXJ-0007Rp-FI for namedroppers-data@psg.com; Tue, 28 Mar 2006 19:07:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJXH-0007RX-Uy for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 19:07:24 +0000 Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2SJ78bR079787; Tue, 28 Mar 2006 14:07:10 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060328184638.GC16548@outpost.ds9a.nl> References: <20060328184638.GC16548@outpost.ds9a.nl> Date: Tue, 28 Mar 2006 14:07:23 -0500 To: bert hubert From: Edward Lewis Subject: Re: ANY queries, recursing nameserver? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 At 20:46 +0200 3/28/06, bert hubert wrote: >People, > >I've trawled RFC 1034, 1035 and 2181, yet I can't find it written down on >what a recursing nameserver should do on receiving an ANY query (aka >QTYPE=*). > >http://www.faqts.com/knowledge_base/view.phtml/aid/30221 lists nonsense I >think - step 4 of the algorithm is never reached if RD is turned on. > >'Mr DNS' (why I think was Cricket), said in 1997: > > Actually, a T_ANY lookup isn't guaranteed to return the TXT records, > unless you're querying the authoritative name server directly. On another > name server, T_ANY will only return whatever the server already knows > about the domain name. > >I'd love to believe this but it doesn't sound all too useful to me, but it >sure makes coding simple. > >Anybody have an authoritative (haha) reference? I'll nominate section 5.3.3. of rfc 1034: # 5.3.3. Algorithm # # The top level algorithm has four steps: # # 1. See if the answer is in local information, and if so return # it to the client. (Boom. Done. To OSI with the rest of the algorithm.) 5.3.3. is "pointed to" in 4.3.2: 4.3.2. Algorithm # The actual algorithm used by the name server will depend on the local OS # and data structures used to store RRs. The following algorithm assumes # that the RRs are organized in several tree structures, one for each # zone, and another for the cache: # # 1. Set or clear the value of recursion available in the response # depending on whether the name server is willing to provide # recursive service. If recursive service is available and # requested via the RD bit in the query, go to step 5, # otherwise step 2. ... # 5. Using the local resolver or a copy of its algorithm (see # resolver section of this memo) to answer the query. Store # the results, including any intermediate CNAMEs, in the answer # section of the response. and: # 5. RESOLVERS (to show that 5.3.3 is resolvers.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 28 14:10:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJZs-0003lx-ST for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:10:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJZq-0001QQ-9r for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:10:04 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJXs-0007U1-QM for namedroppers-data@psg.com; Tue, 28 Mar 2006 19:08:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [216.240.18.37] (helo=mx2.netapp.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJXq-0007Tk-8t for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 19:07:58 +0000 Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2.netapp.com with ESMTP; 28 Mar 2006 11:07:57 -0800 X-IronPort-AV: i="4.03,139,1141632000"; d="scan'208"; a="370520064:sNHT16657768" Received: from svlexc02.hq.netapp.com (svlexc02.corp.netapp.com [10.57.157.136]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k2SJ7v7Z021445; Tue, 28 Mar 2006 11:07:57 -0800 (PST) Received: from RTPEXC02.hq.netapp.com ([10.100.157.167]) by svlexc02.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Mar 2006 11:07:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ANY queries, recursing nameserver? Date: Tue, 28 Mar 2006 14:07:57 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANY queries, recursing nameserver? Thread-Index: AcZSmbJQH/Fo2jZYQ/iaelTWDZ8cygAAIX+w From: "Everhart, Craig" To: "bert hubert" , X-OriginalArrivalTime: 28 Mar 2006 19:07:57.0573 (UTC) FILETIME=[ECAB5350:01C6529A] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c My mental model is that T_ANY semantics agrees with 'Mr DNS'. If the server knows anything about the name, that's what the response will be. If it has to forward the query, you might get back what some *other* server knows about the name, which might be authoritative. Back in the day I was sending mail, so I needed T_MX if it existed, but T_A if it didn't. I decided to query with T_ANY and see what I got, then for the specific types, just because of this T_ANY behavior. That is, if my server had to ask around for the answer, it might as well get everything (with T_ANY) rather than have to make one trip for T_MX and then another for T_A. I think the point is that T_ANY is not what the hypothetical T_ABSOLUTELY_EVERYTHING might be. Craig=20 > -----Original Message----- > From: bert hubert [mailto:bert.hubert@netherlabs.nl]=20 > Sent: Tuesday, March 28, 2006 1:47 PM > To: namedroppers@ops.ietf.org > Subject: ANY queries, recursing nameserver? >=20 > People, >=20 > I've trawled RFC 1034, 1035 and 2181, yet I can't find it=20 > written down on what a recursing nameserver should do on=20 > receiving an ANY query (aka QTYPE=3D*). >=20 > http://www.faqts.com/knowledge_base/view.phtml/aid/30221=20 > lists nonsense I think - step 4 of the algorithm is never=20 > reached if RD is turned on. >=20 > 'Mr DNS' (why I think was Cricket), said in 1997: >=20 > Actually, a T_ANY lookup isn't guaranteed to return the=20 > TXT records, > unless you're querying the authoritative name server=20 > directly. On another > name server, T_ANY will only return whatever the server=20 > already knows > about the domain name. >=20 > I'd love to believe this but it doesn't sound all too useful=20 > to me, but it sure makes coding simple. >=20 > Anybody have an authoritative (haha) reference? >=20 > Thanks. >=20 > --=20 > http://www.PowerDNS.com Open source, database driven DNS=20 > Software=20 > http://netherlabs.nl Open and Closed source services >=20 > -- > to unsubscribe send a message to=20 > namedroppers-request@ops.ietf.org with the word 'unsubscribe'=20 > in a single line as the message text body. > archive: >=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 Tue Mar 28 14:26:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJpa-0008Pl-RF for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:26:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJpY-0002St-H3 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:26:18 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJnU-0008cO-Vr for namedroppers-data@psg.com; Tue, 28 Mar 2006 19:24:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJnT-0008cB-U5 for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 19:24:08 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 053B1452E; Tue, 28 Mar 2006 21:24:00 +0200 (CEST) Date: Tue, 28 Mar 2006 21:24:00 +0200 From: bert hubert To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? Message-ID: <20060328192359.GE16548@outpost.ds9a.nl> References: <20060328184638.GC16548@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Tue, Mar 28, 2006 at 02:07:23PM -0500, Edward Lewis wrote: > # 1. See if the answer is in local information, and if so return > # it to the client. Bit of solipsism here I think - this basically says the answer to an ANY query is the answer. > # 5. Using the local resolver or a copy of its algorithm (see > # resolver section of this memo) to answer the query. Store > # the results, including any intermediate CNAMEs, in the answer > # section of the response. More of the same here. It might simply be that the original implementations copped out - it requires extra work to "properly" support the ANY query because to do so you need to cache the ANY answer as a block, with the TTD at now + min(ttls). You also need to store it separately. Also, you'd probably quickly be lying because if a record was added later on, the ANY query would only return it once the first entry of the previous ANY answer timed out. Oh well - I'll implement the logic that PowerDNS does a full ANY query if nothing is in the cache and if something is, just return what we have. I counted the number of ANY queries in a recent tcpdump, they are very rare and appear to be only used by DNSRBL lookups. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Mar 28 14:35:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOJyW-0005Gh-1y for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:35:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOJyU-0002xm-Os for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:35:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJwD-0009ED-S6 for namedroppers-data@psg.com; Tue, 28 Mar 2006 19:33:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOJwC-0009Dy-Vs for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 19:33:09 +0000 Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2SJWrYb080033; Tue, 28 Mar 2006 14:32:54 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060328192359.GE16548@outpost.ds9a.nl> References: <20060328184638.GC16548@outpost.ds9a.nl> <20060328192359.GE16548@outpost.ds9a.nl> Date: Tue, 28 Mar 2006 14:33:09 -0500 To: bert hubert From: Edward Lewis Subject: Re: ANY queries, recursing nameserver? Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 At 21:24 +0200 3/28/06, bert hubert wrote: >On Tue, Mar 28, 2006 at 02:07:23PM -0500, Edward Lewis wrote: > >> # 1. See if the answer is in local information, and if so return >> # it to the client. > >Bit of solipsism here I think - this basically says the answer to an ANY >query is the answer. I suppose "See if an answer" would have been better. But then again, I don't know the difference between its and it's, and between descendant and descendent. >Also, you'd probably quickly be lying because if a record was added later >on, the ANY query would only return it once the first entry of the previous >ANY answer timed out. The DNS was not intended to deal in temporal logic. "Coherency" means ask any server now and get a consistent answer, nothing about asking two servers in time sequence. In fact, you can ask a cache an "ANY" and then a specific for a record set it is missing. The subsequent ANY ought to return what hasn't times out plus the specific on. >Oh well - I'll implement the logic that PowerDNS does a full ANY query if >nothing is in the cache and if something is, just return what we have. Sounds like what I'd expect a server to do. >I counted the number of ANY queries in a recent tcpdump, they are very rare >and appear to be only used by DNSRBL lookups. T_ANY is at best a debugging tool. It has been used in the past to get mail records I think, but really, T_ANY is just for debugging and others trying to abuse the service. IMHO. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 28 14:43:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOK67-0000g5-5v for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:43:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOK65-0003A2-NE for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 14:43:23 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOK3m-0009jd-Fa for namedroppers-data@psg.com; Tue, 28 Mar 2006 19:40:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOK3l-0009jP-Kf for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 19:40:57 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k2SJevCD023584; Tue, 28 Mar 2006 11:40:57 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 11:40:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: stopping amplification Date: Tue, 28 Mar 2006 11:40:54 -0800 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0039_01C65275.9E65A2B0" Message-ID: <198A730C2044DE4A96749D13E167AD379E1041@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: stopping amplification Thread-Index: AcZSlq3k5XRrUha+Qnu9BqzGNOprYgABn1Gg From: "Hallam-Baker, Phillip" To: "Paul Vixie" , X-OriginalArrivalTime: 28 Mar 2006 19:40:56.0522 (UTC) FILETIME=[8836FAA0:01C6529F] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C65275.9E65A2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Paul Vixie > since recursion and amplification aren't necessary to the > success of this attack, i think we had better focus on > reflection and spoofing. I have been trying to work out what the real problem here is. In particular why is the reflected attack worse than the direct attack? The only difference I can see between direct and reflected is that the open resolver used in the reflected attack is going to do retries. In other words the 'amplification' effect is the number of packets and not just the individual packet size. Moreover there are probably broken resolvers out there that will oblige with ridiculous retry policies. I have a very hard time seeing how extending the packet size from about 50 bytes plus header to 500 bytes plus header turns the attack into a devestating one, the cost of switching is going to dominate the bandwidth cost. Increasing the packet count is a completely different matter. As soon as the congestion starts you get an avalanche effect and the effect of the attack suddenly steps up. The real crux of the problem here is that the open recursive resolvers respond to unauthenticated requests. I don't see much value in the proposed ad-hoc protocol change to relieve the symptoms when the deployment cost is the same as the change necessary to address the cause. We could fix the open resolvers with code to detect repeated requests for a particular host and go into a rate limiting mode. This would be at the cost of creating a DoS attack for users of the resolver. The best approach would be to combine the above with a 'registration' protocol. For example the party that ants to register with the server does a computational proof for X units of work, establishes a TSIK shared secret with the resolver, this is used to authenticate requests (including detecting spoofed source address). ------=_NextPart_000_0039_01C65275.9E65A2B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjgxOTQwNTRaMCMGCSqGSIb3DQEJBDEWBBSD Fi2FA/GXRFBEkCB7xfQ92XTghjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYCk8+N2VPD6vbi9hIOax15sASfF tE//GayzFZkAKSwHBNg1DAC+SIJ12kaF4CrBto/pP/wksdQG5vCNr6fe9nTMnknTcnhj+HeGIloT BcmAB/TR7PeojLShTvMAg/6/CZbLE2yVPjtibHZOgXIwV6RD1cJ81RQe2ZEoXde7IzEDwgAAAAAA AA== ------=_NextPart_000_0039_01C65275.9E65A2B0-- -- to unsubscribe send a message to namedroppers-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 Mar 28 15:16:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOKcH-0004zx-1h for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 15:16:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOKcF-000582-GS for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 15:16:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOKZ1-000Btb-SN for namedroppers-data@psg.com; Tue, 28 Mar 2006 20:13:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [157.185.61.2] (helo=M4.sparta.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOKYz-000BtK-If for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 20:13:13 +0000 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id k2SKDA7k015908; Tue, 28 Mar 2006 14:13:10 -0600 Received: from ponyxpress.rosslyn.ads.sparta.com (861.rosslyn.sparta.com [157.185.86.1]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k2SKD7tE027978; Tue, 28 Mar 2006 14:13:08 -0600 Received: from mailbin.rosslyn.ads.sparta.com ([157.185.85.6]) by ponyxpress.rosslyn.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 15:13:07 -0500 Received: from aud.vb.futz.org ([66.93.83.61]) by mailbin.rosslyn.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 15:28:38 -0500 Date: Tue, 28 Mar 2006 15:12:58 -0500 From: Robert Story To: "Hallam-Baker, Phillip" Cc: Subject: Re: stopping amplification In-Reply-To: <198A730C2044DE4A96749D13E167AD379E1041@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD379E1041@MOU1WNEXMB04.vcorp.ad.vrsn.com> Organization: SPARTA X-Mailer: Sylpheed-Claws 2.0.0 (GTK+ 2.6.10; powerpc-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_1umD=X/1y6PL0+=VtUc/lh/"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Message-ID: X-OriginalArrivalTime: 28 Mar 2006 20:28:38.0765 (UTC) FILETIME=[323E99D0:01C652A6] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 --Sig_1umD=X/1y6PL0+=VtUc/lh/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 28 Mar 2006 11:40:54 -0800 Phillip wrote: HBP> I have been trying to work out what the real problem here is. In parti= cular HBP> why is the reflected attack worse than the direct attack? Reflection helps hide the source of the attack. HBP> The only difference I can see between direct and reflected is that the= open HBP> resolver used in the reflected attack is going to do retries.=20 You are looking at the wrong end of the resolver. The attack is the response from the open resolver, not the queries the resolver makes to respond to the (spoofed) packet. The resolver will not retry sending response packets. HBP> I have a very hard time seeing how extending the packet size from abou= t 50 HBP> bytes plus header to 500 bytes plus header turns the attack into a HBP> devestating one, When you multiply that by the number of open recursive servers (unknowingly) participating in the attack, bandwidth very much becomes a factor. Haven't you seen the bandwidth numbers people were reporting for these attacks? Gigabits per second. HBP> The real crux of the problem here is that the open recursive resolvers HBP> respond to unauthenticated requests. Uhhmm... yes, the very definition of an 'open' recursive resolver is one that responds to unauthenticated requests. So one step in reducing the number of potential participants in these attacks is to close as many open recursive resolvers as possible. HBP> We could fix the open resolvers with code to detect repeated requests = for a HBP> particular host and go into a rate limiting mode. This would be at the= cost HBP> of creating a DoS attack for users of the resolver.=20 That wouldn't fix anything. Each open resolver only sees a very small number of requests, so this 'fix' would more likely affect legitimate users of the resolver, and not the attackers. --=20 Robert Story SPARTA --Sig_1umD=X/1y6PL0+=VtUc/lh/ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEKZjN7/fVLLY1mngRAglRAJ98iCNcNVN/kX39KMbYUIMkpxZ9ZACdHC7/ o5DJAruCB04Z3lu+CB+4BzM= =EGLQ -----END PGP SIGNATURE----- --Sig_1umD=X/1y6PL0+=VtUc/lh/-- -- to unsubscribe send a message to namedroppers-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 Mar 28 16:15:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLXi-0000YL-Cd for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 16:15:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOLXg-0007d9-UI for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 16:15:58 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOLUF-000FMx-1b for namedroppers-data@psg.com; Tue, 28 Mar 2006 21:12:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.74] (helo=colibri.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOLUE-000FMl-9r for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 21:12:22 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k2SLCLmS027676; Tue, 28 Mar 2006 13:12:21 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 13:12:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: stopping amplification Date: Tue, 28 Mar 2006 13:12:19 -0800 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005F_01C65282.633C4C40" Message-ID: <198A730C2044DE4A96749D13E167AD379E1058@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: stopping amplification Thread-Index: AcZSpIK6oARfQfCrQmybTeqX/w0OmgABgtEQ From: "Hallam-Baker, Phillip" To: "Robert Story" Cc: X-OriginalArrivalTime: 28 Mar 2006 21:12:20.0647 (UTC) FILETIME=[4D020B70:01C652AC] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C65282.633C4C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > On Tue, 28 Mar 2006 11:40:54 -0800 Phillip wrote: > HBP> I have been trying to work out what the real problem here is. In > HBP> particular why is the reflected attack worse than the > direct attack? > > Reflection helps hide the source of the attack. But they are using spoofed source addresses? > HBP> The only difference I can see between direct and > reflected is that > HBP> the open resolver used in the reflected attack is going > to do retries. > > You are looking at the wrong end of the resolver. The attack > is the response from the open resolver, not the queries the > resolver makes to respond to the (spoofed) packet. The > resolver will not retry sending response packets. In which case won't the same problem affect every DNS server? > HBP> I have a very hard time seeing how extending the packet > size from > HBP> about 50 bytes plus header to 500 bytes plus header turns the > HBP> attack into a devestating one, > > When you multiply that by the number of open recursive servers > (unknowingly) participating in the attack, bandwidth very > much becomes a factor. Haven't you seen the bandwidth numbers > people were reporting for these attacks? Gigabits per second. And what is the bandwidth these people are using to create the attack? A botnet can generate gigabits per second too. If we were talking about jumbo packets and there was an order of magnitude difference I could see amplification as being the motivation. It is much easier to run a flood attack on the botnet host fast than to find a DNS resolver that responds fast enough to make this an amplification attack. The DNS resolver has to be on iron big enough to saturate its output bandwidth for a start. I understand the damage caused, like Paul I do not agree that amplification is the primary motive for this behavior. ------=_NextPart_000_005F_01C65282.633C4C40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjgyMTEyMTlaMCMGCSqGSIb3DQEJBDEWBBTI 3ZhwME2Up4jV+jZZeFTQPCsp8DBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYCjcp8rQD6p9tCzOi5Oyt4CMpEv H1NVtvn2KqmTy458Mp3E3jVS0avnY6NMyOzUfieeDAbae+WQcHFa7CDA2e7K+khJZcGBgga1F+p2 oPnzlV5ljBP82EFaWQ976AsMmOYe4qqqJJaIC62dAmUx54x1Cy/xleGjpwUnBI9OnNttrgAAAAAA AA== ------=_NextPart_000_005F_01C65282.633C4C40-- -- to unsubscribe send a message to namedroppers-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 Mar 28 17:30:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOMhS-00025Q-4t for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 17:30:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOMhR-0001i7-PD for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 17:30:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOMeK-000JLA-02 for namedroppers-data@psg.com; Tue, 28 Mar 2006 22:26:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOMeI-000JKs-T2 for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 22:26:51 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 28 Mar 2006 23:26:49 +0100 X-IronPort-AV: i="4.03,140,1141603200"; d="scan'208"; a="3276275:sNHT29794492" In-Reply-To: <20060328183435.0CD7C11425@sa.vix.com> To: namedroppers@ops.ietf.org Subject: Re: stopping amplification MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 29 Mar 2006 00:26:59 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 03/28/2006 11:26:59 PM, Serialize complete at 03/28/2006 11:26:59 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d owner-namedroppers@ops.ietf.org wrote on 03/28/2006 08:34:35 PM: > since recursion and amplification aren't necessary to the success of this > attack, i think we had better focus on reflection and spoofing. reflection > as in open recursive nameservers. let's force the attackers into using > authority servers for this, and then let's de-mix the mode of the authority > servers so that there's no "authority and recursion in the same server image" > so that authority servers can safely discard any UDP/53 packet from any other > authority server (and from any known-open known-abused recursive nameserver.) I agree mostly. The resolver has the ability to use tcp. The spoofed source does not have that ability. Hence the reflector is able to build a tcp session between itself and the authoritative server. This is a significant part of the amplification. Sending requests with spoofed source addresses directly to the server does not have this effect. Also caching is neglectable since (in this paticular attack) the requests carry a random string as part of a name which gets synthesized by the server due to a wildcard. Reflection and amplification (resulting in TCP) really is the biggest part of the problem. Ignoring requests with the RD bit set (as in dropping it on the floor, not sending 'refused' back) in the authoritative server should be a configurable policy. 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 Tue Mar 28 17:51:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FON2O-00051H-6K for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 17:51:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FON2M-0002YP-SO for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 17:51:44 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FON0M-000KRr-HV for namedroppers-data@psg.com; Tue, 28 Mar 2006 22:49:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FON0L-000KRY-MZ for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 22:49:37 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id EEDD1E6106 for ; Tue, 28 Mar 2006 22:49:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.4) with ESMTP id k2SMnQkN081871; Wed, 29 Mar 2006 08:49:27 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200603282249.k2SMnQkN081871@drugs.dv.isc.org> To: Edward Lewis Cc: bert hubert , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: ANY queries, recursing nameserver? In-reply-to: Your message of "Tue, 28 Mar 2006 14:33:09 CDT." Date: Wed, 29 Mar 2006 09:49:26 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > T_ANY is at best a debugging tool. It has been used in the past to > get mail records I think, but really, T_ANY is just for debugging and > others trying to abuse the service. T_ANY was used because old versions of named would return SERVFAIL if there wasn't a record of the requested type and named had detected a error while loading. Some MTA's thought they needed to query for CNAME which almost always didn't exist and as people were really bad about checking their logs for errors this would just break email. By querying for "*" you avoided this problem. named now hard fails on any zone file error which make it harder to ignore errors. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 28 17:52:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FON2k-0005MG-Ft for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 17:52:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FON2i-0002Ye-5u for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 17:52:06 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FON1M-000KYe-E2 for namedroppers-data@psg.com; Tue, 28 Mar 2006 22:50:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FON1L-000KY3-9I for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 22:50:39 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 1DF514035; Wed, 29 Mar 2006 00:50:31 +0200 (CEST) Date: Wed, 29 Mar 2006 00:50:31 +0200 From: bert hubert To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: stopping amplification Message-ID: <20060328225031.GA22883@outpost.ds9a.nl> References: <20060328183435.0CD7C11425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Wed, Mar 29, 2006 at 12:26:59AM +0200, Roy Arends wrote: > The resolver has the ability to use tcp. The spoofed source does not have This has been tried. http://www.irbs.net/internet/nanog/0507/0186.html WorldNic quit doing that pretty soon - I bet it didn't work, too many clients behind firewalls that were stupidly configured. bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Mar 28 18:03:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONDQ-0004YZ-88 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:03:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONDO-0003Sq-LH for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:03:08 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONBF-000LGB-Fa for namedroppers-data@psg.com; Tue, 28 Mar 2006 23:00:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONBE-000LFx-3y for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 23:00:52 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id k2SN0eqO007569; Wed, 29 Mar 2006 01:00:40 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id k2SN0dq04595; Wed, 29 Mar 2006 01:00:39 +0200 (MEST) Message-Id: <200603282300.k2SN0dq04595@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: Roy Arends Cc: namedroppers@ops.ietf.org From: Peter Koch Subject: Re: stopping amplification In-reply-to: Your message of "Wed, 29 Mar 2006 00:26:59 +0200." X-Change: No longer at the University MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4592.1143586835.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Wed, 29 Mar 2006 01:00:39 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > Ignoring requests with the RD bit set (as in dropping it on the floor, not > sending 'refused' back) in the authoritative server should be a > configurable policy. Have a look at the (legitimate) queries arriving at your servers that have the RD bit set. These are non-negligible. In fact, I'm not aware of any document that actually says an iterating resolver (aka recursive server) SHOULD/MUST only send queries with RD==0. Might be a nice idea. The RD bit is insufficient evidence that something's wrong. And again: the "open" part in "open recursive name server" is evenly important. Even with recursion disabled, such systems still can be abused. -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 Mar 28 18:05:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONFo-0005YF-Bd for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:05:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONFm-0003cp-T9 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:05:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONE5-000LQv-2Z for namedroppers-data@psg.com; Tue, 28 Mar 2006 23:03:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONE2-000LQU-Lz for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 23:03:46 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 29 Mar 2006 00:03:45 +0100 X-IronPort-AV: i="4.03,140,1141603200"; d="scan'208"; a="2876294:sNHT30673944" In-Reply-To: <20060328225031.GA22883@outpost.ds9a.nl> To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: stopping amplification MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 29 Mar 2006 01:03:53 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 03/29/2006 12:03:55 AM, Serialize complete at 03/29/2006 12:03:55 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 bert hubert wrote on 03/29/2006 12:50:31 AM: > On Wed, Mar 29, 2006 at 12:26:59AM +0200, Roy Arends wrote: > > The resolver has the ability to use tcp. The spoofed source does not have > > This has been tried. http://www.irbs.net/internet/nanog/0507/0186.html > > WorldNic quit doing that pretty soon - I bet it didn't work, too many > clients behind firewalls that were stupidly configured. This has nothing to do with 'what has been tried'. Furthermore the reason why "it didn't work" might have something to do with broken resolvers as well. 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 Tue Mar 28 18:10:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONKf-0000CR-RH for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:10:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONKe-0004RE-CB for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:10:37 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONJ0-000LmE-ER for namedroppers-data@psg.com; Tue, 28 Mar 2006 23:08:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONIz-000Lm0-T7 for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 23:08:53 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id F3858E6108 for ; Tue, 28 Mar 2006 23:08:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.4) with ESMTP id k2SN8orf082214; Wed, 29 Mar 2006 09:08:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200603282308.k2SN8orf082214@drugs.dv.isc.org> To: "Hallam-Baker, Phillip" Cc: "Robert Story" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: stopping amplification In-reply-to: Your message of "Tue, 28 Mar 2006 13:12:19 -0800." <198A730C2044DE4A96749D13E167AD379E1058@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Wed, 29 Mar 2006 10:08:50 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da > > On Tue, 28 Mar 2006 11:40:54 -0800 Phillip wrote: > > HBP> I have been trying to work out what the real problem here is. In > > HBP> particular why is the reflected attack worse than the > > direct attack? > > > > Reflection helps hide the source of the attack. > > But they are using spoofed source addresses? You have to get the ISP of the reflector to initiate the traffic backtrace rather than initiating the traffic traceback your self. With the latter you might have agreements with your peers that they will do a traceback through their network if you request it. You are unlikely to have such a agreement with the reflectors ISP. > > HBP> The only difference I can see between direct and > > reflected is that > > HBP> the open resolver used in the reflected attack is going > > to do retries. > > > > You are looking at the wrong end of the resolver. The attack > > is the response from the open resolver, not the queries the > > resolver makes to respond to the (spoofed) packet. The > > resolver will not retry sending response packets. > > In which case won't the same problem affect every DNS server? Yes. Closing ORNs is just exercise to reduce the scale of the problem. > > HBP> I have a very hard time seeing how extending the packet > > size from > > HBP> about 50 bytes plus header to 500 bytes plus header turns the > > HBP> attack into a devestating one, > > > > When you multiply that by the number of open recursive servers > > (unknowingly) participating in the attack, bandwidth very > > much becomes a factor. Haven't you seen the bandwidth numbers > > people were reporting for these attacks? Gigabits per second. > > And what is the bandwidth these people are using to create the attack? A > botnet can generate gigabits per second too. If we were talking about jumbo > packets and there was an order of magnitude difference I could see > amplification as being the motivation. > > It is much easier to run a flood attack on the botnet host fast than to find > a DNS resolver that responds fast enough to make this an amplification > attack. The DNS resolver has to be on iron big enough to saturate its output > bandwidth for a start. > > I understand the damage caused, like Paul I do not agree that amplification > is the primary motive for this behavior. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Mar 28 18:13:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONNU-00012j-JM for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:13:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONNT-0004n9-A2 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:13:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONLx-000M40-8O for namedroppers-data@psg.com; Tue, 28 Mar 2006 23:11:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONLw-000M3j-BI for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 23:11:56 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 29 Mar 2006 00:11:55 +0100 X-IronPort-AV: i="4.03,140,1141603200"; d="scan'208"; a="2876316:sNHT29835168" In-Reply-To: <200603282300.k2SN0dq04595@tyrannia.TechFak.Uni-Bielefeld.DE> To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: stopping amplification MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 29 Mar 2006 01:12:04 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 03/29/2006 12:12:05 AM, Serialize complete at 03/29/2006 12:12:05 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Peter Koch wrote on 03/29/2006 01:00:39 AM: > > Ignoring requests with the RD bit set (as in dropping it on the floor, not > > sending 'refused' back) in the authoritative server should be a > > configurable policy. > > Have a look at the (legitimate) queries arriving at your servers that have > the RD bit set. I have. > These are non-negligible. They were. my servers are authoritative only. It turned out that the only requests coming in with RD bit set where my own debug attempt using DiG which sets RD by default. > In fact, I'm not aware of > any document > that actually says an iterating resolver (aka recursive server) > SHOULD/MUST only > send queries with RD==0. rfc 1035: RD Recursion Desired - this bit may be set in a query and is copied into the response. If RD is set, it directs the name server to pursue the query recursively. Recursive query support is optional. This 'optional' is ambiguous enough to interpret as 'ignore'. In fact, IIRC, some authoritative implementations do this by default. > Might be a nice idea. > The RD bit is insufficient evidence that something's wrong. It'll teach'em though, gnarf gnarf. :) > And again: the "open" part in "open recursive name server" is evenlyimportant. > Even with recursion disabled, such systems still can be abused. Absolutely ! 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 Tue Mar 28 18:31:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONeo-00045K-VD for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:31:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONen-0005Ga-M0 for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:31:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONcC-000N4P-Vv for namedroppers-data@psg.com; Tue, 28 Mar 2006 23:28:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [81.91.161.3] (helo=smtp.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FONcB-000N4B-Vv for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 23:28:44 +0000 Received: from mail-int1.denic.de (mail-int1.denic.de [192.168.0.45]) by smtp.denic.de with esmtp id 1FONcA-0007WB-7G; Wed, 29 Mar 2006 01:28:42 +0200 Received: from localhost by mail-int1.denic.de with local id 1FONc9-0001cF-00; Wed, 29 Mar 2006 01:28:41 +0200 Date: Wed, 29 Mar 2006 01:28:41 +0200 From: Peter Koch To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: stopping amplification Message-ID: <20060328232841.GB2828@denics7.denic.de> References: <200603282300.k2SN0dq04595@tyrannia.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Wed, Mar 29, 2006 at 01:12:04AM +0200, Roy Arends wrote: > They were. my servers are authoritative only. It turned out that the only > requests coming in with RD bit set where my own debug attempt using DiG > which sets RD by default. i'll try to back this with some 'fresh' figures the next days. > RD Recursion Desired - this bit may be set in a query and > is copied into the response. If RD is set, it directs > the name server to pursue the query recursively. > Recursive query support is optional. > > This 'optional' is ambiguous enough to interpret as 'ignore'. In fact, Come on, apply the robustness principle, not martial law. Support being optional means that the targeted server may not honor the RD bit (which is what we are talking about closing recursors) but is no excuse for dropping the query on the floor (at least not during the 'normal' resolution process). -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 Mar 28 18:55:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOO2M-0001bP-5K for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:55:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOO2K-0005ko-Ru for dnsext-archive@lists.ietf.org; Tue, 28 Mar 2006 18:55:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOO0D-000OOl-HH for namedroppers-data@psg.com; Tue, 28 Mar 2006 23:53:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOO0C-000OOX-0L for namedroppers@ops.ietf.org; Tue, 28 Mar 2006 23:53:32 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 29 Mar 2006 00:53:30 +0100 X-IronPort-AV: i="4.03,140,1141603200"; d="scan'208"; a="3276454:sNHT28075332" In-Reply-To: <20060328232841.GB2828@denics7.denic.de> To: Peter Koch Cc: namedroppers@ops.ietf.org, Peter Koch Subject: Re: stopping amplification MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Wed, 29 Mar 2006 01:53:38 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 03/29/2006 12:53:40 AM, Serialize complete at 03/29/2006 12:53:40 AM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Peter Koch wrote on 03/29/2006 01:28:41 AM: > On Wed, Mar 29, 2006 at 01:12:04AM +0200, Roy Arends wrote: > > > They were. my servers are authoritative only. It turned out that the only > > requests coming in with RD bit set where my own debug attempt using DiG > > which sets RD by default. > > i'll try to back this with some 'fresh' figures the next days. > > > RD Recursion Desired - this bit may be set in a query and > > is copied into the response. If RD is set, it directs > > the name server to pursue the query recursively. > > Recursive query support is optional. > > > > This 'optional' is ambiguous enough to interpret as 'ignore'. In fact, > > Come on, apply the robustness principle, not martial law. I was. I'm being liberal in what I accept, but very, VERY consertive in what I send back. > Support being > optional means that the targeted server may not honor the RD bit (which is > what we are talking about closing recursors) but is no excuse for dropping > the query on the floor (at least not during the 'normal' resolution process). I'm acting as the devils' advocate here. Recursive nameservers talk to authoritative nameservers. They clear the RD bit since they intent to do recursion themselves. If a request does not come from a recursive server, and the authoritative server is not willing to do recursion, who is doing the recursion ? Anykey, one may imho explain 'drops the request' as a result of 'Recursive query support is optional'. It has been implemented this way. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 29 00:10:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOSwd-0008DM-TM for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 00:10:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOSwd-0000mw-Dj for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 00:10:11 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOSrR-000E2l-Pt for namedroppers-data@psg.com; Wed, 29 Mar 2006 05:04:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [129.9.40.81] (helo=odvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOSrQ-000E2X-6U for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 05:04:48 +0000 Received: from odnavip4-hme0.oddc.chrysler.com (unknown [53.231.99.241]) by odvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id 25E9D46DD for ; Wed, 29 Mar 2006 00:04:47 -0500 (EST) Received: from wokcdts1.is.chrysler.com ([53.230.102.252]) by odnavip4-hme0.oddc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2006032900044612274 for ; Wed, 29 Mar 2006 00:04:46 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252]) by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id k2T54kN20879 for ; Wed, 29 Mar 2006 00:04:46 -0500 (EST) Message-ID: <442A156E.1030602@daimlerchrysler.com> Date: Wed, 29 Mar 2006 00:04:46 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? References: <20060328184638.GC16548@outpost.ds9a.nl> <20060328192359.GE16548@outpost.ds9a.nl> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Edward Lewis wrote: > At 21:24 +0200 3/28/06, bert hubert wrote: > >> On Tue, Mar 28, 2006 at 02:07:23PM -0500, Edward Lewis wrote: >> >>> # 1. See if the answer is in local information, and if so return >>> # it to the client. >> >> >> Bit of solipsism here I think - this basically says the answer to an ANY >> query is the answer. > > > I suppose "See if an answer" would have been better. But then again, I > don't know the difference between its and it's, and between descendant > and descendent. I agree. "The" answer is the full set of RRsets, from an authoritative source, which may require recursion. "An" answer is any of the RRsets that might happen to be laying around in some particular cache at some particular time. The distinction between the definite and indefinite article is critical, IMO. Almost as critical as the distinction between "its" and "it's" :-). >> Also, you'd probably quickly be lying because if a record was added >> later >> on, the ANY query would only return it once the first entry of the >> previous >> ANY answer timed out. > > > The DNS was not intended to deal in temporal logic. "Coherency" means > ask any server now and get a consistent answer, nothing about asking > two servers in time sequence. > > In fact, you can ask a cache an "ANY" and then a specific for a record > set it is missing. The subsequent ANY ought to return what hasn't > times out plus the specific on. > >> Oh well - I'll implement the logic that PowerDNS does a full ANY >> query if >> nothing is in the cache and if something is, just return what we have. > > > Sounds like what I'd expect a server to do. I'd have to disagree. A resolver which is providing recursion should recurse for "the" answer. If the client didn't want recursion, i.e. if they only wanted "an" answer from their closest resolver, they wouldn't have set RD in the first place. So it's not appropriate to return a recursion-less answer for QTYPE=* while at the same time providing recursion-full answers to more specific QTYPEs of the same QNAME. And it's *doubly* inappropriate, to set RA in a response where the resolver declined to perform the recursion requested because of its discriminatory treatment of QTYPE=*. >> I counted the number of ANY queries in a recent tcpdump, they are >> very rare >> and appear to be only used by DNSRBL lookups. > > > T_ANY is at best a debugging tool. It has been used in the past to get > mail records I think, but really, T_ANY is just for debugging and > others trying to abuse the service. > Um, RD=0 is the debugging tool. QTYPE=* could IMO be somewhat useful, in limited situations, if it weren't so crippled by poor/questionable resolver-implementation choices. Whether the abuse potential of an unfettered QTYPE=* would outweigh its usefulness, is a debatable point... - 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 Wed Mar 29 02:47:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVOw-00024E-BO for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 02:47:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVOl-0006yI-R1 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 02:47:29 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOVLq-000LU0-0H for namedroppers-data@psg.com; Wed, 29 Mar 2006 07:44:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOVLo-000LTm-E9 for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 07:44:20 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2T7iFE4022779; Wed, 29 Mar 2006 09:44:16 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: References: <20060328184638.GC16548@outpost.ds9a.nl> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-59--45185169" Message-Id: Cc: bert hubert , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: ANY queries, recursing nameserver? Date: Wed, 29 Mar 2006 09:44:15 +0200 To: Edward Lewis X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-59--45185169 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Scripture reading time :-).... > # The actual algorithm used by the name server will depend on the > local OS > # and data structures used to store RRs. The following algorithm > assumes > # that the RRs are organized in several tree structures, one for each > # zone, and another for the cache: > # > # 1. Set or clear the value of recursion available in the response > # depending on whether the name server is willing to provide > # recursive service. If recursive service is available and > # requested via the RD bit in the query, go to step 5, > # otherwise step 2. > ... > # 5. Using the local resolver or a copy of its algorithm (see > # resolver section of this memo) to answer the query. Store > # the results, including any intermediate CNAMEs, in the answer > # section of the response. > > and: # 5. RESOLVERS > (to show that 5.3.3 is resolvers.) > Why did you skip 4? # 4. Start matching down in the cache. If QNAME is found in the # cache, copy all RRs attached to it that match QTYPE into the # answer section. If there was no delegation from # authoritative data, look for the best one from the cache, and # put it in the authority section. Go to step 6. That tells us to first look at the cache and return anything that is there if there is anything at all. Only if there is nothing there we proceed to step 5. In other words, Bert's approach: > Oh well - I'll implement the logic that PowerDNS does a full ANY > query if > nothing is in the cache and if something is, just return what we have. is spot on. Or am I missing something. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-59--45185169 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEKjrPtN/ca3YJIocRAh/RAJ4nk6E6HdtXBrCBASbXNTv6g5Cn7ACfec/1 RkQwAIEDj+5csORYMEKcqrk= =J3+A -----END PGP SIGNATURE----- --Apple-Mail-59--45185169-- -- to unsubscribe send a message to namedroppers-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 Mar 29 02:57:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVYh-0000Kw-Cm for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 02:57:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVYf-0007Ki-3Z for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 02:57:39 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOVVv-000M7C-Er for namedroppers-data@psg.com; Wed, 29 Mar 2006 07:54:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOVVu-000M6p-KM for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 07:54:46 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id BF137403F; Wed, 29 Mar 2006 09:54:39 +0200 (CEST) Date: Wed, 29 Mar 2006 09:54:39 +0200 From: bert hubert To: "Olaf M. Kolkman" Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? Message-ID: <20060329075439.GB31691@outpost.ds9a.nl> References: <20060328184638.GC16548@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Wed, Mar 29, 2006 at 09:44:15AM +0200, Olaf M. Kolkman wrote: > ># recursive service. If recursive service is available and > ># requested via the RD bit in the query, go to step 5, > ># otherwise step 2. > Why did you skip 4? Because of step 1. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Mar 29 02:58:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVZp-0000dW-AB for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 02:58:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVZn-0007Ms-Uh for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 02:58:49 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOVYb-000MJr-6A for namedroppers-data@psg.com; Wed, 29 Mar 2006 07:57:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOVYa-000MJf-J2 for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 07:57:32 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2C83311425 for ; Wed, 29 Mar 2006 07:57:32 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? In-Reply-To: Your message of "Wed, 29 Mar 2006 09:44:15 +0200." References: <20060328184638.GC16548@outpost.ds9a.nl> Date: Wed, 29 Mar 2006 07:57:32 +0000 Message-Id: <20060329075732.2C83311425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 # That tells us to first look at the cache and return anything that is there # if there is anything at all. Only if there is nothing there we proceed to # step 5. # # In other words, Bert's approach...is spot on. # # Or am I missing something. as a matter of practical consideration, even if the rules were to be changed or clarified in a way that matched the common sense interpretation (which is that if RD=1 and the content-in-case didn't come about due to QTYPE=*, one should go fetch QTYPE=* from the authority server and update the cache thusly before generating the response), there are so many servers who treat QTYPE=* as a maintainance mode query ("tell me what's in the cache but don't change it just because i'm asking you this question") that the "new rule" would be pretty much vapid. i'm in possession of at least one recursive nameserver who will return current-cache-content unless that would be empty in which case a QTYPE=* query is issued toward an authority server. all we know for certain is, initiators of QTYPE=* queries toward caching forwarders are expecting the unpredictable. that won't change no matter what the scriptures turn out to have intended. -- to unsubscribe send a message to namedroppers-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 Mar 29 03:02:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOVde-000498-91 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 03:02:46 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOVdd-0007ZQ-0u for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 03:02:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOVbi-000Mag-3U for namedroppers-data@psg.com; Wed, 29 Mar 2006 08:00:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOVbh-000MaL-Dg for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 08:00:45 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2T80hxb044902; Wed, 29 Mar 2006 10:00:43 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <20060329075439.GB31691@outpost.ds9a.nl> References: <20060328184638.GC16548@outpost.ds9a.nl> <20060329075439.GB31691@outpost.ds9a.nl> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-64--44197065" Message-Id: <4A100858-49D7-4EB6-9F33-A6F5E118AE59@NLnetLabs.nl> Cc: Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: ANY queries, recursing nameserver? Date: Wed, 29 Mar 2006 10:00:43 +0200 To: bert hubert X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-64--44197065 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 29, 2006, at 9:54 AM, bert hubert wrote: > On Wed, Mar 29, 2006 at 09:44:15AM +0200, Olaf M. Kolkman wrote: > >>> # recursive service. If recursive service is available and >>> # requested via the RD bit in the query, go to step 5, >>> # otherwise step 2. >> Why did you skip 4? > > Because of step 1. Doohhh... --Olaf --Apple-Mail-64--44197065 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEKj6rtN/ca3YJIocRAqqdAKCFg7I6e/29rOAwtgVUcm+niF32HQCfedua rDIElAPLL4UyaK8I4xk/XWs= =6Hf8 -----END PGP SIGNATURE----- --Apple-Mail-64--44197065-- -- to unsubscribe send a message to namedroppers-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 Mar 29 07:21:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZgJ-0002WO-8D for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 07:21:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOZgH-0001K2-V1 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 07:21:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOZc2-000DBH-BA for namedroppers-data@psg.com; Wed, 29 Mar 2006 12:17:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOZc1-000DAj-9y for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 12:17:21 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2TCHI7X056856; Wed, 29 Mar 2006 14:17:18 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) In-Reply-To: <54AA2F96-C78C-4199-86DC-DD2CD28366F7@verisignlabs.com> References: <28E0A624-C304-4502-BBE9-E30C051AC73C@verisignlabs.com> <31BFB721-5252-453B-ACE8-405D5D925966@NLnetLabs.nl> <54AA2F96-C78C-4199-86DC-DD2CD28366F7@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-77--28802193" Message-Id: <3DABD58A-E556-4E1F-9776-D047F8CF6B31@nlnetlabs.nl> Cc: Sam Weiler , Namedroppers Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: WGLC dnssec-experiments and dnssec-opt-in Date: Wed, 29 Mar 2006 14:17:18 +0200 To: David Blacka X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-77--28802193 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 27, 2006, at 10:35 PM, David Blacka wrote: > However, in general, I think that this is OK, even if it doesn't > comply with the MUST in 4.2.1 of opt-in. I think this because, > while it would allow some forms of non-delegation-only zones to > actually work (assuming the authoritative nameserver knew how to > serve it correctly), it wouldn't expose new corner-cases in the > zone itself (such as: can the SOA be opted-out? can a wildcard?) But this would be an argument for a "SHOULD" instead of a "MUST" in 4.2.1 or at the least some wording about this corner case and an explanation that security properties would not change (you cannot make something insecure that is in fact secure). I think we should address this now we know of it. Maybe not nibble it to death (we are talking about an 'experiment' here). no hats, --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-77--28802193 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEKnrOtN/ca3YJIocRAvXSAJ4/o5hyN9luYhLJoqgbsIY0PTM4LQCfVSc3 PrTJrOrVnJxbXTjI8KX+0IY= =aFB+ -----END PGP SIGNATURE----- --Apple-Mail-77--28802193-- -- to unsubscribe send a message to namedroppers-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 Mar 29 09:20:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FObWv-0005nr-30 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 09:20:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FObWs-0006cT-K7 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 09:20:13 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FObUA-000Ket-Qm for namedroppers-data@psg.com; Wed, 29 Mar 2006 14:17:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FObU8-000Kea-Ke for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 14:17:21 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 1283D33C3F; Wed, 29 Mar 2006 15:17:19 +0100 (BST) Message-ID: <442A967D.4040603@algroup.co.uk> Date: Wed, 29 Mar 2006 15:15:25 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Roy Arends CC: Peter Koch , namedroppers@ops.ietf.org, Peter Koch Subject: Re: stopping amplification References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Roy Arends wrote: >> Come on, apply the robustness principle, not martial law. > > I was. I'm being liberal in what I accept, but very, VERY consertive in > what I send back. I should note that it is not considered a very good idea to be liberal in what you accept these days: it has a tendency to cause interesting security problems. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 29 10:21:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOcUT-0006R8-2t for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 10:21:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOcUS-0001EF-LP for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 10:21:45 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOcQW-000OKl-EE for namedroppers-data@psg.com; Wed, 29 Mar 2006 15:17:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOcQV-000OKS-O8 for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 15:17:39 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2006 07:17:39 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,144,1141632000"; d="scan'208"; a="24718391:sNHT24374576" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2TFHcWc022678; Wed, 29 Mar 2006 10:17:38 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 10:17:38 -0500 Received: from [10.86.240.176] ([10.86.240.176]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 10:17:38 -0500 Message-ID: <442AA511.6030504@cisco.com> Date: Wed, 29 Mar 2006 10:17:37 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? References: <20060328184638.GC16548@outpost.ds9a.nl> <20060329075732.2C83311425@sa.vix.com> In-Reply-To: <20060329075732.2C83311425@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2006 15:17:38.0255 (UTC) FILETIME=[EA207DF0:01C65343] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Paul Vixie wrote: > # That tells us to first look at the cache and return anything that is there > # if there is anything at all. Only if there is nothing there we proceed to > # step 5. > # > # In other words, Bert's approach...is spot on. > # > # Or am I missing something. > > as a matter of practical consideration, even if the rules were to be changed > or clarified in a way that matched the common sense interpretation (which is > that if RD=1 and the content-in-case didn't come about due to QTYPE=*, one > should go fetch QTYPE=* from the authority server and update the cache thusly > before generating the response), there are so many servers who treat QTYPE=* > as a maintainance mode query ("tell me what's in the cache but don't change > it just because i'm asking you this question") that the "new rule" would be > pretty much vapid. i'm in possession of at least one recursive nameserver > who will return current-cache-content unless that would be empty in which > case a QTYPE=* query is issued toward an authority server. all we know for > certain is, initiators of QTYPE=* queries toward caching forwarders are > expecting the unpredictable. that won't change no matter what the scriptures > turn out to have intended. I don't think this is accidental. The example in 6.2.2 of RFC 1034 (second and third packet diagrams) clearly shows a non-authoritative server responding with whatever is in cache. The resolver algorithm in 5.3.3, which is referenced by step 5 in 4.3.2 begins with: 1. See if the answer is in local information, and if so return it to the client. This is probably open to interpretation with respect to QTYPE=ANY queries, but the QTYPE matching described in 3.7.1 says QTYPE * (ANY) "matches all RR types". It doesn't say anything about being guaranteed to produce all RRs for a name, just that it matches all RRs it is compared against. RFC 1035 also has text that implies QTYPE=* returns whatever is in cache. Section 7.1 (Transforming a user request into a query) says, "Where possible, the QTYPE and QCLASS should correspond to a single type and a single class, because this makes the use of cached data much simpler. The reason for this is that the presence of data of one type in a cache doesn't confirm the existence or non-existence of data of other types, hence the only way to be sure is to consult an authoritative source" It may not seem useful or intuitive to someone who wishes to retrieve all RRs for a name without going to the authoritative source, but I think the behavior of a caching server returning what's in cache when queried for QTYPE=* is a valid interpretation of the standard. -josh > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-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 Mar 29 10:47:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOcto-0005OS-4X for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 10:47:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOctm-0002Lo-MA for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 10:47:56 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOcrK-000Py9-WD for namedroppers-data@psg.com; Wed, 29 Mar 2006 15:45:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOcrK-000Pxx-Ez for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 15:45:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1324911427 for ; Wed, 29 Mar 2006 15:45:22 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? In-Reply-To: Your message of "Wed, 29 Mar 2006 10:17:37 EST." <442AA511.6030504@cisco.com> References: <20060328184638.GC16548@outpost.ds9a.nl> <20060329075732.2C83311425@sa.vix.com> <442AA511.6030504@cisco.com> Date: Wed, 29 Mar 2006 15:45:22 +0000 Message-Id: <20060329154522.1324911427@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 # I don't think this is accidental. that's not always as straightforwardly obvious as just "read the examples". # It may not seem useful or intuitive to someone who wishes to retrieve all # RRs for a name without going to the authoritative source, but I think the # behavior of a caching server returning what's in cache when queried for # QTYPE=* is a valid interpretation of the standard. that's why the last failed EDNS1 proposal (written in august 2002) had, in addition to multiple QNAME support, a bit called RRD ("recursion really desired"). i still think this should be explored. time to repost the draft? -- to unsubscribe send a message to namedroppers-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 Mar 29 12:41:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOefk-0003dg-Gu for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 12:41:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOefj-0007xz-7m for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 12:41:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOeZU-0007Om-OY for namedroppers-data@psg.com; Wed, 29 Mar 2006 17:35:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOeZS-0007NE-3a for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 17:35:02 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2THYo6v086169; Wed, 29 Mar 2006 12:34:50 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060329122848.03ef1dd8@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 Mar 2006 12:34:00 -0500 To: Kevin Darcy , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: ANY queries, recursing nameserver? In-Reply-To: <442A156E.1030602@daimlerchrysler.com> References: <20060328184638.GC16548@outpost.ds9a.nl> <20060328192359.GE16548@outpost.ds9a.nl> <442A156E.1030602@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 At 00:04 29/03/2006, Kevin Darcy wrote: >Edward Lewis wrote: > >>At 21:24 +0200 3/28/06, bert hubert wrote: >> >>>On Tue, Mar 28, 2006 at 02:07:23PM -0500, Edward Lewis wrote: >>> >>>># 1. See if the answer is in local information, and if so return >>>># it to the client. >>> >>> >>>Bit of solipsism here I think - this basically says the answer to an ANY >>>query is the answer. >> >> >>I suppose "See if an answer" would have been better. But then >>again, I don't know the difference between its and it's, and >>between descendant and descendent. > >I agree. "The" answer is the full set of RRsets, from an >authoritative source, which may require recursion. "An" answer is >any of the RRsets that might happen to be laying around in some >particular cache at some particular time. The distinction between >the definite and indefinite article is critical, IMO. Almost as >critical as the distinction between "its" and "it's" :-). ANY != ALL As this is ANY query the "An answer" is sufficient. Paul's RDD bit proposal was to address this. It is also possible to add a new query type (ALL) to differentiate between the two behaviors. Not sure either effort is worth the deployment cost. A simple FAQ/BCP that says if you want "The" ALL answer, query authorative servers directly. 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 Mar 29 14:13:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOg6U-0007Zx-Hd for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 14:13:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOg6T-0004V2-9D for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 14:13:14 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOg3t-000EG7-AX for namedroppers-data@psg.com; Wed, 29 Mar 2006 19:10:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOg3s-000EFv-EJ for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 19:10:32 +0000 Received: from [10.31.32.110] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k2TJAKpX086690; Wed, 29 Mar 2006 14:10:21 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20060329122848.03ef1dd8@ogud.com> References: <20060328184638.GC16548@outpost.ds9a.nl> <20060328192359.GE16548@outpost.ds9a.nl> <442A156E.1030602@daimlerchrysler.com> <6.2.5.6.2.20060329122848.03ef1dd8@ogud.com> Date: Wed, 29 Mar 2006 14:10:37 -0500 To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= From: Edward Lewis Subject: Re: ANY queries, recursing nameserver? Cc: Kevin Darcy , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Going back to the start of the thread... Does anyone want a T_ALL? The original post seemed more like a request for clarification than a request to do T_ALL. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-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 Mar 29 14:34:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOgR0-0002rb-K8 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 14:34:26 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOgQy-0005B1-A1 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 14:34:26 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOgP3-000Fxi-Cd for namedroppers-data@psg.com; Wed, 29 Mar 2006 19:32:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOgP0-000FxL-T6 for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 19:32:23 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 15FE34556; Wed, 29 Mar 2006 21:32:15 +0200 (CEST) Date: Wed, 29 Mar 2006 21:32:15 +0200 From: bert hubert To: Edward Lewis Cc: =?unknown-8bit?Q?=D3lafur=5FGu=F0mundsson?= , Kevin Darcy , namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? Message-ID: <20060329193215.GA10248@outpost.ds9a.nl> References: <20060328184638.GC16548@outpost.ds9a.nl> <20060328192359.GE16548@outpost.ds9a.nl> <442A156E.1030602@daimlerchrysler.com> <6.2.5.6.2.20060329122848.03ef1dd8@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa On Wed, Mar 29, 2006 at 02:10:37PM -0500, Edward Lewis wrote: > Going back to the start of the thread... > > Does anyone want a T_ALL? I wouldn't say no to it, but what most clients actually want is probably more along the lines of T_ADDR. I can't think of a use case where you'd just want to have *everything*. It would need to be an EDNS thing though. Generally, I think there are bigger fish to fry in the DNS world. My own favorite, and one that I think DNS operators are actually waiting for, is the zone provisioning protocol as described in: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00565.html And in this message to dnsop, which appears not to have arrived or hasn't been archived: I've been pondering writing a 'zone provisioning protocol', from http://wiki.powerdns.com/projects/trac/wiki/TodoList : The big idea waiting to happen is the Zone Provisioning Protocol which allows 'dns peers' to exchange zones, or force resyncs (regardless of SOA serial numbers). This might live outside of PowerDNS Would anybody be interested in this? My idea would be to keep this as simple as possible, but still provide for zones to be provisioned and deprovisioned by different parties, ie, you get to deprovision only the zones you've previously provisioned etc. It is highly probable that this protocol will not be on port 53, nor use DNS messages. It would only talk about DNS. Let me know. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Mar 29 17:19:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOj11-0004Og-Q4 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 17:19:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOj10-0003Tm-CK for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 17:19:47 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOivo-0003X6-5q for namedroppers-data@psg.com; Wed, 29 Mar 2006 22:14:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOivn-0003Wv-GJ for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 22:14:23 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 9B1DAE6109 for ; Wed, 29 Mar 2006 22:14:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.4) with ESMTP id k2TMEFtt095717 for ; Thu, 30 Mar 2006 08:14:16 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200603292214.k2TMEFtt095717@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: ANY queries, recursing nameserver? In-reply-to: Your message of "Wed, 29 Mar 2006 21:32:15 +0200." <20060329193215.GA10248@outpost.ds9a.nl> Date: Thu, 30 Mar 2006 09:14:15 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 > On Wed, Mar 29, 2006 at 02:10:37PM -0500, Edward Lewis wrote: > > Going back to the start of the thread... > > > > Does anyone want a T_ALL? > > I wouldn't say no to it, but what most clients actually want is probably > more along the lines of T_ADDR. I can't think of a use case where you'd just > want to have *everything*. > > It would need to be an EDNS thing though. > > Generally, I think there are bigger fish to fry in the DNS world. > > My own favorite, and one that I think DNS operators are actually waiting > for, is the zone provisioning protocol as described in: > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00565.html > > And in this message to dnsop, which appears not to have arrived or hasn't > been archived: > > I've been pondering writing a 'zone provisioning protocol', from > http://wiki.powerdns.com/projects/trac/wiki/TodoList : > > The big idea waiting to happen is the Zone Provisioning Protocol which > allows 'dns peers' to exchange zones, or force resyncs (regardless of SOA > serial numbers). This might live outside of PowerDNS > > Would anybody be interested in this? > > My idea would be to keep this as simple as possible, but still provide for > zones to be provisioned and deprovisioned by different parties, ie, you get > to deprovision only the zones you've previously provisioned etc. > > It is highly probable that this protocol will not be on port 53, nor use DNS > messages. It would only talk about DNS. > > Let me know. It would be interesting. Whatever it is would need to be extensible and handle vendor specific extensions. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Mar 29 19:57:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOlTL-0005Pe-Kc for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 19:57:11 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOkh0-0001oI-70 for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 19:07:14 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOkSv-0005oL-IY for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 18:52:43 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOkQT-000Cg5-CB for namedroppers-data@psg.com; Wed, 29 Mar 2006 23:50:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOkQQ-000Cfs-Ts for namedroppers@ops.ietf.org; Wed, 29 Mar 2006 23:50:07 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2TNo2BX030599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FOkQM-0004cE-Bu; Wed, 29 Mar 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-rsasha256-01.txt Message-Id: Date: Wed, 29 Mar 2006 18:50:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --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 : Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC Author(s) : J. Jansen Filename : draft-ietf-dnsext-dnssec-rsasha256-01.txt Pages : 7 Date : 2006-3-29 This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-rsasha256-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-rsasha256-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: <2006-3-29160903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-rsasha256-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-29160903.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 Mar 29 21:08:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOma8-000080-7Y for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 21:08:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOma5-0007Nf-Tf for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 21:08:16 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOmX8-0000ZN-JT for namedroppers-data@psg.com; Thu, 30 Mar 2006 02:05:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOmX5-0000Z3-Qu for namedroppers@ops.ietf.org; Thu, 30 Mar 2006 02:05:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 59B8111425; Thu, 30 Mar 2006 02:05:07 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Mark Andrews cc: namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? In-Reply-To: Your message of "Thu, 30 Mar 2006 09:14:15 +1100." <200603292214.k2TMEFtt095717@drugs.dv.isc.org> References: <200603292214.k2TMEFtt095717@drugs.dv.isc.org> Date: Thu, 30 Mar 2006 02:05:07 +0000 Message-Id: <20060330020507.59B8111425@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 # > I've been pondering writing a 'zone provisioning protocol', from # > http://wiki.powerdns.com/projects/trac/wiki/TodoList : # > # > The big idea waiting to happen is the Zone Provisioning Protocol which # > allows 'dns peers' to exchange zones, or force resyncs (regardless of SOA # > serial numbers). This might live outside of PowerDNS # > # > Would anybody be interested in this? i have a proposal for this, vendor independent, prototyped as some perl scripts. i'll see if the academic paper i submitted has a URL yet. -- to unsubscribe send a message to namedroppers-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 Mar 29 23:01:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOoLH-0004G7-Pe for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 23:01:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOoLF-0003wZ-5o for dnsext-archive@lists.ietf.org; Wed, 29 Mar 2006 23:01:03 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOoHg-000Bsp-Hl for namedroppers-data@psg.com; Thu, 30 Mar 2006 03:57:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [129.9.168.76] (helo=shvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOoHf-000BsZ-22 for namedroppers@ops.ietf.org; Thu, 30 Mar 2006 03:57:19 +0000 Received: from shnavip4-hme0.shdc.chrysler.com (unknown [53.231.141.98]) by shvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id E852210FBA6 for ; Wed, 29 Mar 2006 22:57:17 -0500 (EST) Received: from wokcdts1.is.chrysler.com ([53.230.102.252]) by shnavip4-hme0.shdc.chrysler.com (SMSSMTP 4.1.7.33) with SMTP id M2006032922571724176 for ; Wed, 29 Mar 2006 22:57:17 -0500 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252]) by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id k2U3vHN29919 for ; Wed, 29 Mar 2006 22:57:17 -0500 (EST) Message-ID: <442B571D.9010301@daimlerchrysler.com> Date: Wed, 29 Mar 2006 22:57:17 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? References: <20060328184638.GC16548@outpost.ds9a.nl> <20060329075732.2C83311425@sa.vix.com> <442AA511.6030504@cisco.com> In-Reply-To: <442AA511.6030504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Josh Littlefield wrote: > Paul Vixie wrote: > >> # That tells us to first look at the cache and return anything that >> is there >> # if there is anything at all. Only if there is nothing there we >> proceed to >> # step 5. >> # # In other words, Bert's approach...is spot on. >> # # Or am I missing something. >> >> as a matter of practical consideration, even if the rules were to be >> changed >> or clarified in a way that matched the common sense interpretation >> (which is >> that if RD=1 and the content-in-case didn't come about due to >> QTYPE=*, one >> should go fetch QTYPE=* from the authority server and update the >> cache thusly >> before generating the response), there are so many servers who treat >> QTYPE=* >> as a maintainance mode query ("tell me what's in the cache but don't >> change >> it just because i'm asking you this question") that the "new rule" >> would be >> pretty much vapid. i'm in possession of at least one recursive >> nameserver >> who will return current-cache-content unless that would be empty in >> which case a QTYPE=* query is issued toward an authority server. all >> we know for >> certain is, initiators of QTYPE=* queries toward caching forwarders are >> expecting the unpredictable. that won't change no matter what the >> scriptures >> turn out to have intended. > > > I don't think this is accidental. The example in 6.2.2 of RFC 1034 > (second and third packet diagrams) clearly shows a non-authoritative > server responding with whatever is in cache. No, I think that's a misreading. The intro to the examples section clearly states that the example queries are RD=0 unless otherwise specified. So the example you cite is putatively an RD=0 query, which is apples and oranges from what we're discussing in this thread. > The resolver algorithm in 5.3.3, which is referenced by step 5 in > 4.3.2 begins with: > > 1. See if the answer is in local information, and if so return > it to the client. > > This is probably open to interpretation with respect to QTYPE=ANY > queries, but the QTYPE matching described in 3.7.1 says QTYPE * (ANY) > "matches all RR types". It doesn't say anything about being > guaranteed to produce all RRs for a name, just that it matches all RRs > it is compared against. I think you're misreading a matching rule as a step in, or a statement about the resolution algorithm. Saying that X matches Y doesn't _ipso_facto_ imply anything about how the Y data is fetched, where it's fetched from, what effect the RD flag has, how much work should be expended trying to get the Y answer, etc. It's simply saying that *if*and/or*when*and/or*once*the*data*becomes*available* (by whatever means, maybe it just materialized out of thin air), then a match either occurs or doesn't occur. It's more declaritive than procedural. By reading 5.3.3 as a statement about the resolution algorithm, I think you're imparting far too much passivity to that algorithm in the (arbitrarily) special case of QTYPE=*. The *general* resolution algorithm, in simplistic terms, is to recurse for the answer that the client requested, when recursion was requested and the resolver is willing (as defined by its administrator's conscious policy decisions) and able to provide it and "the answer" (the definition of which can and has been quibbled over) is not already available in cache. Why make a special case for QTYPE=* queries in the resolution algorithm, just because of the way the matching rule was described in a different part of the RFC set? > RFC 1035 also has text that implies QTYPE=* returns whatever is in > cache. Section 7.1 (Transforming a user request into a query) says, > > "Where possible, the QTYPE and QCLASS should correspond to a single > type and a single class, because this makes the use of cached data > much simpler. The reason for this is that the presence of data of one > type in a cache doesn't confirm the existence or non-existence of data > of other types, hence the only way to be sure is to consult an > authoritative source" Actually, I read it exactly the opposite way, i.e. as an operational recommendation to users/applications to *minimize* their use of QTYPE=* and/or QCLASS=* queries, since such queries *force* recursive resolvers to go out and fetch fresh data from authoritative sources in order to be "sure" that the answers returned are complete. The motivation for this paragraph seems to be that overuse of QTYPE=* and/or QCLASS=* might lead to performance/scalability problems. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Mar 30 01:50:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOqyc-0006F1-8R for dnsext-archive@lists.ietf.org; Thu, 30 Mar 2006 01:49:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOqtW-0001z4-Se for dnsext-archive@lists.ietf.org; Thu, 30 Mar 2006 01:44:39 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOqqB-000Mpx-5u for namedroppers-data@psg.com; Thu, 30 Mar 2006 06:41:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOqqA-000Mph-4J for namedroppers@ops.ietf.org; Thu, 30 Mar 2006 06:41:06 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 897B240F0; Thu, 30 Mar 2006 08:40:58 +0200 (CEST) Date: Thu, 30 Mar 2006 08:40:58 +0200 From: bert hubert To: Paul Vixie Cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: ANY queries, recursing nameserver? Message-ID: <20060330064057.GA22945@outpost.ds9a.nl> References: <200603292214.k2TMEFtt095717@drugs.dv.isc.org> <20060330020507.59B8111425@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060330020507.59B8111425@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Thu, Mar 30, 2006 at 02:05:07AM +0000, Paul Vixie wrote: > i have a proposal for this, vendor independent, prototyped as some perl > scripts. i'll see if the academic paper i submitted has a URL yet. That would be very cool, especially if we can whip it up old-school 'implement first, spec later' style, and keep things simple. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-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 Mar 30 03:00:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOs4y-0004S7-Tq for dnsext-archive@lists.ietf.org; Thu, 30 Mar 2006 03:00:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOs4v-000686-H4 for dnsext-archive@lists.ietf.org; Thu, 30 Mar 2006 03:00:28 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOs1P-0001Rm-K6 for namedroppers-data@psg.com; Thu, 30 Mar 2006 07:56:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FOs1O-0001RW-26 for namedroppers@ops.ietf.org; Thu, 30 Mar 2006 07:56:46 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:211:2fff:fed7:7378]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k2U7uakL076829; Thu, 30 Mar 2006 09:56:36 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-87-41951876" Message-Id: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Continuing the work on key-rollover Date: Thu, 30 Mar 2006 09:56:32 +0200 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-87-41951876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Dear Colleagues, After Re-issuing issue 1 [1] and asking for a hum at the physical =20 meeting I plan to close the issue next week and ask the editors to =20 add the text. No other issues have been brought up. If you have any other issues or =20= requirements then please speak up next week[*]. The editors promised =20 to stay on top of the document (by volunteering Suresh for the job, =20 thanks!). I hope that Suresh can whip up a new revision in a week or two and if =20= there are no further comments we'll last call it. In the mean time, please look at the various proposals on the table. =20 The document that Alberto Mart=EDnez Herrera provided to us in November=20= [2] might, or even will, be useful. (URL: http://=20 docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf). There =20 are other people that did comparison matrices, can they please =20 provide links? If there are folk that have any other rollover-proposals to add then =20 please submit that seem to fit to the requirements; better start =20 writing text but please do realize that you add entropy :-) . I hope we can converge to one spec before next IETF. --Olaf [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/=20 msg00370.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/=20 msg01546.html [*] Somebody told me that they would like to see the ability to add =20 a 'time-delay' as a property of the rollover scheme. To paraphrase: =20 That way one cannot compromise the system and immediately run with =20 it. A mala-fide roller will have to sit on the compromised system for =20= a while before it can be abused. (I can't recall who mentioned this =20 but if somebody supports this requirement, please speak up). ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-87-41951876 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFEK481tN/ca3YJIocRAojFAKCoWvIugV7tt1A9ZAptsQlHvPQbdACgoYGk hLjb/1TreddBuMCfGBiQ7qo= =RFry -----END PGP SIGNATURE----- --Apple-Mail-87-41951876-- -- to unsubscribe send a message to namedroppers-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 Mar 30 21:02:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP8yG-0000Fe-Bl for dnsext-archive@lists.ietf.org; Thu, 30 Mar 2006 21:02:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP8yF-0004ya-1A for dnsext-archive@lists.ietf.org; Thu, 30 Mar 2006 21:02:40 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FP8s8-0002T8-7L for namedroppers-data@psg.com; Fri, 31 Mar 2006 01:56:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FP8s5-0002Ss-2K for namedroppers@ops.ietf.org; Fri, 31 Mar 2006 01:56:17 +0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k2V2CKdY001902 for ; Thu, 30 Mar 2006 19:12:20 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k2V29Nji017207 for ; Thu, 30 Mar 2006 20:09:23 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-dnsext-rfc2536bis-dsa-07.txt & draft-ietf-dnsext-rfc2539bis-dhk-07.txt Date: Thu, 30 Mar 2006 20:56:14 -0500 Message-ID: <3870C46029D1F945B1472F170D2D9790C3151C@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-dnsext-rfc2536bis-dsa-07.txt & draft-ietf-dnsext-rfc2539bis-dhk-07.txt Thread-Index: AcZR4ZnpQpE1vEzqSsaiL2P+h3UeoACVeg2w From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe As per my previous email, these are simply updates to the version and date, to re-enliven these expired drafts, and fixes to boilerplate nits. To maintain the continuity of the WG LC. Technical changes were not made. Donald -----Original Messages----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 27, 2006 3:50 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2536bis-dsa-07.txt=20 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 : DSA Keying and Signature Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-07.txt Pages : 8 Date : 2006-3-27 =09 The standard method of encoding US Government Digital Signature Algorithm keying and signature information for use in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-07. txt 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 : Storage of Diffie-Hellman Keying Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2539bis-dhk-07.txt Pages : 10 Date : 2006-3-27 =09 The standard method for encoding Diffie-Hellman keys in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-07. 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 Fri Mar 31 19:52:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPULw-0007uo-Ts for dnsext-archive@lists.ietf.org; Fri, 31 Mar 2006 19:52:32 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPULv-0001Cc-KD for dnsext-archive@lists.ietf.org; Fri, 31 Mar 2006 19:52:32 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPTuE-0009VE-Ro for namedroppers-data@psg.com; Sat, 01 Apr 2006 00:23:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-16.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPTuD-0009Uz-UP for namedroppers@ops.ietf.org; Sat, 01 Apr 2006 00:23:54 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k310NpSb030601; Fri, 31 Mar 2006 16:23:51 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k310NpKR030600; Fri, 31 Mar 2006 16:23:51 -0800 Date: Fri, 31 Mar 2006 16:23:51 -0800 Message-Id: <200604010023.k310NpKR030600@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4398 on Storing Certificates in the Domain Name System (DNS) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d A new Request for Comments is now available in online RFC libraries. RFC 4398 Title: Storing Certificates in the Domain Name System (DNS) Author: S. Josefsson Status: Standards Track Date: March 2006 Mailbox: simon@josefsson.org Pages: 17 Characters: 35652 Obsoletes: RFC2538 See-Also: I-D Tag: draft-ietf-dnsext-rfc2538bis-09.txt URL: http://www.rfc-editor.org/rfc/rfc4398.txt Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: