From owner-namedroppers@ops.ietf.org Sat Dec 1 08:44:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14139 for ; Sat, 1 Dec 2001 08:44:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16AA2B-000Enj-00 for namedroppers-data@psg.com; Sat, 01 Dec 2001 05:18:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16AA2A-000End-00 for namedroppers@ops.ietf.org; Sat, 01 Dec 2001 05:18:22 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16AA2A-000IlW-00 for namedroppers@ops.ietf.org; Sat, 01 Dec 2001 05:18:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: To: namedroppers@ops.ietf.org Subject: list policy From: Randy Bush Date: Sat, 01 Dec 2001 03:00:00 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 2 21:58:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02908 for ; Sun, 2 Dec 2001 21:58:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16AiwI-000Fzg-00 for namedroppers-data@psg.com; Sun, 02 Dec 2001 18:34:38 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16AiwI-000Fza-00 for namedroppers@ops.ietf.org; Sun, 02 Dec 2001 18:34:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16AiwI-000BmQ-00 for namedroppers@ops.ietf.org; Sun, 02 Dec 2001 18:34:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.0.2.1.2.20011202131106.021097b8@localhost> In-Reply-To: <200111302005.fAUK57o03206@as.vix.com> References: <200111300750.fAU7oaI21432@birch.ripe.net> Date: Sun, 02 Dec 2001 18:33:09 -0800 To: Paul A Vixie , namedroppers@ops.ietf.org From: "David R. Conrad" Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, At 12:05 PM 11/30/2001 -0800, Paul A Vixie wrote: >i keep looking at opt-in and DS and asking "how many more years will it take >before we get the complexity managed in dnssec and have widely deployed it?" Yes. >i have an alternative proposal. use hardware crypto and since .COM with the >protocol we have now and stop the merry-go-round of dnssec protocol >development >before a lot of us are overcome with motion sickness. While I too would like the merry-go-round to stop, signing large zones like .COM isn't the problem, or rather it is among the easier problems to solve -- just throw hardware at it as you note. The harder problem to solve is propagating O(10 GB) worth of DNS data globally in a short amount of time (particularly in the worst case scenario of private key compromise). The next hardest problem to solve is key management, particularly in the same worst case scenario. The hardest problem to solve is to convince people DNSSEC does something useful -- it appears there is a view that protecting name/address translations aren't particularly interesting given there are other ways of skinning that particular security cat that are already in use (e.g., SSL, TLS, etc). Of course, the DNS can be used for things other than name/address translations and insuring the integrity of that data would probably be important, however there are people who believe that such use of the DNS is ill-advised. Fix the last problem and I'm sure DNSSEC will be deployed, regardless of what the IETF thinks needs to be done wrt the standards. Rgds, -drc to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 3 09:04:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00377 for ; Mon, 3 Dec 2001 09:04:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16AtIa-0001oa-00 for namedroppers-data@psg.com; Mon, 03 Dec 2001 05:38:20 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16AtIZ-0001oU-00 for namedroppers@ops.ietf.org; Mon, 03 Dec 2001 05:38:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16AtIZ-0005U8-00 for namedroppers@ops.ietf.org; Mon, 03 Dec 2001 05:38:19 -0800 Message-Id: <200112031337.IAA28972@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-01.txt Date: Mon, 03 Dec 2001 08:37:18 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-01.txt Pages : 14 Date : 30-Nov-01 A standard method for storing elliptic curve cryptographic keys in the Domain Name System is described which utilizes DNS KEY resource record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ecc-key-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-ecc-key-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: <20011130160630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011130160630.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Dec 3 09:06:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00519 for ; Mon, 3 Dec 2001 09:06:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16AtIW-0001oI-00 for namedroppers-data@psg.com; Mon, 03 Dec 2001 05:38:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16AtIV-0001oC-00 for namedroppers@ops.ietf.org; Mon, 03 Dec 2001 05:38:15 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16AtIV-0005U2-00 for namedroppers@ops.ietf.org; Mon, 03 Dec 2001 05:38:15 -0800 Message-Id: <200112031337.IAA28959@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dhcid-rr-04.txt Date: Mon, 03 Dec 2001 08:37:13 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for encoding DHCP information (DHCID RR) Author(s) : M. Stapp, T. Lemon, A. Gustafsson Filename : draft-ietf-dnsext-dhcid-rr-04.txt Pages : 9 Date : 30-Nov-01 It is possible for multiple DHCP clients to attempt to update the same DNS FQDN 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-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dhcid-rr-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-dhcid-rr-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: <20011130160532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011130160532.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 5 06:30:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18462 for ; Wed, 5 Dec 2001 06:30:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BZhG-0007NG-00 for namedroppers-data@psg.com; Wed, 05 Dec 2001 02:54:38 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16BZhE-0007Mu-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 02:54:37 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16BZhD-000Nir-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 05:54:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112051050.fB5Aora44300@open.nlnetlabs.nl> In-Reply-To: "Paul A Vixie's message as of Nov 30, 21:33" From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 5 Dec 2001 11:50:53 +0100 To: Paul A Vixie , namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Paul A Vixie, on Nov 30, 21:33, in "Re: Transition from ..."] > i keep looking at opt-in and DS and asking "how many more years will it take > before we get the complexity managed in dnssec and have widely deployed it?" Hi, There are two issues here on which timely deployment, or deployment ever depends, first the conclusions: DS: we need it. OptIn: if OptIn, why not just forget NXT? Let me explain: - DS: There is a real issue with the parent-child communication in 2535, which must be resolved, before TLDs can deploy it. Result: no solution no deployment. On the other hand, there are quite a number of (TLD-)people that are both ready and anxious to start deploying DNSSEC, but just waiting for DS (or any other solution to deal with the parental SIG over the childs KEY) to be accepted. - Opt-In: Opt-In will help superlarge TLDs, but IMHO it also changes the basic idea of DNSSEC from: "securing the DNS infrastructure" into: "securing small parts of the tree or even single RRsets" From recent discussions, I have learned that many people think that doing that is reasonable (although I personally do not agree), because: 1. the DNS infrastructure is not that vulnarable anymore; 2. only few people believe full DNSSEC will ever be deployed; 3. there is real value in securing only the RRsets that matter (KEYs, APPKEYs, CERT, www.bank.tld, etc.); so, secure only what needs to be secured, and forget the rest. My personal conclusion from this line of thinking is: If ("IF") we go for Opt-In, then go for it all the way, and just forget authenticated denial. This will really make implementation and deployment much simpler, and thus speed it up. Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 5 15:26:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09231 for ; Wed, 5 Dec 2001 15:26:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BiJK-00082C-00 for namedroppers-data@psg.com; Wed, 05 Dec 2001 12:06:30 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16BiJI-000822-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 12:06:28 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16BiJG-000NyJ-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 12:06:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200112051050.fB5Aora44300@open.nlnetlabs.nl> References: "Paul A Vixie's message as of Nov 30, 21:33" Date: Wed, 5 Dec 2001 09:24:38 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Transition from 2535 to opt-in Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 5:50 AM -0500 12/5/01, Ted Lindgreen wrote: >OptIn: if OptIn, why not just forget NXT? The question of whether "authenticated denial is desired" has been answered "yes" a number of times over the past year or so The question has been raised by the WG chair on the list and in person at London. So it appears that there is a desire to provide the service. (Why? I don't know.) Opt-In allows those who want authenticated denial to have that service. Because opt-in has a means to indicate when it is in use, there is no ambiguity on the part of the resolver when it comes to understanding the situation. Signalling opt-in is done by the lack of the NXT bit in the NXT RRDATA's type bitmap. I think this is a solid but expensive way to indicate the status. Solid in terms of its indication - there is only one bit involved to comunicate yes/no, so there is no conflict possible in the resolver's processing. Unlike trying to tag the zone key set to indicate the way a zone operates, which means multiple bits indicating a yes/no status, this indication leave no room for ambiguity. Expensive in that this mechanism can only be done once. If we use the NXT bit in the bitmap for this purpose, it can't be done again. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 5 19:41:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23003 for ; Wed, 5 Dec 2001 19:41:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Bm9P-000HHD-00 for namedroppers-data@psg.com; Wed, 05 Dec 2001 16:12:31 -0800 Received: from tserver.conference.usenix.org ([209.179.127.3] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16Bm9O-000HH6-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:12:30 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16Bm9M-000O3V-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:12:28 -0800 Message-ID: <3C0E3271.B5071C1F@isi.edu> MIME-Version: 1.0 References: <200112051050.fB5Aora44300@open.nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 05 Dec 2001 09:42:57 -0500 From: Daniel Massey To: Ted Lindgreen CC: Paul A Vixie , namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lindgreen wrote: > > [Quoting Paul A Vixie, on Nov 30, 21:33, in "Re: Transition from ..."] > > i keep looking at opt-in and DS and asking "how many more years will it take > > before we get the complexity managed in dnssec and have widely deployed it?" > > Hi, > > There are two issues here on which timely deployment, or > deployment ever depends, first the conclusions: > > DS: we need it. > OptIn: if OptIn, why not just forget NXT? > > Let me explain: > > - DS: > There is a real issue with the parent-child communication > in 2535, which must be resolved, before TLDs can deploy it. Ted is exactly right. We need DS to make wide scale deployment feasible. The only thing I would add is that the need for DS is not just limited to just TLDs. Based on our test deployment and related work we have been doing, DS is essential for anyone that has to deal with multiple organizations (i.e. anyone with one or more child zones that are run by someone other than you). Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 5 19:43:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23065 for ; Wed, 5 Dec 2001 19:43:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BmGj-000Had-00 for namedroppers-data@psg.com; Wed, 05 Dec 2001 16:20:05 -0800 Received: from tserver.conference.usenix.org ([209.179.127.3] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16BmGh-000HaI-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:20:03 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16BmGg-000O4l-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:20:02 -0800 Message-Id: <5.1.0.14.2.20011205102507.032deec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 05 Dec 2001 10:35:34 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson (by way of =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair ) Subject: DNSEXT agenda at 52 IETF. Cc: agenda@ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSEXT(tensions) Agenda at the 52'nd IETF 2001/Dec/10 19:30 - 22:00 (Monday) Savoy Room. Chairs: Olafur Gudmundsson, ogud@ogud.com Randy Bush, randy@psg.com DNSEXT Agenda 05 min Agenda Bashing Olafur Gudmundsson 05 min WG status Olafur Gudmundsson Multicast/Zeroconf DNS 15 min Multicast DNS. Bernard Aboda http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-07.txt 10 min Alternatives to Multicast DNS ? Olafur Gudmundsson Open discussion DNSSEC 15 min DNS threat model Rob Austein & Derek Atkins http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-00.txt 05 min Delegation Signer Olafur Gudmundsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-04.txt 05 min Opt IN Roy Arends http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-01.txt 05 min RFC253xbis KEY revisions Donald Eastlake. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-01.txt 05 min AD bit (open issue) Olafur Gudmundsson http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-03.txt 15 min Next steps Randy Bush Open discussion to follow up on the London discussion on the status of DNSSEC protocol and if or what changes to make to protocol before advancing it. Other DNS issues 10 min TKEY rekey mode Yuji Kamite http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-00.txt Other DNS issues 10 min New DNS MIB Barr Hibbs http://www.ietf.org/internet-drafts/draft-hibbs-dns-server-mib-00.txt 10 min NGtrans DNS ops. requirements Alain Durand http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dns-ops-req-03.txt. 10 min DNS Stale Resource Rec. Removal Kamal Janardhan http://www.ietf.org/internet-drafts/draft-janardhan-dnsext-aging-00.txt 05 min Observed DNS Resolution Misbehavior Matt Larson http://www.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-00.txt Where do application KEY's go ? 05 min Restrict KEY Dan Massey http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-00.txt 05 min Generic KEY RR Protocol value Edward Lewis http://www.ietf.org/internet-drafts/draft-lewis-dnsext-key-genprot-00.txt 05 min APPKEY Jakob Schlyter http://www.ietf.org/internet-drafts/draft-schlyter-appkey-01.txt 05 min Directions for using DNS as key storage Olafur Gudmundsson to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 5 19:46:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23169 for ; Wed, 5 Dec 2001 19:46:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BmNf-000Hrx-00 for namedroppers-data@psg.com; Wed, 05 Dec 2001 16:27:15 -0800 Received: from tserver.conference.usenix.org ([209.179.127.3] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16BmNd-000Hrn-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:27:14 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16BmNb-000O5T-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:27:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112051736.fB5Hauo08958@as.vix.com> In-Reply-To: Message from ted@tednet.nl (Ted Lindgreen) of "Wed, 05 Dec 2001 11:50:53 +0100." <200112051050.fB5Aora44300@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Date: Wed, 05 Dec 2001 09:36:56 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From recent discussions, I have learned that many people > think that doing that is reasonable (although I personally > do not agree), because: > 1. the DNS infrastructure is not that vulnarable anymore; i challenge this. the dns infrastructure is as vulnerable as it ever was. in bind8/contrib we ship several "contributed" spoofage tools that work just as well now as the day they were written, and are not BIND specific at all. > 2. only few people believe full DNSSEC will ever be deployed; opt-in doesn't change this. right now we need to get "." signed and then any subdomain who publishes a key can be signed and so on. "opt-in" is for partial signing of large zones -- only those who have published keys. what we need to do is sign the whole thing, including keys when present. opt-in is a crutch for COM, which is "hard" to sign. > 3. there is real value in securing only the RRsets that > matter (KEYs, APPKEYs, CERT, www.bank.tld, etc.); > so, secure only what needs to be secured, and forget the rest. i challenge this. SSL is non-universal and even so depends on trusting small numbers of signing authorities. DNS is universal and depends only on getting one's key signed by the parent domain's administrator, of whom there can be an unlimited number (though only one per domain). we need universal capability for certainty across all RR types. things like A and PTR are no less authenticity-critical than KEY and CERT and so on. > My personal conclusion from this line of thinking is: > If ("IF") we go for Opt-In, then go for it all the way, and > just forget authenticated denial. This will really make > implementation and deployment much simpler, and thus speed > it up. my own conclusion from this is that since arguments for authenticated denial were made years ago and are still quite compelling, there's no reason to do opt-in except as a crutch for COM. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 5 19:51:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23329 for ; Wed, 5 Dec 2001 19:51:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BmUq-000I8Y-00 for namedroppers-data@psg.com; Wed, 05 Dec 2001 16:34:40 -0800 Received: from tserver.conference.usenix.org ([209.179.127.3] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16BmUo-000I8B-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:34:38 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16BmUn-000O5y-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:34:37 -0800 Message-ID: <20011205141844.A17359@research.netsol.com> References: <200112051050.fB5Aora44300@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <200112051050.fB5Aora44300@open.nlnetlabs.nl> Date: Wed, 5 Dec 2001 14:18:44 -0500 From: Mike Schiraldi Cc: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 05, 2001 at 11:50:53AM +0100, Ted Lindgreen wrote: > My personal conclusion from this line of thinking is: > If ("IF") we go for Opt-In, then go for it all the way, and > just forget authenticated denial. This will really make > implementation and deployment much simpler, and thus speed > it up. Without NXT records and authenticated denial, there is no security. Imagine the following subset of the COM zone, in an Opt-In world: ; foo1.com is secure foo1.com NXT foo3.com NS SIG KEY foo1.com NS ns.foo.net foo1.com KEY ... foo1.com SIG KEY ... foo1.com SIG NXT ... ; foo2.com is not secure foo2.com NS ns.xyz.net ; foo3.com is secure foo3.com NXT foo4.com NS SIG KEY foo3.com NS ns.abc.net foo3.com KEY ... foo3.com SIG KEY ... foo3.com SIG NXT ... Let's say you do a query for www.foo3.com, and your ISP wants to hijack the query and make it appear that foo3.com is not secure and has a nameserver of ns.yourisp.nl. Without NXT records, it can formulate a response like FOO3.COM. NS NS.YOURISP.NL NS.YOURISP.NL A 1.2.3.4 But with NXT records, that doesn't work. As shown in the example section of the Opt-In draft, a response for an insecure domain would have to include a NXT record showing it was not secure. In other words, it would have to look something like: FOO3.COM. NS NS.YOURISP.NL NS.YOURISP.NL A 1.2.3.4 FOO1.COM. NXT FOO4.COM. NS SIG KEY ; this record proves that there is ; no secure domain between foo1 ; and foo4; in other words, it=20 ; shows that foo3 is not secure FOO1.COM. SIG NXT ... ; [some other RRs omitted for simplicity] And your ISP can't do this, because it can't create the SIG record. --=20 Mike Schiraldi VeriSign Applied Research --YZ5djTAD1cGYuMQK Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIKIAYJKoZIhvcNAQcCoIIKETCCCg0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B6wwggR2MIID36ADAgECAhAyACTCO7tQsBTRNUR0/tTjMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMDMyMjAwMDAw MFoXDTAyMDMyMjIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pa2UgU2NoaXJhbGRpMSgwJgYJKoZI hvcNAQkBFhlyYWxkaUByZXNlYXJjaC5uZXRzb2wuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDu28IxMPojtN900dqX3LO3rfhirsJstpbSOzKVwPH9GwIgycFIn3YFkmOpeB40 cBkqNC1HzreGuFFAo9f3Y9xPjbvnEWlNo6oBu/wGL53gUtsUcNcj7tOngfjTr/4V3rohPuWU 4qRAZxjd5qaFUSP3bLh/U/7MoRwRB2Sz82HCqwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAYOkgLNF2 HYrK+ucdU0TN2PIAtbB3vV0cLhHJfE6zzyL9u5PlAKnxqwVYozd5S/u4Lg1WvDFE3vG3mVIE Fobol2RmSNIo6kOgED48B6oWgU/21lysVZ6DRPnGTSX7FsIH12L0mHj7jSDkzTqtkbzY6is/ YBkKDmeAuXnmljJ7H7wwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG 9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNV BAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN OTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQW u1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0Rc qkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqn sX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4w PAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOB gQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s 3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg 5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAyACTCO7tQsBTRNUR0/tTjMAkGBSsOAwIa BQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMjA1 MTkxODQ0WjAjBgkqhkiG9w0BCQQxFgQUGsQrFddW1ivg27VXAFXjLeSdSKIwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA2Tyb8Pxl6z39N+unb8Ooa n7Up78sgQYYT6dp3BwDoIUxxv0jv4sPRUWGfVLnb8ZU1skBXha1UAuETjihQDziS/KyOKA+i OfFx5+Knaiow8tNRrPd+yR8iyLqY7y1UNDVdxYcc208f27qp7J78ZHNqdnB/ey/X7izDRMl2 /8MVFw== --YZ5djTAD1cGYuMQK-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 5 19:56:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23467 for ; Wed, 5 Dec 2001 19:56:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BmZY-000IMO-00 for namedroppers-data@psg.com; Wed, 05 Dec 2001 16:39:32 -0800 Received: from tserver.conference.usenix.org ([209.179.127.3] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16BmZX-000IMG-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:39:31 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16BmZX-000O6X-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 16:39:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112052034.fB5KYoo11358@as.vix.com> In-Reply-To: Message from Edward Lewis of "Wed, 05 Dec 2001 09:24:38 EST." To: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Date: Wed, 05 Dec 2001 12:34:50 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Expensive in that this mechanism can only be done once. If we use the NXT > bit in the bitmap for this purpose, it can't be done again. sure it can. we can continue discussing the whichness of what in our ivory tower for another five years (it's already been five years; what's five more?) three years from now we'll have opt-maybe, opt-in, opt-out, and who knows what else. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Dec 5 22:14:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27792 for ; Wed, 5 Dec 2001 22:14:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16BolS-000NHl-00 for namedroppers-data@psg.com; Wed, 05 Dec 2001 18:59:58 -0800 Received: from tserver.conference.usenix.org ([209.179.127.3] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16BolR-000NHf-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 18:59:57 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16BolP-000OBd-00 for namedroppers@ops.ietf.org; Wed, 05 Dec 2001 18:59:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200112051736.fB5Hauo08958@as.vix.com> In-Reply-To: Paul A Vixie's message of "Wed, 05 Dec 2001 09:36:56 -0800" Message-ID: To: Paul A Vixie Cc: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in From: Derek Atkins Date: 05 Dec 2001 20:33:05 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie writes: > > 3. there is real value in securing only the RRsets that > > matter (KEYs, APPKEYs, CERT, www.bank.tld, etc.); > > so, secure only what needs to be secured, and forget the rest. > > i challenge this. SSL is non-universal and even so depends on > trusting small numbers of signing authorities. DNS is universal and > depends only on getting one's key signed by the parent domain's > administrator, of whom there can be an unlimited number (though only > one per domain). It's even worse that you say, Paul... First, SSL only protects TCP-based protocols. That limits it to a subset of existing protocols (a rather large subset, mind you, but a subset nonetheless). Second, using SSL doesn't help you at all when you try to use DNS indirection pointers (CNAME, SRV, AFSDB, etc.) Only 2535+ DNSSec can protect blind[1] DNS "delegations" in this manner. -derek [1] by "blind" I mean that the end-host doesn't know about all the potential delegations that may point to it. In the SSL sense, what this means is that I may have a CNAME from hostX.foo.com pointing to hostY.bar.net; for SSL to work, hostY would need to have a certificate for "hostX.foo.com" whereas with DNSSec it would not need to know about this delegation. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 6 18:10:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15758 for ; Thu, 6 Dec 2001 18:10:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16C7Km-000GTf-00 for namedroppers-data@psg.com; Thu, 06 Dec 2001 14:49:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16C7Kl-000GTZ-00 for namedroppers@ops.ietf.org; Thu, 06 Dec 2001 14:49:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16C7Kl-000FTF-00 for namedroppers@ops.ietf.org; Thu, 06 Dec 2001 14:49:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112060957.fB69vkG09614@birch.ripe.net> In-Reply-To: Message from Edward Lewis of "Wed, 05 Dec 2001 09:24:38 EST." To: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Date: Thu, 06 Dec 2001 10:57:46 +0100 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ed wrote: * The question of whether "authenticated denial is desired" has been answered * "yes" a number of times over the past year or so The question has been * raised by the WG chair on the list and in person at London. So it appears * that there is a desire to provide the service. (Why? I don't know.) * * Opt-In allows those who want authenticated denial to have that service. * * (... technical bit skipped ...) To me this is almost a paradox :-) I am still trying to get to a opinion about opt-in. A few thoughts on the subject; If you say "Opt-In allows those who want authenticated denial to have that service" you only refer to the "server" side of the problem. As a client or as a user of the system I have little choice. If opt-in is adapted the zone owner will decide to which granularity authenticated denial of existence is in place: - In a verifiable insecure zone there is no such thing as authenticated denial. - In a RFC2535 zone authenticated denial is available for all records in the zone. - In an OPT-IN zone the authenticated denial is granular. IMHO DNSSEC can only be a success if it is widely deployed over the DNS tree and it easy for end users to understand they are in a secure zone or not. Adding granularity makes understanding the security in the tree much harder for end users (i.e. troubleshooting sysadmins). I am concerned about OPT-IN becoming a widely deployed mechanism because it adds complexity to the secure DNS tree that is expensive for the end-user. In other words, I understand that opt-in allows for reasonable (and billable) costs on the server side. I am worried about the costs of opt-in on the client side prohibiting deployment. AFAIK .com is one of the few (and maybe the only) zone(s) that has scaling problems when using a non granular (rfc2535) approach. What I understand from the NLnet Labs folk is that it is technically possible to sign and serve relatively big TLDs such as .de (on a desktop PC) and even .com (on a $5000 alpha). Since I think the opt-in is only useful for HUGE delegation zones I would like the to see the last line of the security section changed from: "Thus, it is recommended to use RFC 2535 [4] where possible and to use Opt-In where necessary." into: "opt-in increases the complexity of the secure DNS tree, therefore it's use should be very carefully considered. RFC 2535 NXT records SHOULD be used in almost all zones. The use of opt-in SHOULD only be considered in zones that mainly consist of delegation records and for which inclusion of NXT for the whole zone is prohibitively expensive." --Olaf PS. One technical argument for authenticated denial of existence is a counter measure against DOS attacks; I query for a RR in a secured domain and I get a NXDOMAIN or NOANSWER back from a man in the middle. Without authenticated denial of existence I will be lost. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 6 18:10:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15772 for ; Thu, 6 Dec 2001 18:10:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16C7Me-000GXa-00 for namedroppers-data@psg.com; Thu, 06 Dec 2001 14:51:36 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16C7Me-000GXU-00 for namedroppers@ops.ietf.org; Thu, 06 Dec 2001 14:51:36 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16C7Me-000FYr-00 for namedroppers@ops.ietf.org; Thu, 06 Dec 2001 14:51:36 -0800 Message-ID: <20011206120232.Y46034-100000@main> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 6 Dec 2001 12:46:38 +0100 (CET) From: Roy Arends To: Cc: , Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 5 Dec 2001, Edward Lewis wrote: > At 5:50 AM -0500 12/5/01, Ted Lindgreen wrote: > >OptIn: if OptIn, why not just forget NXT? > > The question of whether "authenticated denial is desired" has been answered > "yes" a number of times over the past year or so The question has been > raised by the WG chair on the list and in person at London. So it appears > that there is a desire to provide the service. (Why? I don't know) Why ? In a secured world I want cryptographic proof that somebank.info does not exist if asked for. Simply handing over an NXDOMAIN status doesn't cut it, anyone could give me that status, and there is nothing to cryptographicly verify. Would make a beauty of a DoS if it did. > Opt-In allows those who want authenticated denial to have that service. > Because opt-in has a means to indicate when it is in use, there is no > ambiguity on the part of the resolver when it comes to understanding the > situation. Signalling opt-in is done by the lack of the NXT bit in the NXT > RRDATA's type bitmap. I think this is a solid but expensive way to > indicate the status. > > Solid in terms of its indication - there is only one bit involved to > comunicate yes/no, so there is no conflict possible in the resolver's > processing. Unlike trying to tag the zone key set to indicate the way a > zone operates, which means multiple bits indicating a yes/no status, this > indication leave no room for ambiguity. > > Expensive in that this mechanism can only be done once. If we use the NXT > bit in the bitmap for this purpose, it can't be done again. Solid indeed, expensive ? The rfc2535-NXT design was expensive to begin with. It's a close design, not open to extend anything. And that the NXT is absolutely neccessary right now is even worse. How do you replace that in the future ? Very hard to do. If we would design a new NXT (lets call it NEX for argument sake), how and where do we signal between NXT and NEX and NO records if at least one of them is mandatory. In the SEC record ? And how do we give authenticated denial for that SEC record. Would that be done with NXT, NEX or NO ? And where would that be signalled ? In the parent ? Am I going in loops ? The above is the real reason why opt-in moved from signalling by KEY to signalling by NXT (the reason I wrote the no-sig draft). The current NXT design can be extended by simply assigning pseudo-RRtypes (huh?, yep!). Types that only exist in the type-bit-map of a NXT record (the original NO-SIG design), but then again, that would be even an uglier hack than using the redundant NXT bit in the type-bit-map. Proposing to design a new NXT type (=add a few more years) from the ground up would probably get me shot in SLC by some religious DNSSEC fanatic. Time is the most expensive protocol of all. Roy Arends to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Dec 6 18:13:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15816 for ; Thu, 6 Dec 2001 18:13:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16C7Ma-000GX6-00 for namedroppers-data@psg.com; Thu, 06 Dec 2001 14:51:32 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16C7MZ-000GWx-00 for namedroppers@ops.ietf.org; Thu, 06 Dec 2001 14:51:31 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16C7MZ-000FYg-00 for namedroppers@ops.ietf.org; Thu, 06 Dec 2001 14:51:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112061134.fB6BYeY48804@open.nlnetlabs.nl> In-Reply-To: "Edward Lewis's message as of Dec 5, 21:48" From: ted@tednet.nl (Ted Lindgreen) Date: Thu, 6 Dec 2001 12:34:40 +0100 To: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Edward Lewis, on Dec 5, 21:48, in "Re: Transition from ..."] > The question of whether "authenticated denial is desired" has been answered > "yes" a number of times over the past year or so The question has been > raised by the WG chair on the list and in person at London. So it appears > that there is a desire to provide the service. (Why? I don't know.) I'm sorry, but I may have expressed myself poorly, but this was not something I was trying to argue against. I was also present in London and understand why and when authenticated denial is desired. I also understand that Opt-In does not do away with authenticated denial. My question, however is (and also was in London, where an answer was given, no consensus was reached, as far as I understood); "what do we want to achieve with DNSSEC"? If it is, like Vixie, myself and others argue: "To protect the DNS infrastructure" or said differently: "to single out, and get rid of bad RRs in an environment of certifyable and intentionally uncertifyable RRs" then we need authenticated denial. This is to detect when certified RRs are being replaced by spoofed uncertified RRs. (Please note that all arguments for the need of authenticated denial, including the post of Mike Schiraldi in this thread, are about this kind of attacks). However, if the goal is, like the author of the current Opt-In proposal states, and was voiced by quite a number of people at the off-the-record DNSSEC meeting during the IETF in London: [Quoting Roy Arends, on Dec 5, 14:04, in "Re: Transition from ..."] > .... > secure only the RRsets that matter. > secure only what needs to be secured. > .... then I argue that authenticated denial is not needed, as we now only need to prove that a certain RR that we want to be secured verifies. Example: I (secure aware user) want to setup an ssh/ipsec tunnel, do banking business, or whatever, with you (secure aware site). It would be very handy, if I can get the key-info from DNS, but I would only use that info when it verifies. The same is true for the other side, as you want to make sure that I am the one I pretend to be. Now there are only two possibilities that matter: 1. It verifies ==> OK 2. It does not verify ==> not OK, but further it is totally irrelevant whether the info was bad, spoofed, had an outdated sig, or was intentionally not secured: for its usage it is just not good enough. The same reasoning comes up for every "RR that matters": you want it to verify or else it's just worthless. The need for authenticated denial was to determine whether info is "intentionally not secured" or "bad", but this distinction is irrellevant for the ""RRs that matter". Why do a make a big point of it? Probably, because I am also looking at it from the user/resolver point of view, and not only from the large TLD point of view. With our (NLnet Labs) work on designing a secure aware resolver we found out the hard way, that: - It is very easy to add a sig-checker and key-chaser to a (stub-) resolver to proof that a secured RR verifies or not. This is a simple bottom-up procedure: get RR/get SIG/get KEY/verify/get SIG of KEY/.. etc. up to a KEY we trust. For the "secure only the RRsets that matter" approach, this is fine and all we need. - However, to "protect the DNS infrastructure" we need to build a resolver, that finds out when secured RRs are being replaced by spoofed uncertified RRs. And this is much more difficult. It requires a top-down analysis of the DNS tree. In fact, it needs the whole DNS machinery which is now only present in the caching forwarders, to be plugged into the stubresolver. Now, with Opt-In we go implement the whole complex machinery, but gain only the "secure only the RRsets that matter" goal. Looking at the added complexity the one hand, and at the gain on the other, I really think we are on the wrong track. In conclusion: If the goal is "To protect the DNS infrastructure", then let us get consensus about that, and we go all the way. But, if the goal is "secure only the RRsets that matter" let us get consensus about that, then first cleanup the complexity not needed anymore, and go that way. Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 00:45:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27834 for ; Fri, 7 Dec 2001 00:45:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CDcS-00061y-00 for namedroppers-data@psg.com; Thu, 06 Dec 2001 21:32:20 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16CDcR-00061s-00 for namedroppers@ops.ietf.org; Thu, 06 Dec 2001 21:32:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16CDcR-000GzB-00 for namedroppers@ops.ietf.org; Thu, 06 Dec 2001 21:32:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112062348.fB6Nm9o39602@as.vix.com> In-Reply-To: Message from Roy Arends of "Thu, 06 Dec 2001 12:46:38 +0100." <20011206120232.Y46034-100000@main> To: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Date: Thu, 06 Dec 2001 15:48:09 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Proposing to design a new NXT type (=add a few more years) from the ground > up would probably get me shot in SLC by some religious DNSSEC fanatic. not me. when rome is going to burn, bring a bag of marshmellows, that's all. > Time is the most expensive protocol of all. yes. we should be deep in deployment by this time. let's not repeat the time-related errors that got us to where we're 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. From owner-namedroppers@ops.ietf.org Fri Dec 7 10:47:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22611 for ; Fri, 7 Dec 2001 10:47:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CN1R-0003M0-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 07:34:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16CN1Q-0003Lu-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 07:34:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16CN1Q-000H1h-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 07:34:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112071334.fB7DYp657398@open.nlnetlabs.nl> In-Reply-To: "Roy Arends's message as of Dec 7, 0:17" From: ted@tednet.nl (Ted Lindgreen) Date: Fri, 7 Dec 2001 14:34:51 +0100 To: Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Roy Arends, on Dec 7, 0:17, in "Re: Transition from ..."] > On Wed, 5 Dec 2001, Edward Lewis wrote: > > > At 5:50 AM -0500 12/5/01, Ted Lindgreen wrote: > > >OptIn: if OptIn, why not just forget NXT? > > > > The question of whether "authenticated denial is desired" has been answered > > "yes" a number of times over the past year or so The question has been > > raised by the WG chair on the list and in person at London. So it appears > > that there is a desire to provide the service. (Why? I don't know) > > Why ? > > In a secured world I want cryptographic proof that somebank.info does not > exist if asked for. Simply handing over an NXDOMAIN status doesn't cut it, > anyone could give me that status, and there is nothing to cryptographicly > verify. Would make a beauty of a DoS if it did. Please note, that if you can substitude a secured RR by an NXDOMAIN, you can probably substitude also other info. Therefore, when a DOS attack is the goal, and substitution is possible, there a plenty more possibilities to do that. This is true whether we have DNSSEC or not. And if we have DNSSEC, it can be done whether the zone is signed or not. In fact, I am affraid that it is even easier to DoS a secured RR, because just flipping any single bit in any of the accompagning SIG/KEY chain will do just as fine as substituting the RR itself, so the substitution possibilities only increase. This seems bad, but please understand that DNSSEC was neither designed, nor capable as defence against DoS attacks. So, yes, there may be compelling arguments why and when authenticated denial is desired, but defence against DoS attacks is not one of them. Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 10:49:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22634 for ; Fri, 7 Dec 2001 10:49:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CMxi-0003DE-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 07:30:54 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16CMxh-0003D8-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 07:30:53 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16CMxh-000GvF-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 07:30:53 -0800 In-Reply-To: <200112061134.fB6BYeY48804@open.nlnetlabs.nl> Message-ID: <20011207111142.T46034-100000@main> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 7 Dec 2001 11:38:07 +0100 (CET) From: Roy Arends To: Ted Lindgreen Cc: Edward Lewis , Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 6 Dec 2001, Ted Lindgreen wrote: > then I argue that authenticated denial is not needed, as we now > only need to prove that a certain RR that we want to be secured > verifies. Example: > > I (secure aware user) want to setup an ssh/ipsec tunnel, do > banking business, or whatever, with you (secure aware site). > It would be very handy, if I can get the key-info from DNS, > but I would only use that info when it verifies. > The same is true for the other side, as you want to make sure > that I am the one I pretend to be. > Now there are only two possibilities that matter: > 1. It verifies ==> OK > 2. It does not verify ==> not OK, but further it is totally > irrelevant whether the info was bad, spoofed, had an > outdated sig, or was intentionally not secured: for its > usage it is just not good enough. ridiculous 1. it verifies ==> OK 2. it does not verify ==> not OK. Then I want to know what went wrong. -) Spoofed ? -) DoSed ? -) Simple typo on my side ? -) some other unexpected variable ? OR -) is it VERIFIABLY UNSECURE ? The difference between the first 4 points and the last is authenticated denial. With the first 4 you simply don't know what went wrong. When you identify your bank and it is not ok, you then simply go home and tell yourself "not ok" and don't care about it ? The rest is irrelevant ? Or could it be that the bank moved, you're lost, you're in the wrong city or simply are at the wrong bank. There is no difference between a signed RRset AND it's authenticated denial in opt-in and in rfc 2535, whether we're talking usage or importance. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 11:13:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23319 for ; Fri, 7 Dec 2001 11:13:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CNS0-0004QF-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 08:02:12 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16CNS0-0004Q9-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 08:02:12 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16CNS0-000Hwv-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 08:02:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112071557.QAA10668@omval.tednet.nl> In-Reply-To: "Roy Arends's message as of Dec 7, 11:30" From: ted@tednet.nl (Ted Lindgreen) Date: Fri, 7 Dec 2001 16:57:23 +0100 To: Roy Arends , Ted Lindgreen Subject: Re: Transition from 2535 to opt-in Cc: Edward Lewis , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Roy Arends, on Dec 7, 11:30, in "Re: Transition from ..."] > On Thu, 6 Dec 2001, Ted Lindgreen wrote: > > > then I argue that authenticated denial is not needed, as we now > > only need to prove that a certain RR that we want to be secured > > verifies. Example: > > > > I (secure aware user) want to setup an ssh/ipsec tunnel, do > > banking business, or whatever, with you (secure aware site). > > It would be very handy, if I can get the key-info from DNS, > > but I would only use that info when it verifies. > > The same is true for the other side, as you want to make sure > > that I am the one I pretend to be. > > Now there are only two possibilities that matter: > > 1. It verifies ==> OK > > 2. It does not verify ==> not OK, but further it is totally > > irrelevant whether the info was bad, spoofed, had an > > outdated sig, or was intentionally not secured: for its > > usage it is just not good enough. > > > > ridiculous > > > 1. it verifies ==> OK > 2. it does not verify ==> not OK. > > Then I want to know what went wrong. > > -) Spoofed ? > -) DoSed ? > -) Simple typo on my side ? > -) some other unexpected variable ? > > OR > > -) is it VERIFIABLY UNSECURE ? > > The difference between the first 4 points and the last is authenticated > denial. With the first 4 you simply don't know what went wrong. Yes, that is exactly the point: - When "you" are the DNS infrastructure, this info is essential, because it distiguishes your actions between: - It is BAD ==> Throw it away. - It is intentionally not secured ==> Keep it as such. - But when "you" are a user, interested to use valid key-info, then it is only usable when it verifies. If it does not verify, the next step is error handling, in which the DNS-protocol may or may not assist you in analysing the problem. And perhaps you even have to call/mail some relevant person to ask "what's up?". But in the meantime the bottomline remains: no verification ==> no valid key-info. > When you identify your bank and it is not ok, you then simply go home and > tell yourself "not ok" and don't care about it ? The rest is irrelevant ? When this bank tells me my credit card is "not ok", I certainly do care about that, and it is certainly relevant. I have to go into an error handling procedure, in which the bankemployee or ATM machine may or may not assist me in analysing my problem. Perhaps I even have to call my own bank to ask "what's up?". But in the meantime the bottomline remains: no valid credit card ==> no money. Please note, that there is a difference between: "securing the infrastructure", where you want to weed out all the BADs between many certifieds and uncertifieds; and "securing certain special RRs, such as an ipsec-key", where you just want to check that your special RRs verify and all other RRs are irrelevant. The difference is that in the former authenticated denial is crucial, and in the latter at most informative for error handling. Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 12:51:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25895 for ; Fri, 7 Dec 2001 12:51:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16COzH-0008Hm-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 09:40:39 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 16COzH-0008Hg-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 09:40:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16COzH-000Kc9-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 09:40:39 -0800 In-Reply-To: <200112071334.fB7DYp657398@open.nlnetlabs.nl> Message-ID: <20011207174337.V47758-100000@main> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 7 Dec 2001 18:21:42 +0100 (CET) From: Roy Arends To: Ted Lindgreen Cc: Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 7 Dec 2001, Ted Lindgreen wrote: > [Quoting Roy Arends, on Dec 7, 0:17, in "Re: Transition from ..."] > > > On Wed, 5 Dec 2001, Edward Lewis wrote: > > > > > At 5:50 AM -0500 12/5/01, Ted Lindgreen wrote: > > > >OptIn: if OptIn, why not just forget NXT? > > > > > > The question of whether "authenticated denial is desired" has been answered > > > "yes" a number of times over the past year or so The question has been > > > raised by the WG chair on the list and in person at London. So it appears > > > that there is a desire to provide the service. (Why? I don't know) > > > > Why ? > > > > In a secured world I want cryptographic proof that somebank.info does not > > exist if asked for. Simply handing over an NXDOMAIN status doesn't cut it, > > anyone could give me that status, and there is nothing to cryptographicly > > verify. Would make a beauty of a DoS if it did. > > Please note, that if you can substitude a secured RR by an NXDOMAIN, > you can probably substitude also other info. > Therefore, when a DOS attack is the goal, and substitution is > possible, there a plenty more possibilities to do that. > This is true whether we have DNSSEC or not. And if we have DNSSEC, > it can be done whether the zone is signed or not. > > In fact, I am affraid that it is even easier to DoS a secured RR, > because just flipping any single bit in any of the accompagning > SIG/KEY chain will do just as fine as substituting the RR itself, > so the substitution possibilities only increase. > > This seems bad, but please understand that DNSSEC was neither > designed, nor capable as defence against DoS attacks. > > So, yes, there may be compelling arguments why and when authenticated > denial is desired, but defence against DoS attacks is not one of them. I keep hearing that statement over and over all over the place in several ways, shape and form. "DNSSEC was not designed as a defense against DoS attacks". When I say "beauty" of a "DoS" attack, I implied one can actually (ab)use DNSSEC in an almost perfect way to simply kick a domain of the planet if one would do away with authenticated denial. Note that this is a far more efficient (several orders) of DoS attack then simply compromising a record on the fly. If the "DNSSEC was not designed as a defense against DoS attacks" is used as a general statement, why aren't NXT and SIG generated on the fly ? EXACTLY, to make sure the system will not be used against a DoS. And why is there DNSSEC in general ? To defend against spoofs, poisons and other DoS attacks. It is all in the eye of the (secure) resolver. It wants some cryptographic proof, a signed record, something to verify. Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 19:03:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02959 for ; Fri, 7 Dec 2001 19:03:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CUPg-000G8S-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 15:28:16 -0800 Received: from 42-196-131-12.bellhead.com ([12.131.196.42] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16CUPg-000G8M-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:28:16 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16CUPd-0000BH-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:28:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Roy Arends of "Fri, 07 Dec 2001 18:21:42 +0100." <20011207174337.V47758-100000@main> Message-Id: <20011207185837.AA2932A51@orchard.arlington.ma.us> From: Bill Sommerfeld To: Roy Arends Cc: Ted Lindgreen , namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Date: Fri, 07 Dec 2001 13:58:32 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm not quite sure who said this, but: > > This seems bad, but please understand that DNSSEC was neither > > designed, nor capable as defence against DoS attacks. > > > > So, yes, there may be compelling arguments why and when authenticated > > denial is desired, but defence against DoS attacks is not one of them. This position taken to an extreme would encourage us to engineer a "please crash" request into every protocol. It would be wrong to lump all denial-of-service attacks together into a single category -- there are many different sorts of attacks which could cause denial of service. Some are easy to defend against, some are hard. IMHO, the way to go is to engineer protocols (and implementations) to be robust against low-packet-rate denial-of-service attacks (such as forged NXDOMAINS and the "classic" SYN flood), while efforts like itrace provide tools to allow network operators to deal with the high-packet-rate attacks. - Bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 19:15:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03126 for ; Fri, 7 Dec 2001 19:15:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CUat-000GN3-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 15:39:51 -0800 Received: from 42-196-131-12.bellhead.com ([12.131.196.42] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16CUas-000GMs-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:39:50 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16CUaq-0000CD-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:39:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698BD@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Paul A Vixie'" , namedroppers@ops.ietf.org Subject: RE: Transition from 2535 to opt-in Date: Fri, 7 Dec 2001 11:33:14 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, Your argument reminds me of the Menendez brothers, who shot their parents and then asked the court for liniency because they are orphans. If you want the discussion to stop then don't fillibuster. Deployment issues are NEVER solved by ignoring them. If you succeed in your apparent aim of stopping deployment of Opt-in you will stop deployment of DNSSEC entirely in the large TLDs. Furthermore, if you were correct in your assertion that Opt-in is incompatible with 2535 then partial deployment in the small domains would block any deployment in the large domains until a new opt-in spec is developed. I dispute your initial assertion but if you insist on making it then please note that in the absence of deployment the discovery of an error in a protocol that prevents extensibility argues for fixing the protocol and not propogating a broken one. Let us consider the history of some other IETF working groups. PEM did not advance deployment by refusing to change its undeployable PKI architecture. The intransigence of the PEM working group eventually fractured the email security space so that we had PGP and S/MIME in competition. This is an engineering issue. Without opt-in the DNSSEC records for .com will take up approximately ten times their current amount of space. That means ten times the amount of RAM, ten times the amount of disk storage, ten time the amount of silo storage etc. The costs of signing the zone are prohibitive even before we count the cost of the signing devices or work out how to securely manage the necessary number of private keys. This is before you get to the problem of distributing the data. If I was on the ICANN board I would explicitly prohibit my contractor from deploying DNSSEC without opt-in. The risk of introducing instability into the main TLDs vastly outweighs any advantage that can be argued for DNSSEC prior to deployment. I am an engineer. For me the cost of deployment is a significant issue. If a specification requires large deployment costs for a security feature that few parties will be able to take advantage of then it is a bad specification. As for your analysis of the security requirements; first DNSSEC will provide no security at all if it remains as spec-ware. Second I do not agree that you have identified a significant security issue. If it were the case that I had $O(10^8) extra to spend on DNS security I would be spending it on physical security (and I would not be telling you in particular what I was doing). Cryptography is no defense against terrorists whose principal skills are knowing how to clean an AK47 and milk a goat. I don't have great respect for people who go around announcing possible targets to these folk through the AP and Reuters. Careless talk such as yours could cost lives. Perhaps next time you could give the street addresses of the new facilities as well so they don't bomb an empty building by mistake. It is very easy to delay deployment of cryptographic specifications by raising alleged security issues that can only be addressed at prohibitive cost. If you wish to continue your filibuster please do not blame others for the delay in deployment that you are causing. At this point there are only two possible outcomes: 1) We deploy DNSSEC with opt-in. 2) We design a new specification entirely. If you insist that you cannot live with option 1 and the group agrees with you then it is time to burn the 2535 drafts and start again. The sooner we do this the better, since the longer we delay starting the longer it will be until we finish. I would prefer to begin by deploying DNSSEC-opt-in and then start consideration of additional opportunities there are to add security to the DNS system. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Research VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Paul A Vixie [mailto:vixie@vix.com] > Sent: Wednesday, December 05, 2001 3:35 PM > To: namedroppers@ops.ietf.org > Subject: Re: Transition from 2535 to opt-in > > > > Expensive in that this mechanism can only be done once. If > we use the NXT > > bit in the bitmap for this purpose, it can't be done again. > > sure it can. we can continue discussing the whichness of > what in our ivory > tower for another five years (it's already been five years; > what's five more?) > three years from now we'll have opt-maybe, opt-in, opt-out, > and who knows what > else. > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 19:16:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03146 for ; Fri, 7 Dec 2001 19:16:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CUZe-000GLk-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 15:38:34 -0800 Received: from 42-196-131-12.bellhead.com ([12.131.196.42] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16CUZd-000GLe-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:38:33 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16CUZb-0000C9-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:38:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058698BC@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Olaf Kolkman'" , namedroppers@ops.ietf.org Subject: RE: Transition from 2535 to opt-in Date: Fri, 7 Dec 2001 11:21:23 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > AFAIK .com is one of the few (and maybe the only) zone(s) that has > scaling problems when using a non granular (rfc2535) approach. What I > understand from the NLnet Labs folk is that it is technically possible > to sign and serve relatively big TLDs such as .de (on a desktop PC) > and even .com (on a $5000 alpha). Olaf, Let us imagine for a moment that we get you to sign a rack of non-disclosure forms, blindfold you, take you on a drive to our data center etc. etc. Do you imagine that you would see the current .com zone being served by a '$5,000 alpha' or anything that remotely resembles such a small scale without DNSSEC? I am interested to learn how deployment of a specification that increases the data volume by an order of magnitude can reduce hardware costs by several orders of magnitude. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 19:23:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03331 for ; Fri, 7 Dec 2001 19:23:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CUol-000Gjc-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 15:54:11 -0800 Received: from 42-196-131-12.bellhead.com ([12.131.196.42] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16CUok-000GjQ-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:54:10 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16CUoi-0000D5-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:54:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20011207174337.V47758-100000@main> In-Reply-To: Roy Arends's message of "Fri, 7 Dec 2001 18:21:42 +0100 (CET)" Message-ID: To: Roy Arends Cc: Ted Lindgreen , Subject: Re: Transition from 2535 to opt-in From: Derek Atkins Date: 07 Dec 2001 17:48:31 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends writes: > If the "DNSSEC was not designed as a defense against DoS attacks" is used > as a general statement, why aren't NXT and SIG generated on the fly ? > EXACTLY, to make sure the system will not be used against a DoS. Well, partially. They are not created in real-time because the data is quazi-static. Why re-sign the same data over and over when you can sign it once and re-use the signature? Also, creating signatures is an _expensive_ operation. It was even more so 5+ years ago when 2535 was being written. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 19:25:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03349 for ; Fri, 7 Dec 2001 19:25:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CUpJ-000GkC-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 15:54:45 -0800 Received: from 42-196-131-12.bellhead.com ([12.131.196.42] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16CUpJ-000Gk5-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:54:45 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16CUpG-0000DA-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 15:54:42 -0800 In-Reply-To: Message-ID: <20011208000812.J47758-100000@main> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sat, 8 Dec 2001 00:19:25 +0100 (CET) From: Roy Arends To: Derek Atkins Cc: Roy Arends , Ted Lindgreen , Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 7 Dec 2001, Derek Atkins wrote: > Roy Arends writes: > > > If the "DNSSEC was not designed as a defense against DoS attacks" is used > > as a general statement, why aren't NXT and SIG generated on the fly ? > > EXACTLY, to make sure the system will not be used against a DoS. > > Well, partially. They are not created in real-time because the data > is quazi-static. Why re-sign the same data over and over when you can > sign it once and re-use the signature? Also, creating signatures is > an _expensive_ operation. It was even more so 5+ years ago when 2535 > was being written. You're right and there is also the private key on an online machine issue. All these arguments make a case for NXT+SIG to be generated in advance. The argument (DoS) I made came up when I was looking at alternatives for storing NXT+SIG's. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Dec 7 20:41:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04319 for ; Fri, 7 Dec 2001 20:41:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CW8p-000IMw-00 for namedroppers-data@psg.com; Fri, 07 Dec 2001 17:18:59 -0800 Received: from 42-196-131-12.bellhead.com ([12.131.196.42] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16CW8p-000IMp-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 17:18:59 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16CW8m-0000GZ-00 for namedroppers@ops.ietf.org; Fri, 07 Dec 2001 18:18:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112080026.fB80QHo64593@as.vix.com> In-Reply-To: Message from Roy Arends of "Sat, 08 Dec 2001 00:19:25 +0100." <20011208000812.J47758-100000@main> To: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Date: Fri, 07 Dec 2001 16:26:17 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > EXACTLY, to make sure the system will not be used against a DoS. > > > > Well, partially. They are not created in real-time because the data > > is quazi-static. Why re-sign the same data over and over when you can > > sign it once and re-use the signature? Also, creating signatures is > > an _expensive_ operation. It was even more so 5+ years ago when 2535 > > was being written. well, the protocol as it sits right now (but not for long!) was designed with the idea that dynamic calculation would be too expensive. in other words the reason we precalc these sigs is because we can, and the reason we can is because we thought we would have to so we designed it that way. > You're right and there is also the private key on an online machine issue. > All these arguments make a case for NXT+SIG to be generated in advance. > The argument (DoS) I made came up when I was looking at alternatives for > storing NXT+SIG's. does anybody other than me think that if we're still addressing issues at this fundamental level five+ years into the project, that we're just doomed? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Dec 8 10:07:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29943 for ; Sat, 8 Dec 2001 10:07:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CiaI-0005WB-00 for namedroppers-data@psg.com; Sat, 08 Dec 2001 06:36:10 -0800 Received: from 254-205-131-12.bellhead.com ([12.131.205.254] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16CiaI-0005W5-00 for namedroppers@ops.ietf.org; Sat, 08 Dec 2001 06:36:10 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16CiaE-0000U7-00 for namedroppers@ops.ietf.org; Sat, 08 Dec 2001 07:36:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112081103.fB8B3Gs66168@open.nlnetlabs.nl> In-Reply-To: "Paul A Vixie's message as of Dec 8, 2:47" From: ted@tednet.nl (Ted Lindgreen) Date: Sat, 8 Dec 2001 12:03:16 +0100 To: Paul A Vixie , namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Paul A Vixie, on Dec 8, 2:47, in "Re: Transition from ..."] > does anybody other than me think that if we're still addressing issues at > this fundamental level five+ years into the project, that we're just doomed? Well, my solid conclusion, after leading a team of DNSSEC developers for the past years is, unfortunately, that you are right about the first part of above question. About the last part of your question... I'm very close to agree. Well, in fact... let me explain: At the London meeting (not during an official meeting, but a side-one, where most of the DNSSEC specialists, some 40 people, met), the question was raised: "Is the DNS cache poisoning threat still an issue here?" A surprisingly large part, well the overly majority of the people present, reacted in the range between: "Hmm, no, this is mostly fixed already, isn't it?" and "Well, no, at least that's not why we want DNSSEC." During the official meeting where other security people were dominating, the wind blew from an other direction. The need to recap the threats was adviced, and in the mean time a draft is presented (draft-ietf-dnsext-dns-threats-00.txt by Atkins and Austein). We were totally puzzled with development going one way, and dnsops talking about another. As a result, we, NLnet Labs, have put our DNSSEC development work on ice. Without a common goal, it is impossible te determine a direction. And therefore, I keep asking (and feel like a broken record) the question: please let's restate our goal again. Then, I see 3 possible outcomes (but there will, no doubt be more, and hopefully better): 1. The goal remains: "Protect the DNS infrastructure" Then, we should focus on either deployment on 2535, with only the real necessary modifications, or conclude that 2535 won't ver work, and put our focus on developing DNS-2 or some other alternative. 2. If the goal is: "A cheap PKI". Then, let's design, build and implement a cheap PKI, and please don't try to clobber into DNS. 3. A compromise, where only "the info the must be signed, is signed". Then, the right way is to strip RFC 2535 to do just that, and not increase its complexity with opt-whatever. Anyway, when above decision is made, NLnet Labs is ready to join the development-party again, but as longs we are directionless, we will standby. Regards, -- ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Dec 8 11:41:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01169 for ; Sat, 8 Dec 2001 11:41:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16CkC7-0007Mo-00 for namedroppers-data@psg.com; Sat, 08 Dec 2001 08:19:19 -0800 Received: from 254-205-131-12.bellhead.com ([12.131.205.254] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16CkC6-0007Me-00 for namedroppers@ops.ietf.org; Sat, 08 Dec 2001 08:19:18 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16CkC6-0000aC-00 for namedroppers@ops.ietf.org; Sat, 08 Dec 2001 09:19:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112081617.fB8GHao88658@as.vix.com> In-Reply-To: Message from ted@tednet.nl (Ted Lindgreen) of "Sat, 08 Dec 2001 12:03:16 +0100." <200112081103.fB8B3Gs66168@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Date: Sat, 08 Dec 2001 08:17:36 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > At the London meeting (not during an official meeting, but a > side-one, where most of the DNSSEC specialists, some 40 people, > met), the question was raised: > "Is the DNS cache poisoning threat still an issue here?" > > A surprisingly large part, well the overly majority of the > people present, reacted in the range between: > "Hmm, no, this is mostly fixed already, isn't it?" they were wrong. it's not fixed. it's not fixable without a protocol change. > and > "Well, no, at least that's not why we want DNSSEC." had i been there i would have said "this is only one of several reasons why i want dnssec." folks use "cheap PKI" as a covering term but it's a misnomer. there's a whole class of data which i won't use the DNS to propagate because DNS is extremely spoofable. > Anyway, when above decision is made, NLnet Labs is ready to join the > development-party again, but as longs we are directionless, we will > standby. isc, on the other hand, remains only as committed as the people who fund us. right now the thing i see as needing work is the protocol development process itself. irrespective of the comments from verisign labs here yesterday, i get the impression that dnssec won't be allowed to progress to the point where it is "stable enough" for deployment until several namedroppers decide to retire. (the verisign counter-challenge was that dnssec can't be stable until it's feature-complete. that skins the same cat but indirectly.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 9 13:31:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03174 for ; Sun, 9 Dec 2001 13:31:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16D8Lu-000Fly-00 for namedroppers-data@psg.com; Sun, 09 Dec 2001 10:07:02 -0800 Received: from 254-205-131-12.bellhead.com ([12.131.205.254] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16D8Lu-000Fls-00 for namedroppers@ops.ietf.org; Sun, 09 Dec 2001 10:07:02 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16D8Lt-0000Gr-00 for namedroppers@ops.ietf.org; Sun, 09 Dec 2001 11:07:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200112091804.fB9I4VG15699@birch.ripe.net> In-Reply-To: Message from "Hallam-Baker, Phillip" of "Fri, 07 Dec 2001 11:21:23 PST." <2F3EC696EAEED311BB2D009027C3F4F4058698BC@vhqpostal.verisign.com> To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org Subject: Re: Transition from 2535 to opt-in Date: Sun, 09 Dec 2001 19:04:31 +0100 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Hallam-Baker, Phillip" writes: * > understand from the NLnet Labs folk is that it is technically possible * > to sign and serve relatively big TLDs such as .de (on a desktop PC) * > and even .com (on a $5000 alpha). * * Olaf, * * Let us imagine for a moment that we get you to sign a rack of * non-disclosure forms, blindfold you, take you on a drive to our * data center etc. etc. That would be fun :-) * * Do you imagine that you would see the current .com zone being * served by a '$5,000 alpha' or anything that remotely resembles such * a small scale without DNSSEC? Sorry, I misphrased that sentence. NLnet Labs only looked at signing not at serving. Signing of .com was possible on a commodity machine. I do understand that serving the a larger data volume is more costly and I also do understand opt-in allows one for a slow transition. --Olaf to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Dec 9 18:36:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05804 for ; Sun, 9 Dec 2001 18:36:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16DDCT-000PBU-00 for namedroppers-data@psg.com; Sun, 09 Dec 2001 15:17:37 -0800 Received: from 254-205-131-12.bellhead.com ([12.131.205.254] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 16DDCS-000PBO-00 for namedroppers@ops.ietf.org; Sun, 09 Dec 2001 15:17:36 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16DDCR-0000lX-00 for namedroppers@ops.ietf.org; Sun, 09 Dec 2001 16:17:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20011209130056.02401770@localhost> In-Reply-To: <4.3.2.7.2.20011120150342.01e852f8@funnel.cisco.com> References: Date: Sun, 09 Dec 2001 13:06:52 -0500 To: Mark Stapp , namedroppers From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: wg last call for draft-ietf-dnsext-dhcid-rr-03.txt to ps Cc: mellon@nominum.com, gson@nominum.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 04:39 PM 11/21/2001, Mark Stapp wrote: >At 02:37 PM 10/19/2001 -0700, Randy Bush wrote: > > >there seem to be folk too tired to speak for themselves on the mailing list, > >so they send this stuff to me in email. as 2026 does not specify that one > >has the right to confront one's accusors, i will forward anonymously :-) > >I've made revisions that address these comments and submitted a new draft. >The notification will show up as soon as the draft editor processes my >submission. Specifics inline: > >-- Mark > > > >3. Does not explicitly state if this is a singleton type or multiple > > DHCID RR can be in a set. > >Done. I assume that there is some other document that specifies how to interpret multiple DHCID, it would be helpful to have a pointer to that. My understanding has been this is supposed to be a semaphore for DHCP servers but allowing multiple DHCID that semantics are broken. > >4. Section 3.4 should be structured something like: > > "digest is calculated over |